Dale Peterson Eric Johansson from Management Doctors in Sweden brought over a great Siemens S7 demo rack to demonstrate some attacks on the Siemens S7 PLC family.
At 7:45 Erik shows the Level 3 (highest security that controls read/write access) can be recovered by capturing the packets sent to the PLC. This was actually known and included in Siemens documentation (July 2011) as a potential weakness — with advice to not let the bad guys on your network.
At 14:13 Erik shows a denial of service attack on the Siemens equipment he brought to S4x13. It requires a power cycle and administrator action to put the PLC back into Run mode.
The Q&A at 18:19 is quite interesting.
Arne Vidstrom of FOI was part of the team that did this work.
Dale Peterson  Odd and troubling week.
DHS Secretary Napolitano announced Enhanced Cybersecurity Services — the US Government will share information on 0days and threats via a paid service offered by private government contractors like AT&T, Raytheon and Northrup Grumman. This would even include 0days purchased from researchers. Does this make or break the 0day market? How does this compare to a bug bounty? this is so odd it’s hard to even come up with a cogent argument for or against your tax dollars at work.
The US NIST published a document analyzing the request for information (RFI) responses to the upcoming cybersecurity framework. Respondents think it should be flexible, global, risk-based and leverage existing standards. Ok …
NIST issued Revision 1 of SP800-82 Guide to ICS Security. More importantly they announced an effort for a major update of this document to Revision 2 in the next year.
The NY Times and most other major media vaguely reported on cyber attacks on energy sector companies with the goal of sabotage or control of the ICS. The information is based on a non-public bulletin from ICS-CERT.
Anonymous announced Operation Petrol will start on June 20th against “greedy oil companies” and governments that support them.
The US Security and Exchanges Commission (SEC) reported that the 27 largest public companies sustained no major financial losses due to cyber attacks.
Tweet of the Week
the same public that says the #nist cyber security framework should be "risk based" says "baseball should include baseballs" #nistcsf #eo Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by ChrisInPlymouth
 
Dale Peterson 
If you had any doubts about the thirst for ICS security news in the press, this week’s articles on some research from NC State provided a vivid demonstration. NC State puts out a press release on some early research, far away from anything that can be purchased, questionable if it would be of value in and ICS, and it turns into articles such as New Software Protects Networked Control Systems From Cyber Attacks.
Let me be clear that is not a knock on the research itself. We have been advocating and highlighting ICS security research for almost a decade now with our S4 conference. The researchers at NC State have an interesting approach that we might consider worthy of a slot at S4x14 or some future event as it develops.
The paper Convergence and Recovery Analysis of the Secure Distributed Control Methodology for D-NCS is available online.
The base idea is to eliminate sensor data from a process if the sensor or device passing the sensor data has been compromised. Actually, this could be due to any fault, not just a physical or cyber compromise. The challenge is how does the system know the sensor or device has been compromised?
The researchers rely primarily on a consensus algorithms, which I believe would severely limit it’s practical use. The example given in Section V.A is easy to understand. Eight temperature sensors take a measurement, and sensors 5 and 6 vary significantly from the converged value of the other six sensors. They are considered compromised and excluded from the process.
The problem with using consensus algorithms to detect cyber attacks or other anomalies is it requires the deployment and maintenance of a large number of additional sensors that don’t exist today in most control systems. Many times sensors are not redundant (let alone in numbers to allow consensus calculations), but data smoothing/interpolation takes place to remove and replace flawed or missing data. In a sense the researchers suggest doing this in a brute force way rather than through intelligent use of surrounding state and data.
There are high risk / high value sensors that implement a simple variant of the consensus algorithm suggested by the researchers. For example, you will sometimes see three sensors used in the chem sector, and one of the sensor’s data discarded if it varies more than a certain percentage from the other two sensors’ data.
If this is pushed out to the field or plant, as the researchers envision and makes sense, then the consensus algorithm would be implemented in the PLC which is much more likely to be attacked than the sensor. And there is still the data integrity issue in the PLC demonstrated by Stuxnet.
A more promising and realistic and difficult approach is to combine the suggested removal of data from a process with process anomaly detection rather than consensus algorithms. There have been a few sessions at S4 where researchers have tried to model possible states of a process and detect when impossible or unlikely states or state chains occurred. The most detailed have involved substation processes, and it has worked. The problem is it was very time consuming to develop the model to detect anomalies.
One minor item in the paper particularly worried and bothered me. The researchers used the term Distributed Network Control System (D-NCS). DCS is a very common term if they wanted to focus on plant implementations, or the could have used ICS. Did they not know what terminology is commonly used by the people they hope will use the research?
The NC State press release was reasonable, not sensational, and sensible marketing of their research capabilities. The press are simply feeding the reading public what they want. The oddity is the interest in control system security is stronger outside the control system community than inside the community where the majority still hope the issue just goes away.
Image by chrissam42
Stephen Hilt  PLCScan is a utility that was released by scadastrangelove to help identify PLC devices. It does so by acting as a port scanner to see if two common ports are open and then decides what to do based on the availability of the ports. Documented within The Rack is PLCScan, a set of python scripts that will help gather information from PLC Devices.
First uses of a utility like this, could be fast scans of large subnets to identify PLCs. This could be PLCs of your own networks or PLCs of the internet, after all the blog post from scadastrangelove was titled “PLCScan the Internet”. It is only a matter of time before functionality of this sort gets added to searches like Shodan. A problem is that even this utility can cause issues on a production system if one does not know what kind of sensitivity comes along with these types of scans.
The more we use the control system protocols within to help identify the systems the more accurate information we will be able to get from the devices, also the safer the utilities will be to run. In recent blog post about practicing tools, Ralph Langner said “the device should be considered fragile by default, period”. I agree with this statement, especially for utilities like PLCScan, we should assume that we will bring the device offline if we are using a tool against a production network.
PLCScan could add great abilities to the assessment team. The utility can pull information from a PLC that then can be used as a reference point to validate information. This information could be information that the assessment team would had to manually pull from devices and configurations with screenshots. Information from the output from utilities like PLCScan are a lot easier to parse and utilize the data then reviewing screenshots.
Even with the risk of bringing the device offline the benefits to knowing what type of information that utilities like PLCScan can provide are very important to understand. Based on the testing we have performed with PLCScan, the script is well written and does take some errors into account to be the safest with the device as possible. It should be used against hosts and not subnets to start with as the only way to truly stop the scan may leave some devices in state that might crash the device.
Control system specific utilities like PLCScan will provide good information and a great value to the community if we keep helping projects like this get the most amount of information in the safest way possible. The more information we are able to gather about the systems on line we will be able to have accurate information about what is truly connected to the internet. If we can correctly identify the devices attached, we can remove them from the internet and protect them from malicious uses.
Image from Threatpost
Dale Peterson  I asked Eyal Udassin of C4-Security in Israel to comment on the ICS hack disclosed this week. “The hack isn’t something for the books. It’s of small kibutz named Sa’ar in the northern part of Israel, indeed from a year ago. The operator had a remote access software with no password on it, so not surprisingly it was hacked. He found out that someone moved the screen view the same morning, so he understood immediately that something is fishy and changed the remote access method to a secure one.”
ISA99 released another draft standard for comment this week – ISA-64432-4-1 Product Development Requirements. I’ll write up my thoughts on it in an article next week.
Kim Zetter of Wired covered another vulnerable ICS connected to Internet story this week. It normally wouldn’t warrant mentioning as loyal readers have certainly heard enough of this Shodan / Internet search story. However, it was a Google Building Energy Management System.
Tweet of the Week
1) Hack Google's Building Management System2) Report it to the Google Vulnerability Rewards Program3) …4) Profit?http://t.co/VvLJrjrr9N  Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Nothing this week.
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by ChrisInPlymouth
Stephen Hilt  At S4x13, Scadastrangelove (@scadasl) released a offline brute force password cracking script (http://pastebin.com/0G9Q2k6y). Shortly after the script was released the functionality from that script was added into John The Ripper. Documented in The Rack is how John The Ripper is capable of cracking S7 password hashes using the Scadastrangelove technique of offline password cracking from a packet capture.
John The Ripper has been around for many years, and is one of the most common password cracking utilities out there. With an add-on plugin and a script that is easy to run, the password hashes are extracted out of packet captures, and cracked using John The Ripper.
The use of John The Ripper outside of the normal workstations and servers inside of ICS environments is very limited, as most devices you can’t get the information required to run the software against the password hashes.
With the rise of password complexity requirements inside of ICS environments, auditing the password complexity of PLC and like devices can be difficult and rely a lot of how much you trust the engineer. As an example there is nothing to say that the PLC configuration that you are looking at on the engineer workstation is the one that is truly pushed out to the PLC. With the ability to gather information from a packet capture and then verify the password complexity adds that much assurance to an assessment.
However, this utility can be used for nefarious purposes, take an example where on a support portal for a vendor some one uploads a packet capture to try to get help, now this packet capture is downloaded by an attacker. This utility makes it easier for an attacker to crack the passwords of S7 devices. This gives an upper hand on the ability to write custom malware to alter configurations and the likes. Thats not to be said this couldn’t and wasn’t a capability before, this just took their ability and made it easier for them.
Password cracking is dependent on the hardware in which you are running the password cracking software on. The only testing I was able to perform was on some packet captures that were given to me from Sergey Gordeychik of Positive Technologies, and the passwords were very simple passwords that cracked within a second or two. The more complex the password the more time it takes to crack via brute force techniques, with more and more password breaches happening the word lists are getting bigger which helps the dictionary attacks get that much more powerful. I expect to see more ICS devices fall to this type of attack in the future.
Photo from awaitingdawn
Michael Toecker  There are several seats still available for the upcoming Cyber Security for Power Generation training outside of Chicago. The one-day course is specifically designed for those engineers and IT professionals responsible for securing a power plant DCS and balance of plant cyber systems. The entire course is taught in the context of model power plant.
I’m looking forward to conducting this training, as I’ve spent the past 8 or so years engaged in power generation work. There are nuances and concerns associated with Cyber Security for Power Generation, and I’m looking forward to sharing with attendees. Cost is $495, which is a bargain for an 8 hour professional training.
For more details, please check out the event site.
Dale Peterson Damiano Bolzoni’s of Security Matters presented Detecting 0-Day and Targeted Attacks on ICS with Non-Signature Based IDS. While the quantitative mode of anomaly detection, looking at the quantity of packets, has had some success, qualitative approach has had a lot of research with minimal practical results.
The session explains n-gram analysis and shows the results of four different n-gram approaches on finding anomalies in 30-days of Modbus/TCP traffic on a water ICS and 7-days of SMB traffic on a gas SCADA. This was great to see because using real world data in ICS research is actually still rare.
The results of the n-gram models were better for the Modbus/TCP, but even the best model had 10 false positives a day even with the highly repetitive Modbus traffic.
Damiano then proposes a new method that is an extension of what is done in Tenable’s Passive Security Scanner, INL’s Sofia and other products. Those products will identify “normal” communication on the network by source IP, destination IP and destination TCP/UDP port. The example demonstrated in the presentation includes other ICS protocol parameters.
For example, it will identify what function codes are used and alert on new function codes. It will identify data lengths and alert on new data lengths. Obviously the similar the protocol the easier it is to do this. An application layer protocol like Modbus/TCP is relatively simple. A protocol that includes its own data and transport layer, like DNP3, could cause more false positives unless packet fragmentation is dealt with. A complex protocol like EtherNet/IP would be much more difficult. It is similar to the issues that require a preprocessor in signature based network IDS.
In fact, some of our early Quickdraw IDS signatures detect similar anomalous behavior. However, the signature based approach requires selecting and modifying the signatures manually. Damiano’s approach generates these rules automatically.
Michael Toecker  Fuzzing, as a practice, has been around for a while. Throw garbage at an input to a program and see what falls apart. Analyze the crashes and dumps, and see if any involve commonly exploitable issues, such as buffer overflows, off by one errors, etc.
I’ve seen SCADA protocols brought low by a simple repetition of ‘AAA…’; and I’ve seen much more complex fuzzing efforts (such as those brought up by Terry McCorkle and Billy Rios in some of their advanced training). In normal IT, fuzzing often focuses effort on the ‘server’ or ‘input’ part of the communication, where the user can influence input sent to the server. This is because the user is determined to be the larger threat, and the server is considered the system to defend. There are exceptions to this, one of the notable ones are browser based bugs designed to infect users based on input received from a web server.
But most ICS deployments have the exact opposite use case. Yes, we use client-server type architectures, but the systems that require the most protection are often not the server ones (the PLCs), they are the client systems (the controlling HMIs, etc). For example, take a Modbus communication: The client requests point data directly from a PLC, which then responds back to the client with the point data requested. Simple right? Read More
Dale Peterson  A draft of ISA-62443-3-2 is out for comment now. Previously it was called Zones and Conduits, but the latest draft recommends a title change to Security Risk Assessment and System Design. The recommended new title is more accurate for the content.
Readers looking for some detailed guidance or requirements on performing a security risk assessment or designing a security architecture will be disappointed. This standard is primarily a process document that tells an owner/operator the tasks that must be done in a risk assessment, but doesn’t provide much information on how to do the tasks.
The positive spin on this document is it provides a consistent process and terminology for performing an ICS risk assessment. For example there is a specific list of information that must be documented for each zone and conduit in Section 4.4.3.1.
The negative spin is it has requirements, “shalls”, without helping an owner/operator determine how to do this. A few examples:
- 4.5.1.1 “A list of the threats that could affect the assets contained within the zone or conduit shall be developed.”
- 4.5.2.1 “The zone or conduit shall be analyzed in order to identify and document the known vulnerabilities in the zone or conduit access points and in the assets contained within the zone or conduit.”
- And then the list of earlier required shalls are combined in a calculation such as 4.6.1.1 “The residual risk calculated for each threat 4.5.5 shall be compared to the organization’s tolerable risk (specified in 4.3). Additional security countermeasures must be applied if the residual risk exceeds the tolerable risk.”
This document is high level Risk Management 101. It’s actually a very short document and quick read with about 5 pages after you strip out the formatting and definition sections and an example annex.
It may be unfair to look at this document in isolation. ISA99 has a large set of standards and technical reports in process that interlock to hopefully form a complete picture. In addition, future annexes (appendices) are hinted at that could provide guidance on how to achieve these mandatory requirements. This is started with a partially completed annex on a chemical truck loading example, and another annex to be written with “several possible methodologies that can be used to assess the frequency of the threat hazard”.
There is guidance on security zones as the standard recommends (shoulds) that control, safety, corporate, wireless, and mobile devices all be in their own zones. All guidance is very broad such as “The organization’s tolerable risk for the SuC should be included in the security requirements specification.”
It’s a draft so there is still work to be done. Consider even the limited examples in this article. Specifying the organization’s tolerable risk is optional, but it is then required in Section 4.6.1.1. ISA99 has a comment form and is very welcoming of any suggested improvements.
In summary, ISA-62443-3-2 isn’t going to be of much assistance to an owner/operator doing a risk assessment or a security design unless there is substantial work on the annex. It likely will be a key component of the overall ISA99 standards framework.
Image by SludgeGulper
|
Subscribe:  
Schneider Has Not Removed Modicon FTP Backdoor Account In
2349 days
|
