Creating heterogeneous environments for malicious code
Tufan Demir
Homogeneity in software is a desired property because it makes it easier for development, distribution, maintenance etc. However it is an undesired property
in terms of security because it allows computers to be infected or attacked easier and faster. The problem is how we can break the vulnerability specification
for the executing component code that the attacker is exploiting without breaking the required functionality of the executing component.
The platform will be Microsoft Windows operating system, because it is the target for most viruses. However this adds some complexity to the project,
since the available code for windows is in binary format. This format is called the PE file format where PE stands for portable executable. All the .exe and .dll
files follow PE file specification [1].
The executable files usually import functions to perform a meaningful task. These functions are stored in dynamic link libraries. As the name suggests, the imported
functions are not statically linked into the executables. Rather, the functions in a dynamic link library are shared among executables. This helps reduce code size and
increases efficiency. The function calls in the executable is implemented as an indirect jump. The jump is indirect because the imported functions address is stored in
the import address table(IAT). The function call first jumps to a specified offset into the IAT to get the real address of the imported function. The call has to be indirect because the imported function’s address is not known at compile time and it is the loader’s responsibility to resolve the function reference. IAT makes the loader’s job easier, instead of patching every function call, it just fills in the IAT and the functions point to IAT.
The presence of IAT is also useful for the malicious injected code. To call a function that is in the IAT, all it has to do is to supply the parameters and learn the function’s address from IAT. Kernel32.dll is one of the system dlls which is imported by almost every dll and executable. It contains two important functions
LoadLibrary and GetProcAddress. Using these two functions a virus can import any function it wants. Permuting the entries in the IAT will break the virus
writer’s assumption that ,say, kernel32.dll is in the specific location he expected. So one of the goals of the project is to modify the executable file by permuting
the IAT.
Some other viruses such as Code Red and MS Blaster find the dll’s they need by performing a search-by-name. Code Red searches the memory starting around 0x7FFFFFFF hoping to find the string “kernel32.dll”. MS Blaster searches the process environment block to locate kernel32.dll. To break the virus writer’s
assumption, one can try renaming the dll names. If kernel32.dll was renamed as xyz_10t.dll at boot time, the virus would not be able to find the dlls it needs by
performing a search-by-name. It could however try to load the dlls listed in the process environment block (PEB) one by one. This method can be detected by inserting fake dlls in the PEB and reporting the access to a dll that should never be accessed. The renaming of the dlls is the second goal of the project. If every
computer has a different set of dlls, the malicious code will have a hard time to perform its tasks.
Some of the previous work done on software diversity includes address obfuscation [2] and instruction set randomization. Both of these approaches are effective
against injected code attacks. In the former approach, the authors randomize the location of data and code in the executable program which makes the crafted buffer overflow code ineffective. In the latter approach, the authors randomize the instruction set, i.e. they xor the instructions with a key. Before execution of the
instruction they apply the key again to get the original instruction. The injected code will be xor’ed with the key only once, which will transform it into a meaningless
instruction. However this approach needs hardware support.
[1] http://www.microsoft.com/whdc/system/platform/firmware/pecoff.mspx
[2] Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, “Address
Obfuscation: An Efficient Approach to Combat a
[3]
Gaurav S. Kc, Angelos D. Keromytis, Vassilis Prevelakis, “Countering
Code-Injection Attacks with Instruction-Set Randomization,” in [ACM-CCS-03]