PHP Security: Analyzing an Exploit

We recently had reports of a vBulletin site we host being infected with malicious code.  Having worked for years in vBulletin hosting, we have a good bit of experience addressing security matters for vBulletin-related plugins. Troubleshooting these types of problems is a fairly common task for our staff. It usually involves doing some security scans and taking inventory of software installed on a website or server. This time, however, we were in for a bit more work as this was not an off the shelf common issue.

After doing some Google searches of the particular malware symptoms that we noticed, we came across several other reports of vBulletin-based sites suffering from the same problem.   There was no known solution for this issue, and the sites in question were running the latest known versions of vBulletin software and plugins. This particular exploit involved malicious code being inserted into the vBulletin database datastore table which then caused the site to redirect users to the suspicious url123.info redirection service.

After finding a few possible workarounds and theories for how the exploit was happening, we decided to delve further and reverse-engineer the attack.

Capturing the Exploit

After doing some basic Apache log reviews for suspicious HTTP requests, we could tell that this was a more advanced attack. We would have to find it the old fashioned way.

We setup a modified version of this script from VBSEO in order to detect when the bad code was finding its way into the vBulletin datastore.  By running the script every minute, we were able to narrow down the attack entry point into a one minute window. While waiting for the bad code to come back, we used the popular command-line tool tcpdump which allowed us record all incoming traffic to the server. We then reviewed all HTTP requests and found the specific method of attack.

After again detecting the malware, we knew that our data capture from tcpdump contained the attack entry point to show us how the malicious code was being put into the vBulletin datastore.  WireShark is a very powerful and flexible packet capture tool that makes it easy to browse, filter and search through packet captures.  We searched the captured packet data for some common footprints that hackers use to try to cover their tracks in PHP such as the base64_decode function.

Success!  This search immediately turned up a suspicious HTTP GET request which we quickly determined was the culprit we were looking for:

From reviewing the above request, we now had some useful data in pinpointing the source of the exploit:

• The payload is being received by the vBulletin search.php script which is a popular script on any vBulletin forum
• The poison payload is being sent in the form of a HTTP cookie which makes it impossible to detect by looking through Apache logs and HTTP POST data
• The vbseo_crules prefix indicates that this attack relies upon a weakness in the VBSEO plugin.

Analyzing the Payload

After carefully decoding the vbseo_crules cookie, we found that it does the following:

• Creates global variables that is used to temporarily hold the attacker’s backdoor plugin
• Grabs MySQL information from the vBulletin config.php file
• Installs the backdoor plugin from previously set global variable into the vBulletin datastore
• Encodes the MySQL connection details using several different hashes and compression and returns the encoded information to the attacker

The backdoor plugin source code is available here. It does two things:

• Creates a backdoor which will let the attacker execute PHP code later by sending it as a HTTP POST variable
• Detects web traffic coming from search engines and uses obfuscated Javascript code to redirect them through url123.info.

So how does malicious code from a HTTP cookie get executed by PHP?  We traced that down to the use of the PHP preg_replace() function in VBSEO.  Under certain conditions, the preg_replace() function has the ability to execute code in an evaluated variable.

Securing Your vBulletin Installation

Luckily, VBSEO was alerted of the exploit around the same time that we discovered the problem. We have tested that this vulnerability has been addressed in the latest version of VBSEO (version 3.6.1).

If you think you may have been affected by this exploit or the url123.info malware, we recommend the following actions:

1. Disable PHP’s register_globals
2. Install the latest version of vBSEO (3.6.1 at the time this article was written)
3. Remove any rogue plugins from the vBulletin datastore
4. Be sure to change passwords for:
   1. All MySQL users on your MySQL server
   2. All vBulletin administrators
   3. VBSEO Admin password

If you have any questions about securing your vBulletin installation or specific questions about this exploit feel free to contact us for help!