CRASHOVERRIDE guidance from NCCIC is confusing at best

[straycat19]

Posters Note:  I frequently comment on articles where the vulnerability being reported is the 'Perfect Storm' only reproducable in a lab.  This is an example of a protection that is impossible to do for the average network and person.

 

After reviewing the awesome Dragos Inc report on CRASHOVERRIDE , Rendition analysts received a similar alert from US Cert and NCCIC.  After reviewing the guidance from NCCIC, we were less than thrilled.  The second recommendation from NCCIC (take measures to avoid watering hole attacks) is impossible by its very definition.  A watering hole attack first compromises a remote site that you would already be visiting in an attempt to compromise your network.  The fact is that the victim is not being tricked into visiting a rogue site as is the case in phishing.  There is frankly no way for an organization to do this.  Unfortunately, the fact that this “mission impossible” is set as recommendation #2 means that many will stop trying to implement anything further down the stack, assuming that the rest may also be impossible by definition.

 

 

Other recommendations are from NCCIC are equally daunting. While I think it would be a great idea if everyone signed every release of software, that’s simply not reality.  Note the recommendation to “insist that vendors digitally sign updates, and/or publish hashes via an out-of-bound communications path, and only use this path to authenticate.”  We highly doubt that the federal government is drinking its own Koolaid here.  And if the US government with all its spending power can’t force this change, there’s little hope that smaller organizations can either.  Also, what qualifies as “out of band” for hashes?  We ask because if an attacker can get into the software distribution chain, it is highly likely that sending emails is probably also in their capability set.

 

Then it is also worth noting that NCCIC posted svchost.exe, without context, in its list of indicators.  To be fair, the Dragos report notes this IOC and does not specify additional context.  This is important, because svchost.exe is a legitimate process for Windows and is critical. Blindly implementing blocks on svchost.exe will either result in false positives (at best) or system instability (at worst).  However, the Dragos IOC list does point the reader to examine notes for the launcher module, which the NCCIC report does not do.  This is a great example of a “yellow snowball” effect.  Dragos reported the svchost.exe IOC with minimal context and NCCIC stripped that context.  Operators relying on the NCCIC report in isolation (as they should be able to do) are left with an IOC that is dangerous to apply.

 

This is sadly another report from CERT/NCCIC following a high profile hacking story that simply falls flat.  This is unfortunately not the standard for Cyber Threat Intelligence (CTI) reporting.  When it comes to reporting, validating your indicators and providing actionable Courses of Action (CoA’s) are paramount.  Instead of doing either, NCCIC has dropped the ball.

 

Source