Vulnerability Inheritance in PLCs – CoDeSys V3 Edition

shibuya_guwashi999At last week’s S4xJapan conference, I gave a talk about insecure-by-design vulnerabilities inherited in PLCs, and provide two vulnerable Japanese PLC vendors as examples of those inheriting security issues.

During the talk, I am speaking purposefully slowly — the conference was being simultaneously translated into Japanese and it was important to allow the translators time to catch up.

Inheriting insecure-by-design vulnerability problems is particularly troublesome.  In the talk, I look at two Japanese vendors who have inherited vulnerabilities from third-party software.  In both cases, it appears that the vendors affected are either unwilling (Sanyo Denki) or unable (Hitachi) to fix their systems.  Even if they would or could produce patches for their PLCs, external software dependencies mean it is unlikely that anyone will actually apply those patches.

Sanyo Denki is actually the more interesting case to me, because the same hardware and firmware is in use by many vendors. Their SanMotion C controller is used primarily for servo-actuated robotic arms.  While that isn’t likely to be critical infrastructure to the general public, it is likely a critical system to a manufacturer that relies upon a robot arm in its manufacturing process.

I’ve said this before — 3S Software is in a unique position in the industry.  Hundreds of vendors run their PLC ladder logic runtime.  I wish that 3S Software would introduce some security into the runtime, for example integrating authentication against a RADIUS server or other network management server, and add proper protocol integrity (encryption or at least message signing). They could revolutionize the industry and become the secure logic runtime of choice for security-concious vendors. But…in the words of Ellie Arroway…that continues to be my wish.

There were some fun challenges in making a tool to speak the newer CoDeSys V3 protocol. Continue reading for a little bit of reverse engineering and code-gawking that didn’t end up in my talk.

Read More

S4x15 Theme & Other ICS Security Events

ICS Security Event

Registration for S4x15 Week will open this Thursday, and be ready if you want to get one of the 50 lowest cost tickets to the event.

We are still working on the one word theme for the event. Some of the leading contenders are Advance, Beyond, and Push. I’ve seen the session abstracts and it is going to be a novel and exciting event, a significant leap forward in the ICS security research community. The gap between S4 and other ICS security events has grown significantly over the last three years and S4x15 will extend that even further. In fact, the technical research and discussions at S4 are going so far beyond the standard ICS security event that it is almost unrecognizable that they are all in the same general category ICS security events

This is not a negative comment on SANS, ICSJWG, WeissCon and the international events. There is still a need to provide basic ICS security education and awareness to a huge portion of the ICS community. In fact, the number of people who need one of these traditional and excellent events is 100x or even 1000x the number of people who need an event like S4.

The problem is the top researchers and thought leaders in this space need to continue to push forward. I guess we could worry about getting too far ahead, outrunning the supply lines. However if we have an event that is accessible and understandable to the newcomer to ICS security, or even an advanced beginner or intermediate, it is worthless to the leaders in the ICSsec space. The S4 target attendee is the type that has long outgrown the other ICSsec events.

A very brief history of recent S4 conferences:

  • S4x12 was Project Basecamp (Insecure By Design), Stuxnet Deep Dive (Detailed discussion of first ICS cyber weapon) and the first session on Internet connected ICS. It opened a lot of fronts and took off the gloves.
  • S4x13 was ICS Exploitapolooza. There was session after session showing a pathetically insecure ICS application or device and watch the speaker exploit it. We had over 50 0days at the event. It brought a number of new researchers into the space, but the point was beaten to death for the S4 audience. This was a turning point.
  • S4x14 was a big step forward. ICS low-hanging fruit exploits were banned. Novel attack techniques for ICS and a greater exploration of what an attacker would do post exploit were the highlights. Some big names in security research stepped into the ICS realm. Plus we moved up to the ballroom, added OTDay, ICS Village, and ICSage: ICS Cyber Weapons as well as a lot more fun at the social events.

So what is in store for the main two days of S4x15? It is a continuation of what was hinted at and started at S4x14. The focus is on the engineering and automation aspects of attacking and defending ICS. We have some great session on simulation for analysis and defense, some novel attack techniques, basically things that you will not see anywhere else. … and there will be triangles.

We have said from the first S4x07 that this event is not for everyone. If you want to discuss OT vs IT or information sharing or what some government agency is doing, go to one of the other great events. If you want a lot of technical meat, new concepts and to mingle with best minds in the ICS security space you should grab a ticket for S4x15.

  • Critical Intelligence

Friday News & Notes

SCADA Security NewsThe biggest story of the week … we may have the 3rd example of malware targeting ICS. Kyle Wilhoit and Jim Gogolinski of Trend Micro write about Sandworm attacking GE Cimplicity HMI. Interesting pull quote, “As further proof of the malware targeting CIMPILICITY, it drops files into the CIMPLICITY installation directory using the %CIMPATH% environment variable on the victim machines.” These directories are likely excluded in anti-virus deployments.

Digital Bond held the first S4xJapan in Tokyo this week. We will be posting the presentations on Monday and the video over the next two weeks. It was great to see some strong sessions from Japanese researchers, and we were particularly impressed by the graduate students at the Nagoya Institute of Technology. The Dynamic Zoning sessions could be one of the best defensive ideas to come to ICS in a while.

ISA acquired the site. The terms of the acquisition were not disclosed in the press release. Walt Boyes, a veteran of the automation press and all things ISA, thinks this is a great move. I’m hesitant to disagree with Walt, but I’m not sure what this says about ISA. publishes thinly veiled, if not blatant, vendor advertising disguised as articles and newsletters. At least they are honest about the advertorial. “As you know the most successful marketing campaigns include a combination of editorial, brand recognition and lead generation components. We look forward to working with you and your team on compelling editorial features, as well as integrated marketing campaigns.” My favorite example was when insisted that Siemens responded well to Stuxnet even though they lied about fixing the problem. ISA will now be even more motivated to curry favor with vendors rather than provide honest information for the user community.

Billy Rios has started Laconicly, a team of “Building Automation Systems and Internet of Things Risk Management Professionals”. They are also selling a building automation system enumeration product or service called Soteria. Good luck in the new venture Billy.

Protocol Differential Analysis

helix_nigel_brownThe term Protocol Differential Analysis needs to make Google as an infosec technique.  I first heard the term from esSOBi at Indianapolis’ Circle City Con.  I first encountered the trick, though, in a research lab a few years before: a quick and dirty tool was written by a colleague there to help analyze a very, very bizarre serial protocol.

The problem, briefly explained, is this: as an attacker, we want to find out what interesting packets are in a conversation between a controller and its engineering software. For example, we want to find out what packet represents the ‘Stop CPU’ command in a proprietary protocol.  Since the protocol is undocumented, we are left either reverse engineering the master application, which can be extremely time-consuming, or analyzing the protocol stream itself to find the interesting packets.

Protocol analysis is often the easier path.  Unfortunately, industrial proprietary protocols are extremely ‘chatty.’ Based upon the classic industrial poll-response model, the protocols may be sending tens or even hundreds of packets per second back-and-forth between the PC software and the industrial controller. By the time we interact with the software and click the ‘Stop CPU,’ button on a graphical interface, we may have thousands of packets to dig through.  We want to find the packets that are interesting, but end up wading in a river, looking for the raindrop that holds the key to an attack.
Read More

Friday News & Notes

Letter FWurldtech announced the Achilles Industrial Firewall. It was hard to understand why GE purchased Wurldtech for their protocol testing, but if they were purchasing this product it begins to makes sense. The pricing for the perimeter model starts at $30K and the field model starts at $6K. This is significantly more than competitor products, not to mention non-industrial firewalls that are about 1/10 this price. The first release has some deep packet inspection for Modbus, DNP3 and OPC Classic, awaiting more details on this.

Mandiant announced an ICS Gap Assessment service. Not a lot of detail and not a big surprise given they had hired a handful of experts. Still my guess is this is a sidelight to the main goal of adding ICS expertise to the incident response service that Mandiant is known for. Many of the largest companies in the US and world own and operate ICS.

This week was the semi-annual, fall meeting of DHS’s ICSJWG in Idaho Falls, ID. There were between 140 and 160 attendees with half attending for the first time. Spy reports say the agenda was solid, but not much new from past events. It’s a reasonable free event for newcomers to ICSsec to attend, and there is probably a place for that.

S4x15 Registration Info


S4x15 registration will open at noon EDT on October 23rd. Registering early will not only guarantee you a spot at the event, it will also save you some money.

We have kept the price for the two-day S4 event at $995 since the first S4 in 2007. We even added a third day, Operations Technology Day (OTDay), last year and kept the $995 price. This year there is a small price increase … unless you are in the first group of registrants.

We will be selling tickets for the main two-day S4x15 sessions in blocks of 50:

  • First 50 tickets will cost $995
  • Tickets 51-100 will cost $1,095
  • Tickets 101 -150 will cost $1,195
  • Tickets 151-capacity will cost $1,295

All tickets will include OTDay on Tuesday at no extra charge. The Friday events for S4 Week (ICSage: ICS Cyber Weapons conference or advanced ICS security training) will cost $600 as in past years.

All this may be a bit confusing, but it will be clear on the registration site. The key is if you are a humble researcher, independent consultant, student or work for a company that is hard to get training funds, register early. Capacity is 190 attendees, but that includes about 20 speakers who get in for free.

The agenda is both great and novel this year. I’ll write up a blog next Monday on the theme and characterize the talks. If you are tired of the same old talks at other ICS security events, you will love this agenda.

We are full up on the 30 and 45 minute sessions on the S4x15 agenda, except for saving a space for some late breaking, amazing research. We are still looking for two or three 15 minute sessions with very fresh content.

OTDay will have full two full tracks this year. One track is already full with a number of potential sessions being worked on / recruited for the second track. The challenge is we are not allowing vendor sessions at OTDay. Instead we are getting owner/operators to discuss what worked, lessons learned and practical applications of OT. OT is more than security. It is how to deploy and maintain a robust, mission critical system. So vendors find a good customer and asset owners, here is a way to attend S4 Week for free.

The agenda for ICSage – ICS Cyber Weapon is about 75% complete. I’m really pleased with how this event has matured in it’s second year. I actually believe that ICSage sessions will generate the most news in S4 Week. For the last 25% we are hunting for historical, economic, political theorist and other non-technical sessions.

Friday News & Notes

SCADA Security NewsThe US Food and Drug Administration (FDA) published Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. We haven’t had time to read it yet, but take a look at Patrick Coyle’s analysis. Pull quote, “Interestingly, in this section the FDA specifically abdicates responsibility for cybersecurity system updates, noting that: ‘The FDA typically will not need to review or approve medical device software changes made solely to strengthen cybersecurity.’”

Oops. Bloomberg reporter Jordan Robertson, who has written good articles on ICSsec, was led astray on ICS honeypot data by ThreatStream. Chattanooga appearing so high on the list should have been a red flag. This is a great cautionary tale with CSO covering the analysis flaws. ThreatStream made matters worse with “The scans were on tcp port 102 and the requests were mostly protocol compliant. Siemens utilizes port 102 … We are not familiar with other services that use this port.”  ICCP, other iso-tsap …

Bob Radvanovsky and the Project Shine team have posted a paper showing the results of their search for Internet connected ICS devices. Great work by this volunteer team. It raised awareness for a lot of asset owners to look and pull these connections. It may also have encouraged John Matherly to add ICS scanning capabilities to Shodan. It is now so fast that Shodan has integrated and scanned for ICS devices within days of a Project Redpoint release.

If you want more on Internet connected PLC’s, read Distinguishing Internet-Facing ICS Devices Using PLC Programming Information by Paul Williams at AFIT.

Stephen Hilt’s presentation from DerbyCon on Project Redpoint is up on YouTube.

On October 11th Altamira is running a CTF called Scram Hackathon 2.0. The goal is to cause a nuclear power plant scram, emergency shutdown. (ht: Paul Asadoorian’s Security Weekly)

A near complete agenda is now up for the ICS Cyber Security Conference, Oct 20-23 in Atlanta, GA. Can we call it WeissCon for one more year even though Joe sold the event?

ISA99 Co-Chair Eric Cosman put together all of the work the committee has done on ICS cyber security. Eric wrote “the sum-total of our work to date, weighs in at slightly less than 900 letter sized pages, with a file size of just over 20MB.”

SSI Software and Technology acquired 60% of S21sec. S21sec is one of the largest ICS security consultancies in Spain, and perhaps in Europe. Schneider Electric is also a minority shareholder.

ARC Advisory Group continues to promote anytime, anywhere, any device control of an ICS. The latest is in their work with/for ICONICS mobile app. “While this is largely driven by the new Millennial generation of workers, most stakeholders are beginning to embrace smartphones, tablets, ‘phablets,’ and other mobile devices to access manufacturing processes, information and intelligence at any time from any location with wireless or cellular access.”

Security Theater ICS Webisode

2957968716_55a53da2f6_mICS-CERT published an advisory on web server vulnerabilities in Schneider Electric PLC’s including Quantums, Momentums, TSX and other Modicon models. It is a near perfect example of what is wrong with DHS and PLC vendors and in a way the ICSsec community for letting this decade long farce continue.

The PLC’s affected by the advisory are insecure by design. The directory traversal vulnerability is just the cherry on the top. The best example is most rely on Modbus function code 90, which we just talked about in the new Redpoint script this week.

Reid released three Modicon Metasploit modules in Feb 2012 with the best demonstration of the insecure by design, function code 90 problem being the modicon_stux_transfer. This lets you upload or download logic from the Schneider Electric PLC without authentication, a la Stuxnet, by using features in the PLC. 30 months later there is no fix or even an announced plan to fix the protocol and PLCs.

I have never heard or read anything from Schneider on how they plan to address this or other core security problems highlighted in Project Basecamp. They appear to be examples of Reid’s Forever Days™.

Even if you apply the firmware update for the web server vuln, your PLC is still insecure with the Modbus standard and Schneider proprietary function codes and other features. No offense to Billy Rios and the good work he does finding ICS vulns, but a web vulnerability does little to increase the risk when the main control protocol is purposely designed to allow anyone with access to affect the availability and integrity of the product in any way they can think of.

Why is the vendor bothering to address “vulnerabilities” when they provide an attacker with all the features required to attack the device? For marketing reasons? Because they don’t know better? Because DHS says insecure by design is not a vulnerability?

And then there is ICS-CERT … which is much more than a CERT. ICS-CERT is the brand DHS uses to market all of their ICS cyber security activities.

I am still waiting for DHS to state that insecure by design protocols and devices in the critical infrastructure need to be upgraded or replaced. crickets

There is a section in most ICS-CERT Alerts and Advisories where this would fit in perfectly. Right after “ICS-CERT encourages asset owners to take additional defensive measures to protect against this and other cybersecurity risks.”

Instead ICS-CERT/DHS processes all vulnerability reports like a clerk processing paperwork. Everything handled exactly the same with the goal of moving something from the inbox to the outbox. We need a leader not a clerk in this position that could have so much influence on the ICS community.

Why is DHS bothering with this type of vulnerability that does not markedly affect risk whether it exists or is patched and not mentioning the serious problems? Because it is how they convince their bosses in the Executive Branch, Congress, reporters and industry leaders who can be fooled that they are doing a good job. DHS shows them stats for number of Alerts and Advisories, number of fly away response trips, CSET interviews, and other busy work.

It is disconcerting when you talk to the leaders that DHS should be rallying to address the problem. They will tell you that DHS is doing a great job, yet they have no idea that most of the critical infrastructure is solely relying on an easily penetrated cyber and physical security perimeter for protection. That once inside critical infrastructure the perimeter the critical infrastructure has less security than your ATM card. In fact they will argue with you that the ICS protocol and device insecurity issue cannot be true.

I will admit, reluctantly, that Project Basecamp has failed, and full post on this subject is forthcoming. It has not instigated any significant move to upgrade or replace insecure by design PLC’s in the critical infrastructure. Siemens has made some improvements in the S7-1500, and the GE D20-MX at least now has the processing power that could handle security. SEL continues to introduce new security features into their substation equipment, and some of this no longer can be called insecure by design. These are the exceptions, and this latest Schneider/ICS-CERT fiasco is the final nail in the Project Basecamp coffin.

The funny thing is there was some hysteria, and we received a fair amount of pressure from vendors and others, after Project Basecamp. The main argument of the detractors was: how could we give the attackers such an advantage and not work with the vendors to fix the problem? In reality, I think most, but not all, of the objection was related to a fear that this would lead to exploits that then might force asset owners, vendors and DHS to face the silently accepted risk.

Let’s just keep it all quiet, in the ICS community, and deal with it in the next decade.

Since little has happened the only logical conclusion is the ICS community chooses to continue to accept the risk of relying solely, or at least primarily, on the security perimeter.

This admission of Basecamp failure doesn’t mean that we will stop raising the issue and educating C-level executives and key leaders to the risk they are accepting whenever we can. There are some leaders in the ICS space that are pushing vendors for DNP3 SA and other secure solutions, and some ICSsec people in the vendor organizations pushing the issue. We have even seen some SCADA Apologist conversions. I hope loyal readers will make their voice heard as well.

Image by novas0x2a

Where To Hide Malware In ICS

ICS Malware

The folders that ICS applications are installed in are usually configured as exclusions to anti-virus scanning.

In some cases, the almost constant updating of the ICS data files leads to unacceptable performance if subjected to anti-virus protection. In other cases the vendor chose to avoid a potential, yet unseen problem.

To make this problem worse, the permissions on the ICS application folders are typically far from least privilege. Full Control for Everyone is not unusual for a default install. Folder permissions was an area we spent a lot of time with ICS vendors in developing the Bandolier Security Audit Files. They can be locked down, but rarely are.

We have not yet seen mass market malware seek out ICS application folders that were typically excluded from anti-virus scanning. However, a directed attacker might put his malware in these folders to prevent getting detected by a future signature.

Redpoint: Schneider/Modicon PLC Enumeration

Our Stephen Hilt released another Project Redpoint script as part of his DerbyCon presentation on Sunday. Modicon-info.nse will identify PLC’s and other Schneider Electric/Modicon devices on the network and then enumerates the device.

The script pulls information that would be helpful in maintaining an inventory as well as assessing the security status of the device, such as types of Ethernet, CPU modules and memory cards as well as the firmware version.

My favorite part of the script is the Project Information field. Here you will see the name of the Project, the version number of Unity Pro (the engineering workstation software) that was used to load the Project, and often where on the engineering workstation the Project file is stored. Below is sample output; click on the picture to see a larger version.


This script is possible due to Schneider Electric’s proprietary and magic function code 90. This is the same function code that Reid used in the modicon_stux_transfer metasploit module to upload and download logic to the PLC a la Stuxnet. You can do almost anything you want to the Schneider PLC’s through this unauthenticated, insecure by design function code 90.

The script begins using function code 43 to identify if there is a Modbus device at the targeted IP address. Schneider, unlike many vendors, supports function code 43 and will return some variant of Schneider in the response message. I should note that even if the Modbus device being queried does not support function code 43 the response can confirm it is a Modbus device.

We had an internal discussion on whether the script should include all identified Modbus devices, but decided to only report on Schneider/Modicon devices since there were already Modbus detection capabilities in Nmap. If we can pull additional useful information there may be a generic Modbus script in the Redpoint rack in the future.