> eduberrocal.net
| protected


SQL injections
2017-03-31 05:47:11

Once in a while, I like to check what pages are accessed in my website and who is accessing them. And once in a while too I get some random SQL injection attack attempt. This is interesting because I can not imagine what hackers may think they could steal by dumping the information stored in the tables used by this website (which, BTW, are mainly used to store meta-information about visits to the site. The fact that hackers think my simple web server is of any value causes in me some mixed feelings, with one of the worse being a "wow I am important" type of feeling.

But of course there is another feeling, and one that people should have more often, which is that more often than not in this crazy world of the internet, security is just as good as the security of the weaker link. Of course hackers are not interested in me per se, or even in what information may be stored in my website backend database, but rather in a way to get access to a computer/server inside an organization (in this case Illinois Institute of Technology, although the server lives in AWS right now) that they can then use to hack juicier targets. This is troubling because a lot of times this is all it takes. A hacker gets into the computer of some employee at organization X, uses the credentials or the information in that computer (or maybe his/her email account) to access other computers/servers and then steals the desired information.

In the case of this attack, which BTW has not been the only one and will probably not be the last, I know for a fact that the only reason it did not work is because I know about SQL injection attacks and I put the effort to make my backend code as robust against these attacks as possible with PHP. But you can imagine that this is not always the case and, in a lot of situations, people get lazy and do not go the extra mile to make their web sites robust against these kinds of attacks. Or maybe they just do not know, or they can not imagine someone will even try to hack their simple personal websites. Of course, these are not the only type of attacks, and one should always stay vigilant (and keep their software packages up to date).

The way SQL injection attacks work is by injecting some SQL code into a text field in an online form (it can also be a GET value) for the server to run. This attack works when the code running in the backend appends the information sent by the frontend to a larger SQL query without checking whether this information is what it is supposed to be. For instance, if the text field is a User ID field, then it should only contain user ids. Or if it is an email field, it should only contain emails, and so forth. To put an example, consider a very simple table called mytable with only two columns: user_id and balance. A user should not be able to see the balance of other users, and so an online form is created where users can enter their id and check their balance. Now, let say that the backend programmer gets lazy and does not check the information sent by the frontend. The query for checking a user's balance is the following:

SELECT balance FROM mytable WHERE user_id=$TEXT_FROM_FRONTEND

If the information stored in $TEXT_FROM_FRONTEND is a user id (let say 1234567890), then this code will just work fine. However, a hacker can easily get all users' balances by entering the following text:

0000000000 OR user_id!=0000000000

Please, consider that this is JUST A SIMPLE EXAMPLE. What this SQL injected code does is to get all balances that are either the id 0000000000 or they are not the id 0000000000, which means pretty much any id. As you can see, if the backend code does not properly check that the information passed does not contain any SQL code, or if it does not properly treat it as just text with no meaning, then the hacker would have stolen everybody's balances. This is what the query would look like:

SELECT balance FROM mytable WHERE user_id=0000000000 OR user_id!=0000000000

Of course, for that attack to work, the hacker would need to know the name of the column (user_id). However, in a lot of cases it is easy to guess. A simpler attack would be to attach the string 0000000000 OR 'x'='x'. Even if the query does not mean anything, the system would evaluate it to logically true and hence it would output all rows in the table.

In my case, and since I store all access attempts that users do to my website, I know someone is trying to do SQL injection when I see funny things like this in my webstats section:

sql_injection

Here one can see the SQL code injected right after resume.pdf. In this case, this is not through a form but through GET variables (the ones that are passed on the URL). After seeing this, I went to my access log to check the IP address from where this attack came from. Of course, real hackers rarely do these attacks from IPs that can incriminate them, and rather use proxies or other hacked machines (zombies), usually in other countries. When someone is able to attempt sophisticated SQL injection attacks, that person is normally well versed in how to cover his/her footprints (at least the most obvious ones). In this case the IP (91.223.133.38) came from a computer somewhere in Greece. I bet this computer is just a zombie controlled by some "evil actors" paid to infiltrate US organizations, or maybe it is just someone simply using a proxy node in the Tor network and trying to break my DIY website. Whatever the case, check these other injections that the hacker tried:

stuff/resume.pdf%' UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL#
stuff/resume.pdf) ORDER BY 1-- ijpz
stuff/resume.pdf,,)',.'(..

Eduardo Berrocal © 2012-2018

Valid CSS! Valid HTML-4.01!

Page generated on 2018-12-10 17:52:58 PST