ICS-CERT Updates Moxa Alert Again

This afternoon the DHS ICS-CERT published a new update to their Moxa alert (originally issued on April 8^th and then updated on April 20^th). The new update adds an acknowledgement of the original disclosure and more details about the ports involved in the vulnerabilities.

The Changes

The Alert now reports that Reid Wightman of Digital Bonds Labs was the original reporter of the five vulnerabilities upon which this alert was based. It also now acknowledges that Reid did coordinate with Moxa (but not, shame for shame, with ICS-CERT).

A paragraph has also been added to the mitigation section of the report that lists the ports that Moxa recommends should be either blocked or have access restrictions applied. The list of ports was in the original alert, but was removed in the first update. The port information in this update is more complete in that it distinguishes between the ports that are not needed by the device and the ports that may be used in normal operation. The same information was available in the DBLabs report that was responsible for the initiation of this alert.

Intellectual Property

I am glad to see that ICS-CERT is finally giving Reid credit for discovering these vulnerabilities. ICS-CERT has had an on-again, off-again policy of disclosing the researchers responsible for alerts. I understand that ICS-CERT would prefer that they (or some other CERT) would be used as a disclosure intermediary. Their thought is that their official office can apply more pressure to vendors to take vulnerability reports more seriously. While that may be true (more on that later) that should have nothing to do with giving credit where credit is due. Not giving credit smacks of theft of intellectual property.

Vulnerability Coordination

Now as to the larger question of the role of ICS-CERT as a coordinator of vulnerability disclosures, let’s take a look at that role. First off, I have seen nothing in legislation or regulation that provides ICS-CERT with any specific authority to act as such a coordinator. That probably is not really necessary as long as researchers and vendors mutually recognize ICS-CERT as an independent arbiter of disagreements about the legitimacy of vulnerability claims, on the one hand, and the legitimacy of vendor mitigations on the other hand.

It is becoming increasingly obvious that there are elements within the research community that no longer have much respect for ICS-CERT as a dispassionate intermediary. I have read a number of social media comments over the last year or so from a number of different researchers that expressed their concerns about the apparent willingness of ICS-CERT to side with the vendors when there is a disagreement on vulnerabilities.

Appearance of Favoring Vendors

In my very limited interactions with ICS-CERT, I have never had any problems. But then again, I am a security gadfly not a researcher. But that really does not make any difference. As I told young NCO’s in numerous leadership classes; it doesn’t make a damn bit of difference if you are or are not prejudiced. If those that report to you think you are prejudiced, then they are going to respond to you as if you were prejudiced.

At the very least ICS-CERT has a problem with the appearance that they favor vendors when there is a dispute between researchers and vendors. That appearance is going to help drive away researchers, particularly those without enough of an industry reputation to have their disclosures stand on their own merit. Those researchers are going to take less desirable modes of disclosure, public zero-day disclosures or, even worse, sell disclosures to the highest bidder.

This is particularly disturbing as the ICS security world is expanding by leaps and bounds. The number of researchers in this space is continuing to expand as new researchers (and established researchers from other fields) continue to see ICS research as an expanding field. Even more important the number of vendors affected by ICS vulnerabilities is also increasing as more industries (medical, automotive, aircraft, and security controls) begin to realize that their control systems have important security vulnerabilities that are no longer masked by obscurity.

Need for Coordination

The other question that this specific set of vulnerabilities raises is whether or not a disclosure coordinator is really needed. A legitimate case can be made that new researchers in the field, without a well established reputation, probably do need to have an independent agency act as a go between particularly when the security issues being raised are novel or difficult to understand.

That was certainly not the case here. Reid Wightman is not, by anyone’s measure, an ICS neophyte. He has a well-established personal reputation built across a number of organizations. That plus his current association with Digital Bond Labs should provide as much weight to the vulnerability disclosure as could ICS-CERT. He should be able to approach any ICS vendor in the world and have his report of vulnerabilities taken seriously and promptly acted upon. I question the commitment to security of any vendor that fails to respond promptly to a researcher of Reid’s stature and knowledge.

To take over a year to correct serious security vulnerabilities (and we are hoping that they will be completed in August as promised) is inexcusable. Particularly when the devices in question exist in a critical communications nexus in so many critical installations. Even if there is a legitimate reason for it taking a year to correct all of the problems (and I find that difficult to believe) most of these issues could certainly have been corrected well before now.

The Siemens model of disclosing a vulnerability even before all of the affected devices have patches/updates available is one that deserves close study by the industry. This is particularly true when there are legitimate methods of reducing the risk of vulnerability exploits that the owner can take while waiting for an update to become available.

A Good Step Forward

In closing, I want to make a clear statement that I think ICS-CERT took a valuable and correct step today with their making these changes to the Moxa Alert. Reid deserves credit for the vulnerability discovery and for his efforts to properly disclose those vulnerabilities to Moxa. System owners deserve to have the information on mitigation measures that are now available in the Alert. I continue to believe that ICS-CERT has an important role to play in coordinating vulnerability disclosures. The changes made today will help to ensure that they look like they are playing the role of a disinterested intermediary that both sides can respect and trust.

ICS-CERT Updates (Changes) Moxa Alert

Yesterday afternoon the DHS ICS-CERT updated the Moxa Alert that was originally released on April 8^th. ICS-CERT reports changes in three areas of the Alert, the summary section, the list of affected equipment and the mitigation section. As was true with the original release, there is some controversy associated with this revision of the alert.

Changes in Summary

First the update removes a general description of the uses of the affected equipment from the Summary. Then it removes the statement that: “The researcher released the report after initially coordinating with the vendor.” Finally, it provides updated information from Moxa confirming all five of the vulnerabilities reported by Digital Bond LABS instead of the just 3 of 5 confirmed in the original Alert. The Alert still does not list DBLABS as the source of the public report of the vulnerabilities.

The removal of the initial coordination statement appears to be a political move by ICS-CERT to minimize the issue that Moxa still does not plan on issuing a fix to the problems until ‘late August 2016’. The revised language makes it look like Moxa was blindsided by the April 5^th report and are diligently working on a firmware update. They may be working on an update now, but the DBLABS report provides a timeline showing that Moxa was notified of the vulnerabilities on July 24^th, 2015.

Changes in Products Affected List

The revised Alert reformats and expands the list of affected Moxa NPort devices affected by the five vulnerabilities. It also indicates that Moxa acknowledges the defect in the new list of affected devices. The DBLABS report suggested that more devices than they originally reported were probably affected by the vulnerabilities, acknowledging that the ones listed in the report were the only ones that they had tested.

Interestingly, some of the devices tested by DBLABS do not appear on the revised list of affected devices. These include Moxa NPort 6150/6250/6450/6610/6650, firmware release 1.13. Also interesting to note is that DBLABS was careful to list the firmware versions of the devices they tested and there are no version numbers on the revised list in this update. This indicates that the problem is nearly universal across the NPort product line.

Changes in Mitigation

The third section of changes to the Alert actually over laps mitigation section heading and includes the last two paragraphs from the summary section. Changes were made in those two paragraphs as well. First the new version eliminates the list of affected port numbers provided by DBLABS. Second it removes the description of the uses of the affected NPort devices. That description had stated that:

“The Moxa NPort 6110 device is a Modbus/TCP to serial communication gateway that integrates Ethernet and serial Modbus devices. The Moxa NPort 5100 series and 6000 series devices are serial to Ethernet converters that can be used to connect serial devices to an Ethernet network.”

The changes in the mitigation section of the Alert deal mainly with the fact that Moxa now acknowledges all five of the reported vulnerabilities and reports that the expected August update will mitigate all five. Moxa continues to report that it will not be updating the firmware for the NPort 6110 since that was discontinued in 2008.

Finally, ICS-CERT removed the statement that: “Password protecting the configuration file for the NPort 5100 and 6000 series devices has been reported by the vendor to prevent the upload of unauthorized binary files to the device.” It has been replaced with the more generic and even less helpful (but more truthful): “Set up access control to affected devices to prevent any unauthorized access.”

The Controversy

While it appears that this update was a political response to satisfy the sensibilities of Moxa, or maybe minimize the concerns of the owners of the NPort devices, it did nothing to sooth the outrage of the investigators who had attempted to ‘properly’ coordinate their disclosure of these very serious vulnerabilities with the vendor.

Last night there was an interesting exchange of TWEETS® between Reid Wightman (@ReverseICS) the author of the original DLABS report and Dale Peterson (@digitalbond) the owner of Digital Bond. Now admittedly, Dale and Reid are very vocal (and persuasive) complainers about insecure by design ICS devices (which might legitimately include the noted overwrite firmware vulnerability), but insecure passwords, buffer overflow, cross-site scripting and cross-site request forgery vulnerabilities are just plain, old-fashioned, sloppy programming problems. And taking over a year to correct that crappy programming is just unforgiveable.

I am more than a little concerned that the ICS-CERT alert continues to ignore two very important points made in the DBLAB report. First the fact that Moxa serial converter devices were targets in the December cyberattacks on the Ukraine grid and that they were bricked by over-writing the firmware. Second that DBLABS has shared at least one report of a live exploit of an NPort device with Moxa.

Finally, the mitigation measures mentioned in the Alert are totally inadequate to provide any sort of protection of these devices in the field. And that is totally inexcusable since the DLABS report provides detailed mitigation measures based upon the vulnerable ports (again those port designations were removed from the alert). If the list of the vulnerable ports had not been removed from the Alert, ICS-CERT might have been forgiven for not quoting the DLAB mitigation suggestions, but they did and I’m not.

I have been a champion in this blog of the vulnerability coordination activities of ICS-CERT, even suggesting that they be made responsible for coordination activities for NHTSA, the FAA, and the FDA. With blatant industry pandering like this alert update, I think that I am going to have to re-think that position.

ICS-CERT Publishes Moxa Alert

This afternoon the DHS ICS-CERT published an alert for five publicly reported vulnerabilities in the Moxa NPort 6110, 5100 series, and 6000 series devices. The vulnerabilities were publicly reported [link updated 21:54 EST, 2-18-17] by Digital Bond Labs (not named in the alert) after initial coordination with the vendor failed to respond to the vulnerabilities in a timely manner.

The ICS-CERT alert lists the five vulnerabilities as:

• Unauthenticated retrievable sensitive account information;

• Unauthenticated remote firmware update;  

• Buffer overflow;

• Cross-site scripting;

• Cross-site request forgery

ICS-CERT reports that Moxa has acknowledged three of the five vulnerabilities and announces that Moxa will release a new firmware version in late-August 2016 for the NPort 5100 and 6000 series devices that will address those three vulnerabilities. The NPort 6110 is a discontinued device and no updates are planned.

The Digital Bond Labs write-up contains some very specific recommendations about mitigating the vulnerabilities.