What is vulnerability analysis

1. Vulnerability analysis - Vulnerability analysis involves discovering a subset of
the input space with which a malicious user can exploit logic errors in an
application to drive it into an insecure state.
http://doi.ieeecomputersociety.org
What is Vulnerability Analysis?
copyright c March 9 2010 McCabe
Technology

2. Potential vulnerabilities – locations within a program that contain known
weaknesses
- Example: The usage of APIs known to be susceptible to buffer
overflows
- Potential vulnerabilities may or may not be exploitable.
Exploitable vulnerabilities - exist when a potentially vulnerable program
location...
- Is dependent on or able to be influenced by user supplied input
- Is reachable on the program control flow graph at runtime
Potential vs. Exploitable Vulnerabilities
copyright c March 9 2010 McCabe
Technology

3. Paths Connecting Attack Surface & Target
Attack Surface Entry Libraries
Attack Surface Target Libraries
Subtrees/Paths
RECV()
STRCPY()
copyright c March 9 2010 McCabe
Technology

4. Advanced Exclude: Select Load Option
Use the Advanced Exclude Menu to load a Class file that includes all the
banned functions from Microsoft & OWASPS. This file user editable.
Additional modules and/or library functions can be added.
copyright c March 9 2010 McCabe
Technology

5. Preloaded User Definable Classes for Security
• List of Banned APIs from the Microsoft Secure Software
Development Lifecycle & from OWASP
• Attack Surface APIs and Libraries (entry points)
• Vulnerable APIs and Libraries (exploitable targets)
• Individual Attack Surface Entry Point
• Individual Attack Surface Target Point
copyright c March 9 2010 McCabe
Technology

6. Class Editor: User Definable Class Libraries
Preloaded with Microsoft & OWASP’s Banned Functions. User has the
ability to add or delete Attack Surface & Target parameters
copyright c March 9 2010 McCabe
Technology

7. Advanced Exclude: Narrow Scope
Use the Advanced Exclude Option to understand entry points into the
system, narrow the scope of analysis, and to view attack space in
context of the rest of the system
copyright c March 9 2010 McCabe
Technology

8. Attack Modeling
copyright c March 9 2010 McCabe
Technology

9. Even if you can make any code you write secure, you're still at the mercy of all those libraries. The C
language is notorious for creating software with buffer overflows because of library calls. Standard C
functions that do no range checking of character string inputs are vulnerable to function algorithm
attacks. These functions include scanf(), gets(), getwd(), [vg]scanf, realpath, [v]sprintf(), sprintf(),
vsprintf(), strcpy(), and strcat().
Gets() is an excellent example. This function performs the common task of reading user input, but it
keeps accepting the input until it sees a command ending the line or closing the file. That means that
gets() can always be used to overflow any size buffer—no matter how large. If you use fgets() instead,
you can set a parameter to limit the number of characters it will accept, thus preventing buffer
overflows.
Strcpy() is similar in that it copies a string from a source to a buffer (again, it doesn’t limit the size of
the string). There are safe ways to use strcpy(), such as adding a check; however, it’s often simpler to
use strncpy(dst, src, dst_size – 1), which lets you specify a maximum number of characters. This is a
particularly good alternative for many uses because it doesn’t throw an error when the input is too
big—it simply terminates. If you need to generate an error when a specified string length is exceeded,
you can use strcpy() along with a check, such as:
if(strln(src) >= dst_size)...
Strcat() concatenates a string onto the end of a buffer. Strncat() is a safer alternative, but it does
require that you monitor the room left in the buffer.
Libraries: Major challenge for developers who need to
produce secure applications
copyright c March 9 2010 McCabe
Technology

10. A software system’s attack surface is the subset of resources that an attacker
can use to attack the system.
The classic attack surface definition assumes all entry points into the
software system; this can include certain Windows registry keys, open
handles to windowed objects, or command-line parameters
It is important to differentiate the classic
definition of attack surface from the
useable attack surface. ...
What is the Attack Surface?
copyright c March 9 2010 McCabe
Technology

11. Use the tools to extract subgraph of overall CFG that includes all nodes on
a path between input acceptance node and target nodes (potentially
vulnerability nodes containing things like strcpy calls)
Standard C functions that do no range checking of character string inputs
are vulnerable to function algorithm attacks. These functions include
scanf(), gets(), sprintf(), vsprintf(), strcpy(), and strcat()
Other possible vulnerable procedures include: printf, fprintf, snprintf,
vsnprintf.
This list names some of the worst offenders. Also, even though there are
safer alternatives for most of these functions, those alternatives aren’t
absolutely safe. You can still get into trouble using them—often with
unterminated strings or by specifying the wrong buffer size
Attack Map Modeling using McCabe IQ Battlemap
copyright c March 9 2010 McCabe
Technology

12. It is the portion of the attack surface that an attacker could use to crash the
software, access sensitive information or gain access to the host machine
remotely. It is these particular areas of code that we are interested in
exercising as they pose the highest degree of risk. It is also independent of
configuration, and specification, as we are testing the connected code to a
particular input source.
What is Useable Attack Surface?
Parsing & validation
logic on path between
recv and strcpy
copyright c March 9 2010 McCabe
Technology

13. Attack Surface Analysis & Reduction
Microsoft Secure
Software Development
Series
Best Practices -The
Security Development
Lifecycle
SDL: A Process for
Developing
Demonstrably More
Secure Software
By Michael Howard
and Steve Lipner
http://www.microsoft.com/security/sdl/about/process.aspx
copyright c March 9 2010 McCabe
Technology

14. Viewing Attack space in relation to rest of code
copyright c March 9 2010 McCabe
Technology

15. In order to determine if the vulnerability is an exploitable threat, one must
prove that it is reachable on the execution path given some user supplied
input. The exploitability is dependent upon the control flow logic on the paths
between the external input and targeted exploitable routines. The diagram
below illustrates this idea, in this case showing control flow inclusive of packet
acceptance and the basic block where a vulnerable API function is used.
To narrow the scope of exploitable code, we consider its attack trees. …
Exploitability Implies Reachability
Parsing &
validation logic on
path between
recv and strcpy
copyright c March 9 2010 McCabe
Technology

16. What is An Attack Tree?
An Attack Tree is a set of paths connecting a specific attack surface and
specific attack target.
Attack Tree is also known as “And/Or Trees”. The history of the Attack Tree
can be traced back to the Fault Tree developed by Bell Labs and the U.S. Air
Force in 1960s. The software related application of Fault Tree is also known
as Threat Tree, which is an excellent tool for modeling a particular attack
scenario.
McCabe IQ uses the McCabe Design Complexity Metrics, visual subtree
graphs, subtree test conditions and code coverage as Attack Trees. McCabe
Design Complexity metrics are typically calculated rooted at the input node
of the attack surface.
copyright c March 9 2010 McCabe
Technology

17. Applying McCabe Design Complexity to Attack Trees
Definition: module design complexity of a module is a measure of the decision
structure which controls the invocation of the module’s immediate subordinate
modules. It is a quantification of the testing effort of a module as it calls its
subordinates.
The module design complexity is calculated as the cyclomatic complexity of the
reduced graph. Reduction is completed by removing decisions and nodes that do
not impact the calling control of the module over its subordinates.
McCabe Design complexity metrics should be calculated by rooting at the input
acceptance node. The McCabe Design complexity metrics and subtrees can be
used to understand and test Attack Trees within the source code.
copyright c March 9 2010 McCabe
Technology

18. How do you assess complexity & test effort
for component design?
S1 = S0 - n + 1= 12 - 7 + 1 = 6
By measuring the integration paths in its
modules
Integration complexity S1
copyright c March 9 2010 McCabe
Technology

19. McCabe System Design Complexity Attack Tree
copyright c March 9 2010 McCabe
Technology