Last week Stephen made a minor, but very helpful, update to the Redpoint script that identifies and enumerates BACnet gateways and devices. All publicly available Redpoint scripts are on our GitHub, and some of the scripts have been integrated into the nmap download.
The latest version has the option to pull the Foreign Device Table (FDT) and the Broadcast Distribution Table (BDT). Both are helpful in enumerating BACnet devices on different, and possibly inaccessible to scanning, subnets.
Imagine the case where you have a BACnet device on the corporate network that is used by the team to view the status of an otherwise segmented building management system from their corporate computers. The BDT and FDT may help you identify those non-accessible devices.
Any time a BACnet network consists of more than one subnet, each subnet must have a BACnet Broadcast Management Device (BBMD). Each BBMD in the BACnet network has an identical Broadcast Distribution Table (BDT) that lists all of the BBMD’s in the network. So by recovering the BDT you will learn all the subnets that have BACnet devices in the BACnet network.
Well, not quite. There is another way for a BACnet device on a different subnet to join a BACnet network … by registering as a foreign device. To fully participate in the BACnet network the foreign device should register with a BBMD. However the foreign device can register with any device that supports foreign devices, and most BACnet gateways do.
So the Redpoint script can also pull the Foreign Device Table (FDT), which is useful in identifying BACnet devices and possibly even attackers.
Each entry in the FDT is suppose to have a Time-To-Live for each registered foreign device, and then erase foreign devices that don’t re-register in that time period. In practice we have found that many foreign device entries never time out.
Let’s look at a practical example from Redpoint output: Read More
For my first blog post at Digital Bond I’m going to break The Rule and talk about what happened in Vegas.
Every year I head to Las Vegas in early August for DEF CON. Usually I’m participating with my fine teammates in the capture-the-flag competition but this year we failed to qualify (sadface). I had heard rumblings of a proposal to start an ICS Village which was a relief because I had no idea what to do with myself at DEF CON without CTF.
Our proposal got accepted and DEF CON 22 had it’s first ICS Village. Spoiler: it was awesome and we’ll be back next year.
Over a dozen people worked together to create the village. Phoenix Contact provided a ton of equipment so Props to Thomas VanNorman and crew. We had a large mock water treatment plant that included multiple PLCs, networks, protocols, and radio communications (plus some flashy lights and sounds). Also a hit were PLC driven robotic arms that attendees could control with provided joysticks or by plugging in their laptops and slinging some code.
Sponsor organizations who made attendee smiles possible
Water treatment plant
The crew with DT. Thanks to all who helped.
The most bestest thing (in my totally unbiased opinion) was the SCADA-from-scratch, done by myself and Ken Shaw, which was a mockup of our homebrew automation system that we installed for use in a local brewery (see what I did there). Given that a large portion of the audience would be completely unfamiliar with ICS technologies we thought it would be interesting to present the “post-apocalyptic” approach to solving the problem with modern hardware, software, and design principles and see the attendee reactions to the contrasts. Our slides are posted here and you can watch the talk online.
Additionally, there were some really great talks by John Matherly on Shodan, Cutaway on radio hacking, Anthony and Bryan of ICS-CERT watch floor un-fame, Chris Sistrunk discussing Project Robus, a grabbag from Atlas 0f d00m, and others. If I get recordings of those I’ll post links.1
Overall it was very well received and went surprisingly smoothly for being a first year event with a non-ICS focused audience. Thanks to all who helped make it awesome, particularly Bryan Hatton (@phaktor) for taking point. That said, there are a lot of areas in which we can improve.
On that topic I am excited to be joining Digital Bond because they know a thing or two about running an ICS Village. I’m looking forward to being involved in the village at S4 and engaging with an audience that already knows ICS. Working with Reid at Digital Bond Labs is going to be great and we’re pretty fired up about the projects we’ve got going on. Stay tuned for fun things.
Photos by Nadeem Douba, Claudio Caracciolo, John McNabb
Digital Bond has started backing Kickstarter projects in order to build up our rack of security assessment and research tools. One of our recent deliveries is the RFIDler, a low-cost 125khz and 134khz RFID tool. RFIDler is an interesting project because it combines an easy-to-use command line interface with a software defined radio, at roughly 1/4th the cost of the Proxmark3. As a tool, it can be used to both easily clone low-security cards and to explore as-yet-unsupported card formats so that you can clone or attack new kinds of proximity card.
For testing the RFIDler, we in the Labs used a handful of unknown tokens, purchased a long, long time ago — so long ago that we didn’t even know what kind of tags they were (let alone where we bought them from). The tags, along with a bare-board unlabeled reader, were originally going to be used as an RFID garage door opener, as a replacement for a standard pinpad. The RFIDler is such a nice tool because now we can find out what kind of reader these badges use, and help us determine whether the project can even be done securely.
The RFIDler contains some nice token exploration commands. The most basic of these is the command-line, ‘autotag’ command, which attempts to read your token using all of the currently supported formats.
‘autotag’ of course attempts all of the format types, many of which produce data. So, what is the actual type of our tag?
The US National Institute of Standards and Technology (NIST) is looking to award contracts to build one or more Reconfigurable Control System Cyber Security Testbeds, see diagram below. This could be useful for basic education, that a lot of University programs are calling research, on what ICS is and ICSsec 101.
Read Adam Crain’s article this week on a specific type of attack on DNP3 master stations. He points out it is not fuzzing, just an unexpected use of the protocol that causes a lot of crashes/denial of service. “With a vulnerability like this, however, you can take down the entire master and all the remote sessions with a single packet.” The DNP3 Technical Committee has put out “Technical Bulletin TB2014-006, Clarification of the Use of Variation 0 with Object Groups 110-113″. Does that sound like a call to arms on a security issue? You may remember that the DNP3 Technical Committee previously stressed that the Crain/Sistrunk vulns were not related to the DNP3 specification.
NIST will hold another workshop on the Cybersecurity Framework, Oct 29-30 in Tampa. “The purpose of this workshop is to gather input to help NIST understand stakeholder awareness of, and initial experiences with, the framework and related activities to support its use.” We have been pleasantly surprised by our experience with the CSF. Not the document itself, but the conversations and action it has spawned. This is not due to the roll out; more in spite of the roll out and a recognition of need.
UPDATE: Moved from comments to main post
Extra ICS news from France last week…
- Cybersecurity for Industrial Control Systems – Classification Method and Key Measures
- Cybersecurity for Industrial Control Systems – Detailed Measures
At first glance just another framework but the focus on measures with some prescriptiveness seems this framework is worthy of closer inspection.
I am very happy to announce that Corey Thuen will be joining Digital Bond Labs as a researcher and consultant. Long-time followers of Digital Bond and the S4 conference will know Corey as co-creator of, ”SCADA from Scratch,” a project he started with Ken Shaw using off-the-shelf embedded tools to create a secure-by-design control system (this tool is the subject of a recent article in Forbes, as well as an upcoming Kickstarter). He has also proctored Idaho National Labs’ much-lauded Red/Blue Training, and co-taught a protocol fuzz-testing class with Adam Crain at S4x14.
Corey brings us a ton of experience in protocol analysis, fuzz-testing, and building and testing control systems. We could not be happier to have him on our team.
Kaspersky issued a research report on Havex they called Energetic Bear – Crouching Yeti after the threat actor. It’s probably worth it’s own post and worth reading but here are three highlights.
On page 15 (HT: Damiano Bolzoni) they describe the Network Scanning Module that looks for much more than OPC servers. It is scanning for Modbus (502), Siemens S7 (102), EtherNet/IP (44818) and ports for two proprietary ICS vendor protocols. Much like Stuxnet, I expect we are just starting to learn what Havex’s ICS capabilities are. Is it asking too much for DHS/INL to actually perform research and inform the community? It’s understandable, after the fact, why they didn’t research Stuxnet, but this is only the second piece of public ICS malware. Stop sending fly away teams for telnet password cracking attacks and other corporate network exploits and use that pricey ICSsec expertise developed over the last decade.
Kaspersky identifies the Swiss company, Mesa Imaging. This is what we were told and is very helpful for identifying the target. Mesa Imaging is not an ICS vendor. So what company or country sector is using eWon, MB Connect and Mesa Imaging products? That is the best clue so far for who the threat actor was targeting with that phase of the attack.
Kaspersky states there is not enough data to identify the Crouching Yeti threat actor. Some have pointed the finger at Russia, but I’d agree that there is not dispositive evidence in the public at this time.
Belden announced Tofino 2.0 this week. Lot’s of good technical info surrounding the obligatory marketing hype in Eric’s blog entry. I want to dig into the technical details more in a future article and perhaps podcast. The EtherNet/IP Deep Packet Inspection had to be a bear to write, and I’m looking forward to running it through some use cases. When are we going to see this technology integrated into a PLC Ethernet module?
Take note of the latest ICS-CERT advisory from the Crain/Sistrunk
DNP3 Telegyr 8979 master fuzzing. This one is related to a SUBNET Solutions product. Most important is a 13-word sentence: “SUBNET had also determined the root issue was in the GPT software library“. The GPT software library was sold by ASE to a number of ICS vendors that now have a latent, remotely exploitable vuln that is available to all. Shouldn’t ICS-CERT be disclosing these vendor names so affected electric utilities can take action? This could be a difficult fix because ASE is no longer selling the GPT/Protocol Pak, but SUBNET found a way.
All software needs to be part of your security patching program … including your security software. Latest example is a new 0day in Symantec Endpoint Protection (SEP). It’s also why you keep your attack surface as small as possible.
Cisco takes your IoT and raises it to Internet of Everything (IoE). They announced partnerships with Rockwell Automation and Yokogawa to support “risk management and compliance for industrial control environments.” It’s one of those press releases that is hard to digest. “It addresses risks using a combination of people, process and technology.” The best I can tell is Cisco will be helping Rockwell Automation and Yokogawa design Cisco products into their ICS.
Graham Speake made the move from Yokogawa to NexDefense. NexDefense is another Mike Assante venture that is trying to commercialize the INL Sophia product. Mike also heads up the SANS ICS security program, and Graham is a SANS ICS security instructor as well as longtime active participant in ISA99. Good luck Graham.
EMET 5.0 is now available from Microsoft. This latest version adds Attack Surface Reduction and Export Address Table Filtering Plus. EMET has gotten some traction in the ICS space, especially for vendors that seem to have little concern for security or fixing identified vulns.
You can get some great tools at reasonable prices by backing the right Kickstarter campaigns. We will be taking the RFIDIer out to an assessment next week, and we should be soon getting our HackRF’s. Look for soon to follow reviews so you can consider them for your toolkit.
Image by ChrisInPlymouth
I was talking a while ago to Justin Engler, a friend who also happens to be a really talented web app and mobile app security researcher, about the popping-up of ICS management software for mobile devices. He theorized that mobile apps for ICS would be an interesting place to watch for bugs nearly three years ago. Dale’s recent ICSJWG Q&A over mobile device security gave me a little motivation to dig into some sample apps and see how the field actually looks. The results highlight some of the issues that your organization will run into if and when you decide to adopt mobile.
The focus of this post is not just application security. While there are a few specific vulnerable applications mentioned, I think that the big lessons should be ones of architecture and integration challenges. The current lot of ICS management apps pay little mind to securing access or preventing bad operation. Even an app with ‘secure’ on its product homepage may leave you wide open.
I decided to pick on Android simply because my only jailbroken iOS device at the moment is so terribly destroyed from years of abuse that installing new apps is a nonstarter. There also seems to be more interesting control systems apps for Android at the moment.
A quick survey of Google’s Play store for terms such as ‘SCADA’’, ‘PLC’, and ‘OPC’ turns up a few applications worth checking out. Unfortunately there are no apps that I could find which do what Dale prescribes: obtain safe, accurate, remote, ‘read-only’ access to control system data. Doing so will require a lot of backend work on your part.
Let’s take a look at two interesting vulnerable applications.
You are pounded with the message: ICS security is different than IT security. The fact is the Operations Technology (OT) in an ICS is a mission critical / high value IT system and needs to be treated like one. Don’t let the ICS is different argument allow you to accept fragility and insecurity in your OT.
The trigger for this entry is Bob Huba’s article in ISA’s Intech: Top Ten Differences Between ICS and IT Cybersecurity. The article is well written and accurate in comparing ICS and IT Desktop management, but that is the wrong comparison. ICS should be compared to mission critical / high value IT where companies can tell you how much money they lose, and it’s often a big number, for every minute of downtime.
There are plenty of mission critical IT systems that have availability requirements that rival ICS (1: Security Objectives). They have a better availability strategy than the too often ICS approach of make it redundant and don’t touch it if it is working. This is software and hardware that must be managed and supported to meet the availability requirements and not devolve into fragility.
Bob’s 8: Untested Software applies to both high value IT and OT. The change management around both includes rigorous testing, phased deployment, rollback strategy, etc. If you load up a patch or upgrade in high value IT and bring something down, you will see a similar management reaction to an ICS outage. Clearly the physical danger in a lack of integrity or availability is a factor in ICS, but do you honestly believe that a large financial impact is not treated with a similar level of concern to a business?
#9: Patching and #10: Security Inconveniences are ICS excuses and actually make the ICS more insecure and fragile than the high value IT. An ICS needs to be designed with a plan to support and maintain the mission critical IT system that it is. Would you put in physical equipment and not consider what maintenance will be required to the physical equipment to support reliable operation? I always point to Langner’s Robust Control System Networks as the book to hand an engineer who needs to understand why a fragile ICS is a problem.
The #3: Network Topology for ICS actually sounds like high value IT systems. #2 Network Segmentation is a partially valid difference. Some high value IT systems are Internet accessible, others are not. The high value IT systems will use DMZ’s and least privilege rulesets that quite frankly are much more restrictive than the average ICS firewall ruleset.
#6: User Accounts really is not a valid difference between IT and ICS, except that ICS too often accepts poor identification. Role based authorization is common in both as are other authorization methods and principles. Authorization has traditionally been an area of strength for ICS, and increasingly this is being performed in Active Directory.
There are a few areas of genuine ICS and High Value IT difference that Bob points out:
- High value IT does not typically have Safety Instrumented Systems (#7: SIS)
- The Purdue model does not apply to IT (#4: Functional Modeling), but you could argue that they have similar data flow and responsibility models with different names.
- Many of the #5: Physical Components are unique to ICS … although you are seeing some of these physical components in a Data Center.
I agree with Bob that if you treat ICS HMI, EWS, Historians, Real Time Servers, PLC’s, RTU’s … like desktop user PC’s you will cause some serious problems, but this is a flawed comparison.
There is a lot the ICS community can learn and emulate from Mission Critical / High Value IT in designing, deploying and maintaining a robust OT environment. We should be leveraging their knowledge and processes rather than pushing them away. And certainly we shouldn’t continue down the path of install and don’t maintain because we didn’t plan to support the OT and don’t know how.
This is not to say that High Value IT is perfect. There are systems running with uncertainty and fragility and just hoping things won’t break … a similarity with many critical infrastructure ICS.
Image by Dan McKay
After the PG&E substation shooting, FERC had ordered NERC, as the ERO, to develop and submit a Physical Security Reliability Standard within a very short time frame for this type of work. NERC complied and now FERC says they will approve the standard with two changes. FERC wants the ability to add or remove facilities from the critical facilities list. While they say this would be “exercised only rarely”, this is a crack in the door or slippery slope that is likely to give utilities heartburn. FERC also wants to replace “widespread instability” with “instability”. There needs to be an adjective in front of instability.
Critical Intelligence is holding a one day conference and two days of training called CounterIntel, Sept 16-18 in Park City, UT. The two day training is to help you be a more effective Cyber Intelligence Analyst, and the whole event is limited to owner/operators. Living in the Park City area, I can tell you it is a great time to hold a conference here.
Read the Kyle Wilhoit of FireEye article on how Havex enumerates OPC Servers. Great work.
The automobile sector has started the Auto Information Sharing and Analysis Center (Auto-ISAC). ISAC’s have a very mixed record based, but it seems every sector will have one.
Image by ChrisinPlymouth (the F king)
The S4x15 Week Call for Papers/Presentations is now out.
Send us your session ideas asap to have the best chance of getting on the agenda. All we need is a short description and time requirement mailed to email@example.com.
We are calling it S4x15 Week now because it goes Tuesday – Friday (Jan 13-16 in Miami Beach):
- Tuesday – OTDay and ICS Village Opens
- Wednesday – Day 1 of S4x15
- Thursday – Day 2 of S4x15
- Friday – ICSage:ICS Cyberweapons and Advanced Topics ICS Security Training
The CFP gives more detail on each day and the type of sessions we are looking for.
I wish that we could sit back and wait for all the great sessions to come in, but history has shown that we need to hunt for this great work and unknown talent. If you see or hear about anything that we should chase for S4x15 week, please let us know.
Last year was a big step forward for the ICS security community. We moved past low hanging fruit; we brought in some top security researchers from outside the ICS space; and there was a new focus on what an attacker would do after successful exploit.
We are looking forward to seeing some new and amazing work for S4x15.