[---------------------------[ Hacking bash History ]---------------------------]
[==============================================================================]
By: ithilgore - ithilgore.ryu.L@gmail.com
sock-raw.org / sock-raw.homeunix.org
July 2008
-------------[ Table of Contents ]-------------
i. Preface
ii. Hardening bash_history
iii. Attacking the logging mechanism
iv. Hacking bash - interfacing with syslog
v. Conclusion
vi. References
[ i. Preface ]
==============
Bash is probably the most widely used shell in the *nix world and one of its
features is the history mechanism. The history mechanism is mainly used for the
users convenience - less typing -> work done faster. However, it has been
discussed that bash_history can also be used as a logging mechanism to monitor
users activity. This article covers the arguments against the above and why the
mechanism is useless against someone who thinks out of the box. We are going
to see that every defensive measure taken for protecting the history file can
be subverted with little or no difficulty. The discussion will be increasive
in the strictness of the methods applied but that doesnt meant they will be
increasingly difficult to implement. Most of them are no-brainers. In the end,
we are going to meddle with the bash source code to make the logging mechanism
(at first sight) "invincible" and we are going to see why even that can fail.
[ ii. Hardening bash_history ]
==============================
Suppose you are an administrator of a shell-providing box and there is a really
pesky user whose activities you would like to monitor, since you are really
suspicious about what he does late at night with the precious CPU power and
system resources that you have pledged to protect against malicious (or other)
usage. Lets call the user Bob - enough of using Trinity as the "bad" one all
the time. Since all users use bash as their default shell in the server, you
start making a few changes to the bash configuration files.
// Step 1 //
-- Make the bash history and relevant files undeletable/unchangeable.
The first thing Bob would probably do would be to symlink his history to
/dev/null.
bob$ rm ~/.bash_history
bob$ ln -s /dev/null ~/.bash_history
That can be prevented by making that file append-only. This can be accomplished
by issuing the following command:
# chattr +a /home/bob/.bash_history
This will use file system extended attributes to mark the file as append only.
Most filesystems (ext2/3, XFS, JFS) support this. On FreeBSD the same
would be done by issuing:
# sappnd /home/bob/.bash_history
You might also want to apply this to all the bash configuration files that
are read during bash startup:
# chattr +a /home/bob/.bash_profile
# chattr +a /home/bob/.bash_login
# chattr +a /home/bob/.profile
# chattr +a /home/bob/.bash_logout
# chattr +a /home/bob/.bashrc
The first three are read by bash in that order (after reading /etc/profile
which applies to all users) when an interactive login bash shell (or a
non-interactive shell with the --login option) is invoked.
.bashrc is only read when a non-login interactive shell is invoked. That means
the case when the user has already logged in and invokes a new bash shell by
himself like:
bob$ bash
Note that .bashrc is the *only* configuration file that is read in this case.
The other 3 conf files are *not* read again.
After doing the above changes, its time to move on to some more "hardening".
One more step towards (futile) protection.
// Step 2 //
-- Configure .bash* configuration files
All changes will be made to .bashrc. It is assumed the other three
configuration files mention reading .bashrc in their body. This means that
.bashrc is read in *every* case (whether the user just logins or invokes a new
bash shell after he has logged in).
By making all changes to .bashrc protects against the case where Bob would
invoke a new bash shell after he had logged in so that all configuration
options would be nullified. If the options were only at the three main
configuration files (.bash_profile, .bash_login, .profile) then the above would
happen. On the other hand, these files must read .bashrc in their body so that
the options mentioned to .bashrc are actually applied in the first login shell
as well.
# cat >> /home/bob/.bashrc << EOF
> shopt -s histappend
> readonly PROMPT_COMMAND="history -a"
> EOF
The option histappend orders bash to append the last $HISTSIZE lines to the
$HISTFILE file (normally ~/.bash_history) whenever an interactive shell exits.
By default, bash overwrites $HISTFILE each time so that only one session is
kept to save space.
The enviromental variable PROMPT_COMMAND holds a command that is to be executed
prior to issuing each prompt. This means that "history -a" is executed prior
to every command the user issues. This ensures that whatever command was typed
just before the current one, is immediately appended to $HISTFILE. This ensures
more robustness in the logging mechanism, as bash doesnt wait until the whole
session is finished to transfer to the disk the history lines from the memory.
The readonly attribute is used so that this variable is marked as non-writeable
in case Bob wants to ovewrite it and most probably nullify it.
One last substep to the above changes would be to mark as readonly all the
environment variables associated with bash_history:
readonly HISTFILE
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCMD
readonly HISTCONTROL
readonly HISTIGNORE
// Step 3 //
- Disable all access to all other out of the box shells of the system. Usually,
these will be csh, tcsh and maybe ksh.
# chmod 750 csh
# chmod 750 tcsh
# chmod 750 ksh
This will prevent Bob from changing his shell from bash to another one.
Now, the astute administrator will complain that the above are *not*
the only shells out of the box! This is both true and false. But before you jump
to quantum theory conclusions based on the above statement, lets clear some
things up.
A long time ago ...(you know the rest), there was only the Bourne shell or sh.
Nowadays, /bin/sh is actually a symbolic link to /bin/bash. Bash checks the
name by which it was invoked and if this is sh, it tries to mimic the behaviour
of the historic versions of sh and also conform. to POSIX. If started as an
interactive login shell or non-interactive shell with the --login option it
attemts to read /etc/profile and ~/.profile for startup configuration. If it is
invoked as an interactive shell, then it tries to expand the variable $ENV and
if it is not empty, uses its value as the configuration file to read and
execute. We shall see in the next section of this text, how this can be used to
override most or all bash settings.
[ iii. Attacking the logging mechanism ]
========================================
It is time to see the whole thing from Bobs perspective. We are going to
examine how each of the above steps can be subverted. In practice, the
possibilities are endless. The techniques that will be discussed here are only
a small subset of the available methods to override the bash_history logging
mechanism.
// Method 1 //
-- Use the Bourne shell /bin/sh as an escape mechanism