Home > Security & Compliance > The Many Senses of Software Security
The Many Senses of Software Security

The Many Senses of Software Security

When the term “software security” is used, it may bring to mind security software, such as antivirus scanners, software-based firewalls, and vulnerability scanners, or it may bring to mind the security components of software tools that are used to authenticate users, generate audit trails, and encrypt confidential data.  What it should also bring to mind, however, is something more comprehensive–using best practices in software design, implementation, and testing to avoid common mistakes that create vulnerabilities in software of any kind.

Two recent stories in the news point out examples of software security issues where an apparent error in the software release process led to the release of production code with a “backdoor” which allows an attacker to gain administrative access to a family of routers without authenticating, and where software itself was a target of attack: a forgotten backdoor in the firmware of D-Link consumer router devices and the breach of Adobe (which led to exposure of the company’s software).

“Software security” isn’t just the use of software to provide security features like authentication and auditing, or avoiding common mistakes that produce exploitable software flaws. It’s also how source code repositories themselves are secured, and, most importantly, the standards and processes around how software gets designed, developed, tested, and released.

The D-Link backdoor, (re)discovered over the weekend by Craig at the “/dev/ttyS0 Embedded Device Hacking” blog, allows anyone who sets their web client user agent string to “xmlset_roodkcableoj28840ybtide” to have administrative access to a D-Link router via the web interface without supplying an administrator username and password.  If you look at the last part of that string backwards, it appears this was probably put in for testing purposes, but mistakenly left in the released code. Mistakes like this are all-too-common, where either debugging code is left in or, worse, where potential obstacles to development testing like authentication code are left out (as occurred on June 19, 2011 with Dropbox).  Checklists, automation, and a strong culture of testing is probably the best defense here.

The Adobe breach, announced on October 3, involved a compromise of the company’s network and theft of software source code including Cold Fusion and Acrobat. The details of how the breach occurred have not yet been published (and perhaps not yet determined), and also involved attacker access to customer account information, including customer information and encrypted credit card data. This was also a common case where there was at least a multiple-week delay between the breach and its discovery, which highlights the importance of network monitoring to detect attacks on your critical business infrastructure, whether that involves software as an asset or not.  While there is as-yet no word on whether the attackers modified any of Adobe’s source code (audits by Adobe are underway as part of their investigation of the breach), the source code is now out and available for attackers to peruse for flaws.

The mere availability of source code is, of course, unnecessary for an attacker to exploit problems in it, nor does it necessarily always provide an advantage to the attacker. Several of Adobe’s products have been notorious vectors of compromise for years before this breach, with vulnerabilities discoverable by either just attacking the exposed interfaces or reverse engineering the binary code. Open source software, freely available, has often been touted as more secure because more eyes are looking at the code for flaws, though in practice this seems to only be an advantage for projects which have active participation from people specifically trying to identify and correct flaws using software security best practices; the mere participation of many developers in different groups on the same project seems to result in more vulnerabilities.  In other words, how secure your software is depends not so much on whether it’s open or closed source, but on how it gets designed, developed, and tested.

About EarthLink Blogger

EarthLink Blogger
For more than 20 years, EarthLink has revolved around how to efficiently connect our customers with technology. Today, we are committed to making our customers’ customers happy with the technology foundation that underpins an exceptional experience. We have numerous industry and technology experts on staff at EarthLink, and each not only has extensive knowledge and experience in their field of expertise, but also a passion for ensuring EarthLink remains true to that commitment. They also enjoy sharing insights into the latest technology innovations in the hopes of informing and helping to reduce the burden on IT professionals.