(I thought I was protected!) <? php / ** / eval (base64_decode (everywhere

Question

I have a fully customizable PHP site with lots of database queries. I just got an injection. This small piece of code below has appeared on dozens of my PHP pages.

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

I was very careful about my SQL calls and the like; they are 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. This is just 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 is probably a couple. I will find out soon). There are also no places where users can put custom HTML or anything else. In fact, most of the pages available to the user, if they use SQL calls at all, are almost inevitably SELECT * FROM pages that use GET or POST, depending.

Obviously, I need to strengthen my safety, but I have never had such an attack, and I'm not sure what I should do. I decided to set limits on all my inputs and see if I missed mysql_real_escape_string somewhere. Anyone have any suggestions?

Also, what does this type of code do? Why is he there?

Answer 1

In fact, SQL injection is not the only type of attack that your server could suffer.

And this is not like SQL injection.

In most cases, it is just a Trojan horse on your PC stealing an FTP password.

to see the actual code, replace eval with an echo. But I doubt that he has something interesting.

Answer 2

This could be caused by any common attack that compromised the server.

This is usually caused by LFI (including a local file), but it can be caused by something.

You can learn more about LFI:

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

Hope this helps (a little)

Answer 3

A few quick tips:

• Use the correct data types in front of your variables, such as intval for numbers in your queries
• Use mysql_real_escape_string for rows in your queries
• Use prepared statements

Resource:

See php.net SQL Deployment Guide

Answer 4

I would look at the rest of the server. MySQL cannot modify / overwrite files for you. It may send the output to a file ("SELECT ... INTO OUTFILE ..."), but there is a security measure that prevents it from overwriting an existing file. In the best case, SQL injection will modify some of your data or undermine the query to return a different result than expected.

Check if someone got to your server by using a coarse forced system account using SSH scanning or even compromising SSH. If you use a shared server, it is possible that someone from the ELSE site was compromised, and the attack simply began to infect every found PHP file.