Guest blogger Rubén Santamarta is European Security Researcher. He publishes his thoughts and research results at reversemode.com and tweets @reversemode.
First of all I would like to thank Dale for inviting me to share my thoughts via this blog.
Having published dozens of vulnerabilities during the last years I have collected multiple reactions. From vendors who want to hire you, to those determined to sue you (just one case fortunately) .
However, I’d empirically say that some SCADA vendors are still lacking the proper policy, or attitude, to face up the fact that their products have vulnerabilities, as well as any other software or hardware might have. I guess they are not used to dealing with these scenarios.
Foreseeing some kind of weird reaction to my reports I took the decision to contact vendors only through 3rd party organisms; ICS-CERT is a good candidate, according to my experience.
Thus, 2 years reporting SCADA vulnerabilities is enough time to collect some reactions. I have been ‘accused’ of physically entering facilities, having access to insider knowledge, or more recently a response was that what I was reporting was not a bug . This situation happened in the Advantech/BroadWin case. After the vendor denied having a vulnerability,I ended up releasing an exploit to demonstrate the real impact. I’m pretty sure some of you strongly disagree with me since releasing a 0day is not usually well considered.
The response I received from Advantech/BroadWin was the following:
“3. WebAccess does use RPC to communicate between Client andserver. But all the server side functions are password protected. With HTTPS and VPN, we think it is safe on the internet. It would be extremely complicate to reverse engineer the RPC code and the alter the data in WebAccess.”
To be honest, it took me less than an hour to reverse engineer their RPC interface . After reading their arguments I also decided to implement another feature in the exploit to grab the password used to ‘protect’ server-side functions. A VPN cannot be a replacement for secure code development, in no case.
According to ICS-CERT, they are actively working on a patch. Unfortunately it seems they are not planning to fix a client-side vulnerability I also reported. Let’s analyze the problem.
WebAccess is a browser-based solution, having a client-server architecture, operators need to install a client-side component (ActiveX) to access SCADA nodes. One of these controls is bwocxrun.ocx which is installed by default and can be instantiated by any domain, without warning. So, what’s the problem? The methods it implements:
+CreateProcess( BSTR CmdLine, short ShowType, short WaitMode )
+OpenUrlToFile, BrowseFolder…
At this point, you are probably thinking about the attack scenario: if the attacker is able to entice the operator into visiting a specially crafted webpage, game over. Below is the response from Advantech/BroadWin:
“On the client side, the OCX does include the CreateProcess method, but it only allow user to create a process in the machine he isusing, there is no way that user can touch the server via this method.WebAccess should be safe on this issue.”
The industrial sector should realize that security researchers are not against vendors. I didn’t ask for money either. I just let them know, for free, a problem I thought should be addressed to make their product more secure.
We will see how things evolve.
Image By Green_Mamba
I completely agree with Ruben’s thoughts regarding SCADA (and other segments) vendors. There are some initiatives that are forcing vendors to take security seriously, but we need to be sure that they fulfill all of them. Any device that controls/monitors/etc. critical infrastructure should be periodically reviewed and vendors should implement secure development life-cycles in their products.
“A VPN cannot be a replacement for secure code development, in no case.”
Ruben has a very valid point. If, as a vendor, your solution relies on some other widget in order for it to be fully functional, the vendor would be expected to show in their proposal that it was needed, cost it, provide it, and install it. At the bare minimum, vendors would be expected to call a specific widget out as an option. Otherwise, your recommendation may appear to knowledgeable clients as a cop-out.
But, we won’t see this often in the real world. Adding these types of widgets to proposals can start pushing them out in front in terms of costs, and those proposals in front tend to get cut. But for asset owners that are concerned with security, this attention to detail would be valuable, and would help demonstrate knowledge and expertise in the ICS Security arena.
The Moral: Know your client, know their concerns, and find out up front if security is a deciding factor in their selection of a vendor.
Mike T
Private Citizen
Dale, thanks for inviting Ruben to post this article. Ruben, you’ve provided an important insight into the interaction between vendors and security researchers. Thanks very much for your work.
Jeffrey Carr