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.
While at S4, Digital Bond Labs had a security advisory published by ICS-CERT (see ICSA-15-013-03). One thing that we tried to do differently with releasing information on the issue this time around was to reach out to vendors that were obviously using the affected software as part of their control system.
The results were pretty strange. Most companies contacted had no security@ email address, and no /security URI on their website.
Of the 32 affected vendors that we reached out to, only 3 had a ‘security@‘ email address that did not bounce (the remaining 29 we contacted using a general ‘support’ email address listed on the vendor website). Two months later, zero of the affected vendors have provided a response beyond an automated ticket.
When I worked for a vendor, I had an internal pep-talk informally called ‘dealing with researchers.’ There are a lot of cheap and easy lessons to learn, based on how the bug comes to you:
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.
Stephen had an article yesterday on the ICS Village / Capture The Flag (CTF) competition at S4x15. We also will be putting up a page with more info on the flags, techniques and pcaps in the next week. In the meantime, check out the interview with the winning team.
The Classic S4 Cocktail Party on Wednesday had an area where you could try piloting a drone. There was a larger drone overhead recording the party on the Kovens deck.
Finally, the SCADA Diva mantle has been passed from S4x14 winner Ronnie Fabela to the new SCADA Diva … Chris Sistrunk. He was awarded the ceremonial pink hard hat and all of the other perks that come with the office. Bonus points are awarded for on-site pictures with the hard hat. Of course based on long standing tradition, Chris will select the next SCADA Diva at S4x16.
This year at S4x15, Digital Bond set out to create an ICS Capture The Flag, or CTF. Flags were created to simulate real world situations that an attacker would encounter if he targeted an ICS. By the end of the CTF, there were over 30 teams playing. Most of the teams consisted of a single player, however the top scoring teams had multiple team members.
An example of an easy (100 point) and more general forensics flag was to identify the potentially infected machine on the Corporate Zone. To do this you needed to visit the GigaView TAP Aggregation Switch that Digital Bond had placed within the ICS Village. (A big thanks to Liam Randall at Critical Stack for providing this for our use in the ICS Village.) Once you collected some traffic, you needed to find a host that was trying to perform a DNS lookup of a known malicious site.
Two more flags were related to this infection inside of the Forensics section of the CTF scoreboard. Below is the traffic you would be looking for and once you found this traffic, the host name was the flag
Another flag that had good feedback from contestants required reading values from a PLC on the network. There were two flags hidden in the Holding Registers of a Modicon PLC. The first one was found in Holding Registers 23 to 33. These values were stored in these registers were decimal representation of ASCII Characters. Depending on the tool you were using this could take some work on converting the numbers found in the registers to ASCII; however, some Modbus Scanners would convert this right out of the box which made it easier for some.
In the same Modicon PLC, there was a flag that consisted of a series of Boolean registers that one needed to convert the binary 1’s and 0’s into ASCII. This flag was rewarded with a higher point value than the other Modbus read flag, as it took more time to concatenate the information back together and convert it to ASCII. Below shows a screenshot of the Holding Registers that were configured with the some of the Boolean values that made up the flag.
A BACnet Flag was hidden inside of an actual BACnet device and could be found on the Internet. There were many different techniques teams used to capture this flag. Some teams downloaded and tried multiple tools, while other teams attempted to modify Digital Bond’s Redpoint script to collect more information to find the Flag. In this case, the Flag was found within the Object Name of an Analog Input inside of the BACnet controller. The Flag is shown below; to find this Flag you would have to read the descriptions of the analog points to know that this Object name was the proper string for the flag.
One Flag (1000 points) proved to be quite difficult, and only one team was able to capture it. This flag was the only 1000 point flag that was found without bending the rules (looking at you team Foobar), and was in the Forensics category. This flag involved using some reverse engineering skills as well as a few hints that were handed out by the judges during the CTF. On the FTP Server in the Corporate zone, there was a Firmware file in a .hex format. In this case, it was a SREC format file. After the team was able to dissemble the file, they were left with assembly code. It was no small task running though the code to find the flag as the flag was hidden inside of an add instruction as shown below. The hex value 0x4841434b then converts to HACK which was the flag.
At the end of the S4x15 CTF, 10 of the 42 Flags were not captured. This is not unusual for a CTF. Out of the remaining flags, some of them were focused around 0-days inside of the ICS based products that were inside of the ICS Village CTF Network. However some of the flags were just overlooked and the judges didn’t give out hints to those flags. Here is the final scoreboard as we shut down the flag submissions:
Over three days the CTF changed leaders a few times with a final result of a team made of Swedes and one Canadian won. Team Foobar won with a final score of 11200 points. The top 10 teams (of which there is single player teams) are as follows:
A big thank you to our sponsors Cisco and mGuard, as well as Checkpoint and Belden for providing hardware for the ICS Village. Without their help, the ICS Village CTF would not have gotten where it did this year. Once again, thanks to all those who played, and we look forward to once again improving the ICS Village next year.
We have posted the presentations from Tuesday’s Operations Technology Day (OTDay) of S4x15. The purpose of OTDay is to provide very practical information on how to apply mission critical IT technology and processes to OT.
There were 150 people in attendance for this bonus day / early start to the week.
In addition to the OTDay sessions, the ICS Village opened and the Capture The Flag competition began. Sponsors all had tabletop displays lining the bustling main hallway.
The event was capped off with the Welcome Party sponsored by PFP Cybersecurity and Waterfall Security Solutions. It was a Cuban themed party with cigar rollers, mojito’s, Cuban food, domino contests, and absolutely perfect weather this year.
This is the companion article to our 15 Reasons to be Pessimistic about ICS Security in 2015 that we ran on Friday. On Wednesday I’ll lay out what to look forward to in 2015 based on these two contrasting articles.
Many of the items below come from experiences with clients, peers and ICS community friends. They are not as visible as most of the pessimistic items, but they are activities going on in real companies making real progress on these issues.
- Many large asset owners, those with 10, 50 or 100 ICS spread around the world, are deploying ICS security programs across all sites with required security controls and metrics that management is tracking.
- The mainstream press remains hot on ICS security stories.
- Multiple high quality ICS security training options are available.
- Application whitelisting deployed on ICS computers with and without vendor blessing.
- Some universities are now performing true ICS security research.
- More ICS vendors are implementing an effective security development lifecycle (SDL).
- The NIST Cybersecurity Framework is launching C-level discussions and programs.
- Governments around the world are now engaged in this problem. Varying approaches, different results.
- Peer pressure … multiple examples in 2014 where ICSsec projects were launched because competitor/peer was doing it.
- Virtualization is becoming a mainstream deployment option.
- Greater acceptance of the need for an inventory, data flow diagrams and other basic documentation.
- Leaders in wide variety of sectors beginning ICS security efforts. It’s not focused on electric, petrochem any more.
- Wait … we are still running Windows XP? Management awakening to state of cyber maintenance neglect and finding it unacceptable.
- Vendors are, admittedly still slowly, adding security posture acceptance tests to FAT and SAT.
- Large consulting practices, i.e. IBM, PWC, …, are creating ICS security teams.
What would you add to the list?
Image by PixelVikings
If this is too depressing, wait for Monday’s article 15 Reasons to be Optimistic about ICS Security in 2015.
- Almost all ICS protocols are still insecure by design with no end in sight. Access to ICS = Compromise.
- Most potentially influential organization, US Department of Homeland Security (DHS), still will not say critical infrastructure ICS need to be upgraded or replaced. Playing small ball with little or no impact.
- No legitimate or reasonably honest and objective Automation Press to reach engineers and technicians.
- ISASecure stamp is still being put on insecure by design PLC’s and other embedded devices.
- Influential ARC Advisory Group saying 20-something controlling the plant from his basement is inevitable and focus on securing it.
- SCADA Apologists still dominate the ICS security thought leader / guru / industry and government expert positions.
- Admiral Rogers NSA/US Cyber Command testifies that our lack of defense is why we need to have a strong offense in ICS security.
- Malware targeting ICS applications and protocols.
- ICS vendors seeing no negative financial impact to vulns/insecure by design product offerings. They are fearlessly saying our product offers no security.
- The Internet of Things is confusing ICS security efforts.
- “Nothing will change until something really bad happens” mantra.
- Even when an ICS vendor has well documented security controls, the ICS vendor or integrator more often than not installs the ICS in most insecure/easiest to install configuration.
- Continued fascination and focus on vulnerabilities that matter little to critical infrastructure ICS risk.
- Widespread misuse of defense-in-depth principle, just put up more security perimeters, as the solution for ICS security issues.
Image by cal 00-0