Bandolier is our DOE-funded project where we are working with control system application vendors to define optimal security configuration for the various components (HMI’s, Historians, Realtime Servers, etc…). We then develop Nessus audit files that allow an asset owner/operator to audit their systems. Loyal blog readers have heard us discuss many facets of the project but perhaps have not actually seen the audit files and Nessus. We made a video to help introduce and demonstrate the project for those who would like to see it in action.

(Click once to watch the video, click again to see it in a larger window on YouTube)

For a more hands-on experience with Bandolier, join us in San Antonio for our training course. In the morning session you’ll get to configure and run Nessus, customize Bandolier audit files, and even create your own audit files from scratch.

The offensive security team here at Digital Bond spends a lot of our time attacking various control system components, from field device to SCADA server to HMI and everything in between.  A big part of these attacks is network analysis.  We examine the protocols being used to control the targeted systems, and in the case of unknown of proprietary protocols reverse engineer them, to try to find flaws in the way that the data is data, what functionality we can control without authenticating (far too often it’s far too much), whether its vulnerable to man-in-the-middle attacks, replay attacks, etc.  Seldom are we able to talk about the process or the results of that work, so a few nights ago I was testing out some software to control a media server and I found some interesting things.  Since its outside of our usual realm of work, I thought it’d be a good topic to write up the analysis, and give you all a glimpse into the process and the results.

My target was Logitech Mouse Server.  It’s a fun little piece of software that lets you use an iphone/itouch as a remote keyboard/mouse for whatever system the server is installed on.  On  initial use no surprise, it works as advertised, but I started getting a little curious when I was controlling the server without any pairing or validation.  Sleep was still a couple hours away, so I decided to take a deeper look into it and see what’s happening.

Down to the network layer we go.  First things first, let’s see what ports the server is using for the connections.  Using netstat, or its nicer looking cousin, TCPView, we see that 4026/tcp and 4026/udp look like our targets.

Using that information we put together a wireshark filter, “udp.port eq 4026 || tcp.port eq 4026” (eq can be read as “==” for those of you that don’t speak wireshark filter) and apply it to the session we’ve been sniffing, and we should see all the important traffic.

It looks like a tcp connection is established, but the data is passed over udp packets, which seem to contain very little data in each packet.  Interesting choice in protocol design since you’ve already got the overhead of the tcp connection and I’d guess that you would normally want keystrokes to arrive in the order that you press them, that’s the choice they went with so we’ll ignore that issue and move along.  Going down a little deeper and examining the individual udp packets.

Thankfully this protocol is probably the easiest protocol I’ll ever reverse since the client doesn’t send anything without you asking it to, and after going through a few packets you quickly seem the patterns emerge.  Here is the data section of the packets sending “test” to the server:

0000   00 00 00 0d 00 00 00 74 00 00 00 00 00 00 00 02          .......t........

0000   00 00 00 0d 00 00 00 65 00 00 00 00 00 00 00 02          .......e........

0000   00 00 00 0d 00 00 00 73 00 00 00 00 00 00 00 02          .......s........

0000   00 00 00 0d 00 00 00 74 00 00 00 00 00 00 00 02          .......t........

And here’s dumps of the  <WIN> key being pressed/release and then the <ALT> key being pressed/released:

0000   00 00 00 02 00 00 00 37 00 00 00 00 00 00 00 02          .......7........

0000   00 00 00 01 00 00 00 37 00 00 00 00 00 00 00 02          .......7........

0000   00 00 00 02 00 00 00 3a 00 00 00 00 00 00 00 02          .......:........

0000   00 00 00 01 00 00 00 3a 00 00 00 00 00 00 00 02          .......:........

Notice a pattern?  The first four bytes are always fixed when sending simple keyboard, like the ‘A’, ‘S’, or ‘D’ key, and its different fixed value for all meta keys like <CTRL>, <ALT>,<WINDOWS>, etc, and different yet again for mouse left/right and mouse up/down.  The 2^nd set of 4 bytes changes with each keypress

Putting this together, we see every packet 16 bytes in length, consisting of 3 fields,  a 4 byte big endian field to specify the type of command being sent, an 4 byte big endian field to specify the value being sent, and then a 8 byte field that seems to be some sort of increasing and seemingly random data, but in testing appears to be ignored anyways so we won’t worry too much about it.   Now onto the fun part, after testing our assumptions a few times with some quick scripting we’ve validated our analysis enough to move onto the next step, and that’s going to be creating a scapy layer so that we can make this a bit more abstract and modular.

Which is as simple as creating a file with this class, dropping it into the layers directory, and adding it to the layers to load on startup in the conf.py file:

class Logitech(Packet):

name = “Logitech”

fields_desc=[ IntEnumField("cmd", 0x0d, {1:"meta_off", 2:"meta_on", 6:"mouse_hor", 7:"mouse_vert", 0x0d:"send_char"}),

ConditionalField(IntEnumField("meta_key",1, {58:"ALT", 59:"CTRL", 0x37:"WIN"}),lambda pkt:pkt.cmd in [1,2] ),

ConditionalField(IntEnumField(“direction”,1, {1:”increase”, -1:”decrease”}),lambda pkt:pkt.cmd in [6,7] ),

ConditionalField(IntField(“character”, 0×41),lambda pkt:pkt.cmd in [0x0d] ),

LongField(“uselessstamp”, 0×02)

Most of the class should speak to itself, its just a collection of fields that are thrown together when the packet is built and sent out on the network, but I tried to make it somewhat user friendly using the enumfields to abstract it out a bit.  The conditionalfields are a nice feature that you can use within the scapy framework/libraries, making the defined field only exist in the generated packet if the condition is true.  The lambdas, well they’re just an anonymous function to do a simple comparison.

So we’ve broken down the protocol into its important bits, we’ve created a basic abstract class within a framework that we can easily send data.  Just a bit of fun and an easy exercise on your way to becoming a network ninja, right?  Well, probably, but there is a small legitimate security concern there, since by default the server runs on startup, and it has to accept external connections since that’s the reason it exists. Of course this type of attack is just slightly more stealthy than hitting someone with a wrench and typing commands into their system until they wake up, but nevertheless it could be used to run arbitrary commands. Say when the victim is particular engrossed in their morning coffee at Starbucks, they and any network that they log onto later could easily be

The larger issue, is to be wary of the applications that are not necessary for the tasks of a given system. Software that allows this kind of behavior is just fine on a media server a basement, but has no place on a system that’s ever going to be on an untrusted network.

The Digital Bond team will be at some events over the next four weeks.

Marco and I will be at Distributech in Tampa from March 23 – 25. We will be in the Department of Energy booth talking about our DoE funded Bandolier and Portaledge projects. Stop by and you can see a Bandolier demo and learn more about the projects. Appropriately and not surprisingly, the main thrust of most of the vendor efforts at the show is Smart Grid.

Jason and Daniel will be teaching the Advanced Control System Security Course on April 5 in San Antonio.

Jason, Daniel and I will then be attending ICSJWG on April 6-7. On the second day I’m part of a panel discussions with NERC, CIS, AREVA and TVA representatives. This should be a good panel because we are talking about configuration security audit and Bandolier from the drivers, to OS guidance documents, through Bandolier Security Audit File Generation and then finishing up with the vendor and owner/operator use of Bandolier.

I always enjoy meeting readers so if you are going to be at one of these events say hello or email me and set up a time to meet.

I’ll be tweeting and blogging on these events in case you can’t attend.

Last week, I discussed the updates to the active profiles and port ranges within rules features. Today, I wanted to talk about a couple encryption and authorization features. Specifically, the ability to dynamically create encryption tunnels and manage the users/computers that can and cannot communicate to the firewalled network service.

The dynamic encryption feature in Windows 7 allows a computer to communicate with an authorized entity, more on that later, without first having to negotiate the encryption tunnel. Once the entity is determined to be authorized and authenticated the system will use the IPSec quick mode feature to ensure that any further communications with the endpoint is encrypted by policy. Once the rule is created, you can then create a connection security rule that will create the IPSec tunnel that will specify how to authenticate (i.e. Certificate, Kerberos, etc.) and what type of tunnel to create (i.e. server to server, server to gateway, etc.).

The second feature that I wanted to discuss in this post is the ability to specify which users and computers are authorized to communicate to a host system. This feature was specifically introduced to work in conjunction with the secure connection features of the firewall. What makes this feature interesting is that you not only specify who is authorized but who is explicitly denied access to communicate encrypted to this system. You maybe asking yourself, why would I even want to use this feature?

Well, imagine you have a system in a higher security zone that you need to run your monthly Bandolier scan against. This feature would allow you to open the required ports and only allow your system engineers and the Nessus server to connect securely to the system to run the scan. Everyone else attempting to connect to these ports/services would be denied access. Thus enabling you to audit your system without sacrificing the confidentiality and integrity of the communications channel.

It should be noted that the dynamic encryption feature is compatible with Win7/2008R2 and the authorization feature is compatible with Vista or later.

• Patrick Miller, previously with WECC, is now the Technical Director, NERC CIP Practice at ICF International.
• Jake Brodsky, Bob Radvanovsky and some others from the SCADASEC list are organizing “The Gathering” on May 14-15 at the Marriott Courtyard Chicago Ohare. It will be interesting to hear what comes from this unstructured brainstorming, show and tell, hack and protect event. People are suppose to bring systems, deploy on site, hack and protect.
• The Agenda for the ISA Safety and Security Symposium on April 29th in New Orleans is now available. Nice level of detail in the abstracts following the schedule. Cost is $199 for ISA members / $299 for non-members.
• PNL, on behalf of the Dept of Energy, has created the American Recovery & Reinvestment Act Smart Grid Investment Grant [SGIG] web site. [HT: Michael Toecker]. The stated purpose is “Provide a resource enabling Smart Grid Investment Grant projects to understand the baseline principles and practices necessary to implement cyber security in the Smart Grid.” Anyone can access the info, but you do need to register.

For the past two weeks we have been working on integrating Portaledge with enterprise SEMs.  We added an outputSEM funtion in all of the Portaledge modules that writes normalized output to a file. The outputSEM function is designed to be easy to alter if an enterprise SEM does not have a method of interpreting log files. The output contains source and destination IPs, source and destination ports, the IP protocol, the triggers, time of the event and a shortened message.  The normalized events do no contain the event chains.

Here is an example of the normalized output:

03/10/2010 19:11:01 | Type: Portaledge | Event: Enumeration | Sensor: EnumICMP | DstIP: 192.168.10.181 | DstPort: 0 | SrcIP: 192.168.10.22 | SrcPort: 0 | Proto: 1 | Msg: Potential IMCP Scan with severity:4

03/10/2010 19:14:46 | Type: Portaledge | Event: MetaEvent | Sensor: Meta_BySrcAndDstIP | DstIP: 192.168.10.181 | DstPort: 0 | SrcIP: 192.168.10.22 | SrcPort: 0 | Proto: 1 | Msg: Meta Event of Type: BySrcAndDstIP: Source IP 192.168.10.22 and destination IP 192.168.10.181 with severity: 4

We have also created a prm file, specific to Tenable’s Log Correlation Engine and Security Center, with rules that will take the normalized Portaledge output and insert it into the Security Center. The prm file uses regular expressions to extract the IP address(es), port(s), IP protocol and trigger. These values are then mapped to the Security Center’s IP address(es), port(s), IP protocols, event names, sensor names and event types. Once these values are added to the Log Correlation Engine, they can be correlated with other logs and viewed in Security Center.

We will be releasing the updated Portaledge files, along with the prm file and a guide to assist in the deployment of Portledge with Security Center and other SEMs, in the near future.

I’m a huge fan of Tom Peters and came across this quote re-reading his Brand You 50 for probably the 8th time.

If the client is an ‘idiot’ who ‘just doesn’t get it’; and you’re a ‘long-suffering genius’ . . . you are d-o-o-m-e-d.

All too often we hear this “just doesn’t get it” attitude in the control system security space. Followed by everything is a disaster, and there has not been serious progress. First of all this is not universally true, a growing number of critical infrastructure owner/operators “get it”. Second, there has been significant progress improving the security posture. Admittedly far from everywhere yet, but that attitude is not going to get it done or help. It may get a headline or two, but is that really a worthy goal?

So this is one of many areas we follow Peters’ advice and only work with clients that we believe get it. Maybe the engagement starts as a check-box or cya project, but it is our job to help them improve their security posture and put together an effective cyber security program that improves year after year. We measure the success of each Client engagement on many factors, but the most important is impact. Is the Client significantly more secure and on a path to be even more secure after the engagement?

About once every two years we get a client who we can’t reach. We typically try for two engagements and if we have not gotten through to them, we have failed and stop working with them. It is as much our fault as theirs, and maybe another team will be able to find a way to educate, convince and motivate them.

By the way, every consultant and engineer on our team works on their personal Brand using the Brand You book and other resources. Jason, Daniel and I will be doing our brand equity review and brand plan for the next six months at ICSJWG. If you are interested in seeing how this works let me know.

PS – Looking forward to reading Tom Peters’ latest book, The Little Big Things: 163 Ways to Pursue Excellence, which is already downloaded to my Kindle.

Yesterday, I wrote a quick introduction to the Win7/2008R2 firewall.  Today, I will be discussing two really great Windows Firewall features that were updated but first I need to clarify something.  The features discussed within this and future firewall posts are specific to Win2008 R2 and not Win2008. This is because Win2008’s firewall feature set is based off of Vista’s not the latest greatest.  Now that I and Microsoft have thoroughly confused you, we can move on.

In Vista, Microsoft added a feature called Network Location Awareness.  In short, the service is able to detect when and what networks you connect to and tag them with different profiles (i.e. Public, Private, Domain).  These profiles are then assigned their respective firewall policy and rules.  However, if you had multiple active network interfaces it would assign the most restrictive policy to all the interfaces.

That has been changed in Win7/2008R2 so that each interface has its own firewall policy and rules.  An example of its use would be in a proxy server environment.  You could assign a more restrictive outbound and inbound policy to the public facing interface to only allow the needed ports to communicate to the internet and only the Internet.  Conversely, you could deny all traffic on the private interface except the ports you need to patch/update and send requests to the proxy.

The second feature that was updated, and my personal favorite, is the support for port ranges within firewall rules.  In the past, you had to create a firewall rule/exception for each port (i.e. pre-Vista) or comma separate ports (i.e. post-Vista).  Win7/2008R2 has now added the ability to specify ranges of ports in addition to the Vista functionality.

For example, an active and passive FTP rule in Vista would look as follows:

In Win7/2008R2, it would look like this:

As you can see the new rule structure helps you understand and update rules faster.  This would be very useful when enabling and auditing a control system, with several modules, to communicate through a firewall.

Recently, I was onsite at a vendor’s office as part of the Bandolier project and ran into a situation where the Win2k3 firewall was not enabled or configured. After the onsite visit and a little Firewall enabling, I started to think about how much the Windows Firewall has changed since WinXP/Win2k3. Specifically, I thought about how Microsoft added several features within Vista and has now introduced new/updated features for Win7/2008. All the new/updated features either added an operational or security improvement but I wanted to highlight the following features that I believe are the best of the lot:

• Multiple Active Firewall Profiles
• Support for port ranges within rules
• Dynamic encryption
• Tunnel mode authorization and exceptions
• Service Hardening and Firewall Triggers

I will be discussing each of the above features in follow-up blog posts starting tomorrow.

We are offering our Advanced Training Course on April 5th in San Antonio to make it convenient for those attending ICSJWG’s Spring Meeting on April 6 – 8. The afternoon module is on using and customizing our SCADA IDS preprocessors, plugins and signatures developed with funding from a DHS S&T contract.

The morning module will teach you how to use and customize the Bandolier Security Audit Files. Jason has developed a more detailed outline showing you what you will learn. It is ideal for asset owners or consultants who will want to use Bandolier for security audits and assessments.

There is still space in the course. Register at this link.