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.
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.
 |
| 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.
