Computer Vandalism and Hacking
This tutorial will provide some advise on computer vandalism and hacking
Vandals often use hacking techniques to deface a website or destroy data and files, but there are also those who just want to steal resources (make use of other people’s servers without their knowledge or permission) or to cover their tracks by stealthily making use of hardware owned by legitimate businesses to carry out processing for illegal operations or to relay spam and viruses to others.
The best defence against the majority of these types of attacks comes through installing and maintaining the latest versions of anti-virus and firewall software. As new threats are identified, updates are issued which can identify and neutralise most harmful operations before they have a chance to do any damage. Having a server fully managed by a reputable hosting company ensures that these defences are always in place.
Perhaps a more sinister threat is that of “black hat” hackers, or “crackers”. As a general definition, “white hat” hackers are enthusiasts who enjoy learning the intricacies (including weaknesses) of computer systems with no malicious intent, whereas “black hat” hackers are those whose sole purpose is to break into systems and gain access to information and functions to which they are not entitled. The word “hacker” was originally used to refer to the “white hat” variety, whereas “cracker” was used to identify “black hats”. The media have since latched onto the word “hacker” almost exclusively in connection with “black hat” hacking, and this is usually what is understood by the term “hacking” today.
SQL Injection
One popular and potentially devastating method of attack is SQL injection. Any web application that makes use of a database usually communicates with the database for necessary functions using a special language known as Structured Query Language, or SQL. By issuing an SQL command to a database server, the web application can control virtually any aspect of the database – adding, editing, or deleting records or tables of data. Although a powerful tool in the hands of a software developer, SQL can become a lethal weapon in the hands of a hacker.
Of course, the web server would need to be configured in such a way that prevents third parties from issuing SQL commands to the database, whilst allowing legitimate requests from the web application to be processed. The problem arises though where a programmer incorporates user input directly into an SQL command quite a common practise.
For example, a program might want to issue an SQL command such as this:
SELECT * FROM users WHERE first_name = ‘John’
This SQL command would request all of the records from the user table in the database where the first name matches the value supplied (in this case John). In many instances, the value to be matched against will need to come from the text that is entered into a form on the website, so instead of the program explicitly using the value John, it would need to insert the text that was entered by the user perhaps like this (using PHP as the programming language):
SELECT * FROM users WHERE first_name = ‘ . $_POST[‘first_name’] .
In this case, the value from the form (the $_POST[‘first_name’] bit) is inserted directly into the command. This would work fine for normal use, but if a hacker realised how this SQL command was constructed, he could inject his own SQL command and perform any operation he likes on the database.
For example, instead of entering a value like John in the website’s form, he could type something like this:
‘; DROP users;
The single quote mark and semi-colon will cause the original SQL command to end, and then the hacker can type any SQL command he likes to be run afterwards in this case, the command DROP users; would delete the users table from the database completely.
All user input must therefore be carefully validated by the programmer, especially before use in an SQL command, and in particular single quote marks should be either removed or ‘escaped’ – which means they are tagged with a special symbol (or ‘escape character’ – usually a forward slash ‘/’) that lets the database server know that the quote mark is part of the data and not part of the SQL command.
Cross Site Scripting (XSS)
Cross Site Scripting is a hacking technique whereby malicious scripting code (usually javascript) is injected into user input forms (in a similar way to SQL injection attacks) or incorporated in a URL query string. The threat is greatest when the user input is then output in a dynamically generated web page, and especially if the data is displayed as HTML code.
A malicious entry could include a piece of javascript which performs virtually any action on an innocent end-user’s browser (typically a hacker would try to get users to visit the infected page, often by posting links in forums etc), including cookie theft (enabling the hacker to then log in as the other user and access their account), or logging the user’s activity for example recording keystrokes so as to intercept passwords etc.
The methods of counteracting cross site scripting are similar to those of SQL injection all data entry (whether posted in a form or passed in a URL) must be carefully validated to ensure that it does not contain special characters (such as greater than or less than symbols) which could allow scripting code to be embedded in the data. These special characters can be represented in hexadecimal notation as well as plain text, so both need to be checked for by the script. Where special characters are to be legitimately allowed, they must be converted to HTML character codes before being displayed in a web page this prevents them from being interpreted as script by the browser.
Directory Traversal
A website is stored within a file system on a server. Some of the server’s file system is therefore exposed to the outside world and can be accessed by an end-user’s web browser. The part of the file system (or directory structure) that is visible to the outside world is limited to a specific root folder and its contents. Any folders higher up the hierarchy (ie. before you get to the root folder) are theoretically unreachable by the world at large – only authorised users who are logged in on the web server itself can access such folders.
For example, on the actual web server, you might have a directory structure similar to this:
home
username
public_html
images
downloads
private
documents
passwords
In the above example, the public_html folder is the root folder for the website. Anything underneath that folder in the hierarchy can be accessed by a web browser. All of the other folders are not accessible to the world at large because they are not located under the public_html folder.
In a directory traversal attack though, a poorly written script can allow a hacker to access those other folders and read their contents – just using a web browser. This is because a server-side scripting language, such as PHP, runs on the server as though it were a logged-in user – the scripting language has access to all of the folders and files, not just those underneath the root. If a script reads (or outputs the contents of) files on the server as part of its legitimate processing, it must be written in such a way that the files that are used cannot be specified arbitrarily by the end user.
Taking the above directory structure as an example, suppose there was a script on the server that reads the contents of a text file in the public_html folder and outputs it to the screen. If the end user were able to specify the name of the text file to be displayed, the script would need to make sure that the name they entered was still within the public_html folder. If they entered a file name like ‘..privatepasswordspasswordlist.txt’, the two dots at the start would tell the script to move up in the directory structure – effectively breaking out of the website’s root folder – and then the hacker can specify any file path he likes whether within the website’s root or not.
Therefore, where user input is used as the basis of files that are to be read (or more importantly, output) by a dynamic web page, the script must include a validation routine that ensures that the value entered by the user is legitimate and does not allow the directory structure to be traversed.
Denial of Service Attacks (DOS, DDOS)
A denial of service attack takes place when a hacker overloads a system with large or repeated requests for a service. For example, where a script requires some intensive processing on the server, if lots of requests are received at the same time, this can cause the server to slow down to such an extent that legitimate requests from others cannot be processed. In some instances, a denial of service attack can cause the server to crash completely.
In an effort to prevent denial of service attacks, many scripts which require intensive processing will only allow a single request from any one user (for example, by checking the IP address of the source of the request, and only allowing one request from that IP address within a certain time period). However, distributed denial of service attacks (DDOS) involve a hacker impersonating hundreds or even thousands of different users in such a way that the script cannot tell whether the requests are legitimate or not.
DDOS attacks are very difficult to prevent, but they can also be very difficult to carry out – the effort involved in executing such an attack without being traced means that in most cases it is not a worthwhile excercise from the hackers point of view; they would prefer to use easier methods of attack. If a server has strong defences in other areas though, and an attacker has a strong grudge against a company, a DDOS attack becomes more likely. For this reason, it is usually large corporations and financial institutions who suffer from these attacks.
HTTP Sniffing
HTTP stands for HyperText Transfer Protocol, and it is the mechanism used to transfer data from one computer to another across the internet. You can use HTTP to request information from a server, or to send information to a client by wrapping the request or data in a packet.
An HTTP packet consists of a header section which identifies the purpose of the packet (eg. to request a file), the destination (eg. the address of the website the file is being requested from), the format of the request (eg. what type of encoding is used in the main text of the packet), and whether the packet is in one part or has been split up and sent as separate parts (so the server can collect all of the parts it needs before dealing with the request), among other things.
Usually, HTTP packets wing their way across the internet from one machine to another without any human intervention, and without anyone seeing what the packets contain. However, the data in an HTTP packet is usually just plain text it is not encrypted in any way and can easily be intercepted, read, and even changed en-route by anybody with the appropriate software and technical skill.
The programs used to intercept HTTP requests are known as HTTP sniffers and they are often used to sniff out important information that can be used maliciously (there are also legitimate uses for HTTP sniffers for example, they can be useful in debugging applications that rely on the transfer of HTTP packets). Any data sent over plain HTTP is therefore susceptible to interception, and must be presumed insecure.
For this reason, any sensitive data that must be transferred from one machine to another on the internet should not be sent as a plain HTTP packet. This includes login screens, and forms that collect sensitive personal information such as credit card details. In these instances it is usually best to use HTTPS.
HTTPS is very similar to HTTP; it’s just that the data in the packet is encrypted. So even if someone uses as HTTP sniffer, they will not be able to read any of the data without a special key and that key is held securely on the receiving computer. If a hacker tries to change the data, this will be detected by the receiving machine, because it will no longer be able to decrypt the package.
Other Tactics
There are numerous other tactics that can be used to break into a computer system, and these usually involve discovering weaknesses or loopholes in the server software’s defences. When a programmer writes software that runs on a web server, he tries to make sure that the software cannot be abused but it can be very difficult to foresee every eventuality; vandals and hackers are always pushing software to the limit and trying out operations which the software was not designed to handle, in an attempt to discover a way in.
Usually, hackers practise using a copy of the software on their own server so that they can try out different tactics without getting caught when they find something that works, they can then use it on other people’s servers. For this reason, it is often well-established server software that is the focus of the attack, rather than proprietary scripts written for a specific site.
Manufacturers and vendors of software packages for web servers often advise on configuration recommendations which will negate common attack tactics, but sometimes even the manufacturers are unaware of, or don’t bother warning about a loophole which can easily be exploited. For example, sometimes the default configuration options are geared towards making the software easy to use and powerful rather than secure.
Installation log files, release notes, welcome screens, and various other files which are generally just ignored by server administrators can be the source of valuable information for a hacker. For example, just knowing which version of operating system your server runs can allow a hacker to exploit a known weakness in that particular version. If he cannot find out what version you are using, he risks being caught if he just tries out an exploit on the off-chance that it will be successful. It is therefore important to make the hacker’s job as difficult as possible by obscuring any information that could be used to identify what software and versions the server is using.
