Dotfiles Backup, for the context of this blog is a framework/methodology/concept. It is a collection of files, often starting with dots (as the name implies) where users (developers, system admins, etc) store their personalised configurations for a variety of software. These collections are often pushed to a git repository and contain configuration files for software such as Vim, VSCode, Zsh, .aliases, git, and so on.
A common use case for dotfiles is when users join new companies and get issued a work laptop. Often we see them clone their dotfiles repository and symlink files to apply custom configuration for their favourite software. Over time these configurations may be updated and changed, such as tokens and credentials being saved to configuration files. Eventually, the user pushes a commit to save their dotfile repository, resulting in unintended credential leakage.
One of the most common (and generic) ways to look for intel or credential leakage via dotfiles is to search for the presence of the string “dotfile” (i.e. path:*dotfile* on GitHub) combined with other keywords of interest. For example, we know AWS CLI is widely used and parameters for AWS Secrets tend to start with keywords like “AWS_SECRET”. Therefore, if we use a search like (path:*dotfile* OR path:*dot-file* OR "dotfile") "AWS_SECRET" we may see some results after filtering through the noise (i.e. the result below from the 4th page). However, this approach is fairly generic and heavily limited by GitHub’s five-page search limit and inability to sort by recently updated (to name a few restrictions).
The real benefit comes when the search is combined with well-defined keywords. For example, in this scenario you work at a company (domain s4.nz) that is currently using Artifactory, and usernames for Artifactory are user emails (i.e. [email protected]). With this in mind, you could run a threat hunt with the theory that someone may be leaking Artifactory credentials through dotfiles. An example search for this may look like (path:*dotfile* OR path:*dot-file* OR "dotfile") "@s4.nz" "artifactory.s4.nz". These types of searches often result in two findings; One - Information an adversary could use for reconnaissance against a target company. Two - Discovery of credential leakage. While this example uses GitHub, the same logic can be applied across GitLab or Bitbucket instances.
At the time this post was published, I came across two main tutorials showing how to utilise dotfiles using different methodologies. The first tutorial is by Atlassian, using a config-based approach to manage dotfiles. This tutorial contained no mention of security or best (security) practices. The next tutorial is a GitHub Pages site maintained by a community, the site is thorough and contains a mention in the FAQ page on how to remove sensitive data (but unfortunately no mentions of security or best practices otherwise).
I am a firm believer that to make someone do something, you have to explain the why (i.e. educate them). It’s likely that when these tutorials are being followed; the consumers of these may not have security in front of mind, or an understanding of the risks associated with following tutorials that you don’t understand completely. A small section on security or security hygiene can go a long way, especially when new members of the industry are following these tutorials. Managing security risks should always be about “Yes…but XYZ condition” instead of a straight “No”. With that in mind; “Yes, we can have dotfiles stored in a publicly accessible repository, but users need to be aware of the risks and should utilise secret scanning”.