Black Hat Sessions and (Dutch) Infrastructure

netherlandswindmill_ archetypefotografieThe Sessions

Digital Bond Labs appeared at Black Hat Sessions in Ede, Netherlands.  We gave a talk on vulnerability inheritance in PLCs, and also discussed some of the challenges associated with removing vulnerable internet-connected control systems from their wide attack surface.

The conference was a well-run one-day event put on by Madison Gurkha.  Ede is a fairly small town, but thanks to being in the Netherlands is easily reached by train (or bicycle).  BHS has been increasing in size steadily over the years, and this year’s attendance was just shy of 400 total conference-goers.  While the keynote talk was in Dutch and thus incomprehensible to me, there were three good technical talks in English, including a talk by ERPScan.  S4 alumni may remember ERPScan as the employer of Alexander Bolshev when he gave his excellent HART security research talk in 2014.

Read More

canbus-utils release v0.2.0

Greetings. Quick post to announce an updated release for the Digital Bond Labs CANBus utilities repository.

This release features the addition of a simple fuzzer to the toolkit. The fuzzer has two modes. The first mode (default with no options) is to send random data to random IDs on the CAN. The –min and –max arguments specify a range of potential IDs to send random data.

The second, and more interesting, mode of the fuzzer is a mutation-based approach working off of a base message buffer. Say you observe a message on ID 0x431 consisting of the data (here shown in hexadecimal string) of “00 02 00 00 82 13 00 01″. If you would like to fuzz the 4-5 bytes (0x8213) you would issue a command like: “node fuzz.js –min 0x431 –max 0x431 –basebuffer “0002000082130001” –mutateIndexMin 4 –mutateIndexMax 5″

Happy hacking.

S4x16 Call For Presentations

s4 final on black

We have opened the S4x16 Call For Presentations on the event website. Since 2007 S4 has been the place to show your ICS Security research to an advanced audience that will get it. In recent years we have added Operations Technology (OT) and ICS Cyber Weapons sessions to the event. But again these sessions are aimed at an audience that knows the basics and doesn’t want to hear SCADASEC 101.

The new venue in South Beach will allow us to produce sessions on two big stages, so we will be hunting harder than ever for quality, fresh and entertaining content.

Here is the short version of the CFP:

  • Email your proposed idea for a S4x16 session to
  • Explain the session in 2 to 3 paragraphs highlighting what is new or novel about the session
  • Identify if it is a Technical Deep Dive Session or Main Stage Session
  • Identify the time requested for the session (15, 30, 45 or 60 minutes)

Also email us any ideas you may have for speakers or topics we should chase for S4x16. We evaluate submissions as they come in, so sending your session idea in early increases the odds it will be accepted. The CFP closes on September 1st.

Book Review: There Will Be Cyberwar

Screen Shot 2015-07-01 at 9.17.37 AMThere Will Be Cyberwar: How The Move To Network-Centric War Fighting Has Set The Stage For Cyberwar by Richard Stiennon

Read this book if you are looking for a summary of the attacks and cyber incidents that have occurred over the past 20 years in government, military, critical infrastructure and business. It also provides numerous concise examples of security controls that are needed to combat the attacks described in the book.

Don’t read this book if your focus is ICS. There is a bit of information on ICS incident, but not enough to justify reading for that purpose and you will find minor problems with the ICS text. Don’t read this book if you are looking primarily for a discussion and analysis of the future of “cyberwar”.

With the exception of the fictional scenario in Chapter 1 most of the book is focused on synopsis of past incidents. It does however convincingly make the case that weapons systems, communication systems and many other elements required to effectively fight a war are now connected to networks, more reliant on software and therefore subject to a cyber attack.

Given the title, There Will Be Cyberwar, and in light of Thomas Rid’s Cyberwar Will Not Take Place it is almost mandatory to see if Richard made his case and why the two authors come to diametrically opposed conclusions.

The answer is actually simple. The two authors have very different definitions for cyberwar. Thomas spent a lot of time defining war and then cyberwar in his book, and he made a convincing case why this definition of cyberwar will not be met. Read the book and listen to my podcast with Thomas to understand this point of view.

Richard has a much less stringent definition of what constitutes cyberwar.

Cyberwar is the use of computer and network attacks to further the goals of a war-fighting apparatus.

Richard has made the case clearly in his book that based on this definition cyberwar will happen and incidents have probably already occurred that would meet this definition.

I’ve heard no dispute that cyber weapons will be used in wartime, just a dispute over the term cyberwar.

A more interesting question is will we see a use of cyber weapons in war that is akin to the Battle of Britain / air warfare? I first heard this question from Jason Healey of the Atlantic Council in a panel discussion. The Battle of Britain proved that air power alone could be used to win a major battle. Will we see a major battle fought entirely in the cyber domain?

Richard also describes what would constitute a Cyber Pearl Harbor in the book.

It is not the destruction of the power grid, or the loss of communications from attacks against the Internet and telecom infrastructure, or even the collapse of the stock market that deservers Panetta’s dire warning. Only a crippling military defeat thanks to overwhelming control of the cyber domain deserves to be labeled a Cyber Pearl Harbor.

I believe the last sentence is a better definition of cyberwar, and perhaps a slightly modified version of the earlier definition is better for cyber weapons. In the end most of the disagreement is definitions, and this is less interesting or important than how cyber weapons will be created, deployed and used as well as defended against.

Note: I read the Kindle version on an iPad Mini 3 Kindle app. The formatting is wrong, but not so wrong to make the book unreadable on that device and still worth the convenience and savings over the print version for me.

S4x15 Video: Attribution and Retribution Panel

S4x15 came on the heals of the attack on Sony. Everyone was discussing how cyber attack attribution can be done and the level of certainty that is possible, so we had a panel to discuss this very issue.

The second part of the panel discussed what does the victim due after they have attributed an attack to a nation or organization —retribution.

The panel included Bill Hagestad of Red Dragon Rising, Jonathan Pollet of Red Tiger, and Tim Yardley of University of Illinois.

Switches Get Stitches (or: Switches Get DNA Helicased)


There is a ‘talk franchise’ that has started titled ‘Switches Get Stitches.’  Started by Eireann Leverett and Colin Cassidy, it showcases problems in industrial network switch hardware and firmware.  Digital Bond Labs offers a humble contribution to the cause: a demonstration of a firmware rootkit for an (admittedly somewhat dated) industrial switch.  If you are attending Defcon 23, be sure to check out the ‘official’ SGS talk there.

One of the components in this year’s ICS Village CTF is going to be pretty unique: we have modified a network switch firmware.  This ends up giving a lot of interesting leeway: we can now mangle packets, talk to a command and control server, and make a few other interesting flags for participants to find.

Most ICS equipment lacks any kind of firmware protection.  Scarier is the fact that some operators, including a very small subset of utility operators, purchase safety-critical equipment from dubious sources such as eBay.

So, let’s take apart a network switch and show just how easy it is to trojan a device!

Read More

ESCAR USA Thoughts and the ROI of Investing in Cybersecurity

ESCAR was an interesting event. There were about 150 in attendance from various parts of the auto cybersecurity community including OEMs, tier 1 vendors, and defense products. There were speakers on a variety of good topics, the full lineup is available at Being an “outsider” to the auto security community I really enjoyed the opportunity to meet people and have some interesting discussions.

The opening keynote by Alex Halderman of U of Michigan was highly interesting regarding the all-too-common re-use of keys or predictable keys that are prevalent in embedded systems due to a common starting point. Relevant information that will hopefully sink in and be of use in the future as more devices are incorporating encryption, but as of now those devices are rare (in both the auto industry and ICS).

“Methods for Penetration Testing of Automotive Embedded Systems” presented by Argus was a good primer in security analysis for these types of systems. A few talks discussed handling the increasing connectivity in vehicles moving forward and how to best separate the concerns of interactive vehicle features affecting safety and operational control systems. I feel like this is the most important area to be considered at the moment for the industry.

password-704252_640Vendors at the conference seem to be focusing on IDS/IPS for vehicle systems. The idea being that installing extra equipment to monitor the CANBus to identify messages that occur when they should not and to prevent those messages from reaching the ECU. This requires keeping a knowledgeable running state of the vehicle to determine if the “steering wheel left park assist” action is correct at a given time. Some vendors seem to do this via software on existing vehicles and others via entirely separate sensor systems to be installed aftermarket. I think this is a *VERY* difficult problem to solve (having worked in the situational awareness space previously) and is a common issue that people attempt to band-aid over in cybersecurity.

Read More

Shodan for Rocket Scientists

shodan_pasukaru76Shodan is a really useful tool for, well, all sorts of research.  Not only can you quickly determine what the public-facing security impact of a new vulnerability is going to be, you can find all sorts of control systems attached to the Internet that shouldn’t be. Searching for random control-systems related terms sometimes even steers a researchers towards new and interesting equipment to test.

John Matherly, who runs Shodan, is constantly tweaking settings and adding features (and new scan types) to help the security community. [On a personal level I can’t thank him enough for teaching me all of the tricks that I’m writing about here].

Two of the recent changes made ended up being really helpful for finding some of the most vulnerable ICS systems: telnet options searching and bannerless telnet searching.  The latter of these is only available to folks who pay for API access, but it opens up some rather interesting critical infrastructure to locatability.

Way back in 2012 we did Project Basecamp.  The ‘Biggest Loser’ of Project Basecamp, purely on the number of red ‘X’ security failures, was General Electric’s D20ME RTU.  (I should mention that GE has made strides in improving the line with the release of their D20MX, but the D20ME line will remain forever vulnerable).  Back then, I really wanted to be able to search for the D20 on Shodan but couldn’t.  This was because the D20 only supports Telnet, and it supports it in a way that Shodan didn’t support.  Until now.

Read More

Unsolicited Response Podcast: Eric Byres after Tofino

After a long and successful struggle to bring an industrial firewall to market, Eric Byres is leaving Belden and Tofino behind. We shouldn’t call it retirement because I expect that Eric will be contributing in a number of different ways in the next ten years.

I gave Eric a few months to clear his head and then talked with him for this episode of the Unsolicited Response Podcast.

The first 16 minutes of the episode are a retrospective of Tofino. What features were surprisingly effective, what were the biggest challenges and dark times, when will we see Tofino on a chip and more.

After that we talk about bigger questions on the ICSsec community, Eric’s home automation and what he may do next.

ESCAR Presentation

I enjoyed last week in Detroit at ESCAR (Embedded Security in Cars). I went there to present on the topic of vehicle security and how remote access and third party devices impact the threat landscape. Many researchers have published about the security concerns of vehicle systems, namely the CANBus and it’s simple nature that lacks security controls entirely. It has been shown that if an attacker is able to send messages on the CAN, they are able to control the vehicle.

I performed a security assessment of a third party OBDII dongle. This dongle sits in the diagnostics port of the vehicle (which is on the CAN), collects information, and sends that information through the cellular networks to the third-party servers. I found that this device follows the pattern we see in embedded systems which is to say that it was designed and created without any security in mind whatsoever. Cleartext communication channels, no hardware separation of concerns, hardcoded database credentials…the list goes on.

What this means for auto manufacturers is that it cannot be assumed that the vehicle CAN will be isolated. An attacker may not need physical access to a vehicle to execute an attack. Attacks are no longer limited to a single vehicle and may affect entire fleets managed by these types of systems. Defending against these attack vectors requires a separation that prevents a compromised dongle from affecting the vehicle in any way whatsoever. I created a proof-of-concept “CAN Protector.” This device acts as a gateway that propagates information out of the vehicle network (one-way/read-only) for consumption by third party devices.

You can find the slides here:

Website for the conference is: