OPC Vendor Security Limitation?
There’s been a delay in releasing the final paper of the three part OPC Security Whitepaper series as the paper has been going through some extensive testing. Our initial testing was with a limited amount of servers as a large amount of OPC servers exist and we’ve started to build a list on the SCADApedia noting the CLSID’s and version numbers. In a later blog I’ll show how this information is useful, but for now back to the vendor problem (or what appears to be a vendor problem).
This is a little sneak peek from our paper that discusses defining the DCOM’s endpoint configurations for a particular application, in this case, OPC servers. If you review the properties of the OPC Server you will notice the endpoint tab section which is particularly helpful for defining firewall rules as the RPC service will just dynamically allocate a port for the OPC communication. Actually the initial conversation takes place over tcp/135 and there after the RPC/OPC communication occurs over the defined endpoint or a dynamically allocated port if one was not defined.
So the problem I ran into, some OPC servers seem to ignore the defined endpoints that I entered. Further analysis and testing revealed that this limitation is tied to the vendor or developer of the OPC server itself. This makes securing a OPC server even harder and only leaves the option of defining a range for ALL RPC SERVICES or making a wide open firewall rule.
Why would vendors not implement something the rpcss service could read to handle the communications over another port? I have somewhat weak development skills, but I’m assuming this is more of a lack of strong development and QA. Is this something the OPC Foundation can chime in on or make mandatory?
In the small lab test, I installed five OPC server demos. I used Lluis’ and Ralph’s OPC security tools just to test ongoing OPC communication and had tcpview listening on the actual server for pretty netstat view. I could have used wireshark, but there’s no need as tcpview will provide (and highlight in eye piercing green) the new connections that are established between the OPC server and the OPC test tools (on another machine).
Here’s the list of servers I used (in a format output by Lluis OPC Security Checker)
C:\Program Files\neutralbit\OPC Security Tester>opctest 2kdev -l -u administrator -p xxxxxxxxx
OPC Security Tester v1.0 - NeutralBit (c) 2007[*] <Init> Server #0: Matrikon.OPC.Simulation.1 (Matrikon OPC Server for Simulation and Testing) {F8582CF2-88FB-11D0-B850-00C0F0104305}
[*] <Init> Version: 1.1 (build 307)
[*] <Init> Vendor: Matrikon Consulting Inc (780) 448-1010 http://www.matrikon.com[*] <Init> Server #1: Matrikon.OPC.Modbus.1 (Matrikon OPC Server for Modbus Devices) {F8582CEC-88FB-11D0-B850-00C0F0104305}
[*] <Init> Version: 3.3 (build 30)
[*] <Init> Vendor: Matrikon Inc 780.448.1010 http://www.matrikon.com[*] <Init> Server #2: NETxEIB.MP.OPEN.OPC.Server.3.0 (NETxEIB MP Open OPC Server3.0) {AAEEF077-F162-4A1F-AD88-C37F35EA4030}
[*] <Init> Version: 3.0 (build 1351)
[*] <Init> Vendor: NETxEIB MultiProject Open OPC/DA Server3.0, NETxAutomation 2006[*] <Init> Server #3: ICONICS.ModbusEthernetDA.2 (ModbusEthernetDA) {9BC87883-EEDA-11D3-9FDE-006067705B5A}
[*] <Init> Version: 3.12 (build 0)
[*] <Init> Vendor: ICONICS ModbusEthernetDA and ModbusEthernetAE[*] <Init> Server #4: KEPware.KEPServerEx.V4 (KEPware Enhanced OPC/DDE Server) {6E6170F0-FF2D-11D2-8087-00105AA8F840}
[*] <Init> Version: 4.264 (build 401)
[*] <Init> Vendor: KEPware[*] <Init> Server #5: Takebishi.Modbus.1 (DeviceXPlorer MODBUS OPC Server) {31A50D31-56E5-4BC2-9FDB-F55E7AD3854E}
[*] <Init> Version: 3.11 (build 2)
[*] <Init> Vendor: Modbus OPC Server by Takebishi Electric
Of the five servers tested only three (#0,#1,#2) seemed to read in the defined endpoints, two were from Matrikon and one was from NETxEIB. I setup all of the endpoints with varied ports like, 5500, 6500, 7500, …, 13500 and on up. These settings were also verified in the registry under HKEY_CLASSES_ROOT\AppId\{AppId GUID}, Endpoints, ncacn_ip_tcp,0,<port number> where indeed the port numbers are defined. Note the screenshots below of the before and during the connection initiation.
Author: Landon Lewis
Posted: August 13th, 2007 under Assessment Tools, Firewall / Perimeter, Microsoft, OPC, SCADA Protocols, SCADA Vendor.
Comments: 13
Comments
Comment from Erik Hjelmvik
Time: August 13, 2007, 10:38 pm
There is one point where I don’t quite follow you Landon. When you are saying “If you review the properties of the OPC Server…” it sound to me like you’re poking around in the OPC server application. I’m however really hoping that you are not doing that, but hopefully you are running dcomcnfg (which is how DCOM settings should be configured).
So if you are using dcomcnfg I find it really strange if the OPC-servers don’t behave acording to the setting you gave their DCOM objects. The reason for this is that OPC servers shouldn’t be designed to mess with the underlying layer (DCOM/RPC), they are just designed to use it. Hey, you don’t even really have to know how DCOM works to program an OPC server.
So if the OPC servers are overriding the DCOM settings then there is really somehting fishy going on. But I really find it unlikely that the OPC servers would override the DCOM settings. Have you tried rebooting the computer? 
Comment from Ralph Langner
Time: August 14, 2007, 4:17 am
“Why would vendors not implement something the rpcss service could read to handle the communications over another port?” asked Landon. The answer is simple: Because vendors don’t know about the more tricky DCOM stuff. The majority of vendors that build OPC servers do not have a strong background in Windows software development. They usually have their roots in process control and once figured out how a particular protocol works. Then they buy one of the few OPC server development toolkits and that’s it. As Lluis correctly pointed out at S4, vast majority of OPC servers that we see today are implemented using two or three toolkits. No need to understand OPC in general and DCOM in particular. Well, almost…
Comment from David
Time: August 14, 2007, 8:35 am
I have a question that the experienced OPC testers here could answer quickly. I read the user guide for the OPC tester and it looks like when you used the -l you got a listing.
My questions is, is that number between the {} brackets the AppID or the CSLID, and what value does knowing those numbers add to your test?
Just trying to learn something, hoping someone could take the time to give me a quick answer…even where I could look up a more involved answer would be good.
thanks
David
Comment from Landon Lewis
Time: August 14, 2007, 11:16 am
Erik- Yes you are correct in the assumption that I used dcomcnfg to modify the OPC server properties and thanks for pointing that out. Unfortunately with regards to the OPC servers ignoring the DCOM/RPC, that’s exactly what it is doing (from what I can tell). I’ve performed this test on three different machines and tested it multiple times, trying different ports, only installing single products (in case there was a product conflict), and of course I’ve rebooted (it’s a lab). Try it out if you get a chance, after all sharing this type of knowledge and information will better the SCADA community.
Comment from Landon Lewis
Time: August 14, 2007, 11:19 am
David-
The AppID/CLSID is useful for actually finding the associated OPC server in the registry where you could modify or review it’s settings. After a release of the final whitepaper I will show everyone how we’re using it and how the community can use it as well.
Comment from Tony Paine
Time: August 14, 2007, 12:21 pm
Landon - Did you contact the vendors to determine whether or not the OPC servers could be configured to respect the DCOM settings versus override them? I know for Server #4 that this particular option exists. Regards, Tony.
Comment from David
Time: August 14, 2007, 12:51 pm
Ok, so the OPC server settings are done in the reg. I thought those numbers looked like reg keys.
I’m not sure why, but my down in my gut, I don’t like that. Controlling the OPC server from the settings in the reg seems, risky. Many different programs access the registry, and a vulnerability in any one of them, including DCOM or MSRPC services, could lead to edits in the OPC configuration.
I might be getting my signals crossed on how the server is configured. I’m going to go read some more about how these systems work.
Thank you very much for your response,
David
Comment from David
Time: August 14, 2007, 1:08 pm
I took a look at this website to gain an understanding of the OPS server set up.
http://automatedsolutions.com/technotes/opcserverconnectivity/Default.asp
pretty good read for a rookie.
Now I see, this is no more risky then anyother DCOM service/server. HKEY_Classes_Root/AppID LaunchPermission key, and editing is my next read.
Thanks again,
David
Comment from Landon Lewis
Time: August 14, 2007, 1:49 pm
And the permissions of those keys can be changed to prevent an attacker from maliciously modifying them. Stay tuned for Part III, it’s a very nice comprehensive (yet technical) document that will assist with securing OPC servers and many DCOM applications.
Comment from Erik Hjelmvik
Time: August 14, 2007, 3:26 pm
Landon, I wasn’t really serious about the reboot comment (hence the smiley which for some reason ended up on the line after). I’m pretty sure you know when a reboot is needed.
I will be performing some simular tests as you did in a couple of weeks, so I’ll probably be able to verify your results then.
Comment from Stephan Beirer
Time: August 15, 2007, 4:28 am
IIRC some years ago there was a windows bug so that some DCOM programs ignored the endpoint settings done through dcomcnfg. That bug was fixed by Microsoft, so I don’t think that’s related, but checking the MS website might be worth a try
regards,
stephan
Comment from Ralph Langner
Time: August 15, 2007, 8:09 am
Ok guys, before you go into more detail on how to secure OPC servers, keep in mind that the server is only one part of the puzzle. Because of OPC’s callback mechanism, the OPC server reconnects to the client. This procedure cannot be limited by assigning a specific port number to the client as there is no matching DCOM server object in the SCADA or HMI application. Therefore, all DCOM acrobatics may be fine but still not be enough if we leave the OPC client (let’s say the SCADA app for example) unprotected in terms of DCOM accessibility. I’m afraid that the only solution for a high security OPC environment is to use an OPC tunneler that is well protected by firewalls on both ends.
Comment from Tony Paine
Time: August 17, 2007, 1:13 pm
The endpoint configuration is transparent to the OPC server (or any DCOM application), in that the OPC server does not explicitly read in the endpoint configuration and apply any port restrictions. This is functionality built into the operating system. However, in order for the OS to apply the port restrictions, the OPC server (or any DCOM application) must provide the proper registry settings to allow the underlying OS to lookup the end point configuration for a particular process. What our OPC server installation (Server #4) was missing was a registry key under HKEY_CLASSES_ROOT\AppID that maps the executable name to the appropriate AppID (in our case HKEY_CLASSES_ROOT\AppID\servermain.exe AppID={6E6170F0-FF2D-11D2-8087-00105AA8F840}). By applying this setting the OS is able to lookup the port restrictions for incoming DCOM connections and apply them as necessary. I believe that any OPC server that you encounter with this particular limitation can be resolved in a similiar manner. The setting will automatically be applied to the our KEPServerEx installation process in our Q3 2007 release coming up in the next few weeks.
Write a comment