The "ln" command is an important tool in any Unix admin's arsenal and attackers use it too, so it is essential that forensics analysts understand it. It is used to either:
- Create a link to a target file with a selected name.
- Create a link to a target file in the current directory.
- Create links to each target in a directory.
The "ln" command will by default produce hard links. Symbolic links are created with the "-symbolic" option set (or "-s"). In order to create a hard link; the target file has to exist. The primary formats of the commands are:
- ln [OPTION]... [-T] <TARGET> <LINK_NAME>
- ln [OPTION]... <TARGET>
- ln [OPTION]... -t <DIRECTORY> <TARGET>
Some malicious uses of ln are in hiding files, though perhaps not very well, and creating subterfuge by wrapping legitimate programs. The "ln" command need not alter any files on the host. Yet, it can be used to redirect a user or process to another file. It can also be used to replace a file or to create one that is linked to a rogue binary in another location.
It is not only binaries. Configuration files and even devices (/dev/*) can be linked. As an example, many users do not check their path. It is all too common to see users and even administrators run a binary without specifying the path to the file. For instance, running "sh" instead of entering "/bin/sh". Worse, path environment variables and many directories are often poorly configured.
In previous security assessments, I have noted this issue many times. The following example is from a real financial system.
- The path for root was
/usr/local/bin:$PATH
- The directory permissions on the "/usr/local/bin" directory were 775 allowing common group members on the system to create files.
- The shell "/bin/sh" existed, but there is no
/usr/local/bin/sh
An attacker could create a malicious script on a virtual file system and add a link to it at "/usr/local/bin/sh". For instance,
ln —s /dev/.. /ramcache/evil_script /usr/local/bin/sh
Where the file
/dev/.. /ramcache/evil_script
can be as simple as a script that does a set of commands and returns to the shell such as:
#!/bin/sh /dev/.. /ramcache/do.evil.stuff.sh /bin/rm -rf /usr/local/bin/sh rm —rf /dev/.. /ramcache /bin/sh
The question arises, "why not just copy a file directly to the link location". The answer is anti-forensics. It is possible to load files into memory space and into memory file systems (e.g. /dev/.. /ramcache). It is far more difficult to recover memory file systems than to recover deleted files on disks.
The symbolic link file will be recoverable, but possibly not its contents.
In the example above, as the wrapper shell is first in the path, the linked file in "/dev/.. /ramcache" will run instead of the desired "/bin/sh" shell command. This could occur through poor scripting (where the full path is not included in the script header) or when a "lazy" user or administrator types "sh" rather than "/bin/sh".
Another example is to link the "touch" command into a memory location. The "touch" command can be used to change the last modified and accessed times on a file. This can hide the fact that a command was executed or that a file was read. The problem is that the touch command will display a modified access time. This is an indication of its being run (logs may also exist, but these are checked less often).
By creating a "hard link" into the *NIX memory file system, a copy of the command can be created in full. Hence, the touch command can be run and leave only volatile data as evidence of its use.
An attacker may make use of this technique and it is important to understand the implications.
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 law and 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.
