Once again, a flaw was found in GTU's website. But this time it's different as I found it :). BTW, if you don't know about last hack on GTU's research website, you can find it here. Now, let's talk about this hack.
I was just frustrated of exams and so spent some time surfing and reading on things other than the paper I had next day. I had some work to do with the GTU Research Dept. and so was searching for a link of some form. But then on Google, I found a website
whose description read GTU Admin Panel. I haven't seen that website before and so gave to thought to see what was the purpose of that site. As soon as I opened the site, it brought me to a login page of administrator.
Before telling you more on what I did and how I hacked the site, let me tell you what was the purpose of that site and what might have happened if someone else (except me) hacked that site (because I am ethical - I follow rules meant for peace and freedom). This website is exactly what the description said. There are many courses going on in GTU like UG courses, PG courses, PhD courses and many more. According to the courses, it provides a login page where the colleges registered for that courses can login. Each college has been assigned an administrator account. Colleges are meant to upload details about students, professors and assistants who are a part of that college. This is all about human resource but this site is specifically for things related to exams.
That means, which student has paid the fees and eligible for exam and who is suspended. Also, you can suspend a student using this admin portal. Other exam related updates like question paper dates, marks, etc. are also a part of this website. In short, each and every information related to exams was available on this site and the admin could modify this information. Now, just think of the consequences of what might have happened if some wrong personality got into this site. I don't need to list the consequences as you are capable of thinking that yourself.
Moreover, this has been my second vulnerability report. The first one was when I found the rsync server password in plain text of the Stanford University's server. I mailed them but no response. But GTU is better in this case (not talking about education system XD). I just sent a mail to 2 different email ids of GTU but one of them was deactivated. I got a response from a person at GTU within 24 hours. At first, he didn'i believe me and asked if I can tell him username and password of any single registered account. I just explained him that no one can get plain text passwords except the owner leaks it intentionally or unintentionally. And there are other ways you can get into account even when you don't have username and password. That's what SQLi is meant for.. It doesn't get into OWASP's top 10 attacks list without any purpose and that too with a high rank (3).
After sending a proof photo, he believed me and asked for the solution and here it is now.. The website is patched of this vulnerability.
Now, let's focus on how to hack rather than discussing what I did. But before that, let me share the proof image with you and make you believe that this works.
SQL Injection
Structured Query Language (SQL) is used to query, operate, and
administer database systems such as Microsoft SQL Server, Oracle, or
MySQL. The general use of SQL is consistent across all database systems
that support it; however, there are intricacies that are particular to
each system.
Database systems are commonly used to provide backend functionality
to many types of web applications. In support of web applications,
user-supplied data is often used to dynamically build SQL statements
that interact directly with a database. A SQL injection attack is an
attack that is aimed at misusing the original intent of the
application by submitting attacker-supplied SQL statements directly to
the backend database. Depending on the web application, and how it
processes the attacker-supplied data prior to building a SQL statement, a
successful SQL injection attack can have far-reaching implications. The
possible security ramifications range from authentication bypass to
information disclosure to enabling the distribution of malicious code to
application users.
Note what I mentioned above is submitting the user input directly i.e. without any preprocessing may lead to SQLi. Hence, the short and simple answer to avoid SQLi is to preprocess the input taken from user, identify threats in it and then submit the inputs for database query. Let us see the same with an example.
One of the many possible uses for SQL injection involves bypassing an
application login process. The following example illustrates the general
operation of a SQL injection attack. An application with a vulnerable login process may accept the submitted
information and use it as part of the following SQL statement, which
locates a user profile that contains the submitted username and
password:
select * from Users where (username = 'submittedUser' and password = 'submittedPassword');
For example, if an application accepts and processes user-supplied data
without any validation, an attacker could submit a maliciously crafted
username and password. Consider the following string sent by an
attacker:
username=admin%27%29+--+&password=+
Once this string is received and URL-decoded, the application will attempt to build a SQL statement using a username of admin') -- and a password that consists of a single space. Placing these items into the previous SQL statement yields:
select * from Users where (username = 'admin') -- and password = ' ');
The string of two dash characters (--) that appears in the crafted input
is very important; it indicates to the database server that the
remaining characters in the SQL statement are a comment and should be
ignored. So, the backend of web application will only check for a matching username without performing a password check and hence, one can easily login into a website if they know a username.
But there's a twist. I didn't knew username of any user account before I hacked the site. Still I was able to login to the account. That's because of a single reason - all the web applications doesn't have the same backend code like 'select * from ...'. And according to the backend logic, we need to try different user input formats to get into a website. Suppose that the SQL syntax was different than the one shown above. Suppose, it was like:
select * from Users where username = 'submittedUser';
select * from Users where password = 'submittedPassword';
And then it matched the username and password separately to login. Then the above described user input wouldn't work as it won't find a variable named submittedPassword when trying to execute the 2nd line of code. Here, the commenting using '--' wouldn't work as the semicolon at the end of 1st line defines the end of comment as well as 1st statement. So, the application would throw an error specifying 'Please provide a password.' This was the case with GTU exams website and so I tried a new modified input as:
username=abc' or 1-1--
password=pqr' or 1=1--
Here, we provide separate values for username and password and add comments to both statements. Here. the OR operator does the task. It just performs a check for '1=1' which is always true and hence I logged in successfully.
That's all about this.. But an extra note - the use input for performing SQLi varies with the varying backend code. So, there are various forms of user input and without knowing the backend script (which you won't), you need to try all of them.
The good news are here.. The site is patched! Ending this article with a last picture.
For any query, just post a comment here.. Thank you!
