Hack.lu 2012 - Fuzzing the GSM protocol stack (paper)

50 %
50 %
Information about Hack.lu 2012 - Fuzzing the GSM protocol stack (paper)

Published on June 14, 2019

Author: SbastienDudek

Source: slideshare.net

1. MobiDeke: Fuzzing the GSM Protocol Stack S´ebastien Dudek and Guillaume Delugr´e Sogeti ESEC R&D July 13, 2012 Abstract Many security issues have been discovered since GSM was designed1, both in the protocol stack and the cryptography[1]. Because of the complexity and costs to build a network, reproducing or finding vulnerabilities in GSM was much more complicated before. But thanks to the recent developed equipments and softwares, security re- searchers are now able to setup their own network, and perform practical attacks. However, trying to find vulnerabilities in the protocol is hard and time consuming. Testcases generation and faults detection are impossible to perform without the right tools. In this paper we show how GSM messages are represented and sent over-the-air, the framework we made and techniques we used to generate our test-cases for fuzzing. Then we show how we managed to perform the monitoring. 1 Introduction 1.1 Context Efforts around SDR (Software-Defined Radio) have introduced projects like OpenBTS[2], OpenBSC[3], and many others. These softwares allow us to setup a GSM network very quickly, using a computer and a small radio peripheral only (USRP[4], nanoBTS or other devices). Thanks to these projects, anyone interested in this area, is able to study and to attack the GSM protocol. Even if the research has progressed and the hardware is more accessible, finding vul- nerabilities in GSM is challenging. Indeed, with GSM we have to deal with complex and proprietary code, so fuzzing is the easier way to do it. But the two main difficulties in fuzzing are data generation, and faults detection. For data generation we need a good knowledge of the GSM protocol. That implies to read a lot of 3GPP specifications, and capture a lot of GSM frames to see how it works practically. The detection of crashes meanwhile is a bit 1 The history of GSM has begun in 1979 in the WARC (World Administrative Radio Conference), that is today the WRC (World Radiocommunication Conference), where an agreement has been establish to open the 900Mhz bandwidth. 1

2. more harder. Indeed, we need as much indicators as possible to detect if a possible crash happens, and also pause the fuzzing process while the mobile phone is not ready to receive our payloads. We have developed a framework that helps to generate testcases for a chosen message, monitor mobile phone’s states while sending the payloads, and generate a report. This final report can be used to replay some crashes later, and find the right payloads to go deeper in the investigation phase. 1.2 State of the art Only a few research have been made lately on the subject of GSM protocol stack security, especially with SMS messages[5, 8–10]. These researches showed us how playing with SMS format (SMS User Data Header, SM-DATA, concatenation that is up to 255 parts) could lead to security issues. For a local fuzzing, Collin Mulliner has also introduced his “injector”[6] to perform these attacks. His work is related to ours, because it provides SMS PDU generation, SMS injection using AT commands and fault detection on Android, iPhone and Windows phone devices parsing their crash reports. Note that this generally, occurs in the application part. However, mobile phones have two processors: the application processor that runs sys- tems like Android or iPhone, and the baseband processor that runs the communication stack for cellular networks. The baseband is a much more interesting target if we want to be persistent. A few attacks only have been found on it, targeting mainly iPhones like the famous Ultrasn0w unlock[11] that uses vulnerable AT commands to inject and exe- cute code locally. Another discovered vulnerability, which is closer to our approach be- cause it is remote, involves a heap-based buffer overflow in the GSM mobility management (TMSI RELLOCATION COMMAND)[12]. Bugs found in the GSM protocol stack, motivate us to look for new vulnerabilities in other baseband brands and versions. 2 GSM Basics In the following sections, we present a general overview of GSM so that the reader could understand much better the procedure of fuzzing. 2.1 Quick overview of a GSM network A GSM network includes 3 interfaces (Um, Abi, and A) that allow the communication between mobile phones. As we can see in figure 1, the mobile station uses the radio wave (Um link) to communicate with the Base Transceiver Station (BTS). The Base Station Controller 2

3. (BSC) is used to handle BTS radio resources allocations, measurements from the mobile phones, and to control handovers from one BTS to another. Figure 1: A classic GSM Network 2.2 GSM layers As we can see in figure 2, the lowest layer (physical layer 1[14]), in the context of radio, includes RF carrier frequency and GMSK (Gaussian Minimum Shift Keying Modulation) as a modulation scheme. The combination of FMDA (Frequency Division Multiple-Access) and TDMA (Time Division Multiple-Access) is used to divide up the bandwidth among users. Because of the use of TMDA, this layer includes burst time and bit corrections, but also multiplexing, coding/decoding and so on. For error correction, it adds redundant bits through convolutional coding and spreads data transmission by interleaving2 . A slot3 is a time unit for a TDMA frame4 . Logical channels are mapped onto physical channels. In fact for a call, a pair of slots is allocated to a given mobile. These slots represent a physical channel and form the basis of two logical TCH5 channels for the numeric voice and a SACCH channel (Slow Associated CHannel) for the control. On top of the physical layer there is the data-link layer based on the LAPDm, which is a slight adaptation of LAPD protocol from ISDN with same main elements of HDLC (frames numbering, ARQ (Automatic Repeat reQuest) correction, error code detection, frame delim- itation by flag). This layer ensures the correct and complete transfer of Layer 3 information blocks over the radio interface. Layer 3 includes three more sublayers RR, MM and CM. CM is also divided in 6 sub- layers CC, SS, SMS, CLS, GCC, BCC. No encapsulation process is made between RR, MM and CM sublayers. A CM message that crosses MM and RR sublayers, can be completely 2 Interleaving: the information to be transmitted is spread or distributed over several bursts 3 A slot is represented by a radio burst ( 75 130 · 10−3 seconds). 4 A TMDA frame is 8 timelots, so it has a duration of 4.6152 ms. 5 Traffic Channel 3

4. Figure 2: GSM Protocol Stack transparent. The RR sublayer is used to establish a dedicated channel or a recovery during a handover. The MM sublayer manages the location updating, security functions (mobile subscriber authentication), and MM connection that provides some abstraction to CM sub- layer when sending short messages or calling as a simple RNIS network. In the CM sublayer, CC (Call Control) is responsible for call establishments and tear- downs. SS (Supplementary Services) provides services like: call forwarding/baring/priority, show the number of a calling party to the called party and so on. LCSs[18] (Location Services) through the SMLC, helps the mobile station to acquire GPS satellite signals and determines their pseudorange measurement on “MS-Assisted GPS” mode. With the “MS-Based GPS” mode, the SMLC sends assistance data to the mobile station to calculate its own location estimation. The sublayers GCC (Group Call Control), and BCC (Broadcast Call Control) are not sup- ported in every mobile station, and serve conference calls purposes. The last sublayer is the SMS (Short Message Service) sublayer that allows us to send short messages. As we can see, Layer 3 seems to be an interesting vector because of all services it provides. 2.3 Layer 3 messages A specific format for Layer 3 messages[15] is defined. The “Type identifier” (figure 3) has a protocol discriminator that indicates which sublayer has to process a given message. In case of a CC message, the “Type identifier” uses a transaction identifier consisting of a TI-flag and a TI-value6 . For RR and MM messages, a “Skip Indicator” is present which and has a default value of “0000” (if not, the message is ignored by the baseband). 6 that allow a user to have multiple transactions in parallel 4

5. The “Message Type” byte indicates the nature of a specific message. Also the purpose of a “sequence number” is to detect duplicate messages. Figure 3: Structure of a L3 message Five categories of standard information elements are defined (described in section of TS 04.07[16]): • information elements of format V or TV with value part consisting of 1/2 byte (type 1); • information elements of format T with value part consisting of 0 bytes (type 2); • information elements of format V or TV with value part that has fixed length of at least one byte (type 3); • information elements of format TLV or LV with value part consisting of zero, one or more bytes (type 4); • information elements of format V with value part consisting of zero, one or more bytes (type 5). 3 GSM Fuzzing 3.1 Prerequisites Fuzzing is of course is a simple way to find vulnerabilities. In this part, we talk about the entire platform we made, which will generate our payload, monitor every possible state, and manage the fuzzing process so we could be sure that the mobile phone is ready to receive our payloads. 3.1.1 Environment For our remote attacks, we will use a USRP device and the OpenBTS software to send pregenerated testcases to the mobile station. If we compare figure 4 and figure 1, we can see how simple a network is with Software-Defined Radio7 . 7 The USRP is used to create the radio link and the software part that is run in a computer plays the role of the BTS (and kind of BSC and MSC with Asterisk). 5

6. Figure 4: GSM network with OpenBTS 3.1.2 An architecture To fuzz the GSM stack, we need a dedicated platform able to generate testcases, and to take care of every possible state that are also used to manage the fuzzing session automati- cally. The architecture we use is shown in figure 5. First and foremost, we take a message, generate and mutate it choosing one of the methods we want. Then we run the fuzzing session with the pregenerated testcases. While fuzzing the handset, a monitoring process checks and records some defined states, and manages the fuzzing session so we could be sure our payload is sent correctly. At the end, a final report is generated to be analyzed deeper by us. Figure 5: GSM network with OpenBTS 6

7. 3.2 Generation 3.2.1 From scratch Fuzzing with random and non-heuristical data is time consuming and useless. If the mobile does not recognize our data, it will simply reject it. This way, we have just lost time and power for the generation, and the payload sending. As we have seen before, Layer 3 messages have a special format that has to be respected, if we want the mobile phone to receive them. For that, two methods exist: • read 3GPP specifications to implement messages of each sublayer: very long; • capture L3 messages using GSMTAP (Nokia F/M-BUS, OsmocomBB, and so on): need a lot of samples to implement every type of message. The second method looks practical. Indeed, if we take as example a capture of a delivered SMS (figure 6), we can see how easy implementing a SMS message could be. Figure 6: GSMTAP capture: SMS data Dumping and dissecting the bitstream of L3 messages is very easy. Alongside, we can use 3GPP specifications to have a precise view of the message when implementing it, and add other missed elements. The GSMTAP technique gives us a practical view of how messages are represented and sent over-the-air. Later, we will use a library that already implements a big part of those messages. 7

8. 3.2.2 Using existing implementations We searched for existing libraries that already implement what we need and we found the GSM contribution for scapy[20]. A bit later, we discovered and tried the libmich library[17], which is much more complete, so we have chosen to use it instead (cf. listing 1): >>> tmsiReallocationCommand () # with scapy ’ s gsm um <TpPd pd=5 |<MessageType mesType=0x1a |<LocalAreaId |<MobileId |>>>> >>> TMSI REALLOCATION COMMAND() # with the libmich l i b r a r y <[TMSI REALLOCATION COMMAND] : SI ( Skip Indicator ) : 0 b0000 , PD( Protocol Discriminator ) : ’ mobility management messages ’ , seq ( Sequence Number ) : 0 , Type ( ) : ’ Security − TMSI REALLOCATION COMMAND’ , LAI(): <[LAI ] : MCC: 001 / MNC: 001 / LAC: 0000>, ID(): <[ID ] : L ( ) : 1 , V(): <[ID ] : No Identity >>> Listing 1: Comparison between scapy gsm um and libmich Continuing the comparison of other message types, we can see that libmich generates more complete messages. This is very helpful when mutating every possible field of a chosen message. We decided to use this last library to perform the generation phase. Now that we can generate L3 messages, we need to introduce faults in elements to see how the protocol stack behaves. To do that, we use two methods: • libmich’s mutor; • sulley’s mutations. 3.3 Mutation 3.3.1 Native using libmich Libmich implements a native Mutor (cf. figure 7) class which mutates the type, length and value field of each element. To mutate a specific message, we use a “Layor” object that takes an element in input, dissects the given element and uses the Mutor class to perform the mutation. 8

9. Figure 7: Generation with libmich’s mutor 3.3.2 Sulley’s technique Sulley, which is inspired by SPIKE, has a powerful engine to generate and mutate mes- sages. As SPIKE, Sulley use block based approach, that matches perfectly our vision of L3 messages (cf. figure 8). And unlike SPIKE (which is written in C), Sulley is written entirely in python. So as libmich is also written in python, we have chosen Python to develop our tool. Figure 8: L3 message elements It is possible to add more methods to generate testcases, but it is also important to keep in mind that sending generated payload is a very long task. More precisely a message is mutated, the more efficient the fuzzing is. So a wise choice of heuristics is not neglectable. 9

10. 3.4 Observation and fault monitoring 3.4.1 AT responses The AT interface allows us to communicate with the baseband. If at anytime the base- band crashes, it will not respond, or respond badly due to a reboot. Each state of a possible crash is recorded to be replayed and deeply analyzed later. These states are also checked to pause and resume the fuzzing test to be sure the mobile phone is ready to receive our next payloads. To do that on smartphones, we reused the injector made by C. Mulliner [6]. Then, we modified it to be able to send AT queries, and get the response through an opened socket (figure 9). Figure 9: The injector changed to injecATor 3.4.2 BTS’s reserved channel OpenBTS and OpenBSC implement a feature made specifically for fuzzing handsets. This feature in OpenBTS is called “testcall”. When using testcall, OpenBTS opens a SD- CCH channel for a targeted phone in multiframe mode, that tie in a UDP socket, where we can send our prepared L3 packets from an external application. However, because this feature is unstable, it is not made for a real fuzzing session. Indeed, in addition to OpenBTS crashes (at least with non-commercial OpenBTS ver- sions), a reserved channel is often destroyed without any reasons, or is not able to send our packet to the target handset. This is problematic because when we finish the fuzzing, we have to be 100% sure that every pregenerated payload has been correctly sent. Our solution is to patch the OpenBTS code, providing a new feature “fuzztrack” (cf. figure 10). This feature opens a channel as “testcal” does, but also ensures that the channel is still opened, and it is still possible to send any message on it. If it is not the case, we recreate automatically a new channel for the targeted IMSI8 . A token is also responsible to inform the fuzzer for every possible state. In this way, the fuzzer can resume or pause the tests automatically. Moreover, the feature indicates if the mobile phone is still in the channel. 8 International Mobile Subscriber Identity: The unique number of a user that is associated to the phone number. 10

11. Figure 10: The fuzztrack feature in OpenBTS 3.4.3 Application logs In Android and iPhone, the use logcat and the CrashReporter respectively reveals some information about crashes. So we can use a defined vocabulary to detect any crashes both in logcat and the CrashReporter. Unfortunately, most of the recorded crashes are application level only and not in the baseband. But it is always interesting to see if we have a vulnerability and find out if we can exploit it. 3.4.4 Baseband logs On Qualcomm basebands there are some interesting procotols which can give us a lot of informations about the baseband, and let us read/write in the memory: DIAG and QXDM. Activated with a certain level of verbosity, DIAG can reveal a lot of information about processes state, especially when they crash. On some smartphones and baseband versions, it it only possible to access the DIAG by turning the smartphone on a special mode, and activating it with an AT command. But in Android there is another way to get the same information as what DIAG provides, it is with the QXDM mode. When the QXDM mode is activated, it records all logs to the sdcard. Logs can could only be retrieved when QXDM mode is turned off. For the moment, these tracks remain non-explored. Moreover, it will be interesting also to find a way to get these log while fuzzing a mobile phone. 11

12. 3.4.5 The darkside Previous methods have recorded every possible crash or suspicious state automaticaly. However, it is not enough to determine if a crash in the baseband occured or not. Some faults could be invisible to these methods. Also on the other side, recording any suspicious state could lead to false positive results. We are not sure if a payload is responsible for some crashes. So before convinced that we found a vulnerability for every recorder event, we have to replay these crashes, and use a debugger to determine precisely their cause. 3.5 Work in progress 3.5.1 Stateful Fuzzing Most of fuzzers only test the first state, and miss the others that can be vulnerable. Very likely, even vendors did not test or patch these states, so much more bugs could be found. The tool can be extended to perform stateful fuzzing on chosen GSM feature like a call, where more states are passed when originating a call (cf. figure 11). Figure 11: Originate a call: Graph states. This kind of fuzzing is harder, because messages are exchanged between the phone and the BTS. Each time when sending a request/response, we have to wait for the phone re- quest/response, parse it and then send the next message to go to the next state. We also 12

13. have to follow the complete path in the precise order, or use an existent state condition to finish the test, because the handset will be blocked on a state until it does not receive the right message to continue. 3.5.2 Advanced monitoring As we mentioned before, any state is recorded in a dedicated session report. If a checker (agent) reports any interesting state to study, it records it. For every possible crash there is a date time, a text that indicates the origin of the event, the “id” of the last payload sent. When analyzing the report, we can replay a range of payloads, and try to find the payload that caused the crash reducing progressively the range. If we succeed at replaying a crash, we need to find its cause. Analyzing the sent payload helps to understand which element in our message is responsible for the replayed crash. What we have to do is to parse the bitstream and eliminate non-important elements. This way we can focus on a specific vector of attack, and go deeper to find out how we can exploit it. To detect more precisely the type of error after a crash, the use of a debugger can give us more information about CPU registers, instructions context, and so on. In that way we could be sure that we found a vulnerability, and if it is possible to exploit it. Some years before, very few, if not none baseband, debuggers existed. Lately, in the 28c3 conference, it was presented an open source debugger qcombbdbg[22] for icon 225 3G keys (Qualcomm baseband). After registering our 3G key in the BTS, we will be able to put tracepoints on interesting functions he wants to debug. On recent smartphone basebands, Ralf-Philipp Weinmann has presented lately a way to port qcombbdbg with additionnal hard- wares to debug from the JTAG[23]. The problem is that we have to dismantle the telephone to solder the JTAG pins to get access to them. Nevertheless we will be working on this solu- tion soon using the Riffbox JTAG[25], which is compatible with approximately 168 models of mobile phones. 4 Conclusion Fuzzing the GSM protocol stack is a hard work. Without specific tools, we can spend months implementing a message, generating faults on it, and then send it to the mobile station. Knowing there is a lot of messages to test, and the fact that we are not sure to see any bug with some of them, a fully manual fuzzing would be just unproductive. The purpose of MobiDeke is to make easier the implementation, the generation and mutations of testcases, payload sending and monitoring. However there are still few limitations concerning the baseband monitoring part. We are not completely sure if a crash occured, because the way AT responses are checked is not precise enough for the moment, and that can lead to few incertitudes. So we should not interpret each recorded payload in the report as a bug before replaying it, and we have to do a deep 13

14. analysis if we succeed at replaying the crash9 . But we are still working on some tracks to get more information on modern baseband, and expect to have very interesting results to show soon. References [1] Karsten Nohl, GSM: SRSLY?, http://events.ccc.de/congress/2009/Fahrplan/ speakers/1317.en.html. [2] OpenBTS project, http://wush.net/trac/rangepublic. [3] Harald Whelte, Fuzzing your GSM phone using OpenBSC, http://events.ccc.de/congress/2009/Fahrplan/attachments/1503_openbsc_gsm_ fuzzing.pdf. [4] Introduction to USRP, http://invihertz.handgrep.se/doc/Introduction_to_USRP. [5] Collin Mulliner, Nico Golde and Jean-Pierre Seifert, SMS of Death: from analyzing to attacking mobile phones on a large scale, http://www.mulliner.org/collin/academic/publications/Mulliner.pdf. [6] Collin Mulliner, Fuzzing the Phone in your Phone, https://www.blackhat.com/presentations/bh-usa-09/MILLER/ BHUSA09-Miller-FuzzingPhone-PAPER.pdf. [7] C. Mulliner , G. Vigna. Vulnerability Analysis of MMS User Agents. In Proceedings of the Annual Computer Security Applications Conference (AC-SAC) (Miami, FL, December 2006) [8] T. Engel. Remote SMS/MMS Denial of Service - Curse Of Silence, December 2008, http://berlin.ccc.de/tobias/cursesms.txt [9] B. Jurry XFOCUS TEAM. Siemens Mobile SMS Exceptional Character Vulnerability, January 2002, http://www.xfocus.org/advisories/200201/2.html [10] Nico Golde. SMS Vulnerability Analysis on Feature Phones, http://www.isti. tu-berlin.de/fileadmin/fg214/finished_theses/NicoGolde/diplom_golde.pdf [11] iPhone Wiki, Ultrasn0w, http://theiphonewiki.com/wiki/index.php?title= Ultrasn0w [12] CVE-2010-3832, Apple iOS versions less than 4.2 Heap-based buffer overflow in the GSM mobility management implementation, http://web.nvd.nist.gov/view/vuln/ detail?vulnId=CVE-2010-3832 [13] 3GPP - Specifications website, http://www.3gpp.org/specifications 9 A deep analysis using a debugger like qcombbdg [? ] or any other. 14

15. [14] 3GPP TS 05.01 - Physical layer on the radio path, General description, http://www. 3gpp.org/ftp/Specs/html-info/0501.htm [15] 3GPP TS 04.08 - Mobile radio interface layer 3 specification, http://www.3gpp.org/ ftp/Specs/html-info/0408.htm [16] 3GPP TS 04.07 - Mobile Radio Interface Signalling Layer 3 - General Aspects, http: //www.3gpp.org/ftp/Specs/html-info/0407.htm [17] Benoˆıt Michaud, libmich librairy, https://github.com/mitshell/libmich [18] osmocom Security, RRLP messages, http://security.osmocom.org/trac/wiki/RRLP [19] Charlie Miller, Dionysus Blazakis, Dino Dai Zovi, Stefan Esser, Vincenzo Iozzo, Ralph-Philipp Weinmann, iOS Hacker’s Handbook http://security.osmocom.org/ trac/wiki/RRLP [20] Laurent Weber, Extending Scapy by a GSM Air Interface, http://0xbadcab1e.lu/ papers/scapy_gsm.pdf [21] Guillaume Delugr´e, qcombbdg, Reverse engineering a Qualcomm baseband, http:// code.google.com/p/qcombbdbg/ [22] Android, logcat, http://developer.android.com/tools/help/logcat.html [23] Ralf-Philipp Weinmann, Debugging Baseband Stacks, http://recon.cx/2012/ schedule/events/242.en.html [24] Benoˆıt Michaud, libmich, libmich/core/fuzz.py, http://recon.cx/2012/schedule/ events/242.en.html [25] RIFF Box JTAG Revolution, http://www.jtagbox.com/ 15

Add a comment