MITRE ATT&CK vulnerability spotlight: Bash history
Introduction
MITRE is a federally funded research and development center (FFRDC) for the U.S. government. This means that they perform a variety of activities for the U.S. government. In MITRE’s case, this includes research and development in cybersecurity.
One of MITRE’s cybersecurity efforts includes developing and maintaining the MITRE ATT&CK matrix. This tool breaks down the cyberattack life cycle into its component stages and describes different methods by which an attacker can perform each stage. This information is valuable for formalizing cyberdefense and penetration testing efforts and aids in R&D efforts and cybersecurity discussion.
Exploiting bash history
The MITRE ATT&CK matrix is broken up into several different stages, one of which is credential access. In the credential access stage of an attack, a hacker tries to steal user credential information to gain access to accounts or elevate privileges on a system. One way of accomplishing this is by taking advantage of the bash history function on Linux systems.
The bash history function in the bash shell on Linux is designed to keep a record of a user’s past 500 commands on the system. This is useful for a variety of different purposes since it makes it easier for a user to recall or reuse previously typed commands. Also, it can be used for monitoring usage of a system, and bash versions 4.1 and later allow automated logging of bash history to syslog.
However, recording a user’s command history can also expose sensitive information. A user may enter commands that include their username or password, and this information may be logged to the bash history file. If so, an attacker who has access to a user’s bash history file can search through it to find these credentials.
One way that user credentials can be included in the bash history file is if they are provided to an application as arguments. Most applications will implement an authentication interface that obscures user credentials, but others may allow them to be provided as arguments.
However, this only works if the command is typed correctly. For example, a user may be quickly typing and type sudp instead of sudo, followed immediately by their password. If this occurs, the password will be recorded in the bash history file.
Examples of bash history attacks
When downloading a file from a web directory that has .htaccess protections, it is necessary to include a password in the wget command. For example, a user may type:
wget -u username -p password http://www.example.com/secret_image.jpg
While this command would allow the user to download the protected file, it also exposes the user’s password in the bash history. An attacker will access to the bash history file could determine the credentials used to access the secret image.
Detection and mitigation
The simplest way to detect if a user’s credentials are contained within a bash history file is to search for the credentials yourself. Regular expressions or fuzzy string matching can be used to detect possible passwords in a bash history file and/or mistyped commands (like sudp) that could have accidentally exposed a user password. Scanning against a list of the most common passwords might also detect leaked passwords on the command line.
It is also possible to prevent a user’s password from being logged to the bash history file. A number of possible options exist, including:
- Running set +o history to stop logging and set -o history to resume
- Append unset HISTFILE to the user’s .bashrc file
- Run ln -s /dev/null ~/.bash_history (writes history to /dev/null)
- Terminate the bash session using kill (terminates session before history file is written)
- Run history -c or deleting ~/.bash_history (clears the history)
However, completely disabling the bash history file might be undesirable. Some other options for ensuring that a particular command or piece of data isn’t included in the bash history file include:
- Putting a space before the command in the terminal (if export HISTCONTROL=ignorespace is in the user’s .bashrc file)
- Storing a password in a temporary variable using read -e -s -p “<prompt>” <variable_name>
- Editing ~/.bash_history to remove the command
- Adding HISTIGNORE=”<regex>” to the user’s .bashrc file (regular expression defines certain commands to ignore)
Training users and developers not to use or create programs that require credentials as command-line arguments is always a good idea. However, mistakes can happen, or such a program may be required for business purposes. All accounts should implement the principle of least privilege to ensure that the impact of a password leaked through the bash history file (or other means) has a minimal impact on the security of the organization.
Conclusion: Protecting against bash history attacks
Bash history is designed to be an asset on a Linux system. It keeps a record of a user’s actions on the system, which can be useful both to the user (by allowing them to recall or reuse past commands) or for monitoring their actions on the system.
Most Linux applications are designed not to take user credentials in a way that they would be exposed in the bash history file, but some exceptions exist, and mistakes can be made. Monitoring the bash history file for data that may be user credentials and/or configuring bash history to minimize the probability that a user credential could be included in the history log can minimize the probability that an attacker could use the file to compromise user credentials.
Sources
- Bash History, MITRE
- Hiding from Bash history, DigiNinja
- Prevention of user's passwords being stored as plain text in bash history, StackExchange
- HakTip 39 – Bash Basics: Keep History Free from Passwords, Hak5
MITRE ATT&CK™
