This year was a banner year for content management system (CMS) hacking. All the big names, including WordPress, Drupal and Joomla, were targeted in 2014, resulting in thousands of breaches that opened back doors, uploaded Trojans and created large-scale botnets for denial-of-service attacks. The following are the big-number takeaways from these CMS vulnerabilities:

Why CMS Hacking?

While it’s tempting to relegate CMS as “also-rans” in the world of security breaches, there is real risk when content management platforms are hacked. High-profile breaches such as Target and Home Depot garnered attention due to the Backoff malware, and rightly — many retailers use point-of-sale systems that aren’t properly secured. As noted by Web Technology Surveys, however, 75 percent of websites using a CMS are powered by popular platforms such as WordPress, Joomla and Drupal, all of which are built on open-source code, are free to use and are largely maintained by a passionate community of users. In other words, this is a huge market for cybercriminals — and since almost every bit of code they need to break down CMS walls is publicly available, it’s no surprise that they are popular targets. But how bad was 2014, really?

WordPress Hacks

In July, a flaw in MailPoet Newsletters allowed attackers to upload arbitrary PHP files to Web servers and take control of WordPress-based websites, according to PCWorld. The hack was used to compromise at least 50,000 websites, and while a newer version of the plugin fixed the problem, many users were unaware of any issues until it was too late.

“The back door is very nasty and creates an admin user called 1001001,” said security researchers from Sucuri, noting that it “also injects a backdoor code to all theme/core files.”

On Nov. 20, the official WordPress site announced that any versions earlier than 3.9.2 required a patch to deal with cross-site scripting vulnerabilities. Almost 86 percent of the 75 million sites running WordPress were vulnerable, and although the CMS provider said there is no evidence any websites were compromised, it’s a hard pill to swallow considering that just a month earlier, 800,000 banking credentials were stolen using hacked WordPress sites, according to Data Breach Today.

Drupal Bugs

CMS Drupal, meanwhile, was hit by a bug in October, according to BBC. Twelve million websites were put at risk, and Drupal staff issued a prepared statement warning that if users didn’t take action within seven hours after the bug was discovered on Oct. 15, they should consider themselves compromised. Left unchecked, the bug allowed malicious users to create back doors and take control of websites.

According to Mark Stockley of security firm Sophos, Drupal should not rely on users to patch their own system after these types of CMS hacking.

“What Drupal badly needs but doesn’t have is an automatic updater that rolls out security updates by default,” he said.

Joomla Vulnerabilities

According to CSO Online, Joomla also came under fire this year when popular e-commerce plugin VirtueMart was hacked. More than 3.5 million websites use VirtueMart. When the plugin was compromised, malicious actors gained “super-admin” privileges. Anyone using versions prior to 2.6.10 were at risk, and for some companies, this meant going through the code line by line looking for problems, since they had large orders or other projects already in progress and plugin developers weren’t forthcoming with the exact code location.

All of the Above

More recently, SiliconANGLE reported that WordPress, Drupal and Joomla were equally vulnerable to a new packaged back door, CryptoPHP. Once installed, CryptoPHP could enable public key encryption for communication between a compromised server and a command-and-control (C&C) server, create manual back doors, remotely update the list of compromised servers and prevent takedowns of C&C servers via email communication.

The takeaway from all this CMS hacking is that common platforms are ideal targets for malicious actors, especially when they’re provided for free and don’t offer the same kind of security as for-pay software. The numbers don’t lie — it was a banner year for CMS hacks, and companies should be ready for even more in 2015.

Image Source: Flickr

More from Software Vulnerabilities

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

Critical Remote Code Execution Vulnerability in SPNEGO Extended Negotiation Security Mechanism

In September 2022, Microsoft patched an information disclosure vulnerability in SPNEGO NEGOEX (CVE-2022-37958). On December 13, Microsoft reclassified the vulnerability as “Critical” severity after IBM Security X-Force Red Security Researcher Valentina Palmiotti discovered the vulnerability could allow attackers to remotely execute code. The vulnerability is in the SPNEGO Extended Negotiation (NEGOEX) Security Mechanism, which allows a client and server to negotiate the choice of security mechanism to use. This vulnerability is a pre-authentication remote code execution vulnerability impacting a wide…

Containers, Security, and Risks within Containerized Environments

Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan. In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would…