1

© 2004 Cigital

Exploiting Software:How to Break Code

Gary McGraw, Ph.D.CTO, Cigital

http://www.cigital.com

© 2004 Cigital

ν Software QualityManagement solutions

ν Security

ν Reliability

ν Performance

ν Fortune 1000 clients

ν Cigital Labs

2

© 2004 Cigital

Pop quiz

ν What do wireless devices, cell phones, PDAs,browsers, operating systems, servers, personalcomputers, public key infrastructure systems, andfirewalls have in common?

Software

© 2004 Cigital

So what’s the problem?

3

© 2004 Cigital

Commercial security is reactiveν Defend the perimeter with a

firewall

ν To keep stuff out

ν Over-rely on crypto

ν “We use SSL”

ν “Review” products whenthey’re done

ν Why your code is bad

ν Promulgate “penetrate andpatch”

ν Disallow advancedtechnologies

ν Extensible systems (Javaand .NET) are dangerous

The “fat guy with keys” doesnot really understand softwaredevelopment.

© 2004 Cigital

Builders versus operatorsν Most security people are

operations people

ν Network administrators

ν Firewall rulesmanipulators

ν COTS productsglommers

ν These people needtraining

ν Security means differentthings to different people

ν Most builders are notsecurity people

ν Software developmentremains a black art

ν How well are we doingteaching students toengineer code?

ν Emergent properties likesecurity are hard forbuilders to grok

ν These people needacademic education

4

© 2004 Cigital

Making software behave is hardν Can you test in quality?ν How do you find (adaptive) bugs in code?ν What about bad guys doing evil on purpose?

ν What’s the difference between security testing andfunctional testing?

ν How can you teach security design?ν How can you codify non-functional, emergent

requirements like security?ν Can you measure security?

© 2004 Cigital

Attaining software security is even harder

The Trinity of Trouble

ν Connectivity

ν The Internet is everywhereand most software is on it

ν Complexity

ν Networked, distributed,mobile code is hard

ν Extensibility

ν Systems evolve inunexpected ways and arechanged on the fly

This simple interface……is this complex program.NET

The network is the computer.

5

© 2004 Cigital

Software complexity growth

Windows Complexity

05

1015202530354045

Win3.1

(1990)

WinNT

(1995)

Win 95(1997)

NT 4.0(1998)

Win 98(1999)

NT 5.0(2000)

Win2K

(2001)

XP(2002)

Mill

ion

s o

f L

ines

© 2004 Cigital

Software vulnerability growth

6

© 2004 Cigital

Science pleaseν Basic understanding of complexity and its impact on

security problems is sorely neededν Do the LOC and vulnerability graphs correlate?

ν Dan Geer’s power law prediction

ν What are software security problems really like?ν How common are basic categories?ν How can we teach students something that now

takes years of fieldwork to merely intuitivelygrasp?

© 2004 Cigital

Who is the bad guy?

ν Hackers

ν “Full disclosure” zealots

ν “Script kiddies”

ν Criminals

ν Lone guns or organized

ν Malicious insiders

ν Compiler wielders

ν Business competition

ν Police, press, terrorists, intelligence agencies

7

© 2004 Cigital

Modern security is about managing risksν There is no such thing as

100% secure

ν Must make tradeoffs

ν Should be businessdecisions

ν Proactive security is aboutbuilding things right

ν Design for security

ν Security analysis

ν Secure coding practiceν Security testing

ν It’s all about the software

ν Most security problemsare caused by softwarebugs and flaws

ν We must build securesoftware

Source: IDC and CERT/CC

Vulnerabilitygrowth outstrippingsecurity spending

0%

100%

200%

300%

400%

500%

1998 1999 2000 2001 2002 2003

Security Investment

Vulnerabilities

© 2004 Cigital

Know your enemy: How stuffbreaks

8

© 2004 Cigital

Security problems are complicatedIMPLEMENTATION BUGS

ν Buffer overflowν String formatν One-stage attacks

ν Race conditionsν TOCTOU (time of check to

time of use)ν Unsafe environment variablesν Unsafe system calls

ν System()ν Untrusted input problems

ARCHITECTURAL FLAWSν Misuse of cryptographyν Compartmentalization

problems in designν Privileged block protection

failure (DoPrivilege())ν Catastrophic security failure

(fragility)ν Type safety confusion errorν Insecure auditingν Broken or illogical access

control (RBAC over tiers)ν Method over-riding problems

(subclass issues)ν Signing too much code

© 2004 Cigital

BUG: The dreaded buffer overflowν Overwriting the bounds of

data objectsν Allocate some bytes, but the

language doesn’t care if youtry to use moreν char x[12]; x[12] = ‘\0’;

ν Why was this done?Efficiency!

ν Two main flavors of buffersν Heap allocated buffersν Stack allocated buffersν Smashing the stack is

the most common attack

ν The most pervasive securityproblem today in terms ofreported bugs

0

5

10

15

20

25

30

1988

1989

1990

1991

1992

1993

1994

1995

1996

1997

1998

1999

Security Problems (CERT)

CERT Alerts

Buffer overflows

9

© 2004 Cigital

Pervasive C problems lead to BUGSvoid main() {

char buf[1024];gets(buf);

}

ν How not to get inputν Attacker can

send an infinitestring!

ν Chapter 7 of K&R(page 164)

ν Calls to watch out for

ν Hundreds of such callsν Use static analysis to find these

problemsν ITS4, SourceScope

ν Careful code review isnecessary

Instead of:Use:gets(buf)fgets(buf, size, stdin)strcpy(dst, src)strncpy(dst, src, n)strcat(dst, src)strncat(dst, src, n)sprintf(buf, fmt, a1,…)snprintf(buf, fmt, a1, n1,…)(where available)*scanf(…)Your own parsing

© 2004 Cigital

FLAW: Architectural problems with Javaν Java’s classloading

architecture broken

ν Separate instantiate classfrom manage name spaces

ν Every release hadproblems

ν March 96: JDK 1.0

ν March 97: JDK 1.0.7

ν July 98: JDK 1.2

ν What is “Java” anyway? (andwhat is .NET?!)

J2EE

J2SE

JavaCard

J2ME

MicroChai

TINI

Moreresources

10

© 2004 Cigital

Attackers do not distinguish bugs and flawsν Both bugs and flaws lead to

vulnerabilities that can beexploited

ν Attackers write code tobreak your code

ν The standard attacker’stoolkit has lots of stuffν Disassemblers and

decompilersν Control flow and

coverage toolsν APISPY32ν Breakpoint setters and

monitorsν Buffer overflowν Shell codeν Rootkits

© 2004 Cigital

Attacker’s toolkit: dissasemblers and decompilers

ν Source code is not a necessity for software exploit

ν Binary is just as easy to understand as source code

ν Disassemblers and decompilers are essential tools

ν Reverse engineering is common and must beunderstood (not outlawed)

ν IDA allows plugins to be created

ν Use bulk auditing

11

© 2004 Cigital

Attacker’s toolkit: control flow and coverage

ν Tracing input as it flows throughsoftware is an excellent method

ν Exploiting differences betweenversions is also common

ν Code coverage tools help youknow where you have gotten in aprogram

ν dyninstAPI (Maryland)

ν Figure out how to get toparticular system calls

ν Look for data in shared buffers

© 2004 Cigital

Attacker’s toolkit: APISPY32ν Look for broken system

calls (at all levels in code)

ν lstrcpy() makes a greatexample

ν On win32 systems, useAPISPY to determine whichAPIs are being used by atarget program

ν Interposition attacks are agreat thing to think about atthis level

12

© 2004 Cigital

Attacker’s toolkit: breakpoints

ν Breakpoints are central to debuggers

ν Use interrupt 3 on x86 architectures

ν Mark entire blocks for access

ν Single step at breakpoint (also as in debugging)

ν Check out “The PIT” http://www.hbgary.com

© 2004 Cigital

Attacker’s toolkit: the buffer overflowν Find targets with static analysisν Change program control flow

ν Heap attacksν Stack smashingν Trampolining

ν Particular examplesν Overflow binary resource

files (used againstNetscape)

ν Overflow variables andtags (Yamaha MidiPlug)

ν MIME conversion fun(Sendmail)

ν HTTP cookies (apache)

ν Trampolining past a canary

Local Variable: Buffer B

Local Variable: Pointer A

Local Variable: Buffer A

Function arguments

Return Address

Canary Value

Frame Pointer

13

© 2004 Cigital

Attacker’s toolkit: shell code and other payloads

ν Common payloads in buffer overflowattacks

ν Size matters (small is critical)

ν Avoid zeros

ν XOR protection (also simple crypto)

ν Payloads for

ν X86 (win32)

ν RISC (MIPS and sparc)

ν Multiplatform payloads

© 2004 Cigital

Attacker’s toolkit: rootkits

ν The apex of software exploit…complete control ofthe machine

ν Live in the kernel

ν XP kernel rootkit in the book

ν See http://www.rootkit.com

ν Get into the microchips (hardware viruses)

ν Hide files and directories by controlling access toprocess tables

ν Provide control and access over the network

14

© 2004 Cigital

Attacker’s toolkit: other miscellaneous toolsν Debuggers (user-mode)

ν Kernel debuggers

ν SoftIce

ν Fault injection tools

ν Failure simulation tool

ν Hailstorm

ν Holodeckν Boron tagging

ν The “depends” tool

ν Grammar rewriters

© 2004 Cigital

How attacks unfoldν Attacking a system is a

process of discovery andexplorationν Qualify target (focus on

input points)ν Determine what

transactions the inputpoints allow

ν Apply relevant attackpatterns

ν Cycle throughobservation loop

ν Find vulnerabilityν Build an exploit

The standard processν Scan networkν Build a network mapν Pick target systemν Identify OS stackν Port scanν Determine target

componentsν Choose attack patternsν Leverage environment

faultsν Use indirectionν Plant backdoor

15

© 2004 Cigital

Knowledge: 48 Attack Patternsν Make the Client Invisibleν Target Programs That Write to Privileged OS Resourcesν Use a User-Supplied Configuration File to Run

Commands That Elevate Privilegeν Make Use of Configuration File Search Pathsν Direct Access to Executable Filesν Embedding Scripts within Scriptsν Leverage Executable Code in Nonexecutable Filesν Argument Injectionν Command Delimitersν Multiple Parsers and Double Escapesν User-Supplied Variable Passed to File System Callsν Postfix NULL Terminatorν Postfix, Null Terminate, and Backslashν Relative Path Traversalν Client-Controlled Environment Variablesν User-Supplied Global Variables (DEBUG=1, PHP

Globals, and So Forth)ν Session ID, Resource ID, and Blind Trustν Analog In-Band Switching Signals (aka “Blue Boxing”)ν Attack Pattern Fragment: Manipulating Terminal Devicesν Simple Script Injectionν Embedding Script in Nonscript Elementsν XSS in HTTP Headersν HTTP Query Strings

ν User-Controlled Filenameν Passing Local Filenames to Functions That Expect a

URLν Meta-characters in E-mail Headerν File System Function Injection, Content Basedν Client-side Injection, Buffer Overflowν Cause Web Server Misclassificationν Alternate Encoding the Leading Ghost Charactersν Using Slashes in Alternate Encodingν Using Escaped Slashes in Alternate Encodingν Unicode Encodingν UTF-8 Encodingν URL Encodingν Alternative IP Addressesν Slashes and URL Encoding Combinedν Web Logsν Overflow Binary Resource Fileν Overflow Variables and Tagsν Overflow Symbolic Linksν MIME Conversionν HTTP Cookiesν Filter Failure through Buffer Overflowν Buffer Overflow with Environment Variablesν Buffer Overflow in an API Callν Buffer Overflow in Local Command-Line Utilitiesν Parameter Expansionν String Format Overflow in syslog()

© 2004 Cigital

Attack pattern 1:Make the client invisible

ν Remove the client from thecommunications loop andtalk directly to the server

ν Leverage incorrect trustmodel (never trust theclient)

ν Example: hacking browsersthat lie

16

© 2004 Cigital

Attack pattern 2:Command delimiters

ν Use off-nominalcharacters to stringtogether multiplecommands

ν Example: shellcommand injection withdelimiters

<input type=hidden name=filebasevalue="bleh; [command]”>

cat data_log_; rm -rf /; cattemp.dat

exec( “cat data_log_ .dat”);

; rm –rf /; cat temp

© 2004 Cigital

Attack pattern 3:Cross site scriptingν XSS

1. Attacker sends activecontent to a victim

2. Content invokes a scripton the vulnerable website

3. Later invoked by a webbrowser hitting the website

4. The script runs5. Attacker allowed access

ν Examplesν Javascript injectionν Inject in non-script

elementsν HTTP headersν Query strings

17

© 2004 Cigital

Breaking stuff is importantν Learning how to think like

an attacker is essential

ν Do not shy away fromteaching attacks

ν Engineers learn fromstories of failure

ν Attacking group projects canbe the most fun part of acourse

ν Fun is good! Softwareengineering is too boring!

© 2004 Cigital

Great, now what do we

do about this?

18

© 2004 Cigital

Software security critical lessons

ν Software security is more than a set of securityfunctions

ν Not magic crypto fairy dust

ν Not silver-bullet security mechanisms

ν Not application of very simple tools

ν Non-functional aspects of design are essential

ν Security is an emergent property of the entiresystem (just like quality)

ν To end up with secure software, deep integrationwith the SDLC is necessary

© 2004 Cigital

Towards a solution

ν Integrate software security best practices intoEVERYTHING you build

ν Understand and follow guiding security principles

ν If you write code, learn about software security!

19

© 2004 Cigital

Ten guiding principles for secure design1. Secure the weakest link

2. Practice defense in depth

3. Fail securely

4. Follow the principle of leastprivilege

5. Compartmentalize

6. Keep it simple

7. Promote privacy

8. Remember that hidingsecrets is hard

9. Be reluctant to trust

10. Use your communityresources

© 2004 Cigital

The antidote: Software security in the SDLC

Requirementsand use cases

Design Test plans Code Testresults

Fieldfeedback

Abusecases

Securityrequirements

Externalreview

Riskanalysis

Risk-basedsecurity tests

Securitybreaks

Staticanalysis(tools)

Riskanalysis

Penetrationtesting

20

© 2004 Cigital

Best practices repriseν These best practices should

be applied throughout thelifecycle

ν Tendency is to “start right”(penetration testing) anddeclare victory

ν Not cost effective

ν Hard to fix problems

ν Start as far to the left aspossible

ν Abuse cases

ν Security requirementsanalysis

ν Architectural risk analysis

ν Risk analysis at design

ν External review

ν Test planning based onrisks

ν Security testing (malicioustests)

ν Code review with staticanalysis tools

© 2004 Cigital

Where to learn more

21

© 2004 Cigital

IEEE Security & Privacy Magazine

ν New Department on SoftwareSecurity best practices called“Building Security In”

http://http://www.computer.orgwww.computer.org/security/security

© 2004 Cigital

Pointersν Cigital’s Software Security Group invents

and practices Software Quality Management

ν http://www.cigital.com/presentations/sploit04

ν Use Exploiting Software and BuildingSecure Software

ν Send e-mail:

gem@cigital.com