After a couple of years in pentesting Telco Networks, I’d like to give you some insight into our pentesting methodology and setup we are using for testing “Mobile and Telecommunication Devices”. I am not talking about pentesting professional providers’ equipment (as in previous blogposts), it is about pentesting of devices that have a modem in place like a lot of IoT devices (you know about the fridge having a GSM Modem, right?) do.
In general, such a device will be a small information gathering and delivering node, transferring the data via GSM/GPRS (or UMTS/LTE) to another services node. Examples are Smartmeters, measuring the actual power consumption or Telematic Units delivering measuring statistical and location data to its supplier.
Most of these devices communicate either via SMS or via mobile data (GPRS/UMTS/LTE), and that is why we need a test environment supporting access to these layers. Once having access to the layers, it is possible to perform typical attacks such as scanning, eavesdropping, data interception or message spoofing and follow your common penetration testing steps.
To get a stable and useful environment running, we have the following requirements for our setup:
- supporting sending of arbitrary SMS (with all standard compliant encodings)
- supporting mobile data (at least GPRS)
- stable connectivity ($device must stay in your network for a while)
- compliant to the standards: we must be able to enhance our setup with other vendor solutions
- access to the code to implement our own testing interfaces and functions
Having a look at the market, there are not many choices for equipment; you can spent a lot of money for a BTS or the core elements, but you usually will never get access to the underlying code. That is why we finally decided to use SysmoBTS in combination with OpenBSC and OpenGGSN. All of them are Open Source, but supported by a strong community (it is maintained and more or less stable). The reason why we’ve chosen SysmoBTS/OsmoBTS instead of OpenBTS is the requirement to be compliant with the standards. Some of you might already know the setup from Troopers GSM network which is quite similar.
The SysmoBTS itself covers the BTS part and is working quite out of the box, we only have to configure the OML address in the local configuration. All other information is pushed by the OpenBSC via the Abis interface. This includes MCC, MNC, the used Frequency, and encryption capabilities. All other processes necessary for pentesting (such as authentication and access to SMS/mobile data) is handled by OpenBSC as central management authority.
openbsc.cfg:
network
network country code 262
mobile network code 23
short name ERNW-Lab
long name ERNW-Lab
auth policy accept-all
encryption a5 0
Configuration of used Frequency/ARFCN:
trx 0
arfcn 870Configuring A5/0 as encryption mechanism makes eavesdropping quite easy. To make it more comfortable for the pentester, we also can use the internal debugging interface of the SysmoBTS. With a simple trick you even can forward all traffic of the radio interface to wireshark. Therefore we have to enable debugging on the assessed channel (e.g. SDCCH) on OsmoBTS. You can simply do this via the following command (in the VTY):
OsmoBTS(trx)# gsmtap-sapi sdcch
Now you can capture the traffic in tcpdump on SysmoBTS and forward it to your laptop (in this example to IP address 192.168.0.1, UDP Port 9999):
tcpdump -s 0 -U -n -w - -i lo udp port 4729 | nc 192.168.0.1 9999
Finally, you have to start a local UDP listener (e.g. via Netcat) on the pentesters laptop and forward the traffic to your pcap file.
nc -l -p 9999 > temp.pcap
The authentication in our setup is done by the OpenBSC in combination with the integrated HLR. The HLR is implemented as a SQLite database allowing easy access to all necessary information. We also can touch the database in runtime via command line or additional applications. We are using a modified version of SimpleHLR. This tool enables us to add or modify subscribers on the fly via web application, and it provides functions for sending and accessing SMS or other services (e.g. Paging) in our network. For pentesting of a device the best authentication option is to accept all connections trying to authentication against our network. Unfortunately this could often result in an accidently IMSI catch of your mates closeby :-). You have to use this option anyhow if you don’t have Ki/Kc of the tested device (e.g. via using an own SIM card).
openbsc.cfg:
network
auth policy accept-all
nitb
subscriber-create-on-demand
Finally, to access mobile data traffic we have to enable GPRS on BSC and configure OpenGGSN to route the traffic to a certain network.
Ok, this is the basic setup and now we have to connect the tested device to the network and start the analysis. With the packet forwarding you can start with eavesdropping and performing a protocol analysis of the transmitted data. This includes both, SMS and mobile data. If the device is using mobile data for transmission you should also start with services scanning and typical vulnerability assessments. If not using packet forwarding and if the device is using SMS communication, youalso can access the SMS table in your SQLite database. All necessary information is stored here:
sqlite> .schema sms
CREATE TABLE SMS (id INTEGER PRIMARY KEY AUTOINCREMENT, created TIMESTAMP NOT NULL, sent TIMESTAMP, deliver_attempts INTEGER NOT NULL DEFAULT 0, valid_until TIMESTAMP, reply_path_req INTEGER NOT NULL, status_rep_req INTEGER NOT NULL, protocol_id INTEGER NOT NULL, data_coding_scheme INTEGER NOT NULL, ud_hdr_ind INTEGER NOT NULL, src_addr TEXT NOT NULL, src_ton INTEGER NOT NULL, src_npi INTEGER NOT NULL, dest_addr TEXT NOT NULL, dest_ton INTEGER NOT NULL, dest_npi INTEGER NOT NULL, user_data BLOB, header BLOB, text TEXT );
This includes the PDU of the SMS, which is saved in cleartext in the text column and the 7-bit encoding data (or 8 bit, depends on configuration) in the user_data. Also interesting might be the src_addr and dst_addr if you want to test message spoofing. Not all command SMS should be accepted from every peer, right? In some cases of pentesting you also will see OTA and no “normal” messages. You can identify those via the protocol_id and the used data_coding_scheme (usually they are transmitted via 8-bit binary data). If you want send SMS you can simply add a message to the SMS table.
I think this is be enough for a first explanation of our setup. It enables us to bring our pentesting methodology to devices using GSM/GPRS as interface.
Feel free to play around with and I am always happy to hear your feedback.
Best,
Hendrik