Look out for the real dorks of content

Insecurity is brimming in content management systems, says Barry Schteiman

Several statistics-gathering engines on the web have suggested an interesting picture. Content management systems (CMSes) have become far more popular in recent years. A significant portion of the top websites rely on CMS.

And it's fair to assume that the proportion is even larger for companies that use a CMS as middleware for content on their front-end website.

Without exception, software throws up security concerns.

Yet when a company chooses a CMS to support online transactions, they rarely give any thought to the fact that the shopping cart mechanism, for instance, can be easily hacked, resulting in PCI violations and credit card and PII data theft.

This has the potential to become a big problem that we cannot ignore.

Vulnerabilities can be found in the CMS core, with a lot discovered in plug-ins and extensions.

One of the most interesting developments we've seen is the addition of item A9 to the not-for-profit Open Web Application Security Project (OWASP) Foundation's top 10 application security risks.

Item A9 describes the threat implicit in "using known vulnerable components". OWASP recognises the problem of using third-party code and applications – such as a CMS – with embedded known vulnerabilities and weaknesses when it comes to security breaches.

CMSes are a petri dish of vulnerabilities. They can be a path of least resistance.

The popularity of the CMS has been a boon for hackers, giving them a much larger surface area to attack.

This is fundamentally changing the way they operate. In the past, a hacker would identify a single target, such as an academic institution, bank, or e-commerce site, find a vulnerability in that target, and then exploit it to compromise or steal data.

That is to say, a hacker had to be a fairly enterprising individual willing to put in long, hard hours.

Now, with the vast opportunities presented by CMS, hackers don't need to break a sweat at all.

Because CMS is ready-greased for hacking success, hackers don't need to waste time and resources identifying targets. Instead of identifying one specific target, hackers use search engines to identify common security vulnerabilities in a CMS platform that enable them to accomplish server takeover and data theft.

There are thousands of these vulnerabilities. Websites can be "fingerprinted" according to the CMS that harbours the known vulnerability, and the fingerprint can then be quickly exploited in multiple CMSes in multiple companies.

As part of our hacker research, we investigate different botnets managed by cybercriminals and monitor their activity. We see a huge opportunity for hackers to move from manually infecting computers online to simply adding them to larger botnet schemes.

To do this, they can use different identification mechanisms, such as Google Dork, to identify CMSes and other third-party vulnerabilities. This makes it easy for hackers to inject malware and on-board infected servers for later use.

In the past, hackers focused on hacking personal computers. Nowadays it makes more sense to focus on CMS servers.

It takes a lot more time and effort to breach a PC or device. Hacking a CMS server is cost-efficient. If a botnet's goal is to create DDoS attacks, 100 servers could potentially have the same impact as 100,000 infected PCs or other devices.

From a hacker's perspective, it just makes good sense to focus on servers as targets. It's quicker, easier and cheaper.

I encourage companies to "dork" themselves, and learn as much as possible from people who know the evolving risks and threats, as well as the necessary precautions.

Monitor your customers' applications carefully and promote real-time alerts on web apps that track against a baseline of behaviour. Promptly investigate all anomalies – reviewing logs now and again won't fend off attackers.

Assume all third-party code has countless security vulnerabilities. And don't assume the software development life cycle will fix these problems automatically. Specific code authored by someone else is not controllable within your environment.

It's impossible to fix code you don't own. Vigilantly patching vulnerabilities, coupled with physical and virtual patching, can help protect customers from these evolving security threats.

Barry Shteiman is director of security strategy at Imperva