printer friendly version

Don’t bash your head over unsecured credentials

While working on servers, you or your team will likely spend a decent amount of time on the command line. During this time, it is more than likely that, amongst other available shells, you will be using the bash shell, which is the default shell in most Linux distributions.

Server administrators are likely to perform the same commands repeatedly, so it makes sense that all executed commands are stored. This allows the administrators to quickly execute a previous command without having to repeatedly type it out.

This, however, also makes it extremely easy for adversaries to search the bash command history on compromised systems for insecurely stored credentials.

An attacker eye view on bash shell misuse

Bash keeps track of the commands that users type on the command-line with the ‘history’ utility. Once a user logs out, the history is flushed to the user’s bash history file. For each user, this file resides at the same location: ~/.bash_history. Typically, this file keeps track of the user’s last 500 commands. The amount can be increased or decreased depending on your environment variables.

Users often type usernames and passwords on the command-line as parameters to programs, which then get saved to this file when they log out. Attackers can abuse this by looking through the file for potential credentials.

Below is a simple one-line command which will return the bash history for every user on a particular Linux server. Once an attacker has a presence on the server and executes a command like the one below, they will be able to see the history of all commands executed through bash. With a slight modification to the command below, they may decide to pipe the response into a simple .txt file for offline consumption and analysis.

find /home -name .bash_history -print -exec cat {} 2>/dev/null \;

While the above command will list the history for all users under the home directory, it is also possible to get more specific with the query so that it will return commands that contain certain key words like ‘Summer2021’, this being a possible indicator of a weak password stored insecurely.

Below is an example of how an attacker would search the bash history of the current user to identify if any passwords have been configured insecurely and therefore, ended up in the bash history.

cat ~/.bash_history | grep "Summer2021"

This is a common technique within the MITRE ATT&CK; Framework: https://attack.mitre.org/techniques/T1552/003/

If the adversary is lucky, they will see usernames and passwords in clear text. Armed with the usernames and passwords, they can then continue their advance through your environment either via lateral movement or privilege escalation. Below is an example of what an attacker might find in your bash history.

• echo 'root:RedactedPassword*' |chpasswd

• useradd -c Joe Blogs joeb ; echo joeb:RedactedPassword |chpasswd

Here, you can see the Bash HISTCONTROL and HISTIGNORE variables to control how commands are added to history.

‘HISTCONTROL can be used to exclude lines starting with a space and prevent duplicates from being placed in history. While HISTIGNORE can be used to exclude repeated commands, commands that start with spaces and commands that match on password irrespective of the case of the word password (*[Pp][Aa][Ss][Ss][Ww][Oo][Rr][Dd]*).’ – Rob Kielty.

HISTIGNORE=”&:[ \t]*:*[Pp][Aa][Ss][Ss][Ww][Oo][Rr][Dd]*”

How to use bash history for incident response

It is worth noting that it is a good idea to hunt proactively across your Linux estate for insecure and weak passwords contained within the bash history file. If you are able to surface these issues at the earliest opportunity, it will strengthen your security posture and hamper the adversary.

In addition, the bash history is an incredibly useful tool during incident response engagements. For instance, if you are performing an investigation on a Linux server, the commands executed by the adversary will be stored in the bash history. Assuming that they haven’t used another shell or cleared the bash history. From this, you can then see the commands and map out the attack made. With this knowledge, analysts can then put in place actions to mitigate the attack or prevent a similar attack from occurring again.

If you found this blog useful, you may also find the analysis of other vulnerabilities that often get overlooked, such as Security 101: Compromised AWS S3 Buckets and Security 101: What are LOLBins and How Can They be Used Maliciously valuable.

Share this article:

Further reading: