Building Virtual Pentesting Labs for Advanced Penetration Testing - Second Edition E-Book
Kevin Cardwell
50,39 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Learn how to build complex virtual architectures that allow you to perform virtually any required testing methodology and perfect it
About This Book
- Explore and build intricate architectures that allow you to emulate an enterprise network
- Test and enhance your security skills against complex and hardened virtual architecture
- Learn methods to bypass common enterprise defenses and leverage them to test the most secure environments.
Who This Book Is For
While the book targets advanced penetration testing, the process is systematic and as such will provide even beginners with a solid methodology and approach to testing.
You are expected to have network and security knowledge. The book is intended for anyone who wants to build and enhance their existing professional security and penetration testing methods and skills.
What You Will Learn
- Learning proven security testing and penetration testing techniques
- Building multi-layered complex architectures to test the latest network designs
- Applying a professional testing methodology
- Determining whether there are filters between you and the target and how to penetrate them
- Deploying and finding weaknesses in common firewall architectures.
- Learning advanced techniques to deploy against hardened environments
- Learning methods to circumvent endpoint protection controls
In Detail
Security flaws and new hacking techniques emerge overnight – security professionals need to make sure they always have a way to keep . With this practical guide, learn how to build your own virtual pentesting lab environments to practice and develop your security skills. Create challenging environments to test your abilities, and overcome them with proven processes and methodologies used by global penetration testing teams.
Get to grips with the techniques needed to build complete virtual machines perfect for pentest training. Construct and attack layered architectures, and plan specific attacks based on the platforms you're going up against. Find new vulnerabilities for different kinds of systems and networks, and what these mean for your clients.
Driven by a proven penetration testing methodology that has trained thousands of testers, Building Virtual Labs for Advanced Penetration Testing, Second Edition will prepare you for participation in professional security teams.
Style and approach
The book is written in an easy-to-follow format that provides a step–by-step, process-centric approach. Additionally, there are numerous hands-on examples and additional references for readers who might want to learn even more. The process developed throughout the book has been used to train and build teams all around the world as professional security and penetration testers.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 463
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Building Virtual Pentesting Labs for Advanced Penetration Testing - Second Edition
Building Virtual Pentesting Labs for Advanced Penetration Testing - Second Edition
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2014
Second edition: August 2016
Production reference: 1240816
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-78588-349-1
www.packtpub.com
Credits
Authors
Kevin Cardwell
Copy Editors
Madhusudan Uchil
Reviewer
Joseph Muniz
Project Coordinator
Judie Jose
Commissioning Editor
Kartikey Pandey
Proofreader
Safis Editing
Acquisition Editor
Kirk D'costa
Indexer
Hemangini Bari
Content Development Editor
Abhishek Jadhav
Graphics
Kirk D'Penha
Technical Editor
Vishal K. Mewada
Production Coordinator
Shantanu Zagade
About the Author
Kevin Cardwell is currently working as a freelance consultant and provides consulting services for companies throughout the world, and he also works as an advisor to numerous government entities within the USA, the Middle East, Africa, Asia, and the UK. He is an instructor, technical editor, and author for computer forensics and hacking courses. He is the author of the Center for Advanced Security and Training (CAST), Advanced Network Defense, and Advanced Penetration Testing courses. He is technical editor of the Learning Tree Course Penetration Testing Techniques and Computer Forensics courses. He has presented at the Black Hat USA, Hacker Halted, ISSA, and TakeDownCon conferences as well as many others. He has chaired the Cybercrime and Cyber Defense Summit in Oman and was the executive chairman of the Oil and Gas Cyber Defense Summit. He is the author of Building Virtual Pen testing Labs for Advanced Penetration Testing, 1st Edition, Advanced Penetration Testing for Highly Secured Environments, Second Edition, and Backtrack: Testing Wireless Network Security. He holds a bachelor of science degree in computer science from National University in California and a master’s degree in software engineering from the Southern Methodist University (SMU) in Texas. He developed the strategy and training development plan for the first Government CERT in the country of Oman that recently was rated as the top CERT for the Middle East. He serves as a professional training consultant to the Oman Information Technology Authority, and he developed the team to man the first Commercial Security Operations Center in the country of Oman. He has worked extensively with banks and financial institutions throughout the Middle East, Europe, and the UK in the planning of a robust and secure architecture and implementing requirements to meet compliance. He currently provides consultancy to Commercial companies, governments, federal agencies, major banks, and financial institutions throughout the globe. Some of his recent consulting projects include the Muscat Securities Market (MSM), Petroleum Development Oman, and the Central Bank of Oman. He designed and implemented the custom security baseline for the existing Oman Airport Management Company (OAMC) airports and the two new airports opening in 2016 as well as for the Oman Telephone Company. He created custom security baselines for all of the Microsoft Operating Systems, Cisco devices, as well as applications.
Acknowledgments
This book is dedicated to all of the students I have had over the years. Each class is a new learning experience, and taking from that is how a book like this gets created. I would also like to thank Loredana, Aspen, and my family for all of their support, which makes this book possible.
About the Reviewer
Joseph Muniz is an architect at Cisco Systems and a security researcher. He started his career in software development and later managed networks as a contracted technical resource. He moved into consulting and found a passion for security while meeting with a variety of customers. He has been involved in the design and implementation of multiple projects, ranging from Fortune 500 corporations to large federal networks. He has spoken at popular security conferences such as RSA, DEFCON, and Cisco Live on various topics. You can learn more about him by visiting his blogs at http://www.thesecurityblogger.com/.
Joseph has authored the following books as well as contributing to many other publications:
I would like to give a huge thank you to my friends and family for supporting me in this and my other crazy projects. This book goes out to Irene Muniz, Ray Muniz, Alex and Martha Muniz, Raylin Muniz, my friends at Cisco, and the many other great people in my life.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Preface
This book will provide you with a systematic process to follow when building a virtual environment to practice penetration testing. This book teaches you how to build the architecture, identify the latest vulnerabilities, and test them in your own environment before you use them in a production environment. This allows you to build, enhance, and hone your penetration-testing skills.
What this book covers
Chapter 1, Introducing Penetration Testing, provides an introduction to what pen testing is and explains how a component of professional security testing and it is the validation of vulnerabilities. By understanding penetration testing, we can prepare for providing professional security testing services to our clients.
Chapter 2, Choosing the Virtual Environment, explores the different types of virtualization technologies and introduces a number of different options. We then compare and contrast and select our software for our range.
Chapter 3, Planning a Range, takes you through the process of what is required to plan a test environment. Professional testing is all about planning and practicing against different vulnerabilities. We review the planning techniques of the professional security tester.
Chapter 4, Identifying Range Architectures, defines the composition of a range and creating a network structure. This structure allows you great flexibility when it comes to connecting components and expanding the range to emulate complex architectures.
Chapter 5, Identifying a Methodology, explores a sample group of a number of testing methodologies. Information will be provided so that you can make a comparison, adapt a methodology, and customize it to your engagement requirements.
Chapter 6, Creating an External Attack Architecture, builds a layered architecture and follows a systematic process and methodology for conducting an external test. Additionally, you will deploy protection measures and carry out testing to see how effective the protection measures are by using the methods of an attacker to evade and bypass protection measures.
Chapter 7, Assessment of Devices, presents challenges against testing devices. This chapter includes techniques for testing weak filtering as well as methods of penetrating various defenses that might be encountered when testing.
Chapter 8, Architecting an IDS/IPS Range, investigates deployment of the Snort IDS and a number of host-based security protections. Once deployed, a number of evasion techniques are explored for evading the threshold settings of the IDS.
Chapter 9, Assessment of Web Servers and Web Applications, provides us with information on one of the most popular attack vectors, one that is accessible in virtually any environment. Almost all organizations require some form of online presence. Therefore, it is a good bet that we will have a web server and probably some web applications that we can use to attempt to compromise a client system and/or network.
Chapter 10, Testing Flat and Internal Networks, provides us with details on how, when we perform internal or white-box testing, we do not face the same challenges that we face when trying to conduct an external or black-box test. This does not mean we do not face challenges when the network is flat and we are inside it—they are just different from the other testing methods.
Chapter 11, Testing Servers, provides us with information about the ways in which we can target and, hopefully, penetrate the servers that we encounter when testing. As the target is a server, we could potentially obtain access via an OS vulnerability or a flaw in an application that is running.
Chapter 12, Exploring Client-Side Attack Vectors, provides us with information about the ways in which we can target clients. We will explore different methods of attacking a client. We will also explore how social engineering is a major attack vector.
Chapter 13, Building a Complete Cyber Range, provides us with a complete architecture that we can use to perform our testing. This design will allow us to plug in any required components that we might have. Furthermore, it will provide us with the capability to test using any type of testing methodology.
What you need for this book
The examples in the book predominantly use VMWare Workstation and Kali Linux. These are the minimum requirements. Additional software is introduced, and references to obtain the software are provided.
Who this book is for
This book is for anyone who works or wants to work as a professional security tester. The book establishes a foundation and teaches a systematic process of building a virtual lab environment that enables the testing of virtually any environment that you might encounter in pen testing.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from http://www.packtpub.com/sites/default/files/downloads/BuildingVirtualPentestingLabsforAdvancedPenetrationTesting_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Chapter 1. Introducing Penetration Testing
In this chapter, we will discuss the role that pen testing plays in the professional security testing framework. We will discuss the following topics:
If you have been doing penetration testing for some time and are very familiar with the methodology and concept of professional security testing, you can skip this chapter or just skim it. But you might learn something new or at least a different approach to penetration testing. We will establish some fundamental concepts in this chapter.
Security testing
If you ask 10 consultants to define what security testing is today, you will more than likely get a variety of responses. Here is the Wikipedia definition:
"Security testing is a process and methodology to determine that an information system protects and maintains functionality as intended."
In my opinion, this is the most important aspect of penetration testing. Security is a process and not a product. I'd also like to add that it is a methodology and not a product.
Another component to add to our discussion is the point that security testing takes into account the main areas of a security model. A sample of this is as follows:
Each one of these components has to be considered when an organization is in the process of securing their environment. Each one of these areas in itself has many subareas that also have to be considered when it comes to building a secure architecture. The lesson is that when testing security, we have to address each of these areas.
Authentication
It is important to note that almost all systems and/or networks today have some form of authentication and, as such, it is usually the first area we secure. This could be something as simple as users selecting a complex password or us adding additional factors to authentication, such as a token, biometrics, or certificates. No single factor of authentication is considered to be secure by itself in today's networks.
Authorization
Authorization is often overlooked since it is assumed and not a component of some security models. That is one approach to take, but it's preferred to include it in most testing models, as the concept of authorization is essential since it is how we assign the rights and permissions to access a resource, and we would want to ensure it is secure. Authorization enables us to have different types of user with separate privilege levels coexist within a system. We do this when we have the concept of discretionary access, where a user can have administrator privileges on a machine or assume the role of an administrator to gain additional rights or permissions, whereas we might want to provide limited resource access to a contractor.
Confidentiality
Confidentiality is the assurance that something we want to be protected on the machine or network is safe and not at risk of being compromised. This is made harder by the fact that the protocol (TCP/IP) running the Internet today is a protocol that was developed in the early 1970s. At that time, the Internet consisted of just a few computers, and now, even though the Internet has grown to the size it is today, we are still running the same protocol from those early days. This makes it more difficult to preserve confidentiality. It is important to note that when the developers created the protocol and the network was very small, there was an inherent sense of trust regarding who you could potentially be communicating with. This sense of trust is what we continue to fight from a security standpoint today. The concept from that early creation was and still is that you can trust that data received is from a reliable source. We know now that the Internet is at this huge size and that is definitely not the case.
Integrity
Integrity is similar to confidentiality, in that we are concerned with the compromising of information. Here, we are concerned with the accuracy of data and the fact that it is not modified in transit or from its original form. A common way of doing this is to use a hashing algorithm to validate that the file is unaltered.
Availability
One of the most difficult things to secure is availability, that is, the right to have a service when required. The irony of availability is that a particular resource is available to one user, and it is later available to all. Everything seems perfect from the perspective of an honest/legitimate user. However, not all users are honest/legitimate, and due to the sheer fact that resources are finite, they can be flooded or exhausted; hence, is it more difficult to protect this area.
Non-repudiation
Non-repudiation makes the claim that a sender cannot deny sending something after the fact. This is the one I usually have the most trouble with, because a computer system can be compromised and we cannot guarantee that, within the software application, the keys we are using for the validation are actually the ones being used. Furthermore, the art of spoofing is not a new concept. With these facts in our minds, the claim that we can guarantee the origin of a transmission by a particular person from a particular computer is not entirely accurate.
Since we do not know the state of the machine with respect to its secureness, it would be very difficult to prove this concept in a court of law.
All it takes is one compromised machine, and then the theory that you can guarantee the sender goes out the window. We won't cover each of the components of security testing in detail here, because that is beyond the scope of what we are trying to achieve.
The point I want to get across in this section is that security testing is the concept of looking at each and every one of these and other components of security, addressing them by determining the amount of risk an organization has from them, and then mitigating that risk.
An abstract testing methodology
As mentioned previously, we concentrate on a process and apply that to our security components when we go about security testing. For this, I'll describe an abstract methodology here. We shall cover a number of methodologies and their components in great detail in Chapter 4, Identifying Range Architectures, wherein we will identify a methodology by exploring the available references for testing.
We will define our testing methodology as consisting of the following steps:
Planning
Planning is a crucial step of professional testing. But, unfortunately, it is one of the steps that is rarely given the time that is essentially required. There are a number of reasons for this, but the most common one is the budget: clients do not want to provide consultants days and days to plan their testing. In fact, planning is usually given a very small portion of the time in the contract due to this reason. Another important point about planning is that a potential adversary is going to spend a lot of time on it. There are two things we should tell clients with respect to this step that as a professional tester we cannot do but an attacker could:
Nonintrusive target search
There are many names that you will hear for nonintrusive target search. Some of these are open source intelligence, public information search, and cyber intelligence. Regardless of which name you use, they all come down to the same thing: using public resources to extract information about the target or company you are researching. There is a plethora of tools that are available for this. We will briefly discuss those tools to get an idea of the concept, and those who are not familiar with them can try them out on their own.
Nslookup
The nslookup tool can be found as a standard program in the majority of the operating systems we encounter. It is a method of querying DNS servers to determine information about a potential target. It is very simple to use and provides a great deal of information. Open a command prompt on your machine and enter nslookup www.packtpub.com. This will result in output such as the following screenshot:
As you can see, the response to our command is the IP address of the DNS server for the www.packtpub.com domain. If we were testing this site, we would have explored this further. Alternatively, we may also use another great DNS-lookup tool called dig. For now, we will leave it alone and move to the next resource.
Central Ops
The https://centralops.net/co/ website has a number of tools that we can use to gather information about a potential target. There are tools for IP, domains, name servers, e-mail, and so on. The landing page for the site is shown in the next screenshot:
The first thing we will look at in the tool is the ability to extract information from a web server header page: click on TcpQuery, and in the window that opens, enter www.packtpub.com and click on Go. An example of the output from this is shown in the following screenshot:
As the screenshot shows, the web server banner has been modified and says packt. If we do additional queries against the www.packtpub.com domain, we have determined that the site is using the Apache web server, and the version that is running; however, we have much more work to do in order to gather enough information to target this site. The next thing we will look at is the capability to review the domain server information. This is accomplished by using the domain dossier. Return to the main page, and in the Domain Dossier dialog box, enter yahoo.com and click on go. An example of the output from this is shown in the following screenshot:
There are many tools we could look at, but again, we just want to briefly acquaint ourselves with tools for each area of our security testing procedure. If you are using Windows and you open a command prompt window and enter tracert www.microsoft.com, you will observe that it fails, as indicated in this screenshot:
The majority of you reading this book probably know why this is blocked; for those of you who do not, it is because Microsoft has blocked the ICMP protocol, which is what the tracert command uses by default. It is simple to get past this because the server is running services; we can use those protocols to reach it, and in this case, that protocol is TCP. If you go to http://www.websitepulse.com/help/testtools.tcptraceroute-test.html and enter www.microsoft.com in the IP address/domain field with the default location and conduct the TCP Traceroute test, you will see it will now be successful, as shown in the following screenshot:
As you can see, we now have additional information about the path to the potential target; moreover, we have additional machines to add to our target database as we conduct our test within the limits of the rules of engagement.
The Wayback Machine
The Wayback Machine is proof that nothing that has ever been on the Internet leaves! There have been many assessments in which a client informed the team that they were testing a web server that hadn't placed into production, and when they were shown the site had already been copied and stored, they were amazed that this actually does happen. I like to use the site to download some of my favorite presentations, tools, and so on, that have been removed from a site or, in some cases, whose site no longer exists. As an example, one of the tools used to show students the concept of steganography is the infostego tool. This tool was released by Antiy Labs, and it provided students an easy-to-use tool to understand the concepts. Well, if you go to their site at http://www.antiy.net/, you will find no mention of the tool—in fact, it will not be found on any of their pages. They now concentrate more on the antivirus market. A portion from their page is shown in the following screenshot:
Now, let's try and use the power of the Wayback Machine to find our software. Open the browser of your choice and go to www.archive.org. The Wayback Machine is hosted there and can be seen in the following screenshot:
As indicated, there are 491 billion pages archived at the time of writing this book. In the URL section, enter www.antiy.net and hit Enter. This will result in the site searching its archives for the entered URL. After a few moments, the results of the search will be displayed. An example of this is shown in the following screenshot:
We know we don't want to access a page that has been recently archived, so to be safe, click on 2008. This will result in the calendar being displayed and showing all the dates in 2008 on which the site was archived. You can select any one that you want; an example of the archived site from December 18 is shown in the following screenshot: as you can see, the infostego tool is available, and you can even download it! Feel free to download and experiment with the tool if you like.
Shodan
The Shodan site is one of the most powerful cloud scanners available. You are required to register with the site to be able to perform the more advanced types of queries. To access the site, go to https://www.shodan.io/. It is highly recommended that you register, since the power of the scanner and the information you can discover is quite impressive, especially after registration. The page that is presented once you log in is shown in the following screenshot:
The screenshot shows recently shared search queries as well as the most recent searches the logged-in user has conducted. This is another tool you should explore deeply if you do professional security testing. For now, we will look at one example and move on, since an entire book could be written just on this tool. If you are logged in as a registered user, you can enter iphone us into the search query window. This will return pages with iphone in the query and mostly in the United States, but as with any tool, there will be some hits on other sites as well.
An example of the results of this search is shown in the following screenshot:
Intrusive target search
This is the step that starts the true hacker-type activity. This is when you probe and explore the target network; consequently, ensure that you have with you explicit written permission to carry out this activity.
Tip
Never perform an intrusive target search without permission, as this written authorization is the only aspect which differentiates you and a malicious hacker. Without it, you are considered a criminal like them.
Within this step, there are a number of components that further define the methodology.
Find live systems
No matter how good our skills are, we need to find systems that we can attack. This is accomplished by probing the network and looking for a response. One of the most popular tools to do this with is the excellent open source tool nmap, written by Fyodor. You can download nmap from https://nmap.org/, or you can use any number of toolkit distributions for the tool. We will use the exceptional penetration-testing framework Kali Linux. You can download the distribution from https://www.kali.org/. Regardless of which version of nmap you explore with, they all have similar, if not the same, command syntax. In a terminal window, or a command prompt window if you are running it on Windows, type nmap -sP <insert network IP address>. The network we are scanning is the 192.168.4.0/24 network; yours will more than likely be different. An example of this ping sweep command is shown in the following screenshot:
We now have live systems on the network that we can investigate further. For those of you who would like a GUI tool, you can use Zenmap.
Discover open ports
Now that we have live systems, we want to see what is open on these machines. A good analogy to a port is a door, and it's that if the door is open, I can approach it. There might be things that I have to do once I get to the door to gain access, but if it is open, then I know it is possible to get access, and if it is closed, then I know I cannot go through that door. Furthermore, we might need to know the type of lock that is on the door, because it might have weaknesses or additional protection that we need to know about. The same is with ports: if they are closed, then we cannot go into that machine using that port. We have a number of ways to check for open ports, and we will continue with the same theme and use nmap. We have machines that we have identified, so we do not have to scan the entire network as we did previously-we will only scan the machines that are up. Additionally, one of the machines found is our own machine; therefore, we will not scan ourselves—we could, but it's not the best plan. The targets that are live on our network are 1, 2, 16, and 18. We can scan these by entering nmap -sS 192.168.4.1,2,16,18. Those of you who want to learn more about the different types of scans can refer to http://nmap.org/book/man-port-scanning-techniques.html. Alternatively, you can use the nmap -h option to display a list of options. The first portion of the stealth scan (not completing the three-way handshake) result is shown in the following screenshot:
Discover services
We now have live systems and openings that are on the machine. The next step is to determine what, if anything, is running on the ports we have discovered and it is imperative that we identify what is running on the machine so that we can use it as we progress deeper into our methodology. We once again turn to nmap. In most command and terminal windows, there is history available; hopefully, this is the case for you and you can browse through it with the up and down arrow keys on your keyboard. For our network, we will enter nmap -sV 192.168.4.1. From our previous scan, we've determined that the other machines have all scanned ports closed, so to save time, we won't scan them again. An example of this is shown in the following screenshot:
From the results, you can now see that we have additional information about the ports that are open on the target. We could use this information to search the Internet using some of the tools we covered earlier, or we could let a tool do it for us.
Enumeration
Enumeration is the process of extracting more information about the potential target to include the OS, usernames, machine names, and other details that we can discover. The latest release of nmap has a scripting engine that will attempt to discover a number of details and in fact enumerate the system to some aspect. To process the enumeration with nmap, use the -A option. Enter nmap -A 192.168.4.1. Remember that you will have to enter your respective target address, which might be different from the one mentioned here. Also, this scan will take some time to complete and will generate a lot of traffic on the network. If you want an update, you can receive one at any time by pressing the spacebar. This command's output is quite extensive; so a truncated version is shown in the following screenshot:
As you can see, you have a great deal of information about the target, and you are quite ready to start the next phase of testing. Additionally, we have the OS correctly identified; until this step, we did not have that.
Identify vulnerabilities
After we have processed the steps up to this point, we have information about the services and versions of the software that are running on the machine. We could take each version and search the Internet for vulnerabilities, or we could use a tool-for our purposes, we will choose the latter. There are numerous vulnerability scanners out there in the market, and the one you select is largely a matter of personal preference. The commercial tools for the most part have a lot more information and details than the free and open source ones, so you will have to experiment and see which one you prefer. We will be using the Nexpose vulnerability scanner from Rapid7. There is a community version of their tool that will scan a limited number of targets, but it is worth looking into. You can download Nexpose from http://www.rapid7.com/. Once you have downloaded it, you will have to register, and you'll receive a key by e-mail to activate it. I will leave out the details of this and let you experience them on your own. Nexpose has a web interface, so once you have installed and started the tool, you have to access it. You can access it by entering https://localhost:3780. It seems to take an extraordinary amount of time to initialize, but eventually, it will present you with a login page, as shown in the following screenshot:
The credentials required for login will have been created during the installation. It is quite an involved process to set up a scan, and since we are just detailing the process and there is an excellent quick start guide available, we will just move on to the results of the scan. We will have plenty of time to explore this area as the book progresses. The result of a typical scan is shown in the following screenshot:
As you can see, the target machine is in bad shape. One nice thing about Nexpose is the fact that since they also own Metasploit, they will list the vulnerabilities that have a known exploit within Metasploit.
Exploitation
This is the step of the security testing that gets all the press, and it is, in simple terms, the process of validating a discovered vulnerability. It is important to note that it is not a 100-percent successful process and some vulnerabilities will not have exploits and some will have exploits for a certain patch level of the OS but not others. As I like to say, it is not an exact science and in reality is an infinitesimal part of professional security testing, but it is fun, so we will briefly look at the process. We also like to say in security testing that we have to validate and verify everything a tool reports to our client, and that is what we try to do with exploitation. The point is that you are executing a piece of code on a client's machine, and this code could cause damage. The most popular free tool for exploitation is the Rapid7-owned tool Metasploit. There are entire books written on using the tool, so we will just look at the results of running it and exploiting a machine here. As a reminder, you have to have written permission to do this on any network other than your own; if in doubt, do not attempt it. Let's look at the options:
There is quite a bit of information in the options. The one we will cover is the fact that we are using the exploit for the MS08-067 vulnerability, which is a vulnerability in the server service. It is one of the better ones to use as it almost always works and you can exploit it over and over again. If you want to know more about this vulnerability, you can check it out here: http://technet.microsoft.com/en-us/security/bulletin/ms08-067. Since the options are set, we are ready to attempt the exploit, and as indicated in the following screenshot, we are successful and have gained a shell on the target machine. We will cover the process for this as we progress through the book. For now, we will stop here.
Here onward, it is only your imagination that can limit you. The shell you have opened is running at system privileges; therefore, it is the same as running a Command Prompt on any Windows machine with administrator rights, so whatever you can do in that shell, you can also do in this one. You can also do a number of other things, which you will learn as we progress through the book. Furthermore, with system access, we can plant code as malware: a backdoor or really anything we want. While we might not do that as a professional tester, a malicious hacker could do it, and this would require additional analysis to discover at the client's end.
Data analysis
Data analysis is often overlooked, and it can be a time-consuming process. This is the process that takes the most time to develop. Most testers can run tools and perform manual testing and exploitation, but the real challenge is taking all of the results and analyzing them. We will look at one example of this in the next screenshot. Take a moment and review the protocol analysis captured with the tool Wireshark as an analyst, you need to know what the protocol analyzer is showing you. Do you know what exactly is happening? Do not worry, I will tell you after we have a look at the following screenshot:
You can observe that the machine with the IP address 192.168.3.10 is replying with an ICMP packet that is type 3 code 13; in other words, the reason the packet is being rejected is because the communication is administratively filtered. Furthermore, this tells us that there is a router in place and it has an access control list (ACL) that is blocking the packet. Moreover, it tells us that the administrator is not following best practices of absorbing packets and not replying with any error messages that can assist an attacker. This is just a small example of the data analysis step; there are many things you will encounter and many more that you will have to analyze to determine what is taking place in the tested environment. Remember: the smarter the administrator, the more challenging pen testing can become which is actually a good thing for security!
Reporting
Reporting is another one of the areas in testing that is often overlooked in training classes. This is unfortunate since it is one of the most important things you need to master. You have to be able to present a report of your findings to the client. These findings will assist them in improving their security practices, and if they like the report, it is what they will most often share with partners and other colleagues. This is your advertisement for what separates you from others. It is a showcase that not only do you know how to follow a systematic process and methodology of professional testing, you also know how to put it into an output form that can serve as a reference going forward for the clients. At the end of the day, as professional security testers, we want to help our clients improve their security scenario, and that is where reporting comes in. There are many references for reports, so the only thing we will cover here is the handling of findings. There are two components we use when it comes to findings, the first of which is a summary-of-findings table. This is so the client can reference the findings early on in the report. The second is the detailed findings section. This is where we put all of the information about the findings. We rate them according to severity and include the following.
Description
This is where we provide the description of the vulnerability, specifically, what it is and what is affected.
Analysis and exposure
For this section, you want to show the client that you have done your research and aren't just repeating what the scanning tool told you. It is very important that you research a number of resources and write a good analysis of what the vulnerability is, along with an explanation of the exposure it poses to the client site.
Recommendations
We want to provide the client a reference to the patches and measures to apply in order to mitigate the risk of discovered vulnerabilities. We never tell the client not to use the service and/or protocol! We do not know what their policy is, and it might be something they have to have in order to support their business. In these situations, it is our job as consultants to recommend and help the client determine the best way to either mitigate the risk or remove it. When a patch is not available, we should provide a reference to potential workarounds until one is available.
References
If there are references such as a Microsoft bulletin number or a Common Vulnerabilities and Exposures (CVE) number, this is where we would place them.
Myths and misconceptions about pen testing
After more than 20 years of performing professional security testing, it is amazing to me really how many are confused as to what a penetration test is. I have on many occasions gone to a meeting where the client is convinced they want a penetration test, and when I explain exactly what it is, they look at me in shock. So, what exactly is a penetration test? Remember our abstract methodology had a step for intrusive target searching and part of that step was another methodology for scanning? Well, the last item in the scanning methodology, exploitation, is the step that is indicative of a penetration test. That's right! That one step is the validation of vulnerabilities, and this is what defines penetration testing. Again, it is not what most clients think when they bring a team in. The majority of them in reality want a vulnerability assessment. When you start explaining to them that you are going to run exploit code and all these really cool things on their systems and/or networks, they usually are quite surprised. The majority of the times, the client will want you to stop at the validation step. On some occasions, they will ask you to prove what you have found, and then you might get to show validation. I once was in a meeting with the IT department of a foreign country's stock market, and when I explained what we were about to do for validating vulnerabilities, the IT director's reaction was, "Those are my stock broker records, and if we lose them, we lose a lot of money!" Hence, we did not perform the validation step in that test.
Summary
In this chapter, we defined security testing as it relates to this book, and we identified an abstract methodology that consists of the following steps: planning, nonintrusive target search, intrusive target search, data analysis, and reporting. More importantly, we expanded the abstract model when it came to intrusive target searching, and we defined within that a methodology for scanning. This consisted of identifying live systems, looking at open ports, discovering services, enumeration, identifying vulnerabilities, and finally, exploitation.
Furthermore, we discussed what a penetration test is and that it is a validation of vulnerabilities and is associated with one step in our scanning methodology. Unfortunately, most clients do not understand that when you validate vulnerabilities, it requires you to run code that could potentially damage a machine or, even worse, damage their data. Because of this, once they discover this, most clients ask that it not be part of the test. We created a baseline for what penetration testing is in this chapter, and we will use this definition throughout the remainder of this book.
In the next chapter, we will discuss the process of choosing your virtual environment.
Chapter 2. Choosing the Virtual Environment
In this chapter, we will discuss the different virtual environment platforms there are to choose from. We will look at most of the main virtual technology platforms that exist. We will discuss the following topics:
One of the most challenging things we have to do is decide on the virtualization software that we want to use. Not only do we have to decide on what we want to do with respect to the software we choose, we also need to decide whether we want to build a dedicated virtual platform or run the software on our existing system. In this book, we are going to focus on creating a new virtual environment on our existing system, which is normally a desktop or laptop. However, it is still important to at least briefly discuss the option of creating a bare-metal environment.
When we install a bare-metal environment (also known as a Type 1 installation of a virtual environment), the OS is provided by the product in the form of a hypervisor. Although this is an extremely useful way of creating powerful and complex architectures, it requires dedicated hardware and as such is not something we would, for the most part, be able to carry around with us. If you are in a lab environment and building labs, then it is something you definitely should explore due to the power and options you have when creating machines.
An example of a Type 1 bare-metal architecture is shown in the following figure:
As the figure shows, in a Type 1 or bare-metal architecture, the Hypervisor is installed on the system hardware and the virtualization resources are provided by the Hypervisor. You can configure a large number of options to include resource allocation when you use a virtual bare-metal solution.
Type 1 virtualization provides a robust and extremely powerful solution to consider when building your pen-testing labs. However, one thing that makes it a challenge to deploy is the fact that the OS is provided by the hypervisor already installed in the hardware, and this can cause challenges with certain hardware versions; furthermore, for the most part, this type of solution is best implemented on a desktop or server-type machine. While it can be implemented on a laptop, it is more common on other platforms. One option is to create your lab environment and then remotely access it. From a virtualization standpoint, it does not impact the machines we create; either type 1 or type 2 will suffice. For the purpose of this book, we will use type 2 virtualization. An example of Type 2 virtualization is shown in the following figure:
As can be seen, in Type 2 virtualization, the Hypervisor sits on the Operating System, and the Operating System sits on the system Hardware. Again, this is the architecture we will utilize as the book progresses. For now, we will look at both type 1 and type 2 solutions. Starting from Chapter 3, Planning a Range, we will maintain focus on the type 2 solution, in fact, a machine with an operating system and a virtual tool installed on top of it.
Open source and free environments
There are a number of free and open source virtual environments; we will look at some of the more popular ones here. In this section, we will discuss the following products:
