Is there any point in writing a standalone SCADA vuln scanner/fuzzer in 2008?

It seems like the Modscan talk at defcon has got some folks thinking

Over the last couple of weeks I’ve been writing it in Ruby. At the moment it is more of a series of classes as a framework for communicating with SCADA ModBus devices either over TCP/IP or Serial. Included are some specific functionality to Enumerate Functions supported by a device, along with discovering the Slave Devices on the ‘network’. I say network as a more generic term as the Serial Connections are not specifically a network, but the code is able to enumerate slaves on a serial bus none the less.

The code doesn’t implement a full all singing and dancing ModBus API just a subset, but it is extendable to allow this. It provides a usable framework for building a valid message that can be sent, which is key for Fuzzing a device.

One of the key features is the code is able to be extended to include other SCADA protocols, I’m looking at a couple of others there too. Another element I’m looking at is code to test against Master devices on the SCADA network, at the moment the majority of the code is designed to look at a Slave device. But I’ve put together the basics of a ModBus Slave to allow me to do bad things to a Master that connects to it.

Now I'm probably letting my own jaded view of both fuzzing and dealing with SCADA protocol implementations cloud my judgment, but my take is that writing a Modbus (Serial or TCP) fuzzer in late 2008 is about as pointless as writing an FTP fuzzer in 2005.

But this blog entry is further evidence that the cat is out of the bag. By 2008 most of the big vendors have found all the low hanging fruit with Codenomicon, Mu, or Wurldtech but who knows, maybe some of the more obscure SCADA protocol implementations will end up at Defcon next year and we'll see yet another SCADA vuln press cycle.