Understand Vandalism and Hacking – Open source CMS

The information provided in this blog is to guide and educate the module developers of open source php applications like xoops, joomla and mambo so that they can maintain an inflexible layer of security in their respective modules. I have been reading a lot about anti hacking techniques and network security stuff since my graduation, So here is something, I would like to share with you.

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 peoples’ 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 cracker.

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 ‘users’ 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. (In actual fact, this would be unlikely to work with a Joomla or Mambo site, as only a single query can be run at a time in most cases. However, other variations, such as adding a UNION statement to the SQL would allow a hacker to read information from your database).

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 backslash ‘\’) that lets the database server know that the quote mark is part of the data and not part of the SQL command. Also, where data is expected to be numeric, it is important to ensure that the value really is numeric before including it in an SQL statement (as quotes are not required for numeric data, so even if the input is ‘escaped’, injection could still occur if the data was not validated).

Remote File Inclusion

One of the most common types of attack against web applications written in PHP (including Mambo, Joomla, Xoops,  components, templates, etc.) is remote file inclusion. Most PHP applications are divided up into a number of files. When the application runs, only those files that are actually needed to perform the requested operation are loaded into memory – thus saving server resources. Different operations may require different files to be loaded or ‘included’ (the command that loads a file is called ‘include’ in PHP).

This is fine as long as the programmer can be absolutely certain that only those files (s)he wants to load are actually loaded. Often, the path to the file that is needed is not ‘hard-coded’ or typed explicitly into the program – because the programmer often does not know exactly where the program is going to be installed. Thus, the path to the files is often held in a variable. In certain circumstances, a cracker can cause the program to include a file of his own instead of the one the programmer wanted to include.

This type of attack would typically happen only if PHP is configured so that both ‘register_globals’ and ‘allow_url_fopen’ are switched on. For example, if the code in a Joomla component file looked like this:

<?php
global $mosConfig_absolute_path;
include($mosConfig_absolute_path . “/my_file.php”);
?>

…a cracker could call that file directly in a browser (even if requests for the file normally go through Joomla’s index.php, there is nothing stopping a cracker from going straight to the file in question), and add something like “&mosConfig_absolute_path=http://www.mycrackingsite.com” to the URL. If the server has register globals switched on, the domain name entered by the cracker will be stored in the $mosConfig_absolute_path variable. So instead of including a local file, a file with the same name on the cracker’s own website is included (note: a remote file can only be included if allow_url_fopen is switched on, otherwise PHP restricts inclusion to files on the local server).

Once a remote file has been included, the cracker has full access to your website and can do virtually anything they like to it.

In order to protect against this type of attack, firstly of course you should ensure that if at all possible, your server has register_globals and allow_url_include (or allow_url_fopen in PHP4) switched off (note: a lot of PHP scripts that legitimately request files from remote servers rely on allow_url_fopen being switched on, and some older scripts rely on register_globals being on, so switching either of these off might be problematic, in particular if using PHP4). The best protection though comes from good programming techniques which prevent remote file inclusion from working even if register_globals and allow_url_fopen or allow_url_include are switched on.

When writing components for Joomla or Mambo, a check for a constant should always be made at the start of every file, eg:

defined(“_VALID_MOS”) or die(“Access Denied”);

In Joomla 1.5, the constant name has changed to _JEXEC. This prevents the script from running unless it has been accessed via Joomla or Mambo (so a cracker can’t go directly to the file in their browser). In this way, many of the important variables are initialised by Joomla or Mambo before reaching the script, and any injected value is overwritten. In addition to that, it is a good idea whenever dealing with files (either for reading/writing or including), to use a constant to hold the file path instead of a variable – that way it cannot be changed. For example:

define(“PATH_TO_MY_FILES”, dirname(__FILE__));

…would set the PATH_TO_MY_FILES constant to the directory name that the file resides in, and you can then use that constant to build the file name to include. 

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.

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 ‘../private/passwords/passwordlist.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.

Form Tampering and Spoofing

Whenever a form is displayed on an HTML page, the end user can enter data which is uploaded to the server and processed by a script. It is usually necessary to perform some sort of validation on the data to ensure that only valid data is processed. Often, javascript is used to perform validation on forms, because javascript is executed on the user’s browser – thus there is no need to post the form back to the server every time a piece of data is entered, and the user can be alerted to problems immediately.

Using javascript for data validation is ok but it must ONLY be used for the sake of user convenience, NOT for security. As the javascript is executed on the user’s browser, not the server, the programmer has no control over whether the javascript is actually executed or not. If the end user turns off javascript in their browser, none of the validation will take place. Therefore, whenever you use javascript to validate data, always add additional validation on the server side (eg. using PHP) before accepting it for processing.

In addition, programmers must be aware that when a form is submitted, it might contain anything – it will not necessarily contain what you are expecting. For example, if you have added hidden fields to the form, remember that even though the user cannot see those fields, and therefore cannot change them in their browser, it is still possible for a cracker to change their values before submission. All they have to do is write their own form with different values in the hidden fields, and post it to your URL – thus ‘spoofing’ (pretending to be your form, but actually being a different one). So always check that the values in hidden fields have not been tampered with (one way to do that would be to use a hash such as MD5 on both the value in the field AND a private key value that is not sent to the browser and that a cracker would not have access to).

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.

Sometimes, by submitting an unexpected piece of data in a form, a cracker can invoke a resource-intensive task which would not normally occur in standard usage. Again then, it is necessary for the programmer to be certain that any user input is fully validated and that the form processing script can handle whatever is thrown at it. For example, if you have a search box on a form which allows the user to specify a search term that is processed by trawling through a database in the back end, what happens if the user enters a complex regular expression or series of wildcard characters? Would that slow down the database query significantly? Another possiblity is for a program to go into an infinite loop if certain data is acted on, and this could result in denial of service to other legitimate requests. So the programmer has to think carefully about all of the ways that data enters their application, and ensure that strong validation takes place – you must be certain of the range of data you might be dealing with at all times.

In an effort to prevent denial of service attacks, many scripts which require legitimate 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 peoples’ 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.