Saw this SQL Injection attempt, could not find much about it, so I thought I'd document it here a bit. I believe from some google searches, that this might be against a vulnerable e-Commerce system called ShopEx, and in particular against the ShopAdmin page in that suite, so perhaps against an administrative login page. The SQL injection POST attack sample is here. It appears to be against the sess_id parameter in the url of that request. It's a simple url GET request.
What you see is that they are passing a ' and (redacated) and '1'='1 which is typical SQL injection. Somebody on the back-end must be concatenating strings to build their SQL query instead of using parameterized queries. Thus the attacker is able to pass a single tick (') which will close the previous string (likely for session id) in the sql command and continue to re-write the SQL query by adding the conditional and keyword, some more sql code in parenthesis that I redacted for now, and finally the typicaly '1'='1 command where it's basically saying return all records no matter what the session id is.
The first thing you might be wondering though is what is the attacker's goal in a statement like this? Well to get at that we have to dig deeper into that redacted code, but for now I can tell you that they're trying to extract data from the database. They're not trying to write data, they're not trying to backdoor the system, etc. they just want data out of the database.
Inside that redacted code you'd see something like this select count(*), (redacted2) x from information_schema.tables group by x which is also commonly seen. This is a bit tricky to understand, but I blogged about it before and described it as SQLi Duplicate entry for key where the attacker will actually be able to extract data from the database via a exception error message. So no matter how the website administrator/developer is displaying or returning results (or maybe they aren't all) ... the attacker can always extract data with this method as long as SQL exception error messages are getting output to the error page. So the above code works because the code in the redacted2 portion will get displayed once for every table in the information_schema database, so assuming your database as more than 1 table, this is going to display the same redacted2 data multiple times, and since you're doing a group by SQL is going to throw and error/exception saying duplicate key, because you're trying to group by/display the same value multiple times which is not allowed.
Lucky for the attacker then, if the website is configured to display the error message generated, the attacker can control the error message and get it to actually display the data they want to extract. In this case ,the code inside redacted2 is select concat(userpass,0x7e,username,0x7e,op_id) from sdb_operators which you can see is the attacker trying to extract the username and password from the spdb_operators table, which likely is some sort of administrator that the attacker can then turn around and login to the shopadmin login page with and thus gain administrative access to the e-commerce site.
To prevent this, first of all the sql injection could be fixed with proper parameterized queries and input sanitization. But also public facing administration pages should be avoided or removed completely so that even if the attacker got the username and password it would be useless. If public facing administrative pages are needed, then at a minimal put in some IP filtering and other restrictions that prevent an attacker from logging into your admin page from anywhere except your known trusted ip ranges.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment