Security Laboratory

Security Laboratory

Security Laboratory: Methods of Attack Series

These papers introduce you to the most common attack methods against computer systems and networks and the basic strategies used to mitigate those threats.

Other Related Articles in Security Laboratory: Methods of Attack Series

Alteration Attacks

By Stephen Northcutt

Alteration attacks are just what they sound like; they occur when someone makes unauthorized modifications to code or data, attacking its integrity. These attacks can take many different forms and have a variety of consequences. An organization might have a Software Development Life Cycle, but the binary code can be altered. A person with access can recompile an existing program to add another library or DLL, or use a binary editor like HT Editor.[1]

"Self-modifying code is quite straightforward to write when using assembly language (taking into account the CPU cache). It is also supported by some high level language interpreters such as SNOBOL4, the Lisp programming language, or the legendary ALTER verb in COBOL. It is more difficult to implement on compilers but compilers such as Clipper and Spitbol make a fair attempt at it, and COBOL almost encouraged it. Batch programming scripts often involve self-modifying code as well."[2] While there are some valid reasons to write self modifying code, from a security perspective, this isn't something we consider good practice since the application could be an unknown, or in an unevaluated state. Here is what Dennis Ritchie, one of the greatest software developers, had to say about a variant of self modifying code, Just in Time compilation:

We've flirted with, embraced, and pulled away from the idea
of this cyclically over the years. (Ken Thompson's compilation
of code for recognizing regular expressions was one of
the early software patents (#3568156, 1971)) and Reiser's
bitblt was the first of several local implementations of the idea
for doing low-level graphics operations.[3]

The place where code is altered and not managed is one of the biggest non-attacker driven problems. Maintenance code is often not subjected to scrutiny. Failures to check inputs and removal of security design measures can happen during this period. Often, the programmers assigned to update or maintain code have less ability and training than an initial implementation team. If your organization is starting to train your developers in software security, make sure all the developers get trained. Otherwise, the security effort you put into the design may be undone during a maintenance phase.

Alteration attacks apply to data as well as code, in fact even more so. For example, what if an attacker defaced your organization's web site in a very subtle manner? Instead of posting a trite message about how your site was 0WN3D and that you suck, they may stealthily modify the numbers in your last quarterly report to make it look like business was very poor in order to drive your stock price down.

Or maybe you caught the latest web server worm. Worms are definitely alteration attacks because they have to modify something on your system in order to work. However, coupled with rootkit technology they may be able to avoid detection. Malware has been a primary vector for integrity attacks for a very long time. Consider the following from F-Secure on the Brain virus from 1986, "The Brain virus tries to hide from detection by hooking into INT 13. When an attempt is made to read an infected boot sector, Brain will just show you the original boot sector instead. This means that if you look at the boot sector using DEBUG or any similar program, everything will look normal, if the virus is active in memory. This means the virus is the first 'stealth' virus as well."[4]

The primary defense against an alteration attack is a cryptographic hash. If you can record the state of a program or data before it is altered and securely store the hash, you can periodically recheck the program or data and compare it with the stored hash. SHA 2 is recommended for the hash algorithm. As NIST says, "The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical."[5]