Transport Layer Security - Part 1

Part of the Security Layer Series

Layer 4 is where the rubber meets the road as far as actual connectivity to the applications and logic of the controllers.

Layer 4 is the transport layer and for IP it typically means either TCP (Transmission control protocol) or UDP (User Datagram protocol).

I mentioned earlier that IP is inherently not deterministic and that has implications for automated control. Layer four is the first place where the compensations for this occur.

A quick run through of how TCP works will help some. I am going to grossly oversimplify here so if someone wants to correct or provide more detail feel free.

TCP establishes a session to ensure data delivery. A host initiates the communication by sending a TCP/SYN packet. The recipient of the SYN responds with a SYN/ACK with session identification information and the original host responds with an ACK/ACK establishing the session. Periodically during the communication stream the acknowledge process is repeated to ensure the communication is maintained. Checksums are included as an inherent part of the protocol. Time sent between packets received is monitored to determine if a session is lost and to initiate reestablishment of the communication stream.

What this means in a nutshell is that TCP has many mechanisms built into it that compensate (in part) for the issues introduced by the fact that IP is non deterministic. It doesn’t by any stretch of the imagination mean that TCP itself is secure in any way. There are many ways to game the system and hackers and worms use them to their full advantage. If you really want to get into the details take a look at NMAP and the lists at www.Insecure.org .

The most common one and the one I have seen cause issues on PLC’s is the syn scan. It basically works by opening up a listening port then streaming syn’s to all of the selected ports on every address that is to be inspected. Everything that responds with a syn/ack is logged. The connection is never completed with an ackack. This is where the problem is (especially for controllers with older IP stacks). The receiving host uses some resources to sit there waiting for that ack/ack. There are DoS attacks related to this but for the most part they are not that effective for newer IP stacks. (Syn floods can still cause headaches though) Unfortunately PLC’s do not always have newer stacks so they are often particularly vulnerable to this.

Aside:

This is directly relevant to the scanning discussions that have occurred with some level of passion on this blog’s comments and in the background via email. My advice here if you plan on scanning a scada system for the first time and you have done the change management it is best to start with a TCP connect scan that exits gracefully as your initial connection enumeration method. Limit the scan to a few interesting ports and don’t hit all 65k (at first at least). I wouldn’t even do fast scan ports. After you have a few under the belt for that address range then slowly expand. Do the fast scan ports then if wanted the whole 65k. After you are comfortable with this make sure you have people watching the equipment and have a recovery plan then try the syn scans. Once you have gotten past this point you can go on to the rest of your vulnerability assessment or pen test. I know this is insanely conservative for most Security professionals but the critics are not exaggerating when they want that bad things can (and will) happen. I am an advocate for scanning systems and have done so many times without significant issue on Rockwell/ABB, Honeywell, Siemens, and other vendor control systems but there is always a risk. My typical response to the DON”T SCAN crowd is “Sooner or later the systems are going to be hit by an actual attack or something that is functionally identical to one so wouldn’t you rather that happen in a controlled manner?”.

End of Aside

Many PLC vendors use TCP as their primary IP communication method to their controllers and all of them use it for their historians, MES, and control aggregation systems. I have seen a bit of an explosion in HTTP access to endpoints and I have mentioned ModBusIP in earlier posts in this series. I am not going to go into detail on what ports are used here. If you want to find out ask your vendor they will tell you. What you should do however is make sure that is possible you block access to the TCP port used as the primary PLC communication protocol at the point closest to the controllers as possible. ACL’s are acceptable if actual firewalls are not available. For vendors that use standard ports such as telnet, http, or RPC this can be somewhat more difficult to do. Take advantage of point to point and point to multipoint (subnet) rules. The key here is to not allow access to the PLC’s from an uncontrolled network. Access to the Historians and central control systems should be controlled primarily on a white list basis. For really large engagements such as regional operation centers it is often possible to isolate both the central and the local subnets and connect them via VPN tunnels. If you are doing this it is best to isolate remote sites from each other.

Enough for today

Rest of TCP and UDP continued later.

Vista Vulnerabilities

Two friends of mine Max and Ivan from Core Security talk with SC magazine about one of the weaknesses that Microsoft has not been able to completely close in Vista.

Good article and they are spot on about the ASLR issue. It randomizes memory utilization to help minimize the potential effectiveness (an attempt to get rid of them completely) of buffer overflow attacks. If it is used it will stop a lot and I would put it easily in the 80-90% effectiveness category but not perfect.

This is why I have been pointing to the solution offered by Determina for a while in this category. To be honest I am surprised Microsoft has hasn't bought them yet and integrated their product. I haven't been able to find any instance in which it didn't work to stop the overflow and it protects all the applications on the system.

Update:
I just discovered that Determina has started up a blog. If you get a chance Sandy or Alex why don't you tell us what the difference is between what you do and what he standard memory randomization methods do?

Application Root Kits? - help me

Some thoughts on Application level Root Kits from Matasano.

Ok quick question here? When is it a root kit and when is it something else?

A lot of this stuff sounds like Trojans or variants thereof.

I am reluctant to get into this discussion because the biggest flame war I was ever in involved semantics around root kits back in '98 but I am just trying to figure out how to classify some of this stuff.

Is it a "root" kit if it doesn't really touch the root? If it touches drivers that touch the root is that enough?

Perhaps another name would fit.

Appleech?

Just some non threatening don't hit me with the heavy metal object or set me on fire thoughts.

:)

More Fuzzing - Details

Digg it

Fuzzing was a very popular post but I can tell from some of my emails that there are a lot of people that really, really don't get it.

They seem to think that fuzzing is some sort of new hacking or pen testing method and that you can use it to get into a remote system that you know little or nothing about.

Nothing can be further from the truth.

First of all fuzzing has been out there for quite some time and is not new. Secondly it can help you find a weakness but only if you already have visibility of what is occuring.

Wiki has a pretty good description of what it really is.

Basically in order to properly fuzz you need to have total access to the target system and application and have the ability to do verbose logging (or at least watch the processes failures). All it is is jamming random (well more often targeted random) garbage at an input interface to the application. That input interface can be a table in a Db, a entry field in a GUI form, web form, IPC Mechanism, TCP or UDP port.

What the fuzzing tools do is make it easy to get to the point where you can most effectively spue the garbage and sometimes help you choose what kind of stink you want that garbage to have and finally watch what happens to the systems and apps when you do.

I'll repeat. Fuzzing will not help you (directly at least) break into a system you do not already have access to. With a few exceptions the best you can do with it is cause a fault and even then it is often only likely if you already have a pretty good idea of how to make it happen.

If you know what you are doing, PHP and/or Perl combined with detailed protocol and application interface documentation are the best fuzzing tools out there. Near unlimited versatility is the biggest reason I say this. The tools mentioned in the Computer Defense post are all great at getting you to the point of the data entry and even helping the random spue but ultimately you have to be able to analyze the failures (if any) that occur to get any value out of it.

If you are trying to find a completely new less than zero day they can help some but even then it is kind of like the infinite monkeys meme (certainly some will write great books) unless you already have a pretty good idea of what you are looking for.

Some of the tools can also be useful in manipulating systems in other ways but that really isn't fuzzing.

Digg It

Fuzzing

Dale has a good post up on Achilles which was Eric's project with help from an oil company before he founded Byres Security.

I would describe Achilles as a fuzzer for SCADA and DCS systems.

There was an effort (well thought really) to build Achilles testing into SP99 that Jay White at Chevron, and a couple of other oil industry guys were thinking of chasing shortly after the first SANS scada conference. I am not sure where it went. If I remember right Michael at INL and Ray and Sandia were also in that conversation briefly.

A standardized way to approach the process would be good for all ACS using industries.

This post at Computerdefense covers quite a few fuzzers not related specifically to SCADA.

Update:

More Fuzzing Detail here.

If you get a chance please visit the home page and mention it on lists or your own blog if you like it. This is a realitivly new blog and I am trying to spread the word.

A visit to CORE

Mike has a post up about our visit to CORESecurity last week. Anyone who has read me for the last several months knows (to use Mikes phrase) I drank the Core kool-aid a long time ago. I have probably already burnt my fuel plugging them already so I will let Mike do some of the plugging for me.

Argghhh I can't help myself

I used it for several years including time I spent as a pen tester at an organization that did dozens of companies including large financials.

They have a great product and if you are a pen tester and not using it then you either:

• Haven't actually looked at what they have
• are arrogant think you know better than everyone else how to pen test and are ignorant of how much time and money you can save per test while at the same time improving consistent quality and therefore probably stiffing your customers
• think it is cost prohibitive and have not talked to them about the options
• Are new to the game and think Metasploit is the cat's meow or running a Nessus scan by itself is actually pen testing
• Just have never heard about it

It has a place inside a non pen testing organization or normal IT shop as well

• Improving credibility while pointing out vulnerabilities to sysadmins
• providing CYA because of its detailed logging of what it does
• Impressing the hell out of executives in IT and the business alike
• Eliminating false positives from vuln scans
• as part of a simplified process to ensure visibility of internal and cross boundary (read firewalls/DMZ/Segmentation) weaknesses (SCADA!!!)
• To pen test yourself for less cost (You can do it monthly even in large companies)

I have used it on Automated Control systems (SCADA) without causing any problem including Honeywell, ABB/Rockwell Siemens and Emerson. (with proper notification and management of change of course)

OK Blatant plug finished. Hey if something works and has helped me I like to tell others.

5 Myths - Part 6 of 6

Part 1

Myth # 5 - You cannot scan or update Automated Control systems.

Scanning and updates are just as essential for these systems (or more important because of the geographic and ownership distributions) as any other IT system. Scanning and updating needs to be done carefully, within change management and with good communication to the users of the systems.

The key phrase here is change management. All stake holders must know when and how the scans will occur. From the Engineering Authority to the operators (current, off going and oncoming) everyone must be informed. This also means that you need a tool to do the scanning that is able to track and log (verifiably) to the second exactly what it is doing to the end system.

The last part is why I prefer CoreImpact over Nessus.

Both are good but Core gives you verifiable CYA. (and in many cases easier granular control)

In all cases you should know what you are doing to what, when, and why and be able to explain it to the engineers and operators. If you can't then you shouldn't be doing the scan.

With the caveats made once you get the process down it becomes a non event (other than fixing the problems that are found which for a while will be many). It was a weekly event at one of the companies I was CISO at.

As for updates not only is it possible to do them it is essential that they are done. Again with proper change management not just arbitrarily.

Mainstream

It was bound to happen.

Troublesome

This is just another indicator that SCADA and DCS security issues are going mainstream.

Those of you have known me over the last eight odd years also know that I am a firm advocate of the need to enumerate and look for vulnerabilities on even SCADA networks. Within that context I am happy when tools become available. Still this indicates that these issues are reaching a clear tipping point as it relates to bad guy target cross section.

I am a big fan of Tenable and long time user of Nessus and my concern is not directed at them.

(I have preferred Core for the last 4 years though. Much more than a vuln Scanner)

My concern is that now the security of obscurity is clearly flying out the window.

It was bound to happen.