The term Protocol Differential Analysis needs to make Google as an infosec technique. I first heard the term from esSOBi at Indianapolis’ Circle City Con. I first encountered the trick, though, in a research lab a few years before: a quick and dirty tool was written by a colleague there to help analyze a very, very bizarre serial protocol.
The problem, briefly explained, is this: as an attacker, we want to find out what interesting packets are in a conversation between a controller and its engineering software. For example, we want to find out what packet represents the ‘Stop CPU’ command in a proprietary protocol. Since the protocol is undocumented, we are left either reverse engineering the master application, which can be extremely time-consuming, or analyzing the protocol stream itself to find the interesting packets.
Protocol analysis is often the easier path. Unfortunately, industrial proprietary protocols are extremely ‘chatty.’ Based upon the classic industrial poll-response model, the protocols may be sending tens or even hundreds of packets per second back-and-forth between the PC software and the industrial controller. By the time we interact with the software and click the ‘Stop CPU,’ button on a graphical interface, we may have thousands of packets to dig through. We want to find the packets that are interesting, but end up wading in a river, looking for the raindrop that holds the key to an attack.
The trick is pretty simple: analyze a protocol stream and build up a list of unique-looking packets. Once communication to a controller is established, the conversation tends to be cyclic: the PC software polls the controller for a series of data elements. Once the complete list of interesting elements has been read, the PC software starts over at the beginning. Only when a manual operation is performed is there any deviation from the poll-response pattern.
Knowing this, differential analysis turns into one of the most useful techniques for industrial protocols, especially for proprietary and undocumented ones. It was the technique that allowed us to crack a lot of the functionality of Modicon’s now-imfamous Function Code 90, letting us to both stop control and retrieve and upload new ladder logic to these devices.
The solution is quite simple, actually. A quick software tool is written to analyze the packets and look for unique packets. Each time a unique packet is observed, its index in the stream is noted. ‘Unique’ is a relative term of course: we need to ignore certain fields (timestamps, session ids, packet numbers, CRCs, or other fields that seem to change frequently during a conversation).
The picture above shows it being applied to the CoDeSys v3 protocol during the exploration phase of that protocol. We connected to the PLC using the CoDeSys engineering software, and sent a start and then a stop command back-to-back via the GUI. The tool takes a few arguments: a pcap file, whether the protocol you want to look at is tcp or udp, the port number, and a comma-separated list of byte indexes to ignore. During testing of CoDeSys v3, we found that there is a session id (2 bytes) and two sequence ids (4 bytes each), as well as a few other bytes that change, so we want to ignore those bytes for packet comparison purposes. In the output, we can see that the login process requires quite a few packets, but after packet 173 the conversion becomes cyclic. Packets 1142 and 1620 represent the ‘start’ and ‘stop’ commands respectively, and the packets after them contain unique responses. Now can attack the Hitachi EHV+ line, or other controllers which speak the UDP version of the CoDeSys v3 protocol.
I’m happy to share a really basic (and hastily-written!) tool for performing this analysis. This tool was used for attacking Modicon PLCs as well as versions 2 and 3 of the CoDeSys protocol, and is available here. It relies on scapy in order to grab the payload of packets, simply because we wrote it in 20 minutes and didn’t want to write our own IP and TCP/UDP parsers. Simply save a .pcap of your communication with a controller, and apply the tool to start learning about the protocol.
Internally, Digital Bond Labs is developing and using a more advanced version of this tool. Ideas thrown in with the kitchen sink include the ability to plug in protocol parsers for aiding in the differential analysis. This allows us to better analyze OSI protocols (Open Systems Interconnection, not Pi) that contain many layers of protocol to analyze pre-payload, deal with protocol encryption, and perform other weird and academic analysis.