I found a couple vBulletin sites I administer getting hacked recently. They use the latest version of the 3.8 series (3.8.7 Patch Level 2). I am usually pretty good at finding the holes where they get in and patching them up, but this one is stumping me. They are injecting data into the MySQL tables. The attack always happens when they make a GET request to the faq.php
script. I was able to save data when the attack occurs. This was the $_REQUEST
, $_GET
, $_POST
, $_COOKIE
, and $_SERVER
arrays. The only thing I saw that looked out of place is that there were two new $_SERVER
keys, HTTP_SOVIET
and HTTP_PACK
:
I have to assume this is the root of the issue, but I cannot for the life of me figure out how the attacker can set this variable. There is nothing in the request string, nothing in the cookie array, it is a GET request, not POST.
Any idea?
The attacker in this case has a backdoor code installed in one of your FAQ phrases (vbulletin
phrases
db table) as a set ofchr()
PHP function calls.that basically when eval'd through the faq.php script, gets decoded to:
You may find the affected vBulletin phrases by issuing a SQL query like so
Though there are many variants of this, some are using HEX strings, base64decode, assert, pack calls or just plain PHP.
A variable like
$_SERVER['HTTP_*']
can set by just adding headers to the HTTP request.A simple command line example would be:
PHP Page:
Then on command line:
You'll see that
$_SERVER['HTTP_SOVIET']
is equal to123
.In this case, the contents of HTTP_SOVIET are base64 encoded (give away, it ends in
==
). Unencoded, it turns into:It's worth noting that query there:
Check your style table, as that's one way/the way code is exposed to the user.
Renaming your style table to something else would likely mitigate the effects of this attack for now.
In there, the base64 bit has more bas64 in, which has more bas64 in which eventually evals:
This writes to a file called
/tmp/phpYRcCBmBr
, so I'd check what that says.It also hides it's behaviour from search engines, which is nice of it.
The bad bit for users is likely:
Which puts some JS on the page hosted by
kjionikey.org
. That JS requires a key based on the IP address.I'd check any code that reads/executes the contents of random $_SERVER variables, but why that would be in there, I don't know.