Kaspersky announced their project to develop a Control System OS back in October 2012. We tried to get them to present some details on the design criteria and goals at S4x13 and S4x14 without success. So we were very happy to have Andrey Nikishin give a session on the Kaspersky.
In this video you will see:
– the OS is for “embedded connected devices” (examples given: Smart Grid, PLC, Medical Devices, Network Appliances, Automobiles)
– the OS is not a clone of any *nix
– a broad view of the architecture including separating the microkernal from the security server. The security server determines the “security verdict” for all communication.
– the concept of a “verdict cache”
There still are many unanswered questions, and Andrey forestalled these questions by asking the questions he would not answer at the end of the session.
Podcast: Play in new window
| Download (Duration: 1:05:55 — 60.3MB)
We had Kim Zetter on stage for an interview at ICSage during S4x15 Week to discuss her new book: Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon. This first 2015 episode of the Unsolicited Response Podcast features that interview.
The podcast includes:
- Who was the target audience for the book
- Why Siemens didn’t play a bigger role in the book
- The hard to believe Sean McGurk chapter
- Did the US want Stuxnet to be discovered
- How her book differed from David Sanger’s book
- How Stuxnet infected Natanz
- Details on Stuxnet version 0.5 that only spread through Siemens project files
The Unsolicited Response Podcast has been inactive for a while now, which is a shame because I enjoy doing it and get a lot of positive feedback. Much of the difficulty in recording the podcast has been solved now that I have a very mobile podcast rig that I can bring with while traveling.
I’m committed to a minimum of 20 podcasts in 2015, and there are a few compelling guests already lined up. We will wait until five episodes are recorded before bringing on podcast sponsors, but let us know if you are interested in sponsoring Unsolicited Response.
Subscribe to the Unsolicited Response Podcast in iTunes.
Digital Bond Labs has been using the IDA Pro API to extend it and make it even more useful for gray / black box testing. At S4x15 Reid Wightman, who heads up the Labs, introduced the first IDA Binary Analysis Library (IBAL) that are released for public consumption on our GitHub.
The goal of IBAL is to improve the state of firmware analysis.
Fuzzing will find a lot of protocol parsing vulnerabilities, but it can also miss a lot of protocol parsing vulnerabilities.
The early IBAL modules start with entry point analysis and then builds up a list of accessible instructions from that entry point. Then a researcher looks for coding mistakes in that accessible code.
Watch the video for a much better technical description of IBAL and how to use it.
Alexander Bolshev of Digital Security in Russia gave a great talk at S4x14 on exploiting vulnerabilities in the HART protocol and devices. His latest research is testing a large number of field devices accessible via the FDT Group’s Device Type Manager (DTM) protocol. According to the FDT Group, “DTM provides a unified structure for accessing device parameters, configuring and operating the devices, and diagnosing problems.”
There are over 2000 certified devices on the FDT Group site, and they consist of flow meters, level sensors, pressure sensors, temperatures sensors, positioners, etc.
As you might expect, Alexander found a number of vulnerabilities, and they are beginning to show up on ICS-CERT as vendors fix these problems. However, the more interesting aspect of the research is how his team efficiently tested a large number of DTM’s. Specifically 114 HART DTMs from 24 vendors that were used in 752 products. This represented a 10% sample of the HART DTMs. And the team had to do this in one month.
Watch the video to see the challenges and how they overcame them. The one that seemed quite nasty was “DeviceDTM will send the next command only when it gets the correct answer to the previous command”.
Today we posted the video of Corey Thuen’s S4x15 Technical Session on the insecure by design Progressive Snapshot dongle. Progressive responded with a statement to a Forbes reporter:
if an individual has credible evidence of a potential vulnerability related to our device, we would prefer that the person would first disclose that potential vulnerability to us so that we could evaluate it and, if necessary, correct it before the vulnerability could be exploited.
What Corey pointed out, in a manner similar to Project Basecamp did with PLC’s, is that these systems are insecure by design. The vendor, Xirgo Technologies, surely knows they didn’t include even basic security controls in their design. This is not news to them. If it was news to Progressive, then they did not perform a rudimentary security analysis before making this available to potential customers.
The best analogy I have come up with so far is storing cash, jewelry and other valuables in a vacant house. The house has no doors, no windows, no alarms, no neighbors watching, no security at all. All that is required is a thief to say I want those valuables, walk in and take them. Is it really necessary to tell the owner of those valuables that a thief can walk into that house because it lacks security? Surely he knows and accepted this.
Corey also briefly points out that a look at the code indicates that basic secure coding practices were not used in the development. It is likely rife with vulnerabilities. Even if the doors and windows with locks are put on the house, the walls are paper, 襖, relying on attackers to respect the illusion of a solid wall.
In the Forbes article Progressive also said, “The safety of our customers is paramount to us.” I’m sure this is true, and they likely have a robust security program around their e-commerce and customer web site projects. Progressive, and other vendors offering these dongles, need to be progressive and extend their security programs to these products that provide remote access to the OBD-II port on your vehicle.
This is a bigger problem than OBD-II dongles. Reid’s session from last October at S4xJapan showed Hitachi and Sanyo Denki using the CoDeSys runtime library without evaluating the security vulnerabilities and deficiencies of that code. Vendor’s buying devices, components and software need to assess the security of the product before they sell or provide it to customers.
Ironically, this was not a very good project for Digital Bond Labs. They work with vendors to find vulnerabilities so they can be fixed before product release, an external red team so to speak. The Snapshot dongle did not require finding and exploiting vulnerabilities. Security needs to be integrated into the design and then it is worthy of an internal or external red team to give it a hard shake to see if their are any latent vulnerabilities.
S4 in January is a great way to start off a new year. This year I had a session entitled “Remote Control Automobiles” where I analyzed an OBD-II dongle from Progressive that is designed to track vehicle usage for insurance purposes. It’s a cellular enabled embedded device that connects directly to a vehicle’s CANBus (the vehicle control network). The video from the talk is below.
I want to acknowledge and point you to the work of Ron Ofir and and Ofer Kapora of Argus Cyber Security who are also doing research in the automotive dongle / remote space. Their results are similar. There is a lot of FUD surrounding this topic so I’ll say this: The disparate systems, communications, and vehicle software makes attacks specialized and non-trivial. It is unlikely that we will see attacks like the extreme ones often used as examples, but the concern is real because the possibility is there. These dongles are cellular enabled and directly connected to your CANBus via OBD-II; an attacker who controls the dongle can control your car.
The main point of the talk was in line with the theme of the conference: what can an attacker do to a process when in control? What now? What are the ramifications of the Internet of Things, of adding network connectivity to a bunch of Insecure by Design systems?
“A system is *good* if it does what it’s supposed to do and it’s *secure* if it doesn’t do anything else.”
– Dr. Eugene Spafford, Purdue
Vendors are solving problems and making *good* systems that aim to improve the quality of life. Vendors are not always putting in the effort to make *secure* systems. Let’s stop using microkernels that were made without anyone uttering the acronyms SDL or TDD. Let’s incorporate technologies like cryptographic authentication. Let’s see some well designed AND secure systems. The engineers of these systems have accomplished a difficult task in making systems do what they are supposed to do. We just have to, at the same time, also be creating systems that don’t do anything else.
LtCol William Hagestad Jr. of Red Dragon Rising brought his expertise on China and Iran to ICSage. The session includes briefings on Iranian and Chinese offensive cyber security efforts with some interesting Q&A on both.
Bryan Singer and Lily Glick start off the S4 Technical Sessions with a great presentation they named The Pragmatic Pwn of ICS. They focus on the engineering aspects of a cyber attack and the defense of a process using a distillation column (making 80 proof vodka) as an example.
They describe a Process Hazards Analysis (PHA) and introduce the concept of a Cyber Security Process Hazards Analysis (CS-PHA). “A PHA establishes criticality, but likelihood only from entropic failure”. A CS-PHA would include directed threats as well.
Some rarely heard but important points made in this presentation include:
- Properly designed systems will have mechanical devices/processes that will prevent certain hazards (explosion in the column due to too much steam), even if a cyber attacker has complete control.
- Manual process can be hacked if you know the system well. Trigger alarms that cause the operators or technicians to take the manual action you want taken.
- Manual verification of true status before potentially dangerous control actions are taken can be an effective defense.
- Operator rounds can be a detection security control.
There are a lot of gems in this session worth watching for those who generally focus on ICS hacking.
Here is my short, 13-minute introduction to S4x15. After going into a brief review of S4x12, x13 and x14, it covers the theme of S4x15 and where ICS security research is heading.
Assume an attacker has gained a presence on the ICS, such as gaining control of a computer or finding a way to connect to the ICS network.
- What could and would an attacker do?
- What can a defender do?
This moves the discussion from a “hacking” focus to engineering and automation. The “hacking” continues to be the easiest part of an ICS attack. What an adversary does after gaining control of a cyber asset is a much more difficult project than the common “I can take down …” bravado that is often read.
Engineering and automation also offers great opportunities on the defensive side, particularly on reducing the consequences of a cyber attack.
Admittedly this moves the ICSsec research community further out front of the ICS community, and there is a concern that we may be outrunning our supply lines. However, if we keep doing “research” on known and solved issues we will lose the best researchers and not be ready when the ICS community comes to the realization this is a problem that can be and needs to be solved.
One final thought that I’ll write more about later. While the ICS security researchers and thought leaders need to press forward, there is a huge and growing need for the typical ICS security conferences and training programs that the S4 attendee has little interest in. The ICSsec 101 needs to be taught to large numbers of people, and scaling these learning activities up is likely to be a major problem.