Phishing attacks accounted for the highest number of cyber security incidents in 2012, and it looks like 2013 is off to a great start. Check out the little gift that showed up in my inbox this morning...

First Phish of the New Year

If you ever receive an email that asks you to click on a link, or open an attachment, take a step back and read all of the details involved in the email first to make sure that it seems right. For me this one was an easy one to detect because I do not have any IT Services or inboxes hosted in Sweden (the .se domain extension on the email source).  Even if the content of the email seems right and appropriate, I would take an additional precaution and go to the root domain of the source of the email to see if the domain is even a legitimate web site. So for this one, I went to www.svenskakyrkan.se (mostly out of curiousity), and found that the site did not exist.

Okay, so I'm now 2 out of 2, and know for sure that this is a phishing campaign to attract unknowing victims to click on the email.  Lastly, if you are a brave soul, you could spin up a Virtual Machine, and actually click on the link.. start up a debugger, open up a bag of popcorn, and sit back and enjoy the entertainment, as the malware hooks into the operating system of your virtual machine and begins to phone home back to the owner of the site, who now has remote control of your computer. I'm not saying that this is what the link in this phishing campaign does, but many like this one are deisgned to allow a remote attacker to have control of your computer.

So not even 3 days into the New Year, the nets are being cast, he botnet armies are swarming, malware is rampant, and it is appearant to me that 2013 will be another fun ride in the world of cyber security. Brace yourself folks, it's going to be a fun ride.

Best Wishes for the New Year!

Jonathan

I received an email that at first glance appeared to come from Delta Airlines. (See the image attached to this article).

Since I do travel a lot, I was thinking that maybe this was a mistake because I don't normally travel on Delta. The body of the message also indicated travel out of Riverside, which was not far from where I was working yesterday.

The following things looked strange to me:

1. The creator/sender of this email had captured the location from my ISP (Internet Service Provider), and used a script to automatically write into the body of the email the closest airport as a way to get me interested in clicking on the attachment. I did not have plans to travel out of that airport, but I was still curious in case Delta had made an error somehow.

2. When I looked at the attachment, it was not an eTicket or even a PDF file, it was a .ZIP file, which is a container for files inside of it.

3. Upon further inspection, the actual email address domain was not @delta.com but something close @deltaa.com - there was an extra "a" in the domain name. Anyone could have registered that domain name to send out legitimate email from a legitimate domain source (no DNS spoofing required), and the domain name was close enough to fool someone that did not take the time to look closely at the domain name.

4. At this point, my spidy senses were on alert, and I was about 99% sure that this was a malicious phishing attack, but I wanted to check out that .zip file.  I carefully copied the .ZIP file into a clean sandbox VM (virtual machine) environment, and expanded its contents. The internal file that the .zip container was holding was a .EXE executable file and it was definitely malicious.

You see, several years ago hackers used to try clever ways to bypass firewalls or overwhelm system resources, but these tactics eventually were detected, logs of their attempts alerted system administrators, and defenses were built to keep them outside of the network. Many in the offensive community determined quickly that since firewalls allow certain types of traffic through as part of the normal process of doing business, an easier way to compromise a system is to slip a malicious file or malware through existing open channels, like email, web, or other known legitimate business traffic. Now all they needed to do was to have a human on the other end click on their bait to essentially digitally invite them into the network.

This email that I received was what I would call a Location-Based Phishing Attack with a Malware Dropper. It used my location to automatically craft an email with the closest airport, it used a legitimate domain name so as to ensure not to get labeled as junk mail or blocked as a domain spoofing attack, and it used a dropper (.zip file container) to drop a malicious executable onto the victim's machine. The .EXE automatically installs itself as a rootkit, thus inviting or allowing the attacker to connect to the compromised computer through the firewall. The dropper file essentially beacons outbound through approved firewall ports to one or more C&C (command and control) servers on the Internet that allows the attacker to have remote control of the computer.

Now this attack was definitely clever, and could have been successful on me had I not noticed a few things that seemed out of place. If I had my black hat on though, I would have made this attack even more deadly by using a compromised PDF file that looked like a boarding ticket instead of a zip file. Most people happily click on PDF documents every day.

Hope this example that happened to me can be a lesson for all of us to be careful of what we click on. Please pass along this link to coworkers, friends, and family.

I know this month overlaps with Breast Cancer Awareness month, but I don't think my laptop would be happy with a pink cover on it.

Happy Cybersecurity Awareness Month, and practice safe computing!
Jonathan

Hope these comments / thoughts can help you determine if your organization has those above four areas of cyber security covered!

Jonathan

While some have called this the most complex malware framework since Stuxnet, in my opinion, Flame is just the next logical evolution for similar IP-stealing threats we have seen for the past 18 months.

Although Flame does not appear to have been written to specifically harm SCADA and Industrial Control Systems, it does reinforce the need for strong perimeter protection and situational awareness.  Since Flame is targeting corporate IT environments, those organizations that still have their SCADA and Industrial Control Systems directly on their Corporate IT networks will have the most difficult time in protecting their SCADA / ICS components.

We are often asked by our clients what small security investments would pay off the greatest amount in terms of a more secure environment. Implementing a strong perimeter between the corporate IT and SCADA networks will block about 95% of typical IT threats. If we assume that most major corporations have or will be hacked at some point in their lifecycle, we should backup that strong SCADA defense perimeter with detective capabilities. In our field assessments, we have seen an unfortunate trend that most organizations do not have the technology or processes in place to detect when they have been compromised. Monitoring basic network statistics like the amount of traffic (bytes) sent and received by each switch port and trunk can provide a clue when information is being stolen right through the firewall.

Ask yourself and others within your company if you believe that your organization can currently deflect stealthy network attacks like Flame. Then ask the next question... Can you detect if you have been compromised? Start asking the tough questions - that is the only way we can collectively increase our level of security.

Jonathan

The other basecamp exploit modules released yesterday are:

1. Modiconstop – Stops a Schneider Modicon Quantum PLC from operating. It is another command that lacks authentication or other security, and its only one packet to send to stop the CPU.

2. Ged20tftpbo – A buffer overflow of the tftp service on the GE D20 PLC. Note that other GE D20 Metasploit modules had been released earlier in Project Basecamp including modules that allow remote control and recover all user credentials.

More information can be found at the Dark Reading site.

While it is nice to have the ability to demonstrate how easy it is to subvert PLCs, RTUs, and embedded control system devices, I struggle with how asset owners will be able to react to this to quickly close the risk associated with releasing this capability into the public domain. It is one thing to show this in a training class or security conference for effect or to raise awareness, but it is another thing to release the capability to anyone with an Internet connection and latest BackTrack release.

One thing that we all agree with is that keeping one's head in the sand is no longer an option for those tasked with securing SCADA and Industrial Control Systems. The spotlight has shifted from IT Enterprise systems to SCADA systems, and new SCADA vulnerabilities are cropping up like weeds in a summer garden. It is going to get worse before it gets better. 

If you cannot answer this question, now is the time to implement the next wave of security solutions that can provide you with the second half of a sound cyber security program. We recently provided a 4-hour workshop on Incident Management for SCADA and Industrial Control Systems for UTC and NERC, and we have uploaded the PDF for this workshop to our website under the "Presentations" link. Once you register with our site, you can access it here. Don't worry, we never send out any emails to our registered users, and we protect the privacy of our users.  We hope this is a helpful briefing, and contact us if you would like more information about assessing the security of your SCADA and Industrial Control Systems.

Thanks,
Jonathan

Now that you have watched the video, we can speak on the same page. The next knee-jerk reaction that some asset owners have is to look at the list of devices that were involved in the project, then compare those devices to their inventory, and then say... "Man... I'm glad we are not running any of those PLCs". Avoid that reaction. We have worked with a large number of embedded automation controllers and RTUs, and we can safely say that all have major cyber security issues.

The security vulnerabilities that are explained in this disclosure are systemic across almost all embedded devices used in SCADA and Industrial Control Systems. The next negative reaction that most have is to blame Digital Bond or blame the control system vendors. Neither of these two groups can really do anything today or tomorrow that can protect your system. Even if you nag your control system vendor for them to patch the problems discovered in the basecamp project, and they listen to you and repair these issues, more vulnerabilities will just crop up later. Yes, the long term strategy is to get the control system vendors to create hardened and secure devices from the factory, but that is a very long term strategy that will not address all of the millions of vulnerable devices already installed today or being installed tomorrow.

If your field controller is connected to an ethernet network using TCP/IP based protocols, just go ahead and assume that any of the vulnerabilities mentioned in the S4 video are potential security issues with your devices as well. We have seen PLC devices from major control system vendors that freeze or reboot just by sending them a flood of ping requests or by simply scanning them with NMAP or NESSUS. There are several documented examples of PLCs failing because a local printer ran out of ink and flooded the local control network with SNMP packets. So if these devices fail under simple network broadcast storms, it is easy to see how much mischief you can cause to these devices if you actually spend some time to send specifc attacks to these systems.

The point of this discussion is that with or without the recent Basecamp project disclosures, if your field devices are connected over an ethernet network, you are and have already been exposed to cyber risks to your automation or control system performance. Attackers do not need to be physically present on your control network for these vulnerabilities to work, since they can be routed into the control system from other networks, or become activated from a script or batch file on a USB stick. Air-gapped networks are not safe either.

So what do you do about this? Knowing is half the battle, and some will say that getting funding to fix the problems once you know about them is the other half. That is an entirely different topic, but assuming that you have the backing and support to actually make changes to your system and secure it, here are some steps to think about.

6 Steps to Securing Access to Ethernet-Connected PLCs and Field Devices

1. Flush out the logical data flow and architecture - Dive into the weeds and understand your control system in-depth. Build an accurate depiction of how the your PLC and field devices are connected back through the telemetry, LAN/WAN infrastructure, and back up through to your control room HMI and I/O servers. Ensure that everything is documented well, including the IP addresses of all major system components. If you need to, setup a laptop, run Wireshark or TCPDUMP, and capture actual SCADA protocol commands on the network to understand the full route from the control room out to the field devices. Try running tracroute to document all of the hops along the way. Knowing the logical data flows from the plant floor or field systems back to the control room is a great first step.

2. Determine what TCP or UDP ports are required to be open on your PLCs and field devices - This is not only a requirement for utilities that must map out their ports and services for NERC CIP compliance, but is also equally important for all critical infrastructure sectors. You can not adequately secure something when you do not completely understand its attack surface. For instance, if you are running a Rockwell Automation controller, and it uses ports 23, 80, 443, and 2222, you probably do not need the lower ports to be open to the controller, since the protocol operates over 2222. You can block all of the other non-essential ports. If you do not have this information, take a spare PLC off the shelf and scan all TCP and UDP ports to determine what ones answer back. You can also sniff the network while it is in use. Knowing how the devices are connected together (obtained from step 1 above), and then armed with what ports need to be open are the first two steps.

3. Next determine what source and destination IP addresses are used for PLC communications - This step may be a bit easier, since there should be only a finite number of computers that are required to poll the PLC network. In most SCADA systems, this number is less than 10. Do your homework to determine what computers really need to communicate with the controller network, and then conversely, what field devices are required to receive and answer back to these commands. Build a model in Excel using one column to show the list of computers that are communicating, then the next column to show the TCP or UDP ports that are used, then lastly a third column showing the devices that are the destination for the SCADA commands. This is not only an excellent troubleshooting tool for how the ethernet-based SCADA system functions at the PLC level, but can also be used to help secure or lock down the network.

4. Enable Access Control Lists (ACLs) between the computers in the SCADA system and the embedded devices in the SCADA system.  The computers in the SCADA system, such as operator consoles, engineering workstations, data historians, and special-use application computers all typically run on modern fat operating systems like windows or *nix systems. These need a large number of TCP and UDP ports to be open for them to function on the network. The embedded devices do not require the same ports to be open, so you can innoculate your field devices from being vulnerable to viruses, worms, and malware that affect your computers by simply blocking all non-essential ports. This way a virus would have to be written specifically for your field device in order for it to affect your control system. Create additional access controls that limit what source addresses can send packets into the control network. This can also help greatly reduce the attack surface by reducing the potential computers that have digital access to the ethernet-connected field devices. After this step, there should only be a limited number of computers that can access your field devices. If you can not introduce ACLs between your SCADA operations computers and the field devices, then at a minimum, back up to the firewall or DMZ that sits between the SCADA environment and the corporate IT or other networks. At a minimum, access controls should be placed at this level.

5. Enable Application Control, HIPS, or Application Whitelisting in those computers that can communicate with the field devices. If you remember, the Stuxnet attack did not directly infect the Siemens PLCs, but rather first infected a computer workstation that already had ethernet access to the PLC network. The engineering workstations were used as a weapon to deliver the Stuxnet malicious PLC logic to the PLCs. Now, because of the above 4 steps, you are aware of the finite number of computers that have the ability to communicate with the field devices using TCP/IP SCADA protocols. These computers should have end-point security on them, and we STRONGLY suggest application whitelisting. Application whitelisting can essentially freeze the computer systems that have access to the PLCs so that only those approved applications can run and execute on those computers. Any new code that is introduced to the system that is not already whitelisted will be blocked and will not execute.

6. Detection compliments active defense techniques - Now if you have gone through all of the above 5 steps, you should feel fairly good about how the system is locked down. The work is not done just yet. You have to assume that active defenses will eventually fail, and there should be a way to detect when you may be under an attack. Implementing both network and host-based IDS products can help alert you when packets are dropped at the perimeter that was intended for your field devices. Now that you know the TCP or UDP ports that your controllers are using, and their destination IP addresses, you can pull in the switch or firewall logs into a SEM product, and have it alert you when any network traffic was intended for any of your field devices or attempted to utilize their protocol ports, especially if it came from a non-approved source address. Parsing logs from the network devices is a great way to obtain situational awareness. To compliment that further, you can also add an IDS solution to the infrastructure and either write or obtain IDS siguatures for known control system vulnerabilities.

There are additional measures for protecting access to ethernet-connected PLCs and field devices, so this is in no way a complete list. It does provide some helpful tips and actionable things that most control system admins can do with their system to prevent accidental or intentional abuse of ethernet-connected embedded devices.

The main things that I took away from the basecamp PLC disclosures are:

- Almost all ethernet-connected field devices are vulnerable
- You can not secure your environment unless you understand how it works down to the device level
- Place as many access controls in front of the PLC devices as possible to reduce the attack surface
- Block all unnecessary devices and TCP/UDP ports so that only essential traffic is allowed
- Implement strong end-point security on the remaining computers that are allowed to communicate with the PLC devices
- Ensure to extract logs and meaningful security context off of network and host devices to detect abnormal or malicious behavior on the PLC network

Hope my comments in this briefing help illuminate the real issues surrounding the Basecamp PLC disclosures, and provide practical tips for PLC administrators to consider when securing or locking down the PLC network.

Thanks,
Jonathan

The presentation and demonstration was a moment of awakening for many in the audiance that were not aware of how prevalent embedded devices are in our society, or how they can be utilized in ways the manufacturer did not intend. 

• There has only been a few infections to-date
• It does not self-propigate or spread like Stuxnet did, so the victums have to be selectively targeted
• Unlike the initial perception, it does not seem to target control system equipment or vendors
• The attackers are using Duku to look for information, such as blueprints, design documents, and any information that can potentially be used to create a future attack on an industrial facility
• Some of the executables used within the Duku framework shares code with Stuxnet and appears to have been compiled after Stuxnet was discovered
• The malware is designed to self-desctruct after 36 days
• Duku may have other variants that are not currently detectable by Antivirus
• Seems to leverage C&C servers based in India
  
  

Steps asset owners should consider to avoid infection:

• update all AV signatures
• tighten up host prevention strategies and consider application whitelisting technology
• review all ports open on perimeter devices such as firewalls and reduce the attack surface by closing off unnecessary ports on network devices upstream of critical SCADA or DCS systems
• isolate control system elements from the corporate IT networks as much as possible
• operate at a higher treat level and review logs on an increased periodic basis
• monitor sensitive SCADA and DCS hosts for new and unusual services that are not traditionally running on those devices
• enable verbose logging on all host systems, and forward the logs to a centralized SEM or SIEM
• monitor hosts for new files added to system directories such as system32, and system32\drivers
• monitor outgoing traffic leaving the network to unknown destination IP address
• place a sniffer on the external side of the firewall and record traffic for 24 hours, then parse the data and cross check the IP addresses in the PCAP files to see if the traffic contains any IP addresses for known C&C servernet and botnets
• also monitor the dirty side of the firewall for spikes in traffic

Hope this briefing provides helpful insight as to how Duku works, and the migitation efforts that can reduce the chance of getting infected.

thanks,
Jonathan