In Depth: Learn from the hackers: how to avoid website exploits

When large data breaches are announced, the media can go overboard with its portrayal of hackers as uber-geeks with flashing fingers and skills that are almost supernatural in origin. In fact, nothing could be further from the truth.
By using basic tools and a logical approach, hackers turn websites into playgrounds full of interesting servers to explore, subvert and destroy. There are databases to plunder; there are pages to deface.
But just what is their approach, and how can we learn to avoid it?
Footprints on the web
Once a hacker finds a website that could be worth exploring, their first task is to create a detailed profile of the target, called a footprint. This identifies the basic building blocks of the site and enables the hacker to draw a map of how everything fits together.
Unfortunately, the way websites work provides hackers with lots of useful information without them having to do much. If there's a login process, for example, they know there's a database containing usernames and passwords. If the site has an ecommerce element, they know there's a shopping cart product in use, or some handcrafted and potentially vulnerable code to try to subvert.
Similarly, a catalogue of products indicates another database, which could link to a stock control server and possibly also a re-ordering application containing information about trade accounts. The hacker will also survey links to ad servers that feed content into the site. They will also consult the DNS records for the domain.
DNS is the only way to keep track of what's on the internet and where it all is. But it also gives information about all the publicly accessible servers owned by a domain, regardless of whether their addresses and names are meant for public consumption.
When I began working as a network security consultant, I found that it was easy to shock clients by showing them their DNS records, and then drawing a map of how I believed their servers were plumbed together. Some network admins had been naïve enough to think that all their important servers needed public IP addresses, making them easy to profile prior to an attack.
DNS information
Windows and Linux have tools capable of interrogating DNS, but they're fiddly command line utilities. Luckily, plenty of websites provide easy access to DNS information, including Kloth.net. Enter the name of a domain you're interested in (such as pcplus.co.uk) and press [Enter]. In the answers section that appears, you'll see lines containing the domain name and associated IP addresses.

To search for a possible web server, add www. to the start of the domain and press [Enter]. This time you'll see the domain's web server. If you change the query type to 'MX' and click 'Look it up', the answers section will contain the name of the computer acting as the local mail server (technically called the mail exchanger).
This name may be the same as the web server, but if it has a different name, enter it into the 'Domain' input box to see its details.
Another important part of this process is the use of a port scanner such as nmap to discover what services are running on each internet-facing server. See nmap in action at www.nmap-online.com. The default IP address is your own computer.

To scan it for open ports, click the 'I agree with terms of service' and then click 'Scan now'. Enter an email address for the site to notify when the scan is complete, along with a password to access the results.
Nmap sends carefully crafted packets to each potentially open port and analyses the information returned to discover not only what's running, but sometimes even detailed information about the running operating system and its TCP/IP stack. This can aid hackers in profiling a website and formulating a coming attack.
If a mail server is also running port 80, there's a good chance that connecting to it via a web browser will reveal a web mail interface that may have exploitable bugs. However, if the hacker is met by a default Apache web server installation page, it may be that system administrator installed the web server but has forgotten about it. It's likely that the software has never been patched and is vulnerable to a range of exploits.
By examining the verbiage returned with the web page, the hacker can determine the exact release of the software and any extra modules installed. Finding a NetBIOS service running (ports 137 and 139) indicates that the server runs Windows. An SQL service (port 1143) indicates that there's a database engine running, and so on.

It's possible to build a detailed map of a domain's capabilities and vulnerabilities from this process.
Once the hacker has constructed a detailed footprint of the website's hardware and basic software, their attention turns to the web applications. Computer science says that above a certain level of complexity, no program can ever be free of bugs. Luckily for the hacker, less skilled programmers keep making the same basic assumptions and mistakes in the logic of web applications.
The first task is to map out how the apps work. The hacker begins with a simple click-through of the site to note the names of the pages and what they contain – which ones need authentication, for example. This tells them a great deal, but they can also delve deeper by mapping out the actual directory structure on the server.
Directory mapping is a matter of noting down the paths in the URL bar of the browser during the click-through. This reveals a lot of detail about the structure of the site, and can give indications about the skill of the web designer. Some structures reveal the hand of a site-builder program at work, in which case a hacker can consult a list of known exploits for sites made with that program.

The hacker notes the methods pages use to pass data from input boxes to PHP scripts. Do they use the GET or POST methods? Each implies the type of processing used by the site's scripts, and may provide ideas about testing for weaknesses in the way rogue input values are dealt with.
The web is set up to serve the index file of any URL you enter, so the hacker will try adding likely directory names to the domain name to see what he can find. For example, for www.victimsite.com, they might try 'www.victimsite.com/admin' to see if they can access an administration page.
Another great source of hidden directories is the 'robots.txt' file. This is a plain text file that sits in the root directory of websites and contains directives to search engines about which directories are OK to index and which aren't. The 'robots.txt' file has to contain a list of all the directories that the hacker shouldn't know about, which highlights the need to avoid putting anything on a site that you wouldn't want to find on Google. Where you can't avoid this, don't give files obvious names.
So-called helper files are also a useful source of information for the hacker. Cascading style sheets, Java classes and embedded JavaScript all give an indication of the skill level of the person who coded the site. This gives an idea of the kinds of errors to expect.
One of the biggest mistakes made in trying to secure a site is to have users validate themselves using JavaScript embedded in the login page. To the developer, the ease of use, compatibility across browsers and speed all seem like benefits, but the advantages are all on the side of the hacker.
The attack begins
The hacker now has a footprint of your site, a list of hidden directories and a map of how the scripts fit together to make up the site's applications. What now?
They have many options to choose from. The simplest is to point a password-cracker at the administrator account and leave it to gain entry for the purposes of stealing information that can be sold on, or to simply deface the site. This childish activity is normally associated with 'script kiddies' – teenagers who consider themselves hackers, but just run scripts developed by others.
Real hackers will begin to explore weaknesses in the services identified as part of the footprint. On discovering an SQL service, for example, they can try connecting a telnet client to the port to gain command line access to the database management system (DBMS). Similarly, FTP and Telnet services are easily attacked using password crackers and by exploiting bugs in their software with buffer overflow attacks that can give command line access to the server.
A more knowledgeable hacker still will try to break or bypass the validation code applied to an input field on a web page to see what happens. Validation code is supposed to take the values of input fields and sanitise them, rejecting data that's clearly wrong.
If an input field is supposed to contain a number, for example, its validation should reject input if it contains anything other than the digits 0-9. If the hacker enters letters and doesn't get an error message, he can tell that the validation code is lacking. If the input field is for a part number, it may form the basis of a query to a back-end SQL database.
That being the case, the hacker will ask what happens if they enter the SQL statement termination symbol (the ' symbol), followed by their own query. If this works, they could then ask the database for a list of tables. If they find ones that store customer details and credit card information, it's game over.

Source.