"Many Cyber Security experts view file objects as purely elements in the IT space, but this is a dangerous oversight."
- Andres Andreu, CTO of Bayshore Networks
blogfileobjects

Contrary to a common theme I have encountered in our industry, file objects (i.e. files) are a very relevant element in the ICS Security space. Many Cyber Security experts view file objects as purely elements in the IT (i.e. Enterprise) space, but this is a dangerous oversight. The transferring of file objects across networks, especially when there is a security domain boundary crossing, with target destinations being IIoT/OT devices, is an area of great importance and concern. This write up does not cover scenarios such as that of a human walking up to a device and inserting a USB stick, our perspective here will be network centric and revolve around the traffic that is generated when a file object is transferred. To give this arena some context, here are two overt examples that are very much real-world and should certainly be at the forefront of your thoughts as you read this article:

  • firmware updates
  • program (instruction sets) and/or ladder logic files

These two areas of interest typically have some downstream industrial device, such as a PLC, as the destination. But ultimately, both consist of actual file objects. The source of course varies, but typically programs and logic files come from workstations that are generally nothing more than PC’s, and typically run Microsoft Windows (and of course at this point in 2019 we all know these tend to be outdated versions of that OS).

These Windows machines, both old and modern, that run typical sets of software for HMI’s and Engineering workstations traditionally support file shares and sharing in native form (i.e. SMB/SMB2/CIFS). While this may seem unrelated to the space of IIoT/OT Security, that is a misconception, and something that should not be overlooked. In many cases, these Windows machines of interest sit on the ICS or OT networks themselves, or at least have direct communications with the industrial devices we aim to protect. So a file transfer to/from a Windows machine can have either a direct or an indirect impact on the downstream equipment that we need to protect.

File transfer mechanisms and details vary wildly from protocol to protocol so generic security is near impossible. But the task is entirely possible and simply requires disciplined and subjective work. Protocol specific implementations will be the only way to support security functionality in respect to scrutinizing, or scanning, file objects. And this scrutinizing is necessary, especially for those who think their networks are actually isolated and segmented. Here are just some basic questions to ask when either implementing a relevant security mechanism, or just analyzing how tight your security actually is:

  • Are your file transfer destinations actually set to only receive file data from specific sources?
  • How protected are the sources that can initiate file transfers that ultimately touch your IIoT/OT space?
  • If you have a Diode (or Unidirectional Gateway) in place can a file that is malware still make it to your protected destination devices? I mean the Diode may enforce unidirectional data flow, but what if that flow is actual malware? Is that Diode reconstructing that file object in memory, or on fast disk, and scanning it or scrutinizing it in any way?

It is only a matter of time before attacking entities figure out how to simulate the network traffic that comprises a file transfer in the manner we are discussing here. I would gamble that the more sophisticated entities already have this capability. So now imagine for a bit… Is it possible that they get a firmware update file, modify it at a binary level, then run code on your network that performs a seemingly legitimate firmware file transfer to a PLC? This is not far fetched, and I can tell you from first hand experience that we have done this in our own lab. So, if we have done it, I am certain the ability exists out there.

Let’s put the healthy paranoia aside for now and move on… For the sake of a real world example we will look at a s7comm protocol based firmware file transfer from an engineering workstation running “Siemens Totally Integrated Automation” (TIA Portal) to a Siemens PLC. When analyzing network traffic the commencement of the firmware file transfer is identified by the s7comm “Request download” function inside of a “Job Request” message while the end of this process is identified by s7comm “Download ended” function inside of a “Job Request” message. Figure 1 will give you a sense of what the commencement data looks like after Wireshark has decoded it while Figure 2 does the same for the end of the file object transfers.

Figure 1

Figure1

Figure 2

Figure2

Buffering up the relevant payloads from the relevant packets (within the “Request download” and “Download ended” boundaries) in order to properly reconstruct the relevant file objects is beyond the scope of this article. But you need to understand that this reconstruction process is critical to IIoT/OT Security functions and:

  1. requires domain expertise
  2. is generally unique for each protocol

An interesting discovery in our example is that when performing the firmware update function within the s7comm protocol multiple file objects were actually transferred under the hood, even though we initiated the action of a single file firmware update. In our example the single file firmware update action generated 3 files to be sent to the PLC:

  • CPU_HD.UPD
  • BG_ABL.UPD
  • KOMP_1.UPD

This hidden set of actions should make it clear that domain expertise is critical to be able to build subjective, effective and intelligent security solutions for IIoT/OT environments.

Some of the protocols that support file transfers, and are related to the IIoT/OT spaces (whether tightly or loosely) are:

  • DNP3
  • S7
  • FINS
  • HTTP(S)
  • TFTP
  • SMB/SMB2/CIFS

This list is clearly not meant to be exhaustive, but to give security practitioners some starting reference points to expand their domain expertise.

So, once you are able to properly reconstruct file objects, you need to be able to take meaningful security actions based on some file content and/or meta-data. But first you need to be able to handle file object type. The reason for this is that these file objects can come in the form of archives (i.e. zip files, tarballs, etc.), or consist of file objects embedded inside of other file objects (think back to the days of Object Linking & Embedding [OLE] for instance). Some examples of interesting file objects (i.e. just not a single obvious file) we have reconstructed from network streams on industrial networks:

  • self extracting Zip archive file
  • archive containing PDF with embedded executable
  • 100% undocumented binary formats

Determining file type certainly has different camps, and there are obviously multiple approaches. But whichever one you choose understand that this will take you down a specific code/logic path, and the importance of this is not to be taken lightly.

One area that can be of instant value is that of signature (i.e. one way hash) comparisons. Obviously these comparisons can be used for both whitelisting and blacklisting on network communications, and easily add value to the security function in the IIoT/OT spaces. So long as the protocol specific reconstruction process is accurate, this becomes possible. If however, your process is off by even one byte, the signature comparisons will fail. This pushes the boundary into the possibility of fuzzy hashes, such as those generated with ssdeep. While mileage may vary, it is certainly an interesting area to be explored to see if there is security value in its use. I will save that for a subsequent article, so that we can stay focused here.

Signature matching is simply valuable at a rudimentary level. But it will only be as good as the mechanisms reconstructing file objects. In the case of archives, this means inflating the content inside the archive and scrutinizing each of those extracted file objects. We, at Bayshore Networks, shared software with the world that performs this type of functionality, and that can be seen in our yextend project. A point of added value here is some data set, whether internal or external, that represents known signatures of malware files. Matching queries can be made via API’s to external sources, or just in-memory for higher speed environments. There are plenty of solid external sources for this type of data, 2 obvious examples come to mind for those who want to learn more, and do so while keeping costs down:

Figure 3 gives you a simple sample of one query against the data store provided by the generous team over at VirusShare. They provide lots of good meta-data and relevant links to VirusTotal when possible. For those who are curious the VirusTotal link at the bottom of Figure 3 can be found here.

Figure 3

Figure3

That list of 2 external malware data sources is certainly not exhaustive, but just a starting point for entities that are starting to explore this space, especially those in the IIoT/OT spaces. Ultimately the key takeaway here is that files are indeed relevant in the security space as it relates to IIoT/OT network traffic. The value of scrutinizing files of this nature will be fully dependent on the ability to accurately reconstruct file objects as they flow across network links, and that endeavor is 100% protocol specific.

 

I urge you to take a look at our  recent trial offer  and try Beacon free for one month.

I look forward to your comments and questions.
Andres Andreu, CTO of Bayshore Networks