Security Series Part 1: Mobile Internet & Zero Rating

Today we’re starting our latest tech blog series, this time about IT-Security related topics. We plan not to use any known vulnerabilities or flaws but instead we’ll present new discoveries made by our team. As well as this, we’ll be exploring areas which aren’t well documented or often talked about. With this in mind, this post will be focusing on the subject of Zero Rating.

Zero Rating refers to internet access being provided under certain conditions without financial cost. The conditions include only permitting access to certain websites or subsidising the service with advertising. Famous examples of this include Facebook Zero, Wikipedia Zero and Google Free Zone which are available as zero-rated services across the globe in several mobile networks.

To get started, you will need the following:

  • Prepaid SIM card
  • Android phone with root permissions
  • Wicap on your android phone
  • DNS Lookup on your android phone
  • Wireshark on your computer
  • A dedicated server on which you can run some scripts

When using a zero-rated service, you are not charged for this usage. The best way to check this is by using a traditional prepaid SIM card and checking its balance before and after using such a service. The easiest way to do so is by using USSD/MMI Codes to check your balance. (#100* for most mobile network operators)

Image 1

Once you find out that services like this exist, the first question you (as an infosec interested person) should ask yourself is: "Can I have everything for free and not just these few zero-rated websites?" Quick answer: "Yes, you can!" I began my research with a prepaid sim card in the o2 / Telefonica network. The first step was to use up any unnecessary phone credit and reduce the balance to zero.

The next step was to identify possible zero rated services. Before Telefonica / o2 acquired E-Plus in Germany, Facebook Zero was reachable via the SIM card I'm using. This is no longer the case and any request to a valid domain now returns a response from my provider that my current balance isn't enough to browse the internet. This returned page has to be zero rated so this made the search for a zero rated service easy!

Next we should check what the traffic looks like when trying to access a page we don't have access to, and what it looks like when it redirects to the zero-rated page. We'll take thingforward.io as example URL. To sniff the traffic, I have used a rooted Galaxy S9 and wicap as sniffer software.

The following steps were executed to achieve the traffic log file:

  1. Start Wicap with root permissions on the phone and press start in the upper right of the screen
  2. Open your web browser and go to thingforward.io
  3. Wait for the redirection to complete and stop sniffing in Wicap
  4. Save the data as .pcap file to analyse it on a computer for the sake of better readability (Swipe from the right corner to the left to show saving options)
  5. Transfer to your computer and open the .pcap file in Wireshark

Image 2

Once transferred and opened in Wireshark, we have a cleaner look at what’s happening:

Image 3

Packet 41 (at the top in the image) is the DNS request going out to resolve the IP of our requested domain thingforward.io

Packet 42 shows us that it resolved the correct IP address and then tries to establish a TCP connection. It looks like it would resolve the data from the correct IP address of our ThingForward server, as it would when we have normal internet access.

Thanks to the providers DPI (deep packet inspection) and modification of packets however, we do not receive the original response but instead something we see in packet 47:

Image 4

The mobile network operator injected its own response data by modifying the response. This is used to achieve the redirection to the previously seen zero-rated web page by using a HTTP response status code 302 which forces the browser to redirect to the specified location in the response header.

From this, we now know that common HTTP(S) requests are modified and how the mobile network operator redirects us. We also can see some interesting behaviour: DNS requests return the correct unmodified response, unlike the HTTP requests.

This leaves an interesting vector open; If DNS requests behave as we expect right now, we should be able to set our own DNS server for cellular connections and use it to transfer and forward data. DNS can potentially be used for this by using its TXT records, which allow the transfer of free configurable text. This would result in a way to tunnel anything we want through DNS. We'll validate this in the next step.

First we have to setup a DNS Server. I'm using a dedicated Debian machine with static IPv4 for this. DNSMasq is the software of my choice to setup the DNS Server and can simply be installed via apt (sudo apt-get install dnsmasq).

Configuration of DNSMasq is quite straightforward. A TXT record should be enough to validate our theory. After configuring this as the DNS server for our prepaid cellular connection, our expectations will be validated, provided the android phone can resolve the TXT record we set.

To configure DNSMasq quickly, I used the dnsmasq.conf file and appended the following:

Image 5

As you can see, the TXT record is configured to return "ThingForward test message" on request.

Continuing on the android phone, install the application DNS Lookup, which allows us to quickly send a TXT record query to a DNS server of our choice.

Image 6

Success!

To sum up: We have zero balance, sent a DNS query and it returned the TXT record we set without the mobile operator to modify its response. This proves that zero-rating applies to DNS requests; at least for the vendors I tested. Going a step further we could now develop applications for client and server side which allows browsing the internet by using this technique or similar.

Due to several limitations it won't be as fast as we are used to but it would work quite well!

Have a look at this sample use-case:

  1. Client (phone) wants to browse google.com

  2. It sends a TXT record query for google.com to our DNS server

  3. The DNS server generates a HTTP request to google.com and on-the-fly generates a TXT record containing the HTTP response. According to RFC4408 TXT records can hold multiple strings to improve the max return size

  4. The client receives the TXT record and has to parse/convert it back to the original HTTP response and show it in a web browser

  5. This could even be extended to be a system wide tunnel application to allow default apps to work too

Right now, there is no clear reason why a vendor would block a DNS request, other than for zero rated websites to resolve their IP addresses. This will most likely be patched in the future; the providers of the SIM cards we used in our tests were informed about this issue.

We hope you enjoyed our first IT security related post, stay tuned for the next one!

Dominik Fehr

Follow ThingForward on Twitter, Facebook and Linkedin!