views:

367

answers:

6

I've got a fully custom PHP site with a lot of database calls. I just got injection hacked. This little chunk of code below showed up in dozens of my PHP pages.

<?php /**/ eval(base64_decode(big string of code....

I've been pretty careful about my SQL calls and such; they're all in this format:

$query = sprintf("UPDATE Sales SET `Shipped`='1', `Tracking_Number`='%s' WHERE ID='%s' LIMIT 1 ;",  
 mysql_real_escape_string($trackNo),
 mysql_real_escape_string($id)); 
 $result = mysql_query($query);  
 mysql_close();

For the record, I rarely use mysql_close() at the end though. That just happened to be the code I grabbed. I can't think of any places where I don't use mysql_real_escape_string(), (although I'm sure there's probably a couple. I'll be grepping soon to find out) There's also no places where users can put in custom HTML or anything. In fact, most of the user-accessible pages, if they use SQL calls at all, are almost inevitably "SELECT * FROM" pages that use a GET or POST, depending.

Obviously I need to beef up my security, but I've never had an attack like this and I'm not positive what I should do. I've decided to put limits on all my inputs and go through looking to see if i missed a mysql_real_escape_string somewhere... Anybody else have any suggestions?

Also... what does this type of code do? Why is it there?

+4  A: 

That could have been caused by any common attack that have compromised the server.

Normally it is caused by an LFI (Local File Inclusion) but it can be caused by anything.

You can read more about LFI from:

http://labs.neohapsis.com/2008/07/21/local-file-inclusion-%E2%80%93-tricks-of-the-trade/

Hope it helps (a little)

Pablo López Torres
+3  A: 

Some quick tips:

  • Use proper data types before your variables such as intval for numbers in your queries
  • Use the mysql_real_escape_string for strings in your queries
  • Use prepared statements

Resource:

See SQL Injection guide on php.net

Sarfraz
He's not using eval. It's what the attack hacked into his pages.
Marc B
@Marc B: hmm that's it, thanks for that :)
Sarfraz
Yes, used prepared statements. They might as well deprecate the stupid mysql_ functions.
ryeguy
+5  A: 

As a matter of fact, SQL injection is not the only type of attack your server may suffer.

And this one doesn't looks like SQL injection.

Most of time it's just a trojan horse at your PC, stealing FTP password.

to see the actual code, replace eval with echo. But I doubt it has anything interesting

Col. Shrapnel
A: 

it looks like you are calling mysql_real_escape_string() AFTER your sprintf().

dar7yl
no, it doesn't.
Col. Shrapnel
the mysql_real_escape_string() are parameters to the sprintf, not after them.
Sagar
Sorry, my bad.That'll teach me to scroll so's I read the entire post.Then again, FORMATTING is critical.
dar7yl
+1  A: 

I'd look at the rest of the server. MySQL can't alter/overwrite files for you. It is possible to have it send output to a file ("SELECT ... INTO OUTFILE ..."), but there's a security measure in place that prevents it from overwriting a file that already exists. At most, an SQL injection will modify some of your data, or subvert a query to return a different result than expected.

Check into someone having gotten into your server by brute forcing a system account via SSH scanning, or even an SSH compromise. If you're on a shared server, it's entirely possible that someone ELSE's site got compromised and the attack simply proceeded to infect every PHP file it could find.

Marc B