ZioMatrix

Website pen testing?

9 posts in this topic

Hey guys, pretty new to this kind of thing. I wonder what i need to look for when pen-testing a website. Such as, what vulnerabilities, code flaws and such. Also what tools would you use?

Edited by ZioMatrix
0

Share this post


Link to post
Share on other sites

Welcome to our world.

For starters, lets take a step back and realize a few things. Web sites run on servers, servers run daemons (like Apache or IIS), and daemons run web applications. So, when pen testing a site, it is different than pen-testing a network, and different than pen-testing a server. However, it is good to point out, that by compromising the web application layer sometimes the server can be compromised, and sometimes by compromising the server, the web application layer can be compromised.

Another few steps back. Many web sites run web applications for the purpose of dynamic content. Usually this would include an SQL (sequential query language) database backend of some sort, and web applications (like forums, talkboards, content management systems, and blogs) are generally written in (but not limited to) php, python, perl, ASP, ASPX (.NET 2.0), ruby, or CGI.

As far as what tools to use, nikto and nmap are good for web application and server scanning, respectively. Some strings that I use (with the example : target.net) are as follows :

user@host# nmap -sS -A -sV -O -P0 --defeat-rst-ratelimit target.net
user@host# ./nikto.pl -evasion 9 -host target.net

Nmap is a good tool for mapping out what daemons are running on the server. This is important, because each daemon could be a chink in the armor of the site. Command injection, buffer overflows, and null-byte/escape string vulnerabilities may plague any of these daemons and so generally after scanning a machine and getting a decent version print I try to google for vulnerabilities in any/all of the running daemons unless I know one off of the top of my head. Keep in mind that if target.net is running an application called "Port Sentry", nmap may come back thinking that every port is open. If this is the case, you may want to try running:

user@host# nmap -sS -A -sV -O -P0 -T paranoid --defeat-rst-ratelimit target.net

or even

user@host# nmap -sX -A -sV -O -P0 -T paranoid --defeat-rst-ratelimit target.net

As it stands, nikto does a great job mentioning CVE references for any vulnerabilities it discovers. Just remember that sometimes you can get a lot of false positives. If nikto doesn't mention a URL for a reference but lists a CVE reference, just ask google about it. :)

As far as common vulnerabilities, the most common that I have run across aside from the aforementioned server errors are web application vulnerabilities. Normally, the most common of these vulnerabilities are Cross Site Scripting (XSS) and SQL injection.

Generally speaking, these vulnerabilities arise from improper error handling, for example, say we are testing target.net and they have an articles.php page. We visit

http://target.net/articles.php?ID=23&title=Hello%20World

and we can see the 23rd article inside of the SQL backend. Now lets look over what a vulnerable PHP/SQL query would look like in this scenario:

<?php
$query="SELECT body FROM articles WHERE articleid=".mysql_real_escape_string($_GET['id']);
?>

This code is vulnerable because an attacker can change the url to :

http://target.net/articles.php?ID=23%20AND...e=Hello%20World

and the page will still display, however when the attacker changes the url to :

http://target.net/articles.php?ID=23%20AND...e=Hello%20World

The body of the article will no longer display. This is called "blind sql injection" because we are not being given an error from the SQL server. The SQL injection vector is considered "Improper Type Handling" or an "Integral Handling Error". Even though mysql_real_escape_string() is being used to sanitize user input, because we are dealing with an integer in the database and the $id variable is not being wrapped in quotes, the attacker does not need to use the %27 (') escape string to inject SQL code.

So in stead of the above scenario, staying with SQL injection, lets say that the code looked like :

<?php
$query="SELECT body FROM articles WHERE articleid='".$_GET['id']."'";
?>

The $id variable is being wrapped in quotes, however mysql_real_escape_string is not being used, so in stead of using the following URLs to verify the site's vulnerability:

http://target.net/articles.php?ID=23%20AND...e=Hello%20World

http://target.net/articles.php?ID=23%20AND...e=Hello%20World

The attacker would use :

http://target.net/articles.php?ID=23%27%20...e=Hello%20World

http://target.net/articles.php?ID=23%27%20...e=Hello%20World

The /* comments out the rest of the query so that the additional ' to close the string is now a comment and does not cause a type mismatch.

Patched SQL/PHP code, or "safe" code, looks as follows :

<?php
$query="SELECT body FROM articles WHERE articleid='".mysql_real_escape_string($_GET['id'])."'";
?>

As well as :

<?php
$query="SELECT body FROM articles WHERE articleid=".intval($_GET['id']);
?>

Now, lets say the attacker or penetration tester, in this case, wants to find out if the site is vulnerable to XSS. Remembering the original URL :

http://target.net/articles.php?ID=23&title=Hello%20World

The penetration tester could visit :

http://target.net/articles.php?ID=23&t...rld%3CIFRAME%3E

If the IFRAME appears by the title, the penetration tester has found a cross-site scripting vulnerability. The %3c is the < sign or opening tag and the %3e is the > or the closing tag. Vulnerable PHP code would look like

<?php
echo($_GET['title']);
?>

whereas patched or "safe" code would look like:

<?php
echo(strip_tags($_GET['title']));
?>

More details of these vulnerabilities are documented on my site (click my sig). Hope this helps.

EDIT : Formatting

Edited by RETN
0

Share this post


Link to post
Share on other sites

Take a look at hellboundhackers.org, it's pretty much the place to go to learn about web-based exploits and vulnerabilities. I also strongly recommend the book "The Web Application Hacker's Handbook". Just be sure that you have a good understanding of web and database programming before you get in to any of this.

Edited by Spyril
0

Share this post


Link to post
Share on other sites

I saw this thread referenced by another...

Tools such as nmap, nikto, etc. generate A LOT of noise. Also, they do all the work for you so you don't learn much (if anything). A true pen test will be one that emulates the real world as much as possible. A good hacker will not generate much noise, thereby flying under the radar. If you take a look at hacker history, the people who have gotten caught were careless. They generated a lot of noise.

The hackers I've learned from do most of their work by hand and are very successful at what they do. They're the ones that haven't been busted.

So, in short, don't use nmap, nikto, etc. Do everything by hand. Besides, you'll learn MUCH more.

0

Share this post


Link to post
Share on other sites
I saw this thread referenced by another...

Tools such as nmap, nikto, etc. generate A LOT of noise. Also, they do all the work for you so you don't learn much (if anything). A true pen test will be one that emulates the real world as much as possible. A good hacker will not generate much noise, thereby flying under the radar. If you take a look at hacker history, the people who have gotten caught were careless. They generated a lot of noise.

The hackers I've learned from do most of their work by hand and are very successful at what they do. They're the ones that haven't been busted.

So, in short, don't use nmap, nikto, etc. Do everything by hand. Besides, you'll learn MUCH more.

If we are pen testing a system would it not make sense to use commercial tools assuming that we are testing our own system. I understand that if we have been hired to pen test someone elses system and we don't want to set of their IDS we would do it by hand.

Also, do you have any good resources tools or books that could help us to learn to pen test without using commercial tools? Would we just scan the different ports manually so that the IDS wont see an automated scan?

0

Share this post


Link to post
Share on other sites

As this thread is about pen-testing, I'd have to say any /authorized/ pen-test is usually /expected/ to set off a few alarms.

Also, not all nmap and nikto scans are loud. I suggest reading the docs to learn about evasion options. For example, on nikto, -evasion 9 will usually hide from network layer IDS systems if the remote host is vulnerable to session splicing. The attack will still be logged, but alarms won't be set off. Not from the network layer anyway. Another trick to hide from the network layer is to simply run scans over HTTPS. Sniffers (except certain IPS systems which are programmed to do an SSL man in the middle) aren't programmed to decrypt the traffic on the fly. A decent system will also rely on a HIDS/HIPS system, which sometimes will be set off and other times won't be.

There are plenty of other options too, and if you're going to say test it manually, how do you justify the amount of time it takes go test all ports? I fail to understand.

Often times the /decent/ black hats (sorry kingospam, but you said "the ones who haven't been busted", so I'm assuming blackhats) don't even scan things by hand; they do a distributed scan from 65,355 botnet nodes, each node testing a single port, then reporting back to the botnet's controller or peer-to-peer with each other until they reach some sort of hub. This technique is also used to evade an application called "Port Sentry", which is what is running on those systems that you scan with nmap which seem to have EVERY port open for some reason.

There are other ways to hide your connections, like out-of-sequence spoofed fin/rst/ack connection closing (if you make it look like the two boxes "hung up", then most sniffers just quit recording the rest of the traffic, similar to the 2600 hz tone, except for computers).

It is possible to pen-test without commercial tools, and as kingospam mentioned, you are oftentimes more successful IF you know what to test by hand. A lot of times you do an automated scan as a preliminary, and then afterwards you check the "fuzzy spots" by hand, things like SQL injection vulnerabilities and other common vulns. Sometimes if nmap returns a version to you, you can simply google up an exploit and use that. Blind fuzzing can be productive as well but very time consuming, but remember that big packetslaps are pretty obvious to NIDS systems.

Books and resources? Not really that I can think of. Maybe hit up some RFC's, learn web applications programming, and perhaps even grab a copy of the shellcoder's handbook. And always remember that the maximum allowable stack size on a little endian processor is limited to 16 megabytes. ;)

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now