So a page on my site (it's a PHP page that displays newsletter articles) was vulnerable to SQL injection and got hit. I discovered it because it was doing enough database queries to cause the CPU load to spike on the database server. I found at least some of the IP addresses that were doing it from my Apache logs and blocked them in the firewall, and I at least kind of hardened the page. What I'm trying to determine is exactly what queries they were running, they obscured/escaped stuff pretty well. This is the query string I'm finding in the Apache logs:

?id=742%2F--%2F%2F!30000and(select%2F--%2F1%2F--%2Ffrom(select%2F--%2Fcount()%2Cconcat((select%2F--%2F(select%2F--%2F(select%2F--%2Fconcat(0x27%2C0x7e%2Cunhex(Hex( cast(sbamail.email%2F--%2Fas%2F--%2Fchar)))%2C0x27%2C0x7e)%2F--%2Ffrom%2F--%2Femail.sbamail%2F--%2Flimit%2F--%2F284079%2C1)%2F--%2F)%2F--%2Ffrom%2F--%2Finformation_schema.tables%2F--%2Flimit%2F--%2F0%2C1)%2Cfloor(rand( 0)2))x%2F--%2Ffrom%2F--%2Finformation_schema.tables%2F--%2Fgroup%2F--%2Fby%2F--%2Fx)a)%2F--%2Fand%2F--%2F1%3D1%2F

This is what the database was showing for running queries:

select title from newsletter_articles where article_id = 2010/--//!30000and(select/--/1/--/from(select/--/count(),concat((select/--/(select/--/(select/--/concat(0x27,0x7e,unhex(Hex(cast(sbamail.email/--/as/--/char))),0x27,0x7e)/--/from/--/email.sbamail/--/limit/--/119488,1)/--/)/--/from/--/information_schema.tables/--/limit/--/0,1),floor(rand(0)2))x/--/from/--/information_schema.tables/--/group/--/by/--/x)a)/--/and/--/1=1/

(both of those repeated Ad nauseam with minor parameter changes) When I tried pasting that query back into MySQL I get a syntax error.

When I actually paste that query string on the affected page (before I patched it), it simply displays this:

Duplicate entry ''[email protected]'~1' for key 'group_key'

The "Duplicate entry" bit is what really has me worried. I initially thought they were just after email addresses(there are no passwords stored in this database, fortunately); it's happened before on other pages and all I can see are "select" statements, but if they were able to insert/update/delete that's much worse news. How can I unescape/decode what they were doing? Should I be panicking and looking at restoring the database from backup?

The page in question is on a pretty basic LAMP stack, if that's relevant at all. No framework or anything.

  • possible duplicate of How do I deal with a compromised server?
    – user3558
    Commented Feb 19, 2013 at 23:33
  • I'm more trying to figure out whether anything was compromised beyond getting some email addresses out of the database. We've been targeted by somewhat similar attacks before and our Sysadmin (who is no longer with us) was confident nothing bad had happened then, but in that case I could clearly see what the queries were pulling and there was no way they had executed an insert to get the duplicate entry error. The fact that I couldn't directly see what queries were going on this time was making me freak out, but it may just have been part of this bug: bugs.mysql.com/bug.php?id=58081
    – joshg
    Commented Feb 19, 2013 at 23:46
  • This query does nothing except use a good amount of processing power of your database server. Combined with multiple maybe lots of IPs doing requests like these you could say DOS on the database server. The question is why? Could be something simple like disliking your company or could be something else like masking what was really going on. You can find out what this does by reading the query. Finding out what they were really doing means checking the logs of all of this. Also have in mind, that there could be stuff that happened before someone made you aware of this issue.
    – lsmooth
    Commented Feb 20, 2013 at 0:31

1 Answer 1


First you should check if your mysql user has the FILE privilege. If so, consider the system completely compromised.

The injections you provided along with the error 'duplicate entry' are a clear example of error based SQL injection.

PHP's mysql_query doesn't support more than one query, so it's not possible to insert/update/delete from a select query in your application. But if your application has an insert/update/delete query that is vulnerable to sql injection (which is very likely) then it is possible to tamper with the database.

  • That's not good. Is there any evidence I can search for to confirm that the server has been compromised before I hit the panic button and take it down?
    – joshg
    Commented Feb 20, 2013 at 19:15
  • @joshg did you check if your mysql user has the FILE privilege? If it isn't enabled, the chance of full server compromise is very low.
    – Zzz
    Commented Feb 21, 2013 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .