APKs are downloaded from Google Play on the device, how can we extract them? Some solutions: 1. adb backup -apk com.mypackage (Works on Android 4.0 and newer) 2. Use a backup application (ASTRO File manager, Titanium Backup…) 3. adb shell , cd /data/app/, ﬁnd your apk, then you can pull it with adb pull /data/app/ mypackage.apk (requires a adb root shell on the device)
provide us a disassembled representation of the Dalvik bytecode, so sort “low level”, with registers, but very understandable because of bytecode metadata. Very useful to disable tampering protections, the code can be modiﬁed and the application can be recompiled and resigned. 7
jad …) dex2jar will convert the .dex ﬁle to a .jar containing Java code We can then use the freely available Java decompilers and obtain back a Java representation of the code. Very readable if no obfuscation is in place. 9
has been modiﬁed in any way or if the signature is changed. • It can be done with the PackageManager class, retrieving the Signature array of your app and comparing with known values. If an attacker resigned the app, the signing key will be different. • Do the checks in multiple code points and use obfuscation, to avoid that it can be easily bypassed. • If your app ships only through Google Play, check with the APIs that it has been installed from Google Play and not from Unknown Sources. • If something is wrong, close the application without leaking informations where the protection code is, to make attacker’s life harder.
It can be done with few lines in Proguard and Dexguard, they remove all the calls to Log.d, Log.e etc in the build process • It’s very easy for third party malware or an attacker to access the Logs on Android. 20
data in the shared storage, almost any application can read it. (In 4.4 a small protection at permission level was added android.permission.READ_EXTERNAL _STORAGE, usually users does not check permissions too much anyway… Don’t rely on this.) 21 My Personal Data stored in a Evernote Note, publicly readable by anyone. CASE STUDY
With root access they can be modiﬁed, avoid store sensitive data at all if possible • With a backup, they can be retrieved from the device usually • The private folder can be found on the device at path /data/data/yourpackage 22 That’s right.. It’s my User and my 36 character Password in PLAIN TEXT CASE STUDY
| grep easy package:com.handyapps.easymoney shell@hammerhead:/ $ exit $ adb backup -apk com.handyapps.easymoney unpack the backup with https://github.com/nelenkov/android-backup-extractor PASSCODE IN PLAIN TEXT RETRIEVED. FAIL! CASE STUDY
in transit! • Don’t transmit sensitive information without SSL/TLS • Implement if possibile Certiﬁcate Pinning, in this way your communications will be more resistant to MITM attacks, for example if a malicious certiﬁcate is pushed into the device, or if an attacker can impersonate your web service with a trusted certiﬁcate. 26
ﬂag android:debuggable=true in production, an attacker can attach with a debugger and execute arbitrary code in your app. • Double check your exported components. Export a component to other processes only if it’s strictly necessary and at least protect the component with a permission. Android has some permissive defaults, some components are exported even if they are not declared exported=true, check the documentation. • If you export a content provider or another component that grants access to data and accepts untrusted output, be careful on the input to avoid sql injections and path traversal attacks.
Security ! Now patched It was possible to bypass the activation and use for free some functionalities. ! $ am start -a android.intent.action.MAIN -n com.wsandroid.suite/ com.mcafee.main.MfeMain ! Credits: Sebastián Guerrero, @0xroot CASE STUDY
applications and the system without touching any APK and we can enable/disable plugins with ease. ! We must have a rooted phone and install a framework that will modify some low level components of the Android OS, to make our life easier.
the wallet. It suppress it, so the Wallet never get the Intent and never go to timeout its session. ! What we learned: The system often is not trusted when doing IPC with Intents, and in any case we must protect the exposed parts of our application, auditing and remediating. CASE STUDY
forced for technical limitation in the sharing process between the PC and the device. • Without root permissions, the user can only write in the shared folder, or the application can use third party services, such ﬁle sharing API by Dropbox, to share the wallet ﬁle. 55 CASE STUDY
an attacker can easily understand the logic of the application and the weak points. • First weak spot: LOGS, the application disabled in productions the logging of the user credentials and other internal information to the Logcat, but the logs are only disabled, the code that logs at the critical points (even the user password) it’s in there. 56 CASE STUDY