Intercepting data traffic via iPhone

Intercepting data traffic via iPhone

By Jordan Marcus Bonagura

Introduction

This article aims to demonstrate in a simplified way different approach for capturing and intercepting network traffic data originating from an iPhone device.

Obviously, the iPhone is not the only device subject to these approaches, and the strategies presented here are not the only ones capable of performing such intercepts.

The simplest way to get this data is to use a proxy server. In the first part of this article, we will adopt BURP software to exemplify this operation. After collecting the data, we will analyze the packages of a given application and its connection to the WEB services.

However, if the objective is a more detailed analysis of the traffic of an application that uses communication ports other than WEB requests, we can diversify the strategy and use a remote virtual interface (RVI), as we will demonstrate in the second part of this article.

Part 1 – Using a Proxy Server – BURP

When we mention the use of a proxy server, we are basically referring to intercepting and analyzing requests related to the HTTP (Hypertext Transfer Protocol), whether the one with the TLS (Transport Layer Security) security layer or not.

Some of the applications we have on our smartphones still only use the HTTP protocol, which means that data travels in plain text form, that is, without any encryption, making sensitive information fully exposed to any attacker who adopts techniques man in the middle.

To configure our proxy, the first step is to open BURP software, by default the interface it will be listening to will be the equipment itself, that is, the IP address 127.0.0.1 and port 8080 as we can see in the image below:

In BURP every capture is by default related to the local machine, but to execute our strategy of intercepting the data that will reach our server through the iPhone we will need to add the internal IP of the local machine in the Specific address field.

Note that in this case we adopt the IP 192.168.1.102 with port 8081.

Once BURP is configured, let’s go to iPhone:

Note: Note that the IP address associated with the iPhone has no relationship with the proxy server, but it is obvious that they will have to be on the same network so that traffic can be captured.

As soon as we finish configuring the iPhone to use BURP as our proxy server, we can already see some packages, this is because several applications are running in the background, usually software’s updates, email’s updates, among others.

Below we have an example of intercepted packet with POST method in connection with office365 for email update, note that DeviceType is already identified as an iPhone.

For demonstration we used a real healthcare application, more precisely from a healthcare company, and for ethical reasons, I obviously kept the data hidden.

We can analyze that when we open the application on our smartphone, API requests to the server are already executed to exchange information and with this we have already seen the packages as shown in the image below:

Despite being an application that requires a high level of information secrecy, data is transferred in plain text, so that’s means without any encryption involved.

As we can see in the image below, we are not yet talking about access credentials, but in any case, they are sensitive data, such as the beneficiary number (insurance ID) and telephone number.

Unfortunately, in this application, not only the previously highlighted sensitive data are transferred in plain text, but also the access credentials (username and password) as we can see in the image below:

This means that if we had someone connected to the same network, for example an airport wifi network, cafeteria, restaurants etc., and were running a traffic analyzer where we opened this application, we would have our user and password data leaked (Man in the middle attack).

Part 2 – Using a Remote Virtual Interface (RVI) – Wireshark

Another approach that can sometimes be more interesting is to analyze all the network traffic that occurs between the iPhone device and the application servers, now not only focused on WEB applications and requests (HTTP), but on different protocols.

To implement this, we start with the connection of our iPhone via USB to the computer that will run Wireshark for data collection, then we will create the RVI (Remote Virtual Interface) where we will need to pass the UUID (Universal Unique Identifiers) of the iPhone as a parameter.

Through “Finder” it is possible to discover the device UUID, just click on the name of the connected device and the information will appear as shown in the image below:

Having the device UUID and being connected, it is necessary to activate the virtual interface (RVI), using the following command:

After receiving the SUCCEEDED message, we are ready with the interface enabled and then we can go to the Wireshark network traffic analyzer opening and select the rvi0 interface.

 

In this example and even for comparison purposes with the previous model, we adopted the same healthcare application and applied a basic filter (ip.src == 192.168.1.23) to facilitate viewing only the source IP (iPhone).

It is possible to view protocols from different layers of the OSI model, in this example, we have protocols from the transport layer (TCP) as well as from the application layer (HTTP) as seen in the image below:

Analyzing only the HTTP packets it is possible to analyze the same information that we saw previously in BURP.

So, if we open the content of our selected package, we will also have all the previously demonstrated credential information, as shown in the image below:

Conclusion

We could verify that there are different approaches regarding the capture of data traffic via iPhone. In the first part we demonstrated the technique with the adoption of a Proxy server (BURP) where it was possible to analyze packages related to WEB requests, this technique is easier to implement, but often limited.

In the second part, we demonstrate a broader analysis where it was possible to verify that protocols from different layers can also be analyzed, therefore, depending on the desired objective and/or the form of communication of the application, this may be more suitable.

It is worth remembering that both techniques are complementary, therefore, depending on the application’s final analysis objective, both can be combined.

The path of the stones is given, now it’s up to you to follow for an in-depth analysis of their applications.

Stay Safe

About the Author

CISO and Information Security Researcher – CEH Hacker is NOT a Crime Advocate

Stay Safe (Magazine and Podcast) Founder

Computer Scientist

Post Graduated in Business Strategic Management, Innovation and Teaching

Organizer of Vale Security Conference – Brazil

Director Member of Cloud Security Alliance – Brazil

Advisory Member of Digital Law and High Tech Crimes OAB (Association of Brazilians Lawyers)

IT Teacher and Course Coordinator

SJC Hacker Space Founder

Speaker (AppSec California, GrrCon, Angeles Y Demonios, BSides Augusta, Bsides SP, H2HC, Silver Bullet, Seginfo, ITA, INPE, BalCCon2k14, etc)

Jordan can be reached online at (jobonagura@gmail.com)