Scanning an Internal Network Through A Firewall

OK - so this post's a quickie because a) the last 2 posts have totaled nearly 12 pages of source material and I need to focus on the new novel this weekend and b) it's so early on a Saturday morning that I've yet to grab a mug of "Jamaica Me Crazy" coffee yet. Thoughts aren't quite as coherent without Java. 

So here goes:

I stumbled across these posts this morning and while I haven't yet had time to try it, the write up seems solid.

According to this article, there are 2 new ways to implement an Idle scan (or variations of an Idle scan) in order to enumerate targets ON THE INSIDE of a firewall. This means that we, the attacker, don't have to be able to route to the victim/target in order to enumerate ports. The zombie we pick is the one that has to route, so in some cases, that can be the firewall or outlying router itself.

Are the terms "zombie" and "victim" not all that familiar to you? Don't quite remember what an "Idle scan" is? No problem.

Get caught up on traditional Idle scans here: http://www.networkuptime.com/nmap/page3-16.shtml

Then, check out this white paper detailing the 2 new ways to Idle scan here: http://people.csail.mit.edu/costan/readings/usenix_papers/Ensafi.pdf

And, just in case your head is spinning from that and you need the breakdown, check out this blog entry (http://www.malwarecity.com/community/index.php?app=blog&module=display&section=blog&blogid=23&showentry=7600) where MalwareCity has taken the time to explain them. 

Personally, I think scan #2 (SYN cache scan) is the way to go because the first option is dependent on having a FreeBSD box in the victim/target's DMZ or at least in the victim/target's external IP space. Chances of that are not exactly tiny, but they are limited. And why limit yourself when you have the option to use the SYN cache scan?

Browbeating Web Apps W/Their Own Javascript

We’ve talked a bit about reconnaissance, NMAP and SQL Injection. But sometimes, our jobs aren’t strictly limited to demonstrating how vulnerable an application is to known exploits. Sometimes, we get the chance to demonstrate how vulnerable a web application is just by existing.

An administrator or developer can put in defense after defense and make it so we have to jump hoops in order to get to known exploits and that’s good. Defense-in-depth is a great concept and it should be used as a building block of any sound security plan. However, if we can develop an understanding of how an application works well enough (and I mean mind-melding like Spock with that rock creature—you know, the one with the silicon eggs *shudder* ), if we can really get to know an app and understand the code in front of us in a web page, then we should be able to test its security without some of the tools we’ve talked about before.

I’m going to demonstrate how, with the help of a web proxy, we can manipulate an application’s code so much so that we can see information we weren’t supposed to see, gain administrative privileges, even dump a database.

Now, all you critics out there, these are extremely basic examples of how to manipulate javascript and HTML to get us escalated access to data. These are not meant to be elaborate examples, by any means and they aren’t.

But they should serve as a great stepping stone for your education and give you a place to start to learn how to do this.

Ready to begin?

The Web Application

The following examples, while simplistic of nature, are real. They have been found out in the field. I can’t divulge where, but I can divulge how to exploit these loops of logic.

Javascript in the URL bar

Now, there are a couple of different ways to skin this particular cat. Some people would take the resulting URL from this particular manipulation and just copy and paste it into a new browser window and change the URL. This is ordinarily a fine idea. However, SOMEtimes you find a sneaky programmer who has figured out that they need to deny direct URL access if it wasn’t the result of a Javascript call. So, the only way to do this particular trick is by manipulating the javascript that we are given in the first place.

First, we log into our Web Application (a management portal, for this particular example) and we are presented with this screen:

Trying SQL Injection on Your Own

Hey, if after our last couple of posts, you feel like your SQL fu is up to snuff and want to get your hands on a real vulnerable web app that maybe doesn't have the answers all leaked out, then check this out.

Head on over to  http://csis.pace.edu/~lchen/sweet and download the vulnerable app they're hosting in VM or Virtualbox format. Stand up that server and follow these two guides, 5 - Security Testing and 6 - Vulnerability Management .

The Ubuntu web server is running BadStore, which you can alternately register for and download here: http://www.badstore.net  Either way, you're going to be able to run SQL Injection and XSS vulns against this web app and database.

Try it out!

Manual SQL Injection without Tools

Last post, we stood up a VM with Damn Vulnerable Web App and used an automated tool, sqlmap, to audit the vulnerable URL and gather up data for us from the database that we ordinarily shouldn't be privy to.

 

This time around, I wanted to talk about basic SQL queries and how they are used in legitimate applications. And then later on, I wanted to build on this to demonstrate to you, the reader, what we can do without automated tools. We'll roll up our sleeves and grab a wrench and jam it into a keyhole to gather data from the database.

One thing I feel I must get off my chest: A lot of people want to learn how to hack. And the simple fact of the matter is: you can't. You can't learn to hack anything. The reason there are great hackers out there is because they became such experts in a particular topic or topics that they knew every which way to use, abuse, torture and amuse a system. If you check out Darknet's site, they've posted their motto: “Don't Learn to HACK – Hack to LEARN”. This is the truest statement I can offer you, the reader. In order to be one of the best hackers, you need to know everything you can about a subject. Will you ever know everything about that subject? Unlikely. I consider myself a UNIX/Linux expert and I learn something new nearly every day. (Albeit, I learn mostly because I've pounded the keyboard and found some new key combo I never knew existed till I got mad but whatcha gonna do? :) )

I don't expect you to become an expert overnight but hopefully this introduction will solidify a few database concepts for you about how legitimate SQL queries help lead to SQL Injection.

Ready to begin?

SQL Queries – Building the SQL Database

To demonstrate to you how SQL queries work, I thought it would be best to illustrate some simple queries first.

To do this, we'll need a mysql server and a mysql client. Luckily, if we're using Ubuntu, these utilities are never far away. Run the following command to install mysql and then we'll start creating databases.

sudo apt-get install mysql-server mysql-client-core-5.1

During install, you may be asked to provide a password for the root user to access the database. Don't use your normal password or the password you used to set up root's account in the OS, if you've done that. Just set up a fairly secure password that you'll remember later. Why? Cuz you'll need it. Trust me.

Once you're installed, go ahead and connect to the mysql server by issuing the following command at the command prompt:

user@workstation:~$ mysql -h localhost -u root -p

Enter password:

… (you will be brought to a mysql prompt like so)

mysql>

Sqlmap Introduction – SQL Injection Walkthrough

In prior posts, we've discussed performing reconnaissance work on targets. We've talked about using FOCA, Maltego and other tools (including some that simply query how the Internet works) and how to gather information from targets about them.

Starting today, we're going to discuss the practical application of some more technical tools. Tools that will provide for us information on targets that will help us determine what our attack vector is going to be for that target.

In this particular write up, we're going to explore the specifics of finding a web application and determining if it's vulnerable through SQL injection. Once we determine that it is, indeed, vulnerable, we're going to use an automated tool called “sqlmap” to help us gather data from the database. I think it's important to also discuss how to manually get to the same point, but that's for another blog post. We'll follow up and show you manual SQL injection in our next post.

So you can follow along at home, let's talk a little about what I've got set up in my lab and where to get the software I'm using.

Setting Up The Lab – Vulnerable Web Application

Now, in order to test a web application for vulnerabilities, you're going to need to deploy a vulnerable web application.

Come back to this blog when you've written up a nice PHP/mysql web application that is chock full of vulnerabilities for us to exploit. Go on, I'll wait.

What's that? You don't feel like writing your own web application just so you can test it later? Fine.

Lucky for us, there are plenty of folks who have done just that so that we don't have to. The Internet has dozens of bootable Linux distributions out in the world that provide for us, the security researcher, the hacker, call-us-what-you-will, an environment that contains vulnerable applications. All we need to do is grab one, boot it up and start testing away.

For my lab, I settled on “Damn Vulnerable Web Application”, which you can find more info on at their web site (http://www.dvwa.co.uk/) and you can download an ISO file of the bootable web app here: (http://www.dvwa.co.uk/DVWA-1.0.7.iso).

You can either burn that ISO file to CD and boot up a physical host or you can create a Virtual Machine in either VMWare Player or VirtualBox and have it boot up that way. In either virtual machine software, you can create a machine with a handful of RAM (say 512 or 1GB) and no hard disk. And then define it to use the ISO file you downloaded for boot. Then you've got a Virtual Machine that's booting a CD/DVD (LiveCD).

Once you've got that set up and running, make sure you know what IP address the machine is (so you know what target you're supposed to be hitting) and then it's to start scanning!