Can hacks become hackers? What I learned exploiting websites with pros

http://www.theguardian.com/technology/2014/oct/16/hackers-exploiting-websites-security-journalists

Version 0 of 1.

It’s a myth that has been perpetuated since the early days of hacktivist crews Anonymous and LulzSec: hardcore hacking is now as simple as downloading some software and clicking a few buttons.

As a hack who has covered the hacker world for some years, your reporter felt it was time to find out whether that myth is true: to get dirty and learn about the more intricate parts of what the pros and hardened cyber criminals do day in, day out.

At the end of it, I’d know how to crack Wi-Fi, have websites cough up their databases and break into people’s online accounts, all without breaking the law. It was a quietly thrilling experience. And yet I’d come away feeling somewhat inadequate, having silently marvelled at the technical aptitude of my humble tutors.

Is hardcore hacking easy now? There’s a modicum of truth to this. After two days on site with some professional hackers, it was apparent that simple tricks could be picked up quickly by the average computer user.

But acquiring real understanding of software vulnerabilities and how to exploit them would take more than 16 hours solid learning. It didn’t take long to realise security can be hard for those who deal largely in abstractions or operate at one remove from the action they believe themselves to be part of (yes, journalists included).

It had all started so well, with high-level concepts that I was already au fait with. Thomas Mackenzie, a Leeds United-obsessed pro hacker (or ethical hacker, or whitehat, or penetration tester – take your pick) from security consultancy NCC Group, took to the whiteboard to do a refresher on HTTP requests and responses.

These form the unseen, underlying way browsing the internet works. Within them are request methods, of which the two most common are GET and POST. There are various differences between the two, but at the most basic level, GET sees data requested from a specified source, whereas POST submits data to be processed.

Where websites contain vulnerabilities, it’s possible to mess with these requests and the client-server model in general to crack open websites and raid them of all their digital goodies.

This is where BurpSuite, the most fundamental tool for any web hacker, be they benevolent or sinister, comes into play. Burp intercepts communications between the PC, tablet or whatever client device is being used and the server, so penetration testers can tamper with the data being sent back and forth to see what breaks.

It has a handy tool called Repeater, which can take a request stored in history and replay it over and over until the user has uncovered some hidden weakness in the site they’re playing with (it soon becomes apparent that much of a penetration tester’s work involves lots of trial and error, many highly educated guesses and constant cat and mouse shenanigans … though they get paid rather well, either through their wage or the rewards they receive for finding bugs. Mackenzie tells of one that earned him a cool £15,000).

After a primer on Burp, we had our first practical lesson. I’d already set up a virtual machine (an operating system within an operating system) running Kali Linux – the de facto OS of penetration testers. There are a host of tutorials online that show how to get hold of both those software products.

Next we had to find a suitable target, one that wouldn’t call the lawyers as soon as we started doing bad things. For any wannabe hacker, there are myriad free testing platforms on which to try out attacks, one of which does exactly what it says on the tin: Damn Vulnerable Web App, which Mackenzie has contributed to in the past and was created by his old whitehat buddy Ryan Dewhurst. It has three difficulty settings: low, medium and hard. Obviously, we went with the lowest.

With Mackenzie and colleague Perran Hill, we’d try to break the site using a technique known as SQL injection, one of the most common attacks used by crooks today. This involves finding an area of the site where users can enter information, such as a login form, or a form to collect a user’s details, that the web server then checks against a type of database generically known as SQL. The aim is to trick the site into coughing up all the information from that database.

The SQL injection task for the Damn Vulnerable Web App simply presents a user ID box. From this alone I’m tasked with finding a vulnerability. To start, I’m told to enter anything. I enter 1. This returns some information on the screen, telling me user 1 is the admin. Nothing more.

Some very basic knowledge of SQL’s workings now comes in handy. When I typed in 1, the website took that input as its parameter and asked the database to select all users where the name was 1. Ultimately, I wanted the database to accept parameters it shouldn’t and reveal more about what it contained. “You need something that is syntactically correct but not what it’s designed to do,” Hill says.

To figure out what was correct, I’d have to find out what was wrong. I started by adding an apostrophe after the 1. This returned an error – good news for the hacker as errors often provide useful information about the target system. I then added another apostrophe. No error. It had simply negated the odd use of the previous apostrophe, or “rebalanced” it, as my tutors put it. This was done in order to “break out” of the expected syntax to determine how the database was working.

One typical tactic is to send the website a true statement such as 1=1. Typing something like “‘Thomas’ or 1=1 --” would ask the database to return users called Thomas or everything else. (Take note that typing this kind of code into websites can cause things to break, so don’t try this at home. In fact, don’t try any of these techniques on sites you haven’t got permission to abuse.)

If it offered up more information, this would likely indicate a vulnerability. Rather than go down the path of manually exploiting the bug, entering more SQL syntax and overloading my tiny mind palace, we chose to run the infamous sqlmap tool in Kali Linux against the database. This would automatically find and exploit weaknesses from which we could extract data.

Having navigated my way to certain areas of the Damn Vulnerable Web App and some internal NCC testing sites, launching sqlmap at various pieces of them I’d copied into a file, I finally launched an exploit against a database and retrieved some passwords.

All were protected by a hash – a one-way cryptographic function for turning text into unreadable nonsense. But the plain text for some of them could easily be found by simply copy and pasting them into Google, as they’d already been cracked in previous breaches. For the rest, it was time to turn to password cracker John (that’s the name of the tool, not another one of NCC’s security boffs).

It’s an incredibly basic password cracking tool that simply guesses at credentials, running a dictionary of passwords as fast as it can through the relevant hashing algorithm and comparing them to the hashes provided. Though this is done thousands of times a second, it’s still slow when compared to more advanced tools.

This is why John won’t break really strong passwords – ones with plenty of letters, characters, special characters and numbers – in any short period of time. You need extreme computer power to carry out enough guesses (known as brute forcing) to crack really good passwords.

That means buying a load of high-powered processor units, or just renting someone else’s systems for as little as $2 an hour, as with Project Mars, run by security firm Praetorian.

John didn’t get the job done for me. And by that time, with my brain suitably drained, it was the end of day one. SQL injection nailed. Sort of.

Day two would be entirely hands-on. We started with cross-site scripting (XSS), which, for whatever reason, I was rather adept at. Though the praise was too high for a novice, Mackenzie even described me as an “XSS master”. XSS is, alongside SQL injection, one of the most prevalent forms of attack on the internet today. It sees the attacker place rogue JavaScript code on a website in the hope it will be executed by the user’s browser. That code will attempt to steal digital things from the browser, such as session cookies, which would grant the attacker access to accounts the victim has logged into, and send them on to the hacker’s own computer.

Again, we moved to a mock site where I was tasked with passing different levels. The ultimate aim was to get hold of one of those tasty cookies. The final level I attempted was the trickiest. We were presented with a plain site and a link that pointed to a chat area, where a lady called Joanne asked us if we needed help. She soon would …

We had to get her to execute our bad code, which would involve having her machine enter a value into the chat form and click on the submit button. This involved slightly more complex JavaScript than the standard “<script>alert(1)</script>”, which is what hackers often try first to see if a vulnerability is present.

Code such as ”document.getelementbyid(chat).value=Thomas” forced Joanne’s machine to write out Thomas in the chat area and then ”document.GetElementById(chatsubmit).submit.click()” would submit that message.

Adding the document.cookie command had her hand over her session cookie. Though we didn’t get round to it, we could easily have added a ”document.location” piece of code to push the cookie to our own IP address.

Next up was Wi-Fi. Hill had lovingly ripped apart an old router with shoddy encryption so we could easily hack it (though I was largely a spectator). For this, we’d need a USB Wi-Fi card (we used an Alfa card with the RTL8187 chipset). This would be put into monitor mode so we could start passively monitoring the airwaves for local Wi-Fi signals.

Various channels popped up. We would select the one using a broken encryption standard known as WEP, known to be exploitable as it leaks information about the cryptographic keys it uses.

Essentially, the key can be derived from the datastream produced by all the different connections going through the router – the more data we collected from the network, the easier it would be to break the encryption. To gather that information, we entered ”airodump-ng --encrypt WEP –channel 11 –w <filename> --ics”. It was then simply a matter of waiting and collecting the packets from the air.

Once we had enough information (in this case around 10,000 packets), we saved it all in a file and ran it through aircrack. This would give us the password used to “secure” the WEP Wi-Fi access point.

Finally, we looked at scanning an internal corporate network, using the nmap tool, another critical weapon in a hardcore hacker’s arsenal. First, my masters gave me a recap of how standard TCP/IP communications worked using the so-called “three-way handshake”. First the computer would send a SYN notification to a server, which would respond with a SYNACK. Finally, there would be an ACK from the computer.

In nmap, it’s possible to probe numerous remote ports – which allow for machines located anywhere to speak with each other via ”sockets” – by replicating these connection attempts. With a simple ”-sT” command in the interface and a set of IP addresses, this will reveal which ports accept outside interaction and are therefore potential targets. It’s possible to specify which ports you want to scan too, using a command such as ”-p1”.

Scans can be far more aggressive, however. The ”-A” option within nmap throws a bunch of protocol specific queries at a target port, from brute forcing of passwords to reporting back vulnerabilities, running services and detailed version numbers. This can then all be recorded to file for possible future attacks with the ”-oA” command. I could do all this for any machine connected to the web. Ah, the power!

Day two was done and the attempt at learning to be a hacker in an infinitesimal amount of time – in comparison to the years professionals spend honing their skills – was done. I had finally got into the nitty-gritty of all the tools and techniques I had understood but never seen put into action firsthand.

It really was possible to pick up some high-level hacking skills in a very short period of time, meaning anyone could do it, with the right resources to hand. This all comes with its positive and negative connotations. Those skills could easily be put to criminal use. It depends entirely on the scrupulousness of those with the knowledge.

Yet it was apparent there was a vast amount I didn’t know. Though I could carry out a handful of attacks, I wasn’t sure of precisely what my actions were doing to the underlying systems. It felt wrong somehow.

On the walk back through the monotonous suburbia of Leatherhead towards a London-bound train, I was at once elated and deflated. Despite being riddled with anxiety over the purpose of a humanities-led education, when software development or anything computer science-related would have given me a more propitious start in working life, I left my masters not completely bereft of hope.

There was one significant reason not to get overwhelmed by inferiority: there was so much left to learn.