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.