Dale Peterson 
This work, and slightly edited blog post, is from a new Project Basecamp researcher that prefers to remain behind the scenes. We welcome any researchers to join the Basecamp team.
One of the most interesting “products” in Project Basecamp was CoDeSys, because this runtime library is used literally by hundreds of vendors. In fact, most users probably don’t even know that their PLC is running CoDeSys libraries. The CoDeSys password mechanism was found to only be effective if you used their GUI. Of course an attacker could easily access the PLC directly via the command line or ftp with no password required. The vendor (3S) claimed:
In general, we do not offer any standard tools in CODESYS which are to protect the controller from a serious cyber attack. Should the offered password functionality suggest such a protection, this was definitely not our intention.
This is proving to be true for the protection of 3S and their OEM customers’ intellectual property.
When a vendor is using CoDeSys as his IEC61131-3 runtime, there is not a lot of room to distinguish your product from all the others using CoDeSys too. However, one way is vendor specific libraries. These are essentially CoDeSys programs with specific functions or function blocks, but with the file extension .lib. Those libraries can be imported into any normal user program.
Say a user wants to have his PLC program get a configuration file from an FTP server. The vendor may provide a library with an FTP_Client function block that can be imported and just used instead of the user having to write all the tedious socket handling.
Now as a vendor, these libraries are essentially intellectual property and should be protected as such. CoDeSys with it’s software history has loads of options to do this:
Now “encrypted internal library” sounds like what we want. Unfortunately, to import an encrypted library, you have to provide the encryption key and thus essentially provide the decryption to customers. So the way to go (and most vendors, including 3S themsel ves, choose this path) is to use an internal library and protect it with a project password:
When a password is entered there, the saved library will still be importable with the library manager, but when you try to open it directly with CoDeSys, a password prompt is shown:
When the library is copied to another computer, the prompt still shows when trying to open it and the password is still checked correctly, so that means the password has to be inside the .lib file.
Once you take a look at a file comparison of a password protected .lib and a clean one, it’s almost immediately clear, how the “encryption” works:
Small side note here: this knowledge is apparently not new. When searching the web for things like “codesys library decrypt” you will find that users in Russian PLC forums already have the knowledge to “unPassword” codesys libraries. There even is some Chinese allround software that can find the passwords for libraries and generate keys for Beckhoff’s TwinCAT software.
So just by looking at the password protected version of the library, I saw the algorithm to “decrypt” it, threw together a python script to do it and did an extensive internet search for publicly downloadable codesys libraries once the script worked. Downloaded all of them and let my python script run against all of them.
I found 489 unique codesys libraries as public downloads on the Internet. 323 (66%) of those libraries were not protected at all. So either the content was not supposed to be protected from view by the customer or the vendor did not know how to do it. This left 166 (34%) of all libraries I found to be protected by a password, so those vendors did care about their intellectual property.
Of the 166 passwords I found:
- 31 were unique
- 22 chars was the longest
- 3 chars the shortest
- 19.77% is the average password strength (measured by www.passwordstrength.com)
The passwords themselves are not that creative with “HELLO” being the bottom of the pit. I can just imagine the snickering developers, when entering their library password “rc3sexpert”. But the funniest one was when the library literally talked to me, with “youthief” as its password.
So what does all this mean?
Well, once again vendors trusted 3S in providing them with a safe and sound product and were betrayed. Now all that precious intellectual property hiding inside the “protected” libraries is basically public knowledge.
This time around, they will also not be able to claim that the password was never intended as a protection mechanism as they did last time.
This excuse will not work since they used the mechanism for their own IP in the CANopen Stack libraries, “protected” by the password “STACK3S”.
What now?
Well, this was all done using the old version of CoDeSys (V2.3.x), not the V3. But I’m not sure the library protection is any better with the new version. So go ask 3S for better protection of your intellectual proptery in upcoming versions. Also, it is always wise to really check the integrity of a third-party mechanism that you will trust your IP with…
And finally, there are quite some vendors I could not obtain all/any libraries from. e.g. Beckhoff has an army of libraries as extension for TwinCAT from “Building Automation” to “Communication” to “Motion”. All of those are downloadable but require a license key (and I did not intend to use the chinese software to get one). You can still try one of the following passwords or just find out how the encraption works by yourself.
Password List:
- 103
- 463
- 583
- 589
- 6020
- 613613
- 91513967
- ANWMODUL
- ARBOGNE
- Enercon
- EXOR_MODBUSTCPSRV
- H2OLA
- HELLO
- L-force
- LIZZY
- MDP211PLC
- MOELLER6020
- PASSWORDFORTCTWINSAFE
- PDMA1
- PLA1
- POLAR BEAR
- PRO502
- PRO503
- RAIDCNTLR
- RALF
- rc3sexpert
- schneetiger11
- STACK3S
- SYSTEMCXXXXX
- youthief
- ZAPPADERMEISTER
Image by Mike Rohde
Dale Peterson  ISA99 continues to churn out quality security documents. Some are written to be ISA/ANSI/IEC standards and others are Technical Reports for guidance. Recently a draft of ISA-TR62443-2-3: Patch Management in the IACS Environment was released for review.
Loyal readers likely don’t need this information because the topic has been discussed for years, but the average ICS owner/operator who is beginning to work on security is struggling with security patching and looking for guidance and good security practices.
Section 5 lists the asset owner requirements in security patching. It does an excellent job in describing and requiring an inventory of “updateable devices”. Documenting what software is running on each device and feeding this into the security patch process is key. Security patching is much more than simply applying Microsoft patches. There are component patches (JRE), 3rd party app patches (web server, database), and patches for the ICS application itself.
Where Section 5 falls down is on prioritization of security patches and phased deployment. There is more information in Appendix B4.3.3, but even that is lacking at this point in the draft. I could write a long section on this, but two important points that weren’t there:
- Prioritized Patching List – It’s a sad fact that many ICS organizations are just beginning security patching efforts and trying to accomplish this across all systems tends to fail. We recommend owner/operators determine what systems are most at risk and focus the initial security patching effort on those systems. For example systems in the ICS DMZ and ICS network systems that are accessible from any external network or the ICS DMZ. If that is too much for a first bite, the prioritized patching list can be further tightened to the services accessible from external networks. This is a lot more practical than evaluating patch by patch.
- Consider Insecure By Design – If the component is insecure by design, patching even a serious issue will do little to improve the security posture. Why do vendors even bother patching systems that can be compromised using a feature.
Section 6 covers the Product Supplier Requirements. It is brief, and the most interesting part is it sets a 30-day window for vendor action on applicable patches.
Section 7 and Appendix A define an XML Schema Definition for vendors to provide Vendor Patch Compatibility information. Will this catch on and is it worth the effort? At least it gives vendors guidance on what information should be provided to their customers.
Most readers should skip straight to Appendix B – IACS Asset Owner Guidance on Patching. Free from the IEC formatting restrictions, this Appendix provides practical advice from start to finish on this process.
The standards making process tends to prevent any strong statements or controls. For example from Section 4:
Some extremely critical systems may have no allowed outage windows available, and can therefore not be patched.
Applying patches is a risk management issue. If the cost of shutdown to apply patches is greater than the risk evaluated cost, then the patch may be delayed, especially if there are other security controls in place that mitigate the risk (such as no internet access from the system).
The idea that it is acceptable for “extremely critical systems” to have no outage window for patching or other component maintenance is flawed. If bringing a component (server/workstation) down for maintenance, not the process, puts an ICS at risk then there is a lack of redundancy and robustness in the system. The danger is an owner/operator not wanting to apply security patches now has an out from a reputable ICS security standards organization — and “such as no internet access” as a security control that mitigates the risk … we would be in for a professional liability claim if we gave that advice.
ISA99 is soliciting comments on this and other drafts. It’s an open process, and they want your input.
Image by ceci un matt
 
Dale Peterson ICS-CERT issued an Alert based on Terry McCorkle and Billy Rios work on the security of medical devices. Not surprisingly they found hard coded passwords in hundreds of devices. But what action are we to take with this Alert, and what is DHS doing beyond coordinating disclosure? We have seen insecure by design PLC and protocol generate alerts with alarming language, and then months and years pass with no further action. Maybe the FDA will take action and foster change where DHS has failed. (I was going to criticize Billy and Terry for not releasing the details, but it was ICS-CERT that chose this disclosure path). (And ioActive joined the party by disclosing the fact they found hard coded ftp credentials in an ICS product, full stop and weak.)
The third workshop on the US Government Cybersecurity Framework is July 10-12 in San Diego. NIST has published a skeleton of an agenda that does little more than give the beginning and ending times. They will likely provide a more detailed agenda as they did for the second workshop. However if this third workshop is going to make progress they should put out materials in advance for review and comment. And we are halfway to the deadline for the release of the first draft.
Tweet of the Week
There was a problem connecting to Twitter.
Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Nothing this week. Enjoy the weekend.
Nothing New This Week
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by duncan
Michael Assante  Guest author Michael Assante is President and CEO of NBISE, an organization focused on improving the cybersecurity workforce. Michael’s career has included ICS security roles with an asset owner, national lab and as the CSO for NERC.
I enjoyed reading your post and offer my thoughts on the topic of technology vs. people (it is a worthwhile discussion/debate):
I agree that one of the largest problems we face is the lack of security in the design and development of Industrial Control System technology. Project Basecamp and national testing efforts has confirmed that security was not a basic requirement for legacy systems and progress has not matched the pace nor breadth at which the world is deploying automation.
People are currently at a distinct disadvantage when trying to protect and defend these systems. I would agree with you that when comparing the security challenge of ICS to other types of technology applications the norm of insecure found in the design is “the immediate problem”. I also see people as the answer in trying to compensate for this difficult circumstance in both the short-term and to prioritize security in the long-term.
It is becoming clearer that necessary security technologies have enabled adequate performance against less directed horizontal threats. Technology will continue to be an important tool for defenders, but it will not dominate our efforts, in the struggle to counter emerging cyber attacks that are highly directed or targeted. Our focus needs to include enhancing the competencies of defenders and changing the behaviors of how people interact with and through technology.
It is as you stated, progress is required on all three fronts (technology, process, and people), but realize that humans will fail to implement technology properly, execute practices reliably, and can always find ways around even the best technology. The amount and extent of which they fail is something that we should be able to influence in the positive direction. As for the attacker’s role I offer that people have a propensity for creativity and a knack for filing in the holes of another person’s imagination.
While I agree on the importance of practices/procedures, I would argue that they are situational in their relevance and will need to be adjusted and changed often. The nature of the cybersecurity problem is a dynamic one. How a system is compromised and attacked has evolved and optimized for success with the least expenditure of effort and energy.
I would also contend that if we were able to change the security nature of ICS technology (an important step to strive for and achieve) that it is but a single dimension measurement. One can assess technology, it has its place and importance, but it cannot be the only assessment. I would argue we are inclined to reduce the challenge of cybersecurity to an assessment of technology. These assessments do not provide the entire picture as the role of people can be undervalued or abstracted. Attackers are people after all (although we might not like them much), and they are co-adaptive in nature, that is to say, they will compensate and adapt to the technology and practices they are facing.
While I can’t and won’t argue with the critical role technology plays in the current problem facing ICS security. I will suggest people do matter and ask that we collectively consider how to optimize this important leg of the cyber stool. For all technology begins as an idea in the minds of innovators and the building of it passes through the minds of developers. I want to echo your notion that executives need to understand cyber and go further to suggest people are important in the following ways:
- Users and administrators introduce vulnerabilities and are capable of circumventing the best security technology implemented. People’s understanding of “why” they are doing something always matters.
- Managers are instrumental in understanding the need to invest in security technologies, practices, and people (we both agree here)
- If you study attacks you realize the important role played by the attacker and the defender’s ability to tune and apply technology to detect and respond to attacks
- People design technology from a system designer, programmer to architect. The more they understand security the better they can define the requirements, follow practices, implement security, and test for it.
- There is too great of a difference between outcomes involving similar technology and involving people with different levels of competency. How a cyber attack effects an organization’s mission, over time, has a lot to do with the level of understanding and skill possessed by the defenders.
- System and process owners need to understand cyber enough to apply it to their work. In the ICS world it means asking ourselves what an operate needs to be aware of and determine how they should react to an event involving a cyber threat? Or what a system engineer should know to make better engineering decisions that account for the new found reality of cyber threats.
Divorcing humans from their role as a viable attack surface and as system defenders is a mistake. Calling for a better understanding of security and greater influence on ICS design and development is a must (again, we are in violent agreement). We should seek every opportunity to push on both the people and technology front as one shapes the other.
Image by USACE Europe District
Dale Peterson 
The ICSJWG Spring Meeting was cancelled, purportedly due to the sequester. ICS-CERT has published the presentations and papers that were submitted for the event on their site. No news yet on a potential fall meeting, but planning should be beginning now if it is going to be a success.
The preliminary agenda for DHS’s Chemical Sector Security Summit, July 10-11 in Baltimore, is now available. Most of the sessions are US Government speakers.
Michael Gross of Vanity Fair has another longish, Vanity Fair style article on cyber war. Not a worth reading from a technical standpoint, but perhaps for the questions you will get from friends and family.
Tweet of the Week
scadafreude, n., Pleasure derived from insecure control systems (and, of course, fixing them) Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by duncan
Dale Peterson The official title of Jason Holcomb’s (Lockheed Martin) session was Turning the Tables: Transformation to Intelligence Driven Defense for ICS, but the thrust of his talk is describing how the cyber kill chain can be used in ICS.
The cyber kill chain steps for a targeted attack are Recon, Weaponization, Delivery, Exploit, Installation, C2 and Actions. Jason points out that the saying the attacker only has to be successful once isn’t quite true. A targeted attack has multiple steps, and the defender has a chance to detect, deny, disrupt, … at each step.
Looking at your SCADA or DCS from the cyber kill chain steps is another way of analyzing and selecting security controls. Jason shows an example of this in a different type of defense in depth table at 26:30. The kill chain steps are on the y axis and the defensive action are on the x axis. The table will identify when you are missing controls at different stages of the attack, and it will also identify the types of security you have in place. For example, a system could have strong deny or disrupt protection at one or more kill chain steps, but lack any detection.
Dale Peterson  Back on 5 July 2012 we added a counter in the right column of our home page: “Schneider Has Not Removed Modicon FTP Backdoor Accound in xxx days.” This was prompted by Ruben Santamarta’s disclosures of the account, but was based off of a December 2006 date when we created a plugin for Nessus that identified the account. As of June 4 the counter was up to 2363 days. Hard to believe.
Tuesday of this week ICS-CERT issued an update to the Schneider Electric Quantum Ethernet Module Hard-Coded Credentials advisory. So the question is have the hard coded FTP credentials been removed thereby stopping the clock?
Based on the information in the advisory the answer is no. The credentials have not been removed and the counter continues.
The advisory states:
Schneider has also created a patch for the HTTP and FTP service that is available on selected Quantum PLC. This patch has a new feature that allows the user to disable the FTP service on modules.
There is no information stating the hard coded credentials are removed.
Future firmware upgrades will likely require FTP be enabled, and there is an open question of how secure is the process of enabling / disabling FTP. Can a hacker simply enable FTP over the network and then use the hardcoded backdoor accounts?
I have taken a break from criticizing ICS-CERT to avoid boring loyal readers, but this bears comment.
An owner/operator reading this advisory or reasonably searching the ICS-CERT would have no idea that the Modicon PLC is insecure by design. It still has unauthenticated ladder logic upload, which allows an attacker to modify the process a la Stuxnet. An attacker with logical access can still start and stop the PLC, and this is all easily demonstrated with the Project Basecamp Metasploit Modules.
Modicon users are still reliant on the keep the bad guys out, security perimeter defense. They lack the defense in depth that is so often heralded as a key tenet of ICS security. We are still waiting for DHS to say that critical infrastructure owner operators should be upgrading or replacing these insecure by design field devices.
For those who say this is not the role of the CERT, understand that DHS has changed its brand and all DHS activities related to ICS are under the ICS-CERT banner.
Dale Peterson  Today we open the S4x14 call for papers / presentations. Send us your brilliant ICS security research for inclusion in the S4x14 program, January 15-16 in sunny Miami Beach. S4 is the one event where presenters can get into technical detail and be understood by an amazing audience. There is no SCADASEC 101 or ITSEC 101.
It’s very simple to submit. Just send an email with your topic, brief description and time needed (30 minutes is standard) to s4@digitalbond.com. If you know of research that we should chase for S4x14, please send us an email as well.
Your session should have some technical meat or a novel idea, or better yet both. Take a look at the S4x13 or S4x12 session videos to get an idea of what we are looking for. I think the definitive S4 presentation was Ralph Langner’s Stuxnet Deep Dive.
Early submission increase your chance for presenting at S4x14.
Our sole goal is to put together the best S4x14 agenda. The process is not a blind, peer reviewed process that waits until the end of the CFP date. Send us your idea, and we will give you immediate feedback. Sometimes we suggest a modification. Sometimes we pair the researcher with another researcher of vendor. If we like the session topic, we will tell you that you are in immediately.
——–
Two other side notes:
- We are also looking for advanced training topics and instructors for the Tuesday and Friday. Last year we had Luigi Auriemma, atlas 0f d00m, Travis Goodspeed and Rios/McCorkle teaching.
- We are working on special one-day events for Tuesday and Friday that should be novel and important for the ICS community. These will be announced in early July.
Dale Peterson  NIST held the second workshop on the US Cybersecurity Framework this week in Pittsburgh, and the main session was viewable on the Internet. You can view the tweets at #nistcsf, and Cynthia Brumfield has published her thoughts on the workshop. The next workshop is in San Diego.
ISA published a Cybersecurity Brochure that covers there activities. It describes the ISA99 standards efforts (a bit light on this I thought), training, books and the certification effort through ISCI.
Missed from last week, Cylance partnered with building construction and operation company McKenneys, Inc. This is likely a follow on from the Rios/McCorkle hack on the Tridium BAS and is a non-traditional partnership for a security firm. A sign of things to come?
SANS has started a new series they call the ICS Security Vendor Briefing. The first one is available at the SANS event in Houston on June 10th and includes and are sponsored by Waterfall, Cylance and Codenomicon. SANS limits the commercialism of the vendor sponsored presentations, but don’t let the non-profit angle fool you. These are paid vendor pitches to the SANS audience.
Tweet of the Week
We get the InfoSec we deserve… so; what are you going to do about it? I'm ready to help shake it up. #SecChat Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by mag3737
Dale Peterson Michael Toecker’s session at S4x13 focused on two things.
- How secure are the applications that engineers use to configure relays in the electric grid? Prominent examples are GE’s Enervista and SEL’s AcSELerator
- Is Microsoft’s Attack Surface Analyzer a useful tool to analyze this electric power software?
These configuration relay applications can be great attack vectors. They are installed on engineering laptops that often connect to a variety of networks, ICS, corporate, even the Internet. Mike shows a real world example of an engineering laptop with Skype and other interesting apps.
The Attack Surface Analyzer found a lot of useful data … unsigned code, no DEP or ASLR on 75% of the software, installed software (including exe’s and dll’s) in world writeable directories, and more. ICS vendors could definitely benefit from using this tool. Owner/operators can use this to get some idea of the quality of a vendor’s SDL.
|
Subscribe:  
Schneider Has Not Removed Modicon FTP Backdoor Account In
2378 days
Worth Reading
The connection to twitter has returned an error. Please try again later.
|
