The Accidental Bug Discovery

Disclaimer: I am not a cybersecurity expert or some kind of ethical hacker. I am simply a techie who loves to tinker with things that I am not supposed to. This bug discovery was a random find while experimenting with something. I have already informed the developer about it. This article is purely for educational purposes only. I want to emphasize that I have no intention of defaming any individual or organization. Yes, I enjoy providing disclaimers to ensure safety.

A few days ago, while I was casually testing an iOS app (I will explain ‘why?’ later), I ‘accidentally’ discovered a bug. I won’t be disclosing the name of the app or the company since it is an established brand and I am not fond of getting sued by such companies with their heavyweight lawyers.

Now, before you jump to conclusions and label me as a weirdo or a nerd for casually testing an app, let me explain my intention. I was actually attempting to develop an iOS widget for that app which would display certain data on my lock screen. I must mention that I had no prior experience in building iOS apps, and this project marked my first attempt at creating a project with the assistance of ChatGPT.

This entire article poses a question to all the experts out there, as I’m not entirely certain if what I stumbled upon is a genuine security vulnerability or just a common practice. Perhaps I’m being more paranoid than necessary. As I mentioned earlier, my goal was to develop a widget that could display some data linked to my account on that app, which is a challenging task due to the stringent rules of iOS. Nonetheless, I decided to give it a shot. Before diving into my project, I wanted to examine the app’s network activity to analyse the API calls to see if I could find anything useful. In the process, I ‘accidentally’ performed a Man-In-The-Middle (MITM) attack.

To intercept the app’s API calls, I had two options: either use the Xcode iPhone Emulator or employ some kind of Proxy Service on my personal iPhone. I chose the latter as I didn’t feel like downloading the emulator along with Xcode. The proxy service I went with was ‘Proxyman,’ a free network debugging tool with some limitations that could be unlocked by upgrading to the premium version.

I won’t go into the specifics of setting up Proxyman here, as the app itself offers a well-guided tour that explains the process thoroughly.

API Calls

There were multiple API calls that were made as shown above. After a few failed attempts at analysing multiple APIs to find something I could use, I ‘accidentally’ (or maybe curiously) checked the Google Maps API calls and it surprised me.

API Query Params

In the Maps API call there are 4 query params that are being passed viz. origin, destination, mode and key. I was taken aback when I saw that the API key is being exposed to the user. To check if it seriously was a usable API key, I went ahead and tested it with Postman.

Clearly seems to be working

Although I did inform them about this vulnerability, I got a partially automated/template response so I am still not sure if this is a real vulnerability or done voluntarily (and if they have even noticed it). There are only 2 possibilities I can think of for which they may have done it voluntarily:

Since customers are paying for the service they are fine with exposing the API keys.The API has a rate limit at the backend.

Despite these possibilities, I still find it concerning to expose API keys to end users. It opens up the potential for misuse by individuals who may exploit the keys for personal gain (I won’t, I promise).

Personally, I am not inclined towards criticizing things or nitpicking every aspect but if I do come across a problem, I try to find a solution for it. Admittedly, I am not well-versed in mobile app development, so I had to rely on my trusted companion, Stack Overflow, to seek answers. While exploring the vast expanse of Stack Overflow, I discovered that protecting API keys from reverse engineering at the client side is a common challenge faced by many developers. After sifting through various solutions, I found out few simple solutions that may fix it.

SSL Pinning

In order to perform an MITM attack, you need a certificate proxy that would be used to redirect the API requests from the client to proxy and then to the actual server. This would track the requests made and there is no way for the app to distinguish between a fake certificate and an original certificate even if it uses HTTPS to send requests. With tools like Proxyman and Charles, you can spoof these certificates and manipulate the host device into trusting the fake certificate (pretty cool). HTTPS does provide additional security over HTTP by encrypting the headers of the request to protect from eavesdropping but all of this has a single point of failure with the help of a proxy.

Source: Beagle Security

SSL stands for Secure Sockets Layer. The client sends a request to the server, and in response, the server sends a valid SSL certificate. Once the client receives the certificate, it responds by sending back the public keys that will be used for asymmetric encryption. HTTPS utilizes SSL to encrypt data transfers.

MITM attack works by performing a double handshake with the client and server. After the legitimate server and client establish a connection, the attacker intercepts their connection and gets access to the server certificate and public keys. The attacker then presents a fraudulent certificate to the client and manipulates it into trusting that certificate. In our case, the attacker was a proxy and we forced our device into trusting the fraudulent certificate. The attacker then shares those valid public keys with the server and establishes a connection.

SSL pinning can be implemented in two ways: embedding the certificate or embedding the public keys in the bundle of the app.

Embedding the Certificate: You can extract the server’s certificate and embed into your app bundle. The network layer compares the server’s certificate with embedded certificate.Embedding the Public Key: You can extract the certificate’s public key and define into your code or place into the app bundle. The network layer compares the servers certificates’ public key with embedded one.

SSL Pinning in iOS apps can be implemented using URLSessions, a networking API provided by Apple or using Alamofire, a swift based networking library for iOS.

At first, I thought that SSL pinning is the solution to protect your app’s secret keys from MITM attacks and unauthorized eavesdropping. However, I later realized that these measures are usually applicable when the APIs are from your own server, rather than a third-party server like Google. There is a high probability that Google’s server certificates change dynamically, and it is uncertain whether the public keys associated with those certificates are affected as well which would lead to frequent deployments with latest certificates/keys. Please let me know in the comments section if SSL pinning is applicable to third-party servers.

To address this concern, one possible approach I thought of is to modify the architecture of your application. Instead of allowing the app to directly make API calls to third-party servers like Google, you can decouple the third-party API calls from the client-side and let your own server handle the API requests from the client. By doing so, you gain more control over the communication and can implement SSL pinning on your server.

Potential Solution

A slightly complex solution, but it offers significantly improved security and can be implemented if your app already makes API calls to your server. The developers may have already considered this solution but chose not to implement it due to concerns about potential impact on response time and increased latency. If any of you reading this article are software architects, please let me know in the comments section if you have alternative solutions that address this problem more effectively.

Restricting the API usage

This is the most straightforward security method that can be implemented, but it may not be effective in cases where the application is used to provide connected services for vehicles, as consistent API access is required. I discovered that Google advises restricting API keys to specific projects using SDKs and Project IDs. However, at an enterprise level where each user may have their own API keys, I struggle to understand how this can be implemented effectively.

While writing this article, my API key expired, and I haven’t received a response from the developer regarding whether the issue has been resolved or if the API key resets daily (I am too lazy to set up a proxy and find out again). If resetting the secret keys daily is the security mechanism they have implemented, it can be considered a workaround rather than an efficient solution, in my opinion.

As I mentioned earlier, this article is not meant to defame anyone or to showcase my cybersecurity skills (after all, it was just an accidental MITM attack). The reason I decided to write this article is because I found the entire situation quite amusing, especially considering it was a complete accident. My aim in writing this article is to spark a discussion with experts in this field and to use it as a learning opportunity for myself.

Being a CS student, I did learn about MITM attacks, network protocols, and security mechanisms in my System Security class. However, I must admit that I wasn’t someone who could understand these concepts just by reading the theory. It didn’t really interest me back then. But this accidental bug discovery of mine made me delve deeper into these topics and revise them with the help of a real-life scenario. Until now, I wasn’t clear about the difference between MITM attacks and simple eavesdropping. While exploring solutions, I came to know that eavesdropping usually applies to unencrypted HTTP requests, while MITM attacks specifically target encrypted HTTPS requests. With that said, I hope the developers have fixed this vulnerability as I won’t be taking the efforts to perform another attack as it won’t be ‘accidental’ this time ;)

If you found this article interesting you could buy me a coffee and please consider following 👉 me and clapping 👏 for it. You can also share your thoughts on better and more effective security mechanisms for mobile apps, and please excuse my limited knowledge in this subject matter in case I made any mistakes. Thank you for reading! 🚀