Comment from Matt Franz
Time: July 24, 2008, 6:02 pm

Really? How does this affect embedded devices that may not even have resolvers, as I would imagine is the case of many PLCS? How is the risk compare for hosts that only address internal nameservers and don’t directly query public nameservers. I haven’t been following the technical details (only the disclosure theatrics with Matasano) so perhaps I’m missing something?

Comment from chris
Time: July 24, 2008, 10:48 pm

Matt, the key is to protect your clients by way of patching the Internet facing DNS servers they use. If you have a recursive public nameserver and aren’t patched or don’t mitigate by way of limiting recursion to internal requests only and port randomization then your internal clients remain vulnerable.

Comment from Matthew Franz
Time: July 25, 2008, 6:56 am

Chris,

Thats all well and good, but that didn’t answer my question about how different SCADA environments are impacted (by defining a practical attack sequence that actually accomplishes something) depending on whether they maintain their own DNS (I would guess some do) whether they use IT DNS (the majority) or rely on public DNS — and tying those different scenarios to specific consequences to specific devices (that may or may not even have resolver that may or may not yet have patches available for them yet) etc. etc.

Comment from Dale Peterson
Time: July 25, 2008, 7:30 am

Matt - I don’t think PLC’s or other field devices are the issue - - yet. Many of the newer control systems, especially those that leverage active directory, use DNS for all the workstations and servers. So the HMI rely on it to find the realtime servers, historians, application servers, … Of course, this should be a separate tree/forest that does not communicate outside the zone, but some asset owners and vendor guidance does not make this clear because of the convenience and management simplification of tying it to the corporate domain or tree.

Frank hit on a key point which are devices in a DMZ like a PI server. Both the corporate and certain control system components to need to know how to reach these devices and that is another reason asset owners give why the corporate and control DNS communicate. Of course there are easy ways to eliminate this communication.

Comment from Jake Brodsky
Time: July 25, 2008, 8:35 am

Dale, I still hesitate to recommend things such as DNS and Active Directory because I don’t see enough benefit to outweigh the potential havoc caused by failure.

For this reason, we still use HOSTS files or even raw addresses. In cases where we have M2M communications, we actually use a single cross-over cable.

In the few places where use a DNS, we make sure the HOSTS file is properly seeded with all the addresses we might need to keep things going, just in case the DNS system has been compromised. Lots of embedded devices are left out.

I know, a DNS is supposed to save us loads of trouble. The problem is that if it fails or is given incorrect information, we can get in to major problems. This is the trade-off between ease of management versus survivability.

Active directory is another area where the paradigm of centralized control versus distributed operations must be dealt with. We’re going to think long and hard before deploying anything this complex. The risk may not outweigh the reward.

Comment from Dale Peterson
Time: July 25, 2008, 8:55 am

Jake - probably depends on the size of your HOSTS file and how often it changes.

The point I’m making is when you buy some of the new SCADA or DCS system [system in this case meaning HMI, Historian, Realtime Server, OPC or other application server, ...], the standard install relies on Active Directory. Users are entered into AD; authorization is set in AD; single sign-on is through AD, which could be smart card or other two-factor for admins or users in physically insecure locations. Some of these are very impressive, but they do affect the attack surface and add DNS to it.

So my comment is not a question of if DNS is a good idea for control systems - - - which is a valid question with pro’s and con’s. It is an essential part in many unless they made changes to remove it which rarely happens when the vendor says this is how our system should be run.

Comment from Dan Kaminsky
Time: July 27, 2008, 2:50 pm

I am the original finder of the bug.

Chris–no, your defense won’t work. If it will resolve a name from the Internet, it’s vulnerable. Any web browser or mail server can drive the resolution.

Jake–your paranoia makes me very happy. HOSTS files are indeed safe.