Bug Hunting and Exploit Development 1: Finding Flaws Using Static Analysis
Channel: Z. Cliffe Schreuders
Date: 2015-06-22

This video is part of the computer/information/cyber security and ethical hacking lecture series; by Z. Cliffe Schreuders at Leeds Beckett University. Laboratory work sheets, slides, and other open educational resources are available at http://z.cliffe.schreuders.org. 

The slides themselves are creative commons licensed CC-BY-SA, and images used are licensed as individually attributed.

Topics covered in this lecture include:
Bug hunting
Mindful design and testing are important to avoid vulnerabilities from being introduced
After software has been created (and during the development process), programs can be tested with or without access to the source code to look for vulnerabilities
After a vulnerability is discovered, you can produce a proof of concept / exploit, or develop a fix the problem
(FOSS vs proprietory software)
Zero days
A zero day security vulnerability is a new security problem that has been discovered
If a security researcher can find a flaw that the software authors do not know about, this can have serious security ramifications
Such as worms or targeted attacks
If they then weaponise the attack, and create an exploit to attack, this is known as a zero-day exploit, if there is currently no fix available to defend against the attack.
Vulnerability disclosure
The way in which vulnerabilities should be disclosed in a topic of heated debate
Responsible/coordinated disclosure involves first contacting the affected vendors and giving them time to fix the issue, usually with a time limit before going public
Full disclosure involves going public with all the technical details of a vulnerability without first giving the vendor an opportunity to fix
Our vulnerability disclosure policy
1) Complete the disclosure template document, by replacing the yellow fields
2) Send it to security representative(s) within the company
3) Apply for a CVE
4) After (not before) 15 days after step 2, report to CERT/CC
5) After CERT releases the details (typically 45 days later), you may (at your discretion) discuss the vulnerability publicly, or post other details and code, such as via a blog post or by contributing code to MSF
Further guidance is provided on the module page
If you would like to follow a different vulnerability disclosure method, then please discuss this with your tutor beforehand
Finding Bugs
When you have access to the source code:
Manual code review
Static analysis: software to automatically analyse code
If you do or do not have access to the source code:
Reverse engineering: as above
Binary static analysis
Fuzzing to do “random testing”
Static analysis
Static analysis can aid code review, to automatically analyse code to detect common programming mistakes
Great for detecting errors that can be automatically detected, such as:
Buffer overflows, memory errors, unsafe functions
Some tools have a high false positive rate
They will not detect everything!
Static analysis tools
There are many static analysis tools available, some FOSS C/C++ tools include
CppCheck (aims for 0 false positives)
Flawfinder
RATS
VCG (VisualCodeGrepper)
Oink (includes Cqual++)
Lots of other tools:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Good to combine: they provide different coverage


Static analysis tools
Coverity Scan Static Analysis, free for FOSS projects