Metasploit mailing list archives
Pen-Testing and Metasploit Question
From: kbeaver at principlelogic.com (Kevin Beaver)
Date: Mon, 04 May 2009 09:28:10 -0400
I wrote an article on this for TechTarget that you may be interested in as well: Essential Elements of a Good Security Assessment Report http://searchenterprisedesktop.techtarget.com/tip/0,289483,sid192_gci1235715_mem1,00.html Hope this helps. Kevin Beaver, CISSP Consultant*Author*Speaker*Expert Witness Independent information security advice ~ Principle Logic, LLC company: www.principlelogic.com audio programs: securityonwheels.com blog: securityonwheels.com/blog twitter: www.twitter.com/kevinbeaver Matt Gardenghi wrote:
Well, I think that this should be enough: - Exec summary (1 page) -- Overview the work that was done -- Any significant highlights -- Grade/Score on the work - Summarize Flaws (1-2 pages) -- Explain the rating for the flaws -- List flaws in categories (High, Medium, Low) -- This isn't the place to give in depth discussion, just <ip/machine name> <vulnerability> OR <vulnerability> <multiple IPs> - Detail Flaws (multiple pages) -- Detail each flaw tested starting with the High -- Include screenshots where applicable -- Possibly add highlights to the screenshots/captured data to emphasize a point -- Explain how the flaw was exploited / broad strokes -- Add footnotes or endnotes detailing specific methods to fix and/or replicate the flaw for the IT guys to repair it as applicable with this specific test - Detailed recommendations -- This should give the client actionable measures to fix many of these vulnerabilities. -- Recommend an IPS if necessary to block automated exploits / RFI / LFI / SQL etc... attacks -- Recommend explicit techniques to sanitize input -- Recommend methods to decrease time to patching and/or methods to protect boxes that cannot be patched regularly -- Recommend best practices for securing RDP, FTP, Telnet, DNS, et al... -- This stuff depends on the results of your test, bust as you can see, most of these recommendation are procedures and do not necessarily require cash. The recommendations requiring cash (like an IPS, better AV) should solve multiple problems if possible. The goal of this section is to highlight low cost methods to boost security. Generally, a client can spend a few hours and secure systems better than they currently are by switching to SSH, SFTP and so forth. These recommendations are the value. You found a whole and if you can help them secure it at a low price, you just made yourself their new best friend. In stead of losing tens of thousands or millions on a breach, they just spent a few on you and secured these holes. :-) - Conclude with statements about what they have done well and a brief summary about what they need to do to continue improving. Hope that helps. Matt Gardenghi chuks Jonia wrote:Hi Matt, would you mind posting a sample report with the guidelines you just specified? ./Chuks On Thu, Apr 30, 2009 at 3:35 PM, Matt Gardenghi <mtgarden at gmail.com> wrote:This is my opinion of course: A report should give an overview for the execs, followed by a short list/snapshot of the critical items found. Then the report should detail the critical holes and data found. Lots of screenshots are helpful. The end of the report should make detailed recommendations on how to fix the holes. so -exec summary -summary of flaws -details of flaws/data captured/flags placed -detailed recommendations to fix the environment (especially low cost high-value solutions) -conclusions Hope that helps. That is roughly what I do. I also like to have plenty of footnotes and appendices with extra-geeky details. My goal is to write a report that any exec can read and understand the basic points, but also has the meat for the technical teams to delve in and solve things. That meat is usually in footnotes and appendices. Write so that a reasonably techie exec has the ability to delve as deeply as they want or stay high up on the surface. Matt pandini pandini wrote:Matt Gardenghi, TK and BN thanks for your replies ! One quote about Matt Gardenghi reply, about writing a good report. Just a .pdf document, containing all vulnerabilities found (Machine XXX vulnerable to ms08-069), its severity (Critical), and how to fix it (some link to a patch) ? Other informations (If I was asked to do it) like credentials grabbed(Plain text/hashed passwords), informations about hosts and devices (running linux, apache, etc), if the target has some database then some tables of an database, or source codes from the a internal cvs server of the company, as "proof" of what can be done by an attacker is usefull or just say "passwords can be stolen" ? About the report, someone has some "model" or example of report that can be shared with us ? I agree with you TK about certifications, and I seriouly thinking about CEH certification. But I have no ideia from where to start, someone knows a good book/material ? Thanks in advance, Pandini. On 4/23/09, Ben Nell <enemy.cow at gmail.com> wrote:A good place to look for help with these types of questions might be the Security Focus pen-test list. You can read some details about it at http://seclists.org/#pen-test. A lot of this sort of thing has already been discussed, so you could probably find a lot of useful information reading through the archives. BNpandini pandini wrote:I'm in the same boat that professor, trying to get into pentest industry but I don't know "where to start". I agree with what max said, imho methodology is the center of the thing, know how and why, is really better than know "where to click" or what command to run. My questions are, "What the industry expect from a pentester" (audit database, software source code, networks, servers , etc..), "What is generally done in a basic pentest", and what certifications are "good" to proof some basic knowledge. Just say to a company that "I'm able to do a pentest, can you give me a change ?" will don't work. I think that I need some formal proof of knowledge, as I haven't any professinal experience in pentest, this is the only one way that I see. Thanks in advance, Pandini. _______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework_______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework_______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework_______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework_______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework_______________________________________________ https://mail.metasploit.com/mailman/listinfo/framework
Current thread:
- Pen-Testing and Metasploit Question, (continued)
- Message not available
- Pen-Testing and Metasploit Question Professor 0110 (Apr 21)
- Pen-Testing and Metasploit Question MaXe (Apr 22)
- Message not available
- Pen-Testing and Metasploit Question Simon Taplin (Apr 22)
- Pen-Testing and Metasploit Question pandini pandini (Apr 23)
- Pen-Testing and Metasploit Question Kevin Beaver (Apr 23)
- Pen-Testing and Metasploit Question Ben Nell (Apr 23)
- Pen-Testing and Metasploit Question pandini pandini (Apr 29)
- Pen-Testing and Metasploit Question Matt Gardenghi (Apr 30)
- Pen-Testing and Metasploit Question chuks Jonia (May 02)
- Pen-Testing and Metasploit Question Matt Gardenghi (May 04)
- Pen-Testing and Metasploit Question Kevin Beaver (May 04)
- Pen-Testing and Metasploit Question pandini pandini (Apr 23)
- Pen-Testing and Metasploit Question Matt Gardenghi (Apr 23)
- Pen-Testing and Metasploit Question Edward Bjarte Fjellskål (Apr 22)
- Pen-Testing and Metasploit Question MaXe (Apr 22)