Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Android Encryption Security

Delivering Malicious Android Apps Hidden In Image Files 113

An anonymous reader writes "Researchers have found a way to deliver a malicious app to Android users by hiding it into what seems to be an encrypted image file, which is then delivered via a legitimate, seemingly innocuous wrapper app. Fortinet malware researcher Axelle Apvrille and reverse engineer Ange Albertini created a custom tool they dubbed AngeCryption, which allows them to encrypt the payload Android application package (APK) and make it look like an image (PNG, JPG) file . They also had to create another APK that carries the "booby-trapped" image file and which can decrypt it to unveil the malicious APK file and install it. A malicious app thusly encrypted is nearly invisible to reverse engineers, and possibly even to AV solutions and Google's Android Bouncer." (Here's the original paper, from researchers Axelle Apvrille and Ange Albertini.)
This discussion has been archived. No new comments can be posted.

Delivering Malicious Android Apps Hidden In Image Files

Comments Filter:
  • by omems ( 1869410 ) on Tuesday October 21, 2014 @09:23AM (#48195161)
    Two crypto researchers whose first and last names all start with the letter "A"?
  • by dasacc22 ( 1830082 ) on Tuesday October 21, 2014 @09:28AM (#48195203)
    This is just a really fancy way of clicking on an apk. So you install Foosball 2020 and click the app launcher icon and then your phone says "sorry, you need to enable installing 3rd party apps, bye!" and you say "damn you android! I want to play foosball with robots!" so you go through system settings and enable 3rd party installations and get a big warning. Then you open the app launcher icon again and instead of a game, you see a whole new installation screen for another app and the permissions it requires ...

    I think from a technical standpoint, this is really neat research, but there are much simpler ways to lead the cattle to the salt lick.
    • One problem might be that enabling third party apps seems to be an all or nothing affair. Your average Android device comes enabled to load apps from the Google Play store, but suppose you want to take advantage of the Amazon App Store also. (They have free apps of the day some of which might be interesting to use.) So you enable third party apps to load the Amazon App Store. However, now you are opened up to ANY third party app. It would be better if you could white-list the Amazon App Store but not R

      • Re: (Score:1, Interesting)

        by dasacc22 ( 1830082 )
        You white listed amazon app store when you reviewed the permissions and clicked install. Enabling 3rd party app installation is an all or nothing affair b/c its, well, 3rd parties.
        • by tepples ( 727027 )

          Enabling 3rd party app installation is an all or nothing affair b/c its, well, 3rd parties.

          Why doesn't the system provide a mechanism for the user to distinguish between trusted and untrusted third parties? For example, a user ought to have a way to choose to trust Amazon and F-Droid alongside Google but distrust all other APK sources.

          • by Himmy32 ( 650060 )
            Because that is putting time and effort into developing features to support competitors. At least they support competition with decent security.
            • by tepples ( 727027 )

              Because that is putting time and effort into developing features to support competitors.

              Canonical put time and effort into the Personal Package Archive system [launchpad.net], which supports competitors to the official Ubuntu repository. Each PPA is a Debian repository with a public key to verify packages, and a Canonical-managed PKI ties them together. True, a lot of that comes from the Debian project, but Canonical still polished it into PPAs starting in Ubuntu 9.10.

              • your point? 3rd party checkbox in this scenario would be like a flag that determines whether your /etc/apt/sources.list file is read or discarded when determining software to install (given the standard ubuntu repos will always be an apt source).
                • by tepples ( 727027 )
                  My point is that Debian and Debian-derived distributions let the owner of a machine edit sources.list and Android doesn't.
                  • it would be interesting if the market app actually worked like this and was decoupled from other google services.
          • by caseih ( 160668 )

            Well the fact of the matter is that Google is only interested in making sure their app store is the only trusted store. The choice to make it all or nothing was deliberate on their part. They could easily have implemented user-selectable trust of signing certificates. Granted 90% of android users don't even understand the problem, let alone the solution.

            Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file tha

            • by tepples ( 727027 )

              why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?

              Ask users of Snapchat.

            • Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?

              The payload is encrypted/embedded into an image that is an asset inside the application such as a splash screen or a logo. It appears innocuous until the application runs, extracts the embedded apk and executes it. Prior to that the malicious payload is not detected by application scanners that scan the carrier apk.

    • by dasacc22 ( 1830082 ) on Tuesday October 21, 2014 @09:39AM (#48195343)
      I stand corrected after RTFA

      In their testing, Android did show a permission request when the legitimate wrapper file tried to install the malicious APK, but the researchers say that this can be prevented by using DexClassLoader.

      Now that sounds plausible and like a real concern (that is being addressed).

    • And if you already have third party apps enabled for some reason?
      • that reads more like a statement rather than a question. Regardless of location source, whether google sanctioned or not, and if one has decided to install things from places other than google (arguably the 3rd party check box is the type of thing that makes android a google project versus pure OSS, or in the same respects is what differentiates chrome from chromium), etc, etc, when you install an application, you will be prompted. This prompt shares similarity with, for example, running a downloaded execut
  • by Overzeetop ( 214511 ) on Tuesday October 21, 2014 @09:30AM (#48195245) Journal

    So I'm going to install an app which is used to open a picture I don't know the origin of and which has been tampered with to append a second app, and if the first app opens the "picture" of choice it then installs another app which triggers a permission request (which they say they can work around).

    I'd say this is implausible, but between porn and LOLcats there are going to be some unsuspecting idiots out there who might actually get caught.

  • So what I really gather from this is encrypted apps can't be check, scan or searched for what the contents hold? Really?

    And seriously, hiding a payload inside something else isn't new, that's been around for decades at least.

    So in other words, don't install apps I have no idea where they come from? Sounds good to me.

    • > And seriously, hiding a payload inside something else isn't new, that's been around for decades at least.

      *cough* trojans *cough*

      decades you say?
  • So they've "invented" Steganography [wikipedia.org]?

    • by hawguy ( 1600213 )

      So they've "invented" Steganography [wikipedia.org]?

      What's with the down-votes? Is hiding an encrypted payload in an image file anything but steganography? it's certainly not a novel way to write a virus since the Windows virus writers have been hiding their code with encryption for quite some time.

  • Can this circumvent permissions of the calling app? If not, this is just another demonstration that arbitrary turing-complete code can not be automatically validated. One can also load Javascript into a WebView and enable it to execute arbitrary Java code through a reflection-based bridge. I am not sure what is the proposed solution.

  • and now go and read some books before you announce the next "big" thing.

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Working...