- Schweitzer Engineering Laboratories [SEL] has published the SEL Process for Disclosing Security Vulnerabilities on their web site. They also have a page that tells researchers and others who discover security issues how to contact SEL and provide the information. Nicely done. Has your vendor addressed the disclosure issue and provided a poc for externally identified security issues?
- Another edition of the SANS SCADA Security Summit is scheduled for Feb 2-3 in Orlando. It looks very similar to previous summits, which was a complaint I heard from past, multi-summit attendees. That said, if you are new to control system security it is a great event to get a grounding in the basics.
- Sorry to say there will be no October podcast since I’m on the road for a prolonged period of time and away from the Digital Bond Podcast Studio. We will be back in November and have a special year end show planned for December.
Archives for October 2008
I will be previewing one S4 2009 paper each week. Digital Bond’s SCADA Security Scientific Symposium is Jan 21-22 in Miami Beach with an advanced control system security course on Jan 20th.
- See the full agenda with detailed paper descriptions
- Register to be a physical or virtual S4 attendee
Last week’s preview focused on physical layer vulnerabilities in IEEE 802.15.4, the protocol underlying Zigbee, ISA 100, WirelessHART and other protocols being considered and deployed in control systems. This weeks preview is a companion paper that focuses on IEEE 802.15.4 implementation errors at the data link layer. The two papers lead off S4 Day 2 and should be a very interesting pair.
Low Level Design Vulnerabilities in Wireless Control System Hardware
The IEEE 802.15.4 protocol can suffer from hardware and software implementation vulnerabilities like any other protocol implementation even if the underlying protocol is vetted and considered secure. In this paper the authors, Bradley Singletary and Darren Highfill of EnerNex and Travis Goodspeed of UT/Knoxville, analyze 802.15.4 hardware and firmware implementations for vulnerabilities and resistance to attacks. Since popular hardware and firmware implementations of low layer protocols are often used in multiple vendor implementations, this work could have widespread ramifications.
Topics in the paper and presentation will include design induced vulnerabilities such as the extraction and modification of communications device firmware, man-in-the-middle attacks between chips of a communications devices, circumvention of protection measures, bus snooping, and other attacks. This abstract has me eagerly awaiting the full paper.
Other S4 Previews
Quickdraw is our DHS funded research project to create a passive security event log generator application for legacy field devices that lack security logging capabilities. We just published a SCADApedia page with a drawing that shows the Quickdraw architecture.
As the drawing shows, we are extending Snort with additional preprocessors and plugins. The control system protocol plugins reconstruct the request and response messages and strip the lower layer formating from the serial protocol before passing the message to the Snort detection engine. We have completed a DNP3 preprocessor, and others are planned. These preprocessors should also be helpful in developing additional SCADA IDS signatures and may help provide deep packet inspection for field firewalls.
The most challenging plugin is the Quickdraw trigger detection plugin because it triggers on data in both request and response packets. Multi-packet detection is something that Snort has traditionally not done very well. There are also plugins to create the security log event after detection and to send it to historians, SEM’s or other log aggregators.
FYI – we are looking for a bit more help writing the Snort preprocessors and plugins. Full and part time available for experienced Snort developers, email us if you are interested.
Last month I mentioned briefly that there are additional functions of Nessus credential checks beyond the policy compliance plugins we’re using for Bandolier. The example in that blog post allowed you to “scan” all 65,535 ports safely and with minimal network traffic. Another example is the ability to check for the MS08-067 vulnerability announced by Microsoft last week. In fact, there are a number of plugin families and “local security checks” that verify patch levels for the OS and many client applications. They are available for Windows and most of the popular UNIX and Linux distributions.
The same arguments we use for the safety of the Bandolier audit files versus traditional scanning also apply to the broader category of Nessus credential checks. The risk of crashing a service or causing other problems associated with scanning control systems is drastically reduced. The credential checks, as the name implies, require a valid user and password, The packets that are sent to the remote machine are normal and expected: SSH for *nix, SMB for Windows, and (once authenticated) normal OS-level queries for information. Contrast that against traditional scanning where the machine can encounter high levels of unexpected traffic.
If you are in charge of security for control system server and workstations, the credential checks are definitely worth a look — even if there is not a Bandolier audit file for your specific application. You can gain insight on patch levels and, indirectly, vulnerabilities. You can also use the baseline audit files to measure your configuration against NIST or CIS benchmarks.
Traditional vulnerability scanning certainly has its place; you need to know what your system looks like from a network perspective. But where safety, speed, and accuracy are concerned, it’s hard to beat the credential checks.
It’s a busier day than usual in regards to network security, and a couple of those events are worth noting here.
For starters it looks like some malware delivery website(s) are targeting industrial control software. An older vulnerability in an ActiveX control included with ICONICS OPC-enabled visualization tools is being actively exploited by at least one website, and in the malware “business” if one is doing it then 100 others probably are as well. The good news is that there has been a patch available for a while, and you can always killbit the specific control, 9d6bd878-b8eb-47e5-ab1c-87d74173baa, if patching isn’t feasible. At first glance it would seem like an exploit for this is being targeted at an awfully small group of people, but perhaps the distribution of this ActiveX control is a lot bigger than we think? Hard to know why this bug was chosen to go along with the others they target, but maybe since these components are free to download the malware guys are banking on it being installed with a lot of other software. Unless its these pages are going to be used as part of a spam campaign they don’t seem to be very targeted and normally attacks like that are going to be a lot more precise and not just serving malware from a site that’s well known enough that Google warns you that its dangerous. On a side note, the affentiy that SCADA developers seem to have for ActiveX controls combined with with web interfaces into control systems being more and more common makes for a sitation thats difficult to secure in a proactive way.
The second interesting event is that Microsoft released an out of cycle patch today in response to some active exploitation around a bug in their RPC interface. This is the first MS bug patched in a while that is exploitable with default configurations and pre-authorization, and that means its possible to result in someone writing a worm to attack it. I know some researchers have already got proof of concepts written, and the bad guys normally aren’t far behind. This shouldn’t affect the control system space too much, as most of the time firewalls and such are in place to block the ports necessary for this to be exploited, but now is as good a time as any to make sure the right firewall rules are in place protecting your HMIs and such. Worms are nasty business, and require a lot of time to eradicate even in the best of circumstances. More specific information and a very useful chart are on the SVRD blog.
Update: Yep, worm in the wild.
I will be previewing one S4 2009 paper each week. Digital Bond’s SCADA Security Scientific Symposium is Jan 21-22 in Miami Beach with an advanced control system security course on Jan 20th. See the full agenda with detailed paper descriptions and register to be a physical or virtual S4 attendee.
This first preview deals with a subject rarely discussed because it is outside the area of expertise of most IT and control system security professionals.
Jamming and Interference Induced Denial of Service Attacks on IEEE 802.15.4 Based Wireless Networks
Most of the discussion on wireless control system security, whether it be ISA 100, WirelessHART, Zigbee or other 802.15.4 based protocols, has focused on authentication, encryption and other security technologies at layer 3 and above. Jake Brodsky and Anthony McConnell of the Washington Surburban Sanitary Commission will present a paper discussing if all that protection is moot. Can an adversary or unintended broadcast attack the physical layer and jam or interfer with the wireless signal to create a denial of service condition?
It’s hard to believe that there has been very little theoretical work and even less practical testing on this important topic. The intent of the paper is to review the validity of IEEE 802.15.4 Annex E, to verify the performance of an adjacent band carrier interference source, and even an ISM band carrier. Pulsed signal attacks, with the pulse width and repetition rates designed to hit each OFDM carrier on every channel, or to match the spread spectrum chip rate, will also be evaluated. Jamming/interference ranges will be discussed mostly in terms of decibel differences.
Improvements in security and availability when using antennas to focus radio energy toward particular areas of interest and to exclude other areas of interest are discussed. There is at least one particular insight that ought to raise many eyebrows (and no, it’s not about polarization).
This is actually the first of two papers on 802.15.4. The second paper deals with Layer 2 hardware attacks and will be previewed next week.
Having been involved in this industry (control system security) for the last five years, a quick examination of what progress has been made in securing critical infrastructure leads me to the conclusion of “not very much”. The industry if still plagued with the same basic vulnerabilities (as noted by the recent release of 3 very simple buffer overflow vulnerabilities and exploits into the public domain) and misconfigurations that were all too common 5 years ago.
Asset owners, those who are actively pursuing more secure deployments, are oft to note that the realities in which they operate are not conductive to security. They deal with old legacy systems with no built in security, the which they can not readily patch, or upgrade. When confronted with the inherent weaknesses in their environments their response is too commonly “we simply can not do anything about it.” There needs to be a paradigm shift then in future products that does not leave asset owners and operators with no options. The reality of their situation needs to change.
As a solution to the legacy problem is not readily apparent, I offer some ideas for future products. Though, in some ways security for control systems has taken “one step forward and two steps backwards”.
What I mean by this is over the last 5 years many companies have had their products examined by researchers, and vulnerabilities have been found and fixed. Yet many “features” in new product lines expose the control system to a wide variety of other exploit pathways. New products with web server management consoles, web based HMIs, and ethernet based “safety systems” quite frankly, give me the willies.
My Wish List for future control system products (or what features I would look for in a control system):
- Product should provide some form of strong integrity and authenticity control for all on the wire communications. This could be either IPSEC or TLS based.
- All system components (hardware, software, field devices etc) should require strong passwords using a strong form of encryption and all password exchanges and key exchanges should be encrypted.
- Software, hardware, field devices, etc. must change ALL default passwords upon initial installation.
- Systems should have exceptional logging and auditing capabilities.
- Products should not come with email, web browser clients by default. HMIs, operator work stations, FEPs, historians, etc should have these removed as they are now the number one exploitation vector in the IT sector.
- Control systems should not use a web app based HMI interface requiring the use of a web browser by operators (see above).
- All unnecessary software should be removed minimizing the attack surface.
- Products should not have unsecured web based interfaces into management consoles. All web server based management products must use SSL and require an authenticated login. No blank passwords or default passwords may be allowed.
- The system must not have outward facing (from local segment into internet etc.) services necessary for its operation.
- Safety Systems should not be ethernet based as this exposes them to common IT vulnerabilities. Do we really want the safety back up systems vulnerable in this manner? (I am aware of a least two teams that have hacked ethernet based safety systems to the point where things that shouldn’t have been able to happen, happened. In test lab settings.)
- Firewalls should be a standard part of every deployment, configured specifically for the environment. The firewall should strictly limit communications to those expressly needed, and should also limit the local segment (control system) communications to those expressly required.
- ACLs should be part of the package that limit what operation users can perform. File system ACLs should also be standard.
- An IDS with the best available rule-sets for the control system should monitor all traffic into and out of the control system. This will alert to the majority of common exploits and returning communications.
- Host Based IDS (HIDS) should be present on all the systems. They should monitor for out of character traffic, modification of files, and the execution of out of character executables.
- Products should initiate patch upload from the downstream side and not allow patches to be pushed up to the field devices, servers and workstations. Patches should also be signed by some type of hash to authenticate and validate the patch.
- Systems should provide redundancy such that patches can be pushed up in real tine with out negatively impacting operations (availability). (This one may qualify as a pipe dream.)
One last story from ISA Expo. The beta release of Bandolier came out the Monday of ISA Expo and included security audit files for four Telvent OASyS DNA components. An attendee from a large oil company had a security assessment scheduled for the next day. He actually downloaded and used the Bandolier security audit files.
He said a lot of great things about Bandolier. The Bandolier security audit files for Telvent have over 1000 individual audit tests total for the four components, so he came in with a lot of credibility on knowing what to assess in the system. The detailed results on each individual non-compliance blew the owner away.
I’m going to make a bold and somewhat self-effacing statement here. No one in the past could assess the security settings of a Telvent system in the level of detail possible now with Bandolier. Digital Bond has done a number of assessments of Telvent OASyS SCADA systems, and we were not able to come close to the completeness possible now with Bandolier.
Don’t take this as Bandolier being a complete assessment solution. There still is a need to look at system architecture, user roles and authorizations, redundancy, as well as use other scanning tools … However, if you have a system with a Bandolier audit file it would be crazy not to use it in the assessment. Digital Bond does assessments in our consulting practice, and believe we are among the best, but we fully expect and hope other assessment practices use the results of this Department of Energy funded research.
The early adopter also found a problem in some hyperlinks to documentation and had some helpful suggestions to organize sets of documentation in PDF’s in addition to the pages. Please email us your feedback.
With the advent of exploits of control system component and application vulnerabilities in the wild, we have added a fourth category to Digital Bond’s IDS signature package – – Vulnerability Exploit IDS Signatures. There are currently three of vulnerability exploit signatures.
All can see the list of IDS signatures in the SCADApedia:
- DNP3 Signature List
- ICCP Signature List
- Modbus TCP Signature List
- Vulnerability Exploit Signature List
Subscribers can download the complete IDS package that is now on Release 3.3. The package includes the signatures files by category, configuration files, and test data to trigger the protocol signatures.
Most IDS vendors, i.e. Cisco, Juniper, Tipping Point, …, have added the Digital Bond SCADA IDS signatures at some point over the last three years. Unfortunately we have no idea of how they are updating these signatures or tracking new signatures we develop. You will have to check with your IDS vendor, especially if you have a control system application with an exploit in the wild.
Subscribers also have access to the documentation page for each signature. The documentation pages are classic Snort documentation format and include useful information such as impact, ease of attack, false positives and false negatives. They are linked to the tables by category, see this page, and if you use the reference file in the package your results will directly link to these pages.
As a harbinger for future signatures, imagine what we will be able to do with control system protocol preprocessors developed as part of the Quickdraw project.
If you are responsible for defending networks and systems, you have many different tools at your disposal (unfortunately so do the attackers). There are many products on the market, from firewalls to intrusion detection/prevention systems, that aim to protect your valuable resources. There are also many host-based products, such as host-based intrusion prevention systems and anti-virus software which live directly on the host and protect your systems from harm. Don’t get me wrong, I believe that all of these defensive measures are fantastic and you must use them in a layered approach to secure your networks and systems.
However, the one defensive layer that cannot be overlooked is system hardening (This was all we had before all the fancy defensive tools). This means without third-party tools, go through your settings, permissions, and other configuration parameters, to ensure that the system is secure. I believe this has been something that, from a defensive perspective, some have overlooked or forgotten about completely. This is why I am excited to be working on the Bandolier project, which was created to develop Nessus audit files to help harden control system application components (See Jason Holcomb’s postings for more information).
To start, I’ve been going through some of the various system hardening standards and guidelines trying to find which ones work best. I’ve found several great resources in this area which I want to share, which include:
- The NIST Special Publications (800 Series), specifically 800-53 and 800-68
- The Center For Internet Security (CIS) maintains best practice security standards for all major platforms. I’ve been working with the Windows Server 2003 template, and really find it useful.
- DISA (Defense Information Systems Agency) produces some of the best, and most restrictive, system hardening guidelines. For example, I really like their Windows 2003 Security Checklist Version 6, Release 1.8 and frequently use it as a starting point (similar to creating firewall rules, I like to start with a “Deny All” policy).
The nice part is that the commercial version of Nessus gives you access to audit files that can test your systems against all of the above standards. A great example of how the audit files actually work, and tests for a flaw that I am particularly fond of exploiting, is the Tenable blog posting on Auditing Windows 2003 Servers for Disabled USB Drives and AutoRun CD-ROM.