SQL injection attack on a PostgreSQL database (t_jiaozhu)
For the first time I have been in a position to realize that a machine was attacked from an outside source in a production enviroment. A web server running Apache 2 and PostgreSQL was successfully attacked using a SQL injection vulnerability. I first noticed there was a new table in one of our PostgreSQL databases named 't_jiaozhu'.
public t_jiaozhu table postgres
The table wasn't something that myself or our developer had created so I immediately went into WTF mode. First I googled for the term 't_jiazhu' and found that there was only one English result that mentioned SQL injection attacks with the previously mentioned table name. At this point we searched the PostgreSQL log files but didn't turn up much but with the advice of a security guru I know (John Sawyer) we checked out the Apache web server log files and found the attack.
# grep t_jiaozhu *fred-access_log:219.153.131.99 - - [25/Mar/2007:11:59:32 -0400] "HEAD /showemploymentopportunity.php?id=38;create%20table%20t_jiaozhu(jiaozhu%20varchar(200)) HTTP/1.1" 200 - "-" "Mozilla/3.0 (compatible; Indy Library)"
Sawyer also came up with a possibility that the IP in which the attack came from may have been a bot using an IDS.
"After the table was created, there were several hits from that IP that had the following user agent "Mozilla/3.0 (compatible; Indy Library)". A little digging shows that it might be a Chinese spambot."
Our developer quickly discovered that we weren't checking varibles that were being passed. A quick addition of code fixed the problem.
if (!is_numeric($id))
$id = 0;
13 Comments:
thanks Richard.
It's really usefull for me.
someone do the same thing for my sql server (windows 2003 Server) but it's clean now.
thank you
~Rio Yotto
Glad to hear that you were able to fix the problem.
I just got hit too, on a SQL Server. Obviously I've fixed the vulnerability now.
Any idea if it has any other payload other than the table creation? I've not been able to find any yet, although, worryingly, my transaction log has grown 10x more today that it has over the previous year!
I couldn't find anything else besides the table that was created. I searched through the rest of the tables to make sure there was not any other additions. It doesn't seem to produce any type of shell or escalation of privileges. If you find out more then please inform me.
I certainly will let you know if I find anything. So far, I've only found the table, I am pleased to say.
Thanks,
Matt.
closed any error code that appears when you run query .. and also check check your scripts and also all permisions on your folder.
i've got attacked by c99 shell scripts also .. :) and it's clean now.
I'm assuming I didn't have a problem with that because I ran on an open-source platform but thank you for the heads up.
Thanks Richard, Found your page after a google search for jiaozhu. I got hit on the 25th april and 19:00 gmt. All I got was a table created, using this ;create%20table%20t_jiaozhu(jiaozhu%20varchar(200))
appended to the querystring.
Once this had succeeded they used a
%20and(char(94)%2Bdb_name()%2Bchar(94))
to find the database name and then a similar attacks to find the user name and the table names. Everything apart from the create table failed, fortunately.
It took 27 seconds for the attack to complete and around 50 different attempts where tried, all of which used data from the previous error messages. So an intelligent bot would appear to be the culprit.
The IP address used was 58.241.178.219 HTTP/1.1 Internet+Explorer+6.0
I have increased the security and all the attacks now fail (so far).
Fingers crossed.
Paul
Thanks for the information Paul!
We have been hit many times by this and other SQL Injection hacks, and we have not yet found a way to protect ourselves from it happening again. The damage was much more than just the creation of the t_jiaozhu table...they were able to insert massive scripts. Any ideas on how to keep this from happening?
Are you allowing your frontend to insert data into the backend (database)? The problem that caused our DB to have the new table to appear; we weren't sanitizing and checking the data that was being inserted correctly. If script are being uploaded and run I would double check your entire system for vulnerable pieces of software especially the DB package.
Thanks for this great article.
I guess it is still out there over 2 years after this original post. It hit us recently on a SQL Server through ASP and updated several tables. I thought I had fixed all vulnerabilities. I now plan to restrict the account permissions to SELECT only everywhere that I can.
Post a Comment
<< Home