ICS-CERT Issues Duqu Update, New Advisory and New Link

Today was a busy day for the folks at the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT); they updated their alert on Duqu, they published a new advisory on a completely separate control system issue and updated the bad link previously identified by some muckraker.

Duqu Update

Less than a day after their initial information alert on w32.Duqu, ICS-CERT provides some added details (presumably supplied by Symantec and/or McAfee) that may allow targeted vendors to identify if their systems have been attacked by Duqu. They provided the command and control server IP address (already shut down according to the alert) and recommended that network and proxy logs be checked for communications with that IP; a sure sign of past or current infections.

They also noted that organizations should update their ‘antivirus definitions’ to allow for detection/prevention of present or future attacks (both McAfee and Symantec have announced that such definition updates are available for their products).

A strange question occurred to me today while reading some of the other conversations and articles about Duku; does this sound like a coordinated disclosure to anybody? I know… this is really a vulnerability in a ICS system so maybe ‘coordinated disclosure’ is not really a proper term to use. But, it does seem to me that the same reasoning should apply; keeping this quiet should have allowed ICS-CERT to coordinate with the relatively small targeted community to detect and isolate this particular Trojan. A public disclosure like this gives the perpetrators too much information about the mistakes that they made that allowed them to be detected.

The reason that I ask is that if this wasn’t the equivalent to a coordinated disclosure (and there is no indication that ICS-CERT got any earlier warning than did the rest of us) why do Symantec and McAfee get their names mentioned when researchers like Beresford and Luigi get specifically un-named? I know what I suspect the answer is, but I’ll leave that as an exercise for the reader.

Schneider Electric Advisory

This new advisory addresses a buffer overflow vulnerability reported (in a coordinated fashion) by Kuang-Chun Hung from the Information and Communication Security Technology Center (ICST) in a device driver used by six different software packages from Schneider Electric.

The ICS-CERT advisory notes that an attacker with a low skill level could use this vulnerability to execute a denial of service (DOS) attack. It would take a more skilled individual to use the vulnerability to execute arbitrary code. Both types of attacks could be remotely executed.

Schneider Electric has published a patch and provided customers with notification describing the vulnerability. The effectiveness of the patch has been verified by ICST.

CSSP Year in Review

Earlier today I noted the bad (incorrect) link associated with the publication of the CSSP Year in Review. The folks at the DHS Control Systems Security Program have corrected that problem and there is now a good link to a pretty PR-document.

Leading people to believe that this is a review of the work that CSSP has done during the last fiscal year is misleading at best. There is a single 8-bullet listing on page 3 that explicates (very broadly and briefly) the accomplishments of CSSP.  For example the first bullet point is:

“• ICS-CERT fly-away teams were deployed to seven organizations over the fiscal year (FY).”

Don’t get me wrong; I understand that these fly-away teams provide an important functional capability, but that is not even addressed. But, we now know that they deployed.

Unfortunately, the things that I was hoping to see addressed did not make the cut. In my quick skim of the 16 pages (filled with color photos) I did not see a single mention of Stuxnet, Beresford v Siemens or Luigi v HMI. Oh well good PR is always valuable for organizations, particularly for public funded organizations.