How to Break Software Security
Functionality vs. Security
• Functional testing: verify that the app does what it is supposed to do– Apply inputs, verify correct outputs– Funtional testers ask: ‘what is the software supposed to do?’
• Security testing: verify that the app does not do what it is not supposed to do– Apply inputs, verify that no bad things happen– Security testers ask: ‘what is the software not supposed to do?’
• But what is the set of bad things that can cause an application to behave insecurely?
An Example
• Let’s examine two bugs:– A functional bug in which the software fails to do
what it is supposed to do– A security bug in which the software does what it
was supposed to (and a little bit extra!)
The Functional Bug
The Security Vulnerability
What Have We Learned?
• That security bugs:– Are much harder to spot…they often have no
visible (to the human eye) behavior…we need better tools
– Require us to think about side effects and what sensitive data might be exposed
– Require us to “think backwards”…that is, instead of thinking what should happen, we need to think about what shouldn’t happen
Two Models to Guide Our Thinking
• A model of software behavior– Functional testing is simply not designed to find security
flaws
• A model of the environment in which software executes– Many security flaws are caused by environment interaction
– Many security flaws are discovered by analyzing an application’s environment
The Behavior Model(the “eclipse” diagram)
Intended Behavior
Actual Behavior
Traditional Bugs
Most Security Bugs
Application Under Test
kernel
UI
file system
Soft-ware
The Environment Model(the “life preserver” diagram)
Are Hackers Really Motivated to Attack You?
• Thousands of underground hacking tools
• Thousands of hacker sites
• The cold hard truth: Hackers have the advantage– They have to find only one bug…we have to close
them all– They have a lot more time on their hands
Enter their world…
The HtBSS Project
• Goal: develop prescriptive techniques for finding security vulnerabilities in software– Not a “hacker how-to,” we are interested in the bug not the exploit
• Process: study bugs that shipped– What fault caused it?
– What failure symptoms do we look for?
– What testing technique would have found it?
• Outcome: four classes of vulnerabilities/techniques– External dependencies – banana peels in the environment
– Unanticipated user input – magic bullets
– Vulnerable design – bad design habits that bite
– Vulnerable implementation – just plain bugs
External Dependencies
• Software does not exist in isolation– Think about the “life preserver” diagram – Software uses OS resources, runtime libraries, set up files,
data files, …– Programming an application to handle all these things
gracefully is very complicated • Ex: when do you check for a LoadLibrary failure?
– These are rare events, check too often you slow down the app– These are crucial events, check often so you don’t get bitten
• The result: software often fails insecurely because of its dependency on its environment
Unanticipated User Input
• Some inputs are problematic and developers tend to ignore them:– Operating system reserved words– Programming language format strings– Character set boundary values (e.g., extended ascii)– Scripts, code and commands embedded in input fields
• It is important to maintain lists of these and make sure they get applied during testing
Vulnerable Design
• Some good design practices are actually bad for security– Performance and security are at odds– Usability and security are at odds– Cohesion, coupling and many other design practices
can often aid an attacker
• We need to understand how some security vulnerabilities have their roots in design practices
Vulnerable Implementation
• As an industry, we’ve been writing bugs since the dawn of computing and we don’t seem to be slowing down
• What common bugs have security implications?– What do these bugs look like?– How do we find them?
External Dependency Attacks
Dependency Attack Vectors
1. Block access to libraries2. Manipulate registry values3. Force the application to use corrupt files (write
protected, inaccessible, data errors...) and file names4. Replace files that the application reads from, writes to,
creates and executes5. Force the application to operate in stressed
memory/disk space/network availability conditions
The IE content advisor
We get stopped by the parental controls…
…So we block access to the msrating.dll library
Now we can view that site!
Holodeck monitors Update Expert for registry interactions
U.E. Shows a patch applied to the local machine
U.E. reads patch info from the registry...
We target an unapplied patch…
We create a folder with the key “installed”…
U.E. Reads the bogus directory and shows the patch as installed…
User Input Attack Vectors
6. Overflow input buffers
7. Examine all command line switches and
input options
8. Explore escape characters, character sets and
commands
Buffer Overflow Details
Modify file with new data
Executable data6A 00 Push x00
Parameter describing type of message box.
68 B0 FB 11 00Push x0011FBB0
Pointer to the message box caption text.
68 D5 FB 11 00Push x0011FBD5
Pointer to message box body text.
6A 00 Push x00
Handle to a window.
FF 15 88 20 40 00 Call User32.MessageBoxA
Calling the windows message box function. In this case we are
calling indirectly through a pointer.
Now we have an exploit!
Open the file and you are owned!
Design Attack Vectors
9. Try common default and test account names and passwords
10. Expose unprotected test APIs
11. Connect to all ports
12. Fake the source of data
13. Create loop conditions in any application that interprets script, code etc
14. Use alternate routes to accomplish the same task
15. Force the system to reset values
Common AccountsUsername Passwords Systems Affected
Administrator
“”; Admin; admin; administrator; Administrator; root
Windows; Unix and many other platforms and applications
Admin
“”; Admin; admin; administrator; Administrator; root
Windows; Unix and many other platforms and applications
Demo “”; demo; demos Many
Guest “”; Guest; guest Windows
Root “”; root Unix
sa “” Windows SQL server; others
setup setup Unix
sys sys; system; bin Unix
sysadmin sysadmin Unix
test “”; test; Test Common to many applications
user user Windows; Unix
web “”; web Windows; Unix
Implementation Attack Vectors
16. Get between time of check and time of use
17. Create files with the same name as files protected with a higher classification
18. Force all error messages
19. Look for temporary files and screen their contents for sensitive information
Logging in with a bogus account…
… produces this error message
A legit account…
… produces this error message
Summary and Take-Aways
Always Remember…
• Security testing is different and requires us to think differently
• There are testing techniques specifically aimed at security testing and these can and should be part of your software practice
Take Away (1)
• Understand your app’s behavior…think about what should NOT happen!
Intended Behavior
Actual Behavior
Traditional Bugs
Most Security Bugs
Take Away (2)
• Understand your app’s environment…think about where the action is!
kernel
UI
file system
SW Application Under Test
Take Away (3)
• Ask yourself: what is the nightmare scenario for this app (or this customer)!
• Then…test every entry point for that scenario being realized– Its UI– Exposed remote functionality – Its communication paths– The files it reads
Take Away (4)
• Use the attacks, master the tools– Attacks:
• Exploit external dependencies
• Find unanticipated user input
• Expose insecure design
• Determine insecure implementation practices
– Tools• The software Holodeck
• Hex editors, debuggers, port scanners, …
• Never cease your vigilance!
THE END
Questions?
Top Related