Aegis Update and Vulnerability Debate

Adam Crain has a very interesting blog post over at Automatak.net providing additional information about his Aegis project (earlier blog post on Aegis). The Aegis Consortium is an important new business model for researchers and for that reason alone this post is worth reading. More importantly, he is adding an important new dimension to the disclosure debate.

Background

Adam is relatively new to the control system security field, but he has already made a significant mark. His first vulnerability discovery was reported by ICS-CERT in June of this year and he already has 8 ICS-CERT advisories with his name on them (along with Chris Sistrunk). All of these have been coordinated disclosures. His Project Robus lists 17 additional vulnerability disclosures that are wending their way through the coordinated disclosure process.

All of the disclosures that have been made public to date have dealt with vulnerabilities in various implementations of the DNP3 protocol. I assume that a number of the pending vulnerability disclosures will also involve that protocol. Adam is quick to note that the problem isn’t with the DNP3 protocol, but with the various implementations by the affected vendors. In fact he goes so far as to say “we have yet to find a proprietary DNP3 implementation without an issue”.

Fuzzer Tool Release

Adam developed the fuzzer tool that he used (again along with Chris and a new associate Adam Todorski) to find these 25 vulnerabilities. Now fuzzer tools are not new in the cybersecurity realm, and I don’t know what make his different than others, but his tool certainly has an impressive early track record. Adam has promised that he will publicly release his fuzzer in March at the SANS NA ICS Security Summit.

Again, I have no idea how user friendly his fuzzer is, but presumably anyone with a modicum of cybersecurity research experience will be able to use this tool to find new vulnerabilities in control system applications. Adam has demonstrated its efficacy with DNP3 so any vendor with a DNP3 application has cause to be concerned that currently undiscovered vulnerabilities in their systems might not remain undiscovered for long after this tool is released.

Now a fuzzer is just a tool, not inherently good or bad. A security researcher like Adam puts it to good use identifying vulnerabilities in a system and reporting them to the vendor. A vendor can use it to find and correct the same vulnerabilities. And a terrorist can use it to find a way to gain system access and control for part of a control system attack.

With this in mind, Adam is offering vendors and researchers access to his fuzzer before its public release; for a fee. After all Adam needs to make a living just like anyone else and he should be able to profit from his talents and efforts.

Vulnerabilities are Available

Some will complain that Adam is making the job of the black hat hacker that much easier by making this tool publicly available. I would seriously disagree. With making this tool available to vendors and other white hat researchers ahead of time, Adam is decreasing the potential attack surface that is vulnerable to attack.

Any criticism of Adam’s making this tool publicly available ignores a very important point in the vulnerability disclosure debate. Adam did not put these vulnerabilities in the DNP3 implementations; he just made them easier to find. They were put there by vendors that did not do an adequate job of testing their product before they made them available to the public. It is the vendor, not the researcher, who is responsible for the vulnerabilities.

Now it is hard to blame the vendor when the owner/operators have already given them a free pass for any vulnerabilities that exist in their systems. We as a user community have accepted the almost universal vendor terms of service that declaim that the vendor is not responsible for any defects in their product and that they don’t warrant its use for any particular application. As long as we give vendors a free pass on the quality of their products, we have little room to complain about the existence of vulnerabilities or researchers who find them.