• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[MOD][XPOSED][2.3.3+]FakeID vulnerability fix 1.1 [2014-08-10]

Search This thread

Tungstwenty

Senior Member
Nov 1, 2011
1,828
4,512
Can this create any issue with genuine apps?
I don't believe so.
The validation implemented by this fix is the same as the one applied on the official AOSP code, and it is taken into account during installation.
I'm not 100% certain, but I'm also not 100% certain if the official fixed ROMs won't cause issues either.

Also, I don't see a reason for a genuine app to include forged certificates claiming to be signed by others when that claim is false, but I guess it can't be completely ruled out.
 
  • Like
Reactions: AndroTech

0355

Senior Member
Jul 15, 2011
708
128
Road Town - Tortola
Is it possible that this module breaks a search based app? I.E. blocking its access to the Web? I have the app version of a site that hosts used items listing and auctions. If I enable this fix the app seems to have no access to Internet. Disabling the fix app works as intended.
LG G2 stock 4.4.2 rooted.

Edit
A couple of reboot seem to have fixed the thing.

Sent from my LG-D802 with Tapatalk 4
 
Last edited:

Tungstwenty

Senior Member
Nov 1, 2011
1,828
4,512
Please note, this apk doesn't fix for the installed apk. So if you have installed a apk with the fake id, this module cannot prevent you from the hacking. For more tech information, please visit here: https://github.com/Tungstwenty/FakeIDFix/issues/1
I am aware of this behavior, yes.

Please check this post: http://forum.xda-developers.com/xposed/modules/mod-fakeid-vulnerability-fix-t2833854/post54629369
It is also a PoC with multiple signatures, and it will scan the entire system for packages with multiple signatures, stating whether each certificate has signed the previous one.
But it doesn't take the Subject / Issuer into account, and it appears that there are some situations where multiple signers are present, and they don't form a chain (nor do they claim to).
Check this example: http://forum.xda-developers.com/showpost.php?p=54630063&postcount=46 and also this one http://forum.xda-developers.com/showpost.php?p=54632966&postcount=53 where AdBlockAddon is issued with 2 independent signers.

About your patch: in the latest version of my mod, I'm only changing the behavior to include the check if it's running on the system process. Since Google didn't change the behavior in JarTools to always enforce the check, I'm guessing that it might cause compatibility issues to always do it.
(I also posted this as a reply on Github)
And I don't it's a good idea to hack the result of the bluebox security scanner...
On one hand yes, it can be deceiving, but on the other hand it might also be confusing to see the scanner reporting the bug as present.
If one installs the mod, he's doing something similar to applying the AOSP commit to his rom which would apparently remove the vulnerability, and Bluebox would detect the 3 arguments on the method and report the system as safe.

Are you aware of any other AOSP commits that actually take advantage of the additional API of JarTools and enforce the check in some places?
 

DADi590

Senior Member
Jan 4, 2017
61
10
Well, I'll try xD. Sorry for coming here after so long haha. Would you still remember if to check if one of the certificates returned by GET_SIGNATURES is valid, I need to code my own algorithm to check the chain of trust of all the app certificates?
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 110
    There is a new security vulnerability in town, this time labeled "Fake ID" (Google bug 13678484).

    The bug allows malicious apps to pretend to be signed by trusted providers and be loaded as extensions in several contexts such as NFC access, browser plugins and others.
    An excellent explanation can be found on this article by Jeff Forristal from Bluebox.


    Checking if you're vulnerable
    It appears to currently affect all devices, to a lesser or greater extent depending on which extensions each manufacturer included in their ROMs.
    You can use Bluebox Security Scanner to detect if your system is vulnerable.


    Installing the fix
    Fetch the package from the Xposed repository: http://repo.xposed.info/module/tungstwenty.xposed.fakeidfix (it is also available on Google play)
    Install as usual and make sure that you enable the module on the Xposed Installer and reboot.

    There are no configuration options. There is a simple information screen which can be accessed by tapping the entry on the Installer's module list (you won't see an icon for this on your launcher).


    Fix details
    For the tech savvy, here's an explanation of what this patch does.
    The JarTools class has an API for grabbing all signature certificatates present on an APK / jar. That API doesn't however check if *all* certificates form a valid chain, where each certificate is properly signed by the next one and so on, and not additional certificates are present that don't belong to that chain. It is therefore possible to insert additional certificates in that list, and *certain* callers of that API might be fooled if they assume that just because a certificate is on that list, the party to which it belongs did in fact sign or trust that code.
    This behavior could not be blindly changed to enforce checking the chain validity, as apparently it would create compatibility issues on some legitimate callers of that API that rely on that behavior, and Google opted (see this AOSP commit) to include an option to both of the behaviors, keeping the old "insecure" one for code that doesn't bother specifying what it wants, i.e. all existing code.
    I haven't spotted any other commits that rely on this new behavior, but from my analysis it seems that the identified vulnerability vectors all go through the getPackageInfo(..., GET_SIGNATURES) PM API.
    Therefore, so as not to cause the compatibility issues that Google seems to be cautious about, I have chosen to modify the behavior of JarTools.createChain() only when it's being used by the PM service. This will stop the possibility of using malicious apps impersonating NFC extensions (e.g. Google Wallet), Adobe web plugins, etc.
    Additionally, and since Bluebox Security Scanner does a more direct check (in order not to require installing a malicious / proof-of-concept APK in order to then ask the PM service about its signatures), I also included code specific to this scanner so that it reports the bug as not present.


    Source code
    Available on Github



    If you appreciated this fix, consider donating with Paypal.


    Thanks!
    11
    Version history

    1.1 (2014-08-10)
    • Support for Xposed Framework 2.2 (bridge v30) and above
    • Support for Gingerbread 2.3.3 and above
    • Reduced potential for compatibility issues by patching only the system services but not other apps that might be using a private API

    1.0 (2014-07-31)
    • Initial version
    9
    Any plans to release a Gingerbread version? I can confirm it works on Gingerbread as I lowered the minimum sdk on your apk and it installed fine. Bluebox Scanner shows FakeID patched.

    That's no evidence, as the module changes bluebox

    It only changes bluebox as long as the hooks on the system code that fetches the certificates without the chain validation were already hooked.

    Anyway, this detection based on the presence or not of the mentioned AOSP commit is not enough.
    It only provides the *alternate* API for strict validation; for the fix to be enforced it is still required that the appropriate places do use that stricter mode.

    I'm trying to setup a proof-of-concept APK including extra certificates to truly check if a system is properly filtering them out or not, regardless of the presence of this AOSP patch. I'll keep you posted.
    6
    Version 1.1 available

    An update is now available on the Xposed repo and also rolling out on Google Play.

    Check the 2nd post for the changelog - lower required version Xposed; GB support.