Last updated at Tue, 25 Jul 2017 16:23:28 GMT
Unless you've been living under a rock, you've probably seen some chatter about the Stuxnet worm and the patch now known to the world as MS10-046. This out-of-band patch Microsoft released on Monday plugged a hole in the Windows shell component which handles lnk file parsing. That bug allowed malware authors to piggyback their own malicious code to infect sensitive networks.
If you hadn't tasked yourself with reversing the worm to figure out it's internals, you'd think that it was exploiting a vulnerability that was limited to local execution--after all, the Stuxnet reports were widely focused on transmission of the worm through USB keys. However, Microsoft's release of the advisory tells us a different story -- now that we have a CVE and associated CVSS score (presumably submitted by MSRC): CVE-2010-2568. Looking at the CVSS vector (scored 9.3), we can see that it allows for remote (AV:N), unauthenticated (Au:N) execution but requires a bit of interaction from the user (AC:M). Why not AV:L? An attacker can coerce a user into viewing a lnk file exploiting the vulnerability by hosting something such as a CIFS share and coercing the user to visit that share. To equate the social engineering method to another type of (unrelated) attack, think of it like an attacker coercing a user to visit a link that exploits an XSS weakness in a webapp to grab that user's session cookie. In the Stuxnet case, SCADA environments (the most volatile of which are infrastructure related such as power plants) are usually totally disconnected or filtered from the internet.
Critical Infrastructure
SCADA environments are typically made up of proprietary equipment with shoddy implementations of contextually popular protocols such as DNP3 and ModBus as well as protocols popular in Corporate IT such as TCP. It is also common for these environments to use operating systems that have reached their end-of-life, and for the vendors of such systems to leave them unpatched for some time. This equipment is used to drive machinery, report statistics and control systems. In the case of power plants, a failure of even one of these assets can have a catastrophic outcome.
Perhaps by now you've asked yourself "why isn't there a clean room policy?". These systems are governed by the NERC CIP standards, which are relatively new. CIP is a gigantic forward for security in that industry, but it's still evolving. The standards cover a wide range of processes which build up a security management program. There is definitely a big focus on critical assets and the data around those assets, but no real policy of what data goes in. Additionally, there are stipulations for the use of a vulnerability assessment solution and endpoint scanner. That's a great mix of proactive and reactive. However, the accuracy of those tools depends on the vendors putting updates out for that 0day (which may not even be known to the public) and the internal policies of the plant that maintains them pertaining to updating the software. If either of those links fail, these environments are still vulnerable to an attack. NERC could improve this gap by more clearly defining policies on what and how data can be transferred into the electronic perimeter.
The great thing about the Stuxnet worm is that it kick-started scrutiny on SCADA environments again. NeXpose was updated with a check for this vulnerability this week, so go grab a copy and scan your own environment if you haven't already. I'm sleeping more easily knowing that there are now guys in black suits scrambling around...
-D
