While debugging an upcoming app of mine, I accidentally got a closer glimpse into Uber’s iOS app internals. I was surprised by what I found and how easy it was to accomplish my findings.
Method of Discovery
I began by firing up Charles, a tool that allows you to monitor and analyze traffic between a client and the internet. Because my lifeblood is building client-server applications, I am a religious user of Charles to aid me in my daily development tasks. I usually route all traffic between the internet and my iOS device through my machine by setting it up as a proxy. While inspecting and debugging the network traffic of my app, I needed a ride so I fired up the latest version of the Uber app and suddenly began receiving requests/responses their app was making/receiving, so I decided to take a closer look.
Uber utilizes SSL in their requests, so if inspected in their raw format, the request would look like a bunch of gibberish, but with Charles, you are able to self sign requests, effectively allowing you to view the requests in plain text. With the requests flowing in, I noticed a request made every 5 seconds.
One particular request of interest is used by Uber to receive and communicate rider location, driver availability, application configurations settings and more to devices. Upon inspecting the response, I discovered the key
isAdmin, which was set to
false for my particular account. Charles allows you to define rewrite rules, so I rewrote the response changing, the value for
true, curious to see the effects it would have on the app. I perused through the app with the new value applied… lo and behold, I stumbled upon the Employee Settings screen from the About screen:
As you’ve probably noticed, Uber’s app is extremely dynamic. Their client’s architecture allows them to customize the app’s UI to certain geographical areas, riders, and even individual devices, allowing them to do things such as deliver kittens, deliver food, offer rides on helicopters, and of course, change prices…all without re-submitting the binary for approval to the app store. This is common practice for many client-server applications, a neat way to target certain features/functionality to a limited subset of users without the burden/time constraints of submitting an app for review.
As you can see, your traffic is not 100% safe and anyone can inspect your requests and responses (even with HTTPS), so it’s a good idea to always utilize defensive programming. A malicious third party could use this flaw to exploit the app in ways unforeseen. Even though Uber utilized HTTPS, there are still inherent flaws with the protocol that allows one to access certain screens meant for employees only. By assigning the UI display logic to the client, they are allowing for discoveries such as the one exposed in this post. Take a deeper look at the apps you use with Charles, you may be surprised at what you find.
[cover photo PSD courtesy GraphicsFuel]