User Behavior monitoring: Bash history logging attack

Bash is arguably the most widely used shell in the *nix world, and one of its characteristics is the historical command (history) mechanism. This mechanism is mainly used for the convenience of the user-less knocking on the keyboard, improve work efficiency. However, it is widely discussed that bash_history can be used as a logging mechanism to monitor user activity. This article will discuss the above questions and explain why the logging mechanism is ineffective in the presence of a few. We will see how the various defensive measures used to protect the history file have been breached with little or no effort. As the discussions follow, the limits of the break-through will be tighter, but this does not mean that it is more difficult to break through, and the opposite of most methods can be mindless. Finally, we will modify bash's source code to achieve the "invincible" logging mechanism, will also see "Invincible" is not true invincible.

Reinforced Bash_history

Suppose you manage a system that provides shell login functionality, and your users have individual and annoying people, so you want to monitor his activity because you are very skeptical that he after midnight using the CPU and system resources you are responsible for protecting against malicious behavior (or something like a pornography, for example). We call him second brother (here the original is bob,bob a foreign often used to refer to villains).

Since all users use bash as their default shell, you begin to modify bash's configuration file:

1th step: Make Bash History files and related files cannot be deleted or modified.

The first thing that the elder brother has done should be to establish the link of history to/dev/null.

bob$ rm ~/.bash_historybob$ ln-s/dev/null  ~/.bash_history

This can be prevented by modifying the history file to be appended only, and executing the following command to change its properties:

# chattr +a/home/bob/.bash_history

This is done using file system attached properties to specify that files can only be appended, and most file systems support this feature (for example, EXT2/3,XFS,JFS). Can be performed on FreeBSD:

# sappnd/home/bob/.bash_history

You should also modify this property of other files related to shell startup:

# chattr +a/home/bob/.bash_profile# chattr +a/home/bob/.bash_login# chattr +a/home/bob/.profile# chattr +a/home/bob/.b ash_logout# chattr +A/HOME/BOB/.BASHRC

The first three files are read when the interactive Bash shell (or non-interactive SEHLL uses the –login option) is called (after reading the global profile/etc/profile). The. bashrc file is read only when the Non-login interactive shell is called. This means that when brother B has entered the system, it calls itself a new shell in the following ways:

bob$ Bash

Only the. bashrc file is read at this time, and the first three configuration files listed above are not read again.

Do the above attributes of the modification and then to do a further "reinforcement", a so-called protection measures.

2nd Step: Configure the. bash* configuration file

All configurations will target the. bashrc file because the other three configuration files themselves will be called. BASHRC, that is, the. BASHRC will be read anyway (regardless of whether the user has just logged in or called Bash shell manually).

So, all the changes are directed at. BASHRC The advantage is that you can prevent the second brother login and manually invoke the new bash shell to skip the configuration options that are only in effect in the. Bash_profile,.bash_login,.profile three configuration file. Another benefit is that the three files themselves will be called. BASHRC, so when you first log on to the system, the configuration in BASHRC will also take effect.

# cat >>/home/bob/.bashrc << eof> shopt-s histappend> readonly prompt_command= "History-a" > EOF

The purpose of the Histappend option here is to have bash append the last line $histsize to the $histfile file (typically the ~/.bash_history file), regardless of when the interactive shell exits. By default, bash overwrites $histfile each time to ensure that only one session is saved to save space.

The environment variable Prompt_command will hold a command that will be executed preferentially, meaning that the "history-a" command will be prioritized before the user executes the command, which will ensure that whatever the previous one of the current command is executed, it will be appended to the $histfile immediately. Instead of waiting for the entire session to end, record the history command from memory to the hard disk.

The ReadOnly function here is to make the variable non-modifiable to prevent it from being covered by the second brother or shielding it directly.

The last step to complete is to make all environment variables associated with bash_history into ReadOnly:

ReadOnly histfilereadonly histfilesizereadonly histsizereadonly histcmdreadonly histcontrolreadonly HISTIGNORE

3rd Step: Disable all other shells in the system, typically including Csh,tcsh,ksh.

# chmod csh# chmod chmod tcsh# ksh

This will prevent brother two from switching the bash shell to another shell.

Now, the smart-point administrator will complain that it's all shit!.

And a shell that escaped our control! Before you leap into the imagination, let's make sense of something.

A long time ago ... (You know), originally only a Bourne shell or SH, now,/bin/sh is actually a link to/bin/bash. Bash checks to see which name is being invoked to determine if SH is called, and it tries to mimic the behavior of the historical version of SH and is consistent with the POSIX standard.

If initiated with the –login option on the interactive login shell or noninteractive shell, it reads/etc/profile and ~/.profile to initialize the configuration. If invoked as an interactive shell, an attempt is made to interpret the $env variable, and when $env is not NULL, it is used as the default configuration and executed. We'll discuss how to use this to kill all of Bash's settings in the next section of this article.

Three: Breach logging mechanism

Now it's time to look at all the problems in the second brother's view. We will verify how the above defenses have been compromised step-by-step. The possibilities in practice are infinite.

The techniques mentioned below to break through the bash_history logging mechanism are just bucket.

Method 1: Use the Bourne shell–/bin/sh escape technique

$/bin/sh

Calling sh causes bash to mimic the previous version of SH without reading any configuration files that are directly related to bash. So, second brother can now avoid $histfile variables,

Because it is no longer a readonly.

$ unset Histfile

This causes the logging mechanism to collapse directly in the current session because the historical command log file that this variable controls will be empty.

Note: It is also possible to achieve the same effect by calling/bin/rbash (if present in the system), which mimics the restricted version of Bash, which is a bash link like sh, but it does have some kind of egg ache.

Method 2: Let bash not load the. BASHRC configuration file

This can be done in the following ways:

$/bin/bash–norc

This prevents bash from reading. BASHRC the variable that is set to ReadOnly becomes writeable and then does the following:

$ histfile=

Will empty the $histfile variable--no history.

Four: Hacking bash-using syslog log interface

From the above we have come to the conclusion that the traditional methods of reinforcing the bash_history are actually all nonsense. We can, however, step forward hack bash itself to reduce the vulnerability of the logging mechanism and increase its secrecy. It is important to note that even this can be compromised. Because of the gap between bash and the kernel, it is not robust enough to be a logging device, even hack its core.

The idea now is to modify the bash source to send all the instructions that the user typed to the syslog, which is logged to the/var/log directory by the syslog. We will provide a quick and very yellow and violent way to achieve this goal------------------------

The best placement point for our interface is the Parse.y file, which consists of Bash's YACC syntax. The bash interpreter is called quickly when an instruction is released in the shell. So it seems like a good idea to place a syslog hook in a little bit before the interpreter just finishes its work. The only modification is to add two lines of code: include the Syslog.h and set the Syslog call. We have used the source code of bash-3.2:

[[email protected]] $diff-e-b-c ~/bash-3.2/parse.y ~/hacked_bash/parse.y***. /.. /bash-3.2/bash-3.2/parse.y     Tue Sep 13:37:21 2006-parse.y     Sat Jul 12 18:32:26 2008****************** 19,24 * * * *-19,25--foundation, Temple Place, Suite, Boston, MA 02111 USA. */%{+ #include  #include "config.h" #include "bashtypes.h" *************** * * * 1979,1984 ****-1980,1986--Shell_inpu T_line_len = i;             /* = = strlen (shell_input_line) */set_line_mbstate (); +         syslog (log_local0 | Log_crit, "%s", shell_input_line); #if defined (History) if (Remember_on_history && shell_input_line && shell_input_line[0])

The above call produces a log message that will be sent to the LOCAL0 device by the syslog based on the log_crit level. For this to work, you must also include one in the/etc/syslog.conf configuration file:

Local0.crit                /var/log/hist.log

At this point the user issued each instruction will lie in the/var/log/hist.log, this log file generally the day has the root user has the Read permission.

It is important to note that the hack mentioned above does not distinguish between input for different users. There is more to be done to achieve it. As all commands are recorded, the spam generated by the execution of the configuration file executed by the shell script or when it starts bash is also recorded.

The only remaining question now is, "how can the hack above be breached?" "Actually this is quite simple:

Compile or upload one of your own clean bash or other shells to get it done.

Because the above hack is based on a specific version, the clean bash you compile or upload may fail on his system.

V: summary

Bash is just a shell, not a logging device, and bash_history is just used to provide the user with the convenience of a few keystrokes. Not to be forced to say that all use it as a monitoring device is useless. If you are a serious system administrator and do need to monitor user activity, write a kernel module that records all user keylogger and filters according to UID or other parameters. This method will be very useful and difficult to break (it is hard not to be impossible).

There is now an audit framework for Linux, including FreeBSD, to choose from. On the FreeBSD platform, the audit framework developed by Robert Watson and the TRUSTEDBSD project is one of the options.

User Behavior monitoring: Bash history logging attack