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.

1 comment:

SynAckPwn said...

The .yara signatures were correctly hosted on the ICS-CERT domain, but the yara binaries (exes) were linked to. If github proper (or just the yara account) were to be compromised, those binaries could be replaced with anything. (with ICS-CERT still pointing asset owners to the same page for download)

In lieu of hosting the yara binaries on the ICS-CERT page (who knows, it's the government and they probably have a policy of not hosting files they didn't author) adding the md5 and SHA hashes are an acceptable mitigation step that is widely used. Really glad they took this additional step and hope future work is just as great, with a little OPSEC sprinkled in.

 
/* Use this with templates/template-twocol.html */