Showing posts with label IOServer. Show all posts
Showing posts with label IOServer. Show all posts

Thursday, October 16, 2014

ICS-CERT Issues 2 New Advisories and Updates 2 Siemens Advisories

ICS-CERT has been busy this week. Today they issued two new control system advisories and updated two Siemens advisories. The new advisories are for vulnerabilities in Fox DataDiode Proxy Server and the IOServer application. The two Siemens advisories have already been mentioned here this week.

Fox Advisory

This advisory concerns a cross-site request forgery (CSRF) vulnerability in the web administration interface. It was reported by Tudor Enache of HelpAG in a coordinated disclosure. A new release has been produced that mitigates the vulnerability, but there is no mention if the efficacy has been verified by Enache. This advisory was originally released on the US CERT secure portal on September 26th.

ICS-CERT reports that a two phase social engineering attack would be required to remotely exploit this vulnerability to conduct a DOS attack.

IOServer Advisory

This advisory concerns an out of bound read vulnerability reported by Sistrunk-Crain (ICS-CERT changed up the order of the team name) in a coordinated disclosure. A new version mitigates the vulnerability and the efficacy has been verified by Adam Crain.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to crash the OPC Server application.

There is an interesting comment by ICS-CERT in the Vulnerability Characterization section of the advisory. They state:

“A vague interpretation of the DNP3 protocol may allow a null header to cause an out of bound read command to create large numbers of entries in the master in some implementations. This is not a universal problem for all DNP3 users, vendors or integrators [emphasis added], but it may occur.”

That plus a reference to a DNP3 Application Note addressing this issue seems to indicate that this is a problem that might affect other systems. Not that Chris and Adam have ever found vulnerabilities in DNP3 implementations that affect multiple platforms (sorry for the low level sarcasm here). As of 9:00 pm CDT this advisory is not listed on the Project Robus web site.

Siemens OpenSSL Update

Well it looks like we are going to need at least update G to get this correct. Yesterday ICS-CERT reported that ROX 1 was the only outstanding affected system without an update; completely missing the APE 1 with eLAN and ROX 2 with eLAN. Well, with the Siemens ProductCERT announcement today that the ROX 1 update was now available ICS-CERT is still failing to report the continuing vulnerabilities in APE 1 with eLAN and ROX 2 with eLAN. Well, maybe tomorrow.

Ruggedcom Certificate Update

ICS-CERT missed the earlier announcement that the ROX 2 update was available, but they did catch up today when Siemens ProductCERT announced that the ROX 1 update was now available. So far so good. Unfortunately, ICS-CERT also changed their reporting of the affected versions of these two devices. It was correct and had not changed in the latest Siemens report. I know; minor details.


I’m beginning to wonder if anyone at ICS-CERT actually reads the Siemens alerts. The bigger question is how accurate are the other vulnerability reports from ICS-CERT, the ones that we can’t check because the vendor is not as meticulous in reporting their vulnerabilities as is Siemens?

Thursday, April 10, 2014

ICS-CERT Updates an Alert and an Advisory and Publishes New Advisory

This afternoon the DHS ICS-CERT published an update of an older advisory for Rockwell Allen-Bradley Micrologic and a new advisory for IOServer’s OPC Drivers. While not listed on the ICS-CERT landing page, they have also updated yesterday’s alert for the HeartBleed vulnerability.

Rockwell Allen-Bradley Update

This advisory was originally published on 12-7-12 and then updated four days later. Today’s update advises that:

• Rockwell has now produced a patch to mitigate the fault generation vulnerability; the previous update noted that Rockwell was considering if a patch would be produced;
• The CVSS v2 base score of 8.5 has been recalculated to be a CVSS v2 base score of 7.1. The new CVSS vector string is (AV:N/AC:M/Au:N/C:N/I:N/A:C); and
• A new Rockwell Automation report (registration required) was published on this vulnerability last summer.

This appears to be a late ICS-CERT response to a less than timely vendor response. To be fair to ICS-CERT, however, Rockwell may not have kept them up to date on the actions taken on this vulnerability.

IOServer Advisory

This advisory addresses a Crain-Sistrunk reported improper input validation vulnerability in the OPC Driver (fooled you, not the DNP3 Driver) from IOServer. It was, as we have come to expect from this duo, a coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to send information to the system that could “lead to parts of the system receiving unintended input, which may result in altered control flow or arbitrary control of a resource”. This sounds very close to saying ‘exploit arbitrary code’.

This advisory is full of surprises. It reports that:

“Adam Crain and Chris Sistrunk updated and tested this version and validated that this vulnerability is resolved.”

We apparently have a new standard for independent researchers; find it, report it, fix it and verify that the fix works. The vendors can now take a long lunch break.

HeartBleed Update

ICS-CERT has updated yesterday’s HeartBleed alert with some information that may be pertinent to control system security. It provides a little more detail about the vulnerability itself and includes a link to a blog post about yesterday’s Sans briefing (with links to the slides for the briefing) by Jacob Williams. This looks like some good technical information, though not specifically about control system vulnerabilities tied to HeartBleed.

The update also includes the intended scare phrase “ICS-CERT is aware of several instances of targeted active exploitation of this vulnerability” while never stating that those exploits have targeted control systems. I would assume that they did not (yet, at least).

The alert now includes instructions for developers for a work around if the new version of OpenSSL cannot be loaded. It also has an example of an IDS signature for detecting an exploit of this vulnerability.


You can’t tell just by looking at this update (it is outside of the red-bordered change areas), but ICS-CERT removed an embarrassing bit of boilerplate from the alert. It no longer refers to using a VPN to remotely access control systems. It would have been better if the boiler plate had been changed instead of removed. It is important that current control system users of VPN’s know that this is a prime potential area for running into HeartBleed and that the VPN should probably not be used until it has been checked for the vulnerability and fixed if necessary.

Monday, June 10, 2013

ICS-CERT Publishes IOServer Advisory

This afternoon the DHS ICS-CERT published an advisory concerning an improper input validation vulnerability in the IOServer’s DNP3 driver reported by Adam Crain of Automatak and independent research Chris Sistrunk in a coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could craft a remotely exploitable attack using this vulnerability resulting in a denial of service attack. IOServer has provided an updated version of the software (http://www.ioserver.com/beta2040.exe) which has been confirmed by Crain and Sistrunk to correct the problem.


NOTE: I’m not sure that I would like clicking on an .EXE file for a file on a different web site. Personally, I would prefer to click to a page that provides some sort of explanation of what the changed software would do before I would be comfortable clicking on the executable file.

Saturday, September 15, 2012

ICS-CERT Publishes IOServer Advisory


Yesterday the DHS ICS-CERT published an advisory about multiple file management vulnerabilities on the IOServer OPC Server. The vulnerabilities were first reported by Hinge of foofus.net (ICS-CERT did provide a link to the initial vulnerability report – finally).

The Official Word


The three listed vulnerabilities allow low-skilled attacker to remotely download files from the affected system. The vulnerabilities are:

• Insufficient access controls (CWE-219);

• Directory listing (CWE-538); and

• Directory traversal (CWE-22).

According to the Advisory, IOServer has produced a patch that resolves one of the three (Directory traversal) vulnerabilities and this has been verified by Hinge. Hinge (NOT IOServer) recommends using a trailing backslash on the ‘Root Directory’ configuration value to reduce the extent of the remaining vulnerabilities. There is no mention in the Advisory if/when IOServer will be correcting these vulnerabilities.

The Oddities


There are some odd things going on with this advisory. First off, since there was not an earlier alert, one would normally assume that this was a coordinated disclosure, but that is certainly not stated. In actuality, the original public disclosure that ICS-CERT provides the link to is dated August 17th, 2012 and there is nothing on that site that would imply a coordinated disclosure. Big question here is if it was a coordinated disclosure why did it take ICS-CERT almost a month to report this serious vulnerability (more on that later). If it wasn’t coordinated why wasn’t an alert issued a month ago?

Underplayed Vulnerability?


A quick reading of the Advisory leaves one with the impression that this is not a real big thing. After all it does not allow anyone to take control of the system or allow for the execution of arbitrary code; it just allows unauthorized people to read some files (all right the cognoscenti will go “Oh Sh*” to that). Reading the Hinge disclosure makes this sound much more interesting; describing it this way:

A directory traversal vulnerability exists such that the web server can be tricked to serve up any file on the server [emphasis added], outside of the configured “Root Directory”. On Windows, one common thing to do with an issue like this is to download the backup copy of the SAM, in order to retrieve password hashes and mount an offline attack on them. Any other potentially sensitive file on the server can be accessed this way as well, if the attacker knows the path to it”

The original disclosure goes on to describe the impact this way:

“Unexpected arbitrary access to the file system can lead to the disclosure of sensitive information. Worst case, disclosure of the system’s password hashes can lead to compromise of the passwords [emphasis added], and therefore, of the server.”

If you own the OPC Server, you have control of the ICS. So, is this a major vulnerability or what?
 
/* Use this with templates/template-twocol.html */