Use Nessus or focus on manual testing?

Question

Nessus scans for a a lot of vulnerabilities, so should I focus on learning vulnerabilities that are not covered by Nessus, like directory traversal attacks? Should I work on only the vulnerabilities that are not covered by Nessus, or learn all the vulnerabilities no matter covered or not by Nessus.

The 2 problems are:

1. Nessus doesn't give a list of the vulnerabilities (All of the vulnerabilities that it checks for and later tells us it is vulnerable to these sets of vulnerabilities) that it can find.
2. We have no idea about how efficient Nessus is (like for XSS attack, there is a big list of filter evasion methods on OWASP, I have no idea how many of these are covered by Nessus).

Advise please.

Answer 1

Putting aside that you are using Nessus, let me answer in terms of the use of any web application scanner as a tool.

Automated scanners are great tools for a quick, repeatable test that can find the most common issues with websites. I would never develop without running automated tools.

But, one always has to understand that these tools come with serious limitations and weaknesses. No tool is perfect.

So, it depends on the outcome you want. If you want a comprehensive understanding of your code, then you need a full process to cover your code. Things like:

• code reviews
• threat modelling
• automated scanners
• manual tests
• 3rd party manual tests

For every thing you decide not to include in your process, you also choose to lose that level of completeness of understanding.

If you depend solely on automated tools, you give up a LOT of understanding. Even if you use tools, it is still a good idea to understand all the common attacks on websites, yourself, and understand how to check for them manually. If for no other reason, than to check on false positives.

Answer 2

Here is a sample of the potential for (and against) automation in network penetration testing:

1. Start with an overall way of organizing your information from multiple tools. Many consider Faraday, but if you don't like it, comment about your experience and I'll provide other recommendations. There is a commercial service, Dradis Pro that many consider to be equivalent or better than most other options for organizing pen test data.
2. Give the pen test a good start with a tool such as discover.sh. This will provide a lot of focus and coordination between tools.
3. Leverage nmap. If you want to see "all vulns", then consider using version detection, the shodan-api NSE script, and the vuln NSE category of scripts with the script arguments to show all vulnerabilities that could potentially be tried.

nmap --open --randomize-hosts --min-rate 450 --script shodan-api,vuln,reverse-index --script-args vulns.showall -sSUV -pT:0-,U:7,9,11,13,17,19,36-37,42,49,53,67,69,88,111,123,135,137,139,161-162,177,213,259,260,407,445,464,500,523,623,1604,1645,1812,5353,5632,6481,6502,10080,17185,49152

4. Leverage other nmap NSE scripts, including third-party ones such as vulscan. Find more on GitHub that relate to your targets. Now you'll feel that you're doing more manual work!
5. Instead of starting with Nessus or Metasploit, integrate them with what you've done with nmap using tools such as nmap2nessus and metasploitHelper.
6. You can even run Nessus scripts manually, such as seen here -- https://security.stackexchange.com/a/3037/140
7. Go further! Try harder! Focus on the attack paths instead of the tools. For example, what about authentication or privilege escalation? What about LFI or IDOR, or as you said, Path traversal. Typically you will want to explore these issues with Burp Suite Professional or an alternative at the webapp layer, but there are so many other layers that can be explored, e.g., DB, middleware, mobile, mainframe, vehicular (i.e., CAN Bus), embedded systems, et al.