Post on 22-Mar-2019
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