Monday, October 27, 2014

Identifying Mobile Network Users

WAP (Wireless Application Protocol) was quite cool thing back in the day. It isn’t much used anymore and service providers are dropping it off. One interesting thing with WAP was billing. You could buy content from WAP sites and it was charged to your mobile phone bill. There was no need for registration.

To make the charging possible, your mobile service provider was injecting some special headers like WAP gateway address to your traffic on route, but the most important header was your mobile phone number for sure. Within the traffic, 3rd party was able to get your mobile phone number and knew who to charge.

Picture 1. Header injection.

According to the old comments found from Google, the service providers Elisa and Saunalahti (Saunalahti was already part of Elisa) were injecting your mobile phone number into every request when WAP gateway was used. This happened years ago. The bad guys were also trying to get benefit here and did spread an interesting page via text messages which led non-wanted charges if the page was opened on your mobile device.

In 2012 there was a case in UK where a local service provider O2 was leaking customers’ phone numbers to every website that was visited. The reason for this was technical changes during a routine maintenance.

I created a test page to show all request headers and I accessed the page with my mobile phone using three different mobile subscriptions from the service providers Sonera, Saunalahti and DNA. Only basic headers were seen, nothing was added on route. This was expected outcome.

Picture 2. Service providers.

Testing was done with all working APNs listed by the service providers. Only DNA has a working WAP gateway anymore as far as I know and it wasn’t injecting my phone number, but some other irrelevant information.

Later I found out that Sonera has its own MSISDN entrichment service. There was a short document describing some technical details of the service.

When you make a deal about MSISDN entrichment service with Sonera, you need to provide them the domain name of your website and it must be listening on the HTTP default port (TCP 80). The domain name will be added to Sonera's system and after that a header called "X-UP-CALLING-LINE-ID" is injected into the HTTP requests of the users with the value of the phone number.

Sonera is also giving the ip address ranges where the traffic with the custom header is coming from. It looks like those ranges are used for mobile clients according to their reverses.

There is a test page for troubleshooting. The page shows your phone number if these things are met:

  • Mobile subscription from Sonera or Telefinland (Telefinland is part of Sonera)
  • Correct APN is used – Either "SONERA", "TELE FINLAND" or "internet"

We know that none of these service providers are revealing your phone number to every web page around the internet, but maybe we could create something with Sonera's test page.

The test page is hosted on the domain "m.tele.fi". There is only some basic information, not much resources. I couldn’t find any XSS vulnerabilities from the domain, but there was a cross-domain policy used with the “basic” configuration.

Picture 3. Cross-domain policy.

If you aren’t familiar with the configuration seen in the picture 3, it’s used for Flash objects to handle data across different domains. As the ”allow-access-from domain” is marked with an asteriks (*), it means that any other domain can access to the site content.


So we just need to create Flash object (SWF), HTML page to load our Flash object and a script for logging. This cross-domain “issue” is very well know for years. From Github you can find a nice POC done by Gursev Singh Kalra which I used here.

The exploiting goes like this (see the picture 4): First the crafted HTML page called "steal.html" is opened and a browser loads the embedded SWF file "XDomainXploit.swf". Both of these files are hosted on the attacker's web server. Flash checks the crossdomain.xml file seeing that it has permission to proceed. Then Flash sends a HTTP request to the test site "whatis.php" and got a response which contains victim's phone number. The last request with victim’s phone number goes to the attacker’s server.

Picture 4. Exploiting.

You might know that Flash isn’t working on mobile phones. At least Android, iPhone and Lumia devices aren’t supporting Flash.

However, mobile broadbands for computers are popular here in Finland and the mobile broadband subscription number (just like a phone number because a sim card is used) is also injected to traffic when visited at the Sonera's test page. So this Flash technique could be used for real.

For Saunalahti and DNA I couldn’t find any reasonable way to make their services to forward phone numbers to a 3rd party. Of course there might be other ways to do that like exploiting browser vulnerabilities. As an example Android users could be targeted by using the recently found SOP bypass in the default browser (CVE-2014-6041).

In addition to the phone number stealing and with help of the information gathered along my investigations, I was able to form a request to view balance and validity of any prepaid subscription by phone number on a specific service provider. Well, that's a minor issue.

Also a backend Perl script containing sensitive information and functions of the prepaid service was found.

Picture 5. Backend script.

Cross-domain policy issue and Perl script disclosure were reported responsibly and both of these issues have been fixed. I never received any reply from DNA abuse team even after an another email to them. My first and the last report to them...

It’s obvious that a phone number can be resolved easily compared to an ip address and this gives a good possibility to identify the user.

I can just recommend you to use a VPN tunnel also in mobile networks to make sure your service provider can’t touch your traffic. Your identity information might be sent out to wrong hands even with properly configured service provider equipment as seen in this blog post. And of course there are +100 other reasons to use a VPN tunnel.

If you’re familiar with the modern MSISDN entrichment and have good knowledge or ideas to share for me, please ping me on Twitter. I would like to learn more.