Short-Message-Service (SMS) is one of the most used ways to exchange text messages ofered by mobile networks. In this paper, we explore the feasibility of establishing a tunneling system based on SMS. Our proposed scheme allows a client (e.g. a web browser) to connect to the Internet by encapsulating HTTP/HTTPS requests/responses into SMS messages. Along with the development of the tunneling architecture and the attack modelling, we conducted some preliminary tests to evaluate the feasibility of the proposed tunneling system. Obtained results indicate that our system is able to handle up to 1200 bytes of web request data when using equal mobile operators, whereas 1248 bytes for diferent mobile operators.
followed the last criterion to provide an overview of the existing covert channels. Protocols
of the network and transport layers (IP, TCP, ICMP) present header fields that can be misused
to convey secret data: this can be achieved by header bit modulation (e.g. unused header bits,
TCP ISN field, checksum field, address fields, etc.), header bit crafting (e.g. header extension,
padding, IP ID and Fragment Ofset) or optional header extension [
In recent years, we have assisted to a rapid growth of mobile technologies, so their security is now a very important issue to take into account. It is often compromised: as an example, a well-known phone company has recently declared that private and technical data have been stolen from users’ SIM cards 1.
Covert channels afecting mobile networks worth to be investigated; in particular, text messages like SMSs can constitute a new opportunity to construct a covert channel, since they are now widely available at relatively low cost.
In this paper, we study the feasibility of a novel tunneling system based on CSC, in which
application data are carried inside Short-Message-Service (SMS) payload. Since people bring
their mobile phones everywhere today, as essential parts of their everyday activities, such
devices may become instruments for an attacker too. In fact, thinking about the insider threat
scenario [
The remaining of the paper is structured as follows: Section 2 introduces SMS and their functioning, while Section 3 describes the concept idea of the proposed innovative covert channel. Instead, Section 4 reports some preliminary tests on the feasibility to establish SMSbased tunnels. Section 5 reports the related works on the topic. Finally, Section 6 concludes the paper and reports further work on the topic.
Short-Message-Service (SMS) is a service that allows the exchange of text messages between mobile devices. A first implementation of SMS was carried by Global System for Mobile Communications (GSM), the first standard developed for mobile telephony systems in the world. SMS was implemented by GSM according to the European Telecommunication Stardard Institute 1More information is available at the following address: https://www.cybersecurity-help.cz/blog/1855.html (ETSI) technical specifications, then it has been carried out in the scope of 3G Partnership Project (3GPP) activities so that, by now, the service works in 3G and 4G networks too.
A single SMS comprises a header, with useful information, and a payload, which is the text content. The maximum size of a single SMS is 160 characters with 7-bit encoding.
The flow of an SMS through the GSM network involves the following steps [
MSC and from here to the final recipient.
There are two ways to submit a message on GSM network: Protocol Description Unit (PDU)
mode, that is in bits, and text format, i.e. the normal text. PDU format is more structured: the
message appears as a string of hexadecimal octets, grouped in diferent parts containing useful
information regarding the message and also details about the user. In PDU mode, SMS packets
are diferent depending on if the SMS is being sent or received: SMS_SUBMIT or SMS_DELIVER
formats are used respectively (see Section 3.3 of [
AT (ATtention) commands are a set of short text string commands used to control GSM phones or modems. They can support many actions, including all the processes involved in sending/receiving of SMSs. To understand the AT commands usage, in Table 1 we report a list of the most common ones in the field of SMSs.
Parameters can be added to the AT commands after an = sign to enable functionalities (e.g. AT+CGMF=1 for SMS text mode). There are lots of AT commands, but manufacturers usually do not implement all of them in the same way and with the same parameters. Hence, the use of AT commands cannot be generalized for all kind of devices.
In network security context, the aim of a tunneling system is to carry a given communication
protocol into the payload of another one. Typically, such systems may be used to overcome
network limitations (i.e. firewalls) and potentially to leak private and sensitive data. Such
scenario can fit the insider threat problem [
AT AT+CLIP AT+CRC AT+CMGF AT+CNMI AT+CMGL AT+CMGD AT+CMGW AT+CMSS AT+CMGS
Returns OK when the communication between the device and the application has been verified Refers to the GSM/UMTS supplementary service CLIP (Calling Line Identification Presentation) Controls whether or not the extended format of incoming call indication or GPRS network request for PDP context activation or notification for VBS/VGCS calls is used Message format (0 for PDU mode, 1 for Text mode) New message indications to Terminal Equipment Lists all text messages that are stored in memory Deletes messages from memory Writes SMSs to message storage area of SIM card Sends SMSs from message storage area
Sends SMSs directly to the recipient’s phone number
Inspired by the rapid development of mobile technologies and the drastic cost reduction of SMSs, we decided to investigate if it is possible to implement a tunneling system that exploits the SMS protocol.
Our SMS tunneling system can be described through the architecture shown in Figure 1.
The proposed system is composed of four software modules: socks, tunnel client, tunnel server, and tunnel proxy. In order to understand how the system works, the first two blocks may be ideally coupled to form a socks server and, similarly, the other two blocks are referred to as a unique tunnel receiver component. In our scenario, an attacker establishes a connection over the tunnel by communicating with the socks server through a client (e.g. a web browser). We assume that the socks server is located inside the targeted private network and used by the malicious node to initiate the tunneling system. In contrast, the tunnel receiver component is thought as an external node, which is under the control of the attacker too.
Therefore, by exploiting such tunneling system, the client may be able to perform web browsing activities.
Suppose → and → being the request and response pathways respectively, involving tunnel client and tunnel server modules. We now provide a more detailed description of the single modules; in this context, our focus is on HTTP/HTTPS data, but the involved messages can actually be of any kind: • Socks server. In the → pathway, it receives the HTTP/HTTPS raw requests from the client, splits their payload into -characters-sized parts and builds an SMS string for each obtained portion. Such SMS is then sent to the tunnel receiver. In → , it listens for incoming connections from tunnel receiver and reconstructs the web response from the received SMSs. Finally, such response reaches the client. • Tunnel receiver. This component acts in a symmetric manner with respect to socks server. It overtly communicates with a web server: while being in → phase, the tunnel receiver reconstructs the original HTTP/HTTPS request from SMSs received by the socks server; in → , it receives a web response, then it generates SMSs in the same way as socks server does for → and sends them to the socks server.
Each SMS, both in → and → phases, is made up of a string containing five fields, separated by a dash character (-), containing (i) the web server IP address (destination_ip in the following), (ii) the web server listening port number (destination_port in the following), (iii) the client port number, (iv) a message index (index in the following), and (v) the payload (portion) to send. The first three fields represent a kind of header used to match the connection between the client and the socks2. In addition, the tunnel proxy connects to destination_ip:destination_port to get the information about the requested web page.
The index is calculated in order to count how many fragments of the original request/response are generated by splitting it into pieces of characters. This information is needed to control the correct order of SMSs after they travel along the tunnel.
The content field encapsulates the request/response fragment. Before being sent through the tunnel, it is encoded in base 64 in our design, in order to maintain the standard ASCII SMS characters and prevent possible SMS reading issues. Once the SMS reaches its recipient, this ifeld will then be decoded from base 64 for further processings.
In order to handle the connection between the client and the socks server at the transport level, so that the system acknowledges when the data exchange between them must be interrupted, we introduced a particular SMS, which we call zero packet. Such SMS has the same header as described above, while its index is fixed at 0. The content is put to 1 if the connection is open, whereas it is 0 when closed. When the communication between client and socks server ends, the closure zero packet is used to close it. Similarly, a zero packet with content=0 may be sent to establish connections, although this may lead a connection closure, if the message with index=1 is not received before the expiration of the server-side timeout waiting for data after the three-way-handshake is completed.
2Here, we assume a single client is present; in case of multiple clients, an additional field may be required, specifying the IP address of the involved client.
In order to better define the proposed attack and evaluate if it is possible to exploit it for network communications, we will now model the attack behavior.
In order to analyze if the proposed tunneling attack can be employed for a specific communication, it is required to analyze the time delays introduced in the communication by the tunnel architecture.
In particular, referring to the scheme depicted in Figure 1, let’s suppose that a request message has to be sent from the client to the web server. Once is received and interpreted by the web server, the relative response message is generated and sent back from the web server to the client.
Suppose | · | being the length of · , in bytes, and the addition symbol + the concatenation of two strings, expressed in bytes. Let’s also define as the maximum size (in bytes) of a single SMS message. Given a message to be sent through the tunnel by one endpoint to the other, we can compute the number of required SMSs as follows: = ︂⌈ || ⌉︂ (1) (2) (3) (4) Similarly, for the → pathway, we define as follows:
= ∑︁ =1 = ∑︁
=1 where, for simplicity, we assume that no overhead is introduced on each message (for instance, by headers, footers, or changes in data representation).
Referring to the → pathway, we have:
|| > =⇒ = 1 + . . . + where > 1 is the number of SMS messages required to send a message , computed as in Equation 1. Instead, for = 1 , we have || ≤ .
The expression of in Equation 2 can then be simplified as: with being the number of SMSs needed to send , defined as in Equation 1.
Now, in order to define if it is possible to exploit the proposed tunnel, it is required to analyze the network requirements of the specific channel which has to be established. Such channel depends both on the client and web server characteristics. For our scenario, such characteristics are browser and server timeouts.
In particular, considering a specific channel, let’s suppose that, through the proposed tunnel, the number of sent SMSs per second is .
Notation | · |
Let’s suppose be the timeout used by the client/browser and, similarly, be the server timeout. Let’s also define the time required to send a message from one endpoint to the other one, through the proposed tunnel. Particularly, we define in function of , as follows: (5) (6) (7) (8) = <
In addition, for given and , we define the time required to the web server to process the request, in order to produce .
Therefore, we expect a server side connection closure if the timeout, related to the → pathway, expires, according to the Equation 6.
Also, we expect a client side connection closure if the timeout, related to both the → and → pathways, expires, according to the Equation 7.
Finally, we state that the proposed tunnel is efective if Equation 8 is satisfied.
< + + + + ≤ ∧ ≤
For sake of clarity, in Table 2 we wrap up the notation adopted throughout our attack description.
In order to perform an evaluation on the feasibility of the proposed attack, we conducted some preliminary tests based on AT commands (Section 2.1), aimed at studying the behavior of SMSs sent between the endpoints.
For the implementation of our system, we used two Raspberry Pis, one as the socks server and one as the tunnel receiver, each interfaced with a USB HSPA modem provided with a slot for a SIM card.
We performed a direct sending test, where SMSs were sent to the recipient without intermediate steps, using the AT+CMGS command (Table 1).
Let’s suppose , = [1, . . . , ] as the sequence of diferent SMS messages that our system is able to continuously send in a fixed time window (expressed in seconds), being ≤ the number of messages which is possible to send in that time interval, with defined as in Equation 1. The goal of the preliminary tests we have accomplished is then to compute in two diferent test cases, involving (i) the same mobile operator (TIM Italian mobile carrier) for both sender and receiver, and (ii) a diferent mobile operator between sender (TIM Italian mobile carrier) and receiver (Iliad Italian mobile carrier). In both test cases, the content of each message was made up of a text string containing also a counter, which we use to evaluate the SMSs sending, also in terms of reception order or losses.
Such tests were conducted by fixing = 60s as time window. Within such time window, we found out the following results: for the first scenario (same mobile operator), and 1 = 15 2 = 16 for the second scenario (diferent mobile operators).
Referring to the attack model presented in Section 3.1, we exploited the obtained values to compute the total maximum size || of HTTP/HTTPS requests/responses payload we can transfer over the tunnel, measured in bytes.
First of all, we computed the frequency of SMS sending, expressed by (i.e. how many SMSs are sent per second), as follows: = (11) For our two scenarios we obtained 1 = 0.25 SMS/s (same operator) and 2 = 0.26 SMS/s (diferent operators).
Referring to Equation 8, we can assume, for simplicity, = 0 s , hence an extremely reduced
server-side computation time. This may be reasonable, considered the greater impact of both
and . We can also assume = 30 s, corresponding to a client-side timeout (e.g.
a browser timeout) of 30 seconds. Finally, we can assume = 300 s, as it represents, for
instance, the default Apache2 timeout [
= + ≤ (9) (10) (12) (13)
At this point, according to Equation 5, by fixing = = 30 s (as we do not want to expire the client timeout), we get = · . The maximum payload length can be then computed as || = · · (Equation 1). By assuming, for simplicity, that the size of SMS messages to be sent through the tunnel is the highest supported by the SMS protocol, we fix = 160 bytes/SMS (i.e., 160 characters with 7-bit encoding).
Therefore, in our two test cases we get: for the first scenario (same mobile operator), and |1| = · 1 · = 1200 bytes |2| = · 2 · = 1248 bytes (14) (15) for the second scenario (diferent mobile operators). All payloads exceeding such sizes will lead to a connection closure for the considered web scenario. Also, since the results show |1| < |2|, the exploitation of equal operators seems to slightly have a negative impact on the tunnel performance. Other scenarios (like chats or SMTP data exchange) will be investigated in the scope of further works on the topic.
Moreover, by monitoring the SMS reception, we noticed that the order of the received SMSs was not the same as the one in which the messages were sent: we expected such a behavior, in fact our tunneling system embeds a reordering mechanism for the messages received from a tunnel endpoint to another one.
In the era of mobile technologies outbreak, people are prone to make a massive use of their mobile phones, they download lots of apps without being aware of the risks they may encounter. For this reason, security of mobile devices is always more under threat.
In recent years, a lot of work ([
In another survey ([19]), SMS interception and manipulation attacks are presented, where attackers act as SMSC and make use of fake MSC in order to get IMSI and address of the victim, thus identifying it.
SMSs are now a common method for two-factors authentication, even if they’re not so secure. In [20], three methods to intercept SMSs are presented: GSM trafic capture; getting access to Signalling System No. 7 (SS7) architecture and exploiting its protocols (like CAMEL) flaws; SIM swapping, which consists in porting a user’s SIM card by fooling mobile operators, so that the attacker receives all its data.
Focusing on GSM network, a second generation standard for cellular networks that reached
90% of market share by 2017 [21], very few works explored the feasibility of creating covert
channels exploiting SMS protocols. The author in [22] demonstrated the possibility to embed
secret information inside SMS User Data Header redundant fields, in such a way that an
independent warden (recalling Simmons’s Prisoner Problem [
The idea of an SMS tunneling was investigated in [26] too, where a so-called WebSIM was developed, i.e. a SIM card acting as a web server for personal security. In this context, IP packets were embedded into SMSs in order to reach the WebSIM and provide connectivity. In contrast, in our system we use SMSs just as carriers for bringing connection outside. Another work [27] developed a query/retrieve system, called iTrust with SMS, which allows users to search/get information cointained in iTrust with HTTP network nodes[28] via SMS. The requests are made through text keywords and then this framework is able to convert them to GET HTTP requests. Such a system has limited application because of the limitation in SMS size (140 bytes) and it cannot fit into a covert channel definition.
To the best of our knowledge, no studies investigated the feasibility of a SMS tunneling, intended as a way to exchange forbidden information between two nodes via SMS.
In this paper we have theorized an innovative tunneling attack based on the exchange of SMS messages. Such a system may represent a potentially dangerous threat, as the stealing of private and sensitive data could lead to serious problems in critical contexts like health, finance or industry. In addition, using a third-party network, potentially uncontrolled, may hinder detection and mitigation of the proposed threat. Despite many malicious tunneling applications already exist and are well-established, involving the most common network protocols (DNS, ICMP, SSH, etc), our proposed scheme allows to exploit a protocol in the field of mobile networks. In our concept, this feature represents a great advantage, in virtue of the huge development of mobile devices and the fact that the sending of SMSs has become cheaper in recent years.
Nevertheless, in this paper we have presented a preliminary investigation on the feasibility of the SMS tunneling. Due to the limited size of SMS messages, we expect performance limitations of the tunnel: however, the obtained preliminary results indicate a promising starting point for further investigations. Namely, future works will be addressed to a deeper testing of the system, aimed to the individuation of the SMS tunneling capabilities and weaknesses.
This work was supported by the following research project: the Integrated Framework for Predictive and Collaborative Security of Financial Infrastructures (FINSEC) project, which has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under Grant Agreement No. 786727. vulnerabilities and their defensive mechanism, International Journal of Computer Applications 56 (2012) 24–29. doi:10.5120/8960-3163. [16] M. La Polla, F. Martinelli, D. Sgandurra, A survey on security for mobile devices, Communications Surveys & Tutorials, IEEE 15 (2013) 446–471. doi:10.1109/SURV.2012.013012. 00028. [17] B. Rashidi, C. Fung, A survey of android security threats and defenses, Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications (JoWUA) 6 (2015) 3–35. [18] S. Farhan, S. F. Zaidi, A. Munam, M. Shah, M. Kamran, Q. Javaid, S. Zhang, A survey on security for smartphone device, International Journal of Advanced Computer Science and Applications 7 (2016) 206–219. doi:10.14569/IJACSA.2016.070426. [19] K. Ullah, I. Rashid, H. Afzal, M. M. W. Iqbal, Y. A. Bangash, H. Abbas, Ss7 vulnerabilities—a survey and implementation of machine learning vs rule based filtering for detection of ss7 network attacks, IEEE Communications Surveys Tutorials 22 (2020) 1337–1371. doi:10.1109/COMST.2020.2971757. [20] R. P. Jover, Security analysis of sms as a second factor of authentication, Commun. ACM 63 (2020) 46–52. URL: https://doi.org/10.1145/3424260. doi:10.1145/3424260. [21] F. Hillebrand, The creation of standards for global mobile communication: Gsm and umts standardization from 1982 to 2000, IEEE Wireless Communications 20 (2013) 24–33. [22] M. Z. Rafique, K. Khan, K. Alghatbar, M. Farooq, Embedding high capacity covert channels in short message service (sms), in: Communications in Computer and Information Science, volume 186, 2011, pp. 1–10. [23] K. G. Kangas, Clandestine transmissions and operations of embedded software on cellular mobile devices, 2011. [24] W. Mazurczyk, L. Caviglione, Steganography in modern smartphones and mitigation techniques, IEEE Communications Surveys & Tutorials 17 (2015) 334–357. [25] S. Patiburn, V. Iranmanesh, P. Teh, Text steganography using daily emotions monitoring,
International Journal of Education and Management Engineering 7 (2017) 1–14. [26] S. Guthery, J. Posegga, M.-m. Deutsche, The websim - clever smartcards listen to port 80, 2000. [27] I. Lombera, L. Moser, P. Melliar-Smith, Y.-T. Chuang, Mobile decentralized search and retrieval using sms and http, Mobile Networks and Applications 18 (2013). doi:10.1007/ s11036-012-0412-0. [28] Y.-T. Chuang, M. Isaí, L. Lombera, P. Moser, Melliar-Smith, Trustworthy distributed search and retrieval over the internet, 2012.