Attacking CAN Protocols

The CAN protocol suite is used in both the automotive and wider automation sectors to control a variety of processes, from vehicle safety systems to large circuit breakers. Digital Bond Labs has been developing software to help analyze implementations of the protocol, which often use proprietary payload formatting to store data.

CAN, like most industrial protocols, lacks data integrity. The single-loop design of a CAN bus means that an attacker with access to the bus is able to record and inject traffic. He can cause a variety of problems for the system that the CAN loop is used for control. In vehicle usage, examples have been demonstrated by Chris Valasek and Charlie Miller. Notably, the protocol lacks any data integrity, making it impossible to differentiate real sensor message data from data that is being spoofed by a rogue device.

The Labs’ Corey Thuen has been documenting his research in CAN protocol exploration. In a two-part blog series, he shows the basics of the CAN physical layer and data payload as well as how to identify CAN messages from a particular piece of hardware in a running vehicle. This message identification is a first step in further comprising a vehicle’s security. Once an attacker understands what sensor data a particular CAN ID represents, he can spoof messages and cause incorrect or faulty operation in the vehicle.

If you are interested in auto security make sure to check out Corey's CANBus Protector, CANBus protection used to isolate third party systems requiring OBDII access, and CANBus Utilities, command line utilities to help CANBus hacking. Both are available on Digital Bond's GitHub site.

Finally, check out Corey's presentation below at the Embedded Security in Cars (escar) USA event that took place in May in Detroit.

Digital Bond Labs Teams with State of Virginia

Digital Bond Labs has joined a research consortium including the University of Virginia, MITRE, and the Virginia State Police to look at the security of automobiles and vehicle fleets.

“High-tech systems now used in most automobiles are opening up potential new avenues for cyber attacks. Thanks to the continuing efforts of the Virginia Cyber Security Commission and Virginia Cyber Security Partnership, we have the opportunity to lead the nation in the establishment of safeguards protecting the vehicles of Virginia’s 5.8 million licensed drivers.” - Governor McAuliffe

The Labs will provide threat modeling, red teaming, and technical support to the project, which aims at identifying security weaknesses and solutions to police vehicles and fleet management systems. Bringing expertise and an ever-expanding toolkit, Labs researchers can offer unique skills and perspective to the project to better understand vehicle security and cybersecurity risk. The official press release is available at https://governor.virginia.gov/newsroom/newsarticle?articleId=8430.

Digital Bond Labs is all about finding new vulns so they can be fixed prior to compromise. Looking for programming and hardware flaws, and introducing clients to secure programming and design concepts isn’t just our day job, it’s also what makes us tick as human beings.

We have spent quite a bit of non-billable research time recently hunting for new and novel bugs in frequently-used ICS software. While we don’t consider ourselves full-fledged members of the ‘no more free bugs’ movement, it is safe to say that bug-hunting is a time-consuming task. When done for research purposes, it is essentially providing free quality assurance (QA) for large ICS vendors -- vendors who should be performing such QA work and often aren’t (or at least not doing so very effectively).

Try to imagine a world where our bridges are built, sometimes shoddily, and the civil engineers who build them expect citizen testers to volunteer to use the bridge and point out its structural problems (all for free). It is not a comforting security model. Yet, many of the vendors who produce and sell the software which run our critical infrastructure are not testing in the right way to find their software defects. Design and implementation flaws abound.

Enter bug bounty programs. Many companies in the commercial software space offer direct cash awards to researchers who uncover critical software defects. Not so in ICS of course -- the first and to our knowledge only bug bounty program in the ICS space (Integraxor) still only offers licenses as rewards. Integraxor only issues these rewards to folks who already purchased a valid license to their software. This is the opposite of the bug bounty -- Integraxor is essentially requiring researchers to pay money for the privilege of performing free labor.

In the ICS space, there is only one option to get paid for the research: third-party resellers. For example, the Zero Day Initiative, owned by Hewlett-Packard, has been uncovering a lot of ICS software vulnerabilities. So far in 2015, ZDI has helped uncover 10 vulnerabilities in ICS software. These bugs primarily affect Schneider Electric software.

In 2014, quite a lot more bugs were found. 2 in Honeywell software, 2 in Rockwell Automation, 24 in Advantech, 2 each in GE and WellinTech, and 10 in miscellaneous software that is commonly seen on ICS networks. That corresponds to roughly 10% of all ZDI reports for 2014. The output of these vulnerabilities are IDS signatures for HP’s customers. So, we have a secondary market generated by software defects.  A pessimistic view of the existence of this secondary market is that ‘reliability costs extra’ from many ICS vendors.

Of course running a bug bounty only makes sense if the vendor is otherwise running their software through a Security Development Lifecycle (SDL). In particular, if a vendor has known insecure-by-design issues in their software and protocols, then it makes little sense to hunt for bugs in this way.

Perhaps it speaks to the troubled ICS security world that there are no bug bounties. To us, the first companies that step up to this plate will be signalling their confidence in their own product.

Prep work has already begun for the ICS Village at S4x16 Week, January 12-15 in Miami South Beach. The Village was a great success in 2015 and many participants enjoyed playing the Capture the Flag (CTF) competition, see the ICS Village web page and video with the winners. We are taking the lessons learned and valuable feedback from participants and working them into next years ICS Village.

Of course the challenge is it needs to be much bigger and much better every year, and Stephen and the team set the bar high at S4x15. So we are looking for some volunteers to help create flags, set up the ICS Village and help keep it up and running during the event. We are also looking for ICS software and hardware to add to the Village.

As a small reward for your help we are giving three ICS Village volunteers a free pass to all of the S4x16 activities. Send an email to s4@digitalbond.com if you are interested in helping in any way.

External Research and News

Cybati has been hard at work building their CybatiWorks education platform. The platform’s first public release includes a virtual machine running a variety of systems, architected as a typical IT/OT network.

At the heart of CybatiWorks is CORE (the Navy Research Lab’s Common Open Research Emulator), which presents an easy way to draft up a network architecture of lightweight virtual machines (essentially sandboxed systems running the host operating system). Of course, with some fancy scripting CORE can swap out these lightweight virtual machines for ‘heavy’ machines (virtual or physical) running real ICS software.

Researchers and ops folks alike can take the virtual network and learn how protocols work, determine the best network architecture, and apply networking rules to separate systems. They can also set up virtual mirror ports, attach intrusion detection systems, and deploy other compensating controls. The effectiveness of the security controls can be tested by launching real attacks.

One of the nice things about launching attacks is that the default lightweight virtual machines are sandboxed clones of the host operating, which is based on Kali. This means that Kali’s default toolset comes for free -- so you can run the usual suspect exploits against specific target machines. The attacks will follow virtual routes through the network.

Setup and teardown of systems is a snap. The platform aims to teach a long list of skills in attacking control systems, including using existing exploits and developing your own custom tools to attack (and detect attacks against) insecure protocols. The sample control system can be expanded using a Raspberry Pi with PiFace board to give it physical IO for a much lower cost than using a PLC.

CybatiWorks promises to be a way to inexpensively introduce OT and ICS security to the masses.

A beta of the VM platform is available on the CybatiWorks-1 Google Group, as well as an image for use on Raspberry Pi devices for integration into the network.

Matthew Luallen will be holding a CybatiWorks overview telecon and webcast on June 11th, which includes some HOWTOs on setting up a network, attaching a Raspberry Pi, and other tricks. Register at the webcast url: https://attendee.gototraining.com/r/8568936485435068417

Billy Rios performed an assessment of Hospira’s LifeCare drug infusion pumps and found their security to be among the worst in the business; which is to say, typical of any industrial field device.

The pump, which features an Ethernet interface, contained backdoors that could allow drug dosages to be modified by an attacker. Performing forensics on such an attack would be difficult due to the system’s design.

While ICS-CERT has an advisory, it is notable that the Food and Drug Administration released a safety alert of their own. This marks the first time that the FDA has issued a security advisory targeting a specific product.

The FDA currently has published guidance for security in networked medical devices.  While it provides a reasonable set of recommendations, they are just that -- recommendations. It is interesting that the medical field has no requirements in this area.

To hear more about this listen to Dale Peterson's interview with Billy Rios on the Unsolicited Response Podcast.

Threatpost reported that L3 and Cisco are working together to block SSH bruteforce attacks from a series of compromised networks. This SSH Botnet is responsible one third of all SSH brutefroce attacks on the internet, according to Threatpost.

When ICS-CERT announced massive SSH attacks against critical infrastructure control systems in 2012, we were curious: were these really targeted attacks, or were they simply detections of the background noise that is the modern Internet? Our conclusion was to be a bit critical of the assumption that the attacks were truly ‘targeting’ ICS.

We posted an initial analysis of one our personal internet-facing servers at the time of the ICS-CERT alert. Indeed when we look at our logs, we see a sizable (roughly 15%) reduction in SSH attacks since the L3/Cisco maneuver. Attack rates are consistently moving upwards again, as the attackers change ISPs and change tactics.

We recommend using tactics such as fail2ban to protect yourself from distributed intrusion attempt attacks. As we noted in 2012, even distributed attacks tend to come primarily from a few compromised hosts. Blocking those hosts is an easy way to protect your remote access and prevent a curious attacker from discovering what is connected to the interior of your network.