Attacks on open source call for better software design
Connecting state and local government leaders
With as much as 90 percent of the code used for in-house development is based on pre-fabricated modules, we need better tools that scan components for potential vulnerabilities before they are tied into actual products.
Another day, another major vulnerability for government systems, it seems. This time it affects Drupal, a popular, open source content management system that’s been used for an increasing number of agency websites, including the White House.
An announcement from the organization that oversees Drupal warned several weeks ago of a vulnerability that would allow an attacker to use an SQL injection, where malware can be inserted into a system because of an error in database code, for example. Depending on the content of the attacker’s request, it said, the attack could lead to privilege escalation, arbitrary PHP execution or other scenarios that put data at risk.
However, the real danger of this vulnerability was revealed several weeks later, when the Drupal organization put out another announcement warning that, even if the patch issued at the time of the original announcement was applied, timing was critical. If sites weren’t patched “within hours” of the vulnerability announcement, the damage may have already been done.
Automated attacks began compromising sites shortly after the vulnerability was revealed, and those who waited to patch their systems then should assume their sites were compromised.
Even if the system appears to be patched, the Drupal organization warned, attackers may have “fixed” it themselves after they injected their malware, in order to keep other attackers out and to try and fool IT administrators into thinking it was safe. Attackers may also have created backdoors to later get into affected systems .
If timely patches weren’t applied, then the Drupal security team outlined a lengthy process required to restore a website to health:
- Take the website offline by replacing it with a static HTML page.
- Notify the server’s administrator emphasizing that other sites or applications hosted on the same server might have been compromised via a backdoor installed by the initial attack.
- Consider obtaining a new server, or otherwise remove all the website’s files and database from the server. (Keep a copy safe for later analysis.)
- Restore the website (Drupal files, uploaded files and database) from backups from before 15 October 2014.
- Update or patch the restored Drupal core code.
- Put the restored and patched/updated website back online.
- Manually redo any desired changes made to the website since the date of the restored backup.
- Audit anything merged from the compromised website, such as custom code, configuration, files or other artifacts, to confirm they are correct and have not been tampered with.
This year has been “Annus Horribilis” for open source software used in government. The Heartbleed OpenSSL bug revealed in April was considered “one of the scariest ever” in terms of its potential for attackers to get access to data. A steady stream of scares followed, and by October when the Shellshock bug in Linux and Unix operating systems was announced people seemed to be suffering from bug fatigue, even thought it was deemed as potentially damaging as Heartbleed.
Consequently, warning bells started ringing, again, about the inherent security of open source software. As the theory goes, open source is, by nature, open to the widest range of bad guys who could compromise it. Various industry types have tried to downplay that, however, putting it down to human mistakes that could happen anywhere.
Others point out that most of the compromised software has one thing in common: it was built on pre-fabricated modules. That’s generally considered a benefit. Because developers don’t have to repeat what’s gone before, they can use a more Lego-like approach and only write code where it’s needed.
That leads to a much speedier time to market, but it also means that whatever errors are included in those modules gets passed along. Some security vendors estimate that as much as 90 percent of the code used for in-house developments is based on these components.
We need more and better tools that scan these components for potential vulnerabilities before they are tied into actual products. That’s something the National Institute of Standards and Technology, for example, has recognized with its recent effort to develop better guidelines for systems and software design.
On a related note, Google recently came out with its nogotofail tool that can be used to test networks for weak transport layer security and secure socket layer connections. That won’t address every bug out there – it doesn’t address the Drupal bug, for example – but it will go some way toward fixing the kinds of vulnerabilities that Heartbleed and similar bugs introduce.
NEXT STORY: 10 ways to recharge cybersecurity ops centers