40,81 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Identify tools and techniques to secure and perform a penetration test on an AWS infrastructure using Kali Linux
Key Features
- Efficiently perform penetration testing techniques on your public cloud instances
- Learn not only to cover loopholes but also to automate security monitoring and alerting within your cloud-based deployment pipelines
- A step-by-step guide that will help you leverage the most widely used security platform to secure your AWS Cloud environment
Book Description
The cloud is taking over the IT industry. Any organization housing a large amount of data or a large infrastructure has started moving cloud-ward — and AWS rules the roost when it comes to cloud service providers, with its closest competitor having less than half of its market share. This highlights the importance of security on the cloud, especially on AWS. While a lot has been said (and written) about how cloud environments can be secured, performing external security assessments in the form of pentests on AWS is still seen as a dark art.
This book aims to help pentesters as well as seasoned system administrators with a hands-on approach to pentesting the various cloud services provided by Amazon through AWS using Kali Linux. To make things easier for novice pentesters, the book focuses on building a practice lab and refining penetration testing with Kali Linux on the cloud. This is helpful not only for beginners but also for pentesters who want to set up a pentesting environment in their private cloud, using Kali Linux to perform a white-box assessment of their own cloud resources. Besides this, there is a lot of in-depth coverage of the large variety of AWS services that are often overlooked during a pentest — from serverless infrastructure to automated deployment pipelines.
By the end of this book, you will be able to identify possible vulnerable areas efficiently and secure your AWS cloud environment.
What you will learn
- Familiarize yourself with and pentest the most common external-facing AWS services
- Audit your own infrastructure and identify flaws, weaknesses, and loopholes
- Demonstrate the process of lateral and vertical movement through a partially compromised AWS account
- Maintain stealth and persistence within a compromised AWS account
- Master a hands-on approach to pentesting
- Discover a number of automated tools to ease the process of continuously assessing and improving the security stance of an AWS infrastructure
Who this book is for
If you are a security analyst or a penetration tester and are interested in exploiting Cloud environments to reveal vulnerable areas and secure them, then this book is for you.
A basic understanding of penetration testing, cloud computing, and its security concepts is mandatory.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 502
Veröffentlichungsjahr: 2019
Ähnliche
Hands-On AWS Penetration Testing with Kali Linux
Copyright © 2019 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 authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been 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.
Commissioning Editor: Vijin BorichaAcquisition Editor: Shrilekha InaniContent Development Editor: Deepti ThoreTechnical Editor: Mamta YadavCopy Editor:Safis EditingProject Coordinator:Nusaiba AnsariProofreader: Safis EditingIndexer: Tejal Daruwale SoniGraphics: Jisha ChirayilProduction Coordinator: Nilesh Mohite
First published: April 2019
Production reference: 1260419
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78913-672-2
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Packt.com
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.packt.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.packt.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.
Contributors
About the authors
Karl Gilbert is a security researcher who has contributed to the security of some widely used open-source software. His primary interests relate to vulnerability research, 0-days, cloud security, secure DevOps, and CI/CD.
Benjamin Caudill is a security researcher and founder of pentesting firm Rhino Security Labs. Built on 10+ years of offensive security experience, Benjamin directed the company with research and development as its foundation, into a key resource for high-needs clients.
Benjamin has also been a major contributor to AWS security research. With co-researcher Spencer Gietzen, the two have developed Pacu (the AWS exploitation framework) and identified dozens of new attack vectors in cloud architecture. Both GCP and Azure research are expected throughout 2019.
As a regular contributor to the security industry, Benjamin been featured on CNN, Wired, Washington Post, and other major media outlets.
About the reviewers
Rejah Rehim is currently the Director and Chief Information Security Officer (CISO) of Appfabs. Prior to that, he held the title of security architect at FAYA India. Rejah is a long-time preacher of open source and a steady contributor to the Mozilla Foundation. He has successfully created the world's first security testing browser bundle, PenQ, an open source Linux-based penetration testing browser bundle preconfigured with tools for security testing. Rejah is also an active member of OWASP and the chapter leader of OWASP Kerala. Additionally, he also holds the title of commander at Cyberdome, an initiative of the Kerala police department.
Shivanand Persad has an MBA from the Australian Institute of Business, and a BSc in Electrical and Computer Engineering from the University of the West Indies, among a number of certifications in the technology sphere. He has a number of areas of specialization, including controls and instrumentation systems, wireless and wired communication systems, strategic management, and business process re-engineering. With over a decade of experience across multiple engineering disciplines, a lengthy tenure with the Caribbean's largest ISP, and oversight of the largest media group in Trinidad and Tobago, he continues to be passionate about technology and its ongoing development. When not reading everything in sight, he enjoys archery, martial arts, biking, and tinkering.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Hands-On AWS Penetration Testing with Kali Linux
About Packt
Why subscribe?
Packt.com
Contributors
About the authors
About the reviewers
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Download the color images
Conventions used
Get in touch
Reviews
Disclaimer
Section 1: Kali Linux on AWS
Setting Up a Pentesting Lab on AWS
Technical requirements
Setting up a vulnerable Ubuntu instance
Provisioning an Ubuntu EC2 instance 
Installing a vulnerable service on Ubuntu
Setting up a vulnerable Windows instance
Provisioning a vulnerable Windows server instance
Configuring a vulnerable web application on Windows
Configuring security groups within the lab
Configuring security groups
Summary
Further reading
Setting Up a Kali PentestBox on the Cloud
Technical requirements
Setting up Kali Linux on AWS EC2
The Kali Linux AMI
Configuring the Kali Linux instance
Configuring OpenSSH for remote SSH access
Setting root and user passwords
Enabling root and password authentication on SSH
Setting up Guacamole for remote access
Hardening and installing prerequisites
Configuring Guacamole for SSH and RDP access
Summary
Questions
Further reading
Exploitation on the Cloud using Kali Linux
Technical requirements
Configuring and running Nessus
Installing Nessus on Kali
Configuring Nessus
Performing the first Nessus scan
Exploiting a vulnerable Linux VM
Understanding the Nessus scan for Linux
Exploitation on Linux
Exploiting a vulnerable Windows VM
Understanding the Nessus scan for Windows
Exploitation on Windows
Summary
Questions
Further reading
Section 2: Pentesting AWS Elastic Compute Cloud Configuring and Securing
Setting Up Your First EC2 Instances
Technical requirements
Setting Up Ubuntu on AWS EC2
The Ubuntu AMI
Configuring VPC settings
Storage types that are used in EC2 instances
Configuring firewall settings
Configuring EC2 authentication
Summary
Further reading
Penetration Testing of EC2 Instances using Kali Linux
Technical requirements
Installing a vulnerable service on Windows
Setting up a target machine behind the vulnerable Jenkins machine
Setting up Nexpose vulnerability scanner on our Kali machine
Scanning and reconnaissance using Nmap
Identifying and fingerprinting open ports and services using Nmap
Performing an automated vulnerability assessment using Nexpose
Using Metasploit for automated exploitation
Using Meterpreter for privilege escalation, pivoting, and persistence
Summary
Further reading
Elastic Block Stores and Snapshots - Retrieving Deleted Data
Technical requirements
EBS volume types and encryption
Creating, attaching, and detaching new EBS volumes from EC2 instances
Extracting deleted data from EBS volumes
Full disk encryption on EBS volumes
Creating an encrypted volume
Attaching and mounting an encrypted volume
Retrieving data from an encrypted volume
Summary
Further reading
Section 3: Pentesting AWS Simple Storage Service Configuring and Securing
Reconnaissance - Identifying Vulnerable S3 Buckets
Setting up your first S3 bucket
S3 permissions and the access API
ACPs/ACLs
Bucket policies
IAM user policies
Access policies
Creating a vulnerable S3 bucket
Summary
Further reading
Exploiting Permissive S3 Buckets for Fun and Profit
Extracting sensitive data from exposed S3 buckets
Injecting malicious code into S3 buckets
Backdooring S3 buckets for persistent access
Summary
Further reading
Section 4: AWS Identity Access Management Configuring and Securing
Identity Access Management on AWS
Creating IAM users, groups, roles, and associated privileges
Limit API actions and accessible resources with IAM policies
IAM policy structure
IAM policy purposes and usage
Using IAM access keys
Signing AWS API requests manually
Summary
Privilege Escalation of AWS Accounts Using Stolen Keys, Boto3, and Pacu
The importance of permissions enumeration
Using the boto3 library for reconnaissance
Our first Boto3 enumeration script
Saving the data
Adding some S3 enumeration
Dumping all the account information
A new script – IAM enumeration
Saving the data (again)
Permission enumeration with compromised AWS keys
Determining our level of access
Analysing policies attached to our user
An alternative method
Privilege escalation and gathering credentials using Pacu
Pacu – an open source AWS exploitation toolkit
Kali Linux detection bypass
The Pacu CLI
From enumeration to privilege escalation
Using our new administrator privileges
Summary
Using Boto3 and Pacu to Maintain AWS Persistence
Backdooring users
Multiple IAM user access keys
Do it with Pacu
Backdooring role trust relationships
IAM role trust policies
Finding a suitable target role
Adding our backdoor access
Confirming our access
Automating it with Pacu
Backdooring EC2 Security Groups
Using Lambda functions as persistent watchdogs
Automating credential exfiltration with Lambda
Using Pacu for the deployment of our backdoor
Other Lambda Pacu modules
Summary
Section 5: Penetration Testing on Other AWS Services
Security and Pentesting of AWS Lambda
Setting up a vulnerable Lambda function
Attacking Lambda functions with read access
Attacking Lambda functions with read and write access
Privilege escalation
Data exfiltration
Persistence
Staying stealthy
Pivoting into Virtual Private Clouds
Summary
Pentesting and Securing AWS RDS
Technical requirements
Setting up a vulnerable RDS instance
Connecting an RDS instance to WordPress on EC2
Identifying and enumerating exposed RDS instances using Nmap
Exploitation and data extraction from a vulnerable RDS instance
Summary
Further reading
Targeting Other Services
Route 53
Hosted zones
Domains
Resolvers
Simple Email Service (SES)
Phishing
Other attacks
Attacking all of CloudFormation
Parameters
Output values
Termination protection
Deleted stacks
Exports
Templates
Passed roles
Bonus – discovering the values of NoEcho parameters
Elastic Container Registry (ECR)
Summary
Section 6: Attacking AWS Logging and Security Services
Pentesting CloudTrail
More about CloudTrail
Setup, best practices, and auditing
Setup
Auditing
Reconnaissance
Bypassing logging
Unsupported CloudTrail services for attackers and defenders
Bypassing logging through cross-account methods
Enumerating users
Enumerating roles
Disrupting trails
Turning off logging
Deleting trails/S3 buckets
Minifying trails
Problems with disruption (and some partial solutions)
Summary
GuardDuty
An introduction to GuardDuty and its findings
Alerting about and reacting to GuardDuty findings
Bypassing GuardDuty
Bypassing everything with force
Bypassing everything with IP whitelisting
Bypassing EC2 instance credential exfiltration alerts
Bypassing operating system (PenTest) alerts
Other simple bypasses
Cryptocurrency
Behavior
ResourceConsumption
Stealth
Trojan
Others
Summary
Section 7: Leveraging AWS Pentesting Tools for Real-World Attacks
Using Scout Suite for AWS Security Auditing
Technical requirements
Setting up a vulnerable AWS infrastructure
A misconfigured EC2 instance
Creating a vulnerable S3 instance
Configuring and running Scout Suite
Setting up the tool
Running Scout Suite
Parsing the results of a Scout Suite scan
Using Scout Suite's rules
Summary
Using Pacu for AWS Pentesting
Pacu history
Getting started with Pacu
Pacu commands
list/ls
search [[cat]egory] <search term>
help
help <module name>
whoami
data
services
data <service>|proxy
regions
update_regions
set_regions <region> [<region>...]
run/exec <module name>
set_keys
swap_keys
import_keys <profile name>|--all
exit/quit/Ctrl + C
aws <command>
proxy <command>
Creating a new module
The API
session/get_active_session
get_proxy_settings
print/input
key_info
fetch_data
get_regions
install_dependencies
get_boto3_client/get_boto3_resource
Module structure and implementation
An introduction to PacuProxy
Summary
Putting it All Together - Real - World AWS Pentesting
Pentest kickoff
Scoping
AWS pentesting rules and guidelines
Credentials and client expectations
Setup
Unauthenticated reconnaissance
Authenticated reconnaissance plus permissions enumeration
Privilege escalation
Persistence
Post-exploitation
EC2 exploitation
Code review and analysis in Lambda
Getting past authentication in RDS
The authenticated side of S3
Auditing for compliance and best practices
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
This title is the first of its kind and will help you to secure all aspects of your Amazon Web Services (AWS) infrastructure by means of penetration testing. It walks through the processes of setting up test environments within AWS, performing reconnaissance to identify vulnerable services using a variety of tools, finding misconfigurations and insecure configurations for various components, and how vulnerabilities can be used to gain further access.
Who this book is for
If you are a security analyst or a penetration tester who is interested in exploiting cloud environments to establish vulnerable areas and then secure them, this book is for you. A basic understanding of penetration testing, AWS, and its security concepts would be necessary.
What this book covers
Chapter 1, Setting Up a Pentesting Lab on AWS, focuses on setting up a vulnerable Linux virtual machine (VM) as well as a generic Windows VM on AWS and putting it on the same network as the Kali instance.
Chapter 2, Setting Up a Kali Pentestbox on the Cloud, focuses on creating an Amazon EC2 instance, setting it up with a Kali Linux Amazon Machine Image (AMI), and configuring remote access to this host through a variety of means.
Chapter 3, Exploitation on the Cloud Using Kali Linux, walks you through the process of scanning for vulnerabilities in a vulnerable lab, exploiting these vulnerabilities using Metasploit, gaining reverse shells, and various other exploitation techniques. This serves to help budding pentesters practice on a cloud environment that simulates real-life networks.
Chapter 4, Setting Up Your First EC2 Instances, walks you through the concepts of EC2 instance sizes, different types of instances and their uses, AMIs and the creation of custom AMIs, various storage types, the concept of input/output operations per second (IOPS), Elastic Block Stores, security policies, and virtual private cloud configurations.
Chapter 5, Penetration Testing of EC2 Instances Using Kali Linux, focuses on the methods for performing a security assessment on an EC2 instance.
Chapter 6, Elastic Block Stores and Snapshots – Retrieving Deleted Data, introduces you to the different types of storage options that are available through AWS, extending the information covered in Chapter 3, Exploitation on the Cloud Using Kali Linux.
Chapter 7, Reconnaissance – Identifying Vulnerable S3 Buckets, explains the concept of AWS S3 buckets, what they're used for, and how to set them up and access them.
Chapter 8, Exploiting Permissive S3 Buckets for Fun and Profit, goes through the process of exploiting a vulnerable S3 bucket to identify JavaScript files that are being loaded by a web application and backdooring them to gain a pan-user compromise.
Chapter 9, Identity Access Management on AWS, focuses on one of the most important concepts in AWS that is meant to manage user identity and access to various layers of services within AWS.
Chapter 10, Privilege Escalation of AWS Accounts Using Stolen Keys, Boto3, and Pacu, focuses on using the Boto3 Python library and the Pacu framework to leverage AWS keys for a wide range of attacks within an AWS environment. We go through the processes of enumerating access validity, identity information, and complete account information as well as enumerating information such as that pertaining to S3 buckets and EC2 instance metadata. This will also cover the process of automating some of the steps that we covered in earlier chapters. Finally, the steps to change and set administrator roles for a given user or group are also covered.
Chapter 11, Using Boto3 and Pacu to Maintain AWS Persistence, deals with permission enumeration and privilege escalation, which are integral to AWS pentests.
Chapter 12, Security and Pentesting of AWS Lambda, focuses on creating vulnerable Lambda applications and executing them within a code sandbox. Once the architecture has been set up, we focus on pivoting to connected application services, and achieving code execution within a Lambda sandbox as well as achieving ephemeral persistence. To further simulate an actual pentest, there is a walk-through of running a vulnerable Lambda application and achieving subsequent compromise.
Chapter 13, Pentesting and Securing AWS RDS, focuses on explaining the process of setting up a sample Relational Database Service (RDS) instance and connecting it to a WordPress instance in a secure, as well as an insecure, way.
Chapter 14, Targeting Other Services, is designed to show some attacks on some less common AWS APIs. This chapter deals with misconfigurations and attack vectors available in Route53, SES, CloudFormation, and Key Management Service (KMS).
Chapter 15, Pentesting CloudTrail, helps us deal with one of the most detailed sources of information within an AWS environment, which is CloudTrail. CloudTrail logs can be a treasure trove of information to a potential attacker regarding the internal operations of various AWS services, virtual machines, and users, alongside significant amounts of other useful information.
Chapter 16, GuardDuty, introduces you to GuardDuty, the dedicated intrusion detection system for AWS. You will be exposed to the range of GuardDuty alerting capabilities and how it relies on the CloudTrails listed in the previous chapter. After covering the monitoring and alerting capabilities of GuardDuty, we'll explore GuardDuty as an attacker and how to bypass AWS security monitoring capabilities.
Chapter 17, Using Scout Suite and Security Monkey, introduces you to another automated tool, Scout Suite, which performs an audit on the attack surface within an AWS infrastructure and reports a list of findings that can be viewed on a web browser. It also deals with Security Monkey, which, on the other hand, monitors AWS accounts for policy changes as well as continuously monitoring for insecurity configurations.
Chapter 18, Using Pacu for AWS Pentesting, puts together many of the Pacu concepts given throughout the previous chapters, walking you through the full capabilities of the AWS attack framework, Pacu. Modular and easily extendable, we'll walk through the structure of Pacu, how to build new enumeration and attack services, and leverage the existing framework for complex AWS pentests.
Chapter 19, Putting it All Together – Real-World AWS Pentesting, brings together the various concepts to walk you through a real-world AWS penetration test, starting with the enumeration of permissions, the escalation of privileges, the backdooring of accounts, the compromising EC2 instances, and the exfiltration of data.
To get the most out of this book
Make sure you have an AWS account set up and ensure that you have a good understanding of AWS services and how they work with one another.
Download the example code files
You can download the example code files for this book from your account at www.packt.com. If you purchased this book elsewhere, you can visit www.packt.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packt.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Hands-On-AWS-Penetration-Testing-with-Kali-Linux. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/9781789136722_ColorImages.pdf.
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "This information is returned to us in the ListFunctions call we just made under the "Environment" key."
A block of code is set as follows:
"Environment": { "Variables": { "app_secret": "1234567890" }}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
:%s/^/kirit-/gor :%s/^/<<
prefix>>/g
Any command-line input or output is written as follows:
aws lambda list-functions --profile LambdaReadOnlyTester --region us-west-2
Bold: Indicates a new term, an important word, or words that you see on screen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Now, click Create bucket to create it."
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packt.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in, and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
Disclaimer
The information within this book is intended to be used only in an ethical manner. Do not use any information from the book if you do not have written permission from the owner of the equipment. If you perform illegal actions, you are likely to be arrested and prosecuted to the full extent of the law. Packt Publishing does not take any responsibility if you misuse any of the information contained within the book. The information herein must only be used while testing environments with proper written authorizations from appropriate persons responsible.
Section 1: Kali Linux on AWS
This section is a beginner-oriented introduction to how an individual without access to a ready-made AWS environment can set up a lab to practice their pentesting skills, as well as the ways in which they may practice their skills. It also walks the reader through the process of setting up a Kali pentestbox on AWS that can be easily accessed on the go, using nothing more than a web browser.
The following chapters will be covered in this section:
Chapter 1
,
Setting Up a Pentesting Lab on AWS
Chapter 2
,
Setting Up a Kali Pentestbox on the Cloud
Chapter 3
,
Exploitation on the Cloud using Kali Linux
Setting Up a Pentesting Lab on AWS
This chapter aims to help penetration testers who don't have direct access to targets for penetration testing set up a vulnerable lab environment within AWS. This lab will allow testers to practice various exploitation techniques using Metasploit and rudimentary scanning and vulnerability assessment using multiple tools within Kali. This chapter focuses on setting up a vulnerable Linux VM and a generic Windows VM on AWS, putting them on the same network.
In this chapter, we will cover the following topics:
Setting up a personal pentesting lab for hacking on the cloud
Configuring and securing the virtual lab to prevent unintended access
Technical requirements
In this chapter, we are going to use the following tools:
Damn Vulnerable Web Application
Very Secure File Transfer Protocol Daemon
(
vsftpd
) version 2.3.4
Setting up a vulnerable Ubuntu instance
As the first of the two vulnerable machines that we will be creating, the vulnerable instance of Ubuntu will contain a single vulnerable FTP service, as well as some other services.
Provisioning an Ubuntu EC2 instance
The very first step in setting up our vulnerable lab in the cloud will be to provision an instance that will be running a vulnerable operating system. For this purpose, we can use an Ubuntu LTS version. This can be accessed from the AWS Marketplace for quick deployment.
We will use Ubuntu 16.04 for this purpose:
Once we click on the Continue to Subscribe button, we are prompted to configure the instance that we are going to launch. Since this is a pretty standard image, we will proceed with the default settings except for Region and VPC settings.
For Region, you can use the AWS Region that is closest to yourself. However, keep in mind that all the other instances you create on AWS need to be hosted in the same region or they cannot be a part of the same network.
For VPC, make sure you note down the VPC and the subnet IDs that you are using to set up this instance. We will need to reuse them for all the other hosts in the lab. In this case, I will be using the following:
It should be noted that the VPC IDs and the subnet IDs will be unique for everyone. Once done, we can proceed to deploy the EC2 instance by clicking on the Launch with the 1-Click button.
Once done, the next step is to SSH into the newly created VM using the following command:
ssh -i <pem file> <IP address of the instance
>
Once connected, run the following command:
sudo apt-get update && sudo apt-get dist-upgrade
These commands will update the repository listing and all the packages installed on the instance, so we don't have to deal with any old packages.
Installing a vulnerable service on Ubuntu
For this Ubuntu host, we will be installing a vulnerable version of an FTP server, vsftpd. Version 2.3.4 of this FTP software was found to be backdoored. In this chapter, we will be installing this backdoored version and then will attempt to identify it using a pentesting box we will set up in the next chapter, and finally we will exploit it.
To make things easier, the backdoored version of vsftpd 2.3.4 is archived on GitHub. We shall be using that code base to install the vulnerable software. To start with, we need to clone the git repository:
git clone https://github.com/nikdubois/vsftpd-2.3.4-infected.git
Next, we need to install packages for setting up a primary build environment. To do this, we run the following:
sudo apt-get install build-essential
Now, we cd into the vsftpd folder to build it from source. However, before doing that, we need to make a small change to the Makefile. The -lcrypt value needs to be added as a linker flag:
Once done, save the file and just run make.
If all goes well, we should see a vsftpd binary in the same folder:
Next, we need to set up some prerequisites before installing vsftpd. Namely, we need to add a user called nobody and a folder called empty. To do that, run the following commands:
useradd nobody
mkdir /usr/share/empty
Once done, we can run the installation by executing the following commands:
sudo cp vsftpd /usr/local/sbin/vsftpd
sudo cp vsftpd.8 /usr/local/man/man8
sudo cp vsftpd.conf.5 /usr/local/man/man5sudo cp vsftpd.conf /etc
With that done, we need to execute the vsftpd binary to confirm whether we can connect to the localhost:
The next step is to set up anonymous access to the FTP server. To do this, we need to run the following commands:
mkdir /var/ftp/
useradd -d /var/ftp ftp
chown root:root /var/ftp
chmod og-w /var/ftp
Finally, enable local login to the vsftpd server by making the following change to /etc/vsftpd.conf:
Setting up a vulnerable Windows instance
With a vulnerable Linux Server set up, we now set up an attack vector through a Windows server that's running a vulnerable web application. This application shall provide two environments that readers without an actual test environment can try their hand at.
Provisioning a vulnerable Windows server instance
For the purpose of this lab host, we will be using a Server 2003 instance from the AWS Marketplace:
The provisioning steps are pretty much identical to what we used to set up the Linux instance earlier. Care should be taken that the VPC settings are similar to what we used for the previous instance. This will later allow us to configure the VMs to be on the same network.
After verifying the VPC settings and the region, we proceed to launch the instance—precisely as we did earlier. Finally, we set the key-pair that we have been using all along and we are good to go. Once the instance has been launched, we need to follow a slightly different process to access a Windows instance remotely. Since Remote Desktop Protocol (RDP) doesn't support certificate-based authentication, we need to provide the private key to decrypt and get the password using which we can log in. This is done by simply right-clicking on the instance and selecting Get Windows Password:
On the following screen, we are required to upload the private key that was downloaded earlier:
Once done, simply clicking on Decrypt Password will provide us with the password that we can use to RDP into our Windows server instance. Once done, it's a simple matter of firing up Remote Desktop and connecting to the IP address using the displayed credentials.
Once we are logged in, the next step is to set up XAMPP on the Windows server so we can host a vulnerable website on the server. But before we proceed, we need to install the latest version of Firefox on the server, since the Internet Explorer version that comes packaged with Windows Server 2003 is pretty old and doesn't support some website configurations. To download XAMPP, just access https://www.apachefriends.org/download.html and download the version that's built for XP and Windows Server 2003:
Note that you will need to scroll down and download the correct version of XAMPP:
Finally, we need to follow the default installation process, and we will be set up with a working installation of PHP, Apache, and MySQL, along with a few necessary utilities that we need to manage a website.
Configuring a vulnerable web application on Windows
In this section, we will be setting up an extremely vulnerable web application for the pentesting lab. To begin with, let's clear up the XAMPP hosting folder by accessing C:\xampp\htdocs.
Create a new folder called _bak and cut and paste all the existing files into that folder. Now, let's download the vulnerable website's source code. For this, we will use one of the many vulnerable PHP samples that are available on GitHub: https://github.com/ShinDarth/sql-injection-demo/.
The fastest way to get the files is to directly download the ZIP file:
Once downloaded, it's simply a matter of copying the contents of the ZIP file into the C:\xampp\htdocs folder. If done correctly, this is what the file structure should look like:
Once completed, the next step is to create a database for the application and import the data into it. To achieve this, you need to access the phpMyAdmin interface, which is accessible at http://127.0.0.1/phpmyadmin. Once here, select the New option under Recent:
Here we create a new database called sqli:
Next, to import data into the newly created database, we go into the Import tab and browse to the database.sql file that we just extracted into the htdocs folder:
Once we click on Go we will see a success message. Now, if we browse to http://127.0.0.1 in our browser, we will be able to access the vulnerable website:
Congratulations, you have successfully configured a vulnerable web application on the Windows server! The next step will be to set up the networking rules within our VPC so that the vulnerable hosts are accessible from the other EC2 instances.
Configuring security groups within the lab
Now that we have set up two vulnerable servers, the next step is to configure network so that our web application isn't accessible to outsiders and, at the same time, so that the other lab machines can communicate with each other.
Configuring security groups
We had originally set all of the EC2 instances to be on the same VPC. This implied that the EC2 instances would be on the same subnet and would be able communicate with each other through internal IP addresses. However, AWS doesn't want to allow all 4,096 addresses on the same VPC to be communicating with each other. As a result, the default security groups don't allow communication between EC2 instances.
To allow connectivity from the Ubuntu instance to the Windows instance (you can repeat these steps for the Kali instance that will be set up in the next chapter), the first step is to get the Private IP address of the Ubuntu host:
Next, we need to modify the security group rules for the first Windows instance. This is as simple as clicking on the security Group Name in the summary pane to get to the Security Group screen:
Now we simply need to click on the Edit button and add the rule allowing all traffic from the Kali Linux instance:
Once done, just save this configuration. To confirm that Kali can now communicate with the Windows server, let's run a curl command to see if the site is accessible:
curl -vL 172.31.26.219
Make sure to replace the IP address with your IP address for Windows. If all is well, there should be a bunch of JavaScript in response:
In the next chapter, once the Kali PentestBox has been set up, the preceding steps can be used to whitelist the Kali Linux IP address on both the Ubuntu and the Windows server instances so we can get started with hacking the lab environment!
Summary
In this chapter, we have set up a lab that can prove useful to beginner penetration testers who do not have access to a test environment or hands-on exposure to a lab. In our lab, we have set up one Ubuntu host with a vulnerable service running on it, and we also set up a Windows server host that is running a vulnerable web application. This represents the two biggest surface areas for an attack in any environment. Additionally, we also went through the process of establishing a network connection between the various instances that we have set up so far. With these steps taken care of, the user can set up any operating system instances in the cloud, set up security groups to configure networking, and protect against unauthorized access as well.
In the next chapter, we will be looking at setting up a Kali PentestBox, using which we can perform scanning, enumeration, and exploitation of the two vulnerable EC2 instances that we have set up.
Further reading
Vulnerability and Exploit Database:
https://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor
Amazon Virtual Private Cloud (User Guide):
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html
Setting Up a Kali PentestBox on the Cloud
There is a readily available Amazon Machine Image (AMI) that runs Kali Linux on the Amazon Marketplace. This means that a penetration tester can quickly set up a Kali Linux instance on the Amazon Cloud and access it at any time for any kind of penetration test. This chapter focuses on creating an Amazon EC2 instance, setting it up with a Kali Linux AMI, and configuring remote access to this host in a variety of ways. Once set up, a penetration tester can remotely access a Virtual Private Cloud (VPC) belonging to an AWS account and perform pentests within that VPC and on any remote hosts using Kali.
In this chapter, we will learn about the following:
How to run Kali Linux on the Amazon Cloud
Accessing Kali remotely over SSH
Accessing Kali remotely through clientless RDP
Technical requirements
In this chapter, we are going to use the following tools:
AWS EC2 instance
Kali Linux AMI
Apache Guacamole (
https://guacamole.apache.org
)
SSH client and a browser
Setting up Kali Linux on AWS EC2
In this section, we will go through the very first steps of setting up a virtual penetration testing machine on the cloud, as well as setting up remote access to it to perform penetration testing on the go. The penetration testing machine will go hand-in-hand with the penetration testing lab that was set up in the Chapter 1, Setting Up a Pentesting Lab on AWS, that allows you to perform penetration testing and exploitation on those hosts.
The Kali Linux AMI
AWS provides a fascinating feature that allows for the rapid deployment of Virtual Machines (VMs) on the Amazon Cloud—Amazon Machine Images (AMIs). These act as templates and allow one to quickly set up a new VM on AWS without going through the unnecessary hassle of manually configuring hardware and software like on traditional VMs. However, the most useful feature here is that AMIs allow you to bypass the OS installation process entirely. As a result, the total amount of time needed to decide what OS is required and to get a fully functioning VM on the cloud is reduced to a few minutes—and a few clicks.
The Kali Linux AMI was added to the AWS store pretty recently, and we shall leverage it to quickly set up our Kali VM on the Amazon Cloud. Setting up a Kali instance using the ready-made AMI is pretty simple—we start by accessing the Kali Linux AMI from the AWS Marketplace:
The previous screenshot shows the following information:
The version of the AMI that we are using (2018.1)
The
Typical Total Price
for running this in a default instance
Overview and details of the AMI
It is useful to note that the default recommended instance size for Kali Linux is t2.medium, as we can see under pricing information:
Further down the page, we can see that the size of the t2.medium instance consists of two CPU virtual cores and 4GiB RAM, which is more than enough for our setup:
Once we have confirmed that we're setting up the image according to our requirements, we can go ahead and click on the Continue to Subscribe option to proceed with our instance.
Configuring the Kali Linux instance
In the previous section, we confirmed the AMI we are going to use along with the specifications of the machine we will be using to launch our Kali machine. Once that has been selected it is time to launch our machine.
This brings us to the Launch on EC2 page. This contains some options that need to be set:
The version of the AMI that we will
use
: It is usually recommended to use the latest version of the AMI that is available in the marketplace. Often, this isn't the one that is selected by default for Kali Linux. At the time of writing, the latest version is 2018.1, and the build date is February 2018, as can be seen here:
The region where we will be deploying the instance
: As discussed in the
Chapter 1
, Setting Up a Pentesting Lab on AWS, we need to set the region to the data center that is geographically closest to the current location.
The EC2 instance size
:
This was already verified in the previous step. We will be looking at various instance types and sizes in greater depth in later sections of this book.
VPC Settings
:
The
VPC
and
subnet
settings need to be set to use the same
VPC
that we used to set up the penetration testing lab in
Chapter 1
,
Setting Up a Pentesting Lab on AWS
. This will put our hacking box on the same network as the vulnerable machines that we set up earlier. The setting should match whatever was configured in the previous chapter:
Security group
: Previously, we set up the
Security Group
in such a way that unauthorized outsiders would not have access to the instances. However, in this case, we need to allow remote access to our Kali instance. Hence, we need to forward the
SSH
and the Guacamole remote access port to a new
Security Group
:
Key pair
:
We can use the same key pair that was created during the setup of the lab environment in the
Chapter 1
,
Setting Up a Pentesting Lab on AWS
.
With these settings in place, we are good to go and can spin up the instance by clicking on Launch with1-click:
AWS will then launch the Kali machine and assign it a public IP. However, we need to be able to access this machine. In the next section, we will see how we can use OpenSSH for accessing a Kali Machine.
Configuring OpenSSH for remote SSH access
AWS already sets a default form of SSH access for their Kali AMI with an ec2-user account using a public key. However, this isn't convenient for access via a mobile device. For users who want to conveniently SSH into their Kali instances from mobile applications directly with root privileges, the following section walks through the process. It should be noted, however, that using a limited user account with PKI authentication is the most secure way to connect over SSH, and using a root account with a password is not recommended if securing the instance is a priority.
Setting root and user passwords
The very first step of configuring root SSH on a Kali Linux instance is to set the root password. The root account usually doesn't have a password set for ec2 instances that are using an ec2-user account that has sudo privileges. However, since we are setting up SSH access from mobile SSH applications, this needs to be set. It should be noted, however, that this comes with a reduction in the security stance of the Kali instance.
Changing the root password is as simple as running sudo passwd on the SSH terminal:
Similarly, the password of the current user can also be changed by running sudo passwd ec2-user over SSH:
This will be helpful in SSH-ing as ec2-user from an SSH client application that doesn't support authentication keys. However, another step remains before we can SSH into the Kali instance as root.
Enabling root and password authentication on SSH
As an enhanced security measure, OpenSSH server comes with root login disabled by default. Enabling this is a straightforward process and involves editing a configuration file, /etc/ssh/sshd_config:
The critical parts of this are the two entries:
PermitRootLogin
: This can be set to
yes
if you want to log in as root
PasswordAuthentication
: This needs to be set to
yes
instead of the default
no
to log in using passwords.
Once you are done performing the changes, you will need to restart the ssh service:
sudo service ssh restart
With that, our Kali Machine on the cloud is up and running and can be accessed over SSH using a password. However, SSH only gives you a command line interface.
In the next section, we will take a look at how we can set up a remote desktop service to get GUI access to our Kali Machine.
Setting up Guacamole for remote access
Apache Guacamole is a clientless remote access solution that will allow you to access the Kali Linux instance remotely using a browser. This will allow you to access the PentestBox on the go even from a mobile device, without having to worry about other complications surrounding remote access. The traditional way of accessing such servers is over SSH, but this will not be able to provide a GUI when accessed from a mobile device.
Hardening and installing prerequisites
Setting up remote access to a VM can be a risky affair, hence it's recommended that we install and set up a firewall and IP blacklisting services to protect against brute-forcing attacks and similar attacks on the internet. The services we will install are ufw and fail2ban. They are pretty easy to set up:
All you need to do is run the following command:
sudo apt-get install ufw fail2ban
Once we have installed the
ufw
firewall, we need to allow the two ports that we will be using for remote access:
22
for SSH and
55555
for Guacamole. So we need to run the following commands:
sudo ufw allow 22
sudo ufw allow 55555
Once that's done, we need to restart the
ufw
service:
Next, we need to install the prerequisites for Apache Guacamole. You can do this by executing the following command:
sudo apt-get install
build-essential
htop
libcairo2-dev libjpeg-dev libpng-dev
libossp
-
uuid
-dev tomcat8 freerdp2-dev libpango1.0-dev libssh2-1-dev libtelnet-dev libvncserver-dev libpulse-dev libssl-dev libvorbis-dev
Post-installation, we need to modify the configuration of Apache Tomcat to listen on port
55555
(as set in our
Security Group
) rather than the default
8080
. To do this, we need to run the following command:
sudo nano /etc/tomcat8/server.xml
Within this file, the
Connector port
needs to be changed from
8080
to
55555
, as shown in the following screenshot:
Next, we need to set up the RDP Service on the Kali instance. This is easily achieved by installing
xrdp
using the following command:
sudo apt install xrdp
Next, we need to allow all users to access the RDP Service (the X Session). This requires the editing of a file:
allowed_users=anybody
Finally, we need to set the
xrdp
services to start automatically and
enable
the services:
Once this step has been completed, we have to download the source code for Apache Guacamole server from
https://guacamole.apche.org/releases/
.
Keep in mind that you need to download the latest guacamole-server.tar.gz and guacamole.war files. At the time of writing, the latest version is 0.9.14, which we can download using the following command:
wget http://mirrors.estointernet.in/apache/guacamole/1.0.0/source/guacamole-server-1.0.0.tar.gz
wget http://mirrors.estointernet.in/apache/guacamole/1.0.0/binary/guacamole-1.0.0.wa
Once these have been downloaded, we need to extract the source by executing the following code:
tar xvf guacamole-server.tar.gz
After entering the extracted directory, we have to build and install the package. This can be achieved by executing the following code:
CFLAGS="-Wno-error" ./configure --with-init-dir=/etc/init.dmake -j4sudo make installsudo ldconfigsudo update-rc.d guacd defaults
Once this has been successfully run, Guacamole has been installed. However, further configuration needs to be undertaken in order to fully set up remote access.
Configuring Guacamole for SSH and RDP access
Guacamole's default configuration directory is /etc/guacamole. It requires a file called guacamole.properties to be properly created to function. There are some other directories that we might want to place within the configuration directory, but they won't be needed for the current setup.
The Guacamole properties file should contain information about the address of the
guacamole proxy
:
# Hostname and port of guacamole proxy guacd-hostname: localhost guacd-port: 4822
In addition to this, we also need another file called
user-mapping.xml
in the same directory, containing a list of usernames and passwords that Guacamole will authenticate with:
<user-mapping> <authorize username="USERNAME" password="PASSWORD"> <connection name="RDP Connection"> <protocol>rdp</protocol> <param name="hostname">localhost</param> <param name="port">3389</param> </connection> <connection name="SSH Connection"> <protocol>ssh</protocol> <param name="hostname">localhost</param> <param name="port">22</param> </connection> </authorize></user-mapping>
Once completed, it is time to deploy the war file that we downloaded earlier. We need to move it into the
tomcat8/webapps
folder so that it gets auto-deployed:
mv guacamole-0.9.14.war /var/lib/tomcat8/webapps/guacamole.war
Now, we just have to restart both the
guacd
and
tomcat8
services to get Apache Guacamole up and running! To do that, use the following command:
sudo service guacd restart
sudo service tomcat8 restart
There's one last configuration step that is required—copying the authentication information into the Guacamole client directory. This is done by executing the following code:
mkdir /usr/share/tomcat8/.guacamoleln -s /etc/guacamole/guacamole.properties /usr/share/tomcat8/.guacamole
Now, if we point our browser to
ipaddr:55555/guacamole
, we will be able to access Guacamole! We are greeted with the following screen:
We have to log in with the same credentials that we set up in the
user-mapping.xml
file.
Once we have successfully logged in, it's a simple matter of selecting the technique through which we want to access the server:
Congratulations, you have successfully set up your Kali PentestBox on the cloud and can access it remotely from anywhere using your browser!
Summary
After going through this chapter, you will be able to successfully set up a Kali Linux PentestBox on the Amazon Cloud, which will aid you in the exercises in the upcoming chapters. We learned how to set up remote access to the cloud instance via SSH, RDP, and Apache Guacamole. This chapter also focused on certain information about the hardening of a cloud instance that will help you to better understand several advanced security concepts related to the EC2 service further in the book.
In the next chapter, we will be going through the steps to perform automated and manual pentests of our pentesting lab (which we set up in the first chapter) using the PentestBox that we set up in this chapter.
Questions
What is the advantage of using Guacamole for remote access rather than a service such as
tightvnc
?
With the current setup, anyone who knows the IP address can easily access the Guacamole interface. Is there any way to protect the server from such access?
What is the purpose of the
-Wno-error
flag that was added during the compilation process of Guacamole?
Why does the default
sshd_config
set the
PermitRootLogin
value to
no
?
Why does AWS disable password-based login?
Can we use SSH-tunneling to improve the security of this setup?
Further reading
SSH Tunneling:
https://www.ssh.com/ssh/tunneling/
PKI in SSH:
https://www.ssh.com/pki/
P
roxying Guacamole:
https://guacamole.apache.org/doc/gug/proxying-guacamole.html
Exploitation on the Cloud using Kali Linux
In the Chapter 2, Setting Up a Kali PentestBox on the Cloud, we set up a penetration testing lab as well as the Kali Linux PentestBox configured with remote access. It is time to start performing some scanning and exploitation using the PentestBox on the vulnerable hosts in the lab.
This chapter will focus on the process of automated vulnerability scans using the free version of a commercial tool and then exploiting the found vulnerabilities using Metasploit. These vulnerabilities were baked into the lab environment earlier, on the vulnerable hosts that were configured in Chapter 1, Setting up a Pentesting Lab on AWS, and Chapter 2, Setting up a Kali PentestBox on the Cloud.
The following topics will be covered in this chapter:
Running automated scans with Nessus and verifying the vulnerabilities that are found
Exploitation using Metasploit and Meterpreter
Exploiting vulnerable Linux and Windows
virtual
machines
(
VMs
)
Technical requirements
The following tools will be used in this chapter:
Nessus (needs manual installation)
Metasploit
Configuring and running Nessus
Nessus is a popular tool for automating vulnerability scans within a network, with some added functionality of scanning web applications as well. In the first section, we shall set up Nessus on our PentestBox on EC2. Then we shall use it to run basic and advanced scans on the lab that we set up earlier.
Installing Nessus on Kali
The first step to performing automated pentesting and vulnerability assessment using Nessus, is obviously to install it on Kali. To make things easy, Nessus comes in a .deb package that can be directly installed using dpkg.
To install Nessus, the first step is to download the
.deb
package from the tenable website, on
https://www.tenable.com/downloads/nessus
:
Once downloaded, we need to transfer this to our Kali PentestBox on AWS. We can do this file transfer using
WinSCP
on Windows. On Linux/macOS, the native SCP utility can be used. The setup is available at
https://winscp.net/eng/download.php
Once WinSCP is installed, we need to set up a connection to our Kali PentestBox. First, we need to add a new site:
Next, we need to add the public key, downloaded from AWS, for authentication. To do this, we need to click on
Advanced
and set the path to the key on
SSH
|
Authentication
:
Once done, it's a simple matter of saving the site and then connecting to it to see a folder listing on the remote host:
From here, it's a simple matter of dragging the
.deb
package into the
root
folder that we just accessed in the previous step. Once done, we can get started with installing the package. This can be achieved using
dpkg
through an SSH shell to the AWS EC2 instance:
Once done, we start the Nessus service and confirm that it is running:
sudo /etc/init.d/nessusd start
sudo service nessusd status
If the
status
command returns a status of running, we have successfully started the service. Next, we need to set up SSH tunneling to forward port
8834
from the Kali PentestBox to our localhost over the SSH connection. On a Linux Terminal, the following syntax needs to be used:
ssh -L 8834:127.0.0.1:8834 ec2-user@<IP address>
On Windows, if you're using PuTTY, the
SSH Tunnels
can be configured here, by clicking on the
Tunnels
option after launching PuTTY:
Once done, reconnect to the instance and you can now access Nessus on your local machine on
https://127.0.0.1:8834
.
Configuring Nessus
Once Nessus has been installed and the SSH tunnel configured, we can access Nessus on the browser by pointing at https://127.0.0.1:8834. We will need to go through a set of first steps to set up Nessus now.
The very first screen prompts the user to
Create an account
:
Enter suitable credentials and proceed to the next step. Now we need to activate a home license. We can grab one at
https://www.tenable.com/products/nessus-home
by filling in the following form:
Once you've received the activation code by email, enter it into the web interface and trigger the initialization process. Now Nessus goes through the process of downloading data that is needed for the scanning of network assets:
This process usually takes a few minutes, so there's enough time to go grab a cup of coffee while this is happening.
Performing the first Nessus scan
Once the initialization is complete, we're welcomed by the Nessus home screen. Here, we need to click on New Scan to start a new scan on the pentesting lab that we set up earlier.
Once on the new scan tab, we need to start a
Basic Network Scan
:
After clicking on
Basic Network Scan
, we need to give a scan name and enter the IPs of the two other hosts that we set up in the lab:
Next up, we configure the
DISCOVERY
and
ASSESSMENT
options. For discovery, let's request a scan of all services:
This has the advantage of enumerating all services running on a host and discovers hosts if no traditional services are running on them.
Let's configure Nessus to scan web applications as well:
Finally, we
Launch
the scan:
Once again, scanning is a time-consuming process, so this would take around 15 to 20 minutes to complete on average, if not more.
Exploiting a vulnerable Linux VM
Now that we have finished scanning both the hosts in the vulnerable lab, it is time to start exploitation of these hosts. Our first target is the Ubuntu instance that we set up in our lab. Here, we shall go through the scan results for this host and try to gain unauthorized access to the host.
Understanding the Nessus scan for Linux
We first start with the Nessus scan results for our Ubuntu server host:
Unsurprisingly, we just find a bunch of information vulnerabilities, since there are just two services installed—FTP and SSH. The FTP server has a backdoor baked into it; however, it has not come out as a critical vulnerability. If you look at the last result in the Linux scan, it does detect that vsftpd 2.3.4 is installed, which comes with a backdoor.
To summarize the other results on this page, the Nessus SYN scanner simply lists a number of services enabled on the host:
There is a bunch of more useful information on this page that can be manually inspected. As of now, we shall focus on exploitation of the vsftpd service that we installed on the Ubuntu server.
