A Late Response from Triangle Microworks

Readers of this blog are well familiar with the on-going issue of improper input validation vulnerabilities in a variety of DNP3 protocol products from a number of different suppliers. There was yet another ICS-CERT advisory published yesterday. Each of the disclosures in this family have been coordinated disclosures by Crain-Sistrunk that remained tightly held until the affected vendor had patches or upgrades in place to fix their specific vulnerability. Only then did ICS-CERT publish the advisory for that vendor’s vulnerability.

A Late Announcement

This makes the announcement earlier this week on the Triangle MicroWorks web site more than a little odd. This is the first mention of the ICS-CERT advisory on their web site since that advisory was issued back in August. According to ICS-CERT they had a verified (by Crain-Sistrunk) update available then (no link was provided, just a note to contact the company) to correct this vulnerability. So, why the delay?

Now I don’t know the folks at TMW and I don’t follow the business side of this issue, so I can’t answer that question with any certitude. But I can tell you what it looks like to me like an attempt to ignore the problem, hoping that they would never have to admit to their customers that they had made a mistake. They corrected the coding problems; they get attaboys for that. But those attaboys get wiped out by the awshit that they get for not being proactive about getting the word out to their customers so that they could fix the existing problems in the installed systems.

Blame Shifting

To make matters worse the announcement attempts to minimize the extent of the problem by noting that the vulnerability “can only be exploited by a hacker when the security perimeter for the SCADA Network has been breached”. So this makes the problem not a coding issue, but a problem with the customer’s implementation of security.

Now, to be fair, there is an ongoing debate within the control system security community about the topic of ‘insecure by design’ and whether or not security is a perimeter defense issue or whether it should be focused on the interior devices. Both sides in that debate have legitimate points in support of their arguments.

Unfortunately, many of the slave devices affected by this vulnerability are placed in locations where no one is going to install real physical security safeguards to provide a reasonable security perimeter behind which these vulnerable devices can operate with impunity. Pole mounted devices and devices in remote locations protected by a simple fence are particularly vulnerable to the serial port vulnerability reported by Crain-Sistrunk.

I suppose it is the customer’s decision to deploy these devices in locations where their security cannot be assured. And that is a risk-benefit analysis that only the system owners can make. But to make that decision they must be fully aware of the potential vulnerabilities that they are accepting.

Bigger Problem than Reported by ICS-CERT

There is another attaboy that TMW gets for information in this announcement. The original ICS-CERT advisory only reported vulnerabilities associated with the outstation source code library produced by TMW. According to this week’s notice:

“A similar vulnerability was discovered shortly after, which could affect customers using our DNP3 Master Source Code Library.”

Looking at the language used here it looks like TMW is self-reporting an expanded vulnerability that they discovered. I think that it is always a good thing for vendors to self-report vulnerabilities, it demonstrates an on-going commitment to increasing the security of their devices and code.

I look forward to seeing ICS-CERT update their TMW advisory to reflect the additional vulnerability.

DNP3 Application Note

So why would TMW be making this late statement about their corrected vulnerability if they had been trying to publicly ignore it for so long? It looks like the reason is related to last week’s release of the new DNP3 User Group application note addressing this exact issue. While many people don’t directly follow the ICS-CERT advisories, most anyone that would buy the various DNP3 code libraries from TMW would be expected to notice that announcement from the DNP3 Users Group.

In fact, yesterday TMW posted another announcement on their web site specifically about that topic. Interestingly they close that post with the following comment:

“We are pleased to report that the coding practices at Triangle MicroWorks already exceed these recommendations.”

I’m surprised that they didn’t add that their DNP3 libraries have been fuzz tested by an outside independent security research team; Crain-Sistrunk.