Corelan Cybersecurity Research

Kyle Wilhoit, Threat researcher at Trend Micro, explains that he will provide an overview of ICS systems before looking at some interesting attacks at ICS systems.

Concerns/Overview of ICS Security and Typical deployments

ICS devices are used in production of virtually anything. They are used in water/gas/energy/automobile/manufacturing, etc.  They are notoriously insecure in many ways.  Software is sometimes embedded, sometimes not. ICS devices are typically proprietary, specific to the vendor.

A typical ICS deployment contains a supervisory network (SCADA network) and one or multiple control systems.  The supervisory network communicates with the control systems.  Traditional deployments usually don’t contain any security layers.

Overview of 2 SCADA protocols

DNP3 is a complex protocol, used to send and receive messages.  There is no authentication or encryption and have several published vulnerabilities.

Modbus is the oldest ICS protocol, which mostly controls I/O interfaces. No authentication or encryption, no broadcast suppression and has multiple vulnerabilities.

Typically, priorities for ICS are productively, up-time and reliability of data.  IT is concerned about protecting the data, communications and limiting the number of interruptions.

In 2012, 171 unique vulnerabilities affecting ICS products were reported, affecting 55 vendors.  26% of these devices revolve around internet-facing devices.

Scada on the internet

It has proven to be trivial to find ICS systems using Shodan. Example searches include “VxWorks” and “Meter Information”.  Of course, this only gets you the systems that are internet facing, not just the ones that are vulnerable.  You can find other systems by querying paste bin, ERIPP and Twitter.  In short, there a multiple ways to find Scada systems exposed to the entire world.

Story time

“Small town in rural America, has a water pump controlling system, which is internet facing.  During Q3/Q4 of 2012, it has been attacked multiple times.”   Kyle introduces the fact that he has set up an ICS honeypot in his basement that looks like a water pump controlling system to gather information about real attacks.

His honeypot consists of 2 low interaction systems and one high-interaction system (using real devices), deployed on a Windows 2008 server and 2 Ubuntu servers.  It ran for 28 days in total.  On the internet facing UI, he included very clear messages that a system compromise might adversly affect water containment.

The external IP of the honeypot exposes a “Control System”, which uses a PLC in the back-end, simulating a water pump system.  The high-interaction honeypot consists of a couple of machines (combination of physical systems and Amazon EC2 instances), simulating a control system, a Nano-10 PLC, a Siemens Simatic S7-1200 system, and a separate workstation that contained “salted” docs.  He also used Honeywall and generated real DNP3 and Modbus traffic on the network.

To make things look real, he registered a domain name that references the name of the city where he set up the honeypot, to make it look like this is the city water containment system.

To make the system vulnerable, he used a set of vulnerabilities:

• SNMP vulnerabilities, allowing read/write
• Authentication limitations (admin/admin username & password, default username&password configs for control devices, etc)
• Limits of Modbus/DNP3 authentication/encryption
• VxWords vulnerability (FTP)
• Open access for certain ICS modifications (fan speed, temperature and utilization)

During his test, he decided to only track of

• Real targeted attacks
• Modifications of the pump system (FTP/Telnet/…)
• Attempted modifications via Modbus/DNP3
• DoS/DDoS

Attacks

Based on the gathered statistics, he discover that

17 attacks originated from China, 9 came from the US, 6 from Laos, 4 from the UK, and some individual attacks from a variety of countries (North Korea, Chile, Palestine, Vietnam, Poland, Brazil, Japan, the Netherlands).

Attacks included:

• 2 VxWorks exploitation attempts
• 12 Attempts to shut down the system
• 7 attempts to modify the temperate output
• 5 attempts to modify the pump pressure
• 9 attempts to access a secured area
• 2 attempts to modify traffic
• 6 attempts to modify the CPU fan speed.

He was able to detect some of these attacks using Digital Bond’s Quickdraw Scada Snort rules and created some custom snort rules as well.  One of the interesting facts was that he didn’t see any DNP3 traffic based attacks, probably because of the complexity of the protocol.

Kyle continues by explaining that he also set up a mailbox using the same ‘fake’ domain name and noticed that one of the attacker actually sent a spear phishing email to the mailbox, which contained the name the real city administrator for the system. In other words, the attacker did some recon, figured out who the real admin was and used the email address found on the honeypot website to attack that person.  The email contained a kind request for the person to fill out a survey and included a CityRequest.docx file. Of course, this document contains an exploit that infects the machine with malware.

Kyle analysed the malware and noticed that it exploits CVE-2012-0158 and connects to a C&C server in China.  After 5 days, files started leaving the infected machined. Further analysis shows that the malware monitors reg keys for value changes, creates guard pages, dropped PE files, communicates with C2 IP’s, creates files, creates fake documents and opens it.

Attacker profile

Who’s attacking the ICS system?  One of the C2 serves was wide open, so Kyle hopped onto the server and could see the documents that were pulled from his own ICS server.  The malware used seemed to be co-reused and the attacks seemed to be targeted, but it’s unclear what the motivation was for the attack.  There was some reconnaissance activity on the infected system, attempts were made to damage the system, data was stolen, and a persistent backdoor was placed.

Recommendations

• Disable internet access to your trusted resources, where possible
• Maintain your trusted resources at the latest patch levels and ensure you are diligent in monitoring when new patches/fixes are released
• Require username/password (two-factor if possible) combinations for all systems, including those are not deemed “trusted”
• Control contractor-access. Many SCADA/ICS networks utilise remote contractors and controlling how they access trusted resources in imperative.
• Use SSL/TLS for communications to web-based ICS/SCADA systems
• Control access to trusted devices. Use a bastion host with ACLs for ingres/egress access. Segment your network
• Improve logging on trusted environments, in addition to passing logs to SIEM devices for third party backup/analysis
• Utilize zones such as “BLAN”, “WLAN” and SCADA
• Develop a threat modelling system to your organisation, understand who’s attacking you and why.

Remember: These attacks are happening… today.

© 2013, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Similar/Related posts:

BlackHatEU2013 – Day2 – DropSmack: How cloud synchronization services render your corporate firewall worthless BlackHatEU2013 – Day2 – The Sandbox Roulette: Are you ready to ramble BlackHatEU2013 – Day2 – Advanced Heap Manipulation in Windows 8 BlackHatEU2013 – Day1 – Hacking Appliances BlackHatEU2013 – Day1 – Practical Attacks against MDM solutions