.svg){kind=icon}
.svg){kind=icon}
When I talk about pen testing for mobile, the first question people ask me is which vulnerabilities do I go after? When it’s a mobile target, there are lots of restrictions. For instance, many enterprises clearly mention that issues found on “rooted / jailbroken” devices won’t be accepted. However, other companies specifically require testing of rooted or jailbroken devices for complete coverage.
However, when performing a mobile app pen test that requires testing of rooted or jailbroken devices for complete coverage, I often get the same question. So to answer the question of which vulnerabilities should I submit in order to get accepted and get paid I’ve created this blog to offer my advice.
For this blog I want to share two real-life examples from my experience of pen testing 100+ mobile applications. Sharing the vulnerabilities that were accepted and provide insights on how I found them.
App #1: iOS Application Pen Test
Here are the steps that I took to test an an iOS app:
-
I decrypted the application using Clutch
-
Then dumped the classes (using class-dump) and started looking at the code. I found couple of references for AWS
-
The next step I performed was loading binary into Hopper disassembler and started taking a look at the application workflows. If you’ve never used disassembler for iOS binary, **Hopper** is awesome — and my favorite — for macOS and Linux Disassembler. I found that there were AWS calls made by mobile app and found something “arn:aws”
-
I started dumping all keywords using “strings” command and greping it with AWS/keys. Finally I found hardcoded access key and a secret key!
-
Next, I checked what was permission for those keys. I used AWS CLI and was able to list ‘ALL’ IAM users of that enterprise. Now the keys I got had lot more permissions.
-
Did I mention that I was able to launch EC2 as well? ;)
-
For Proof of concept, I launched t2 free tier ec2 instance. Now I had enough proofs to submit my bug! yay!
-
Finally I prepared a write up and submitted this vulnerability which was fixed on high priority. Can you imagine getting those AWS secret keys in wrong hands and launching hundreds of EC2 large instances over few mins? Or something worse?
App #2: iOS Application Pen Test
On another pen test, I observed that after the application was installed on the device, it also used to create database having QA account credentials. Now it’s common practice to check the local storage of the application. If I had just gone ahead and reported that the app is storing sensitive info locally, it would be ‘low’ severity / or got rejected because exploitation will require prerequisites like rooted device. So I began to explore further.
I stayed motivated and started looking for a few more things. I found references to a few other endpoints which were not listed on program. I checked further and observed that I can use QA account credentials (found during storage analysis) for new endpoints (not listed one!) and was able to fetch their all upcoming features of app for next couple of quarters.
I prepared writeup and submitted bug with all evidence. Can you imagine accessing those all upcoming features by competitors?
Similar to this, I’ve several cases where companies said ‘wow’ or got surprised. Well this is my first blog and I don’t want to make it very lengthy, so stay tuned for upcoming blogs.
Want to dive deep in iOS app pen testing? Check out this free and open source project at — http://igoatapp.com/. Explore more on this topic with an overview of the OWASP Mobile Top 10 2024.
