[PDF] 600.643 - Group 2 Report Hiding Code

View - Download 600.643 - Group 2 Report Hiding Code

Previous PDF

Next PDF

600.643 - Group 2 Report

Hiding Code

Lucas Ballard

lucas@cs.jhu.eduDaniel Chou dhchou@cs.jhu.eduJoann Chuang joannc@jhu.eduSujata Doshi sdoshi@cs.jhu.edu

Peter Kimball

kimball@cs.jhu.edu

November 11, 2004

1 Introduction

Though many techniques for finding malicious code have been developed, we found few publicized tech-

niques for creating and hiding malicious code. Traditional malicious code examples include viruses, trojans,

and worms, but we define malicious code to be any code that does not behave as the user intended. Our goal

is to analyze current methods for the creation and hiding of malicious code and to develop novel program-

matic methods for creating malicious code and hiding it. To analyze current methods, we began by searching for existing malicious code hiding tools, but in

addition to the paucity of papers on malicious code hiding we found no existing tools. We hypothesize that

the lack of code hiding tools is indicative of the nature of this work. Attackers do not want their techniques

known, because malicious code detection programs would be adjusted and customized to find those attacks.

Though a few articles discuss hiding malicious code in binaries, we limit our work to the source code level.

From our research, we found several general categories of code hiding techniques: steganography, plausible

deniability, human fallibility, and machine fallibility. Steganography involves hiding malicious code in files

other than source code files, while plausible deniability focuses on injecting vulnerabilities that could simply

be human error. Human fallibility exploits human expectations and machine fallibility uses known malicious

code detection tools to tailor malicious code hiding methods to escape detection. Code interpretation in general is undecidable making the development of good generalized malicious

code injection tools extremely challenging. Our tool design began by using the last technique, machine

limitations. We examined methods for finding malicious code and developed techniques to escape detection.

Our first tool, All Your Stacks Are Belong To Us, aims to subvert ITS4 [7]. It analyzes source code for

possible buffer overflow locations, determines the most dense areas of source code (presumably the most

difficult areas for humans to analyze/understand), and in those areas minimally change code to produce

overflows. The inspiration for our second tool comes from a combination of the results from static analysis

tools and the second technique, plausible deniability. These static-analysis tools report unsafe function calls

that could produce vulnerabilities. Our second tool, Captain Careless, searches for safe function calls and

replaces them with their unsafe counterparts, removes restrictive permission calls, and replaces permission

checks with a constant value of 1 meaning success. Lastly, we propose extensions to our tools and an additional method for developing code hiding tools using abstract syntax trees. 1

2 Generalized Techniques

2.1 Steganography

Although not strictly source-code related, malicious code can be hidden in non-source files, such as images

or binaries. This technique for hiding code is steganography. During execution extracted code becomes

the source of malicious behavior. The majority of malicious code exists in non-source files, minimizing the

amount of malicious code hidden in source code. The problem with hiding information through steganography is that there must be code to extract the

hidden data. This extraction code is equivalent to hiding any other code complicating information hiding

through steganography. Since hidden code needs to be extracted during execution, this code must be in

binary formto separate executionand compilation. Steganographyhas the potentialto allow theintroduction

of significant malicious code, but its reliance on executing extraction code before injection and the need to

hide extraction code limits its practical value. Since steganographic techniques do not directly relate to source-code vulnerabilities, we do not im-

plement any of these techniques in our tools. We are aware of no tools designed to facilitate the use of

steganography in vulnerability insertion. An example of a vulnerability that uses steganography is the re-

cent "JPEG COM Marker Processing Vulnerability" [1], which allows arbitrary code in a modified JPEG file to execute as the local user.

2.2 Plausible Deniability

If insertion of malicious code can appear accidental, there exists plausible deniability. By constructing

malicious code from known vulnerabilities and common coding mistakes, one can introduce vulnerabili-

ties while maintaining the outward appearance of legitimate software. Human reviewers will believe the

mistakes to be the work of an incompetent programmer, rather than the carefully constructed art of a so-

phisticated cracker. Although an intelligent auditing tool will properly flag the common mistakes, a human

reviewer may dismiss them as simple negligence. While a programmer may be blamed for outwardly malicious behavior, malicious code comprised of

simple mistakes could be dismissed as unintentional, giving the evil programmer a significant advantage.

However, the same programmer must cope with the limitations of what can be reasonably believed to be

accidental. Though there are many common mistakes, there are limitations to what a hacker can do with

these: pairing a common mistake with even a single outwardly malicious technique reveals the malicious

nature of an entire series of "mistakes". The wily hacker has numerous common mistakes available for use and thousands of well-publicized

exploits that use these mistakes. The problem is so widespread that evenUNIXman pages explicitly warn

of the potential misuse of certain functions likestrcat. Identifying malicious code which exploits these

weaknesses is not the problem: instead the problem lies in identifying malicious code which does not.

2.3 Human Fallibility

A careless programmer often introduces vulnerabilities to source code. Though the code review process

should screen out these errors, sometimes a thorough code review for large software projects is infeasible.

Here a general source code review that looks for the most common problems may replace an in-depth

detailed review. Thus the auditing process may overlook source code vulnerabilities that lead to more

complex race conditions and buffer overflows. The attacker can modify the source code to appear similar to

2

the original code such that the new code does something completely different. For example, changing '=="

to '=" alters a compare UID statement to a set UID statement [5]. The attacker may also insert misleading

comments to disguise his exploit. Even security analysis may incorporate human error. One method of identifying exploitable vulnera-

bilities in software security analysis is through the use of attack trees. Attack trees represent the decision-

making process of attackers. These structures allow security analysis by organizing the available data into a

logical flow; however, there is no set standard for building and using attack trees. Building a good attack tree

requires highly specific knowledge of protocols, implementation, and the execution environment. Security

analysts are not infallible and may overlook an attack or a potential vulnerability when defining an attack

tree structure. Thus, the analysis designed to secure software may contain errors that allow vulnerabilities to

escape detection. If attackers can determine which vulnerabilities an attack tree overlooks, he/she can take

advantage of the vulnerabilities to launch an attack.

Even if the software security analysis detects a vulnerability, the cost to defend against the vulnerability

may be too high. Software designers may decide only to document and not to fix a vulnerability. Attackers

can take advantage of these expensive vulnerabilities to create source code exploits. On the other hand,

normalizing code format and color coding regions by type (e.g. highlighting comments) minimizes human

fallibility.

2.4 Machine Limitations

and hinders meeting production deadlines. Static-analysis tools (e.g. RATS [6] and ITS4 [7]) scan source

code for potential security vulnerabilities. These auditing tools generate a list of potential vulnerabilities in

software and suggest potential remedies. This list provides a basis for security analysts to build on.

Unfortunately, these tools focus mostly on UNIX vulnerabilities and the scanning process is not fully

automated. At present, these tools require expert knowledge for the scanning process to be accurate and

efficient [8]. After scanning is complete, a manual security analysis is necessary adding another time-

consuming component to the software security review. The inadequacies of only using the security auditing

tools allows insertion of malicious code in an undetectable manner. Our first tool utilizes this technique (See

Section 3). The drawback of this technique is that a careful human auditor performing a manual security

analysis will catch these obvious exploits.

3 Tool 1: All Your Stacks Are Belong To Us

We developed a tool which facilitates the process of insertingbuffer overflowvulnerabilities into C source

code. Our tool deals only with inserting vulnerabilities that can be exploited when smashing the stack. Heap

overflows are beyond the scope of this tool.

3.1 Simplifying Decisions

Before writing this tool we made the following assumptions and decisions to keep our project manageable.

1. We do not need to capture the complete understanding of the C programs that we are parsing. We

made this assumption because we are not securing a system, but attacking it. We just have to be thorough enough to allow/insert exploits. More specifically, we avoid following conditional flow in the given source program to reduce the complexity of our tool. 3

2. We decided to modify the source code as little as possible. Due to the complexity of software, even

small changes can lead to large ramifications. This tool implements subtle focused attacks that require

changing minimal amounts of source code.

3. We did not want this tool to actually modify source code, because it is not infallible. Our tool simply

quotesdbs_dbs7.pdfusesText_5

[PDF] raw socket python

[PDF] rayon de la terre en km

[PDF] rayon de la terre en m

[PDF] raz and dworkin

[PDF] rb digital canada

[PDF] rbdigital vs flipster

[PDF] rdm 6

[PDF] rdm flexion exercice corrigé pdf

[PDF] rdm flexion poutre

[PDF] rdm6 flexion telecharger

[PDF] reaction acide base exercices corrigés pdf

[PDF] reactions of alkyl halides

[PDF] reactions of alkyl halides pdf

[PDF] reactions of amides pdf

[PDF] read inheritance free online