A sudden and critical publicly disclosed vulnerability in popular software periodically sends organizations around the world scrambling. Recently, a very popular web-forum called vBulletin was found to have a critical vulnerability, putting user data at risk. This resulted in many companies having to choose to either take their forums offline or be at a severe risk of attack.
In this case, specific versions of vBulletin (versions 5.0.0 – 5.5.4) had an especially worrisome bug. Here is the problematic PHP code:
As you can see, a parameter called $code is accepted by the evalCode method on line number 1, and that variable ultimately winds up in the PHP method eval on line number 4. The eval method and many others like it are particularly problematic because they can allow user input to transform into executable code. In vBulletin’s case, the $code variable contained user-controlled data. This means data originating from the user is sent to the server, converted into executable code, and then executed on the server.
Even a novice attacker can abuse a vulnerability like this to gain control over the webserver running vBulletin. Once the announcement of this vulnerability was made public, attacks started almost immediately. Since vBulletin is a such a popular 3rd party provider, it’s nearly effortless for an attacker anywhere around the world to run a quick search and find vBulletin installations. From there crafting an attack is straightforward, and example attacks can also easily be found online.
How Did This Happen?
In this case, an anonymous individual disclosed the vulnerability on a popular security message board, complete with exploitation code, and apparently without any warning to the vBulletin team. This means the severity of this issue was compounded by the fact there was no patch readily available, which resulted in users having to take the forum ofline for days or be at grave risk.
How to Protect Your Organization From Publicly Disclosed Vulnerabilities
At the code level, we can’t speculate as to why the eval method was inserted in the first place, and why its use wasn’t discovered until several years later. Establishing secure coding practices is a company-wide necessity. The forefront of this includes providing a means of education for all members of the development team, as teaching how to code securely is key to avoiding these types of errors. For example, in this case, the eval method is known to be very dangerous and should never be used along with user-defined input. This would fall under the “remote code execution” vulnerability category. As referenced in A1 of the 2017 OWASP Top Ten series, SQL Injection and OS Command Injection are very similar in that user-defined data is rendered into executable code.
Companies must go beyond simply supporting application security training for only their developers. Since vulnerabilities in 3rd party code will continue to be a problem, management and nontechnical staff must participate in gaining knowledge on how they can support their company’s overall application security program. There are a few key security activities and practices that a company can implement to minimize their risk related to 3rd party components: Creating an inventory of those components, checking your inventory for known vulnerabilities and performing regular security reviews.
In the case of vBulletin, almost immediately following the disclosure, attackers were exploiting the vulnerability. CVEs similar to the vBulletin case are constantly being published, and in addition to having secure coding practices, your organization needs to be very aware of any publically disclosed vulnerabilities that can put your organization at risk.
For more information about building a security program, please refer to our “Integrating Security throughout the SDLC” eLearning course. And for an overview of the most fundamental web vulnerability categories, development and management teams alike would benefit from education in our respective”OWASP Top 10 for Developers” and “OWASP Top 10 for Managers” courses, which covers “Injection” and “Using Components with Known Vulnerabilities” in detail.