Thursday, October 30, 2014

ICS-CERT Releases 3 Lesser Communications Advisories

While everyone is still talking about Black Energy the DHS ICS-CERT released three advisories today concerning lesser vulnerabilities in three applications used in control systems communications. One was a follow up to an alert issued last Halloween, while the other two are newer vulnerabilities that were released earlier this month on the US-CERT secure portal.

Nordex Advisory

Last Halloween ICS-CERT published an alert about an uncoordinated disclosure (complete with exploit) of a cross-site scripting vulnerability in the Nordex Control 2 (NC2) application. Today ICS-CERT announced that Nordex has (I think) produced a patch to mitigate the vulnerability; needless to say no one has contacted the uncooperative researcher, Darius Freamon, to verify its efficacy.

ICS-CERT reports that a relatively low skilled attacker could use the publicly available exploit to remotely “execute arbitrary script code in the user’s browser”.

I said ‘I think’ parenthetically above because of the wording of the following sentence in today’s advisory:

“Nordex will release a patch for all affected NC2-SCADA versions until the end of 2014.”

I think that that means that the patch is available but Nordex will only be applying the patches through the end of the year. The Advisory notes that the patching of the wind turbine control system has to be done by Nordex. A year to wait for the vendor to fix a cross-site scripting error and then have to wait until they can get around to your site to apply the fix; I hope Nordex is including all of this in their sales material.

Meinberg Advisory

This advisory reports another cross-site scripting vulnerability, this time in Meinberg Radio Clocks GmbH & Co. KG LANTIME M400 web interface. This was originally reported by Aivar Liimets of Martem Telecontrol Systems in a coordinated disclosure. ICS-CERT reports that Meinberg has produced a firmware update that has been verified by Liimets. This advisory was originally released on the US-CERT secure portal on October 2nd.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to “cause the time server to provide misinformation to devices”.

Accuenergy Advisory

This advisory reports two authentication vulnerabilities in the AXN-NET Ethernet module from Accuenergy. The vulnerabilities were reported by Laisvis Lingvevicius in a coordinated disclosure. According to ICS-CERT Accuenergy has produced a firmware update that has been validated by Lingvevicius. This advisory was also released on the US-CERT secure portal on October 2nd.

The two vulnerabilities are:

• Authentication bypass vulnerability, CVE-2014-2373; and
• Password disclosure vulnerability, CVE-2014-2374

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to change network settings for the AXM-NET module web server as part of a denial of service attack.

Interestingly, the Accuenergy web site offers the following information about the firmware update:

“Redesign and improve encryption method on web-server, tested and verified by Department of Homeland Security, industrial control system cyber emergency response team [sic]”.

In light of discussions about what ICS-CERT really does (see most recently Dale Peterson’s blog post “What Does ICS-CERT Do?”) it is nice to see positive signs of actual involvement in the process of fixing vulnerabilities. Of course there are lots of businesses out there that are trying to make payroll by doing the same sort of thing.


Of course Accuenergy could just be blowing smoke to try to make their own efforts look good.

ATF Sends Explosives Registration Final Rule to OMB

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received a copy of the final rule implementing the Safe Explosives Act registration requirements from the Justice Department’s Bureau of Alcohol, Tobacco, Firearms, and Explosives. The Interim Final Rule (68 FR 53509) on this rulemaking has been in effect since September 30th, 2003.


There is no telling at this point what changes might be included in this Final Rule.

Wednesday, October 29, 2014

ICS-CERT Adds Hash Validations for Yara Downloads

This afternoon the DHS ICS-CERT published its first update for yesterday’s alert about the newly identified (but old in the field) Black Energy compromise of control systems from multiple vendors. Today’s update provides the information necessary to complete a validation of the Yara binaries that ICS-CERT provided for download.

Those binaries were provided to allow owner/operators to check their systems to see if they were part of the compromised control system environment. Unfortunately, unless you are part of the twisted minority that can actually read binaries, downloading and executing binary that have not been verified is probably the single most unsecure action anyone can do on the internet. And there was ICS-CERT asking critical infrastructure owners to do just that.

Now, to be fair, I did not point this out last night because I made the same assumption that ICS-CERT probably expected everyone to make. These files came publicly from ICS-CERT so they were properly vetted, verified and safe. And that is almost certainly true (I don’t know because I can’t read binaries) if you downloaded them from the ICS-CERT site (unless of course someone hacked the ICS-CERT site and modified the binaries posted there). If you downloaded them from a bogus copy of the ICS-CERT site, or got them from some other site as a ‘true copy’ of the ICS-CERT supplied, or you got them in an email that appeared to come from someone you should be able to trust, or any number of alternative methods, then you would need some independent method of insuring that the binaries are the ones that ICS-CERT provided in the first place.

Fortunately, there are some people around who are less trusting. One such last night was OMG ‘H’AXOR (@SynAckPwn) who noted: “Juicy watering hole target identified: ICSCERT just reco'd control sys owners go to gDrive linked from github, DL EXE, run on ICS systems”. That comment spawned a very interesting series of Twitversations last night. Apparently, ICS-CERT was listening as they quickly (for a government agency VERY QUICKLY) provided the necessary data to verify the binaries.

Is it enough? It depends on how many noids you have. If you have a pair you might point out that anyone could still set up a mirror site and post modified binaries with modified hash information and they would still own any system upon which this binary was used to check for the Black Energy compromise. In a truly paranoid world you would want the two items to come from different sources with appropriate separate authentication for each source. But, let’s face it; even that could be hacked.

BTW: The REALLY PARANOID would never have seen this information in the first place because it was published in a .PDF document; and NOBODY in the right mind would open a .PDF.

But, I think that ICS-CERT should still be given credit for taking the effort. This time. They really should come up with a better method for sharing this information in any future action of this sort.

Tuesday, October 28, 2014

ICS-CERT Publishes Long Term Anti-ICS Campaign Advisory

This evening the DHS ICS-CERT published an alert about a long term anti-ICS campaign that has been compromising various control systems from multiple vendors since at least 2011. ICS-CERT is reporting that, at a minimum, HMI from GE, Advantech and Siemens have been compromised in this campaign. They are not currently reporting any damage to control systems or to operations that are controlled by those systems.

ICS-CERT is publicly providing detailed information about how these compromised HMI can be identified and it is asking all potentially affected system owners to check their systems and notify ICS-CERT if evidence of compromise exists.

As one would suspect with something that is apparently as serious as this, ICS-CERT has released an alert (ICS-ALERT-14-281-01P) on the US-CERT secure portal and has already published an update to that alert. ICS-CERT is also taking the unusual step of publicly describing that alert and notifying “US critical infrastructure asset owners and operators” that they can request a copy of the alert by email (ICS-CERT@HQ.DHS.gov).

As I have already mentioned on TWITTER®, this is the most detailed ICS-CERT alert that I have ever seen, especially on an initial publication. This is the type of information that we should be able to expect from ICS-CERT. This is also the type problem that we really need to be able to expect them to delve deeply into. I suspect, however, that we will be receiving the bulk of our information on this from private sector researchers who will have more resources and expertise to throw at this problem. That would be a good topic for a congressional investigation.

BTW: Here is an interesting question about this issue from Chris Sistrunk: “Could the BlackEnergy ICS malware be related to the vulns discovered by Z0mb1E and amisto0x07 from ZDI and the Metasploit mods they wrote?”

BTW: The alert contains a link to the GE security page. Nothing specific there except a brief note that: “The CIMPLICITY Webview server that existed in prior versions of CIMPLICITY, has been removed due to security concerns.” No further information available.


BTW: Siemens Product-CERT also is saying nothing. 

Monday, October 27, 2014

Small Unmanned Aircraft Systems (sUAS)

On Saturday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that the FAA had submitted a notice of proposed rulemaking (NPRM) for Operation and Certification of Small Unmanned Aircraft Systems (sUAS). This rulemaking was mandated by the FAA Modernization and Reform Act of 2012 {§332(b) PL 112-95} with the final rule to be published by August 14th, 2014 (Oops).

According to the Unified Agenda abstract for this rulemaking:

“This rulemaking would adopt specific rules for the operation of small unmanned aircraft systems (sUAS) in the national airspace system. These changes would address the classification of small unmanned aircraft, certification of their pilots and visual observers, registration, approval of operations, and operational limits in order to increase the safety and efficiency of the national airspace system.”


It is way too early to tell if this rulemaking will have any critical infrastructure security implications.

Thursday, October 16, 2014

ICS-CERT Issues 2 New Advisories and Updates 2 Siemens Advisories

ICS-CERT has been busy this week. Today they issued two new control system advisories and updated two Siemens advisories. The new advisories are for vulnerabilities in Fox DataDiode Proxy Server and the IOServer application. The two Siemens advisories have already been mentioned here this week.

Fox Advisory

This advisory concerns a cross-site request forgery (CSRF) vulnerability in the web administration interface. It was reported by Tudor Enache of HelpAG in a coordinated disclosure. A new release has been produced that mitigates the vulnerability, but there is no mention if the efficacy has been verified by Enache. This advisory was originally released on the US CERT secure portal on September 26th.

ICS-CERT reports that a two phase social engineering attack would be required to remotely exploit this vulnerability to conduct a DOS attack.

IOServer Advisory

This advisory concerns an out of bound read vulnerability reported by Sistrunk-Crain (ICS-CERT changed up the order of the team name) in a coordinated disclosure. A new version mitigates the vulnerability and the efficacy has been verified by Adam Crain.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to crash the OPC Server application.

There is an interesting comment by ICS-CERT in the Vulnerability Characterization section of the advisory. They state:

“A vague interpretation of the DNP3 protocol may allow a null header to cause an out of bound read command to create large numbers of entries in the master in some implementations. This is not a universal problem for all DNP3 users, vendors or integrators [emphasis added], but it may occur.”

That plus a reference to a DNP3 Application Note addressing this issue seems to indicate that this is a problem that might affect other systems. Not that Chris and Adam have ever found vulnerabilities in DNP3 implementations that affect multiple platforms (sorry for the low level sarcasm here). As of 9:00 pm CDT this advisory is not listed on the Project Robus web site.

Siemens OpenSSL Update

Well it looks like we are going to need at least update G to get this correct. Yesterday ICS-CERT reported that ROX 1 was the only outstanding affected system without an update; completely missing the APE 1 with eLAN and ROX 2 with eLAN. Well, with the Siemens ProductCERT announcement today that the ROX 1 update was now available ICS-CERT is still failing to report the continuing vulnerabilities in APE 1 with eLAN and ROX 2 with eLAN. Well, maybe tomorrow.

Ruggedcom Certificate Update

ICS-CERT missed the earlier announcement that the ROX 2 update was available, but they did catch up today when Siemens ProductCERT announced that the ROX 1 update was now available. So far so good. Unfortunately, ICS-CERT also changed their reporting of the affected versions of these two devices. It was correct and had not changed in the latest Siemens report. I know; minor details.


I’m beginning to wonder if anyone at ICS-CERT actually reads the Siemens alerts. The bigger question is how accurate are the other vulnerability reports from ICS-CERT, the ones that we can’t check because the vendor is not as meticulous in reporting their vulnerabilities as is Siemens?

Wednesday, October 15, 2014

ICS-CERT Updates Bash and Siemens OpenSSL - Issues Pyxis Advisory

Today the DHS ICS-CERT published four documents concerning vulnerabilities in control systems. One is actually a correction to yesterday’s Siemens OpenSSL update. Then they updated the BASH advisory and issued a supplement to that advisory. Finally they published a new advisory for a medical supply system with multiple vulnerabilities.

Siemens OpenSSL Update

Yesterday ICS-CERT published an update for the Siemens OpenSSL advisory that reported that all affected systems had updates available. Today they are reporting that what Siemens actually said was that a new update was available for ROX 2-based devices. And it reports that Siemens is still working on an update for ROX 1.

Oops, no, they got it wrong again. According to the Siemens ProductCERT advisory, the newest update only affects ROX V2.6.0 with Crossbow V4.2.3.  There are three products listed by Siemens that do not currently have updates available:

• APE 1 with eLAN installed: All versions <= 1.0.1;
• ROX 1: All versions (only affected if Crossbow is installed);
• ROX 2 with eLAN installed: All versions < V2.6.0

Sorry. I did not read the Siemens ProductCert advisory on this yesterday; I trusted ICS-CERT to get it right. Well, maybe they’ll get it right tomorrow. And that will be version ‘F’ when we should still be on version ‘C’. Oh well….

BASH Advisory Update and Supplement

Back in September ICS-CERT published a brief advisory on the Bash command injection vulnerability. I was kind of busy at the time and didn’t write about their advisory because much more complete information was readily available elsewhere. Well, today the published an update to that advisory that was not much better. The only change was the addition of the following paragraph:

“ICS-CERT sent out a query to vendors we have collaborated with in the past. Many have responded back with information about which products are affected by this bash vulnerability. ICS-CERT created a supplement to this advisory that contains this information. It can be found at the following web location: https://ics-cert.us-cert.gov/advisories/Supplement-ICSA-14-269-01. This supplement will be updated with additional information as it becomes available, without updating this advisory.”

So now we have a new ICS-CERT document that will be periodically updated so they don’t have to update the advisory so often??? Okay, what ever.

Okay, the supplement provides some useful information. First it provides a list of companies that have responded to ICS-CERT inquiries about potentially vulnerable systems. Then it provides a list of vulnerable systems (by vendor) with links to further information. It is not clear that systems from vendors on the first list that are not listed on the second list are actually not vulnerable. I think that that may be a dangerous assumption to make. In any case, selected products from the following vendors are reportedly at least potentially vulnerable:

• ABB;
• Cisco;
• Digi;
• eWON;
• Meinberg;
• Moxa;
• Red Lion (pardon me; use bash shell but “are not considered to be vulnerable or exploitable”; and
• Siemens (okay, this lets them off the hook for not mentioning the Siemens ProductCERT advisory yesterday).

Pyxis Advisory

NOTE: This is for a medical supply control system, not really an industrial control system, but hey the FDA won’t touch this and ICS-CERT doesn’t have anything else going on right now….

This advisory is for multiple authentication vulnerabilities in the CareFusion Pyxis SupplyStation reported by Billy Rios. CareFusion has produced a new version of the software that mitigates three of the four vulnerabilities. No mention if Billy was given the chance to verify the efficacy of the fix.

ICS-CERT reports that the vulnerabilities are:

• Hard-coded password, CVE-2014-5422;
• Hard-coded credentials, CVE-2014-5421 and CVE-2014-5420; and
• Insecure temporary files, CVE-2014-5423

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to manipulate the locking controls on the automated medical supply cabinets. I don’t expect that these are used to dispense narcotics or else the DEA would be involved.


CareFusion reportedly will not be offering a fix to one of the hard-coded credential vulnerabilities because it would only allow access to some application files, but not the physical access controls. That would seem to be a reasonable risk assessment decision if it was made by the system owner, not the manufacturer. Good news, it will be fixed in future versions.
 
/* Use this with templates/template-twocol.html */