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 Shamoon JSAR

Yesterday DHS ICS-CERT, in conjunction with US-CERT, issued an update of the Joint Security Awareness Report on the Shamoon malware. While this information stealing tool is suspected as being responsible for shutting down the Saudi oil company IT network, there has been no mention of it being used, or being specifically capable of being used, against control systems.

New Information

The new information included in the Update (on page 2) are three new entries in the ‘Tactical Mitigations’ section of the JSAR. The first is a ‘no duh’ entry, the second is somewhat useful, and the third is somewhat confusing. In general these three additions hardly make issuing an update worthwhile, particularly for the ICS community.

Drill Your Recovery Plan

I did say that this was a ‘no duh’ mitigation strategy, but to be fair ‘drill your recovery plan’ is one of those common sense strategies that probably doesn’t get done much. I’m not sure that simply listing it in a JSAR will help that. Perhaps an explanation of why any plan must be practiced (drilled) to be effective will help.

The military probably has the best experience in developing, perfecting and executing contingency plans. They know from bitter and painful experience that plans inevitably have short comings due to assumptions made in the planning process. Most often these assumptions are not clearly understood and frequently not even identified.

Practicing a plan will usually point out some of the shortcomings in the plan that are a result of inaccurate or incomplete assumptions. This does require, however, that after the plan has been exercised, that a clear and complete analysis has to be made of the areas where the plan did or did not work. And then the plan has to be modified to correct the deficiencies and build on what was done right.

 

Finding these mistakes during an exercise is much less painful and makes them easier to correct than if they are discovered for the first time while responding to the real thing.

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 – New JSAR, Advisory and Updated Alert

Still getting caught up after Isaac; while ICS-CERT hasn’t been real busy they haven’t waited for me either. So here is a quick look at a new Joint Security Awareness Report (JSAR), a new privilege escalation advisory and an update on a Siemens related alert.

Shamoon JSAR

ICS-CERT and US-CERT published a JSAR on Wednesday for the information-stealing malware W32.DistTrack, also known as Shamoon. Actually calling this an ‘information-stealing’ malware is misleading since it also contains a module that corrupts selected existing files on the hard drive and then erases the Master Boot Record so that the computer cannot be re-started. To me this sounds like a software bomb that also steals information. Oh, and before it destroys the virtual computer it spreads to other computers on the network.

The JSAR is very light on details about this threat, but it does reference two pages from the Symantec web site that provide more details. Of the two sites referenced the best one contains all of the publicly available Symantec information.

Symantec rates this as a low level threat in the wild, but that is based upon the small number of times this has been detected (less than 50). Neither the JSAR or the Symantec site mention that the Shamoon is suspected of being responsible for the shut down on the Saudi oil company’s computer systems last month. I suppose they think that if you are not a targeted company you may be okay. But this is another low-risk, high-consequence piece of malware.

There is no mention in the JSAR of why this is a joint US-CERT ICS-CERT publication. There is nothing that currently indicates that this is targeted at control systems, but it would appear to be difficult to determine exactly what information was stolen from a subsequently unusable computer. Since one of the targets appears to have been an energy sector company, it would seem prudent to think that control system access information may have been part of what may have been stolen.

GarrettCom Advisory

Justin Clarke of Cylance has identified another hard coded password in an industrial control system component. This time it was in the GarrettCom Magnum MNS-6K (an Ethernet switch) Management Software. Since access to the network is required to exploit this vulnerability it is called an ‘escalation of privilege’ vulnerability; someone with limited access can gain administrator level access to the system.

GarrettCom has released a patch that ‘mitigates this vulnerability’, though there is nothing in the advisory that indicates that either ICS-CERT or Justin has verified this mitigation. Interestingly though, the advisory does note that the vulnerability is not specifically identified in the release notes for the updated software version that was released back in May. This may mean that system owners are not aware of how important the upgrade may actually be and thus may decide to delay or completely forgo implementing the upgrade.

I have noticed that Justin has been taken to task on some internet sites (the SCADASEC list in particular) for this disclosure. It is apparent, however, that his detractors were not aware that this was a coordinated disclosure where the vendor was able to produce a patch and that patch to be publicized on the secure server at US-CERT before it became general public knowledge. Part of the fault there lies with this Advisory as it does not specifically state that this was a coordinated disclosure, but that really is clear if you read the ‘Overview’ portion of the Advisory carefully.

RuggedCom Alert Update

This is the second update of the RuggedCom Alert originally published back on August 21^st. Well, it looks like a second update as it is version B. I can’t find where ICS-CERT published anything on this between August 21^st and yesterday when this version was published. Maybe they got confused with the A version of the earlier RuggedCom Alert published in May.

In any case this update is based upon a Siemens CERT report published on Friday (NOTE: the Revised Alert points at the page where the Siemens alerts are posted not this specific alert). Siemens reported that vulnerabilities similar to those identified by Justin in the RuggedCom ROS were also found in the ROX operating system and the RuggedMax operating system. Interim mitigations are have been provided by Siemens/RuggedCom.

Siemens is to be commended for their effort to identify the fact that other systems produced by their recently purchased subsidiary have similar problems and to publicly report that fact. Hopefully they are also taking internal measures to ensure that security is a higher priority in the production of future products.