Archive for January 14th, 2008

Dealing with “Hidden” Files

Files can be “hidden” on a filesystem in several ways; some are just attempts to “hide in plain sight.” This is not hiding data in files (such as steganography) but rather hiding the mere existence of files themselves.

There are several ways to do this. The basic ideas are:

  • Make reporting tools lie about the existence of files. This falls into the realm of “rootkits.” Utilities such as ls (and even the kernel itself) may modified in order to not report the existance a particular file. A way to avoid this is to use programs (during examination) that are statically linked and precompiled and saved to read-only media: such programs are immune to future modifications, except for kernel resources (if the kernel is taken over, then all other resources are suspect).
  • Make files “disappear” in file listings. Files of this sort include “.. ” (two dots followed by a space) and other non-standard characters. These files look normal but are not. One way to see files like these is to use the ls command and its -b and -q options. The -b option prints the octal equivalent of non-printing characters; the -q option uses the “?” character instead of non-printing characters. The -F option may also be of use: a file with a terminating space will show up when the -F places its “type” character at the end of the file name.
  • Open the file, then delete it. As long as the file is in use, its disk blocks remain in use, and the file remains available. No other processes can access it - or even see it - but the program (or programs) that opened it still has access to it. Of course, this only works for running programs, but files disappear this way almost entirely. To see the files, use the utility lsof with the +L1 option. The +L option lists files with less than that many links; thus, +L1 lists files with less than one link (or zero links).

As mentioned previously, a static build of all relevant utilities to CDROM can be a very useful tool during investigation of a possible system break-in. All general reporting tools should be included: ls, ps, top, etc. Also included should be any desired programming interpreters: ksh, perl, ruby, tclsh, lua (whatever one finds useful). Also included should be any more intensive tools as well: tcpdump, nmap, etc.


Add comment 14 January 2008


David Douthitt

David is an experienced UNIX and Linux system administrator, a former Linux distribution maintainer, and author of two books ("Advanced Topics in System Administration" and "GNU Screen: A Comprehensive Manual"). View David Douthitt's profile on LinkedIn

Recent Posts

Top Posts

RSS Sharky's Column!

Calendar

January 2008
M T W T F S S
« Dec   Feb »
 123456
78910111213
14151617181920
21222324252627
28293031  

Recent Comments

bharat on The Demise of the HP-UX System…
H4mm3r on Avoiding catastrophe!
Vladimir on Argument list too long?
ddouthitt on The UNIX find command and…
Mihir G joshi on The UNIX find command and…

Category Cloud

BSD Career Debian Debugging Fedora FreeBSD HPUX Learning Linux MacOS X Mind Hacks Mobile Computing NetBSD Networking OpenBSD OpenSolaris Open Source OpenVMS Personal Notes Portable Presentations Red Hat Scripting Security Solaris Tips Ubuntu UNIX Wheel Group Windows

Archives

Feeds

Links