The systems we use every day
keep clues to our identity

Breadcrumbs are left throughout computer systems that hackers can use to track attribution or recover sensitive information that was unintentionally left behind by the development team. We have put together a list of possible gotchas and present them in this blog post.

But before we present our list, let us define the categories of vulnerabilities you may encounter as you work with your computer systems.

ssh

Using ssh can lead to some accidental identity leaks, especially if your username or hostname have clues to your identity. Here are some examples:

• [Identity] The last field of your ssh public keys contains a comment that is initialized by default with the “user@host” value when the key is generated.
• [Identity] When connecting to an ssh server, it by default tries all of your public keys in sequence, which may leak your identity. It’s also possible to scrape all the public keys linked to accounts on GitHub, which you can use to associate a key with a username. See https://github.com/FiloSottile/whoami.filippo.io.
• [Identity] Even if you scrub your keys, ssh attempts made without specifying an explicit user will default to using the username of the active user. For example, the command:
  • ssh <remote-domain> is, by default, modified in the background to be:
    • ssh <user>@<remote-domain>
  • And, if there isn’t an account on the remote system for these usernames, failed attempts are logged in authentication logs (/var/log/auth.log) with the usernames attempted.

Ghidra

Ghidra, especially with a shared Ghidra server, can be a great tool for software analysis; however, there are several places to watch for where it can record your username:

• [Pathname] While uploading files to a shared Ghidra server, the full path of the file is captured and stored in an “About [file]” information page (accessed in Ghidra via the CodeBrowser view, Help -> About).
  • To check if the file path contains identifying information, run the pwd command in the location where your soon-to-be-uploaded files live.
  • To avoid this, place files to be uploaded on a path outside of your home directory, like /usr/local/ghidra or /opt/ghidra or /home/ghidra/files, and then upload them.
• [Identity] Additionally, Ghidra stores a history of changes made to shared files. For example, when modifying files on a shared Ghidra server and checking in those updates, a label history is kept of changes to labels. This history stores the username of the active user who made the changes.
  • You can prevent this by assigning a different default username for Ghidra to use in your Ghidra configuration settings.
  • Add a line to your Ghidra launch properties (i.e., </path to Ghidra>/support/launch.properties) with:
    • VMARGS=-Duser.name=<new username>

git [Identity]

When cloning a git repository, a reference log (<path to repo>/.git/logs/HEAD) is created to track all the local events for the repository. The first event logged is the initial clone event.

The logged event contains the username and email of the user responsible for the action. For the initial clone event, git fills in this information by first looking for a global username/email configuration to use. If there is no global configuration set up, the default behavior is to fill in the “username” section with the current user’s username and the “email” section with his or her hostname (i.e., <username>@<hostname>).

This issue persists even when you change the local username/email configuration for the repository. You must then be careful not to copy the repository directory with the reflog file to a sensitive system.

Tar File Metadata [Identity/Primary Group ID]

When tar-ing files and directories, the default behavior is to capture the effective user id and group id (UID/GID) ownership permissions of the files and directories and preserve these file permissions in the resulting tarball.

This can easily be prevented by explicitly defining the UID/GID to placeholder values when tar-ing files via the tar options: --owner=0 –group=0

USB Storage [Miscellaneous]

Identifying traces can be left on USB sticks. Files in the System Volume Information folder have no official documentation and can store anything. Some file systems, like EXT, have superblocks that contain data—such as the last mount point—that can also contain identifying information.

Searching for Strings [Miscellaneous]

On systems with Bash, a history of terminal commands that have been run during the current session is stored for reference in ~/.bash_history. This is something to note if you are in the process of scrubbing a system after an identity leak: If you use commands like grep to search for any remaining traces of identifiable information on your system, you have just inadvertently added new traces into the Bash history buffer. Those buffered commands will update the history file on disk after you log out.

$ tail -f ~/.bash_history
grep -rni "bob smith"

To make matters worse, if you go to edit your Bash history to remove identifiable strings using text editors like vim, and in doing so search for those strings using vim commands, you have just inadvertently added those into your vim history (~/.viminfo).

$ cat ~/.viminfo
...
# Last Search Pattern:
~MSle0~/bob smith
...
# Search String History (newest to oldest):
?/bob smith
|2,1,1712777001,47,"bob smith"

And if you have to use the sudo command to run specific commands (like when searching for strings or editing files in another user’s home directory), those commands are stored in authentication logs (/var/log/auth.log).

$ tail -f /var/log/auth.log
Apr 10 15:15:26  sudo:  : TTY=pts/4 ; PWD=/home/somewhere ; USER=root ; COMMAND=/bin/grep -rni bob smith

Conclusion

This post is definitely angled towards Linux systems. If you know of any identity leaks we missed or want to add the Windows/MacOS/etc. equivalents, message us at hello@zetier.com.