Automatic Fuzzer Generation

Following up my last post on fuzzing an unknown proprietary protocol, we’ve now got a collection of packet captures to start ripping through to get some semblance of a fuzzer going to send packets to our target. Theres a few routes we can go, something as simple as flipping bits and putting garbage data into the stream all the way up to building a network model. I’m not big on either of the extremes. Flipping bits definitely works, but it tends to take a long time and you have a ton of crashes to dig through, and building a full protocol model can sometimes lead to great results and sometimes lead to terrible ones because you built something that works too well.

Auditing Protocols in Control Systems

Thanks to the near constant stream of “the sky is falling, these protocols aren’t secure” presentations at security conferences around the globe, everyone is familiar with mainstream ICS protocols, Ethernet IP, DNP3, and of course Modbus, amongst others. And of course it is important to make sure that these protocols are implemented correctly to assure that the devices supporting them function reliably. Generally, these protocols aren’t on the “front lines”, they’re going to be behind at least a couple of firewalls, probably a dmz, and if someone was interested in causing trouble then by the time they’ve gotten access to the parts of the network that these protocols live on, they’re able to do anything they want.

What Authentication Isnt

To a lot of you, this is post isn’t going to tell you anything you don’t already know, but for others I think it needs to be said again. MAC and IP addresses are easily changeable and are useless for authentication.

Far too often when we’re on site we see security measures that rely heavily on them, and its something that we need to move away from in control systems. We need to decouple connectivity and authentication. This is bad enough on the control network itself, but often it goes past that point and extends out to the corporate network, allowing a handful for special ips to access the control systems, essentially rendering your firewall useless.

Code Signing, Misconceptions and Realities

Code signing is a security feature that has been around for quite some time, and has been proven in many other areas, but is uncommon to find it in any control system component and very rare to find in control devices where firmware uploading is an important feature. Without a doubt the technology is useful, and provides a high level of assurance that the code running on the device is the code that you want running on it, but lately I’ve been in too many conversations where code signing is seen as a panacea for any and all security issue we may ever face and many involved in securing, administering, or pontificating about control systems don’t have a real understanding of the technology even as they praise or denigrate it.

Do the Dumb Thing First

This phrase was hammered into my head during an uncharacteristically interesting AI class during college (I later dropped the class, my hats off to those of you who enjoy writing search algorithms all day, I’ll never compete with you for a job), and it’s something that I remind myself of constantly when doing assessments. Much of the work of attacking systems is doing the dumb thing first, a burglar wouldn’t bother to kick in a door without seeing if it’s unlocked first and neither would a hacker. As exciting as vulnerability research is, the truth is that systems usually aren’t compromised by using 0day, and most vulnerabilities aren’t going to be exploited until someone has put it in an easy to use tool.