Monday, 29 August 2011

Setting up Nessus in Backtrack 5 R1

In an earlier post I described how to setup Nessus on Backtrack 5:

For some reason, BT 5 R1 does not come with Nessus installed by default, but it's easy to download and install.

You will need to download Nessus from the following location:

(I used the Debian 64 bit package)

Then install it with the following command:

dpkg -i Nessus-4.4.1-debian5_amd64.deb

Then you can simply follow the rest of the instructions in my original post.

Update - Of course, there is an easier way to do this ;o)

apt-get install nessus

Sunday, 28 August 2011

How good is your browser security?

So, if you are reading this blog, you are probably interested in IT security (or insecurity, otherwise you are in the wrong place).

Is your browser secure?

This is a great resource for testing browser security:

Run the above test on each of the browsers on your system (IE, Firefox, Chrome etc)

If all is well you should get a screen which looks something like this:


If you get a red bar, you are not up-to-date, and probably not fully secure for browsing. If this is the case then I recommend you should to follow the on-screen instructions to get this fixed.

I would be interested to see how many people pass on the first attempt, and what measures others needed to take to get up-to-date.

For me, I run Backtrack 5 R1 (Linux), I needed to update Firefox, and the flash-plugin.

I have added explanations of how to upgrade to Firefox 6.x and also update the Flash plugin in my "Backtrack 5 R1 notes" at the following location:

I recommend anyone who is using Backtrack 5 R1 to apply the updates to help make their system more secure.

I also run chrome on this system, and my chrome status looks like this (Shockwave Flash 11.0 is currently pre-release)

Thursday, 25 August 2011

GIAC Web Application Penetration Tester (GWAPT)

I took and passed the GIAC Web Application Penetration Tester (GWAPT) exam today, so I thought I would write something about it (and the SANS course that supports it).

The SANS "Web Application Penetration Testing and Ethical Hacking" course coverage

I had taken the SANS "on-demand" online version of their Web Application Penetration Testing course. I felt the online version of the course is a great format, because it gives you plenty of time to absorb the material and experiment in your own time.

I had previously read the excellent book Web Application Hackers Handbook (which I would highly recommend, before considering the SANS course). There were a few key things on the SANS course that are not covered in that book (and vice versa)

On reflection, this course covers quite a lot of ground. It has the basics of various common attack vectors (such as SQL injection and XSS) but it goes beyond the norm in some areas (though some other attacks and detail seem to be missing).

Additionally to what is covered in the WAHH book, the SANS course covers subject areas such as:

Decomposition and basic analysis of Java applets and Flash objects
Understanding AJAX
Various tools for spidering, and Web app vulnerability scanning
Exploitation frameworks

Most notably, the SANS course covers the basics of a lot of different tools for web-app security testing, including:

Burpsuite, Webscarab, Paros, Dirbuster, Skipfish, W3af, Tamperdata, SQLinjectMe, Sqlmap, Grendel-scan, Nikto, Aura, SiteDigger, Wikto, Goolag Scanner, Maltego, Nmap,  HTTPrint,  OpenSSL, THC SSL Check, CeWL, SprAJAX, RatProxy, WebService Studio, WSDigger, WSFuzzer, Flare, HP SWFscan, SWFIntruder, JAD, Websecurify, XSS Me, GreaseMonkey, XSS Assistant, PostInterpreter, Absinthe, MonkeyFist, BeEF, Dursosploit, AttackAPI

This is a lot of coverage, though obviously in many cases we are talking about the bare minimum of one slide of notes per tool (you will need to do a lot of your own practice and research to get to know these tools properly).

Though I didn't feel the SANS audio track was as good as it could have been, the course notes and lab examples are good (if you complete them all a couple of times, and do some extra experimentation).

In addition, I did a lot of my own testing with the Web Security Dojo, and some Virtual Appliance UI research in my home lab - which I feel helped me a lot with understanding how to use some of the tools more effectively.

Notes for GWAPT test-takers

This is an open-book exam, which was a new thing for me. I would definitely recommend test-takers to study the SANS course thouroughly, and take there course material with them, because the exam sticks very closely to the SANS course material.

Also, make sure you know which information is in which section of the course material, i.e. know where you would find information on SQL injection syntax, or PHP functions, or HTTP response codes (as examples).

In terms of practice, the certification exam is similar to (but not as easy as) the example tests provided by GIAC. I would also recommend reading the course material a couple of times, completing all the course practicals, and doing extra practice with the tools, such as completing the Web Security Dojo (or Web Goat at the very least).

Tuesday, 23 August 2011

Backtrack 5 R1 - Some things fixed, some things broken + workarounds

Sometimes installing the latest releases is a good thing. You get to learn lots of new technology, and improve your understanding and troubleshooting skills at the same time.

However, there is a cost in time, tweaking and fixing things, and learning new ways to do the same things you used to do. Today Backtrack 5 R1 is only 3 days after release, so there are bound to be some issues.

Pluses and minuses

Some things seem to work a lot better (for example I had none of my usual issues with graphics drivers, that I often get during a Backtrack install)

However, some tools that were previously working fine seem to be broken (at least on the BT5 R1 KDE 64-bit version that I am currently looking at).

Problems I have seen so far (and workarounds/fixes):

Wireshark not working

Wireshark won't run - I got the following error:

wireshark: error while loading shared libraries: cannot open shared object file: No such file or director

The Backtrack development team are aware of this, and currently in the process of developing a fix.

Fix = Rebuild wireshark from source

Workaround = Copy the following files, which fixes the problem:

cp /usr/local/lib/ /usr/lib/
cp /usr/local/lib/ /usr/lib/

Nessus is missing

Fix = Follow the instructions to download and install it here:

VMware Player not working

VMware Player will install, but not compile and run - with the following errors in "/tmp/vmware-root/setup-*.log":

Failed to compile module vmmon

This is pretty essential for my home lab - probably more an issue that VMware need to fix, to make VMware Player work with the latest Linux Kernel.

Workaround = Use Oracle VirtualBox

Download the "Ubuntu 10.04 LTS" version from here:

Run the following command to install it:

dpkg -i virtualbox-4.1_4.1.2-73507~Ubuntu~lucid_amd64.deb

If you already have VMware VMs, make a copy of these, and for each - in VirtualBox, add new machines, and select the *.vmdk files when you come to add the disk.

This seems to work pretty well, and has more or less the same features as VMware Player.

(Guess which VM is the victim ;o)

Workaround2 = See comment from Anonymous below (untested at this time)

Grendel-scan not working

Grendel-scan throws the following Java exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3349 or swt-gtk in swt.library.path, java.library.path or the jar file

TBD - I guess I can get along without this for a while.

Mozilla Firefox not up-to-date

Firefox is not the latest version (which could potentially be a security risk).

Fix = Run the firefox built-in updater (to upgrade to Firefox 6.x)

  • In firefox, go to Help > About
  • Click on "Check for updates"
  • Click on "Apply updates"
  • Follow the instructions (this will require a restart of firefox)
  • Follow the instructions to update the version of no-script

Installing flash player for Chrome and Firefox

Flash plugins are missing for Chrome and Firefox.

Workaround = Add the executable in the correct directories

First download the kits at the following locations:

Close both Chrome and Firefox and then do the following:

cd ~/Download
tar xvfz  flashplayer11_b2_install_lin_64_080811.tar.gz
chown root:root
chmod 0644
cp -f /usr/lib/mozilla/plugins/
rm -rf

tar xvfz install_flash_player_10_linux.tar.gz
mkdir ~/.mozilla/plugins
chown root:root
chmod 0644
mv -f ~/.mozilla/plugins/

Restart the browsers and this should fix it

Crash issue

I did have an issue where I think it went into screen-save mode where the system seemed to go into a graphics-card test screen and completely lock-up (?! not sure on this one).

Not seen this since

Suspend to disk causes failure to boot

Yeah, this one is not much fun, seems persistent and I'm currently troubleshooting it... Hangs on red BT5 boot-loader screen.

Workaround = Not sure, I re-installed my system, and have not seen the issue since. Weird.

(I will add issues and workarounds as I find them in this post)

Monday, 22 August 2011

Using Hydra to dictionary-attack web-based login forms

Hydra is a online password cracking tool which can be used to dictionary-attack various services by trying lists of user-names and passwords until a successful login is found. It is multi-threaded, and can be very fast, trying username/password combinations at a rate of thousands per minute.

Hydra can be used to attack many different services including IMAP, SMB, HTTP, VNC, MS-SQL MySQL, SMTP, SSH, and many more.

(Hydra is to online-cracking of passwords, what John The Ripper is to offline-cracking of password hashes)

Often, web-based login forms authenticate using the HTTP POST method, but judging from several blogs I have read on this subject, it sounds like some people have great difficulty in getting Hydra to work effectively in this situation.

I have had a great deal of success with hydra, so here I describe how to get Hydra working with web-based form logins.

This attack is not limited to websites, and I would argue that it is more suited for gaining login access to software products that have a web UI, for example in penetration tests.

This tool should not be used to attack websites or services where you do not have permission to do so. Use this for legitimate testing purposes only.

Some differences between online and off-line password cracking

There are significant differences between online and off-line password cracking.

With off-line cracking, you have the hashes on your system, they are static, and you can try dictionary, hybrid, and brute force attacks to you hearts content. You have as long as you want, and you can try many billions of attempts in a short space of time.

The attack success is purely dependent on password strength, verses processor-power and time (and few user-chosen passwords will be strong enough to last).

With online password attacks there are more issues to consider, such as; network bandwidth, account lockouts, tar-pitting, changing passwords, detection in logs and IDS.

Online attacks are more suited to relatively small and focused dictionary attacks rather than exhaustive brute-force.

A simple Hydra SSH example

Here is a simple example of running a Hydra attack against an SSH server.

hydra ssh2 -s 22 -P pass.txt -L users.txt -e ns -t 10

This will attack the system, on port 22 with the SSH protocol, 10 threads at a time, and try all the combinations of usernames and passwords supplied in the files user.txt and pass.txt (+ empty passwords and passwords the same as the username)

This can take a while, so it is best to only use usernames you know exist, and a relatively small list of passwords (many thousands rather than many millions). This attack generally works very well for simple dictionary passwords.

Web-based login forms prerequisites

For web-based forms, you have to know much more information about the form you are attacking before you start the attack. Every web-based form is slightly different, different URLs and parameters, and different responses for success or failure.

You need to know:
  • The hostname/IP and URL
  • Whether it is a HTTPS or HTTP service
  • Whether the form supports GET or POST (or both)
  • The parameters of the request
  • The difference in response between success and failure
  • Whether any session cookies are required to be set or maintained
  • What lockout features and thresholds are enabled (if any)
Not knowing or understanding the above information can be a big cause of failure.

For the parameters of the request, you can intercept and examine a normal login attempt with a web proxy (such as owasp-zap, webscarab or burpsuite) or use a browser plugin (such as tamperdata) or just look at the HTML form.

An example attack

The Web Security Dojo VM has various vulnerable applications that you can use to test these techniques. So looking at an example the w3af testing framework has a test login at the following location

The important parts of the HTML form are:

<form name="input" action="dataReceptor.php" method="post">
<input type="text" name="user">

<input type="password" name="pass">

If we put in one wrong username and password combination we get:

Bad login, stop bruteforcing me!Bad u/p combination for user: a

So, now we have the information we need to attack this login form, we can use this info to construct a Hydra brute-force attack as follows:

hydra http-form-post "/w3af/bruteforce/form_login/dataReceptor.php:user=^USER^&pass=^PASS^:Bad login" -L users.txt -P pass.txt -t 10 -w 30 -o hydra-http-post-attack.txt

If we break this up

Host =
Method = http-form-post
URL = /w3af/bruteforce/form_login/dataReceptor.php
Form parameters = user=^USER^&pass=^PASS^
Failure response = Bad login
Users file = users.txt
Password file = pass.txt
Threads = -t 10
Wait for timeout = -w 30
Output file = -o hydra-http-post-attack.txt

Hydra basically iterates through all the username/password combinations, until it gets a response that does not contain the text "Bad login". When we run this attack we get:

Hydra v6.5 (c) 2011 by van Hauser / THC and David Maciejak - use allowed only for legal purposes.
Hydra ( starting at 2011-08-22 13:11:03
[DATA] 5 tasks, 1 servers, 5 login tries (l:5/p:1), ~1 tries per task
[DATA] attacking service http-post-form on port 80
[STATUS] attack finished for (waiting for children to finish)
[80][www-form] host:   login: admin   password: 1234
Hydra ( finished at 2011-08-22 13:11:07

As you can see, this was successful and found the user "admin" with password "1234".

Other examples

HTTPS forms can be brute-forced in exactly the same way by changing the method to "https-form-post".

Similarly there are the GET equivalents, of "http-get-form" and "https-get-form", though this type of method is really not recommended for web-based login forms (due to confidential information being passed in the URL, which can appear in proxy-logs, and browser history). Some forms do exist out there that use this.

Sometimes you need to look for text that appears meaning "success" rather than the absence of text meaning "failure". This can be done if you put "S=" in front of the failure string variable, it becomes a success string check, for example


Remember that the "failure" or "success" string does not have to be part of the HTML of the page. These strings could be information in the response headers, such as cookies being set, or locations of redirects. There are flexible options for dealing with pretty much any type of response, as long as it is repeatable, and there are distinct differences between success and failure.

Other more complex examples may be where you need to specify particular header values, or use an additional page to obtain set browser cookies before the form is submitted. These can be done by adding the additional parameters "C=" and "H=" on the end:

"/foo.php:user=^USER^&pass=^PASS^:S=success:C=/page/cookie:H=X-Foo: Foo"

All in all, this is a pretty straight forward, and a very effective tool, as long as you understand how the form is working, and what parameters are required, before you start the attack.

Sunday, 21 August 2011

A few other tips for Backtrack 5 graphics drivers issues, and software installs

Having rebuilt my main BT5 laptop again today, here are some tips I can share for anyone else who has the same needs (and to hopefully this will help make it quicker for me if I want to rebuild the same setup again)

I already made some suggestions for my Desktop system (when I installed that with Backtrack 5) but that covered Nvidia graphics drivers, and other software installs:

I'm currently using BT5 KDE 64-bit on a Dell Inspiron 17R 7010 - This has a nice big screen, which is useful for virtual hosts etc...

Anyway, the reason for the rebuild was that; initially a kernel update ( stopped various packages from working. So I thought I would try out BT5 R1 KDE 64-bit, but then after an abortive install of R1, I've gone back to my previous stable setup (I haven't got to the bottom of the kernel and R1 issues yet, maybe more on that next time)

So, after a standard install of BT5...

Intel graphics drivers

My laptop has Intel graphics drivers and initially "startx" would result in a black screen, and lockup with no errors. I got a solution previously speaking to some of the folks on the #backtrack-linux IRC channel a while back (I couldn't remember it exactly, but I figured it out for myself this time, but thanks to a_landim_xhkl and _ope_ for the original feedback).

A basic way to get the Intel graphics driver working is to reconfigure /boot/grub/grub.cfg , but this needs to be done via the template files and grub config builder.

You need to edit the file /etc/default/grub and added the Intel option (back it up first)

cp /etc/default/grub /etc/default/grub.old

... then edit the following line adding the options in red:

GRUB_CMDLINE_LINUX="text splash vga=791 i915.modeset=1"

Then rebuild the grub config and reboot:

grub-mkconfig -o /boot/grub/grub.cfg
init 6

The BT5 KDE 64-bit gotcha

We're not out of the woods yet for KDE, but this one has been mentioned over and over in various places - this is the known issue where KDE crashes out after the first Chinese symbol on the red starting screen.

If you are using BT5 KDE 64-bit you will likely need to do the following before you can run startx

rm /root/.kde/cache-root/icon-cache.kcache
rm /root/.kde/cache-root/plasma_theme_Volatile.kcache
rm /root/.kde/cache-bt/icon-cache.kcache
rm /root/.kde/cache-bt/plasma_theme_Volatile.kcache
rm -rf /var/tmp/kdecache-root

After that KDE starts fine, now to install some extra stuff...

Installing and running VMware Player

Download VMware Player

Then you need the kernel sources in order to install and run VMware Player. Run the following (and go do something else while it does it's thing)


Then run the install, and this should work fine


Installing and running Google Chrome

Download the latest 64 bit Google Chrome build and then do:

dpkg -i ./google-chrome-stable_current_amd64.deb

You may get a complaint about running this as root, so either create an account for browsing, or start the browser with the following command

/opt/google/chrome/google-chrome %U --user-data-dir

(I've seen some ridiculously complex suggested ways of doing this, such as hex-editing binaries, the above seems like the easiest by far)

You can either run this from the command line, or easier still, change the shortcut command to the above. This works very well as of Chrome version 13.0.782.215.