April 2, 2015

Stateful firewalls are very common these days. In a nutshell all traffic initiated from the inside is allowed out and the return packets of a TCP session which has been initiated from the inside are allowed back in. Any other outbound to inbound communication needs an explicit rule on the firewall. So far, so good.

However, what happens if an attacker can compromise any open service on a server which is open at the Firewall? A classic here is port 80, as Web servers need to be accessible, right?

Here is a little case study from a recent Pentest. It was a relatively small company with an ASA 5505 perimeter firewall. Pretty much locked down from the outside except for port 80. No DMZ was in place but an in-house intranet portal was exposed on purpose to the outside world. That web server had a serious flaw and we were able to exploit it without much hassle. We have then uploaded the so-called mad leets script to the document root of that web server and then accessed the mad leets php file through a Web browser.

Mad Leets is an evil script as it allows control over the machine by moving all traffic through port 80.

What could have been done proactively to prevent such an attack? Well 2 things spring to mind.

  • Deep Packet inspection aka Web Application Firewall
  • Outbound connection filtering on the ASA

Many clients still struggle to understand that attacks are often tunnelled through legitimate open ports such as 80, 22, 110 etc. Only inspecting within the protocol may detect malicious behaviour. Of course port 80 must be open, but it’s vital to check what’s transmitted over that port.

Secondly, once an internal machine behind a stateful Firewall has been compromised by any means (remote exploit, social engineering USB stick etc.) the attack is usually stopped nowhere as the stateful Firewall will natively trust inside or DMZ hosts going out. We find that more than 90% of all Firewalls we assess don’t do outbound filtering at all. The reverse shell concept isn’t anything new but current architectures allow for those compromises unfortunately.

We strongly advice to inspect traffic with Web Application Firewalls and/or IPS systems and in addition run through potential what/if scenarios and how a compromised inside host could expose services to an attacker.