Covert Channels and Firewall Egress Rules
If the “holy grail” for an hacker is to execute a vulnerability that allows for the installation of a payload (rootkit) that provides control of a remote system, how do defenders prevent this?
Experience has shown that new vulnerabilities arise at a fairly rapid rate and that there is often a lag between the discovery of a vulnerability and the implementation of counter measures be they; av, ids, ips or patches, which provide a window during which systems are vulnerable. Aside from this window of time, there is always the possibility of an attacker possessing a previously unknown vulnerability, the hallowed “zero day” allowing them to root a system without detection.
Remote control of a system depends on two way communication between the attacker an an infected host. Such communication could prove anomalous allowing for detection of the infection. A savvy attacker, knowing that both incoming and outgoing communications may be monitored by ids/ips sensors may try to hide his communications in innocent looking traffic. The Loki covert channel is an example of such a method, allowing for control shell commands to be passed back and forth in the unused extra space of ICMP pings or UDP dns traffic.
More recently open source projects have emerged, such as HTTP Tunnel and Corkscrew (see the following article for more information on firewall evasion tools) that allow for port forwarded traffic such as ssh tunnels to hide inside of http traffic, effectively thwarting outbound firewall and proxy rules/configurations, if outbound http traffic is allowed. All that can be monitored in this case is the connection’s address and bandwidth usage.
In control system environments two methods could be employed by an attacker. If unfettered http access is allowed from the control system lan to the internet, it becomes trivial for the attacker to now deploy a covert ssh tunnel embedded in http traffic. If http traffic is not allowed to the internet, but is allowed to a corporate intranet, the same scenario could occur to an infected host in the corporate environment that relays (chains) traffic from the agent in the control environment, through the agent in the corporate environment, out to the internet in what appears to be http traffic.
The threat does not solely exist for http traffic as a sufficiently wily attacker could potentially hide outbound communications in any type of allowed protocol, and such an attacker, if they have performed diligent research before launching the attack, may know of standard communications and their associated firewall exceptions for a targeted system.
Effective use of firewall rules becomes imperative in this situation. If http or any other type of communication must be allowed between the control system segment and any other network, be it internal and external, only specific exceptions to firewall rules should be allowed. More specifically this means that systems on the control system lan should only be able to talk to those necessary, and known safe ips on specific ports, that are critical for achieving the mission of the system. All other communication should be blocked. A system on the control system side should not be able to talk to any system on the corporate network (or on a DMZ) except for those very few system for which specific exceptions are warranted. With emphasis on very few.
In this case even if an attacker launches a successful attack it becomes exponentially more difficult to achieve system control as there are no responding systems. Yes the exploit worked and the payload was installed, but it becomes in many ways moot as the payload’s calls to home go effectively no where. Yes it may be still possible to chain agents on the specifically allowed communications through the firewall, but the odds of doing so are astronomically less and the sophistication level of the attack would be out of the realm of most attackers.
Author: Kevin Lackey
Posted: June 2nd, 2008 under Firewall / Perimeter, IDS / IPS, SCADA Architecture.
Comments: 8
Comments
Comment from Matthew Franz
Time: June 2, 2008, 7:20 pm
I think proxies (such as Bluecoat, or even good old Squid) provide a little more flexibility than you describe, because at least within HTTP you can peek into the payload. Of course if you allow 443 out all bets are off. OpenVPN has a very cool proxy tunneling feature that is even better than using ssh with proxytunnel for poking holes through your corporate firewall.
- mdf
Comment from Kevin Lackey
Time: June 2, 2008, 8:14 pm
Matt,
With httptunnel you can port forward an ssh connection to an external connection through http traffic on port 80. Httptunnel encapsulates the encrypted communication in http posts and gets. You can peek at the payload but all you see is encrypted gibberish.
I have played with it and it works pretty well.
Comment from Ralph Langner
Time: June 3, 2008, 7:37 am
Kevin, a good follow-up on “just surfing the web”. One cannot emphasize the importance of proper firewall configuration enough. All too often people feel secure just because they have the piece of hardware in place — through which malicious traffic may be flowing freely and undetected. The worst thing I see happening is a common misconception of equaling VPN with secure.
How about writing a white paper about Internet usage for SCADA environments, similar to the OPC paper.
Comment from Eyal Udassin
Time: June 3, 2008, 11:38 am
Whenever a client asks for a full-blown penetration test, which includes sending malware in emails to employees, we use these methods to evade firewall restrictions. Works flawlessly to date, all across the range - from financial to utility clients.
There are several ways to mitigate this issue - none are bullet proof and we’re currently applying the final touches to a utility to assist in this process.
On a differnet note - Kevin, congrats on joining Digital Bond, I think that you’re recent posts are excellent and assist in the effort of bringing security issues from the “standard” networks to the SCADA domain.
Comment from Kevin Lackey
Time: June 3, 2008, 12:16 pm
Ralph,
I do not know if the topic merits a white paper as my thoughts on the subject can be surmised in one sentence “Internet usage from SCADA environments, do not allow it.”
What scares me to no end is the new generations of PLCs and such which are web server for configuration control enabled, and HMIs that want to talk to the vendor over a web browser for the help system.
Eyal,
I have played with Corkscrew and Httptunnel and both do a very fine job of evading proxies and such, especially httptunnel in very restrictive environments. With the client on the inside and an httptunnel server on the outside I was able to evade detection from all of the IDSs and proxies I tested against, which wasn’t a whole lot, but still. The only way I can see httptunnel not working on a network that allows outward bound http connections is if the ip address of the external server is not allowed by the proxy or firewall.
I also wrote a small rootkit that auto-detected proxies (using a MS supplied api) and tunneled commands and file transfers hidden in http post and gets. It all looked like image file transfers. The actual information was chunked up and encoded, sent in the image get/post data and re-assembled on either side. This also evaded the IDSs and proxies I tested against.
Comment from Marcin Antkiewicz
Time: June 3, 2008, 11:07 pm
Kevin,
in a best case scenario, all traffic traversing ESP (perimeter in NERC-speak) should be scrubbed by a security-proxy. Such proxy should support ACLs on various OSI layers (ip, ports, protocol verbs), and vicious logging/analytics (sic! - I know what lives on control room networks).
The reason for such a dream tool is that http/icmp tunnels should be the least of your worries - they require decently open ruleset, and are decently easy to spot. Problems begin with of the shelf tools, which abuse dns, essentially a low-latency relay:
iodine, nstx, OzymanDNS, dnscat
http://code.kryo.se/iodine/
http://thomer.com/howtos/nstx.html
http://afs.eecs.harvard.edu/~goodell/blossom/tor-via-dns.html
http://tadek.pietraszek.org/projects/DNScat/
smtp has the same design, and it’s abuse has… history
http://www.derkeiler.com/Mailing-Lists/Firewall-Wizards/2003-04/0015.html
tunneling is so popular, that people write frameworks where protocol support comes in form of plugins
http://wiki.freebsd.org/mtund
Now, layer encryption on top of such tools, and allow for some creativity (think simple, but intelligent control - like rxbot), and the need for true security proxies should be obvious.
Comment from Ralph Langner
Time: June 4, 2008, 3:32 pm
Well, at least this would give the term “white paper” a whole new meaning — just a blank page with “don’t use it” in the middle.
Beware, however, that we are facing an industry where major players are advocating insecure design principles and services every day. Be it “open” Industrial Ethernet, OPC, web-enabled PLCs or Internet connectivity from the process network: Vendors are spending big marketing bucks to promote all these things. Now there comes one smart security consultant (or two, three of them) and advises to the contrary. As the average John Doe in the control room, who do you believe? Anyway, I don’t want to press on you, it just occured to me that we don’t have some reference work that we could hand out to clients who think that Internet-enabled SCADA is a good idea.
Comment from Bryan Owen
Time: June 5, 2008, 12:02 pm
The issue of covert channels and egress is not new but this discussion helps highlight exposure from tunneling and proxy services, even within the framework of good network architecture advice.
NIST 800-82,SP99, etc… addresses this topic with perhaps a bit more relaxed posture than “don’t use it”; more of a “if you must” limit attack surface using the mechanisms suggested above.
I wonder tunneling OPC/DCOM has similar characteristics to VPN/SSH/HTTP tunnels?
Write a comment