1 / 38

Drinking from the Firehose : Ten Years of Vulnerabilities through the CVE Lens

Drinking from the Firehose : Ten Years of Vulnerabilities through the CVE Lens. Steve Christey The MITRE Corporation April 21, 2010. Welcome to 1998. Vulnerability databases were mostly private “We’ll show you our database if you show us your NDA” Bugtraq was a low-traffic list

ariane
Download Presentation

Drinking from the Firehose : Ten Years of Vulnerabilities through the CVE Lens

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. Drinking from the Firehose:Ten Years of Vulnerabilities through the CVE Lens Steve Christey The MITRE Corporation April 21, 2010

  2. Welcome to 1998 • Vulnerability databases were mostly private • “We’ll show you our database if you show us your NDA” • Bugtraq was a low-traffic list • CERT advisories said very little • Exploits were shared privately • Attacks were rampant for months/years • Vendors didn’t fix things for months/years • Vulnerability scanning industry still in infancy • WWW wasn’t ubiquitous • Maybe 10 unique vulnerability types • “Smashing the Stack” was only 2 years old • Most reported vulnerabilities were in servers

  3. Party Like it’s 1999 Security Advisories Priority Lists Software Vendor Patches Vulnerability Scanners Intrusion Detection Systems CVE-1999-0067 Research Incident Response & Reporting Vulnerability Web Sites & Databases

  4. An Approximate Timeline ofSome Important Events 1999: Public launch 2000: Building steam, learning from mistakes 2001: Content decisions still evolving 2002: SNMP/PROTOS, responsible disclosure 2003: More regular updates, smaller batches 2004: Voting largely abandoned; increasing volume 2005: VIM mailing list, NVD dependence 2006: milw0rm 2007: grep-and-gripe, multi-stage exploits 2008: Getting to “root cause” 2009: drowning in details, oss-security 2010: back to the essentials?

  5. CVE Growth Over the Years

  6. Number of Words per Description

  7. Number of References per CVE

  8. “Counting” Varies Widely CVE-1: SQL injection in version 1.x through login.php and order.php. CVE-2: SQL injection in version 2.x through admin.php. CVE-3: XSS in version 2.x through login.php and search.php. ISS and Bugtraq ID OSVDB 1: Mult. SQL injection in 1.x and 2.x 1: SQL injection in login.php 2: XSS in 2.x 2: SQL injection in order.php 3: SQL injection in admin.php Secunia, ISS, and Bugtraq ID 4: XSS in login.php 1: SQL injection and XSS in 1.x and 2.x 5: XSS in search.php

  9. Content Decisions: Abstraction These factors are generally stable across all phases of vulnerability disclosure, and often known early in the game. http://cve.mitre.org/cve/editorial_policies/cd_abstraction.html AB1: SPLIT if different flaw types AB2: SPLIT if different versions are affected SPLIT if different vectors are released at a later time SPLIT if different codebases Otherwise MERGE

  10. Content Decisions: Inclusion Site-specific / hosted software can be difficult to identify. • INCLUDE any issue for software that • Could be deployed in an enterprise • Could be network-connected physical devices • Has minimal, but non-zero, risk • path disclosure, admin-to-SYSTEM, client-side crasher • EXCLUDE any issue that • Is “site-specific,” SaaS, hosted, “in the cloud,” … • Is provably wrong • Is just a rumor • Is not “actionable” • Is “just a bug” (e.g. defenestration exploit)

  11. “All Publicly Known Vulnerabilities,”Ten Years Later Shout-outs to OSVDB for still trying to track everything. • Site-specific (SaaS, Cloud, etc.) • How to even identify these? • Legal questions: can you hack your own site if it’s on someone else’s physical system? • Joe Schmoe’sphpGolf application • Country X’s most popular IM app • Physical devices: mobile, voting machines, remote-control coffee makers, alarm clocks with built-in microphones, software that disables cars, SCADA • Vulns from the 1960’s • Vulns in malware

  12. Anatomy of a CVE Description:CVE-2009-4623 Multiple PHP remote file inclusion vulnerabilities in Advanced Comment System 1.0 allow remote attackers to execute arbitrary PHP code via a URL in the ACS_path parameter to (1) index.php and (2) admin.php in advanced_comment_system/. NOTE: this might only be a vulnerability when the administrator has not followed installation instructions in install.php. Flaw type, vendor name, product name, affected versions, remote/local, impact, attack vectors, clarifiers.

  13. 10 Years of CVE Descriptions

  14. 10 Years of CVE Descriptions

  15. Some Favorite CVEs

  16. Rise of the Web Applications • 17% “other”

  17. Postcards from the Linux Kernel

  18. The Common Weakness Enumeration http://cwe.mitre.org 800 weaknesses - not 40,000 vulnerabilities Builds heavily on CVE and external taxonomy efforts Main goal: prevent CVEs from happening in the first place

  19. 2010 CWE/SANS Top 25 Programming Errors • 1. CWE-79 XSS • 2. CWE-89 SQL Injection • 3. CWE-120 Classic Buffer Overflow • 4. CWE-352 CSRF • 5. CWE-285 Improper Authorization • 6. CWE-807 Reliance on Untrusted Inputs in Security Decision • 7. CWE-22 Path Traversal • 8. CWE-434 File Upload • 9. CWE-78 OS Command Injection • 10. CWE-311 Missing Encryption • 11. CWE-798 Hard-coded Credentials • 12. CWE-805 Incorrect Length Value in Buffer Access • 13. CWE-98 PHP Remote File Inclusion • 14. CWE-129 Uncontrolled Array Index • 15. CWE-754 Improper Check for Exceptional Conditions • 16. CWE-209 Error Message Infoleak • 17. CWE-190 Integer Overflow/Wrap • 18. CWE-131 Incorrect Buffer Size Calculation • 19. CWE-306 Missing Authentication • 20. CWE-494 Download of Code Without Integrity Check • 21. CWE-732 Insecure Permissions • 22. CWE-770 Allocation of Resources Without Limits or Throttling • 23. CWE-601 Open Redirect • 24. CWE-327 Broken Crypto • 25. CWE-362 Race Condition http://cwe.mitre.org/top25

  20. Predicting Popular Vulnerability Classes Generally there seems to be at least a 2-year lag time between first discovery and rampant exploitation. Exception: format strings. • A class may become popular if it has all of these: • Bad consequences • Remote code execution, data compromise, security bypass • Easy to find • Easy to write exploit code • Has had a white paper or two written about it • Has hit very popular software • Past examples: buffer overflows, format strings, SQL injection, PHP file inclusion, XSS, CSRF • Future: • Exposed ActiveX methods, file uploads, …

  21. The Tipping Points

  22. The r0t Method of Vulnerability Analysis ' <script>alert(‘XSS’)</script> Be 14 or 15 years old, with spare time Go to a software repository web site Download a package or try its demo site Do blatantly simple SQL injection and XSS: Move on after 10 minutes Disclose the issue on your blog

  23. Number of CVEs Disclosed Per Month(2004 to 2006) r0t

  24. Grep-and-Gripe:Revenge of the Symlinks Dmitry Those who do not learn from the past are doomed to repeat it. Grep-and-gripe is a valid methodology. Dmitry E. Oboukhov, August 2008 grep -A5 -B5 /tmp/ [PROGRAM] Run against Debian packages

  25. Grep-and-Gripe 2:Attack of the Clones abc.php $language = “english”; … include(“$language.php”); http://example.com/abc.php?language=[RFI]

  26. template=http://example.com/c99 -rwxrwxrwx myprog “../..” or “/full/path” AAA…AAA <SCRIPT> ’ OR 1=1 Any include/require that interpolates $_GET, $_POST, etc. User/Password Filenames Common Commands Get/Send Command File sharing User/Password Body, subject, title, to, from Executables Libraries Configuration Files User/Password id or other numeric field SQL Injection Buffer overflow XSS Remote File Inclusion World-Writable Files Directory Traversal Unforgivable Vulnerabilities:The Lucky 13 (CWE-23) (CWE-79) (CWE-120) (CWE-276, 279) (CWE-98) (CWE-89)

  27. Help http://example/admin/script.cgi tebj lbhe bja pelcgb authenticated=1 Selected from privileged Windows executable Admin functionality Library code with executable extensions Substitution Cipher Form field Cookie User: psychyore Pass: psychyore Crypto Direct Request Hard-coded Default? Length: 0xffffffff Width: 0xffffffff Privilege Escalation Auth bypass Arbitrary length, width, height, size… ln –s /tmp/App.dat /etc/passwd sleep 100000 Integer overflow Hard-coded Pass Log files Temporary files Command-line args Symlink Following The Lucky 13 (Continued) (CWE-327) (CWE-425) (CWE-271) (CWE-472) (CWE-61) (CWE-259) (CWE-190)

  28. 3 7 5 1 Obvious types in critical functionality Variants of common vulnerability types Elimination of most common types Unique types or attacks, extensive expert analysis Incomplete fixes, closely related vectors Limited environments, platforms, configs Rare or novel types and attacks 6 4 2 Typical Vulnerability History of a Product High-profile network servers ActiveX, Joe Schmoe SW Image and Document Processors

  29. Chains: Why Buffer Overflows are Still Here C X B D A Use of Signed Integers for Always-Positive Operations Insufficient Memory Allocation Incorrect Range Check Integer Overflow Heap Overflow height = -65534; width = -65534 A if (height > 64000 || width > 64000) { error("too big!"); } size = height * width; buf = malloc(size); memmove(buf, InputBuf, SZ); Assumption: the range check will prevent an overflow from occurring. B C D

  30. Symbolic Link Following (composition) Symlink Following CWE-41 Symlink Following - CWE 61 Predictability CWE-340 Race Condition CWE-362 Path Equivalence CWE-41 Insecure directory permissions CWE-275

  31. The Four I’s Principle of Vulnerability Information Coordinated disclosure between researcher and vendor frequently wipes these out. • Incomplete • Missing versions, product names • Missing patch information • Inaccurate • Incorrect diagnosis • Blatantly wrong • Inconsistent • Acknowledgement discrepancies • Bug type discrepancies • Varying severities • Incomprehensible • Poor writing • Lack of clear formatting

  32. Four I’s: Some Examples From Spring 2010 CVE-2010-1040 : original Symantec advisory implies that Symantec Endpoint Protection 11.x is affected, but later they say it’s not. CVE-2009-3376 : Red Hat, Ubuntu claim Thunderbird is affected, but this is not in the original Mozilla advisory. Same with several other CVEs. CVE-2010-0009 : vendor accidentally includes CVE-2008-2370 in subject line of advisory. developer of affected software, on oss-security: “I'm half way down this discussion and already I'd prefer to stick needles in my eyes.” Nowhere in the thread is an affected version mentioned. CVE-2010-1188: Red Hat provides this CVE as a link in RHSA-2010:0178, but doesn’t include within their details section. Did they fix this or not? See CVE-2009-4538 for Mandriva. CVE-2010-1028: reliable researcher claims a vulnerability but posts no details and did not provide them to the vendor. Commercial exploit available. CVE-2009-4463: a reliable researcher says “hard-coded passwords” but ICS-CERT performs further research and finds out these are default passwords.

  33. Four I’s: Some Examples From Spring 2010 CVE-2010-1055: original researcher says “RP” parameter is affected, but everyone else says “id” CVE-2010-1060: exploit implies consequence of reading files, but it’s really executing arbitrary programs CVE-2009-4763: software developer removed third-party plugin due to “security issues” but no information on the plugin site; is it the same problem as one that was reported more than a year earlier? CVE-2005-1426: re-discovered and disclosed in 2009; researcher didn’t mention issue had already been disclosed; also said “blog.msb” which is a typo of “blog.mdb” CVE-2008-7254: researcher posts a vulnerability to Exploit-DB in 2010, when it had already been disclosed in 2008 on PacketStorm.

  34. Carving Out Your Niche inApplied Vulnerability Research • Applied vulnerability research is a meritocracy • Your idea might be way ahead of its time • Someone else had the idea before you • … but you’re the one doing something about it • You know less than you think you do • … but eventually, maybe a little more than anyone else • There are many opportunities • Thought leaders will understand the limitations of your breakthrough • Thought leaders are busy • We need more freely-available white papers on “established” techniques that “everybody” knows

  35. Carving Out Your Niche (2) • Stay open to change in strategy and focus • Criticism is an opportunity to learn • Learn to say “no” but be mindful of the consequences • The future tends to change things • Don’t let the perfect get in the way of the good • Understand your work in the context of the larger picture

  36. Carving Out Your Niche (3) • Communication skills are critical • Share what you know – you’ll learn, too • Get out of the office every once in a while • If you don’t fail at least a little bit: • You’re not pushing the envelope enough • You’re not introspective enough

  37. How VDBs Notice Researchers • Quality over quantity • If you post a lot, we notice • If you’re often wrong, you face being ignored • If you post a little but it’s great, we notice • We read disclosure timelines for fun

  38. Conclusion We’ve come a long way, baby We’ve got a long way to go Getting to the root causes – and understanding their solutions - has a greater chance of success than hack-and-patch

More Related