ICS-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