Fuzzing101 uvm-reporting-and-mitigation-2011-02-10

  • 635 views
Uploaded on

Fuzzing 101 webinar: unknown vulnerability management - reporting and mitigation

Fuzzing 101 webinar: unknown vulnerability management - reporting and mitigation

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
635
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
19
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. UVM: Reporting and Mitigation Ari Takanen, CTO of Codenomicon Feb 10th, 2011
  • 2.
    • Fuzzing 101:
      • The webcast series for fuzzing industry
      • Vendor neutral presentations on fuzzing technologies and use-cases
      • Includes invited speakers from the industry
    • Codenomicon:
      • Fuzzing research since 1996
      • 2001, Spinoff from University of Oulu
      • 50-100% annual growth in number of customers and revenues in fuzzing industry
    About Fuzzing 101 and Codenomicon
  • 3. About Ari Takanen
    • The Past: Researcher and Lecturer
      • 1998-2002
      • University of Oulu
      • OUSPG/PROTOS research group
      • Software Quality related lectures
    • The Present: Entrepreneur and Evangelist
      • 2001-today
      • CTO of Codenomicon
      • Evangelist: 10 conference talks every year
      • Author of two books:
        • VoIP Security
        • Fuzzing
  • 4. Agenda
    • Introduction to UVM:
    • UVM Overview and Phases
      • Attack Surface Analysis
      • Testing = Fuzzing
      • Reporting and Mitigation
    • Vulnerability Reporting
      • Process and best practises
    • Mitigating Unknown Threats
      • Fuzzing results with security devices
      • Challenges
  • 5. Unknown Vulnerability Management Overview and Phases The Only Means of Catching Zero-Day Vulnerabilities!
  • 6. Challenges with Vulnerability Management
    • Detect Vulnerabilities as they are found
      • Not as they emerge, they are in the hiding already
    • Most costs are in patch deployment
      • Crisis management, each update needs immediate attention
      • Ad-hoc deployment is prone to errors
      • Maintenance downtime can be expensive
      • New patches emerge several times a week
      • No time to test the patch
  • 7. Zero-Day Vulnerability
    • The biggest threat to IT systems everywhere is a Zero-Day vulnerability
      • No patches or updates available
      • No security defenses
    • Software is released with vulnerabilities
    • In the past, those problems were found and disclosed by the security community = hackers
  • 8. Some Helpful Definitions
    • Vulnerability – a weakness in software, a bug
    • Threat/Attack – exploit/worm/virus against a specific vulnerability
    • Protocol Modeling – Technique for explaining interface message sequences and message structures
    • Fuzzing – process and technique for security testing
    • Anomaly – abnormal or unexpected input
    • Failure – crash, busy-loop, memory corruption, or other indication of a bug in software
  • 9. The Challenge: Unknown Vulnerabilities Are Everywhere
  • 10. Codenomicon Labs Test Results http://www.codenomicon.com/labs/results
  • 11. Unknown Vulnerability Management (UVM)
    • Another name:
    • Zero-Day Vulnerability Management
    • Process of:
      • Detecting attack vectors
      • Finding zero-day vulnerabilities
      • Building defenses
      • Performing patch verification
      • Deployment in one big security push
  • 12. UVM Phases
  • 13. Phase 1: Attack Surface Analysis
    • Tools:
      • Port scanners
      • Resource scanners
      • Network analyzers
    • Codenomicon Network Analyzer identifies what needs to be tested within your network
      • Record traffic at multiple points in your network
      • Automatically visualize the network
      • You can drill up and down from looking at high-level visualizations to inspecting the corresponding packet data
      • Real time analysis
      • Reveal hidden interfaces and possible exploits.
  • 14. Phase 2: Test
    • Fuzzing means crash-testing
    • Discover both known and previously unknown vulnerabilities with unparalleled efficiency.
    • Specification-based tools for over 200 protocols
      • Tools contain all the possible protocol messages and structures
      • Genuinely interoperate with the tested system exposing vulnerabilities even in deeper protocol layers
    • General purpose fuzzers
      • Defensics XML Fuzzer can test all XML applications.
      • The Traffic Capture Fuzzer uses real traffic
      • Generic File Format Fuzzer tests all file formats.
  • 15. Phase 3: Report
    • Codenomicon test suites generate different reports for different audiences
    • Management reports provide an high-level overview of the test execution
    • Log files and spreadsheets help you to identify troublesome tests and to minimize false negatives
    • Individual tests by augmenting the already extensive test case documentation with PCAP traffic recordings
    • Remediation Packages can be send to third parties for automated reproduction.
  • 16. Phase 4: Mitigate
    • Mitigation tools quickly and easily reproduce vulnerabilities, perform regression testing and verify patches
    • The tools automatically generate reports, which contain risk assessment and CWE values for the found vulnerabilities and direct links to the test suites that triggered the vulnerabilities
    • Identification of the test cases that triggered the vulnerability is critical
    • The test case documentation can be used to create tailored IDS rules to block possible zero-day attacks.
  • 17. Vulnerability Reporting Experiences with Bug Reporting
  • 18. Security View: Window of Vulnerability SW - under vulnerability analysis SW - after product release SW - after the vulnerability process TIME BUG APPEARS RELEASE BUG FOUND VULN FOUND VULN REPORT VULN FIX AVAIL. PATCH RELEASE ADVISORY RELEASE PATCH INSTALL Zero Exposure Limited Exposure Public Exposure
  • 19. Vulnerability Reporting Process
  • 20. Finding and Reporting Problems
    • Motivations in finding bugs in third party code:
      • Protecting your own system
      • Security research in some other component
    • Note that the above is one of the most important things to analyze!
  • 21. How and To Who Do You Report?
    • To whom do you report the findings
      • First ask from your support contact (no details yet)
      • Vendor security contact (vendor CERT, PSIRT, …)
      • Mailing lists, support forums, …
      • Third party such as CERT
      • Remember confidentiality, encryption (PGP)
  • 22. A Bug Report
    • What to write to a bug/incident report?
      • Note that first purpose is reproduction
    • Selected observations:
      • Use bug report templates
      • Write complete but compact bug reports
      • Be prepared that the report might leak or become public
      • Clearly indicate what is confidential information
      • Consider carefully if you want to write demonstration exploits (but be prepared for it)
      • Never propose a specific fix (in worst case it will just be blindly adopted)
  • 23. Share Test Environment Details
    • Bug reports should clearly indicate the test environment that was used
      • Exact software versions
      • Operating system versions
      • Network architecture (or virtual setup)
    • If possible, give the vendor the exact setup
      • This is easiest with virtual setups
  • 24. Defensics Includes Test Setup Details
  • 25. Collaboration and Document Sharing
    • If your test tools produce reports, share those with the vendor
    • In many cases, it might be best to actually share the fuzzing tool that you used to find the issue
    • Collaboration platforms and IM will make communication much easier
      • Codenomicon can provide the platform for you
  • 26. Best Method for Reproducing with Defensics
  • 27. But Often You See This…
  • 28. PCAPs as Test Documentation
    • PCAPs are quick method for reproduction
    • Most fuzzing tools can save tests as PCAP, and re-execute those PCAPs
      • E.g. Defensics Traffic Capture Fuzzer reproduces and tests around most PCAPs, wherever they come from
    • The biggest challenge with PCAPs is that they are difficult to maintain
    • When specification changes, the efficiency of PCAP-based test will quickly degenerate
  • 29. Risk Assessment from Bug Identification
  • 30. Different Types of Reports
    • Fuzzing tools will produce different reports for different audiences
  • 31. Remediation Package
    • Defensics Remediation Package collects all required data
    • Typical difficulties with reproduction:
      • If only the reported test is reproduced, the next test case can still crash the system
  • 32. How to Protect Yourself
    • It is good to involve third party in the process:
      • Codenomicon (or another security company)
      • Internal CERT
      • External CERT
    • Remember that legal departments will almost always get involved
    • If something becomes difficult, let the professionals in the bug reporting process handle it
    • Remember: Almost always the biggest failure is in personal communications
  • 33. What to Expect
    • Timeline:
      • From reporting to first acknowledgement should be really really fast (reporters do not have patience)
      • From acknowledgement to first threat analysis: “we do not think this is critical”
      • From start of fixing to ready patch, this is often the longest wait, up to months or few years
    • Quality of the patch:
      • Quick and dirty patches are always suspicious
      • When vendor is given more time, the quality is often better, and the patch does not break any valid functionality
    • What to do while waiting?
  • 34. Challenges in adopting Fuzzing results with security devices Mitigating Unknown Threats
  • 35. Challenges with IDS
    • Although all fuzz test cases are easy to convert to IDS rules, those IDS rules are quite easy to circumvent
      • “ Advanced Evasion Techniques” ;-)
    • Traditionally IDS rules detect individual attack exploits, with the same problem that variants of the same attack can easily pass through
  • 36. How to Build Good IDS Rules
    • Be generic in the rules, detect string lengths instead of string contents, etc.
    • Extensively test the rules with both legal (valid case) traffic and with systematic fuzzing in the vulnerable protocol element
    • Note that not all fuzz tests need to be blocked by IDS -> Too complex, does not work
  • 37. Patch Verification Using Fuzzers
    • Use the same tool and same setup immediately when you receive the first patch candidate
    • Also relevant to vendor, before even providing the patch candidate to the reporter
      • Note that it is really annoying to reporters when the patch is bad quality, and they might just give up if they do not have motivation to continue
    • Some critical systems might already include the patch you are testing, so bugs in the patch are also critical, and have to be handled in such way
  • 38. Conclusions
    • Most challenges in bug reporting are not in technology, but communication
      • Codenomicon provides collaboration platform to assist
    • Main purpose of bug reports in reproduction of the found flaws
      • Codenomicon Remediation Package!!
    • Easiest reproduction of bugs is always with exactly the same test setup, and exactly the same tool
      • Codenomicon provides free access to our tools for reproduction
    • Fuzz test cases cannot all be blocked by IDS
      • Codenomicon provides extensive documentation of every test case
  • 39. Summary of UVM
    • Security is not about security mechanisms
    • For full security analysis, you should study:
      • Threats
      • Attacks
      • Vulnerabilities
      • Architectures
      • Countermeasures
    • Unknown Vulnerability Management is about identification and elimination of zero-day vulnerabilities
    • Security is a process not a product!
  • 40. Our Book On Fuzzing!
    • http://www.fuzz-test.com/book/
    • Takanen, DeMott and Miller: “Fuzzing for Software Security Testing and Quality Assurance”
    • Aimed at the general public, you do not need to be a security specialist to read this book
    • Purpose of the book is to teach next-gen testing approaches to:
      • Software practitioners
      • Security engineers
      • Academics
  • 41. More News from Codenomicon
    • Facebook:
      • Become fan of Codenomicon and Fuzzing
    • Twitter:
      • CodenomiconLTD
    • Codenomicon Website:
      • Newsletter every second month
    • Customer portal
      • The Backstage! Contact us for access!
  • 42. PROACTIVE SECURITY AND ROBUSTNESS SOLUTIONS THANK YOU – QUESTIONS? “ Thrill to the excitement of the chase! Stalk bugs with care, methodology, and reason. Build traps for them. .... Testers! Break that software (as you must) and drive it to the ultimate - but don’t enjoy the programmer’s pain.” [from Boris Beizer]