Introduction to Information Security

Slides:



Advertisements
Similar presentations
TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection Tielei Wang 1, Tao Wei 1, Guofei Gu 2, Wei Zou 1 1 Peking.
Advertisements

By Skyler Onken.  Who am I?  What is Fuzzing?  Usual Targets  Techniques  Results  Limitations  Why Fuzz?  “Fuzzing the Web”?  Desired Solution.
Grey Box testing Tor Stålhane. What is Grey Box testing Grey Box testing is testing done with limited knowledge of the internal of the system. Grey Box.
Copyright © Microsoft Corp 2006 Introduction to Security Testing Shawn Hernan Security Program Manager Security Engineering and Communication.
Introduction to InfoSec – Recitation 6 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)
By Brian Vees.  SQL Injection  Username Enumeration  Cross Site Scripting (XSS)  Remote Code Execution  String Formatting Vulnerabilities.
Fuzzing Dan Fleck CS 469: Security Engineering Sources:
Leveraging User Interactions for In-Depth Testing of Web Applications Sean McAllister, Engin Kirda, and Christopher Kruegel RAID ’08 1 Seoyeon Kang November.
Web Proxy Server Anagh Pathak Jesus Cervantes Henry Tjhen Luis Luna.
Leveraging User Interactions for In-Depth Testing of Web Application Sean McAllister Secure System Lab, Technical University Vienna, Austria Engin Kirda.
A Scanner Sparkly Web Application Proxy Editors and Scanners.
MICHAEL EDDINGTON Advanced Fuzzing with Peach 2.
28/08/2015SJF L31 F21SF Software Engineering Foundations ASSUMPTIONS AND TESTING Monica Farrow EM G30 Material available on Vision.
Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.
1 DAN FARRAR SQL ANYWHERE ENGINEERING JUNE 7, 2010 SCHEMA-DRIVEN EXPERIMENT MANAGEMENT DECLARATIVE TESTING WITH “DEXTERITY”
Revolutionizing the Field of Grey-box Attack Surface Testing with Evolutionary Fuzzing Department of Computer Science & Engineering College of Engineering.
Automatic Diagnosis and Response to Memory Corruption Vulnerabilities Authors: Jun Xu, Peng Ning, Chongkyung Kil, Yan Zhai, Chris Bookholt In ACM CCS’05.
Testing and Debugging Version 1.0. All kinds of things can go wrong when you are developing a program. The compiler discovers syntax errors in your code.
TaintScope Presented by: Hector M Lugo-Cordero, MS CAP 6135 April 12, 2011.
Security monitoring boxes Andrew McNab University of Manchester.
Debugging and Profiling With some help from Software Carpentry resources.
© 2006, National Research Council Canada © 2006, IBM Corporation Solving performance issues in OTS-based systems Erik Putrycz Software Engineering Group.
IST 201 Chapter 11 Lecture 2. Ports Used by TCP & UDP Keep track of different types of transmissions crossing the network simultaneously. Combination.
Common System Exploits Tom Chothia Computer Security, Lecture 17.
* Web Servers/Clients * The HTTP Protocol
SE-1021 Software Engineering II
Original slides prepared by Theo Benson
Lab 2: Packet Capture & Traffic Analysis with Wireshark
K. K. Mookhey Network Intelligence India Pvt. Ltd.
Lesson Objectives Aims You should be able to:
Module 30 (Unix/Linux Security Issues II)
The Joy of Breaking Code Testing Logic and Case Selection
CSE 374 Programming Concepts & Tools
Topics Introduction to Repetition Structures
Computer Architecture
COMP280:Introduction to Software Development Week 12, Lecture 34
Introduction to Information Security
Secure Software Development: Theory and Practice
Fuzzing fuzz testing == fuzzing
Evaluating Program Security
White-Box Testing.
Module 3 Building a web app.
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
Computer Architecture “Bomb Lab Hints”
Continuous Performance Engineering
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Completing the tasks for A452 with….
Chapter 3. Basic Dynamic Analysis
Chap 10 Malicious Software.
Topics Introduction to File Input and Output
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
White-Box Testing.
Selected Topics: External Sorting, Join Algorithms, …
Go to =>
CSE 303 Concepts and Tools for Software Development
Python programming exercise
Chap 10 Malicious Software.
Topic 5: Communication and the Internet
Planning and Storyboarding a Web Site
Mutation Testing The Mutants are Coming! Copyright © 2017 – Curt Hill.
Min Heap Update E.g. remove smallest item 1. Pop off top (smallest) 3
CS5123 Software Validation and Quality Assurance
NAVIGATING THE MINEFIELD
Engineering Secure Software
CSE 153 Design of Operating Systems Winter 2019
Topics Introduction to File Input and Output
Lecture 34: Testing II April 24, 2017 Selenium testing script 7/7/2019
Performing Security Auditing In Hardware
Hardware is… Software is…
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Introduction to Information Security Fuzzing

Introduction to fuzzing Fuzzing principles Useful tools and leads Today Introduction to fuzzing Fuzzing principles Useful tools and leads

What is fuzzing? Fuzzing == Looking for vulnerabilities not by reverse engineering the binary / source code, but rather – by playing with the data ובעברית == התססה The basic idea is to throw lots and lots of ‘weird’ input at the target, and see if things break Assuming the target is poorly written, bad data will crash it (Even if it won’t crash, we can usually find a way to know if something bad happened)

Code Coverage Cover the most L.O.C (lines of code) Reach every nook and cranny. Find a way to make internal functions reach unexpected edge cases.

Fuzzing input vectors Files (eg. PDF) SMS TCP/IP SQL over Web Environmental Variables Etc. Software usually has more than one input vector.

Fuzzing principles Target startup (process / network service / VM) Fuzzing takes time We want to automate everything Basic elements in our ‘endless’ loop – Target startup (process / network service / VM) Feeding the input to the target through our vector Monitoring health of the target (black box / white box) Log successful iterations – ‘bad’ test vector (and the way it was generated if relevant)

Generating test vectors Naive solution: iterate over the entire input range But that is impractical for almost all scenarios Two main approaches – Generation – generate input from scratch, following the most minimal set of rules required Mutation – Using a valid starting point (sample), start flipping / moving / inserting bits

Preparing to fuzz a format Read the protocol / file format documentation Observe several test-cases with ghex / wireshark Find important fields – Length fields Checksums Flags Tree-like structures Etc. We may need to make sure some or all of these are ‘correct’ Or, we may want them to be incorrect! 

Basic example - Browser We’ll try to fuzz MS Internet Explorer 6.0 Elements – Target startup + Feeding the target our test vector by running “iexplore %s” %target_file Monitoring the target’s health – by testing if the process is still alive after ‘x’ seconds Any sample that crashed IE will be saved Before moving to the next iteration – kill left-over IE to always start with similar conditions

Another example – Network Daemon Almost any network server will do Elements – Feeding the target our test vector via a TCP connection Monitoring the target’s health – by issuing benign requests constantly If the server has died – log Everything Collect core dump via ssh / remote agent Restart via ssh / remote agent

Faster? Stronger? Until now, we stuck with the most external level of control We want to have more information about the crash And we want to be able to try more test vectors But we don’t have more CPU time…

Faster! Stronger! Install a breakpoint Solution: restart from the middle – Install a breakpoint ‘Freeze’ the memory and state when the breakpoint is triggered Apply test vector Run until function / module / process exit / crash Restart Can be done With a ‘smart’ debugger With an entire VM (Leveraging snapshots) With better instrumentation (white-box testing)

The sad truth Form your data with simple patterns The truth is that finding crashes is not that hard Finding exploitable vulnerabilities is a lot harder Good fuzzing usually requires a lot of tuning and after-processing to filter out the noise After you get a crash, there are some Triage steps that can help you figure out “how exploitable” the bug is – Form your data with simple patterns Inspect registers, stack & heap after crash See if any of your patterns remain (slightly) modify the patterns and repeat

Further reading & Tools Google ‘fuzzing’ / ‘fuzzer’ / ‘python fuzzer’ / ‘protocol fuzzer’ Fuzzing.org is a great resource As are many good papers / slideshows you’ll find via google(especially lectures from BlackHat)

This week’s exercise Fuzzing the ImageMagick image-processing suite Fuzzing Image file formats Mutation based fuzzing (“bit flipping”) Bonus – Smarter fuzzing 

Questions?