Walking the path least trodden – hacking iOS apps at scale

This is a story of how I set out to find some bounties and how I found gold, hacking iOS apps, at scale.

One of the essentials qualities of a bug hunter is the ability to find exploitable vulnerabilities that others haven’t found.

The ability to find bugs not discovered by others is a quality that comes from – not deep technical knowledge – but rather, creativity and innovation.

So how to get an edge over others? – find the path least trodden.

How to find the path least trodden? be creative: come up with new ways to build footprint/reconnaissance on a target.

In my case, I decided to apply this concept to an area of bug bounties which usually doesn’t get as much attention as web applications: iOS apps.

I also chose iOS apps, because they are closed source, and not straight-forward to hack. I figured, that because hacking iOS apps has a price barrier to entry, as well as messy configuration would mean I would be working on targets which other researchers would be less likely to see. Therefore, it would be a path, least trodden.

So I set out on the task; found an old iPhone, went out and purchased a MacBook, used that to root the iPhone. Then in order to be able to decrypt and download in-scope bug bounty apps, I had to configure a few apps.

After some tinkering, I built an end-to-end workflow, called iGold, which enabled me to hack in-scope iOS apps at scale with little manual involvement.

I wrote the workflow in bash, and it enabled me to perform two key functions:

Use case 1 (on-demand): Whenever I see a new bounty program, I can download the iOS app onto my phone which triggers a process to automatically download, decompile the app, test API key access to database’s etc.

Use case 2 (bulk): Download hundreds of apps from various bounty platform’s at once. As they are downloaded, they are automatically decompiled and tested, en masse.

The script essentially decrypts iOS applications, downloads them, decompiles them, converts plist files, performs some class dumping, run’s strings on the binaries, and then starts grepping this data for specific targets like API keys, URL’s, tokens, and all manner of secrets using regex. The script also tests some API keys.

I compared my script process with some common tools like MobSF, and found that in some cases I was looking for things that MobSF was not searching for.

Because I was able to perform this recon at scale, I was able to discover a number of interesting things – which I’ll break into two categories.

  1. Secrets (as expected) – found a number of API keys which had not been discovered by others.
  2. Valuable recon about organisations which is otherwise hard/impossible to get.

I found point 2 to be of more value.

By way of example, I discovered an iOS app binary which contained an s3 bucket address. I then looked the address up and found it was public. I then identified a very suspicious looking file in this public bucket, but alas, the file was blocked/secured. I knew they had a number of private buckets, so I scanned the same file name against their private bucket and then I got a hit – it downloaded.

On another occasion, I found an s3 bucket address in a binary which contained a file which once downloaded and decompressed contained the administrative credentials to their entire global AWS tennancy.

Oftern less attention is given to securing assets that are harder to find – so find the path least trodden!