Penetration Testing Magazine

01/2011 (1) April http://pentestmag.com Page 301/2011 (1) April http://pentestmag.com

EDITOR’S NOTE01/2011 (01)

TEAMEditor: Sebastian [email protected]

Proofreaders: Michael Munt

Betatesters: Michael Munt, Edward Werzyn Jr

Senior Consultant/Publisher: Paweł Marciniak

CEO: Ewa [email protected]

Art Director: Ireneusz Pogroszewski [email protected]: Ireneusz Pogroszewski

Production Director: Andrzej Kuca [email protected]

Marketing Director: Sebastian [email protected]

Publisher: Software Press Sp. z o.o. SK02-682 Warszawa, ul. Bokserska 1Phone: 1 917 338 3631www.hakin9.org/en

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 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.

Dear Readers,Welcome to Penetration Test Magazine, a new publication from Hakin9 team, with its focus on the penetration testing field. What you are looking at right is what you might call the “zero” teaser issue, which we’ve decided to publish to reach you and – hopefully – encourage you to stay with us and become our avid readers in the future.

For there are surely good reasons to take a closer look at Penetration Test Magazine, especially if you are a pen tester, security assessment provider or client, or simply an IT security enthusiast. Our main goal is to create a platform, where like-minded specialists as well as amateurs could exchange their views, discuss important issues, or just observe the trends on the market. The penetration test market is thriving and it deserves a magazine that can deal with its issues. As for now, we are the only magazine of its kind on the market.

The magazine proper will be available by paid subscription, 29 USD per issue. What we offer for this price is more than fifty pages of top-quality, non-commercial technical writings by IT security specialists, who are more than happy to share their knowledge and expand yours.

The following teaser mag features two splendid pieces of writing. Iftach Ian Amit from Security Art and Chris Nickerson from Lares joined forces to present their views on the industry and how Penetration Testing Execution Standard can “fix” it. If you feel, like the writers do, that the term “penetration test” has been “cannibalized”, “commercialized”, and attracted too many “charlatans” – the article is just for you. The second article, by Bill Mathews from Hurricane Labs, will give you some practical advice on how to operationalize penetration testing results using network monitoring software, and – as the author highlights – for free.

We would like to thank the contributors for submitting great content and meeting very close deadlines at the same time, especially Iftach Ian Amit, whose assistance and commitment was truly invaluable for us.

We hope you enjoy the magazine – and don’t forget to check out our first issue in May!

Enjoy your readingSebastian Buła

& Penetration Test Magazine Team

/2011 (1) April http://pentestmag.com 01/2011 (1) April http://pentestmag.com

CONTENTS

STANDARDSFixing the Industryby Iftach Ian Amit and Chris Nickerson

HOW TO……Operationalize Penetration Testing Results Using Network Monitoring Software – All For Freeby Bill Mathews

ContributePenetration Testing Magazine is a community-oriented magazine. We want IT security specialists and enthusiasts to work together and create a magazine of the best quality, attractive to every individual and enterprise interested in the penetration testing field.

If you are interested in being a part of our community – submit an article or bring up a subject you consider important and up-to-date. Are there any trends on the market you’d like to take a closer look at? Are there any tools or solutions worth reviewing or presenting to the community? Are there any touchy and controversial issues you feel have to be discussed in public? Then share your opinions with us.

If you run an IT security company, your contribution is the most welcome. Tell us about your solutions and advertise in the magazine for free, or have a special issue devoted exclusively to you. As long as you provide top-notch quality of you writings, we are always ready to cooperate and help your company develop with us.

Are you a student? We’re looking forward to you articles! Fresh attitude, opinions and beliefs of the young and budding IT security gurus are invaluable for us. You will give your career a great start when you write to a respectable IT magazine. Showing an issue with your name among the names of other authors – and often famous ones – will be your great asset during a job interview.

If you think you don’t have enough time to create an article from scratch, but feel interested in the magazine – become one of our beta testers. This way you will get the opportunity to look at a new issue’s contents before it’s even published, and your name, too, will appear in the magazine. If you feel the need to contribute and share you knowledge, but don’t have enough spare time for creative writing – beta testing is just for you.

Sections:White Box Application SecurityBlack BoxWeb SecurityNetwork Security

Wireless Security Standards and MethodologiesHow To…Open Source IntelligenceVulnerabilities

CONTENTS

STANDARDS


The commercial industry has embraced the Sexyness of penetration tests, built products around it uprooted its values with product marketing

and sales speak, and conned organizations into buying deeper and deeper to the dreaded pentest unit (as in I need 2 units of pentest to complete this compliance effort). Backed by a thriving regulatory compliance rush to check-off as many items as they can on audit lists, pentesting was given the final blow to its heritage of value. A once surgical skill that required innovation, critical thinking, technical savvy, business understanding, and good old hacker-sense was reduced to a check box on the back of a consulting companies marketing material.

This type of market commoditization has led to the frustration of many businesses and consultants alike. With this in mind, a group of security veterans (each one

with at least a decade under their belts, and numerous successful penetration tests in various industries) have gotten together to discuss the state of the industry, and a common gripe was echoed. Many of the venting sessions from professionals around the world centered around the wide array of testing quality within penetration tests. This huge gap was often boiled down to the Scanner/Tool Tests and the Real Testing arguments. Another common theme for these sessions was the decided

lack of value presented by the Scanner type of testing and some brainstorming of how that could be resolved worldwide. This issue was not localized or specific to any vertical but it was something that InfoSec professionals from all around the globe were experiencing. From these sessions happening at EVERY security conference thrown an idea was born. The idea – to finally standardize and define what a penetration test really is. This would help the testers increase the quality and repeatability of the testing while also giving the organizations doing the testing, a reference list of what is to be done during the test. This is where the Penetration Testing Execution Standard (PTES) started. After a couple of months of working behind the scenes, a group of about a dozen security practitioners from different parts of the industry put forth a basic mind map of how they did penetration tests. Later on, that blended map was released to a larger group of InfoSec professionals. This group tore apart the original map and streamlined it to fit a larger and wider audience. At that point a final rendition of the mindmap was constructed between 25+ International InfoSec Professionals. With over 1800 revisions to the Alpha mindmap, the team then opened up the stage for more massive collaboration and started building one of the more exciting concepts in the security industry. Currently the Penetration Testing Execution Standard is backed by dozens of volunteers from all around the world, working in teams on writing the finer details of what will be the golden

Fixing the Industry

Penetration testing has been a skill (some say an art) for as long as we can remember information security and the computer industry. Nevertheless, over the past decade or so, the term has been completely ambiguated. It has been cannibalized, commercialized, and transformed into a market where charlatans and professionals are on the same playing field.

Commercializing security tools and Compliance are giving the industry a double-blow

STANDARDS

Page 401/2011 (1) April http://pentestmag.com 01/2011 (1) April http://pentestmag.com

perceived by an investigative attacker. A lot of information is being spilled out through unauthorized (and seemingly legitimate) channels, social media, and just plain old bad policies. It is crucial for the tested organization to see exactly what information is available out there in order to either prepare for such information being used against them or fix any policy/training gaps that it may have in relation to information disclosure. Until this exercise is performed, most companies do not understand the gravity of the information that can be collected about them. For example: If a tester can identify that the customer is using an unpatched version of Acrobat (found through the analysis of metadata within a published document), they are a prime candidate for a client side/malicious file attachment attach. Also, if there are sensitive documents published on corporate directed locations, it may pose an even bigger risk (i.e. VPN Login instructions on a public webserver; Yes…we ran into these many times in the past).

The information and intelligence gathering phase aims to gather as much information as possible about the target and fully explore the increased threat surface to attack. The standard covers digital collection through open source intelligence resources as well as paid for resources, physical on-site collection and observation, and human intelligence collection. After all, the more a tester has to attack the more comprehensive the results will be. This is the most aggressive approach available but will not be required for all strengths of tests. It’s important to note that the standard will also define levels or strength of operations within each section – which would allow small engagements to employ the more standard OSINT (Open Source Intelligence) methods, and larger scale or higher level/strength engagements to include the more elaborate on-site, physical and HUMINT (Human Intelligence) elements.

Threat ModelingThe threat-modeling section provides the tester and the organization with clear documentation of the relevant threat communities as well as the assets and their values. The threat modeling is performed around two central lines – the attacker, and the business assets. From an attacker perspective, all the relevant threat communities are identified, researched, documented, and their capabilities are fully analyzed and documented.

From a business asset perspective, all the critical business assets (physical, logical, process, 3rd party, intellectual, etc.) are identified. During the documentation phase of these assets, every relevant supporting technology system is mapped, along with the relevant personnel, interaction, processing, and the information lifecycle.

The main output from this phase is a well-documented threat model that takes into account the data gathered

standard for penetration testing for organizations as small as a 15 people company, and as large as a government agency or a nation’s critical infrastructure.

The standard spans seven sections that define the content of a penetration test. These sections cover everything from how to formalize the engagement legally and commercially, up to what areas the final report should cover. Following is an overview of the seven sections and what they reflect in terms of how a penetration test should be conducted.

Pre-Engagement interactionIn this section the standard defines some basic rules of engagement, scoping, points of contact, and most importantly goals for the engagement. It is often neglected and overlooked (as in our previous example of two pentest units – that are usually followed by a website or an IP address to be tested), and one of the main reasons for organizations not getting any value out of such testing. The section goes on to define what are the allowed resources that the tester can utilize in the business, and the tester is given an opportunity to gain a better understanding of what is the business aspect that is being scrutinized, and what are the real goals of the test (which are NEVER a server, an application, or even a network). In addition to the goal/value oriented approach of the tester, the organizations receiving the test (customer) will also be able to reference this section. The customer will be able to set guidelines for the test, understand the safeguards put in place and have a full understanding of the communication pathways that will be open throughout the test. Often times, customers do not have the appropriate channel of communication with the testing group and it causes confusion in the testing process. We aim to make the goals and tests performed clear to both sides well before the testing begins.

Information and Intelligence GatheringIn this section the standard really kicks in. This is where we were receiving the most comments in the lines of this is too expensive, we don’t know how to do this, and this is not really necessary. From our collective experience (at least the founding team) we can clearly state that when this phase is done right, we can already know the outcome of the pentest. During the intelligence-gathering phase, the tester aims to build a comprehensive as possible picture of the target organization. Everything from corporate information, the vertical in which the organization is operating in, business processes that are crucial to the business, financial information and all the way up to mapping out specific personnel, their online social presence and how to use all of that information in a way that an attacker would use. On the other hand, the organization being tested will finally get a clear overview of how it is being

STANDARDS


and analyzed at the intelligence gathering phase, and can be used to create attack trees and map out venues for vulnerability analysis of key processes and technologies. This is another key component to providing value in Penetration Testing. If the customer does not know what the threat is to the business or the actual risk, why should they resolve the issue. Threat Modeling provides a weighting system so that testers can rely less on a screenshot of a shell and more on the overall value to the business.

Vulnerability AnalysisOnly at this stage we run into what more traditional penetration tests actually include in their scope. As we can clearly see, the new penetration testing execution standard provides a much more thorough background – both from a business understanding, as well as from a technical perspective to the test. Leveraging this extensive research, the vulnerability analysis phase (which can sometimes be considered as a technology centric threat modeling) defines the extensive coverage of mapping out and documenting any vulnerability in processes, physical infrastructure, and of course technology related elements. This phase does include some interaction with the organization, as the testers probe for services and equipment, confirm assumptions made at the threat modeling and intelligence gathering phases, and fingerprint the underlying software being deployed.

One of the deliverables from this phase (on top of the actual vulnerability mapping and assertion) is attack trees that correspond to the entire process thus far. This by itself can provide a lot of value to the organization as a living document that can be updated with relevant threats, vulnerabilities and exposure that is used as one of the parameters for the ongoing risk management practice.

Mind you, this is not just running a scan or port mapping. This is a comprehensive process to analyze the data collected for attack routes as well as identify venues for attacks. The tester will leverage conventional and unconventional ways to identify vulnerabilities from missing patches, open services, misconfigurations, default passwords, Intellectual Property leakage, increased threat through information (leaked passwords/docs), and much more. This hybrid approach allows the testers to collect actionable information and rank the ease of attacks. Once the tester has analyzed the potential vulnerabilities present, they will have a clear picture of what/why/how/where and when to execute attacks to confirm the validity of that vulnerability.

ExploitationThe exploitation section is very close to the common scope of penetration tests these days. It includes the actual attack execution against the organization. With all the proper

intelligence, threat modeling and vulnerability analysis in place; this phase becomes much more focused and more importantly much more fine-tuned to the organization being tested. In a proper penetration test, we should not just see spread-spectrum scans and exploitation attempts on every conceivable technology from a tool or two, but also (and again – much more importantly) a dedicated attack path that lends from the true assets that the organization holds and the specific vulnerabilities (either technology related or human/process related). This type of validation is a process that is often lost in the throw all the attacks we have at it type automation. Here, the standard aims to act on the vulnerabilities identified and confirm or refute their existence. Many testers and testing tools, due to lack of actionable intelligence or poor planning, will run exploits against hosts that do not have the exploitable package running or even installed. This causes undue increased traffic and potential risk to the business environment.

Post-ExploitationAt this point most pentests conclude the engagement and provide a report that includes every finding with some sort of traffic light rating (low, medium, high...) that is pre-baked into the reporting tool. However, real world attacks would not suffice in getting a foothold inside the organization, and would try to leverage it further – either trying to obtain additional information/resources, or to actually find a way to exfiltrate the information/control outside of the organization. The exfiltration and access to the data types or control systems will fit directly into the threat modeling conducted earlier in the process. The tester will be able to show the real company impact of certain attacks and why they are relevant to the company (i.e. there is a big difference in showing an executive a screenshot of a shell than showing them the interface THEY use to change the General Ledger within the ERP system. This type of focus provides an instant impact and is formatted in the language that makes sense to the business).

The post-exploitation phase defines the scope of such additional tasks, that provide the organization with a way to see how would it really stand up to such an attack, and whether it would be able to identify related data breaches and leaks. Conducting this focused attack on resources paints a very clear and concise picture of the threats capability and its possible effects on the business as a whole.

ReportingFinally – this trip through an attackers modus-operandi needs to be concluded with a clear and useful report, for the organization to actually see value from such an engagement. The value is not limited to documenting

STANDARDS


the technical gaps that need to be addressed, but also needs to provide a more executive-level report that reflects the organization’s exposure to loss in business terms (financial). This would include the actual meaning of which assets are at the highest risk, how much resources are used to protect different assets, and a recommendation on how to more efficiently close any gaps in exposure by spending resources on controls and protections more intelligently.

Such a recommendation would not have been possible without the surrounding activities that provide the business relevance of the exercise and the tested business elements. This is also where the organization would end up finding the most value out of the engagement, as opposed to most common pentests which leave it with a laundry-list of exploits and vulnerabilities, without their actual relevance or business impact. In the report, the tester will be required to identify the symptomatic vulnerabilities (like a patch missing) as well as tie out the systemic vulnerabilities – a patch is missing BECAUSE there are gaps in policy and procedure in x/y/z area which allowed for the patch to not be installed in a timely manner or within the specified time)

It’s important to note that although there isn’t a dedicated section for detection and incident response, the organizations capabilities to identify, and react to anything from the intelligence gathering, through the vulnerability analysis, exploitation and post exploitation is also put to the test. The penetration test includes direct references to such capabilities in each section (as well as in the reporting section), and can be extremely useful to clearly identify the organization maturity in terms of risk management and handling. This provides

an additional value to the customer as they are allowed to test the effectiveness of their defensive monitoring systems and/or outsources solutions.

At the end of the day, the forces of the industry will dictate what a penetration test will look like and what would it contain. Nevertheless, the PTES is aimed to provide the industry with a baseline it clearly lacks now. The term has been mutated over many iterations and it has been given a very narrow freedom to operate between the minimum that has been dictated by regulatory requirements (which did good and actually forced more businesses to test themselves), and the “glass ceiling” that has been created de-facto by the hordes of pentesters that know nothing better than using some product to push out a report to the customer and move on to the next. By clearly defining the term (which is used in a multitude of standards without an adequate definition of what it means or consists of) and what the purpose, value and components of a Penetration Test are, PTES will increase the confidence of customers and testers alike. For quite some time

now, organizations expect the value of conducting a Penetration test to be not

much more than a rubber stamp on the audit report or a ticked checkbox on their compliance worksheet. PTES is attempting to increase that value and blow some wind into the dwindling sails of what once was a critical part of running a secure operations. In the modern days where everyone being so easily hacked by an APT isn’t it time our testers start acting like one? Or would you rather an Automated Penetration Test (APT) that you pay for and does not even attempt to learn WHY they are doing the test in the first place?

IFTACH IAN AMITbrings over a decade of experience in the security industry, and a mixture of software development, OS, network and Web security expertise as Vice President Consulting to the top-tier security consulting firm Security-Art. Prior to Security-Art, Ian was the Director of Security Research at Aladdin and Finjan. Ian has also held leadership roles as founder and CTO of a security startup in the IDS/IPS arena, and a director at Datavantage. Prior to Datavantage, he managed the Internet Applications as well as the UNIX departments at the security consulting firm Comsec.Ian is a frequent speaker at the leading industry conferences such as BlackHat, DefCon, Infosec, Hacker-Halted, FIRST, BruCon, SOURCE, ph-neutral, and many more.

CHRIS NICKERSONChris Nickerson, CEO of LARES, is just another Security guy with a whole bunch of certs whose main area of expertise is focused on Real world Attack Modeling, Red Team Testing and Infosec Testing. At Lares, Chris leads a team of security professional who conduct Risk Assessments, Penetration testing, Application Testing, Social Engineering, Red Team Testing and Full Adversarial Attack Modeling. Prior to starting Lares, Chris was Dir. of Security Services at Alternative Technology, a Sr. IT compliance at KPMG, Sr. Security Architect and Compliance Manager at Sprint Corporate Security. Chris is a member of many security groups and was also a featured member of TruTV’s Tiger Team. Chris is the cohost of the Exotic liability Podcast, the author of the upcoming RED TEAM TESTING book published by Elsevier/Syngress and a founding member of BSIDES Conference.

Measuring detection and incident response is an integrated part of a penetration test

HOW-TO


Penetration Testing these days is often done on a one-off basis, meaning companies do them once a month, once a quarter or once a year

and then never think about them again. I find that to be a shame and think that penetration testing can be an invaluable tool in vulnerability management when performed properly.

One of my hobbies/passions/interests/whatever in the industry is finding a way to effectively operationalize security. That is, moving security out of the this is theoretically possibly realm and into the hey, we should fix this because it’s happening now realm. Part of this, I think, is finding a way to utilize the tools used by our compatriots in the network and applications management domains. This article will use two very popular (well... one very popular and one really-should-be popular) tools in the network monitoring and application monitoring spaces respectively. This will give us a way to display that the vulnerabilities from the report still exist as reported and measure the response/remediation time.

Tools Needed: • Icinga (http://www.icinga.org) – A fork of the

popular Nagios (www.nagios.org) monitoring suite. • Webinject (http://www.webinject.org) – A very

powerful Perl script tool that allows you to build test cases for web applications.

• DVWA – Damn Vulnerable Web Application (http://www.randomstorm.com/dvwa-security-tool.php) – An intentionally naughty web application.

• A Linux operating system. I used Ubuntu 10.10 for everything, but you may use what you wish.

You will obviously need network connectivity between the machines and virtual machines are recommended for this exercise. You will also have to be able to talk to the web application on the desired ports (typically ports 80, 443).

Setting up these tools is beyond the scope of this article, but the installation documentation for all three tools is excellent, plus there are LiveCDs for two out of the three of them, so go ahead and get your environment set-up.

In our theoretical world, let’s pretend we just received a penetration test report that our web application (DVWA) has a weak password associated with it. For this example the login is admin/password. We begin by using Webinject to test that the login does indeed work. This is done by creating a testcase in Webinject language: see Listing 1.

The first test, cleverly given the id of ‘1’, verifies that the login.php page loads correctly, we want to be sure it’s there before we try to login to it. The second test then posts our username (admin) and our weak password to login.php and then verifies we can see

Operationalize Penetration Testing Results Using Network Monitoring Software – All For Free

We will model the results of a penetration test using network and application monitoring tools. The end result will be a dashboard showing you the vulnerabilities that still exist and the ones that have been remediated. This gives you a quick view of your vulnerabilities and the speed with which they’re resolved.

http://www.icinga.org

http://www.nagios.org

http://www.webinject.org

http://www.randomstorm.com/dvwa-security-tool.php

http://www.randomstorm.com/dvwa-security-tool.php

HOW-TO


you on how fast vulnerabilities are getting resolved. This can be a powerful tool in your arsenal and it speaks the languages of your network and application teams, as well as, articulating the vulnerabilities to your security team while, providing metrics for your business team.

the content behind the login. We can further extend this to test cases encompassing everything on our reports. SQL Injections, XSS bugs, etc., can all be modeled this way and monitored for. The beauty of using Webinject is it allows us to use it easily as a nagios/Icinga plugin. Simply add <reporttype>nagios</reporttype> to config.xml and you will get nagios/Icinga compatible output.

Now you could very easily be done at this point. You have some test cases to run that verifies the issues found in the report. You could put this in a cron job that emails you the status every couple of days and be perfectly happy. However, with a little more work you can integrate this verification with Icinga and then have a near real-time dashboard showing the status of your remediation efforts. This integration will do a few things for you, most importantly, it will provide some perspective on how much badness was really found during your penetration test. It will also add some accountability as you can break up the dashboard by responsible groups. This way the server administrators can see what is going on with the servers and the application team can see just the applications. Finally, it can provide some reporting for

BILL MATHEWSBill Mathews is co-founder and lead geek of Hurricane Labs, an information security firm founded in 2004. Bill wrote this article while recovering from pneumonia so any errors are purely the result of medication. :-) You can reach Bill @billford on Twitter and be read other musings on http://blog.hurricanelabs.com

Listing 1.

---testcases.xml

<testcases repeat="1">

<case

id="1"

description1="Load Login Page"

description2="verify Page Loads"

method="get"

url="http://192.168.38.156/login.php"

verifypositive="Damn Vulnerable Web Application"

/>

<case

id="2"

description1="Verify Weak Login Works"

method="post"

url="http://192.168.38.156/login.php"

postbody="username=admin&password=password"

verifypostive="Welcome to Damn Vulnerable Web App"

/>

</testcases>

SecurityArt'sRedTeamserviceoperatesonallfrontsonbehalfoftheorganiza�on,evalua�ngallinforma�onsecuritylayersforpossiblevulnerabili�es.

OnlyRedTeamtes�ngprovidesyouwithlivefeedbackonthetruelevelofyourorganiza�onalsecurity.

Thinkingcrea�vely!That’sourapproachtoyourtest.

SecurityArt’sRed-Teammethodologyconsistsof:

1.Informa�onandintelligencegathering2.Threatmodeling3.Vulnerabilityassessment4.Exploita�on5.Riskanalysisandquan�fica�onofthreatstomonetaryvaluesthreatstomonetaryvalues6.Repor�ng

Readytoseeactualbenefitsfromyournextsecurityreview?

[email protected]

OrcallUSTollfree:18003003909UKTollfree:0808101272208081012722

www.security-art.com

SayHellotoRedTeamTes�ng!

��

��

� � � � � � � � � � � � � � � � � � � � �

��

��

��

��

� � � � � � � � � � � � � � � � � � � � �

Penetration Testing Magazine

Education

Transcript of Penetration Testing Magazine