Attempting To Send An MMS Using A Huawei GSM Modem Dongle

Introduction.

Multimedia Messaging Service (MMS) was created as a way for sending multimedia messages and content through the telecommunication networks and evolved from the standard SMS (Short Message Service) capability which only allows exchange of text messages up to 160 characters in length. 

MMS functionality is basically a combination of the SMS (Short Message Service) and the Wireless Application Protocol (WAP). The Wireless Application Protocol (WAP) is an international standard for application-layer network communications in a wireless-communication environment. The main technical specification reference document for the Wireless Application Protocol (WAP)  is this document. Other technical document specifications can also be referenced. 

Although most modern messages (especially multimedia contents such as GIFs) are conveyed using IMs, the functionality is still maintained in most modern smartphones for backwards compatibility. 

In the security research context, this not only exposes an attack surface but also exposes modern smartphones to other memory corruption vulnerabilities as MMSes are a fairly effective entry-point to a modern smartphone. An attacker is able to send a malicious payload as one only needs to know the victim's phone number. 

Thus, the main aim for my research is to understand how MMSes are structured and sent over the network. Furthermore, it is crucial to be able to send an MMS over the network using inexpensive hardware (such as a huawei modem dongle). 

For this first phase, three main components need to be researched and implemented. 

• Learn the basics and working of the Multimedia Messaging Service (MMS) protocol from official documentation and functional descriptions. The main technical specification reference document for the Multimedia Messaging Service (MMS) protocol will be ETSI TS 123 140. 
• Install, configure and validate the python-mms module.
• Configure the GSM modem through WSP and WTP layers of the Wireless Application Protocol (WAP) to connect to the carrier's gateway (the carrier's MMSC)  and send an MMS to ascertain that the customized configuration is working.

Basics Of Multimedia Messaging Service (MMS) Protocol

The image below is a summary flow of the MMS Protocol. 

MMS Message Flow (Simplified). Credits

The labeling of MMS abstract messages follow certain naming conventions ranging from MM1 to MM11. However, in this context the most relevant are MM1 and MM4. MM1 is a reference to transactions between an originator UA and it's MMS Relay Server while MM4 is a reference to transactions between different MMS Relay Servers. 

When an MMS User Agent (MMS UA) wants to send an Multimedia Message (MM) to a recipient, a request/response pair is sent to the originator MMS Relay Server to check whether it is compatible i.e supported by the carrier (Pg 63 - 67).  If compatible, the originator the MMS Relay Server initiates a request/response pair to the recipient MMS Relay Server (Pg 92 - 97). 

The recipient MMS Relay Server shall then send a request for a notification from the recipient MMS UA whether it is able to receive the MM i.e an MM is waiting for it (Pg 67 - 70).This is done by sending a WAP PUSH notification to the recipient.  Once a valid response is acquired, the recipient MMS UA initiates a request/response pair that is used to retrieve the MM (using a HTTP GET request). In some cases i.e some devices, the MM is retrieved automatically once the notification is received. An acknowledgement request is then sent to the recipient MMS Relay Server (Pg 70 - 74). 

A request/response pair is then initiated to the originator MMS Relay Server to inquire whether a delivery report has been requested for the submitted message. (Pg 98 - 100). This is done by initiating a request to the originator MMS UA (Pg 77 - 78). The value can either be 'yes' or 'no' and if it is 'auto' then this is automatically assigned as a 'no'.

The recipient MMS UA then sends a request to the recipient MMS Relay Server to inquire whether a read-reply has been requested (Pg 78 - 80). The two relay servers then perform a request/response pair to inquire whether a read-reply will be sent back to the originator MMS Relay Server (Pg 101 - 103). Finally, the read-reply report is availed to the originator MMS UA when ready through a request prompt from the originator MMS Relay Server (Pg 78 - 80). 

In line with the context,  the main focus is going to be MM1_notification request/response pair as this is where an MMS notification is sent to the receiver MMS UA via SMS (WAP PUSH) and the respective MM is retrieved/downloaded  using a HTTP GET request. It is important to note that an MM is a binary file of MIME type application/vnd.wap.mms-message.

Prerequisite Installations And Settings

1. python-mms Installation

To install the downloaded python-mms module, simply run python setup.py install  from the respective folder.

Because the module is outdated (published 11 years ago at the time of writing this), one has to clean the code and fix the multiple syntax errors. The module will be installed in the dist-packages folder. In my system, it is installed in the /usr/local/lib/python3.10/dist-packages folder.

In case of errors when installing, simply delete the two newly created files by issuing the sudo rm -rf  <filename 1> <filename2> command in the /usr/local/lib/python3.10/dist-packages folder and repeat the process again till all errors have been resolved. 

A successful installation may look like this:

2. wvdial Configuration

In order to work with the python-mms module, it is important to initiate a GPRS connection and the carrier's WAP gateway and MMSC should be reachable. To do this, wvdial comes in handy as a tool for connecting the GSM modem as the PPP connector. 

Simply install wvdial and run sudo wvdialconf /etc/wvdial.conf  to create the configuration file. The dialer automatically detects and applies the correct settings e.g baudrate. Finally run sudo wvdial  to connect to the WAP gateway. After successful connection, an IP address and DNS address is displayed in the terminal. 

It is important to note that for recent linux distributions, the NetworkManager interface overrides the wvdial dialer and thus, one has to toggle the On/Off button in the NetworkManager menu in order for wvdial to connect. Furthermore, one can also input the SIM PIN through that menu interface and one doesn't have to provide an AT command in the configuration file to provide this. 

Attempt At Full Functionality

After successful installation and configuring of the module, the first step was to create a script to ascertain that the modem was working. The successful script is shown below:

The initial goal was to programmatically send messages of different content types through the carrier to a modern smartphone. The messages would contain images e.g bitmap images,  videos and other content types. The messages would have multiple files of the same content type with different dimensions, various header variables and bits flipped in order to trigger a crash in the stock messaging app or the underlining codec (responsible for decoding the contents). This was the method chosen to fuzz the target with hopes of triggering a crash on the target. Once a crash was achieved, triaging and researching on the crash would hopefully reveal a memory corruption vulnerability. A good resource for this method and scope in practical action is this series posted at Google's Project Zero official blog site. 

However, after successful installation of the module, multiple syntax errors had to be fixed as the module was written more than a decade ago when the code syntax was different. It was soon discovered that import mms  (which is the name of the installed dist-package) was not working and multiple errors of the same type would  render the library practically unusable. Thus, refactoring of the library is necessary in order to be able to achieve the intended goals. However, huge credit is given for the library which teaches one a lot of how the practical aspects of MMS works. In the future, more work i.e refactoring of the library would be conducted in order to achieve full functionality. 

 

Conclusion

At first glance, it seems like a trivial task to get full functionality i.e sending an MMS using a huawei GSM Modem Dongle. However, after thorough research and further insight on other tools, libraries and programs (like NowSMS) to achieve this, it appears to be counter-intuitive to try and achieve this with open-source tools and a cheap huawei GSM dongle.

However, thorough knowledge of the protocol's inner workings has been achieved. 

For future reference, one can also look at kannel as the project is described as the most used SMS and WAP gateway. This might be more preferential instead of configuring the modem to connect to the carrier's WAP gateway using a Huawei GSM Modem Dongle. 

Furthermore, one has to find out whether the carrier has a firewall that will block the requests and how to counter the firewall. Recommended baseline security controls and recommendations are provided for Mobile Network Operators in this document by GSMA.

However, from a BlackHat presentation about the StageFright exploit, it seems possible to send an MMS without a carrier by modifying your device APN settings and hosting your own MMSC server (Pg 84 - 85). Thus, in the future, proper implementation of the recommendations in the presentation will be used if sending an MMS through a carrier becomes unfeasible.