This presentation contains android and iOS pentesting resources and methods to test the applications.

1. root@:~#Hacking Mobile Apps
@kunwaratulhax0r

2. $ /USR/BIN/WHOAMI
Hi everyone, my name is Kunwar Atul ☺
• Yet another Appsec and DevSecOps Guy
• Break – Fix – Repeat
• Synack Red Team Member
• OWASP MASVS Hindi and DevSecOps University
Contributor
• Social media- kunwaratulhax0r

3. Some Statistics
• 25% of mobile apps include at least one high risk security flaw.
• 35% of mobile communications are encrypted.
• Mobile malware incidents have doubled.
• In the year 2019, there were approximately 2.6 million android apps
and 2.2 million of iOS apps available for users.

4. Types of Mobile Apps
Native Apps are created for
one specific platform or
operating system.
Technology Used: Native
apps are coded using a
variety of programming
languages. Some examples
include: Java, Kotlin, Python,
Swift, Objective-C, C++, and
React.
Web apps are responsive
versions of websites that can
work on any mobile device or
OS because they’re delivered
using a mobile browser.
Technology Used: Web apps
are designed using HTML5,
CSS, JavaScript, Ruby, and
similar programming
languages used for web
work.
Hybrid apps are
combinations of both native
and web apps, but wrapped
within a native app, giving it
the ability to have its own
icon or be downloaded from
an app store.
Technology Used: Hybrid
apps use a mixture of web
technologies and native APIs.
They’re developed using:
Ionic, Objective C, Swift,
HTML5, and others.

5. Mobile Security Threat Types
Application Based Threats:
• Malware
• Spyware
• Privacy Threats
• Vulnerable Applications
Web Based Threats:
• Phishing Scams
• Drive – By – Downloads
• Browser exploits/attacks
Physical Threats:
• Lost of Stolen Devices
Network Threats:
• Network Exploits
• Wi-Fi Sniffing

6. Attack Surface on Mobile Application

7. Why Does It Matter

8. Many Vulnerabilities != A Lot Of Malwares

9. Mobile Threat Model
Spoofing:
• Improper Session
Handling
• Social Engineering
• Malicious QR Codes
• Untrusted NFC tags or
peers
• Malicious Application
Tampering:
• Modifying Local Data
• Carrier Network Breach
• Insecure Wi-Fi Network
Repudiation:
• Missing Device
• Toll Fraud
• Malware
• Client-Side Injection

10. Mobile Threat Model
Information Disclosure:
• Malware
• Lost Device
• Reverse Engineering
• Backend Breach
Denial of Service:
• Crashing Apps
• Push Notifications
Flooding
• Excessive API Usage
• DDOS
Elevation of Privilege:
• Sandbox Escape
• Flawed Authentication
• Weak Authorization
• Compromised
Credentials
• Make Unauthorized
Purchases
• Push Apps Remotely
• Compromised Device

11. OWASP Mobile Top 10
Insecure Data Storage
Insecure Communication
Insecure Authentication
Insufficient Cryptography
Insecure Authorization
Client Code Quality
Improper Platform Usage
Code Tampering
Reverse Engineering
Extraneous Functionality

12. Android Architecture

13. Inside the apk
MYAPP.APK
ANDROIDMANIFEST.XML
META-INF/
CLASSES.DEX
LIB/
RES/
RESOURCES.ARSC/

14. iOS Architecture

15. Inside the ipa

16. Keychain
• Used by Apple to store passwords, certificates, tokens etc.
• SQLite Database
• Can be arbitrarily read on a jailbroken device using keychain-dumper
(https://github.com/ptoomey3/Keychain-Dumper).

17. Application Sandbox
• Third-party application runs as `mobile` user.
• Few applications have permission to run as `root`.
• Application can access its own files and data only.

18. How to Do a Lab Setup??

19. General Tools For Android Pentesting
• A Rooted Android Device/Emulator And
ADB Tools
• AVD, Gennymotion, NOX…
• ADB Tools
• A Web Proxy Tool
• CHARLES Proxy, Burp Suite
• Decompiling Tools
• APK TOOL
• DEX2JAR
• JD GUI
• MOBSF

20. Methodology
• Intercept the traffic from application to its server
• Test Server-Side Access Controls
• Privilege Escalation by manipulating Parameters
• Authentication Flaws
• Decompile the Android/iOS application
• Identify flaws in the native code
• Bypass security controls like SSL Pinning/Jailbreak/Root Detection
• Check local storage for sensitive information leakage
• In application directories
• Local Databases
• Logs

21. SSL Pinning
SSL Pinning is a technique that we use in the client side
to avoid man-in-the-middle attack by validating the
server certificates again even after SSL handshaking.
The developers embed (or pin) a list of trustful
certificates to the client application during development
and use them to compare against the server certificates
during runtime.
If there is a mismatch between the server and the local
copy of certificates, the connection will simply be
disrupted, and no further user data will be even sent to
that server.
Image:https://dzone.com/refcardz/securing-mobile-applications-with-cert-pinning?chapter=1

22. SSL Pinning Bypass Android
• Use Xposed + SSLUnpinning for bypassing the certificate, but if the super tricky SSL Pinning is implemented
then you can simply decompile the apk via apktool and change protocol from https to http, compile back
and sign, create a rule in Charles that replaces the protocol from https to http.
• Modifying and repackaging an app
• If you don’t have root or don’t want to modify the system trusted certificates, you can install the Burp
CA as a user cert and then modify the specific APK you want to MitM.
• Starting with Nougat, apps will ignore user-installed certificates by default. This is evident by looking at
logcat output when launching the app:

23. SSL Pinning Bypass Android
• Without a network security config, the app will only trust system CAs and will not honor the user installed
Burp certificate.
• To get around this, it involves:
• Disassembling the APK
• Adding a new XML resource to define a network security profile
• Modifying AndroidManifest.xml
• Repackaging and self-signing the APK
• Next, add a new network security config by creating
the file network_security_config.xml in the res/xml directory:
<network-security-config>
<base-config>
<trust-anchors>
<!-- Trust preinstalled CAs -->
<certificates src="system" />
<!-- Additionally trust user added
CAs -->
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>

24. General Tools For iOS Pentesting
• A Jailbroken Device
• Pangu
• Electra etc.
• A WEB PROXY TOOL
• CHARLES PROXY, BURPSUITE
• RE TOOLS
• Otool
• Clutch
• Class-dump
• IDA Pro
• Runtime Analysis
• Cycript
• iNalyzer
• Keychaindumper
• Snoopt-it
• Bypassing Jailbreak
Detection/SSL Pinning
• SSL Kill Switch 2
• iOS TrustMe
• Xcon
• Frida
• Other Tools
• PListEditor
• iTunes
• iMazing
• iExplorer

25. Usual Test Approach
• Obtain IPA file
• Bypass Jailbreak detection (if present)
• Bypass Certificate pinning (if present)
• Inspect HTTPS traffic
• Abuse application logic by runtime manipulation
• Check for local data storage (Cache, binary cookies, plists, databases...)
• Check for client specific bugs (SQLi, XSS)
• Other checks like logging to ASL with NSLog, application screenshots, no app
backgrounding)

26. Local Storage Analysis - Objection
Objection is a runtime mobile exploration toolkit, powered by Frida, built to help you
assess the security posture of your mobile applications, without needing a jailbreak.
• Python based
• Can be installed by using pip3
• Supports both iOS and Android.
• Inspect and interact with container file systems.
• Bypass SSL pinning.
• Dump keychains.
• Perform memory related tasks, such as dumping & patching.
• Explore and manipulate objects on the heap.
• For more details - https://github.com/sensepost/objection

27. Touch ID/Face ID
• Fingerprint/facial data is stored in the Secure Enclave which is part of the iOS device.
• The provided data is sent to the Secure Enclave and compared with the stored data
to authenticate the user.
@IBAction func startVerification(_ sender: Any) {
let myContext = LAContext()
let myLocalizedReasonString = "Verifying...."
var authError: NSError?
if myContext.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error:
&authError) {
myContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics,
localizedReason: myLocalizedReasonString) { (success, evaluateError) in
DispatchQueue.main.async {
if success {
self.verificationStatusLabel.text = "✅ Verification successful"
} else {
self.verificationStatusLabel.text = "❌ Verification failed"
}
}
}
}
}
Note that the application’s (SecuBank) logic was implemented in Swift:

28. Easy Way To
Bypass Touch
ID/Face ID

29. Bypassing Touch ID/Face ID
• $frida -U -l bypass.js -f biz.securing.SecuBank --no-pause
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value) {
console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}
https://medium.com/securing/bypassing-your-apps-biometric-checks-on-
ios-c2555c81a2dc

30. How To Do It In Right Way?
• Do not just use LAC Framework (LAContext), use it with Keychains.
• The app stores either a secret authentication token or another piece of secret data identifying the
user in the keychain. In order to authenticate to a remote service, the user must unlock the keychain
using their passphrase or fingerprint to obtain the secret data.
• A valid set of biometrics must be presented before the key is released from the Secure Enclave to
decrypt the keychain entry itself.
• See more - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-Local-
Authentication.md#using-keychain-services-for-local-authentication

31. Making Things Harder
• Obfuscation
• Root/Jailbreak Detection
• Anti Tampering
• Detection of Dynamic Instrumentation such as Frida.
• ………… Many more

32. Detection of Frida
• Checking for open TCP ports, by default frida-server process binds to port 27042.
• App Signatures
• Scanning Process Memory e.g. - the string "LIBFRIDA" present in all versions of frida-gadget and frida-
agent.
• See More - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-
Resiliency-Against-Reverse-Engineering.md#detection-methods

33. Where There is a
Detection, There
is a Bypass
•
•

34. References
• https://github.com/OWASP/owasp-mstg
• https://youtu.be/wyIx0D-M2S8
• https://youtu.be/m2h3sK7s2eQ
• https://youtu.be/8Yd1myx6BG0
• https://blog.intigriti.com/2019/03/26/bug-bytes-11-insecure-deeplinks-new-xs-techniques-and-int0x33-s-
365daysofpwn/
• https://hackerone.com/reports/401793
• https://www.nowsecure.com/blog/2019/04/05/how-to-guard-against-mobile-app-deep-link-abuse/
• https://dzone.com/articles/how-to-guard-against-mobile-app-deep-link-abuse
• https://www.tooboat.com/?p=1116
• https:// hackerone.com/reports/583987
• https://hackerone.com/reports/805073
• https:// hackerone.com/reports/401793
• https://blog.securitybreached.org/2020/02/04/exploiting-insecure-firebase-database-bugbounty/
• https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/
• https://servicenger.com/blog/mobile/android-privilege-escalation-techniques/
• http://nestedif.com/android-security/identifying-hard-coded-sensitive-values-native-library-files-12-diva-solution/
• https://manifestsecurity.com/android-application-security-part-21/
• https://blog.nviso.eu/2020/06/12/intercepting-flutter-traffic-on-ios/

35. At The End
Reverse Engineer
Will Always Win
Ping me for any question - @kunwaratulhax0r