Open source PLC

[thiagoralves]

What about OPC UA?

OPC UA seems to be a nice idea, however I see it more as an integrator than a low level PLC protocol. Unfortunately, in the field we deal with 30 years old PLCs that barely know what is ethernet... That's the biggest issue to introduce security, because the hardware is essentially old.

Look interesting! Please do share any developments!

I opened a forum at openplc.discussion.community to discuss about the development process.

 

[mk42]

Unfortunately there isn't any PLC protocol that is secure, at least none that is used commercially. All of them lack the basic premise of security: encryption. In our lab, we've successfully hacked into the most used protocols in industry, Modbus included. I picked Modbus for a number of reasons. Modbus is one of the most used protocols in industry, is open source (no royalties to use it) and is relative easy to implement. I plan to include other protocols in the future, depending on how the research goes. For now, I'm focused in creating a better version of the modbus protocol that will be backward-compatible but that will also include some security features.

I'm curious about this. I'm not surprised to hear that a lot of the main protocols are easily hackable (I'm assuming you did Profinet, Ethernet/IP, etc). However, do the safety versions of those protocols have similar issues (Profisafe, CIP Safety)?

From what I understand while they aren't encrypted and you can easily read the data transmitted, they have protections against data injection and attacks like that. Thoughts?

 

[Thomas_v2]

I'm curious about this. I'm not surprised to hear that a lot of the main protocols are easily hackable (I'm assuming you did Profinet, Ethernet/IP, etc). However, do the safety versions of those protocols have similar issues (Profisafe, CIP Safety)?

From what I understand while they aren't encrypted and you can easily read the data transmitted, they have protections against data injection and attacks like that. Thoughts?

I only can say for Profinet/Profisafe, that it's not protected against data manipulation. The CRC which is transferred with the data, has only to prove that the transferred data matches with the checksum. So if you capture a PN-packet on the fly, you can modify the data, calculate the new CRC and sent it to the receiver. If you get this in the specified time, this should work. Therefore there are environmental requirements in network security, when you are using PROFIsafe. There's a special document which describes this (PROFIsafe - Environmental Requirements, V2.5; Order No. 2.232).

The new protocol which the S7-1500 and S7-1200 (1200 with new firmware) are using, has real data integrity in terms of network security. There is a challenge/response authentication on session setup. And each telegram contains a message digest. The message data itself is not encrypted (maybe there's an option to do fully encrypted communication). I think it's kind of HMAC, but the hash length's are not standard I think. So you can't easy modify telegrams, or just do a replay of a telegram sequence.
As far as I know, there has no one found out how the authentication works, so there are only Siemens drivers capable of using this type of communication.

 

[harryting]

Frankly, I don't have high hope for open sourced PLC. The few open sourced products that are successful all share a common trait; large customer-base, including large corporation that are willing to pay for support (but products are "free"). The reality is somebody got to pay for it.

You can always encrypt what ever insecure protocol you have and air-gap the rest.

 

[mk42]

I only can say for Profinet/Profisafe, that it's not protected against data manipulation. The CRC which is transferred with the data, has only to prove that the transferred data matches with the checksum. So if you capture a PN-packet on the fly, you can modify the data, calculate the new CRC and sent it to the receiver. If you get this in the specified time, this should work. Therefore there are environmental requirements in network security, when you are using PROFIsafe. There's a special document which describes this (PROFIsafe - Environmental Requirements, V2.5; Order No. 2.232).

I thought that there were secrets that were part of the CRC check, like packet number and profisafe address. Is this not the case, or are those trivial to detect/discover?

The new protocol which the S7-1500 and S7-1200 (1200 with new firmware) are using, has real data integrity in terms of network security. There is a challenge/response authentication on session setup. And each telegram contains a message digest. The message data itself is not encrypted (maybe there's an option to do fully encrypted communication). I think it's kind of HMAC, but the hash length's are not standard I think. So you can't easy modify telegrams, or just do a replay of a telegram sequence.
As far as I know, there has no one found out how the authentication works, so there are only Siemens drivers capable of using this type of communication.

Wonderware at least claims to have it sorted out: http://blog.wonderware.com/2016/01/siemens-direct-operations-integration.html

 

[rootboy]

Frankly, I don't have high hope for open sourced PLC.

Sad, but true. Anyone else remember the old "Puffin PLC" project? Nonetheless, I'm happy to see someone making a go of it.

 

[Thomas_v2]

I thought that there were secrets that were part of the CRC check, like packet number and profisafe address. Is this not the case, or are those trivial to detect/discover?

When the packet number is part of the CRC, then you also know the packet number if you are capturing the packet(s). I haven't done this for myself. Recently someone was working on the Profisafe plugin for Wireshark. And it calculates the CRC from the data-part, and compares it with the transferred CRC do show you if there is a mismatch. If it would not be possible to modify such telegrams, there wouldn't be a document which describes that you have setup a separate secure network for Profisafe.

Wonderware at least claims to have it sorted out: http://blog.wonderware.com/2016/01/siemens-direct-operations-integration.html

That's interesting. I've reverse engineered this protocol (search for s7comm-plus), it's complete and opensource since end 2014 I think. For a commercial product, you have to prove that you haven't done the reverse engineering by decompilation or such things. I' guessed that you won't get the keys without doing this. But I only have very basic knowledge in cryptograpy, maybe you can buy such informations from Siemens, if you pay enough....

 

[mk42]

When the packet number is part of the CRC, then you also know the packet number if you are capturing the packet(s).

Isn't this only true if you've been capturing from the beginning of the communication? Maybe you need to convince the partners to re-establish comms, and can then record from there?

The profisafe system description specifically says that the "consecutive number" isn't actually transmitted, and that the PLC/IO each have their own separate counter that runs.

I haven't done this for myself. Recently someone was working on the Profisafe plugin for Wireshark. And it calculates the CRC from the data-part, and compares it with the transferred CRC do show you if there is a mismatch. If it would not be possible to modify such telegrams, there wouldn't be a document which describes that you have setup a separate secure network for Profisafe.

See the attached image, about what protections the Profisafe system description says it has. I don't see any statements in the v2.5 environment document you mention that indicate specific weaknesses. I read it as recommending layered protection, which is a smart security practice regardless.

That said, you clearly have way more protocol dissection experience than I do; all I know about the bits and bytes of profisafe I've read from manuals.

That's interesting. I've reverse engineered this protocol (search for s7comm-plus), it's complete and opensource since end 2014 I think.

Oh my, you're THAT thomas V2. Thank you very much for your work! I've been using the classic plugin for a while.

I've tried downloading the newer plus plugin recently, but it doesn't seem to work with Wireshark V2 (or my PC, whichever). I haven't gone so far as to re-install V1, or try to compile the plugin myself yet. It looks like the most current S7comm-plus download is from early 2015, and is way behind the code in the trunk. Or maybe I have no idea how to use sourceforge. Both are strong possibilities.

I can submit a bug report, if that would help.

For a commercial product, you have to prove that you haven't done the reverse engineering by decompilation or such things. I' guessed that you won't get the keys without doing this. But I only have very basic knowledge in cryptograpy, maybe you can buy such informations from Siemens, if you pay enough....

I know wireless security (WPA2) is based on a mutual exchange of keys, so it is possible something like that is at play here between the two partners.

Regardless, I can't imagine Siemens playing nice with a competitor at that level. WinCC and Wonderware are direct competitors. I'd think they'd be more likely to let their PLCs act as an EIP controller first....

Anything's possible, though, I guess. $$$ does tend to change minds, even German ones.

 

[Thomas_v2]

The profisafe system description specifically says that the "consecutive number" isn't actually transmitted, and that the PLC/IO each have their own separate counter that runs.

Is there a free spec available for Profisafe? I know fields only from the wireshark dissector sources, and there seems to be an Framecounter inside the Profisafe part. If this number would be kept secret, then there must be a way that both partners know the start value. Otherwise the partners would not be able to check if the CRC is correct. I don't there are real cryptographic methods involved.
And then the partners have to calulate the missing frames, as Profinet IO allows at least a number >1 lost frames before resetting the application relationship.

Oh my, you're THAT thomas V2. Thank you very much for your work! I've been using the classic plugin for a while.

I've tried downloading the newer plus plugin recently, but it doesn't seem to work with Wireshark V2 (or my PC, whichever).

Yes I am ;-) Thank you.

In short: If you are using the latest wireshark release (v2.x), you don't need the s7comm plugin anymore. It's now a builtin protocol.

For s7comm-plus I send you a PN, I think all too much off-topic.

 

[mk42]

Is there a free spec available for Profisafe?

Not as far as I know, but if you google "Profisafe System Description" some useful pdfs are stored in a lot of accessible places.

This paper seemed to be a good discussion of the bits and bytes of the protocol.

https://dspace.vsb.cz/bitstream/handle/10084/83791/AEEE-2006-5-3-158-rofar.pdf?sequence=1

 

[Ken Roach]

Anyone else remember the old "Puffin PLC" project?

Oh, yes, I do. I regularly got trashed by those guys for being an "greedy" or even "evil" Allen-Bradley employee every time I questioned the wisdom of a DIY logic controller.

My recollection (which might be wrong) was that the open-source hardware side of that project was frequently delayed because the developer had to wait for the next month's Social Security check before he could order parts for a circuit board.

While I appreciated his dedication and enthusiasm, it got tiring of hearing how everything would be great and perfect if only everyone did hardware development and software development and firmware development for pure free-software idealism reasons.

 

[thiagoralves]

Anyone else remember the old "Puffin PLC" project?

The "Puffin PLC project" was an idea that was started at the Control.com forums. The actual implementation however was called "MAT" (Manufacturing Automation Tools"). MAT later evolved to MATiec, which now the OpenPLC is heavily based on. That's what I love about the open source community, you can always build upon someone else's work.

I've reverse engineered this protocol (search for s7comm-plus), it's complete and opensource since end 2014 I think.

So you are the creator of the s7comm-plus wireshark dissector plugin! I also need to thank you for that. My research group relied a lot on it to hack into the Profibus communication. I didn't participate much in this work since I was too busy working on the OpenPLC. But after they could understand the protocol (thanks to your plugin), everything got much easier.

I believe that without encryption and authentication, there isn't much you can do on a protocol in order to make it truly secure. As Thomas_v2 said, these protocols can't be protected against data manipulation. That's exactly what we did. We performed a MiTM (Man in The Middle) attack to intercept the packets and changed them before they reached the final destination. This is only possible because the information is sent clearly (without encryption) on the network. By doing so, it is possible to change any value (variable reading or writing, or any other command) in the packets without any of the parties to know about it.

 

[shooter]

could you please send same info to the arduino.cc community forum, as i am sure they will give a good review on you.
Please have a look at oscat.de for a vast library, (in ST available)
it is also open.

 

[thiagoralves]

could you please send same info to the arduino.cc community forum, as i am sure they will give a good review on you.

I posted a thread at the Arduino forum a long time ago, when I started developing the OpenPLC: https://forum.arduino.cc/index.php?topic=236945.15

Please have a look at oscat.de for a vast library, (in ST available)
it is also open.

I've seen the project, but all I could find about it is in German. Unfortunately I don't speak German...

 

[shooter]

for oscat: it is a german site, however the complete library, the txt version and the PDF are all in english available.

btw thanks for the update in arduino.

make contact to codesys.com, maybe they are intersted in you as a programmer.