Alleen beschikbaar in het Engels
11 December 2017, by Ralph Moonen, Technical Director at Secura
Practical GPRS MitM attack- mobile setup with YateBTS
Many IoT devices and other assorted connected equipment such as smart meters, car charging stations and connected cars still use GPRS communication to send small bits of data to a backend service, or receive commands. GPRS is built on 2G communication and has a wide geographical coverage. It is a well-known fact that 2G and GPRS are not secure due to the fact that the 2G protocol set does not authenticate the network, leaving it open to attacks where the network is spoofed, making the device connect to the fake network and the attacker gaining a Man-in-the-Middle (MitM) position. From there, an attacker can modify traffic, see what's being sent and of course potentially impersonate the backend and send commands over that supposedly trusted channel.
At Secura, we recently were in need of such a setup, and we were interested in knowing how easy or difficult it would be to perform such a GPRS MitM attack. Such attacks are not new and we know from others it is possible. We'd simply never had the need to perform such an attack.
Mobile setup
There are many online resources and software implementations that fill in parts of such a setup. Obviously a Software Defined Radio (SDR) is necessary, as is a host controller. We wanted to make it a mobile, battery powered setup though, giving it a high degree of mobility. Many people have used OpenBTS but in earlier experiments, we failed to get this working reliably. Also, many dependencies exist with external packages, and compiling all necessary bits was quite tedious to say the least.
The cheapest option for a suitable SDR is the BladRF x40 (available at www.nuand.com): it is a great piece of hardware. For it to work well, it needs a USB3 port on the host controller. Since we wanted a mobile setup without a laptop we settled on the Odroid XU4. It has USB3, enough processing power and RAM to run Linux and the required software stack. The fast eMMC flash helps it boot quickly and it has a nice feature set.
Because of our experience with OpenBTS we were looking for a different stack, and found YateBTS to be very suitable (https://yatebts.com/download). The BladRF is supported out-of-the-box but we were struggling finding the most compatible Linux distro due to library dependencies and versions. In the end after trying several, we settled on Ubuntu MATE which comes with the XU4 and fits easily on the host controller.
YateBTS -> 4G dongle -> OpenVPN
Simply posing as a fake 2G base station doesn't fulfil the requirement for MitM though, we need a way to connect back to the telephony network, or to internet, or in a more complex cases to the so-called "private APN" of the device (see http://www.wirelesslogic.com/frequently-asked-questions/ for a nice overview of all relevant terminology). So we used a Huawei 4G dongle to provide connectivity.
The idea was to have a reasonably autonomous unit, and some way of remotely loggin in to the host controller is required. Since virtually all 4G providers do not allow incoming connections, we need a way to make it accessible, while providing a secure backend connection. So we set up a virtual server as an OpenVPN server. The host controller then opens the VPN tunnel as soon as the 4G dongle has a connection with the provider. We did not use WiFi for this connection because we wanted to be able to use the device in places where WiFi is not available.
It took a bit of configuring and scripting to get it all to run and boot in the correct order. Especially because the 4G dongle drivers and network manager run in userspace. They only connect to the mobile network when a user logs in. After solving this problem, the unit boots as thus: Linux -> YateBTS -> 4G dongle -> OpenVPN.
How easy or difficult is it to make a device connect to us, instead of the real network?
We provisioned a generic VoIP provider in YateBTS to provide voice communication, and set up routing and NAT-ting on the host controller to provide GPRS internet access through the OpenVPN tunnel. Since all our traffic is now routed through the OpenVPN server, we don't necessarily have to access the host controller except for configuring YateBTS, which can be done with the built-in web interface and command line utility that runs on port 5038 of the host controller (all accessible from the OpenVPN server). This makes the setup easily manageable from a remote location.
So in theory, the setup allows us to present ourselves as a functioning GPRS network provider, with full MitM capabilities, configurable and autonomously deployable (we also covered battery operation but won't go into that here).
In practice however we had yet to find out how easy or difficult it is to make a device connect to us, instead of the real network. There are several hurdles to overcome here. Many providers of M2M services use networks of other telco's. In order to spoof those networks, we need to know which one to spoof. However, if we know the telephone number of the SIM card, we can do an HLR Lookup to find out what provider in which country is serving this device. The first 5 digits of the IMSI tell us what the Mobile Country Code and Mobile Network Code are. As you can see, my phone number's IMSI starts with 20404: 204 being The Netherlands, and 04 being VodafoneZiggo.
Our lab setup
At this point you might be asking yourself "Is this all legal"? The short answer is yes, but only under certain conditions. You can transmit on the unused channels of the DECT Guard Band, with very limited transmitted power. And if you do, you cannot impersonate a real network publicly. However if we place our transmitter and the device under test in a faraday cage and make sure the real networks is not hindered in any way, this is permissible in a lab situation.
Back to our little project: We know what MCC and MNC to spoof, so we configured Yate to do this. Rebooting the device while making sure it cannot connect to the real network (there's several ways of doing this such as the aforementioned faraday cage, or removing antennas from the device under test) indeed lead to the desired result: we see the device register to our fake BTS. It is give an IP address by Yate, we can ping it, do portscans on it (from the position of what a telco would normally only have) etc.
And finally, when we run wireshark on the OpenVPN server and filter out the GPRS traffic, we see all data being sent from the device to the backend server, through our infra, ready to be captured, manipulated, reverse engineered or whatnot ;-)
