mysql injection damages?

I Just noticed that my mysql_real_escape_string function is not inside a '' in some of my php scripts and it was vulnerable to injections and things like sleep(30) executed on my production site.

I am going the PDO route and implementing the prepared statements after lots of reading here. but this is not implemented yet.

Few questions, I see in my logs that lots of injections where done by people online but I can not see any damages. the user that the site runs to do sql queries has update/select/delete/insert only privileges.

But I am woried things like sleep(30) and what not works and if they did any damages I am not seeing?
Can you tell me where to check for damages or was I safe for at least major damages?
Can they have changed hidden mysql settings or system settings?

By the way, I tried to run latest updates on centos 6+ linux and php.

Thanks

edit: just to clarify, the database is empty almost and i am not worried about the data being there and the passwords are hashed sh512. so the data inside is not important since this is a new application i am writing. but i am worried if they changed anything on the system or the db i should be worried about. some of the injections i see have java etc but the log is huge and its going to take time to go over it. i also see some schema strings in the injections.

now the question is can they have read my schema info or modified them? why does functions like sleep are working if it is a restricted user? what other functions could they have run?

note i have other DBs in the same MySQL. should i be woried about those?

by '' i mean: select * from dbname where id=scaped_string i should have put it in quotes

Solution 1:

Checking for damage done to your data is dependent on the kind of data you have in your database. If after careful inspection you don't see anything wrong, then there is probably nothing wrong. If your data is of any decent size, this will be difficult or impossible.

There are many automated bots roaming the internet looking for code vulnerable to SQL injection attacks. Their attempts are probably what you are seeing in your logs. Just because an attempt was made does not necessarily mean an intrusion occurred.

Also keep in mind that you won't necessarily have evidence of data being stolen. The best way to determine this would be to take your server logs and replay them on a copy of your current server, checking to see if you get any data back.

Solution 2:

Without any further information, we have to assume the worst case: An attacker is able to read, write, and delete arbitrary data in your database, and possibly even files on your file system, which may lead to compromise of your whole server (e.g. command execution via PHP file, privilege escalation, etc.).

Now let’s have a closer look at the possible impact:

Since PHP’s MySQL extension does not allow multiple statements, so called stacked statement attacks are not possible. So the remaining possibilities depend on the actual statement verb and the context, i.e. the clause inside the statement:

• SELECT statement:
  • Reading any accessible data (e.g. sub-queries, unions, boolean-based blind, etc.)
  • Reading files (LOAD_FILE())
  • Writing files (… INTO OUTFILE …)
• UPDATE statement:
  • Obviously updating any accessible data, possibly not just in the current table
  • Reading any accessible data (e.g. sub-queries, boolean-based blind)
• DELETE statement:
  • Obviously deleting any accessible data, possibly not just from the in the current table
  • Reading any accessible data (e.g. sub-queries, boolean-based blind)
• INSERT statement:
  • Obviously inserting arbitrary data
  • Reading any accessible data (e.g. sub-queries)

Some of these may not have a direct impact but may be used to exploit other vulnerabilities. In the end, it depends on the actual vulnerable statement.