ICS-CERT Publishing Old Updates

NOTE: As of 5-3-13, 19:30 CDT the issues identified in this post with this update have been resolved. The link now takes one to the September 27th, 2012 version updated to the new HTML format.

Yesterday I was kind of surprised when ICS-CERT published an update to the Ruggedcom Advisory that was news before the original advisory was published. Today, I am more than surprised; I am more than a little concerned because ICS-CERT re-published as new an update to the SHAMOON JSAR that was originally published last September.

Now this could just be a problem of updating all of the old .PDF alerts to the new .HTML model, but today’s publication certainly claims that the date for the –A update is April 30^th, 2013 not September 27^th, 2012.

Now there was a second update to this advisory published last October. As I noted in that earlier blog post the second update was not that impressive, but it did provide some new information. That information is not included in today’s “update”.

Now the links to the ICS-CERT publications in the previous blog posts about the updates are no longer particularly useful. The first update (-A) link now takes you to today’s version of the update (virtually the same as the original outside of some formatting changes and the ‘wrong’ change date). The second update (-B) link now takes you to the original version of the JSAR (again in the new HTML format) with a bogus ‘original release date’ of October 16^th, 2012.

I understand that it is easy to make inadvertent changes to documents when you fool with reformatting the documents. This is why historical records do not typically get reformatted; there is no need to put their information integrity at risk.

BTW ICS-CERT: If you need copies of the original .PDF files to correct the historical record, let me know. I have copies of most of the alerts and advisories back to June of 2010. I’ll be happy to ship them to you on a thumb drive….. ;-)

ICS-CERT Updates JSAR and Luigi Vuln

Yesterday DHS ICS-CERT published an updated Joint Security Awareness Report (JSAR) on Shamoon and an advisory for an Optimalog vulnerability reported last year by Luigi.

Shamoon

US-CERT/ICS-CERT updated their earlier advisory on Shamoon. The new version adds almost three pages of mitigation measures that organizations can take to protect themselves (actually only reduce their vulnerability) against a Shamoon attack. The JSAR divides the mitigations into ‘tactical’ and ‘strategic’ measures. The measures are an interesting mixture of the common (‘Ensure that password policy rules are enforced…’), the old school (‘Execute daily backups of all critical systems.’) and new form (‘the whitelisting of legitimate executable directories…’) security measures. Implementing all of the recommended actions will require a lot of work, particularly training.

There still isn’t anything in the JSAR that reports any specific ties of the Shamoon to control systems. Of course with the small number of reported infections it is hard to tell exactly what may or may not be at risk. At this point this is a low probability high consequence threat. That makes one question the need to spend the time and money to implement the listed mitigations. I guess that’s what CSO’s get the big money for.

Optimalog Vulnerability

Last November ICS-CERT published an alert based upon an uncoordinated disclosure by Luigi for the Optima APIFTP Server system. Yesterday ICS-CERT published an advisory on the twin vulnerabilities; a null pointer dereference and a loop with unreachable exit condition. ICS-CERT reports that a relatively unskilled attacker could use the publicly available exploit to remotely execute a denial of service attack.

Optimalog has released a new version that no longer installs the APIFTP server by default. If the APIFTP is to be used, Optimalog recommends configuring “the firewall and VPN accordingly”. There is no link to any Optimalog document or site that details that ‘accordingly’.

This advisory mentions Luigi’s uncoordinated disclosure but does not provide links to Luigi’s web page describing the vulnerability. Nor does it actually mention the original alert. The latter is unusual, but I thought that ICS-CERT had finally gotten it through their collective head that they had an obligation to give appropriate credit to the intellectual property that forms the basis of their report. Reid Wightman got credit last week, but Luigi doesn’t this week. I’m starting to see a pattern here; Digital Bond and the Washington Post carry enough weight to demand acknowledgement, an independent researcher doesn’t.

ICS-CERT Updates sKyWIper JSAR

Yesterday the folks at ICS-CERT published an updated Joint Security Awareness Report (JSAR) on the sKyWIper ‘information-stealing malware’ (someone has got to come up with a better name for this type thing; how about ‘cyber-sucker’?). The JSAR adds some information about the use of Microsoft digital certificates in this malware.

There is not a lot of information here (to be fair it does provide a link to the Microsoft advisory that does provide more detailed information), but it does make two very important points about the MS certificate issues. First:

“This is an avenue for compromise that may be used by additional attackers on systems not originally the focus of the sKyWIper malware.”

This is a general problem for all new security holes that are re-discovered during the investigation of any new cyber-attack tool. While sKyWIper currently appears to be focused on systems in the Middle East (and that could always change; it’s a very flexible tool), the certificate issue could be used by any malware designer for a new attack tool.

The second issue is more directly related to industrial control systems. The JSAR notes that:

“ICS-CERT and US-CERT recommend that industrial control systems owners and operators review the Microsoft Advisory and work with equipment vendors to install this update.”

While this is similar to the standard ICS-CERT warning to “to perform proper impact analysis and risk assessment prior to taking defensive measures” (which is also included later in the same paragraph of the JSAR), it would seem to indicate that there may be some product specific problems with the application of this specific MS update.

I know that Siemens reports on their analysis of the applicability and usability of MS updates with their products, but I am not so sure that other vendors do the same (one would expect that the larger ones would). Even so that is going to take weeks or months before the vendors are going to be able to commit to compatibility of the update with their systems and even longer to produce a working implementation if there are system related problems. Meanwhile the good, the bad and the ugly in the hacker community are working on exploiting this problem.

Unfortunately, there is no easy answer to this problem; have a good in-depth ICS security program in place and hold your breath.