Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 8 down vote favorite

I am currently studying how to do server pentesting and need some advice/protip related to methology/best practices.

People often mention that it is a good idea to gather intelligence and enumerate all vulnerabilities you are going to verify before moving to exploitation.

I've already done some recon/banner grabbing for the services running on the server, and thinking about building list of vulnerabilities so I cold have some kind of checklist containing vulnerabilities I should try to exploit.

My idea at the moment is to manage this:

  1. by running vulnerability scanners like openvas and nexpose
  2. by doing manual search using services that runs on server in public databases like exploit-db.com and 1337day.com

[1] should give me CVE numbers/other references regarding to the ways I can exploit found vulnerabilities manually. I also should be able to import reports them into metasploit and use metasploit for their exploitation later.

[2] seems to be more effort taking point since I'll have to check multiple databases and grab all they have for all the services I've discovered and then merge this list with vulnerabilities discovered using [1]

After that I am going to try to exploit everything I've found.

So, my questions are: Is the described scenario is a good idea? Maybe I am missing something and there is something I should change in my plan? Maybe there are any other tips you can give me (I am especially interested in ways to ease [2] as much as possible)?

share|improve this question

3 Answers

up vote 5 down vote accepted

Every vulnerablity listed on the CWE-2000 database and the CAPEC-2000 database is a good place to start. This is by no means complete, and these databases are expanding. Sometimes there are vulnerabilities that are clearly a problem that needs to be addressed, but doesn't really fit neatly into the CWE database.

Automation and already discovered vulnerabilities should be looked at, but this probably makes up about 1% of what I do as a pentester.

Burp, grep, Firefox, vi, python, these are the tools you need. (And god damn MS-Word for reporting)

share|improve this answer
Thanks for the tips on CWE and CAPEC. I'll definitely going to check them. However, it seems that both of the lists provide rather abstract description of vulnerablities/attacks, something like design patterns in terms for sw development. While this seems to be very handy during design of exploit/attack I have a feeling that you will try to get maximum from public vulns/exploits before trying to implement your own home-grown exploit/attack. ... – Eugeny Loy Sep 5 '12 at 19:41
... What I am curious about is if, lets say, you'd discovered that your target server runs sshd. Would you delve into protocol/sources analysis and see what you can do or you would try to find (how?) CVEs or other known vulnerabilities first? – Eugeny Loy Sep 5 '12 at 19:42
1  
@leo well namp -sV will give you version information, and then just search the cve database. sshd is probably the least likely to be vulnerable to attack. There is no shortcut for a decade of exploit development, maybe you should try cutting your teeth on an easy project, like some open source php application that is about a year old. – Rook Sep 5 '12 at 20:09
up vote 2 down vote

A good place to start is the OWASP Top Ten. It's a list of the most common vulnerabilities found in web apps and I'm sure you can apply a lot of the information to your case. They describe each vulnerability in detail as well as some mitigation techniques.

share|improve this answer
1  
Hmm owasp top 10 is kind of small, no? – Rook Sep 5 '12 at 15:22
By definition it's the most commonly exploited vulnerabilities. Protecting from them first would protect you from the majority of potential attackers. Surely more vulnerabilities can exist but any opportunistic attacker would be likely to poke at your server, see no major flaws and move one to something else. A targeted attack would require you look beyond the top ten. – KDEx Sep 5 '12 at 15:32
4  
OWASP is for generic descriptions of vulnerabilities, and advice on how to prevent / mitigate them. It's useful for background knowledge, but it doesn't really directly help identify vulnerabilities in systems, or document specific instances of known vulnerabilities. – Polynomial Sep 5 '12 at 15:34
I agree with Polynomial. Yes the owasp top 10 should be looked at, but in terms of the OP's question. If a pentester just looked at the owasp top 10 I would be seriously worried. – Rook Sep 5 '12 at 16:33
I don't think OWASP top 10 will help me a lot since I am not testing web application right now. I am rather interested in testing server\infrastructure. – Eugeny Loy Sep 5 '12 at 19:00
up vote 0 down vote

There is a lot more you can do and have fun with that maps to the “good idea to gather intelligence” part of your question.

You can regularly win in real world pentesting without discovering a known vulnerability or launching an exploit.

Discovering open FTP servers on an internal scan of an enterprise network is commonplace. Often these same FTP servers are free of known vulnerabilities (i.e. they’re patched). Far from game over, you can do the intelligence thing and go manually trawling the FTP servers for treasure. Pentesters, countless times, have stumbled across full MS SQL backups, server backups, and other exciting booty on otherwise unexciting, up-to-date, patched servers.

So spending the appropriate time manually checking out what is accessible to you beyond the version/banner check is important. If you’re lucky, you’ll find something way more fun than a boring and known vulnerability.

FOCA Pro is an example of an awesome tool designed to extract information valuable for pentesting activities (e.g. usernames, UNC paths, server names, print servers) that doesn’t require the vuln/exploit precondition. The intelligence gathering you do can help with tons of activities including the building of tailored brute force dictionaries.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.