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.
The ICS Security Research Newsletter has been dormant for a while now, but Reid Wightman and the team at Digital Bond Labs has resurrected it. They are committed to at least a quarterly issue in 2015.
The first issue for 2015 includes:
Information on the IBAL extensions for IDA Pro
Equipment Disposal Failures
Latest Project Redpoint ICS Enumeration Scripts
Auto Hacking x 2
Additional items we found interesting, novel or important.
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.
The ARC Advisory Group invited me to participate in one of the security panels at the annual ARC Forum this week in Orlando. It’s an event I always wanted to check out so I spoke and attended. Here are some brief thoughts from the event.
The best part of the event is the large number of ICS owner/operators that attend. This includes many higher level attendees, people that can drive strategy and decisions.
Some of the asset owner attendees presented great case studies. Nothing related to security, but as an example Pitney Bowes talked about their Big Data efforts, setbacks and successes in the last ten months.
The only useful case study on security I attended was from Tyler Williams of Shell. They have been working on security for years and have a program now focused on 11 controls they can measure.
In a continuing regrettable string of events, Gregory Touhill from DHS missed or passed on another opportunity to tell this audience their ICS are insecure and need to be upgraded or replaced. Instead he just gave pablum, cyber watch, here are DHS programs, … He’s a good speaker and could have delivered an important and powerful message, but it appears DHS is happy with the status quo as long as we share information better.
The vendor exhibits were quite interesting to me as I hadn’t seen some of the newer versions or offerings, such as Bedrock Automation new controller, the progress made in the GUI and capabilities in Industrial Defenders ASM, the NextNine solution that is powering the Yokogawa/Cisco/Shell support, and PAS application for change control + security.
What ARC calls the Industrial Internet of Things (IIoT) was part of almost every session. They are calling existing ICS and ICS functions as IIoT. It’s almost impossible to talk about security of IIoT in a productive manner when everything is IIoT, “everything will communicate with everything” is the main description, and there is no taxonomy or organized set of use cases to discuss specific security needs. I saw very little value in the discussions of securing the IIoT at the event, including my contribution in the panel.
The pronouncements on what the IIoT would and should allow or look like were frightening, especially during an ARC keynote on Tuesday. There was about 5 minutes when my jaw was on the floor.
I need at least five long blogs to discuss the IoT issues and what ARC calls the IIoT. I’ll develop those over the next few weeks.
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.”
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”.
I thought I would write a quick post to share some interesting web logs. I set up a very temporary server to make the CANBus Hacking class materials available for attendees.
The server was available for about a week and not connected to anything or linked from anywhere other than on email servers.
[Wed, 21 Jan 2015 10:58:57 GMT] "GET /muieblackcat" "undefined"
[Wed, 21 Jan 2015 14:21:11 GMT] “POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E” “Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25″
[Sun, 25 Jan 2015 23:37:46 GMT] “GET /tmUnblock.cgi” “undefined”
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.
