Sunteți pe pagina 1din 22

07/2011 (7) November

EDITORS NOTE
Halloween injected!

07/2011 (07)

TEAM
Managing Editor: Maciej Kozuszek maciej.kozuszek@software.com.pl Associate Editor: Shane MacDougall shane@tacticalintelligence.org Betatesters / Proofreaders: Davide Quarta, Rishi Narang, Scott Christie, Ed Werzyn, Jeff Weaver, Aidan Carty Senior Consultant/Publisher: Pawe Marciniak CEO: Ewa Dudzic ewa.dudzic@software.com.pl Art Director: Ireneusz Pogroszewski ireneusz.pogroszewski@software.com.pl DTP: Ireneusz Pogroszewski Production Director: Andrzej Kuca andrzej.kuca@software.com.pl Front page photo by: www.scribbletime.com Publisher: Software Press Sp. z o.o. SK 02-682 Warszawa, ul. Bokserska 1 Phone: 1 917 338 3631 www.pentestmag.com Whilst every effort has been made to ensure the high quality of the magazine, the editors make no warranty, express or implied, concerning the results of content usage. All trade marks presented in the magazine were used only for informative purposes.

All rights to trade marks presented in the magazine are reserved by the companies which own them. To create graphs and diagrams we used program by

Mathematical formulas created by Design Science MathType

DISCLAIMER!

The masquerade is on. Therefore, weve decided to bring you a little longer edition of PenTest. This time 61 pages about SQL Injection, Fuzzing and other interesting stuff. Lets than have a closer look at what we have prepared for you in Novembers edition. Were starting with the main topic SQL Injection. Two articles, but altogether 16 pages describing practical side of this technique. First one, written by Sow Ching Shiong, focuses on using Open Source and Free Tools for both Windows and Linux. Second one, whose author is Christopher Payne, will show you how to inject your way to success. The author starts with a simple example of sql injection, describes its various types and ends the article writing about defending against sql injection. This is injection of a really large dose of knowledge. See for yourself! In the next section of this issue weve decided to continue the Fuzzing topic, as it occurred to be much broader field than we thought. Here, you will find three papers written by: Mrityunjay Gautam, Jose Selvi, and Sagar Chandrashekar. The first one is devoted to the theory of fuzzing, but also gives us some insight in some fuzzing tools, so its a great introduction into two another articles. In the second one Jose is bringing us some useful information about not so popular fuzzing tool called Sulley. And the last one is a thorough description of another tool called WebScarab. If youll jump to a page No 38, youll find yourself in third section, Focus. This section is a continuation of a huge article by Jonathan Brossard, where he describes a tool called Pmcma (Post Memory Corruption Memory Analysis). This one is aimed especially in those interested in reverse engineering. The next article called Maximizing the Value of Pentesting is obligatory for all those who work in IT Security business, and especially for those conducting any forms of penetration tests or vulnerability assesments. This piece is a great talk about the quality of services in this business, and how should they be improved. Finally at the end of this issue you will find an interview with Dean Bushmiller, professional with a great experience and not a lesser knowledge. Unfortunately this time our collumnist Shane McDougall couldnt provide us with the article due to the unforeseen circumstances. His articles will surely appear in the future issues. We hope, you will find this issue of PenTest compelling and worthful. Thank you all for your great support and invaluable help. Enjoy reading! Maciej Kozuszek & PenTest Team
Page 3

The techniques described in our articles may only be used in private, local networks. The editors hold no responsibility for misuse of the presented techniques or consequent data loss.

07/2011 (7) November

http://pentestmag.com

CONTENTS

SQL INJECTION
SQL Injection is an attack in which the attacker manipulates input parameters which directly affect an SQL statement. This usually occurs when no input sanitisation is conducted. Depending on permissions, an attacker may be able to read database contents or even write to the database. In this article, the author will show you how to perform SQL injection pen-testing using open source and free tools available for Windows and Linux.

06

SQL Injection Pen-Testing


by Sow Ching Shiong

WebScarab is a framework maintained by OWASP. It helps security engineers, developers to identify vulnerabilities and bugs in web applications. It is written in Java, and is thus portable to many platforms. The author focuses on describing how does the WebScarab Tool work like.

FOCUS

38

Introduction to exploit automation with Pmcma, Part II


by Jonathan Brossard

16

SQL Injection: Inject Your Way to Success


by Christopher Payne

Databases are the backbone of most commercial websites on the internet today. They store the data that is delivered to website visitors (including customers, suppliers, employees, and business partners). Backend databases contain lots of juicy information that an attacker may be interested in. Here the author makes a great introduction into the art of SQL Injection.

This year a tool called Pmcma (Post Memory Corruption Memory Analysis) was released at the Blackhat US security conference. The following article is an introduction to Pmcma. The second part of the article describes pmcma.c implementation, focusing on attacking function pointers, simulating arbitrary reads, detecting unaligned memory accesses and finally automating analysis and exploitation scenarios. The author made a serious efforts to provide you all the details concerning this tool, that you might need.

STANDARD

FUZZING
As a developer working on a product release, we tend to re-use most of the legacy code from the previous release and then work on the new features and bug-fixes only. As a QA resource, we would be using the same conformance test suite or the same stress test suite to ensure that the new builds are working as expected. In this article the author gives us the good insight into the theory of the art of fuzzing.

24

Fuzzing for Free

50

Maximizing Value in Penetration Testing


by Ed Skoudis

by Mrityunjay Gautam

The penetration testing business faces a great danger as more and more people jump into the field offering very low-value penetration tests that are little better than an automated vulnerability scan. In this article, well discuss how to conduct your tests and write up results so that they can provide significant business value to the target organization. The author will surely convince you that the quality of your services is what really matters in this business.

Can you write a simple python script? Can you understand a network protocol and describe it using a simple object set? If so, you can find your own 0-day vulnerabilities! In this article we are going to describe how we can use Sulley Fuzzing Framework with a real vulnerable FTP Server. As it is mentioned above, the author presents you how to use the Sulley Tool.

28

Fuzzing With Sulley


by Jose Selvi

INTERVIEW

56

Interview with Dean Bushmiller


by Aby Rao

In order to follow along with the fuzzing exercises in this article, you will need a fuzzer and fuzzing target. WebScarab will be our fuzzer and WebGoat web application is our target. WebScarab and WebGoat can be installed on both Linux and Windows machines.

32

Fuzzing With WebScarab


by Sagar Chandrashekar

Dean currently consults on information assurance and operational security. Proving insecurity by penetration testing is a natural part of consulting. He focuses on converting the business philosophy of security is an obstacle to security is a money maker. He has served on 6 beta testing teams. He is the subject matter expert on the 10 domains of the CISSP official curriculum. In this interview Aby talks with Dean about his career, courses hes leading and his statement about todays security business condition.

07/2011 (7) November

Page 4

http://pentestmag.com

07/2011 (7) November

SQL INJECTION

SQL Injection PenTesting


using Open Source and Free Tools
SQL Injection is an attack in which the attacker manipulates input parameters which directly affect an SQL statement. This usually occurs when no input sanitisation is conducted. Depending on permissions, an attacker may be able to read database contents or even write to the database.

n this article, the author will show you how to perform SQL injection pen-testing using open source and free tools available for Windows and Linux.

The program is able to identify error and Booleanbased SQL injection problems, as well as uncovering

SQL Injection Tools for Windows

Netsparker community edition is a powerful web application vulnerability scanner, which can detect and report potential website security problems and allow you to resolve them before they are used by hackers.

Figure 3. Netsparker community edition successfully obtained the version of back-end database

Figure 1. Netsparker community edition main screen

Figure 2. Netsparker community edition scan results

Figure 4. Havij free version main screen

07/2011 (7) November

Page 6

http://pentestmag.com

SQL INJECTION

SQL Injection: Inject Your Way to Success


SELECT * FROM winners WHERE pentester = YOU or 1=1--
SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. SQL Injection is one of the most common vulnerabilities in web applications today. It is (as of the time of writing) ranked as the top web application security risk by OWASP[1].

atabases are the backbone of most commercial websites on the internet today. They store the data that is delivered to website visitors (including customers, suppliers, employees, and business partners). Backend databases contain lots of juicy information that an attacker may be interested in. Data such as: User credentials, PII, PII, confidential company information, and anything other data that a legitimate user may need access to through a web portal. At its most basic form, web applications allow legitimate website visitors to submit and retrieve data over the Internet using nothing more than a web browser which allow the internet to be the giant consumer market that it is. SQL Injection is the attack technique which attempts to pass SQL commands through a web application for execution by the backend database. If not sanitized properly, web applications may result in SQL Injection attacks that allow hackers to view or modify information from the database. The attack tries to convince the application to run SQL code that will result in access that was not intended by the application developers. The attacker uses SQL queries and creativity to bypass typical controls that have been put in place. Common web application features introduce the SQL injection attack vector. These features include login pages, search pages, e-commerce checkout systems,
07/2011 (7) November

a myriad of user submit able forms and the delivery of dynamic web content. Many of these features users take for granted and demand in modern websites to provide businesses with the ability to communicate customers. These website features are may be susceptible to SQL Injection attacks and are good place to start during a pentest engagement that includes a web application testing component.

A Simple SQL Injection Example

Take a simple login page where a legitimate user would enter his username and password combination to enter a secure area to view his personal details or upload his comments in a forum. When the legitimate user submits their information, a SQL query is generated from this information and submitted to the database for verification. The web application in question that controls authentication will communicate with the backend database through a series of commands to verify the username and password combination that was submitted. Once verified, the legitimate user should be granted the appropriate access for their account to the web application. Through SQL Injection, the attacker may input specifically crafted SQL commands with the intent of bypassing the login form authentication mechanism. This is only possible if the inputs are not properly
http://pentestmag.com

Page 16

07/2011 (7) November

Page

FUZZING

Fuzzing for Free


State of Art and Upcoming Research
As a developer working on a product release, we tend to re-use most of the legacy code from the previous release and then work on the new features and bug-fixes only. As a QA resource, we would be using the same conformance test suite or the same stress test suite to ensure that the new builds are working as expected.

ut what troubles us the most is that some security researcher (or hacker, as some of us prefer to call them) sends an email to your security response team telling about an exploitable buffer overflow in your product. Some of us think that the researcher actually reversed engineered the code to find this issue; or he has access to some very specialized hardware and software to spot these issues. The reality is far more simple and costeffective. In this article, we would talk about a few open source tools which are used by security researchers to spot vulnerabilities in our products even if they have zero or a very minimal knowledge of the product.

Introduction

With companies like ZDI out there in the market to pay for every vulnerability you find, the motivation to work in security research has gone exponentially high in the last few years. The model of payment by ZDI and many similar companies is that, if you disclose an exploitable vulnerability to ZDI with its proof of concept (PoC), you get paid anything from 5000 USD to 40000 USD depending on the width of deployment of the product targeted and the severity of the issue. Hence, if you can compromise a machine by exploiting some product on it from the network, the money you get it quite decent. Hence, the general interest in identifying network, file and web based vulnerabilities is consistently growing amongst the
07/2011 (7) November

researchers. Here, in this article, we would discuss some state of the art open source tools which can be used for fuzzing networks, files and activeX controls. Fuzzing is one of the most commonly used techniques for identifying security flaws in any application. The entry points for user controlled or tainted data is identified in the application. These are files, registry entries, emails, network sockets, activex controls, dll, etc, typically the places where any attacker controlled data can enter into the system and the application starts processing it. Fuzzers typically have a stored dictionary of strings and integers which it uses at appropriate places iteratively. If the fuzzer identifies some part of the input as a variable string, it would try all possible values of strings from its dictionary and further mutations of these strings. These strings typically target standard vulnerability classes like buffer overflow, format string vulnerability, directory traversal, sql injection, xss injections, command injections, etc. All of these can be grouped as implementation level flaws only. Another class of vulnerability is design level vulnerability. If there is a design flaw in a network protocol which allows for a man-in-the-middle attack, it can never be detected by a fuzzer. Hence, by definition, fuzzers are intended to target implementation level flaws only.

Network Fuzzers

One commonly targeted attack surface is network protocols. In the industry, we either have implementation for
http://pentestmag.com

Page 24

FUZZING

Fuzzing With Sulley


Can you write a simple python script? Can you understand a network protocol and describe it using a simple object set? If so, you can find your own 0-day vulnerabilities! In this article we are going to describe how we can use Sulley Fuzzing Framework with a real vulnerable FTP Server. Check it, try it on your own software, and... enjoy, of course.

uzzing is a technique used in software security testing in which lots and lots of abnormal input data are sent to the software, in order to produce errors in normal software operation. Since a software error is usually a potential security threat, Fuzzing is a great technique to detect security flaws. Fuzzing is usually used by attackers in order to discover unknown vulnerabilities, but also can be used by security staff or software deverlopers, in order to test their software strenght against this kind of attacks.

Sulley Fuzzing Framework

Sulley is an Open Source project, written in Python, that try to be a new standard in fuzzing software.

Sulley provides the tester with a... powerful framework where he can describe, using a simple grammar, the protocol to fuzz, and then the framework generates a complete set of tests based on mutations of the given grammar. Each test of this set is checked against the fuzzed software, while other components of the framework are monitoring all processes and network events related with each test. When an abnormal response happens, Sulley Framework stores all data related to the crash, so the tester has all the information regarding the CPU registers, stack, network, and much more. It can be very useful in order to understand the weakness and correct (or exploit) it.

Figure 1. Sulley from Monsters Inc.

Figure 2. Sulley Architecture

07/2011 (7) November

Page 28

http://pentestmag.com

FUZZING

Fuzzing with WebScarab


Although there are ample techniques to identify vulnerabilities in software, fuzzing is the best technique as it is cost effective and enhances software security as it often finds odd lapses and vulnerabilities through automated or semi-automated process followed by manual expert reviews.

uzzing is all about finding vulnerabilities or errors in applications, operating systems and networks by injecting large amount of arbitrary data, called fuzz. A Fuzzer is a tool which successively picks a value from a fuzz template to replace user-specified parameters in a request sent to the server. Response from the server is manually reviewed to identify vulnerabilities or errors.

There are different fuzzing methods depending on how the fuzzer is used depending on the input parameters.

Session Fuzzing

Introduction To Fuzzing

Why fuzzing? Where does it fit? What are its limitations? Vulnerability scanners are imprudent; they discover known security issues and other low hanging fruit. Fuzzing along with penetration testing covers this gap and discovers unknown vulnerabilities. Fuzzing is one of the techniques for automating security assessment.

Session fuzzing involves analysis of valid sessions of the application or the server. During fuzzing, preferred parameters or parts of the session are altered and sent to the server or application. Since this method enables fuzzer tool to change data that already exists, it is possible that the application will go into an uncertain state which results in a security vulnerability. Example: Incrementing session ids of a web application.

Explicit Fuzzing

Fuzzing Overview And Requirements

Fuzzing enables security engineers, developers and testers to locate defects, errors, and vulnerabilities produced by abnormal values via user inputs. Fuzzing covers the vital attack surfaces in a system fairly well, identifies many common errors, probable vulnerabilities quickly and economically. Fuzzing is useful in evaluating black box systems, as it does not involve any access to source code and can be performed without knowing the inner mechanism of the target system.
07/2011 (7) November

Explicit fuzzing involves building of specific fuzzing tools for specific applications or servers. It is possible to enumerate the target which may go into an uncertain state which results in a security vulnerability. Example: Fuzzing FTP server with FTP Fuzzers.

Generic Fuzzing

Generic fuzzing involves tool analysis to identify vulnerabilities on array of protocols, but they are not as efficient as explicit fuzzing. Generic fuzzing involves lot of manual inputs from the users and only experienced users can able to use these types of tools. Example: Protocols Fuzzing Tools such as Spike
http://pentestmag.com

Page 32

FOCUS

Introduction to

Exploit Automation With Pmcma (Part II)

Earlier this year, we released a tool called Pmcma (Post Memory Corruption Memory Analysis) at the Blackhat US security conference. The tool is available free and open-source at http:// www.pmcma.org/ under the Apache 2.0 license. The following article is an introduction to Pmcma. In addition advanced readers can refer to the full Blackhat whitepaper mirrored on the Pmcma website[0].

he second part of the article describes pmcma.c implementation, focusing on attacking function pointers, simulating arbitrary reads, detecting unaligned memory accesses and finally automating analysis and exploitation scenarios.

Attacking Function Pointers

Now that we have a way to experiment on various modifications of a given process and address space, how do we find function pointers? Well, lets get back to the definition of a function pointer... It is a variable, hence in a writable section, which points to a function. The majority of times a function starts with a standard epilogue. And they all are in executable sections. So what we do (in pseudo code) is: see Listing 2. Two things are worth mentioning: first of, we may miss a few pointers if we use this algorithm, because some functions may not start with a standard prologue. This was anticipated, and pmcma allows to test all of the pointers to +X zones pointing to a valid assembly instruction just by passing it the relaxed flag. This is very time saving and works well in practice though. Secondly, the list of pointers we get this way (by a pure static analysis) is w list of _ potential_ function pointers. They may just happen to be variables to luckily point to a valid functions entry point. More importantly, it doesnt give us the list of function pointers actually being dereferenced between a given point in time (eg: the one where we found, say, an invalid
07/2011 (7) November

write condition), and an other (either the process exit, or the return to this very same instruction in case of loops). To detect those, were going to use the mk_fork() technique. The algorithm is as follows: see Listing 3. To the best of my knowledge, this is the first proposed technique to exhaustively enumerate all the function pointers inside a process between two points in time. By default, pmcma uses the valid 0xf1f2f3f4 as a remarkable value, which is obviously never correct from userland, and is quite remarkable, hence limiting false positives. This value can be changed from the command line. Lets see how this would work inside pmcma on a simple example, by listing the function pointers from a given point in /bin/su: see Listing 4. So using the strict mode, we found 0 potential function pointer to overwrite: Fortunately, in such a case, the application will then try the relaxed mode: see Listing 5. We found 5 function pointers that are actually being dereferenced by /bin/su before exiting. To verify we actually got something relevant, we can read the message logs from the kernel:
jonathan@blackbox:~$ dmesg |tail -n 1 [ 7472.786312] su[20879]: segfault at f1f2f3f4 ip f1f2f3f4 sp bfcab4e8 error 15

jonathan@blackbox:~$

Page 38

http://pentestmag.com

STANDARD

Maximizing Value in Penetration Testing


The penetration testing business faces a great danger as more and more people jump into the field offering very low-value penetration tests that are little better than an automated vulnerability scan. In this article, well discuss how to conduct your tests and write up results so that they can provide significant business value to the target organization.

f you are an in-house penetration tester in an enterprise, providing more business value through your work can help improve your job security in a tumultuous economy, and, better yet, may help you land that fat raise youve been hoping for. If you are a third-party penetration tester, providing more business value can lead your career to the point where you will command a higher bill rate. Whats not to like? I read a lot of penetration testing reports. In my work as an expert witness analyzing large-scale breaches, Im regularly called upon to look at the previous five years of penetration testing and vulnerability assessment reports of a large number of companies. Also, in my own pen testing work with my team, I review many of my teams reports, as well as take a critical eye to my own reporting output, always with the goal of making our results better and more meaningful. In any given week, I read between two and five pen testing reports, and I spend a lot of time thinking about their effectiveness. And, Ive got to tell you, a lot of penetration testers generate absolutely horrible reports. Some of them are little more than regurgitated vulnerability scanning results, all packaged up and labeled as Penetration Test Results. Admittedly, some organizations desire what I like to call the RCPT, the Really Crappy Penetration Test. That is, they want to procure a test so that they can check off a compliance box saying that they got a penetration test, but the last thing they want is test
07/2011 (7) November

results that make an effective argument for changing things in their environment. Although there is, sadly, a distinct market segment of enterprises that desire the RCPT, other organizations demand more business value for the penetration testing expenditures, as they should. As a penetration tester, yes, you could take the easy way and deliver low-quality results from low-quality tests, catering to the RCPT market. But, Im hoping youll strive to do better. I strongly believe that its in all of our best interest to do so. If the RCPT comes to dominate and tarnish the definition of a penetration test, well all be worse off. Fewer organizations will want to employ us for the high-quality work we all love to do. The folks working on the Penetration Testing Execution Standard (PTES) have done some fantastic work in defining procedures for conducting thorough, high-value penetration tests, and I celebrate their work. What Id like to focus on in this article, however, is tips for helping to maximize the business value of your penetration testing results, especially in the report itself. Look, most penetration testers can scan and exploit a target environment. But what really differentiates the best of the best from the merely good is the ability to provide value and drive change that helps an organization improve its security stance. That has to be our relentless focus, as we strive to avoid the pit of the RCPT.
http://pentestmag.com

Page 50

Keeping the Main Thing the Main Thing: Its Not All About Shell or Even Domain Admin Its Really About Business Risk

As penetration testers, our hearts dance when we pop a target box, getting that much-coveted shell access to the machine. You know it and I know it. But please realize that merely compromising machines actually isnt the ultimate goal of your work. Its a means to an end. The end is to determine the business risk the organization faces in association with the vulnerabilities youve discovered. As you conduct a test, and especially as you prepare the report, make sure you always keep the main goal in mind: to determine, demonstrate, and explain the risk to the business, as well as methods for mitigating that risk. One item in which some penetration testers fall short in determining business risk involves a view of a target environment as just a group of individual machines. Once theyve gotten shell on one of them, such pen testers figure that they have a high-risk finding, and they call it a day. The real bad guys dont do it that way. That initial compromise is the toe in the door, and they view the entire group of machines and the network itself as their target. The real bad guys, whose work we need to mimic to understand business risk properly, pivot mercilessly, bouncing from that initial compromised machine to other machines in the target environment. Pivoting through a target, some penetration testers set their sites on seemingly very juicy prey: Domain Admin rights in a Windows environment. But, honestly,

even that very important level of access is still a means to the end of demonstrating business risk. Decision makers in management of the target organization likely will not understand the risks they face if their penetration testers tell them that an attacker can conquer shell on a machine or even Domain Admin rights on their Windows environment. The penetration tester who can show the implications of this access, such as the ability to access millions of sensitive healthcare records or control systems that contain vital trade secrets, will provide so much more value. Joshua Jabra Abraham has written convincingly about goal-oriented penetration testing, in which a penetration tester focuses on achieving certain goals beyond discovering vulnerabilities in a target environment. Abraham cites goals such as remotely gaining internal system access, gaining Domain Admin access, and gaining access to credit card information. I strongly support the idea of goal-oriented testing, and urge penetration testers to work with target system personnel to define their goals in terms of business issues (not just technical achievements) that are important to the target organization. When initially scoping a penetration test, make sure you ask target system personnel what their most important information and processing assets are, and what their nightmare scenarios for computer attacks might be. Sometimes, you may have to stretch their minds a little bit about what an attacker could actually do. Have an open and honest discussion about the possibility of economic loss (due to down time, stolen

Figure 1. Pen Tester C Has Dened Business-Centric Goals that Go Beyond Shell and Domain Admin

07/2011 (7) November

Page 51

http://pentestmag.com

STANDARD
money, diminished competitive advantage through stolen trade secrets, etc.), regulatory and compliance oversight (if a breach were to occur and government investigators were to come a-calling), lawsuit possibilities from customers or business partners, brand/reputation tarnishment, and physical threat to life and limb. In a frank discussion about these points, I often ask target system personnel, What keeps you awake at nights in terms of computer attacks? This isnt about spreading Fear, Uncertainty, and Doubt, the lame FUD used to scare people into better security practices. Instead, this is about an honest view of security risks and how a penetration test can help determine how realistic those risks are. For example, I was once discussing with a manufacturing company their biggest worries about what an attacker could do in compromising their computing infrastructure. They were focused on whether a bad guy could deface their website. I asked them whether they thought about an attacker who got access to their internal environment and stole their sales contacts, swiped their future product plans, or gained control of their manufacturing equipment controls causing it to malfunction or shut down. Are those things possible? they asked. Lets structure a penetration test so we can carefully see if they are, I responded, as we set more business-centric goals for the test. Consider the three penetration tests illustrated in Figure 1. In the first test (indicated by Pen Tester A with green text and arrows), the penetration tester gets shell access on a target machine and reports that a critical exploitable vulnerability was discovered, but stops there. In the second test, Pen Tester B (whose work is illustrated by text and arrow B in blue) has gone deeper than the first tester, pivoting after exploiting the initial flaw, by dumping hashes, conducting a pass-the-hash attack, and gaining access to a machine with a Domain Administrator token on it. This tester then seizes the Domain Admin token, and writes up the results in a report, claiming victory due to Domain Admin compromise. Pen Tester B has certainly demonstrated some risks associated with the original flaw better than the first pen tester. But, it isnt until we get to the third penetration tester, Pen Tester C, shown with red arrows and text, who continues pivoting even after gaining Domain Admin privileges, getting access to a machine with highly sensitive trade secrets. This third penetration tester will be able to best express the risk the organization faces due to the collective flaws in its environment, and make the best argument to management for action. Note that not only does Pen Tester C pivot more than A or B, but Pen Tester C is also focused on
07/2011 (7) November

showing business risk by gaining access to sensitive trade secrets instead of just technical dominance of the target environment.

Remember Who Your Primary Audience Is Not Other Pen Testers

Many really skilled penetration testers write their reports so that they will impress people like themselves, that is, other penetration testers. I am often tempted to do this myself, as I get into a mindset of I want to knock the socks off of other penetration testers with the amazing work I did here, so Im going to describe it all in terms that pen testers will understand and get excited about. While the temptation is understandable, it should be avoided. Impressing other penetration testers shouldnt be the real goal of our reports, as they arent the audience that will allow us to provide the most business value in our reports. Who is? For your executive summary, decision makers are. These people can allocate resources to help alleviate the issues youve discovered if you can make a convincing business-centered point to them. The remainder of your deliverable, however, should be written with an eye toward providing maximum value to the enterprise security professional and the operations team. Phrase your discussion and recommendations so that they help security people and system administrators implement your recommended fixes. How? Thats what Tips number 3 and 4 are all about.

Provide the How-To In Your Recommendations

In your recommendations for remediation, dont just describe at a high-level the changes that need to be made, but instead, include a practical step-by-step

Figure 2. Different Styles of Recommendation Carry Different Levels of Business Value (and Risk of Something Going Horribly Wrong)

Page 52

http://pentestmag.com

description of how to implement your recommended change. Provide command-line or GUI screenshot examples that show how to make your recommended changes. Consider a straight-forward sample finding that many network penetration testers encounter, illustrated in Figure 2. Suppose the target organization has internal Windows machines that support NTLMv1, an older, weaker form of Windows authentication. A fairly lowvalue finding would involve copying and pasting the result from a vulnerability scanner recommending that the target organization move to NTLMv2. But how? A bit higher-value finding would tell the target organization to set the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\LSA\LMCompatibilityLevel registry key value to 5 for servers. Such a recommendation is certainly better than just saying to move to NTLMv2, but it still leaves open some questions of how target environment personnel can do this. A higher-value finding might include information about running a command such as the following on the discovered impacted servers, which will alter the given setting to the recommended value:
C:\> reg add hklm\system\currentcontrolset\control \lsa /v lmcompatibilitylevel /t REG_DWORD /d 0x5

every finding? In many enterprises, a penetration test report is split up among multiple groups or individuals, with each group assigned tasks to fix a subset of findings and receiving only the pages corresponding to their actions. If you include that text with only one finding, another group may get a separate part of the report, and not see the vital caveat you included in another section of the report. Does this get redundant? Yes, but that redundancy is the price of reducing risk.

Provide the How-To-Check-Remediation In Your Recommendations

To provide even more value, you can include a walk-through of how to implement this finding using Group Policy and then apply it to an entire Windows environment. The bottom line here is to always look at your recommendations, and see how well youve answered the question, But how? I know what you are thinking. At this point, you are likely concerned that the more detailed you get with your recommendation, the more risk that target system personnel will blindly follow it, potentially wreaking havoc in a production environment. This concern is quite valid, and must be managed in the report itself. Thats why I like to include language with every single finding that says:

Now, heres a real gem that can help differentiate your penetration testing results and significantly increase their value. In your recommendations for remediation, include not only the how-to for implementing the fix, but also include a description of how the organization can verify that the remediation is in place. That way, they can have some level of assurance that the fix is working. The how-to-check description may be prose, but I like to go further, providing one or more command lines, GUI screenshots, or tool configurations that do the job of verifying the efficacy of the remediation. You should write such recommendations so that they can be carried out by a skilled security professional or a very knowledgeable system administrator, but dont write them in a manner that only other penetration testers would be able to perform your recommended actions. For some findings, including a checking step is trivially easy. Consider the NTLMv2 recommendation discussed earlier. You could add the following to that recommendation, significantly improving its value: You can check this setting by running the following command:
C:\> reg query hklm\system\currentcontrolset \control\ lsa /v lmcompatibilitylevel

These changes are based on their applicability to numerous environments, but could have unknown consequences in this particular environment. For that reason, any recommended changes should be evaluated in a test environment first, and then rolled out through proper, formal change control processes. If you do not test these configurations in an experimental environment, they could result in downtime or other damage to a production environment.
I like to put this text in bold face font and italicize it to emphasize its importance. I include it with every finding that requires a change of configuration. Why
07/2011 (7) November

You should verify that its output is 5, an indication that the system is configured to use NTLMv2. For small tweaks to configuration or the application of various patches, Windows commands such as reg, wmic qfe, and wmic product are especially helpful. On Linux, youll often rely on cat, grep, rpm, and running a program with the version option as a check. For more complex recommendations, crafting a checking step that is suitable for non-penetration testers can be much more of a challenge. For example, writing a procedure to test whether CrossSite Scripting (XSS) defenses have been implemented at first seems very difficult. If you suggest that they try
http://pentestmag.com

Page 53

STANDARD
to enter certain specific test XSS strings to evaluate their newly implemented filters, it is quite possible that the filters remove only the specific test strings youve provided! The organization would then have a false sense of security, as other XSS strings would still work against the target application. Thats why Ill sometimes craft my verification process around the running of a given tool with a specific configuration. So, for XSS, Ill suggest that the organization run a particular free XSS scanning tool that I know will put the application through its paces and give a reasonably good read on whether they have defended against XSS more comprehensively than by just filtering a few test strings. When I first proposed adding these checking recommendations to our reports, some folks at the penetration testing company where I worked protested, saying that this will lengthen the report writing time and drive up our costs. But, Ive found that adding this extra information really only requires a few minutes for each recommendation, and lends itself to templatization. It may mean that your reports take ten percent longer to write, but their value to target system personnel will be significantly greater. At first blush, third-party penetration testers who do assessment projects for other enterprises may think that this recommendation will cost them future remediation verification work. That is, if you tell your customers how to check their own remediation in your report, theyll be less likely to come back to you for a retest to verify their fixes. While that is certainly true, quite honestly, retest work focused on verifying fixes tends to not be terribly interesting, nor financially lucrative. Id rather provide as much value up front as I can, with the knowledge that Im helping to cement the customer relationship for their next real penetration test.

Prioritize Your Findings Carefully According to Impact and Probability of Exploitation

The vast majority of penetration testing reports that I read prioritize finding based solely on whether the issue is high, medium, or low risk. While such rankings do provide a broad signal to decision makers and technical personnel about where they should focus their remediation activities first (high-risk items), the so-called HML (High-Medium-Low) mechanism often lacks the granularity many organizations need for prioritization with the high-risk category itself. Thats why I recommend categorizing risks according to both their potential impact as well as their probability of being successfully exploited. That way, organizations can get a better feel for the risk factors and focus their efforts on items that are simultaneously high impact and rather likely to be exploited. Of course, there are far more complex methods for assigning risk levels to discovered flaws, such as the Common Vulnerability Scoring System (CVSS) developed by FIRST. While CVSS is an excellent method for detailed analysis of flaws, some penetration testers find that its complexity and precision make it difficult or costly to use in routine penetration testing. Ive found that categorizing issues according to impact and probability to be a happy medium between the toosimple HML approach and the more complex CVSS scheme. In your executive summary at the start of a penetration testing report, it can be useful to provide a graphical summary of discovered issues according to their relative importance to the organization. For HML-style findings, many penetration testers just cut and paste a bar chart showing the relative count of

Figure 3. A Traditional Bar Chart Used with the HML Model Doesnt Convey Very Much Information or Business Value

Figure 4. A Matrix Showing Impact and Probability, with Circle Size Indicating the Number of Each Type of Issue

07/2011 (7) November

Page 54

http://pentestmag.com

high, medium, and low-risk issues discovered, which doesnt really convey that much information or value, as shown in Figure 3. Going beyond the simple bar chart, our team has had a lot of success in showing a graphical summary of discovered issues based on impact and probability of successful exploitation using a multi-dimensional graph, such as that shown in Figure 4. Here, we have a matrix with the probability of successful exploitation running along the X-axis, and the potential impact going up the Y-axis, with a relative ranking of 1 to 5. Note that we indicate the relative number of issues discovered at each intersection by including a circle whose area corresponds to the number of findings there. A bigger circle indicates that the pen test team identified more instances of this kind of finding. We have had several customers tell us that this kind of chart provides a more meaningful summary of our results, and allows decision makers to more quickly understand results and assign resources necessary for remediation.

Conclusions

It is important to note that all of the recommendations Ive described here presume that you perform excellent technical work. You must continuously strive for that. Then, to add that final polish to your results, apply one or more of these tips to maximize the business value of your work. Weve discussed several different approaches for providing significantly more value in your penetration tests. Now, Im not expecting that every reader will follow every single tip here. But, I do hope that youll incorporate at least one or two of these practices, helping to drive up the business value of the work you do. Working together to help define and provide highvalue penetration testing will help our industry avoid the valueless death spiral of the Really Crappy Penetration Test.

ED SKOUDIS
SANS Fellow and Pen Test Curriculum Lead Author of SANS 504 and 560 Courses Founder, Counter Hack Challenges

07/2011 (7) November

http://pentestmag.com

INTERVIEW

Interview with

Dean Bushmiller
Dean currently consults on information assurance and operational security. Proving insecurity by penetration testing is a natural part of consulting. He focuses on converting the business philosophy of security is an obstacle to security is a money maker. He has served on 6 beta testing teams. He is the subject matter expert on the 10 domains of the CISSP official curriculum. Dean has been teaching on-line for 7 years and face-to-face for 11. As a non-military person, Dean Bushmiller is a proud Recipient of 5 mission coins for preventing deer in the headlights look.

Can you tell us a little bit about yourself and how you got involved in the field of Information Security?

DB: It is odd how I got into security; I backed my way into Information Security from training. I was a technology trainer back when Windows 95 had major problems with basic print processing. Explaining why it worked and how it worked seemed easy to me. I could read the big thick book and relate it to people. My customers said, hey you can teach. I started to teach technology and people would ask crazy questions. One student decided to test me and started asking questions from the then CD version of Microsofts Technet. I just kept on answering until he was bored. Then students started to ask me how to solve real problems they were having. It seemed logical to look at packet traces and ask about protecting the resources. I did my investigations for a few years, helping people with bigger and bigger problems. Once while on a customer site, some guy was looking over my shoulder and said in a very accusatory tone, What are you doing? After I explained, he said that was a security problem not a technology problem. Stay out of the security! I did not know there was a distinction. I thought all computing was computing and security was just another part. That is when I realized I had been in the Information Security field for about three years. I started doing more formal focused work and study in the security field and here I am.
07/2011 (7) November

This is a two-part question: You offer Penetration Testing consultation in addition to Security Education, how do you divide your time between the two, and does one play any role in the other?

DB: As far as the task at hand, it depends on the year, but it averages out to 50/50. I really like consulting by referral from my students. They know my way of doing things and appreciate it. As far as mental focus, its never really divided, you know? The roles blend together quite nicely! I learn from everything I get to do and always try and bring it to the next experience. Students in the classroom bring me new tools that I have never heard of before. As they are doing their homework, I am doing mine. Playing with that new tool, reading that book they talked about. I have a big lab environment in my office, every version of every operating system I can get my hands on built up so I can test tools. Things that I learn in the field make the training richer and deeper. Sometimes you can read the things you need in books. Sometimes it takes doing it over and over, optimizing until it is just right. And sometimes you create a great lesson out of thin air. That creativity is the spark that keeps both the classroom and the consulting working well. I am answer driven. I dont care what the answer is; I just want it so I can get to the goal of securing the environment. If the client is wrong or I am wrong, who cares? Lets just get to the answer so we can fix it.
http://pentestmag.com

Page 56

In the Upcoming Issue of

Client Side Exploits Available to download on December 2nd

Soon in Pentest! Ric Messier Stealth Testing Using NMAP Aniket Kulkarni Fuzzing Internals Craft it! Nimrod Ben-Em What XSS cant do for you? Tal Null Session Puzzling and more...

If you would like to contact Pentest team, just send an email to en@pentestmag.com. We will reply immediately.

S-ar putea să vă placă și