The magic of passive web vulnerability analysis lava kumar

OWASP InfoSec India Conference 2012
August 24th – 25th, 2012 The OWASP Foundation
Hotel Crowne Plaza, Gurgaon http://www.owasp.org
http://www.owasp.in

The Magic of Passive Web
Vulnerability Analysis
Lavakumar Kuppan
lava@ironwasp.org
https://twitter.com/lavakumark
https://ironwasp.org

OWASP InfoSec India Conference 2012. Hotel Crowne Plaza, Gurgaon (India)

About
Penetration Tester
5+ years of experience

Security Researcher
Flash 0-day
WAF bypass 0-day using HPP
Multiple HTML5 based attack techniques
5th best Web Application Hacking Technique of 2010
Attack and Defense Labs – http://andlabs.org
HTML5 Security Resources Repository – http://html5security.org


About
Developer
IronWASP (C# + Python + Ruby)
Ravan (PHP + JavaScript)
JS-Recon (JavaScript)
Shell of the Future (C# + JavaScript)
Imposter (C# + JavaScript)

Speaker
BlackHat
OWASP AppSec Asia
NullCon
SecurityByte
ClubHack

Pentesters are focused on the big catch

SQL Injection
Cross-site Scripting
Command Injection
Code Injection
etc

OWASP InfoSec India Conference 2012. Hotel Crowne Plaza, Gurgaon (India) 4

So the focus is mostly on Active Checks


Passive Analysis is done by the tools


What about Manual Passive
Analysis?


Let’s look at what Manual Passive
Analysis will find
(using IronWASP)


Step 1 – Collecting HTTP Logs

Set IronWASP as the proxy and browse the
site
Automated Crawling of the site
Import Burp Proxy Logs


Step 2 – Make list of all Parameter Name/Value

Parameters include:
Query parameters
Body parameters
Cookie parameters
Request & Response Header parameters
Set-Cookie parameters
Form field parameters in HTML response


Step 3 - Print out the parameter names
Eg:
lang
user
pwd
id
…
…
logged_in
is_admin
…
…
Notice anything interesting?
This can be probed further manually


And used for Hidden Parameter Guessing

Regular Password Change Url:
http://test.site/change_pwd.php
Password Change Url with inclusion of
Hidden Parameter
http://test.site/change_pwd.php?is_admin=1
Now ‘Change Password’ feature does not ask
for old password!!!


Step 4 - Print out the parameter values
Eg:
en
true
23944
s77eod
…
…
Fy2010_11_report.pdf
Fy2011_12_report.pdf
…
…
http://partner.site/data.php
…
…
SELECT id FROM Users
…

Parameter Values say a lot
Fy2010_11_report.pdf – possible LFI vulnerability
http://partner.site/data.php - possible RFI / Open
Redirect vulnerability
SELECT id FROM Users – SQL queries created on the
client-side and executed on the server-side !!!
Ironically automated scanners might not detect this
type of SQL Injection!


Check parameter values for possible encoding
Do you see anything interesting in the strings below:

asdljz2398sdsdsdsdkss
z23sds9sd9a;sdk=awe
bgf2yto6c2vjcmv0mtiz
646973636f756e743a323125
2238019jadja8498434dfdf
Lsjflosow2384fkshfl


How about now?
asDljz2398sdYDKus3lns
z23sdE9sd9Asdk=awe
bGF2YTo6c2VjcmV0MTIz –Base64 Decode-> lava::secret123
646973636f756e743a323125 –Hex Decode-> discount:21%
2238019jadja8498434dfdf
lsjflosow2384fkshfl

Base64 and Hex encoding are the most commonly used encoding
schemes in web apps
Try base64 and hex decoding all parameter values and see if they
decode to ASCII strings or binary strings with embedded ASCII
values
There could be interesting data hidden there


Check parameter values for Hashes
Make list of parameter values that are of the same
format as MD5 & SHA
Try cracking these hashes by using dictionary list of
the other parameter values
You will know if any parameter value is linked to this
hash
Helps you probe the connection further


CSRF token Analysis
Once you know the name of the CSRF token check it
against the list of Parameter names
If any request contains the CSRF token in Query
then it’s a problem (similar to Session ID in Url)
http://test.site/action.php?create_user=test&token=JDK7kS02jso

If any POST request does not contain the CSRF
token in body then is probably a problem.
Investigate.


Clickjacking through lack of Framebusting
Find out the JavaScript code that is used as
Framebuster to protect against ClickJacking
Check JavaScript islands in all HTML pages for this
Framebuster
List out all pages that don’t have it. These are
probably vulnerable to Clickjacking. Investigate.


Cookies set/manipulated on the Client-side
Compare key/values from the Set-Cookie response
headers to the key/values in the Cookie request
header
Any key/values in the Cookie header that is missing
from the Set-Cookie header has been set by
JavaScript
Indicates data storage or possible logical decision
making on client-side. Investigate.
Eg:
Set-Cookie: discount=10%; path=/

Cookie: SessionId=oasow823djdlna33rfz; discount=13%

Check for Reflections
Analyze all responses for reflection of any of the
input parameters
If user input is reflected back in the response then it
must be tested for Cross-site Scripting
This helps identify potential candidates for Stored
Cross-site Scripting


Closing notes
These are only indications, what you can do is only
limited by your imagination
A Python script that automates all discussed
techniques will be made available at
https://github.com/lavakumar before end of this
month
This script would soon be turned in to an IronWASP
module with GUI

Thank You!

Subscribe mailing list

www.owasp.in
Keep up to date!

24


The magic of passive web vulnerability analysis lava kumar

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (14)

Similaire à The magic of passive web vulnerability analysis lava kumar

Similaire à The magic of passive web vulnerability analysis lava kumar (20)

Dernier

Dernier (20)

The magic of passive web vulnerability analysis lava kumar