How to sniff HTTPS traffic on an iOS device

  • Tutorial


Hi, my name is Andrei Batutin, I am a Senior iOS Developer in DataArt, and today we will sniff the HTTPS traffic of your iPhone.

FoodSniffer and what it is eaten with


Take, for example, the very simple FoodSniffer iOS application . Depending on the time of day, it shows the user what to eat.



The application receives from the server JSON type:

[
  {
    "name" : "soup",
    "consumePeriod" : "morning"
  },
…
]

The server in this case is Dropbox, and JSON can be viewed here .

Problem number 1


A bug has come that instead of two items on the list of permitted morning meals, the application only shows one.

One way to check what went wrong is to see the JSON that the server returns to you.

How to sniff traffic?


Suppose your MacOS computer and iOS device are on the same local network, which looks like this:



Traffic goes from the iOS device through the router to the server, regardless of the computer traffic.

To read the traffic of an iOS device, we need to make it go through our Mac. Something like this:



In addition, we need an HTTP / S proxy server , with which we would look at / modify the traffic going through the iOS device.

Another very important task is to be able to sniff HTTPS traffic. The hitch is that the HTTPS protocol was created so that, apart from the client and the server, no one could read what is being transmitted in HTTPS requests. Therefore, the HTTPS proxy should also provide an SSL certificate., which is needed to work with HTTPS traffic.

In other words, we need to implement M an-in-the-Middle- attack on our own network.



Charles Web Debugging Proxy Application


As you can see, sniffing HTTPS traffic is a multi-step task, so in order to simplify my life as much as possible, I use Charles Proxy .

Let's start with the cons:

  • It is paid, but the only restriction that is in the trial version is that Charles does not work longer than 30 minutes, then he must be restarted. There is still a five-second delay on startup. It is annoying, but you can live.
  • If you need a genuine hacker tool to work on a remote server 24/7, and with a normal CLI, Charles is not for you.
  • If you are working on Windows, you better get Fiddler , it’s also free.
  • If you need a proxy server for a large number of devices (more than two or three), Charles is not for you.
  • If you need to work with TCP / IP-packets in its pure form, take Wireshark .

Now the pros:

  • User-friendly UI. Charles does not require any special knowledge to install, to configure, or to use. Normal MacOs window application.
  • HTTPS for iOS - Charles has a set of tools that make HTTPS sniffing from your iOS device as easy to set up.
  • Functionality - Charles can sniff, modify traffic passing through it, simulate slow Internet, collect statistics, import / export traffic in various formats.
  • Available for Windows and Linux.

For me, this is the best solution in terms of functionality and ease of use when working with iOS devices.

Setup Charles and iOS devices


Next will be described the procedure for initial setup of an iOS device for working with Charles Proxy.

1. Run Charles on the computer:



2. Install the Charles Root Certificate on the iOS device:

In the menu, select Help -> SSL Proxing -> Install Charles Root Certificate for Mobile Browser.



The following window will appear:



3. In the network settings of the iOS device, specify the IP and port of Charles Proxy:



Depending on the architecture of your network, the IP address on which Charles is running may differ.

4. Open the browser on the iOS device and follow the link - http://chls.pro/ssl .



5. Install the Charles SSL certificate on the device:



6. Specify in the device settings that we completely trust this certificate:



The sixth stage is needed for devices with iOS 10 and higher.

At stages 5–6, we installed a SSL certificate on the Charles device and indicated that we trust it. That is, now all HTTPS traffic signed by this certificate will not be blocked by ATS .

How to watch iOS device traffic


Open the FoodSniffer app . If the proxy setting was done correctly, then you should see the following screen:



In Charles Proxy, open the menu Tools -> No Caching.

And completely turn off caching on the proxy server.



The application implements Pull-to-refresh, after updating the list of products in Charles you should see https://www.dropbox.com in the list on the left side. Right-click on it and select Enable SSL Proxing .



After that, once again update the list of products in the application. Now you should see something like this:



Now we can freely read the HTTPS traffic that comes from the Dropbox app for our JSON.

But that is not all!

Dropbox does not give JSON from dropbox.com directly. Instead, it returns a 302 response and redirects to another host, from which data is loaded.

You can find it by viewing the Raw Response of the following query:



In this case, it is
uc9c29db95802af8490afc3afda9.dl.dropboxusercontent.com .

You will most likely have a slightly different host.

Then enable SSL Proxing: Enabled for it .

Update FoodSniffer again.

And now we can finally see the real JSON, which shows the application!



We see that we have only one type of food in the evening - whiskey, we write about this to our team leader and go to drink coffee, the problem is not on our side.

* The project uses already corrected JSON, with two types of food for the evening: beer and whiskey.
* If you do not see the host http://uc9c29db95802af8490afc3afda9.dl.dropboxusercontent.com or similar to it in the list in the left part of the window, try updating the list of products in the application several times.

Problem number 2, or How to change the HTTPS traffic iOS device


The backend team fixed the menu for the evening, and now JSON is formed correctly. But what if it's morning now, and you don't want to wait until the evening to check the fix?

One option is to use Charles to change the JSON that comes back from Dropbox.

In this case, we need to change consumePeriod from evening to morning .

To do this, select Tools -> Rewrite from the menu .

In the Rewrite Settings window that appears, add a new category for overwriting - dropbox .



Add a host by specifying the https port in the Edit Location menu:



After that, add rewriting rules toRewrite Rule menu as follows:



That is, now in every Body Responsa from our server the word evening will be replaced by the word morning .

If necessary, we can change any part of the HTTP request / response, plus use a regex expression to replace the text.

Now, having updated the list, we should see four types of products:



Conclusion


Charles is fairly simple, shareware, has a rich HTTPS proxy functionality. From my point of view, it works best when working with MacOS and iOS devices.

This is not the only way to sniff traffic. Fiddler is also widely used for HTTP / S-traffic . If you need to go deeper into the TCP / IP stack, there is Wireshark .

In addition, there is a problem certificate pinning . If it is implemented in your application, you need to either add the Charles SSL certificate to the list of allowed certificates, or use tools such as Frida to disable certificate pinning already at the level of the application itself. I hope to tell you more about this in the next article.

I would be glad if you share your experience in monitoring traffic, including HTTP / S, tips and life hacking.

Note. Use this technique only for your applications, please. Be white hare hackers!

Note 2. Recently, the story came out in Ukrainian , but in Russian I publish it for the first time.

Also popular now: