Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Android Security

Code Released To Exploit Android App Signature Vulnerability 81

chicksdaddy writes with news of a Proof-of-Concept exploit for the recent Android APK signature vulnerability. From the article: "Pau Oliva Fora, a security researcher for the firm Via Forensics, published a small, proof of concept module on GitHub that exploits the flaw in the way Android verifies the authenticity of signed mobile applications. The flaw was first disclosed last week by Jeff Forristal, the Chief Technology Officer at Bluebox Security, ahead of a presentation at the Black Hat Briefings in August. ... The simple program leverages APKTool, an open source tool for reverse engineering Android applications — decompiling and then recompiling their contents. His script allows a user to select and then decompile a legitimate Android application and then recompile it, creating an altered, 'malicious' APK that will have the same, cryptographic signature as the original file. In an e-mail statement, Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."
This discussion has been archived. No new comments can be posted.

Code Released To Exploit Android App Signature Vulnerability

Comments Filter:
  • So... (Score:5, Insightful)

    by Microlith ( 54737 ) on Monday July 08, 2013 @06:39PM (#44220723)

    This simplifies the generation of a hostile patch but, unless I'm mistaken, this still requires injecting the hostile patch into the Play Store via a trusted account or by convincing some sap to side load it.

    third party application stores – especially loosely regulated Android markets in the former Soviet republics and China could be fooled into hosting a malicious application that exploits the APK vulnerability he said.

    Gee, 3rd party stores in China and Russia being completely lax on security matters? Go figure.

    • by EEPROMS ( 889169 )
      That was what iIwas thinking, this would only effect people downloading apk files from third party sites or android users downloading files that they think are free version of a $$$ app. If you stick to the Google play app store then you should be fine for now.
      • Re: So... (Score:2, Insightful)

        by alen ( 225700 )

        Isn't the magic if android the fact that you can install from third party sources?

        • Re: So... (Score:4, Informative)

          by scot4875 ( 542869 ) on Monday July 08, 2013 @07:47PM (#44221103) Homepage

          Isn't the magic if android the fact that you can install from third party sources?

          Sure, that's one very nice thing, but it still doesn't allow you to just be a moron and expect everything to be hunky-dory.

          TotallyFreeVersionOfSomePopularGame.apk from a site that's written in mostly Cryillic or Chinese characters? Seems legit!

          --Jeremy

          • by smash ( 1351 )

            So you mean end users should check the digital signature to ensure that it is trustworthy? Or that the site they are retrieving from hasn't been hacked and trojaned?

            Oh, wait...

            • by damium ( 615833 )

              Digital signatures in android are mostly self signed (you can use a notarized certificate but it has to be issued as valid for 20 years to be on the play store, so good luck). They are for use in verifying updates automatically by the system for installed packages with the same name and for packages requesting to run with shared code or data as another package (upgrade key packages or feature modules for instance).

              If you want to verify the source you check the hash or only download from a trusted location.

              • by smash ( 1351 )
                So what you're saying is that basically - they're useless? I.e., it's a feature tickbox item that doesn't actually provide any meaningful benefit?
          • by amck ( 34780 )

            Y'know, there may be reasons why I don't want to go to Google Play even though the .apk I'm looking for is free (and 1$ is practically free). I'm not signed into Google Stores because they insist on me handing over just about everything about me.

            I'm _not_ giving access to my location, my contacts, etc.

            So, I'm on cyanogenmod and F-Droid for free software.

            • So what's your point? You've chosen to use F-Droid to vet your software rather than Google Play; good for you, that seems pretty reasonable and safe.

              The whole appeal of sideloading is to give yourself the option to take security into your own hands without Google or Apple or Microsoft babysitting you. You can't demand to get out of the walled garden for a stroll and simultaneously demand that the walled garden keep you safe and then get pissed when you get infected somewhere that the walled garden had no

        • What it means is that I can go to the app developer's web site to download the app. For example, if I want VLC, I'll go to VideoLAN to get VLC. The only way this signature vulnerability would affect me is if the app developer's web site is itself compromised.
          • by smash ( 1351 )

            Or, a mirror site. Which is not as uncommon as we'd like. Furthermore, without any red flags from say, invalid digital certs, detecting this would require some sort of checksum validation - which if the signature worked would be entirely un-necessary, and is the entire point of using a digital certificate.

            This is a major, major flaw - essentially the entire point using of digital signatures on android has been invalidated, unless your device has had this flaw patched.

            • Furthermore, without any red flags from say, invalid digital certs

              Are you talking about an invalid APK signature or an invalid SSL certificate? Because even if the APK signature is successfully forged, forging an HTTPS download would require the attacker to either A. compromise the developer's web server or B. both forge an SSL certificate and MITM the user's Internet connection. I will admit that this is easier with Android 4.x, whose SSL stack supports Server Name Indication, than with Android 2.x, which supports only clear HTTP for sites using name-based virtual hostin

      • by tlhIngan ( 30335 )

        That was what iIwas thinking, this would only effect people downloading apk files from third party sites or android users downloading files that they think are free version of a $$$ app. If you stick to the Google play app store then you should be fine for now.

        And eliminate useful third party legit sites?

        Like say, Amazon App Store? Or Humble Bundle apps?

        Sure, you tend to trust these apps as they're from legitimate sites, but are you ABSOLUTELY certain that Amazon and Humble Bundle are checking their files?

    • Re: So... (Score:5, Informative)

      by EGSonikku ( 519478 ) <petersen.mobile@gmail . c om> on Monday July 08, 2013 @06:54PM (#44220809)

      Google PlayStore does NOT use https for actual downloads (check your own WiFi logs). So in theory, if you were connected to an insecure/public WiFi network someone could intercept your download request and replace it with a compromised download using available WiFi auditing tools.

      • That's good to know, I'd always assumed it was HTTPS.

        • It's pretty odd, all the PlayStore APIs are done via https, but then the download is http. No idea why they'd do that.

          • ... unless there's another signature verification of the download with signature sent via HTTPS. Seems off though since Google does almost everything via HTTPS these days.

            • by gl4ss ( 559668 )

              ... unless there's another signature verification of the download with signature sent via HTTPS. Seems off though since Google does almost everything via HTTPS these days.

              it's so that they can do load balancing cheaper. some of the apk downloads can be quite sizey.

          • by smash ( 1351 )
            Performance. HTTP can be cached easily, and doesn't require processing overhead for the encryption. HTTPS not so much.
            • HTTP can be cached easily

              Resources served over HTTPS, such as style sheets, scripts, and images, can be cached just as easily by the client as resources served over HTTP. Yes, I'm aware that some web browsers disregard far-future Expires dates and exclude from disk cache so as not to leak HTTPS resources to other applications that can access the same file system. On the other side of a connection, the server can and ideally does cache portions of dynamic pages that seldom change. For example, some of the modules on Phil's Hobby Sh [philshobbyshop.com]

          • by AmiMoJo ( 196126 ) *

            Caching.

    • by Andy Dodd ( 701 )

      Also note that I believe Google is now scanning for APKs that have duplicate file entries - so this should (or will soon) get blocked right in the Play Store even with a trusted account, and also will likely get caught by Google's sideload malware scanning capabilities.

      In short, this "master key" is of no impact to any user that applies the most basic levels of common sense (don't sideload shit from sources you don't trust.)

  • by Anonymous Coward

    Their is a big difference between OS vendors' attitudes toward mobile devices and desktop/laptop computers. Many phones will never get - or even be able to run - the newer versions of Android that will have this flaw patched. Desktops & laptops get much longer support for their OS's.

    Yes, I know some Apple computers can't run the latest and greatest anymore. That's due to a hardware architecture change that took place several years ago.

    • by gnoshi ( 314933 )

      The 'get' is very true, the 'be able to run' is less true.
      If you look at some of the current 'budget' phones running 4.x, the specs are equivalent to previous phones which have ended with support for 2.2 or 2.3.
      Also, many phones have quite functional CyanogenMod releases based on 4.x when the most recent official release is 2.2 (Motorola Defy for example) or 2.3. This reflects a problem of desire on the part of manufacturers. (Perhaps also a problem of a lack of legal obligation to provide at least security

      • by damium ( 615833 )

        Indeed, also many of these fixes can also be/are already backported to older releases. The manufactures just don't care enough to build and test them and if they did the carriers don't want to send a patch through QA and the side deals for many branded phones don't let the manufactures publish updates directly.

  • by Anonymous Coward on Monday July 08, 2013 @06:43PM (#44220735)

    There's only one solution for a malicious APK.

    We need a custom HOSTS file ...

    • nonono! We need to assign a governmental agency to watch all our traffic and block all malicious content.
       

  • From a previous AC comment [slashdot.org]:

    APK's are signed with what amounts to the normal jar signing process. So either they have found a way to create a hash collision, or there's some other bug in the verification process that allows some unsigned code to be included in the file and executed.

    Either way, you will still need to trick people into installing your version of the apk.

    My guess is this: android just checks the first files matching in the jar/zip for the names, but installs the files found last in the jar(or vice versa, zip files can have multiples of the same filename).

  • by Anonymous Coward

    http://threatpost.com/android-vulnerability-enables-malicious-updates-to-bypass-digital-signatures/

    “Users need to be cognizant of the source of applications they’re installing and trustworthiness of the source of APKs if they’re not installing from Google Play,” Forristal said. “If you don’t know where the APK came from, it’s no different than grabbing .exes from the Net. Make sure you’re not using apps from untrusted sources and stick to Google Play; Google m

  • by complete loony ( 663508 ) <Jeremy DOT Lakeman AT gmail DOT com> on Monday July 08, 2013 @07:11PM (#44220901)
    Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.
    • Looks like the fix they have applied will cause java.lang.zip.ZipFile to throw a ZipException, indicating a format error, whenever it encounters a duplicate entry in *any* zip file, for *any* application using android's dalvik JVM.

      I'm not certain that's the correct response to this issue. Should a zip file with duplicate entries always be considered invalid?

      • What would that exactly mean, to have duplicate entries in a zip file? How would you even unzip it? You would end up having two files with the exact same name in a directory, an impossibility in most filesystems.

        I imagine that's how the exploit worked, when they checked the signatures, they just unzipped the first file that matched the signature name (which would be the original file), then they unzipped it, the first file being unzipped first, then the second file being unzipped and replacing the first.
        • by gl4ss ( 559668 )

          What would that exactly mean, to have duplicate entries in a zip file? How would you even unzip it? You would end up having two files with the exact same name in a directory, an impossibility in most filesystems.
          I imagine that's how the exploit worked, when they checked the signatures, they just unzipped the first file that matched the signature name (which would be the original file), then they unzipped it, the first file being unzipped first, then the second file being unzipped and replacing the first.

          you can just pick which files you unzip out of the zip. there's no problem in the format itself, there's no rule saying that you would have to unzip them all at once. this is the thought hole the google developers fell into. I don't understand why they don't sign the zip file itself and add the signature as a block at the end of fixed length(the way .jar signing for j2me worked was that you had to have the .jad application descriptor file distributed at the same time, that complicated things a lot in regard

    • Does this affect anything jars that are signed with the standard java jar signer as well?
      • I don't think it was a problem at the signing stage, it was a vulnerability at the stage where they check the signature.
    • by rabtech ( 223758 )

      So basically the signature only verifies the first instance of a file it finds in the archive, but when extracted it extracts the latest. In fact ZIP (and RAR IIRC) allow overwriting a file with a newer version later in the archive; probably a hold-over from the floppy-swapping and/or tape days when you needed such abilities.

      Reminds me of the chimera file exploits that use the fact that many common file formats like ZIP and PDF will ignore extraneous data, scan into the file looking for a header, etc to mak

    • That is unbelievable that they would overlook that. Thanks for the explanation.

  • by Anonymous Coward

    to people who want to use the exploit to compromise your phone. It's not helpful to Android users or to legitimate developers.

  • by __aaltlg1547 ( 2541114 ) on Monday July 08, 2013 @07:46PM (#44221091)

    Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."

    It's nice that Google's OEM and carrier parters are getting a patch but what's their mechanism for distributing the patch to the installed base of Donut, Eclair, Froyo, Gingerbread, Ice Cream Sandwich and Jelly Bean users in the field who would like their phones to not be infected with malware? And does it affect Kindles and other systems running on Android forks?

    • One method is Google Play Services. I've noticed that even on a 2.2 device, the app formerly known as Android Market installed a new application called "Google Settings" and an .apk file handler called "Verify and Install". Apparently app verification, introduced alongside Android 4.2 [thenextweb.com], is some subset of the "bouncer" that Google uses to reject applications exhibiting the most common malicious behaviors, and Google could easily update it to reject .apk files that include two files with the same name.
    • by gl4ss ( 559668 )

      a lot of the attack would be mitigated by simply having the apk downloads from the market be https.. they don't need to update android itself for that, just the play store client.

  • It seems that most Android manufacturers don't upgrade major versions for their phones (2.3 to 4.x).

    That may make sense because the newer versions may relate to features or power the older phones don't have.

    But do the manufs/Google at least offer minor upgrades (2.3.x) for security/backport purposes?

    It seems that Google offering a patch which would only go into new Samsung phones is about useless.

    • by Nemyst ( 1383049 )
      Google's distributed it to the manufacturers, Samsung was the first to implement and push it. Doesn't mean they're the only ones with the ability to do it, only that they're the only ones to have done it thus far. I'd also expect this fix to be in the stock Android distributions.

      Old devices running on 2.3 will never see updates as they're already considered long out of support. 2.3.x devices might see something due to GB still being widely used by cheaper and older devices. 3.x devices are dead and buried
    • by Skapare ( 16644 )

      Buy a new phone. You know they want you to.

    • by gl4ss ( 559668 )

      they could just distribute the patch through a new google play store client.

      anyhow, the way the attack works is laughable, like they had a perfectly brilliant idiot design the system(who didn't know shit about how zip works). bad, bad google.

  • It's kind of interesting to me how what we've seen with the rise of the app store model has largely mirrored what we've seen in the "real world" post-9/11. It hasn't quite been simultaneous, but pretty close.

    What I mean is that a lot of people love the app store model and always say how it's "safer". Especially when talking about Apple, you have a gatekeeper checking on the safety of apps, to at least some degree. They ensure what gets through won't hurt you (in theory... but, to be fair, they do pretty

This is the theory that Jack built. This is the flaw that lay in the theory that Jack built. This is the palpable verbal haze that hid the flaw that lay in...

Working...