Sunday, June 26, 2016

Android signature verification

Leave a Comment

I have got lot of doubts to be cleared in the case of Android signature verification and its vulnerability.

Once we generate apk for an application we can unpack the apk and edit resource files using apktool. As we repack the edited apk back it loses its signature. I can resign the unsigned apk using the jarsigner with my own private key that i used while generating the apk. I found an application named zipsigner in playstore which can be used to sign such kind of unsigned apk.

So when this zipsigner signs the unsigned apk, whether the apk is signed with my same private key or with a different key? Because my META-INF folder still holds the XXX.SF and XXX.RSA files which holds the information of my private key. If it is with my same private key then the new apk will be an upgrade for my application or if it is a different key i will be having two different applications with same name.

From the above situations there are possibilities that malware could be included in my apk while repacking. There seems to be a loophole in Android's signature verification mechanism where the message digest of the files inside the META-INF folder are not included in the MANIFEST.MF as well as in the XXX.SF file. This creates a possibility for anyone to include malware codes inside these folders, repack the apk and resign it with the zipsigner application.

I was searching for a solution where i can prevent files being added into the META-INF folder and i found one from the below blog. But I'm unable to get the point of the solution. This looks like more of a research topic so there is not much information available in the internet. Can someone try and figure out the solution specified in the blog. The blog link is specified below the question.

http://blog.trustlook.com/2015/09/09/android-signature-verification-vulnerability-and-exploitation/

1 Answers

Answers 1

  1. Private key is never part of a distributed APK, unless I misunderstood your question. Someone else signing on your behalf is not possible unless your own system is hacked.

  2. The shared link (blog.trustlook.com) talks about Android skipping checking of files with .sf (and files with related extensions) extensions. So a malware could cloak itself in a file with one of these extensions. The fix mentioned there is an Android "system firmware" fix, not something that can be done at application level. This means, an OEM (Google itself, or Samsung/other) has to release an updated firmware to fix this. Check the latest updates, it might have been fixed already.

  3. In my opinion, even if an user sideloads APK's, this is more of a nuisance than a real attack/threat. Refer to the Blackhat paper below for further details - https://www.blackhat.com/docs/ldn-15/materials/london-15-Xiao-What-Can-You-Do-To-An-APK-Without-Its-Private-Key-wp.pdf

You should also read this for potential ways of tamper proofing APK - https://www.airpair.com/android/posts/adding-tampering-detection-to-your-android-app

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment