Whittaker How To Break Software Security - SoftTest Ireland

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?