Today ICS-CERT published an advisory for a buffer overflow vulnerability on the MatrikonOPC SCADA DNP3 OPC Server. Actually the document published today is a revised version of an advisory published on the US-CERT secure Portal back on August 2nd. The vulnerability was reported by Adam Crain and Chris Sistrunk in a coordinated disclosure.
ICS-CERT reported that the vulnerability can be remotely exploited by a moderately skilled attacker to execute a DOS attack. MatrikonOPC insists that an exploit would require “in-depth technical knowledge of the DNP3 protocol and the specific vulnerability in the MatrikonOPC software”. I guess (sarcasm alert) that Adam and Chris were just lucky to be able to find the ‘specific vulnerability’.
MatrikonOPC has developed a new version of the OPC Server for DNP3 that eliminates this vulnerability. ICS-CERT reports that Adam has verified the efficacy of the update.
As I noted earlier this publicly available version of the advisory is actually an update of the earlier, limited release version. There are two changes listed in the update; a more detailed explanation of the mechanism of the vulnerability and an additional suggested mitigation to prevent the vulnerability from being remotely accessible.
The update notes that the server only stops communication because of this vulnerability after receiving a malformed DNP3 packet from a device. In an unusual move ICS-CERT added additional language indicating that Adam and Chris suggested that an additional mitigation measure would be to block “DNP3 traffic from traversing onto business or corporate networks through the use of an IPS or firewall with DPN3-specific (sic) rule sets”.
This is actually a pretty specific expansion of a standard ICS-CERT recommendation to protect control systems from unauthorized access via the use of a firewall or IPS. It is not surprising that Adam and Chris would focus on DNP3 communications since this is an area that they have been spending a great deal of time investigating here recently. It might be interesting if they were to post on the Automatak blog a more detailed discussion about the types of DNP3 rule sets that would provide additional control system protections for DNP3 servers in general.