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.

The mechanics behind how attackers exploit simple programming mistakes ...

87 views

Published on

A good defense against insecure code requires understanding the mechanics behind how attackers exploit simple programming mistakes. Developers today face a massive onslaught of new and old attack vectors in both the code they write and the open source they use.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

The mechanics behind how attackers exploit simple programming mistakes ...

  1. 1. OWASP 1 Agenda ● Introduction to OWASP (Open Web Application Security Project) & Web application security Overview ● Review of OWASP Top 10 Web Application Security Vulnerabilities ○ Description and Affected Environments ○ Detection and Protection ○ Code Example (Where possible/applicable) ○ Defense Mechanisms
  2. 2. OWASP About Me Bruce Mayhew Director of Data Research at Sonatype Project Lead and co-author of WebGoat Me: webgoat@owasp.org WebGoat List: owasp-webgoat@lists.owasp.org Slack: https://owasp.slack.com/messages/project-webgoat 2
  3. 3. OWASP 3 Introduction to OWASP ● Open Web Application Security Project Ref: www.owasp.org ● Workshop partially driven by OWASP Education material
  4. 4. OWASP Risk Ratings Ref: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology 4 What is the risk if I steal your password? What is the risk of an asteroid hitting earth? What is the risk of another Equifax ?
  5. 5. OWASP What are power law distributions? 5
  6. 6. OWASP 6 Deadliest Earthquakes since 1900
  7. 7. OWASP Japan Earthquakes 7
  8. 8. OWASP Fukushima Reactor Fit 8
  9. 9. OWASP Reality 9
  10. 10. OWASP Terrorism 10
  11. 11. OWASP Applicable to Security Breaches? 11 Power Law
  12. 12. OWASP So what can we do? 12 Inevitability
  13. 13. OWASP 13 Web application security Overview ● Application level attacks occur on Port 80/443, used for legitimate web traffic ● Secure Socket Layer (SSL) does not protect against application level attacks. ○ SSL only encrypts the tunnel ● Hardening (Web Server and OS) does not prevent Port 80/443 attacks ● WAF/IDS ○ Only detect known holes, don’t have signatures that match these attacks ○ Hard to configure ● Secure coding and component management– the only way to prevent application level attacks ○ Unit test attacks are often not included
  14. 14. OWASP OWASP Top 10 Risk Rating Key 14 Easy is “bad” How difficult is this to exploit in the wild Widespread is “bad” How often is this seen Easy is “bad” How easy is this to find Severe is “bad” How much damage can this cause
  15. 15. OWASP 15 OWASP Top 10 - 2017 A1 - Injection A2 - Broken Authentication and Session Management A3 - Sensitive Data Exposure A4 - XML External Entities A5 - Broken Access Control A6 - Security Misconfiguration A7 - Cross-Site Scripting (XSS) A8 - Insecure Deserialization A9 - Using Components with Known Vulnerabilities A10 - Insufficient Logging & Monitoring https://www.owasp.org/images/7/72/OWASP_Top_10-2017.pdf
  16. 16. OWASP 16 A1 - Injection Flaws Occurs when an attacker relays malicious code through an application to another system
  17. 17. OWASP 17 A1 - Injection Flaws ● Description ○ Injection occurs when user-supplied data is sent to an interpreter as part of a command or query ○ SQL injection is the most common ● Affected Environments ○ All web application frameworks that use interpreters are vulnerable to injection attacks.
  18. 18. OWASP 18 A1 - Injection Flaws ● Detection ○ Verify that the user cannot modify commands or queries sent to any interpreter used by the application ○ Code Reviews are useful to detect ■ Difficult to definitively detect with penetration testing ● Protection ○ User input validation using whitelists ○ Avoid interpreters where possible ○ Parameterized queries ○ Enforce least privilege
  19. 19. OWASP A1 Injection Flaws Summary ● Attacks are performed by hackers benefitting from YOUR mistakes ● All sources of data are vulnerable to injection; the environment, variables, parameters, external/internal web services etc. ● Minimal tools and skill set needed to perform these attacks ● Injection vulnerabilities usually found in SQL, LDAP, XPATH, XXE, XML, etc. ● Scanners and fuzzers help one find injection flaws (attackers and defenders) ● Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover 19
  20. 20. OWASP 20 A1 - Injection Flaws ● Vulnerabilities ○ SQL Injection ○ Command Injection ○ XXE Injection ○ XML Injection ○ LDAP Injection ○ RCE Injection
  21. 21. OWASP 21 SQL Injection ● Dynamic query in application ○ “select * from users where name = ‘” + userName + “ ’” ○ “select * from users where employee_id = ” + userID ● Attacker supplies unexpected text ○ userName = Bruce’ or ‘1’=‘1 ○ userID = 1234567 or 1=1 ● Application executes query ○ select * from users where name = ‘Bruce’ or ‘1’ = ‘1’ ■ select * from users where name = Bruce or TRUE ■ All records are returned from database ○ select * from users where employee_id = 1234567 or 1=1
  22. 22. OWASP 22 A1 - SQL Injection - Try It
  23. 23. OWASP SQL Injection Defense Mechanisms ● Input validation ○ Prevents other attacks from being stored ○ All data acted on by SQL commands should be escaped for meta-characters ● Parameterized queries and parameterized stored procedures ● Connecting with least privilege ○ Limits damage if SQL injection occurs 23
  24. 24. OWASP 24 A4 - XML External Entities (XXE) A type of injection attack which parses XML Input
  25. 25. OWASP A4 - XML External Entities ● Description ○ An injection type of attack which occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser ● Affected Environments ○ Any web application framework containing weak XML Parsers 25
  26. 26. OWASP A4 - XML External Entities ● Exploitation of vulnerable XML Processors can only happen under specific conditions ○ Upload XML or include hostile content in an XML Document ○ Exploit code, dependencies, or integrations ● Using older XML Processors is not advised as they allow a specification of an external entity ● SAST tools can discover this issue by inspecting dependencies and configuration ● DAST tools will work as well but require additional manual steps to detect the issue ● Flaws can be used to; extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, etc. ● Business impacts vary on the protection needs of affected applications and data 26
  27. 27. OWASP A4 - XML External Entities ● Vulnerabilities ○ Application accepts XML directly ○ XML Processors in application have DTDs (document type definitions) enabled ○ If your application uses SAML for identity processing within single sign on purposes 27
  28. 28. OWASP A4 - XML External Entities - Application Accepts XML Directly ● Since the server accepts XML directly, the attacker can upload malicious XML. ● For example, this attacker attempts to extract data from the server using this source code ○ <?xml version=”.-”encoding=”ISO-8859-1”?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM “file:///etc/passwd” >]> <foo>&XXE;</foo> ● While this source code may not work on every application, it is an example of how easy it is for an attacker to upload malicious code when application accept XML directly 28
  29. 29. OWASP 29 A4 - XXE - Try It
  30. 30. OWASP A4 - XML External Entities - DTDs ● DTDs are a template that set out the format and tag structure of an XML compliant document ● DTDs can allow DOS attacks such as Billion Laughs/XML Bomb ● For example, Billion Laughs would look something like this ○ <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE lolz[ <!ENTITY lol "lol"> <!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;"> ]> <lolz>&lol9;</lolz> ● When an XML parser loads this attack, it sees the one element “lolz”, that contains the text “&lol9”, which is an expansion of “&lol8”, which is an expansion of “&lol7”, so on and so forth ● This block of XML actually contains 10⁹ “lol’s” (or one billion) and takes over 10 GB of memory 30
  31. 31. OWASP A4 - XML External Entities - Defense Mechanisms ● Use less complex data formats such as JSON, whenever possible ● Upgrade or patch all XML processors and libraries being used by the application or on the underlying OS ● Disable XXE and DTD processing in all XML Parsers being used by the application ● Whitelisting ○ server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes. ● Use SAST tools to help detect XXE in source code 31
  32. 32. OWASP A9 - Using Components with known Vulnerabilities 32 Older versions of components tend to have more known vulnerabilities. These vulnerabilities can easily be taken advantage of by an attacker
  33. 33. OWASP 33 A9 - Using Components with known Vulnerabilities ● Obviously, it’s very easy to find already-written exploits, but finding other vulnerabilities requires concentrated effort ● Component heavy development patterns can lead to teams not understanding which components they use in their application/API ● Some scanners (such as retire.js) help in detection but one cannot rely on this. Teams must have full information on what components and version number they are using for said project ● The impacts will vary. Some vulnerabilities will lead to minor impacts and some have the largest breaches to date ● The risk can jump to the top of the list depending on the assets one is protecting
  34. 34. OWASP ● Vulnerabilities ○ All of them (XSS, XXE, RCE, Buffer Overflow…… ) ○ Lack of a Bill of Materials for application components ○ Lack of risk re-evaluations; new risk discovered every day ● The underlying vulnerability is a general lack of a component management strategy. A9 - Using Components with known Vulnerabilities 3434
  35. 35. OWASP ● There are many components whose older versions have blatant vulnerabilities ○ CVE-2017-5638, CVSS 10 - Struts (Equifax ) - RCE. ■ 20% of organizations are actively using it ○ CVE-2010-1632 - CVSS 7 - Axis2 - DoS ■ 50% of organizations are actively using it ● Components age like milk; not wine A9 - Using Components with known Vulnerabilities - Example 35
  36. 36. OWASP A9 - Components Age Like Milk 36 ● Components older than 2 years: ● Account for 62% of all components ● Account for 77% of the security risk ● Are likely inactive ● Application vulnerability density is 6.8 %
  37. 37. OWASP A9 - The Developer Ask 37
  38. 38. OWASP A9 - Vulnerable Components - Try It 38
  39. 39. OWASP ● Ways of defending include ○ Removing unused dependencies, unnecessary features, components, files, and documentation ○ Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies ■ You can use tools such as versions, DependencyCheck, retire.js, to complete this process. ○ Only obtain components from official sources over secure links. ● Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application. A9 - Using Components with known Vulnerabilities - Defense Mechanisms 39

×