Introduction to Web Application Security...16 Thursday, October 10, 2013 Gillis Jones for Derbycon...

Introduction to Web Application Security

Thursday, October 10, 2013

What is this “web”

Thursday, October 10, 2013 Gillis Jones for Derbycon 20132

The “World Wide Web” is the main

thoroughfare for accessing HTML web

pages and resources from across the

world.

Websites/Applications typically make

use of one of four ports.

HTTP(80;8080) HTTPS(443,8443)

Browsers!


-Apple Safari

-Mozilla Firefox

-Google Chrome

-Opera

-Konqueror

-Microsoft Internet Explorer

-Seamonkey

-Kmeleon

-QT

Browsers serve you rendered HTML that is provided by Web Servers.

HTML? HTTP? It’s all gr33k!


•Want to familiarize yourself

w/ HTML? Real-time Sandbox:•http://www.dreamtemplate.com/dreamcodes/d

ocumentation/html-editor/

HTML:A standardized system for tagging

text files to achieve font, color, graphic,

and hyperlink effects on World Wide Web

pages.

HTTP: An application protocol for

distributed, collaborative, hypermedia

information systems.

Simplified:HTTP(S) Makes the request, HTML is the rendered response

http://en.wikipedia.org/wiki/Application_protocol

http://en.wikipedia.org/wiki/Hypermedia

How can I see what a browser is doing?


•Proxying (Intercepting) Your

browser is the most effictive

way to view browser

requests/responses.

Effective Proxies:

Burp Suite (Free or Paid)

WebScarab

Fiddler

Charles

HTTPWatch

Firebug

Chrome Dev Tools

HTTPFox

For demonstration purposes, we will be using BurpSuite

Setting up your Browser Proxy.


•1. Go to your Browser

Network Connection Settings.

•2. For BurpSuite- Set the

manual proxy settings to

127.0.0.1:8080.

•3. Turn Intercept On.


•n

PROXY LISTENERS: Where you will route you browser connections

Intercept Client Requests: Outbound traffic you will intercept (Checkbox)

Intercept Server Responses: Inbound traffic you will intercept

What is a HTTP Request?


There are several basic parts to a response

- Request Type: (Get)(Post)

- Host: www.<destination>.com

- User-Agent: Your Browser Identifier

- Accept: Media accepted as a response

- Cookie: Server Defined cookies to

maintain state.

- Connection: Server should persist

connection or terminate.

There are 47 request headers specified in the W3 standard.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

URL Structure


http://www.example.com/site.asp?resource=1&attack=2

1.Protocol

2.Sub Domain

3.Domain Name

4.Top Level Domain

(TLD)

5.Resource

6.Parameters

1. This denotes the protocol used to transmit data (HTTP,FTP,SMTP,PPTP,etc.)

2. Subdomain is a specific domain within the main domain (Mail.example.com)

3. Domain Name is a quick reference tool for IP addresses. (example.com instead of 126.0.1.2)

4. TLD is the global identifier for domain location (.gov, .org, .eu,.jp,.it)

5. Resource is the file/directory that you are utilizing on the designated web server.

6. Parameters are passed to the file which you are utilizing on the server. (UserID=,Page=)

COOOKIES YOU SAY?


HTTP cannot maintain session state by

itself.

Cookies were developed as a clever

“Hack” to allow developers to establish

sessions.

These cookies are passed both in initial

request, and can be set in the server’s

HTML response.

Cookies maintaining state is fraught with exploitable problems.

HTML Responses


Once a request is made to a

server, the server responds with

a message containing the

requested content.

Content Types MAY include:

Text/html

Image/png

Image/gif

text/css

Audio/basic

HTML responses can often reflect

malicious input to execute code.

Attacker Mentality

{Trigger Warning: Hacking, XSS, SQLi, Pwnage,LULZ}


TL;DR= We want ur d0x.

Who is your threat?


Attacker Profile:

Your attacker IS:

Curious.

Dedicated.

Knowledgable.

Better than You.

Your Attacker ISN’T:

Omniscient.

Omnipowerful.

Omnipresent.

Fueled by Brawndo.

Brawndo, it’s got what plants crave.

What do you want to get?


Any site you test will have “Targets”

Usernames

Passwords

Administrative Functionality

System Configurations

Source Code

Personally Identifiable Information

Industry Secrets

Your Mission is to get as much valuable info in the shortest time possible

How will you get it?


•The Major Web Vulnerability

classifying bodies:

Open Web Application

Security Project (OWASP)

Web Application Security

Consortium (WASC)

There are an infinite number of “Mixed

threat” attacks that can be executed

against a target, however- most fall into

one of ten categories.

1.Insufficient Authentication

2.Insifficent Authorization

3.Session Fixation

4.Predictable Resource Location

5.Cross-site Scripting

6.Cross-site request forgery

7.SQL Injection

8.Insecure direct object references

Insufficient Authentication


•Items to look for:

•/admin/

•/userid=1&mode=edit

•Areas of a site accessible

when authenticated, but not

unauthenticated.

User

Credential

Check

Restricted

Content

User

Credential

Check

Restricted

Content

Normal Usage Attacker Strategy

Insufficient Authentication


•Applications occasionally

make use of content archiving

systems which assign a

number value to each

document. These files are

typically accessed via a URL

parameter such as fileID or

ID. Iterating (1…2…3…4)

through the ID’s can often

reveal files not meant for

public consumption.

Developers often times leave

Authentication checks restricted to the

initial “login” phase.

The thought behind this is that if you

know the URL (Which is “only”

displayed to authenticated users) then

you must be authenticated.

This can obviously be abused for

administrative functionality, however it’s

also common to find hosted

*Confidential or *Eyes Only, Memos &

Disclosures.

Insufficient Authentication Tips


•http://example/foo.cgi?admin=false

V

•http://example/foo.cgi?admin=true

•http://example/foo.php?userlevel=*

Finding Insufficient Authentication:

1. Be knowledgable of known vulnerable

areas (administrative, privileged user

access, target data)

2. Analyze Web Application for

parameter patterns (FileID, UserID,

Username=, Sensitive file names)

3. Using the identified Application

Specific Patterns, it should be

possible to surmise vulnerable URLs.

4. Attempt to visit functionality that you

can access while authenticated, when

unauthenticated.

This is common w/ routers & customer relationship

management systems

http://example/foo.cgi?admin=false

http://example/foo.cgi?admin=true

Insufficient Authorization


Tom Mary

Authorization

Check

Tom’s

Data

Authorization

Check

Mary’s

Data

Normal Behavior Attacker Behavior

Tom

Authorization

Check

Tom’s

Data

Mary

Authorization

Check

Mary’s

Data

Tom is being

naughty and

accessing

Mary’s Data

without

permission.

Bypassing all

authorization

checks.

Bad Tom.



•Can be as simple as iterating

through user id’s.

•Can likewise be extremely

complicated, requiring

intimate knowledge of

backend functionality.


Insufficient authorization is accessing

content of which you should not have

access to.

There are two types of Insufficient

authorization.

Lateral- (User to User)

Vertical-(User to Higher Privilege

Level)

Vertical Insufficient authorization is commonly referred to as privilege

escalation!


Change Parameter

Account_no from 1

to 9


Resulting transaction details are COMPLETELY different, suggesting that

you have successfully accessed another person’s details w/o

permission.

Authorization Tips & Tricks


• User ID’s can often be

sequential, administrative

account will often times be

the lowest number

(001,002, etc.)

• These admin account id’s

will often reveal sensitive

data, if accessible.

1. Just because you don’t hit something

on your first try, does NOT mean it

isn’t there.

2. Often times developers may have

auth checks in place for every other

piece of functionality, but even the

most miniscule chink in the armor can

lead to a full compromise.

3. Help sections meant for auth’d users

can often contain Admin exclusive

links & functionality- as well as

credentials.

Session Hi-Jacking

(Session Fixation)


Common URL Parameters:

JSESSIONID

SESSIONID

LOGINAUTH

AUTHCOOKIE

ASPXAUTH

Session Hijacking is most often

found/exploited when sensitive

cookie(s) are passed inside of URL.

This is bad because if an application is

ONLY using the cookie being passed

to authenticate users, and the cookie

is being passed via unsecured GET

parameters- then any intermediary is

able to compromise a user session

with little effort.

Cross Site Scripting (XSS)


•There are 3 kinds of XSS

commonly recognized.

•(1) DOM Based

•(2) Non Persistant/Reflected

•(3) Persistant/Stored

XSS allows attackers to execute scripts

in the victim’s browser, which can

hijack user sessions, deface web sites,

insert hostile content, conduct phishing

attacks, and take over the user’s

browser using scripting malware.

This is typically achieved by storing

unsanitized user data on the server,

and rendering the resulting

metacharacters in html.

XSS EXAMPLE


•POST Requests

• (Unexpected user input)

Stored Cross Site Scripting attacks

are arguably the most dangerous XSS,

and will be what we are discussing.

Testing for cross site scripting typically

involves dropping in a metacharacter

string in to potential attack points such

as:

Login Screens

Log Files

Error Messages

Welcome Screens (Welcome X Name)

Comments

Messages to other Users

Anywhere that your input is stored.

Common XSS Test Strings


Metacharacter

Title

Metacharacter

Symbol

URL Encoded

Metacharacter

Double Encoded

Metacharacter

Hex Encoded

Metacharacter

Dbl Quote “ %22 %2522 "

Single Quote ‘ %27 %2527 '

Greater Than > %3e %253e >

Less Than < %3c %253c <

Forward Slash / %2f %252f ?

Forward Paren ( %28 %28 (

Back Parenth ) %29 %29 )

XSS Analysis


1. Escape context that your

input lands into.

2. Exploit the context that your

input is in.

3. Rewrite the page entirely.

4. Iframe Your Own Page into

the context.

When analyzing a page for vulnerable

inputs, you are looking for anywhere that

your input is landing unsanitized.

SUCH AS:

<HTML>

<h1>

<script>test(“USERINPUT”)</script>

</h1>

</HTML>

A possible injection for this HTML would be:

“)</script><script>alert(document.cookie)</script>

What is SQL?


SQL IS NOT

•A magical unicorn that will

give you leet dox.

•Pronounced “Squeal” ಠ_ಠ•The solution to everything.

SQL= Structured Query Language

is a special-purpose programming

language designed for managing data

held in a relational database

management systems

Used pre-dominantly for storing

relational data, files and server

instructions.

A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

https://www.google.com/url?q=http://www.urbandictionary.com/define.php?term=%E0%B2%A0_%E0%B2%A0&defid=3837013&sa=U&ei=m_pEUqbnHo6-9gTXgYHADg&ved=0CBwQ0gIoADAA&sig2=XfVdrok3uscidZyJAKKS7Q&usg=AFQjCNGS-rO18-3ru2PdIgQa62J3wMGx2A

SQL INJECTION


When passing data to a datebase

(MSSQL,ORACLE,MYSQL,Etc.)- the

input is typically expected to be in a

known trusted format.

However, attackers can make use of

metacharacters (‘,%27, ', etc) to

break the syntax that is passed to the

server.

This can allow an attacker to pass their

own SQL commands to the server.

Common SQLi Uses


•Statically written webpages

typically won’t have many

parameters that could be

vulnerable.

•Dynamic pages (rendered

based on input or browser

variables) are more likely to

be exploitable.

• Reading content in the database not

meant for public consumption.

(Usernames,Passwords,Hashes,

Credit Card Numbers)

• Writing malicious content into the

database, which can be used to

essentially “Take Over” a given

server.

• Mass defacement of a website.

• Hosting malware.

• Depending on the design of the

application, this can be a devastating

attack.

What to watch for?


•Numeric parameters

(Page=22) (User=13)

•Requests which contain

attacker supplied data

(searches, orders, etc)

•Requests which result in error

messages

SQL Injection relies on data being passed

to a database, in order to manipulate or

view data.

Requests or Parameters which only

update the DOM are typically not good

candidates for SQL injection.

Good Candidates:

• Shopping elements

• Price,ItemID,Amount,Discount,etc.

• News Article/Blog Posts

• PostID,BlogID,PostDate,Author

• Function Elements

• Function,pageid,id,command,etc.

SQL Injection Workflow


Vulnerable

Parameter

Error

Message?

Correct Error

Exploit

Vulnerable

ParameterAttempt

Injection

Discernible

change from

initial

observation?

No

Yes Exploit

Error based sql relies on error messages.

Returning

Data?

Blind SQL is depending on Results instead of errors

Observe

Normal

Behavior

Cross Site Request Forgery (CSRF)


There is NO way to

make CSRF funny.

I’ve tried.

CSRF is an attack which utilizes the lack on intention verification to get

users to execute application commands without their knowledge.

Cross-Site Request Forgery


•POST requests are NOT

immune to CSRF attacks.

•It is possible to utilize

XMLhttprequest to force a user

to issue POST requests.

Applications are often built with the

mindset that any request coming from a

user is authorized, because the user is

obviously authenticated.

Because of this, there is typically no

user intention verification (Captcha,

Nonce,Per Request Dynamic Tokens)

An attacker can exploit this weakness to

force a user to make requests without

their knowledge.

CSRF


•What to look for?

• Password Change

• Account Transfers

• State Changing

Requests.

Testing & Analyzing applications for CSRF

• Watch for sensitive functionality going

over GET requests.

• If a particular functionality utilizes

CAPTCHA, it does NOT mean it’s not

vulnerable. (Try stripping the param or

see DC949’s Stiltwalker)

• While authenticated:

• Capture Sensitive Requests in Burp

• Analyze for any Request specific

tokens

• Attempt to “Replay” sensitive request

• Analyze application for response to

replayed request.

CSRF Attack Scenario


Annie discovers a Bank Transfer being made over a GET request

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

Annie modifies the link to reflect her name in the acct= field, changes amount

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

Annie then creates an img, which is hosted on a malicious page & auto loaded.

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

Annie doesn’t want maria to see the response, so she creates a zero-byte image.

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0">


Maria just transferred 100,000 dollars to Annie-

without even knowing she did it.

Maria is an overachiever.

BUTAnnie is rich.

There ARE banks that are this oblivious.


There was a time that these

Vulnerabilities were “out of the reach”

of every day attackers.


But that’s NOT the case anymore.


With little to no training, not using even half of the

popular vulnerabilities.

You Have:


1. Accessed Classified Files

2. Impersonate Administrators

3. Steal Valid User’s Sessions

4. Download Malware on Client’s PC

5. Retrieve full PW hashes of Server

6. Steal hundreds of thousands from

poor, unsuspecting Maria

Quick Bonuses


Often times you may encounter a device called a Web Application Firewall.

These devices are meant to shield servers from malicious requests.

To avoid these devices, typically all you need to do is obfuscated your expected

attack.

Obfuscation meaning “hiding” your attack amongst different encoding methods.

Double URL encoding: %2522 will pass into a WebApp as “, allowing for execution.

Occasionally, even old skool hacks come in to play in Web Apps.

Nop Sleds: (opcode 0x90) used to allow for code execution inside of programs by

Quick Bonuses


Occasionally, even old skool hacks come in to play in Web Apps.

Nop Sleds: (opcode 0x90) used to allow for code execution inside of programs.

This is now applicable to Web Apps as well, if you are interacting with a Web

Application that utilizes a WAF, dropping a URL encoded NOP Sled

(%90%90%90%90%90%90) can often times cause WAF’s to seize

And even completely ignore traffic which is being sent to it, allowing for your

Malicious traffic to go through just without being analyzed by the WAF.

Date post:	24-May-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Introduction to Web Application Security...16 Thursday, October 10, 2013 Gillis Jones for Derbycon...

Documents