MS12-020 and Control Systems

Earlier this week, Microsoft released a strongly worded advisory regarding a Critical vulnerability affecting the Remote Desktop Protocol (RDP). I’ve been looking over the advisory, and now that Luigi Auriemma has also released his original Proof of Concept there’s even more detail to go on.

There are tons of posts, assessments, etc out there on the ‘Net now, and I’m not going to regurgitate all that data. What I am going to do is explain some mitigation actions for an assumed audience of Control System engineers, and lay out a basic process for mitigating that involves vendor participation.

RDP is used in control system environments as a remote administration and maintenance tool, or as a means to access an application that engineers can’t distribute over their entire infrastructure due to licensing costs. It’s especially used in multi-vendor environments, basically to allow a single console to act over the multiple vendors. It is also used extensively for remote troubleshooting and maintenance activities, one of the higher risk functions. I’ve even seen it used as a primary method of operator interaction with the central SCADA server. In summary, it’s used everywhere, rarely managed on the internal network, and is often allowed from the corporate network and even over Internet (doubt that?).

The consequences of being exploited are severe: Computers targeted by currently available exploit code will freeze, show a blue screen of death, or will slow down and crash processes. Use of Remote Desktop in a control system environment on unpatched systems makes that system vulnerable to losing control of the process due to unavailable workstations. Proof of concept code is available on the ‘Net as we speak for crashing systems via this bug. Additionally, this exploit has the potential to be wormable, which means that even systems that are not directly accessible via the Internet could be affected as secondary infections.

The first level of mitigation is to identify, and eliminate, any remote desktop connections that can come from outside your control system network perimeter. If Remote Desktop (TCP 3389) is allowed through the perimeter unchallenged, you are vulnerable. The use of multi-factor authentication (like that required for NERC perimeters) is also a good mitigation measure.

Second, identify all systems within your perimeter that have Remote Desktop enabled, and list them as vulnerable. Go through each system individually, and disable Remote Desktop unless the system literally cannot function without it. If you aren’t sure how to disable Remote Desktop, there is a simple instruction. This exercise mitigates the vulnerability to each individual system. As operator workstations are typically highly critical systems that run Windows XP, prioritize disabling Remote Desktop on those systems.

Last, work with your vendors on how to best patch your systems. You’ll need to ensure that the Remote Desktop patch doesn’t affect your process, but recognize that your systems are vulnerable until patched. Back at my old job, this is a patch I would recommend be applied to vulnerable systems within the next 2-3 weeks, namely because it affects only the Remote Desktop service, and not any other underlying APIs and functions. I would have classified it as “low risk to process, high-med vulnerability”. But, we also had extremely good perimeter protection, without that protection systems would be highly vulnerable.

While Microsoft’s posts discuss that Network Level Authentication (NLA) is a possible mitigation measure, for control systems it isn’t. Critical Control systems just don’t stay as current as IT systems, and our highly critical systems are often running Windows XP or Windows 7, not Server. NLA requires specific measures to be installed on both clients and servers, which takes much more time than simply disabling Remote Desktop until you are patched.

I’m going to spend some time looking around at control system vendor sites to see what guidance is available on how to patch affected systems. If you want to help me out, let me know of any guidance you’ve seen via the comments below, via twitter (@mtoecker), or via email (toecker@digitalbond.com)..

Our Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.