Microsoft Security Bulletin MS10-046 was released this morning and has extensive detail on how to patch or workaround the vulnerability in windows shell that allows remote code execution.
A couple keys points in the advisory:
First, Microsoft notes that the exploit only gains the rights of a local user. It is fine to suggest a role-based control approach. It is a best practice. However, everyone knows that Windows runs best with a local user in the Administrator group. It echoes my earlier post on this issue, where I tried to emphasize that this story has not significantly moved the dial in terms of Windows exploits. It is significant more because it was targeted to a specific vendor (Siemens) implementation of Windows. This is an excellent example of an Advanced Persistent Threat, versus an Advanced Threat. Persistence comes in the form of intelligence gathering and targeting specific/unique weaknesses. I would wager that Siemens software requires Administrator privileges.
Second, a specific service is implicated as an attack vector
Disabling the WebClient service helps protect affected systems from attempts to exploit this vulnerability by blocking the most likely remote attack vector through the Web Distributed Authoring and Versioning (WebDAV) client service. After applying this workaround it is still possible for remote attackers who successfully exploit this vulnerability to cause Microsoft Office Outlook to run programs located on the targeted user’s computer or the Local Area Network (LAN), but users will be prompted for confirmation before opening arbitrary programs from the Internet.
Once again we can say all unnecessary services should be disabled as a best practice and for compliance (e.g. PCI DSS). Nothing new here. WebClient is even disabled by default in server versions of Windows since 2003 (they also have a redirector option). It has been enabled in Microsoft desktop systems since Windows 98. Windows 7 even provides a webdav server capability.
The WebClient service does nothing more than allow webdav (Web-based Distributed Authoring and Versioning) access. The service description calls them “Internet-based files”, which is too broad to be a useful definition.
With this functionality in mind it is interesting to note that the attack was distributed by USB. A network-based attack was not chosen perhaps because the systems targeted were said to be disconnected from a network. A WebClient service should only be enabled on a system that needs to manage HTML files via HTTP over a network. So the advisory pins together a local hardware attack with a network service exploit.
Did the Stuxnet authors know that Siemens runs on Windows XP or 98 with default services enabled? Does Siemens WinCC software or the SIMATIC distributed control system require WebClient, thus making it a networked system after all? I would wager, as above, the Siemens systems were configured without security in mind and an unnecessary service was enabled.
Therefore, from the above two points, a Windows user who disables unnecessary services and uses role-based access would reduce the risk of attack.
The real rub in this issue is that these basic security and compliance controls may not be present in utilities and attackers will use this to their advantage. Change to the environment will not come quickly, unfortunately, because some continue to argue against it. Control systems specialists, for example, often try and defend control gaps as another form of control – necessary for safety
One workaround that Siemens users should avoid, however, is changing the default passwords on their control systems, warned control systems expert Joe Weiss, writing on his blog. “Microsoft wants default passwords changed — standard IT policy — while Siemens is telling its customers not to change the default passwords as it could cause problems,” he said.
The disconnect highlights how in control environments, safety — not security — comes first, he said. “The IT folks do not understand why anybody would want to keep a default or hardcoded password as an emergency back door. IT in enterprises, outside of banking, simply doesn’t have real-time emergencies.”
This is very wrong. I could give obvious examples of enterprise IT that has real-time emergencies outside of banking and utilities (e.g. health-care). More to the point, however, even an emergency back door can be setup in a controlled fashion. A vendor default password should not be confused with the need and option for an emergency back door. Role-based access is the difference. Only some people should be authorized to have access to the back door. Access to the back door also should be monitored and logged. I think it stands to reason that a back door that everyone and anyone can access, without an audit trail, actually increases the risk of real-time emergency.
P.S. Kudos again to Microsoft for a thorough and highly useful report on the update as well as the vulnerability. Customers benefit greatly from this exchange of information.
Compare Microsoft’s excellent work with the current method used by Google, as demonstrated by the update report for a High Risk vulnerability in Chrome:
[$500] [43813] High Issue with large canvases. Credit to sp3x of SecurityReason.com.
Imagine if Microsoft had posted only “[2568] Critical Issue with Shell. Credit to Stux.”
