Tech Insight: When Security Products Attack

What happens when the very products enterprises buy for security introduce vulnerabilities of their own? As we've seen through recent attacks on HBGary, RSA, and Comodo, even security products can fall prey to vulnerabilities, such as buffer overflows and directory traversal attacks.

It's easy to assume that security tools are themselves inherently secure. But the truth is that security products are no different than the applications suffering from zero-day vulnerabilities on our desktops -- they are all written by human programmers who sometimes make mistakes that lead to vulnerabilities.

Harsh reality: Security products need to undergo the same scrutiny as any other piece of software or appliance that is being considered for deployment.

Enterprises should not blindly bring in a new security solution. Just as they do with nonsecurity products, IT organizations should evaluate the risk associated with a new security tool, determine whether secure code practices were followed during its development, and perform a penetration test of the solution in a test deployment.

The first step is to perform a risk assessment to ensure the placement of the appliance or installation of the software will not negatively impact the security of the environment. Important questions need to be answered: What would happen if an attacker were to exploit a vulnerability in the software? What can an attacker break or steal by gaining access to the system?

In late 2006, the "Big Yellow" worm provided some scary answers to those questions. Attackers were able to gain full remote administrative access to Windows systems running a vulnerable installation of Symantec Antivirus. From there, the worm joined the systems to a botnet, allowing an attacker to gain remote control of the exploited system.

Had a risk assessment taken place, organizations might have understood how to better lock down the product. The vulnerable ports used for remote management could have been restricted to only communicate with the management server, greatly reducing the spread and impact of the worm.

Many enterprises simply forget to ask their security vendors whether they follow secure coding practices. Do they have a software development lifecycle (SDLC) that includes security testing? Most likely, the person on the phone will say they do, so press them for more information. Do they perform source code audits? What about third-party analysis and penetration testing?

Of course, in this scenario you will have to take the vendor's word on what it actually does. Still, talking to it and learning about its processes (to the extent it will share them) can be reassuring. And it's something that can be brought up later should a problem occurs -- how did the vendor miss the flaw, and what is it doing to improve the situation?

Penetration testing during the product evaluation phase -- or against a small test deployment -- can also reveal security concerns that could have been missed during a risk assessment. Installation of the product might require a change in access controls that end up weakening the current environment. Or the product might contain a vulnerability that can be identified through a vulnerability scan, fuzzing, or other testing.

Many security solutions now offer Web-based management interfaces, which can lead to a breach, experts say. A compromise of the management interface could expose the entire enterprise to attack. It might be subject to cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injection, or unauthorized remote command execution -- all vulnerabilities you don't want to see in your security product's management Web interface (or any Web app that belongs to you).

Sometimes the vulnerabilities stem from the underlying Web server bundled with a security product. Two examples come to mind: In one case, a vendor used an outdated installation of Tomcat that led to a compromise, exposing a few hundred thousand patient records. While an interesting forensics case, it was extremely painful for the breached customer, and it could have been prevented had the solution been evaluated before deployment.

A second was the discovery of a similar vulnerability in a JBOSS server. During a penetration test, a server was found to be exploitable, allowing full remote access to the Windows server running the vulnerable JBOSS service. In this case, the customer gave information to the vendor on how to fix the problem before buying and deploying the security tool.

No one expects a security product to contain vulnerabilities, but it happens. Performing a risk assessment, asking the right questions, and doing penetration testing can help reduce -- even prevent -- a vulnerability from making a huge impact. Remember, you're paying money for the product to help secure your environment, not make it less secure. Take the proper precautions to ensure it does the right thing.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.