The What
In 2008 a lot of reports and press centered around SCADA Networks and their protection, additionally Core Security and several other researchers released vulnerabilities in software related to SCADA networks. The most notorious was the vulnerability in CitectSCADA (http://www.coresecurity.com/content/citect-scada-odbc-service-vulnerability), which kicked off a lengthy discussion on protecting SCADA networks and other so-called critical infrastructure.
This got me thinking that the Sourcefire VRT should have some additional protections in place for these types of networks and the software that runs on them. So we set about learning about how these types of networks work, what runs on them, what protocols, and how they are configured. Luckily, I grew up with my bud Brian, who now builds coal fired power plants, and used to attend the local 2600 meetings with me 10 years ago. He brought me up to speed on how these networks are configured, deployed, and protected in real world environments, the main take-a- ways from this conversations where the following:
- HMI is the generic name of all monitoring and controlling software - This is essentially what CitectSCADA is, it monitors lots of sensors on the hardware in a power plant or other facility and returns the data it reads from those sensor to a central location were it can be monitored. Think of it as a massive SNMP monitoring station.
- Every device on the planet is different, they all have special things that can be monitored, and most of them run manufacturer specific protocols. Even if something runs something standard like MODBUS or IDP3 you still have to program your HMI to read the correct values from the device based of the vendor documentation. IE reading memory bank0 on device X gives you temperature, while reading it on device Y gives your pressure.
- Unless you work for the power company you aren't getting access to the devices and or sensors that run in these places to play with. Or your really wealthy. Neither of which I am, and I would fear for my life if me or my team had access to remotely controllable pressure values, temp gauges, and spinning disks. I know what I would build, and I know my team is even more creative than I am.
Given that I sat down and worked up the following. - A long list of free or shareware HMI applications that were available.
- A very very very short list of SCADA vulnerabilities. At the time I did my search it was around 3, all 3 being in HMI software non of which applied to SCADA specific protocols. i.e. you're not going to find a "pressure gadge XYZ when sent a malformed MODBUS packet results in the device failing open and letting all the pressure out"
- A threat diagram based on zones of trust for the typical SCADA network configuration.
This led me to the following goals for providing coverage for SCADA networks.
The Goals
- Cover any vulnerabilities related to SCADA software in reachable by traditional protocols. This would include CitectSCADA as the vulnerability travels over ODBC database traffic.
- Develop Snort rules for finding SCADA specific protocols. Specifically MODBUS, IDP3, OMRON-FINS, ELCOM, etc.
- Using the threat diagram determine what types of coverage categories SCADA networks would need. This resulted in the following:
- SCADA traffic leaving or entering a domain of trust. Most SCADA networks are designed in principle so that the SCADA traffic is on a specific network, and can only be accessed from very specific places.
- Locate malformed traffic - Malformed traffic can either be bad devices on the network, or bad guys on the network. Both of which are of interest.
- Locate critical commands and detect there existence - Uploading new instructions to a read only device, overriding a read only status, halting a device, or starting a device seemed like interesting critical commands.
With all that we could now start taking some of these protocols apart and building the correct coverage for each threat category. At this point I selected OMRON-FINS as the protocol I was going to investigate.
The How
Now that I knew what I wanted to do and what protocol I wanted to work with I needed to start diving into the details. This is the procedure that I worked through to get all the details that I thought I would need to go from concept to Snort Rules.
- Find all the documentation - http://forums.mrplc.com/index.php?showtopic=5693. MRPLC is an excellent resource for PLC / SCADA related devices and sensors. It has a ton of reference manuals that are hard to find, and some forums with excellent information from people trying to make certain devices work.
- Setup a client and server that can talk OMRON-FINS. This was a lot easier than I thought it would be, as OMRON-FINS is UDP and the first piece of HMI shareware I downloaded supported talking to these devices. Therefore I built my own fake client in perl and set about setting up the HMI software to talk to my simple UDP listener.
Setting up the HMI software as actually kind of fun as you got to draw visio like diagrams, call them sensor XYZ, define what type of values it would write and set, and arrange those sensors to control specific pieces of the diagram. At the end of the day I settled on a template of a engine with a temperature gauge, speedometer, and a gas petal. This allowed me to read the engine temperature, check the current speed, and make the fake engine go faster or slower with the gas petal. I even made the screen flash red if the temperature got to high. Once I hooked all that together the HMI software started sending me all kinds of OMRON-FINS UDP packets. Now I need to go back to the documentation and figure out what I need to send back to the HMI software in the form of responses so that I would show the values on the screen. This took a couple hours, as the documentation is a bit lacking in a few key areas. Additionally the guy who wrote it obvious knows how serial coms work, but never really grasp this whole Ethernet craze.
At this point I had a really awesome set of pcaps and other data to go work with.
Next I set about working up a Wireshark dissector for OMRON-FINS, I find writing a new dissector for a protocol makes my life easier as I can name things, break them out, do fun things with bits, and it results in a nice set of "code" documentation if I ever need to go back to this protocol in the future. Also its always fun to send some code back to a project you use all the time. You can find my patch to Wireshark here https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3226. It hasn't been added to the mainline code yet, but should patch nicely into code checked out of SVN.
In conjunction with the Wireshark dissector I build a unit test script for the Wireshark dissector that created one of every OMRON-FINS command, and one of every possible OMRON-FINS response. This allowed me to do two specific things, create a test case for each command, and a reason to read the entire OMRON-FINS manual. While doing that I would write down any command or response that fit my threat profiles from above, giving me a nice clean list of Snort Rules I wanted to
write.
The Details
The following is the list of Snort Rules I came up with that met my criteria above.
Interesting commands that wrote information to memory for the device to use later.
SCADA OMRON-FINS memory area write attempt
SCADA OMRON-FINS memory area fill attempt
SCADA OMRON-FINS memory area transfer attempt
Interesting commands that wrote information to the parameter areas on the device. These memory areas would then be used by other functions of the devices. IE parameters for functions.
SCADA OMRON-FINS parameter area write attempt
SCADA OMRON-FINS parameter area clear attempt
SCADA OMRON-FINS file memory write attempt
SCADA OMRON-FINS data link table write attempt
Interesting commands that wrote program code to specific areas on the device. Normally the device would be in a "protected" state were you couldn't write, unless the protection flag was cleared.
SCADA OMRON-FINS program area protect attempt
SCADA OMRON-FINS program area protect clear attempt
SCADA OMRON-FINS program area write attempt
SCADA OMRON-FINS program area clear attempt
Commands for starting or stoping a job on the device.
SCADA OMRON-FINS RUN attempt
SCADA OMRON-FINS STOP attempt
SCADA OMRON-FINS RESET attempt
I don't know about you but I think that messing with clocks is always bad, they are really important when the clock turns wheels, gears, or sets the timing of some event.
SCADA OMRON-FINS clock write attempt
Asking for more access is always suspect.
SCADA OMRON-FINS access right acquire attempt
SCADA OMRON-FINS access right forced acquire attempt
Writing and deleting files might be bad.
SCADA OMRON-FINS single file write attempt
SCADA OMRON-FINS file delete attempt
Anything with the word force in it you want to know about.
SCADA OMRON-FINS forced set/reset attempt
SCADA OMRON-FINS forced set/reset cancel attempt
Deleting and formating, hum.....
SCADA OMRON-FINS name delete attempt
SCADA OMRON-FINS memory card format attempt
Generic overflow protection on things that have fixed protocol lengths.
SCADA OMRON-FINS memory area write overflow attempt
SCADA OMRON-FINS memory area fill overflow attempt
And no brute forcing passwords thats not nice.
SCADA OMRON-FINS program area protect clear brute force attempt
The Conclusion
When working with new detection categories or coverage of unknown protocols, its best to following something like the above, especially if there is limited information about the types of threats that affect these types of networks or applications. This is the process we use here for this type of work and it has worked well for new protocols, new classes of vulnerabilities, and policy based detection of IM/P2P/and other applications people do not want on their networks. Feel free to give it a try next time you're working on something new, and don't forget to send your wireshark dissector to the Wireshark guys.