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!

Bypassing 403

A few weeks ago I came across this cool “accidental” exploit vector which was documented about 8 years ago by IRCmaxwell and describes a way to trick servers (behind a reverse proxy or load balancer) into thinking a HTTP request which is ordinarily unauthorised, is actually authorised.

I read the blog post while doing some research into the X-Forwarded-For http request header and immediately identified this “accidental exploit” as a really cool use-case for applying to bug bounty targets.

To explain this exploit we need to first understand the purpose of the X-Forwarded-For request header.

The X-Forwarded-For (XFF) header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer. When traffic is intercepted between clients and servers, server access logs contain the IP address of the proxy or load balancer only. To see the original IP address of the client, the X-Forwarded-For request header is used.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

This header is used and implemented in a variety of ways and because of this, it can also be exploited in a variety of ways. Researchers often use this header to inject SQL payloads, perform proxy enumeration, client IP spoofing, SSRF and many other interesting use-cases which I’ll cover later.

However the use-case that really got my attention was a variation of IP spoofing which causes the target web server to reveal information that it shouldn’t. I like to find vulnerabilities that most scanners aren’t configured to find and this I think is another one of these cases.

So IRCMaxwell experienced a situation where he unintentionally configured all of his outgoing http requests to include the X-Forwarded-For header configured with an ip address of 127.0.0.1 (the local host) – you can read his blog to find out how and why.

However this resulted in a situation where he discovered that StackOverflow was revealing parts of an administrative console to him that should not have been available for public viewing or access.

What was happening is that once the StackOverflow server recieved this request, it interpreted the “X-Forwarded-For: 127.0.0.1” to mean that webserver itself had initated the request, and that by implication, the requestor was authorised to see all the content available at that endpoint. IRCMaxwell was effectively masquarading as the webserver itself as far as the webserver was concerned.

I thought this was a pretty cool vulnerablity and so thought about how I could apply this to bug bounty targets.

So I wrote a tool which sends numerous requests to a target address with different variations of the XFF header localhost addressing to accommodate for cases where a WAF was blocking requests based on localhost signatures.

The tool uses heusristics to learn variations in the http response that could be indicative of additional sensitive information that is being disclosed.

As I developed this tool and scanned across hundreds of bug bounty targets I began to discover some interesting nuances. Web applications would handle and respond to XFF input very differently, resulting in some unexpected bug bounty leads.

However, the biggest win came early in the scanning when the tool discovered an admin console on a subdomain that is blocked to the public (response code 403), until you sent it a http request with an XFF header set to 127.0.0.1:80 at which point, the admin console became accessible.

After writing up the report – demonstrating the impact – it occurred to me that the same issue might occur on other subdomains of the parent domains.

After some searching I realised that not one subdomain, but two, no wait… over 800 subdomains for this particular organisation were impacted by the same issue. Each of these subdomains contained web applications, APIs or other services which were normally blocked to public access, but were bypassable using this technique!