Shellshock attacks against MTAs could leave SMBs exposed

Large enterprises are likely protected, but the SMB space is a viable target

serverskulls header
Jen Anderson

Yesterday, I reported on some research I did over the weekend concerning targeted attacks on mail transport agents (MTAs) via Shellshock.

While such attacks aren't the end of the world, and are preventable, they have the ability to hit the SMB market dramatically.

Small businesses have that name for a reason. They're small, so they don't have the ability to manage risk the same way a large enterprise does. In some regards, a small business is more agile and can adjust change faster, but when it comes to security that's not always the case.

Most SMBs have the basics in-house, such as Internet, telecommunications, etc., but development and scaled infrastructure needs are outsourced and hosted. Looking at risk, SMBs focus on the most essential security needs first, leaving the others for later (assuming they get to them at all).

Outsourcing hosting and development enables an SMB to meet their technology needs at an affordable cost. Data centers offer self-managed hosting, which is cheaper than managed dedicated hosting, and developers can complete projects quickly for little investment.

But the term self-managed in the dedicated server hosting market means just that, so many small business owners are on their own when it comes to security. Likewise, outsourced script development means that changes come with a cost, and comes with the risk that it's a different developer (with their own unique style) doing the work. Just as too many cooks and spoil the soup, too many developers can spoil code.

Depending on the situation, if the SMB is self-managing their hosting, the NOC didn't upgrade the server, that's the client's responsibility. Moreover, the NOC didn't check scripts for vulnerabilities, that's something the client's developer needs to do. NOC teams are happy to help a client manage their hosted systems, but for a cost.

The reality is that most SMBs don't want to pay for extended management and support, they just want the technology to work, as expected, no questions asked.

In my experience, it's a basic truth in the SMB space: business growth is the primary concern – technology (including security) is just an ends to a means.

The MTA attacks using Shellshock highlight a weakness in the hosted SMB market, because there are plenty of development servers and hosted accounts using vulnerable platforms or services just ripe for the picking.

This leads to a situation where a functional system - one that has never broken down - sits forgotten; missing a patch that would prevent the attacks that I observed last weekend.

Another problem are the systems that are left alone because they use scripts or applications critical to the SMB's needs, but changing them impacts the business.

For example, I once worked in a place where the business owner refused to update PHP script because he didn't like the way the UI changed. Updating PHP on the server broke the script, so that wasn't an option either. Instead, the vulnerable application was kept in production for years, until the business owner moved over to Salesforce.

Here's another example: While researching the MTA story, I discovered a script for monitoring sendmail (one of the MTAs targeted in the attacks), which required a patch in order to avoid Shellshock exploitation. While the script's author was quick to fix his code, how many users actually updated their installations?

A script like that would have been used by someone to address a security need for the SMB (anti-spam), and as long as it's working, it isn't likely to be checked or updated.

Right now, on, there are nearly 500 pages of code snippets, scripts, and programs dedicated to email. How many of them are vulnerable to attack, or tied to Bash in a way that would enable Shellshock exploitation on an unpatched system?

Using external code and outsourcing development is fine, but there's a need for caution.

"As any other coding exercise, expecting the worst by input validation and output sanitation are effective approaches to minimizing this sort of risk," said Tim O'Brien, director of security threat intelligence at Norse's DarkWolf Labs.

"In addition, looking at alternative way to address the same operational need without calling shell commands would be prudent; as well as patching and hardening the operating system and applications."

SMBs should make sure that Bash has been properly updated in all of their systems, especially those that deal with email in any way. Once that's done, scripts that handle email or communications need to be checked as well.

When it comes to outsourcing hosting or development, it's wise to fully vet the developer and ask them about security designs and plans. If there is a way to get updates and fixes in a timely manner, it's worth the cost.

Likewise, talk to the NOC and ask them about various levels of support and management. While full management could be off the table, partial management – including patch management and security help – is also worth the additional expense in the long term.

Bottom line, patch Bash. Patch it right now.

"The first line of defense is to mitigate the vulnerability at the server side," said Rod Soto, principal security researcher lead for Akamai PLXsert, when commenting on yesterday's MTA attack story.

"If the servers are patched, or updated at this point the probability of exploitation using Shellshock is very low."

Copyright © 2014 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)