Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

2/12/2014
03:45 PM
Shahar Tal
Shahar Tal
Commentary
Connect Directly
Twitter
RSS
E-Mail
100%
0%

3 Web Security Takeaways From Wikipedia's Near Miss

Even the most useful and benevolent websites have the potential to host malware.

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.

Shahar Tal is the Vulnerability and Security Research Manager at Check Point Software Technologies. Prior to joining Check Point, he held leadership roles in the Israel Defense Force, where he was trained and served as an officer. He brings more than 10 years of industry ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
2/14/2014 | 9:42:37 AM
Re: How did you find the vulnerability
Thse of us in the realm you protect, salute you (and others) for your work! Definitely a growing and important field. 
shahartal
50%
50%
shahartal,
User Rank: Apprentice
2/14/2014 | 3:33:37 AM
Re: How did you find the vulnerability
These was no external activity to prompt the investigation. We regularly identify popular platforms and perform research in order to expose vulnerabilities that might harm all kinds of users. We're no 'protectors of the realm' but we do our best to help secure the Internet.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
2/13/2014 | 4:48:02 PM
How did you find the vulnerability
Shahar, Were you looking for something specific, or did some activity the investigation? 
shahartal
50%
50%
shahartal,
User Rank: Apprentice
2/13/2014 | 1:58:31 AM
Re: Was anyone actually affected?
The WikiMedia foundation has stated that they found no evidence of a past attack exploiting that vulnerability. Of course, the first thing a clever attacker would do is clean the logs. As for other web sites, I don't know of any other case yet, but as the exploit has been made public on exploit repositories, it's a matter of finding the unprotected ones and simply running a script.
jagibbons
50%
50%
jagibbons,
User Rank: Strategist
2/12/2014 | 9:56:26 PM
Re: Was anyone actually affected?
The false sense of security around the oldie but goodie attack vectors is a very real issue. In the quest to protect against the newest threats, we don't always think about the older variants that are still out there. Security teams can't take anything for granted. Continually test and verify that systems are protected as best as they can be.
Thomas Claburn
50%
50%
Thomas Claburn,
User Rank: Ninja
2/12/2014 | 7:05:54 PM
Was anyone actually affected?
Did anyone get hacked as a result of this flaw or is that still to come if sites don't patch quickly enough?
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27605
PUBLISHED: 2020-10-21
BigBlueButton through 2.2.8 uses Ghostscript for processing of uploaded EPS documents, and consequently may be subject to attacks related to a "schwache Sandbox."
CVE-2020-27606
PUBLISHED: 2020-10-21
BigBlueButton before 2.2.8 (or earlier) does not set the secure flag for the session cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http session.
CVE-2020-27607
PUBLISHED: 2020-10-21
In BigBlueButton before 2.2.8 (or earlier), the client-side Mute button only signifies that the server should stop accepting audio data from the client. It does not directly configure the client to stop sending audio data to the server, and thus a modified server could store the audio data and/or tr...
CVE-2020-27608
PUBLISHED: 2020-10-21
In BigBlueButton before 2.2.8 (or earlier), uploaded presentations are sent to clients without a Content-Type header, which allows XSS, as demonstrated by a .png file extension for an HTML document.
CVE-2020-27609
PUBLISHED: 2020-10-21
BigBlueButton through 2.2.8 records a video meeting despite the deactivation of video recording in the user interface. This may result in data storage beyond what is authorized for a specific meeting topic or participant.