Last month, researchers in our Vulnerability Research Group found a critical vulnerability in MediaWiki, the open-source web platform that is used to create and maintain wiki websites, including Wikipedia.org, the sixth most visited website in the world.
This critical vulnerability left the MediaWiki platform (version 1.8 onward) exposed to a remote code execution (RCE) attack. An attacker could have used this vulnerability to gain complete control of the Wikipedia web servers, potentially exposing Wikipedia's 94 million monthly visitors to malware or massive information disclosure.
Since an update and patch has been issued to the MediaWiki software, the vulnerability has been exposed and resolved, so long as all MediaWiki users install the patch. However, there are still some useful lessons we can take away from this near miss.
Lesson No. 1: Know your stack
The RCE vulnerability was only the third of its kind found in the widely used, open-source MediaWiki platform since 2006. That's a good track record, but it demonstrates how easily organizations can be lulled into a false sense of security just because a vulnerability has not been announced in months or even years on the platforms they use.
Web application server stacks expose a broad software surface for an attacker on the vulnerability hunt. Even the most minimal setups typically overlay a web framework (e.g., Wordpress) based on a platform language (PHP), using a database (MySQL) in a web server (Apache) over an operating system stack. Any of these components can be an exploitation candidate -- and we haven't even mentioned custom application business logic, imported JS libraries, plugins, mods, and other extras. The opportunities are abundant.
In addition to keeping a vigilant eye for vulnerabilities on the development side, it's more important than ever to keep your software updated across the board. Make sure you are running recent versions of your framework and services, running on top of a modern OS with built-in exploit mitigation techniques and other native protections enabled, or look into threat prevention technology. Best-practices would recommend doing all three; follow your vendor's hardening guides.
Lesson No. 2: Occam's razor still cuts true
The slightly more modern version of Occam's razor is KISS (keep it simple, stupid). Both axioms hold true in this case: The simplest answer is usually the right one. Though we've seen a steady rise in sophisticated threat vectors, advanced persistent threats, mobile device breaches, DDoS attacks, and even international bank heists make headlines, relatively simple attacks through vulnerabilities like the one we discovered on the WikiMedia platform are still a very real and common threat.
Worse, some input validation vulnerabilities tend to go unnoticed because the exploitation techniques are not particularly new or technically advanced. This presents an attractive target, since attackers are always looking for the path of least resistance. It's akin to putting up the "Beware of Dogs" sign, keeping a big dog in the backyard, arming your sophisticated home protection system with mobile alerts, bolting the front door, locking the back gate, and then leaving one of the front windows open. Sometimes those simple, obvious entry points are the most lucrative for criminals -- and the most overlooked by developers and site owners.
Lesson No. 3: No such thing as a safe click
Even the most trusted sites are susceptible to exploits like this RCE vulnerability. But if you put appropriate protections in place, you can detect and block infecting code before it spreads to your clients and servers. It's not practical to block employees on your network from all sites, and as this case shows, even the most useful and benevolent sites can host malicious code.