back to article Android trojan EventBot abuses accessibility services to clear out bank accounts – fortunately, it's 'in preview'

Researchers have analysed a new strain of Android malware that does not yet exist in the wild. Cybereason boffins did this by observing submissions to virus detection site VirusTotal not from the general public, but from one source presumed to be miscreants testing whether the nasty would be spotted. Its creators call the …

  1. Jamie Jones Silver badge

    And google/android will get the flack

    ... which is why later and later versions of android are having many capablities removed completely, rendering useless those apps that could legitimately make use of the functionality.

    They should really leave the more dangerous options in place, but hide their activation behind the developer mode, or something.

    1. Dan 55 Silver badge

      Re: And google/android will get the flack

      Perhaps all these dialogs which in the end boil down to:

      Do you want the shiny new app to work? Yes/No

      aren't an effective security measure. Perhaps it has to be done another way.

      Symbian used extended vetting if a developer wanted to use certain permissions and the app had to be signed with a different certificate which gave access to them. I'm not saying that should be the way for Android too, but Yes/No dialog boxes aren't security.

      1. robidy

        Re: And google/android will get the flack

        Seems like someone blowing smoke uo their arse and alerting hackers to avoid virus total until the last minute for effective deployment.

      2. Jamie Jones Silver badge

        Re: And google/android will get the flack

        I agree. My point was that they should be done a different way, rather than simply removed altogether.

      3. JimboSmith Silver badge

        Re: And google/android will get the flack

        There were people at work who thought I was slightly eccentric for having a feature phone for my calls and SMS, a smartphone for internet/apps etc. That's until somebody was unlucky enough to get some form of nasty on their phone. I don't know the full details (she's not in my dept) but I do know she banked using an app on the phone. They had 2FA through SMS and apparently she never saw the messages, especially the ones warning that a payement to a new account/sort code was being set up. It was only the bank being suspicious of some of the transactions that prevented their account being cleaned out.

        Last I heard she'd bought a new handset and wasn't using anything outside of the big well known apps from the App Store. I don't do internet banking but my family do and as far as I know they don't use apps. Card readers that generate codes or RSA token generators are prevalent.

    2. jelabarre59

      Re: And google/android will get the flack

      Yes, Google needs to be held responsible for not making access controls more granular, and for taking too long to give us the level of granular control we have now. And I'm sure they grudgingly did that, as giving us better control might mean we'd find ways to avoid the Google-kaiju.

      But a lot of blame also has to go to the lazy app developers, the ones who configured their apps to "request everything" for permissions, rather than actually THINKING about what they actually needed, and restricting the controls to just those.

      1. doublelayer Silver badge

        Re: And google/android will get the flack

        I'm usually quick to jump on the bandwagon of complaining about Android's security model and the way Google has delayed any improvements, but in this case, they really can't be blamed unless they fail to find it when someone eventually pushes it to them. An app using this functionality will have at least five security warning screens. The screens can't be bypassed. The screens are very clear what is going on, with no technical language or waffling. At this point, the users have quite a lot of responsibility if they read this and click yes.

        If Google lets this into the Play Store, they will have blame to take. There are other things we can attack them about for which they are completely blameworthy. In this case, there's little more they can do other than block it from their store--there is pretty much no change to Android that can cure stupid user syndrome.

        1. Anonymous Coward
          Facepalm

          Re: And google/android will get the flack

          Google does seem to be trying. Currently you can deny any permission for an app. However it may cause the app to break or limit its functionality (as Google points out). But John or Jane Doe just trusts the app (as they did when they clicked through any security warnings and checked off any EULAs). And requiring app developers to pay for, pass, and submit an independent security assessment for each app (and each app update) would raise an uproar.

  2. amanfromMars 1 Silver badge

    :-)

    I'm taking the fifth on this news.

  3. Anonymous Coward
    Anonymous Coward

    Assets

    The majority of malicious Android apps over the last couple of years have encrypted files located in the apps "Assests" directory including the malicious app mentioned in the Kaspersky article.

    (The "Browser Turbo-Scanner and Cleaner" app mentioned has an encrypted file in it's Assests folder called "data.dat")

    What I'm having a hard time understanding is why Google isn't able to flag these apps?

    A simple script to unpack the APK's and scan files in the Assets directory with the "file" command would show the presence of an encrypted file and could be flagged for further review.

    1. Anonymous Coward
      Anonymous Coward

      Re: Assets

      So I'll call it background.jpg and store the encrypted code as a base64 encoded metadata comment.

      1. Anonymous Coward
        Anonymous Coward

        Re: Assets

        Or in the least significant bit of the red channel, when combined with a stream cipher using a magic key downloaded in a months time.

      2. Anonymous Coward
        Anonymous Coward

        Re: Assets

        "So I'll call it background.jpg and store the encrypted code as a base64 encoded metadata comment."

        The "file" program does not look at a files extension to determine the file.

        https://linux.die.net/man/1/file

        https://en.wikipedia.org/wiki/List_of_file_signatures

        Just as the gallery app "Gallery_com.android.gallery3d.apk" found in the phones distributed by Assurance Wireless and Access Wireless through the government assistance "Lifeline" program that tried to disquise two encrypted executable Java Jar files as TrueType font files in it's assets file: "samsun.ttf and small.ttf".

        #MD5

        a212acf8ddeb513092b9d47999e94cca

        The 'file" command showed that these font files were fake and when decrypted showed that they were impersonating the Google Play store complete with a list of downloadable apps from third party providers and some even served on VPS's on Digital Ocean.

        apkfind[.]com

        cdn.apk-cloud[.]com

        dl3.apk-dl[.]com

        1. Aquilus

          Re: Assets

          "The "file" program does not look at a files extension to determine the file."

          Yes which is why i'm storing the code as a base64 encoded comment to a valid jpg. Keep up!

          1. Dan 55 Silver badge

            Re: Assets

            I think AC's point is how Google could and should find out something is up. Comparing the file type returned by file (or similar program which determines magic numbers) with the file type from the extension and checking if there's a difference.

  4. IGotOut Silver badge

    Wouldn't most users refuse such permissions

    Ha, ha ha ha ha.

    .

    Good one.

    Now I must hurry and download that Torch app that needs access to storage, contacts, network, SMS, phone calls and...oh I give up....to long to read...where do I click OK?

  5. Pascal Monett Silver badge

    "The human link is the weakest link in cyber security"

    Never have truer words been spoken. Truly secure procedures cannot actually be implemented because they impose so much inconvenience that humans automatically employ every imaginable workaround they can find.

    Cue the one PC that can access patient records with the logon and password on a post-it on the screen.

    Because people want convenience at any cost. Security is the opposite of convenient, because if it is convenient for you, it is also convenient for the hacker.

    1. a_yank_lurker

      Re: "The human link is the weakest link in cyber security"

      Good systemic security is a balance of convenience and restrictions. A common mistake is to assume you need access to your bank on your phone when access through a desktop or laptop might be all you really need for monitoring and paying bills. A related mistake is not to use a 100% wired connection whenever possible for financial and commercial activities from your desktop. Are both inconvenient, to a degree yes, but both are much more secure.

      1. Anonymous Coward
        Anonymous Coward

        Re: "The human link is the weakest link in cyber security"

        Only accessing banking services from a PC works great for me and you (and is the only way I handle financial transactions) but there are people out there that only have a smartphone for their communication needs.

        As for wired vs. wireless connections: if someone has the technological ability and the wherewithal to intercept my banking transactions over my home WiFi, then it's a small step for them to covertly break into my house and infiltrate my wired network. (I'm not advocating for logging into your financial sites from a random free WiFi access point by any means.)

      2. sitta_europea Silver badge

        Re: "The human link is the weakest link in cyber security"

        [quote]

        A common mistake is to assume you need access to your bank on your phone when access through a desktop or laptop might be all you really need for monitoring and paying bills.

        [/quote]

        An even commoner mistake is to have any online access to your bank at all.

  6. Ashto5

    Where IS The Protection

    Apple / Google etal

    Should implement a protection strategy, that FORBIDS users to download and install applications that have NOT been put through hard core security testing.

    IF they cannot protect the device then how the hell is a user tech or not supposed to ?

    *Example*

    I forwarded a suspect email to the security team via the dodgy email button in outlook, I did my part.

    Security opened the email and then opened the attachment, it encrypted every share within the company followed by popups asking for money.

    These companies / individuals need to be held responsible for the job they do / product they supply.

  7. TeeCee Gold badge
    Meh

    So it's "in preview" and yet not also widely deployed globally?

    That's Google off the list of potential authors then.

  8. Claptrap314 Silver badge
    Happy

    Here is your rouge user

    In another thread, there was some b******* & moaning about worrying about "rouge users" inside an organization.

    It's not the user, it's the user's device that matters.

    Certainly, a user might try to do naughty things. But absolutely, if the user's device is compromised, naughty things have already occurred.

    So, unless you can scan every website for every bit (heh) of malware that ever has or ever will exist, if you allow some access to the internet, than you must consider that machine, and every access coming off of it, compromised.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like