Digital forensics practitioners, incident responders and *nix system administrators should be aware of programming tools that can aid attackers. It is simple for an attacker to load code when compilers or other tools are installed on a system. In this event, the attacker can simply add any tools that are desired by compiling them on the host. Source code can be uploaded over ASCII connections such as telnet, so even a console can be used to load one's favorite tools when compilers are installed.
In many cases, compilers and other similar tools have been restricted or (ideally) not installed on production systems. Where this is the case, it is still common to discover many related tools (including disassemblers) on a host. Some of these tools are covered in this section. These may allow an attacker to create and load code on a system, so when analyzing a compromised host, you need to think beyond gcc and the common compilers.
In many instances, systems will not have tools at one's disposal that can easily be used to test privilege escalation. In this instance, an attacker may "roll their own" exploits. Stack and Heap overflows are all too common in software. Even where patches are available, it is all too common to find patches missing. This can be a result of legacy systems not functioning when the patch is applied, or a simple failure for any reason to have applied the patch.
In these instances, an attacker could exploit a flaw in the software to gain additional privileges on the system (maybe even root). The following tools are a small sample of common Linux tools that may be found and used on systems that have restricted compiler access.
GDB / DBX
"gdb" is a software debugger in Linux and "dbx" is essentially the same in UNIX. These commands are commonly found on systems where compilers have been removed as many system administrators are uncertain of their use.
There are many useful tutorials on the web for both gdb and dbx. Some of these include:
These are highly advanced tools, so I have left them to the end of this paper. The boon of finding them on a system cannot be beaten. These tools are primarily used when looking for exploitable flaws on a system.
If you can copy an executable from the system, this can be run and verified on another *NIX system. Any exploitable flaws can then be discovered and used in the testing and validation process.
objdump
The "objdump" command is a disassembler similar to gdb. It is not a debugger. This difference means that you can disassemble the executable binary without actually having to execute it. This can come in handy when you are looking for poorly constructed binaries (e.g. those with stack overflows) but are not ready to execute these.
This also gets around the issue where a binary has read privileges for a user account used by the tester but not execute rights.
readelf
The "readelf" command is similar to "objdump" with more detailed information being provided on ELF headers (Executable and Linking Format). It is used in the analysis of executable binary files to view the GOT (Global Offset Table) and the PLT (Procedural Linkage Table).
ltrace / strace
The "ltrace" tool is used to intercept and record library calls. It is similar to "strace". The "ltrace" command executes a program recording all of the library calls made and any signals that are received. "strace" also records system calls as well as library calls.
Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC and completed the GSE as well. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial lawand ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.
