Breaking Software Security

Randy Marchany VA Tech IT Security Lab

Fault Model for Security Vulnerabilities

Software can be correct without being secure Intended behavior doesnt always equal actual behavior Software does extra things its not supposed to do This is where many security vulnerabilities exist

Called side effects

Software Fault Model

Kernel OS API UI

Application

File Systems

Software Fault Model Components

OS, Kernel provides memory, file pointers, time, date and other functions File System provides data stored in binary or text format User Interface (UI) set of APIs that gets inputs from keyboards, mouse and other devices API other software that provides input to the software application

Security and the User Interface

Inputs that originate from a UI, or program Security concerns

Sabotage Unauthorized access Malicious input

Security and the File System

Interaction between the application and the file system is rarely tested File system is entrusted to store sensitive data, passwords, other persistent info Is this info stored in publicly accessible areas?

Security and the OS User

Application information must pass through memory at one time or another Cleartext info could be leaked if memory is accessed by unauthorized users or programs Low memory, crash dump areas need to be investigated

Security and the Software User

Applications rely on other software to accomplish their tasks Application is only as secure as the other software it uses Build a catalog of external components the application uses Software component interdependency is important

Security Inside the Software

Sometimes the software itself has to be protected Can it be reverse engineered?

The art of learning software secrets from a compiled binary

Creating an Attack Plan

What fault would have caused this vulnerability? What were the failure symptoms that would alert a tester to the presence of the vulnerability? What testing technique would find this vulnerability? This created 4 attack categories

Software dependency attacks UI attacks Application design attacks Design implementation attacks

Attacking Software Dependencies

Environmental Fault Injection

Simulates failures in the applications environment Error handling routines are subjected to far less testing than the functional code theyre designed to protect Source-based Fault injection Modify source statements to trigger faulty behavior Runtime Fault Injection Intercepting OS function calls

2 basic approaches

Attack 1: Block access to libraries

When to apply

Test is designed to ensure the application doesnt behave insecurely if software libraries fail to load Applications rely on library code for validation routines If calls cant be executed or return unexpected errors, the applications error handlers might not respond securely.

What faults make this attack successful?

Attack 1: Block access to libraries

Was security compromised?

Sensitive data dumped? What happens if the application continues to run despite failing to load modules properly? Application that fails to display error when modules arent loaded may not have good error handlers in place Data corruption? Failure to perform critical validation tasks

Attack 1: Block access to libraries

How to conduct the attack? Find out which libraries the application accesses and when Try to figure out which libraries might impact security Block access to a library and see what happens. Watch for insecure behavior

Sensitive data dumped? What tasks were being performed when it tried to load the library>

Attack 2: Manipulate the applications registry values

When to apply the attack

Whenever a registry key is read or written by the application Not all info stored in the registry is secured from other users or applications Does the application trust information from the registry?

Attack 2: Manipulate the applications registry values

What faults make the attack work?

Trust Applications trust data from the registry especially if it wrote data there in the first place Piracy, theft or disclosure of sensitive data

How to determine whether security is compromised

Read the registry keys User-access info, implementation clues, confidential information

Attack 2: Manipulate the applications registry values

How to conduct the attack

Find the registry keys that the application relies on

During installation Application startup Update installation Users or resources authenticated

Once registry keys are identified, alter their values and see how application responds

Attack 3: Force application to use corrupt files

When to apply the attack

Make sure application handles bad data gracefully without exposing sensitive data or allowing insecure behavior
UI data usually ok File system data usually not because most testing is done on the UI

What faults make it work

Attack 3: Force the application to use corrupt files

Was security compromised?

DOS attack? Application dies when it reads bad data Buffer overrun Corrupt data displayed on screen displays
Identify a file the application will use and change it in some way the software doesnt expect

How to conduct the attack

Attack 4: Manipulate, replace files that the application uses

When to apply the attack

Any time the application reads/writes to the file system, launches an executable or accesses functionality from a library Previous attack tried to get the software to process corrupt data
Applications tend to trust the file system as an input source Library and executables trust is implicit

What makes it successful

Attack 4: Manipulate, replace files the application uses

How to determine success

Goal: test whether application allows us to do something we shouldnt be able to do First, watch the application and see which files it accesses Second, determine when its accessed and for what purpose Look for data files, libraries that can be replaced with malicious or trojaned versions Web apps that use cookies are good targets

How to conduct the attack

Attack 5: Force the application to operate in low memory, disk space

When to apply the attack

w/o sufficient memory or disk space, most applications will not work Appls that rely on shared data also rely on the net Stress test the appl by blocking a resource when the appl most needs it Disk space: look for periods of read/write

Attack 5: Force the application to operate in low memory, disk space

What makes it successful

Unhandled, poorly handled failures can leave the application vulnerable

Low memory tends to use swap memory or files. Can you read the swap file? Low disk space can generate crashes and leave sensitive data in dumps Network access can affect user authentication

How to determine success

Attack 5: Force the application to operate in low memory, disk space

How to conduct this attack

Memory: launch multiple copies to use up memory Fill up disk space using infinite loop

Summary of Dependency Attacks

List the libraries the application uses Find out the registry values it uses Find what files it opens and uses Alter the libraries and files Try disk, memory, network DOS

Breaking Security Through the UI

Fault model tells us most security bug result from additional, unintended and undocumented user behavior Goal is privilege escalation, information disclosure

Attack 6: Overflow input buffers

When to apply the attack

Most high level languages are immune to BO because they detect and prevent them explicitly or automatically resize arrays Applicable any time software accepts alphanumeric input from a user GUI, command prompt or API

Attack 6: Overflow input buffers

How to determine success

Application crash send long strings to the application and see if it crashes Identify input field as target Look for data gathered from untrusted user via WWW I/F or data files Look for applications that run at higher priv levels

How to conduct the attack

Attack 6: Overflow input buffers

How to conduct the attack

Use longstrings.doc Use 1234567890, increase length by 10 each time Look for error messages that quote the string. Theyre storing the data somewhere in the program and could be overflowed

Attack 7: Examine all common switches and options

When to apply the attack

Applications are tolerant of user input from default configs How does it react when these configs are changed?
Developers may not consider all of the possible configs as they attempt to secure input

What makes it successful

Attack 7: Examine all common switches and options

How to determine success

Some code paths include security procedures, others dont. This lets us do the penetrate and patch
Command line switches forced the application to execute underutilized code Get around input string filters.

Was security compromised

Attack 7: Examine all common switches and options

How to conduct the attack

Look at previous releases, look for obscure switches, options Try different command line options

Attack 8: Explore escape characters, character sets and commands

When to apply the attack

Find out which characters of combinations of characters are treated differently Force application to process special characters and commands
Poorly constrained input Web apps, input scripts

What makes the attack successful

Attack 8: Explore escape characters, character sets and commands

Was security compromised

Possible DOS by sending bad input to a remote application Craft an input string to force the appl to perform unauthorized actions Applications usually have 2 parts
Form that GATHERS data Server applications that PROCESSES data

Attack 8: Explore escape characters, character sets and commands

How to conduct the attack

What OS does the appl run on? What language is it written? What libraries, scripts, dbs and external applications does the user data get passed to? What are the character sets, reserved words, commands that the application components use?

Attack 8: Explore escape characters, character sets and commands

NUL

MS-DOS uses NUL terminated strings in system functions Program interrupt character
Unix uses EOT as an EOF

^C (ETX)

^D (EOT)

Embedded Nulls may cause all chars following it to be ignored Program may abort EOT may cause the shell to terminate

Attack 8: Explore escape characters, character sets and commands

^J, LF

Unix uses it as a linespace character

Terminal handshake, ^Q causes input echo to freeze looking like a lockup

^Q, ^S XON/XOFF

Windows uses CR/LF, could cause persistent data problems Unix handles this differently

Attacking Software Design

Attack 9: try common default, test account names and passwords Attack 10: Use Holodeck to expose unprotected test APIs.

Holodeck is available from www.howtobreaksoftware.com/security Monitors applications and its interaction with system calls

Attack 11: connect to all ports

Attack 12: Fake the source of data

When to apply the attack

Some data is trusted implicitly based on its source This attack ensures the application verifies the source of data and that the level of trust that extends to the source is appropriate
Trust is usually extended on identification w/o authentication Network data might be poorly authenticated

What makes it successful

Attack 12: Fake the source of data

When is security compromised

If the application accepts data from untrusted or unauthenticated sources

What type of data is accepted Try to determine which user is associated with the input (person, program, location) Determine the privileges for each user Try to alter the tag, field, property that identifies the datas source

How to conduct the attack

Attack 13: Create loop conditions in any application that interprets script

When to apply the attack

Take benign commands and repeat them over and over to DOS users or processes
Command loops can cause the application to DOS itself or users Successful DOS

What makes it successful

Was security compromised

Attack 13: Create loop conditions in any application that interprets script

How to conduct the attack

Any user inputs that get processed as more than just a string Parsed values like HTML fields

Discover set of commands your application will process

<SCRIPT Language=VbScript> On Error Resume Next Dim a Dim i For i=1 to 100 Set a = CreateObject(Word.Application) Next </SCRIPT> If placed at a www site, will attempt to open 100 instances of Word

Attack 14: Use alternate routes to accomplish the same task

When to apply the attack

Example: how many ways can you open a Word doc Type the path in the Run dialog box Double-click on the icon in Explorer Type the path, filename in Explorer Type the path, filename in Internet Explorer Select it from My Recent Documents on the start tab Type the file name in the Open dialog box within Word Is security in place for all of these paths?

Attack 14: Use alternate routes to accomplish the same task

What makes it successful

Software inherits characteristics from its environment May restrict input from one source but forgot about multiple sources like keyboard shortcut (Ctl-N in Windows)
If user is able to perform restricted actions Copy and paste issues

Was it successful

Attack 15: Force system to reset values

When to apply the attack

Applies to all types of software Leave fields blank, click FINISH instead of NEXT, etc. Are default values in place?
Software allows variables to have illegal or non-existent default values Missing user input allows garbage input because s/w doesnt have defaults

What makes it successful

Attack 15: Force system to reset values

Was security compromised

Software crashed if data introduced remotely Do default values leave the application in a vulnerable state?
Enter data, delete it and see if youre allowed to proceed

How to conduct the attack

Design Attack Summary

Try common default password and userids Launch application under Holodeck and look for libraries loaded by the application Port scan the system Fake the source of input data Try to force the application into a loop through user data supplied remotely Explore alternate routes to run the program or supply data Try null values to force application to accept default values

Attacking Implementation

Implementation often is less secure than the design Functional requirements are easy to test for security Implementation isnt

Attack 16: Get between TOD and TOU

When to apply the attack

Data is at risk whenever you can separate the functions that check security from the functions that actually uses it. TOD & TOU: too much time passes between the time the data is checked and its used
Some actions arent atomic and involve multiple steps

What makes it successful

Attack 16: Get between TOD and TOU

Was security compromised

If you can escalate your privilege over some part of the application or its data Look for gaps between when a privilege is checked and it is used

How to conduct the attack

Attack 17: Create files with the same name as higher privileged files

When to apply the attack

Some files enjoy special privs based on their location

Dll file

Sometimes libraries are usually loaded by name w/o further checks Attack targets is applicable any time the application makes execution or privilege decisions based on filename

Attack 17: Create files with the same name as higher privileged files

What makes it successful

Search order of applications for libraries Windows appls have a very specific sequence of directories they search when looking for libraries Files treated as special cases based on their name AUX used to represent devices WordPad properly recognized AUX as a fileneme. IE doesnt (pre SP2)

Attack 17: Create files with the same name as higher privileged files

Was security compromised

Attacker is allowed to perform a restricted action by manipulating or creating a file that bypasses normal security controls Application processes a file depending on the file name that causes different treatments of the file or its contents

Attack 17: Create files with the same name as higher privileged files

How to conduct the attack

Pick a feature that interacts with the file system Think about the files, file types that this feature may try to read

Attack 18: Force all error messages

When to apply the attack

By trying to cause error messages, we are testing the robustness of the data input section of the code
Error handlers are usually added after testers have broken functionality Error handlers written at different times to handle similar data

What makes this successful

Attack 18: Force all error messages

Was security compromised

Application may be breached by malicious data Sensitive data may be revealed by error messages
Test applications robustness to erroneous input Review error messages to ensure they dont reveal sensitive data

How to conduct the attack

Attack 19: Use Holodeck to locate temp files and screen contents

When to apply the attack

Temp files can hold sensitive info Find creative ways to gain insecure access to these files
Temp files, cookies can leak info

What makes it successful

Was security compromised

Sensitive info obtained?

Attack 19: Use Holodeck to locate temp files and screen contents

How to conduct the attack

Identify sensitive applications Launch application under Holodeck Watch for CreateFile calls Pause execution to view temp files Open the files and examine their content

Reference

All material for this unit was taken from How to break software security by James A. Whittaker, Herbert H. Thompson, Pearson Addison-Wesley, ISBN: 0-32119433-0 Holodeck was developed by the authors