application security 101
TRANSCRIPT
APPSEC 101BREAK STUFF LIKE A PRO! WELL, ALSMOST…
Vladimir Garbuz
HP ALM Security Center of Excellence
Intro
What these sessions are NOT
What these sessions are
Contents
AppSec testing tools
Testing stages
Mapping application’s content
Input-based vulnerabilities
Denial of Service
Client-side controls
Authentication mechanism
Session management
Logic flaws
Application Server Vulnerabilities
Final word on process and security RC
AppSec testing tools
the Swiss Army Knife of AppSec – Fiddler
not just a proxy
inspect HTTP and HTTPS! (best served in RAW)
modify and replay
intercept mid-air
setup reverse proxy mode
get request stats
set filters
do text encoding
autoresponder
scripting in C#
AppSec testing tools
WireShark – when Fiddler doesn’t cut it
only passive traffic monitoring
sees everything!
your browser’s developer console
socket programming in any language, e.g. Python
hacker’s mindset
Mapping application’s content
read the feature specs
monitor HTTP traffic for all user data entry points
look at interface differences for different user roles
discover hidden content
ViewDocument.jsp Delete, Upload, Edit, Create, etc.
lookout for direct server file access (filename specified)
lookout for verbose error messages
lookout for debug/god-mode parameters
lookout for disabled old/future functionality
lookout for default content - webserver console, files,...
Input vulnerabilities
Input vulnerabilities: basic checks
check if server correctly handles unexpected data
negative indexes and values
overly large integers
zero-bytes and other string terminators (e.g. “, #, ;)
non-existing string specified dates
look for differences in processing of directly submitted
values AND when parsed from a user uploaded or
controlled file
relates to ALL input-based vulnerabilities!
Input vulnerabilities: SQL injections
use DB server management software and profiler
submit ‘ or “ in request, not only “Edit” operations!
SQLi can be anywhere where DB is accessed based on
user data, in any way!
monitor for server errors AND the DB log/profiler!
broken SQL query in DB log, error, etc?.. REPORT!
Input vulnerabilities: XSS injections
general principle – lack of input encoding
user submitted data is unmodified in HTML page
from Google XSS guide: "A good test string is
>'>"><img src=x onerror=alert(0)
generally, raise an ALARM for any of the following 5:
< > & " ‘
within HTML actions and JavaScript code, additionally
\n \r \’ \” \\ \uXXXX
sometimes escaping won’t help
ALARM if URL protocol (http, https) can be manipulated
Input vulnerabilities: XSS injections
reflected XSS
when a part of URL is reflected back in HTML page
DON’T forget to URL encode special characters! e.g.:
http://url.com/1.jsp?param=%3E%3Cscript%3Ealert(1)
%3C%2Fscript%3E
stored XSS
a malicious string is added to the server once and
displayed as a part of a page to everyone viewing it
from POST body, HTTP header, uploaded file, HTML
based server log, etc… MANY vectors!
Input vulnerabilities: XSS injections
DOM XSS
caused by unsafe JS during runtime inside the browser
basically, all ALM AngularJS XSS were DOM XSS
same principles apply (at this low level)
monitor for special chars appearing in resulting HTML!
OK, that’s enough, I’m leaving!
Input vulns: HTTP header injection
for each response header where user data appears
try inserting carriage-return and line-feed symbols
the actual symbols! “0d” and “0a” in hex
if they are returned in server response header unmodified
ALARM! malicious server headers can be forged or HTTP split!
Input vulns: Open redirection
if the URL data specifies a redirection target
try modifying or adding the redirection domain, e.g. in
http://url.com/qcbin/authentication-point/web-ui-
login.jsp?redirect-url=%2Fui%2F
after that, trigger an event that causes redirection, e.g.
login
if it redirects to a different domain, ALARM!
Input vulns: OS command injection
if you suspect (or know) some input is passed to
system shell, try adding additional commands. E.g.:
; cat /etc/passwd
http://url.com/ping.jsp?ip=8.8.8.8%3B+cat+%2Fetc%2F
passwd
if cannot get the response, try long running command
or creating a file to see if the attack was successful
if this works or something weird happens – ALARM!
Input vulns: Path traversal
a file path or name is directly specified?..
try adding ../../ in sequences to backtrack out of current
directory and access server file system
you can create a test file and try accessing it
also run Process Monitor by Sysinternals to monitor file access
if you gain access to other files or something fishy
happens – ALARM!
Input vulns: XML injections - XXE
XML External Entities
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" > ] >
<username>&xxe;</username><password>……………
if no error or file is retruned by server – ALARM!
if gives an error, but it disappears after you remove
embedded entity and leave only declaration, ALARM!
<username>blabla</username>
Input vulns: XML injections - DoS
Recursive “billion laughs” attack
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT lolz (#PCDATA)>
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<username>&lol9;</username><password>……………
Denial of Service
Denial of Service
API request flooding
check if server correctly handles unexpected data
oversized data
zero-bytes in input
XML “billion laughs” attack or XXE of a huge file (/dev/random or c:\pagefile)
logic fuckups (sorting)
unpacking
recursion
large low entropy data
malicious usage of regex, globbing
asynchronous/heavy functionality invocation
text instead of number
………
thread/socket exhaustion – e.g. slow HTTP, slow request
………
Denial of Service
Client-side controls: Data transmission
locate and understand all hidden fields and
parameters in client request
try to intelligently modify them according to their
name/meaning to pwn the system
for encoded, obfuscated or badly encrypted data
decode/decrypt, play with it, encode/encrypt back
and replay to pwn the server
e.g. ASP.NET ViewState is using base64 encoding, like
YmFzZTY0IGV4YW1wbGU=
Client-side controls: User input
find all places where client restricts input length or
JavaScript enforces some rules or logic
always check if the server-side code does the same
not always a vulnerability, but CAN lead to pwnage
find all controls that are invisible/disabled for certain
user groups, but visible to others
record a request such controls send for users who can use
them and replay them with user sessions that can’t
servers frequently trust client-side to perform permissions
checking, which is… erhm… not very smart
Authentication mechanism
Authentication mechanism
Test password quality
no/weak rules at registration OR “change password”
attempt to log in with password variations
e.g. make a long password and try to log in without the last
char
change character case of one letter an see if that is successful
ensure no “default accounts” are present in final release
Authentication mechanism
Test username enumeration
find ALL locations where the username is submitted, e.g.
primary login, self-registration, password change, logout,
account recovery, etc…
attempt submitting valid and invalid user names
check if the server responses differ in ANY way (small
typographic differences, server response time, etc.)
ALARM on any difference
Authentication mechanism
Test resilience to Password Guessing
find ALL locations where user credentials are submitted
e.g. login or badly designed “password change”
try submitting various passwords for a user
after ~10 times, enter valid ones
if all this succeeds – the system is vulnerable, ALARM!
Authentication mechanism
Check for unsafe transmission of credentials:
in URL
stored in cookies
if ever transmitted from server to client
creds are vulnerable to session, access control and XXS attacks
should never go over HTTP
if creds are sent over HTTPS but the login page over HTTP
MITM attacks can steal creds, ALARM!
Authentication mechanism
Check for insecure storage
check all logs for credentials
or their hashes
check configuration files for clear-text credentials
check for credentials saving on client-side
in logs, in browser or client “autocomplete”, etc
all the points are valid for both client and server side
Session Management mechanism
Check for insecure transmission of Session Tokens
under HTTPS, check if Secure flag is set for cookies
verify that HTTP and HTTPS parts of application use
different cookies
Session Management mechanism
Check Cookie scope - Domain
domain better not be set than set liberally to a domain
e.g. domain=server.com gives the cookie to subdomains
Check Cookie scope - Path
path must include only the webapp for which the cookie is
Session Management mechanism
Check for insecure Session tokens storage
when in URL – proxy logs, Referer header, screen
or visible in some logging mechanisms
Logic flaws
Logic flaws
Check for Fail-Open conditions
whenever the app checks user’s credentials, make a note
of all the request parameters
for each parameter, try:
submit an empty string as the value
remove the name/value pair
submit very long and very short values
submit strings instead of numbers, and vice versa
submit the same named parameter multiple times, with the
same and different values
notice any unusual behavior? ALARM!
Logic flaws
Check Multistage mechanisms
a single action is performed via a fixed series of steps?..
modify the steps to interfere with app’s logic, e.g:
pass all stages, but in a different sequence
go directly to each step in turn, and continue the normal
sequence from there
go through the normal steps repeatedly, skipping each single
step
be clever and try breaking the multistage process
see anything fishy?... ALARM!
Logic flaws
Application server vulnerabilities
Check for default content and creds
google info on default config of your specific server
try default server admin accounts
try default management console, UI
nothing irrelevant to the web-app should be present!
Application server vulnerabilities
Check for dangerous HTTP Methods
try issuing a TRACE request – shouldn’t work, i.e. shouldn’t
return your request to you
try issuing an OPTIONS request – shouldn’t work either
not a vulnerability but may aid attacker, bad practice
Process and security RC
don’t be afraid to bother with questions or something
suspicious – you are our helping hands
another upside – you’ll definitely learn something new
report every suspicious instance – even if you couldn’t
write an exploit
prioritize security RC defects
nothing high or critical from OWASP Top-10
Questions and Discussion