While researching lateral propagation password use in our Deception module, Fidelis Cybersecurity found a surprising number of passwords publicly available. We continued to investigate by pivoting on what we found and uncovered vast caches of passwords. These password lists are publicly available, most likely without the owner’s knowledge or clear understanding. Here’s what we found:

Credentials in the wild

Our cursory scan of GitHub – a well-known development platform for businesses of all sizes– revealed numerous accounts and passwords stored in plain-text including:

• More than 500 Chrome password manager databases, most of them in plain text, unencrypted. In some cases, we found hundreds of such credentials stored by a few GitHub users.
• 100+ Firefox password manager files. While these were encrypted, we could, in many cases, locate the encryption key and easily get to the passwords.
• 250+ Linux password managers based on Gnome-Keyring.
• In some cases, we were even able to remotely discover and validate Linux admin passwords.

The passwords and credentials that we found could enable access to popular web sites and services, including: PayPal, Facebook, Google, Twitter and Office 365. Credentials were also found for access to corporate web services and university accounts, probably leaked from home computers and smartphones used for business.

We notified GitHub on this issue together with examples of information types found and informed them of our intention to post a research blog on the dangers of using password managers that are not secure enough and to alert on the danger of uploading personal information to be publicly available.

We recommended that they notify users that could be affected and advise them to remove such data and update their passwords. Up to now, we have not received a response from GitHub on this issue.

We know that in other cases, GitHub has notified their users when there was a possibility that their plain text passwords had been viewed by others.

We are publishing this to help prevent potential security breaches.

Contributing too much to the community

Community sites are used by software developers to share their code. A very popular community site, GitHub, enables developers to host and review code, manage projects, and build software alongside millions of other developers.

When people upload files to GitHub (or other such communities), they are encouraged to upload hidden files to make backup and sharing easier for the community.  These hidden files can include some sensitive information that people might be uploading with the best of intentions or without even knowing that they are in essence making this information public.

After upload, the files cannot be removed by merely deleting them. Once they reach GitHub, they might remain in repository history forever. GitHub has published a guide for removing sensitive data from the repository, but we suspect that few do this. Furthermore, even if people do go through the permanent removal effort, the data might have already been cached by other tools or services. Users can never be sure the content has been removed completely.

Combining weak password managers together with uploaded hidden files to public locations can expose plain-text credentials. This is valuable data that attackers can get their hands on easily without even accessing endpoints or the enterprise network. From that point, breaching security and exfiltrating data is simple. Corporate security teams and red teams have also been doing this for years – evaluating the company’s external password exposure and searching the web for privileged information.

Using password managers in browsers

These days, we have a password for almost any service used on the internet. Since most of us have a hard time remembering our inventory of passwords, we utilize the convenient facilities of browser or operating system-based password managers that do the remembering for us. However, these facilities are not as safe as we might think.

People who are knowledgeable about cyber security will usually keep their passwords safe via services like LastPass or KeePass. However, most users are not in this category. They will typically use the built-in password manager in their browser (Chrome, Firefox, Opera, etc.) or in the operating system. (Note that browsers like Edge and Internet Explorer utilize the Windows OS credential manager.)

Combining non-secure password managers with the uploading of hidden files to public locations (knowingly or unknowingly) results in credentials in the wild, often in plain text! Even when passwords are encrypted, the keys are often made available for their decryption. 

Regardless of which services are used, the passwords are typically encrypted and saved locally on the computer. Despite the encryption, passwords shouldn’t be saved in the browser, at least not in the default way. Here’s why:

Firefox

By default, Firefox encrypts passwords before saving them. It sounds secure, but it’s not. For encryption, Firefox uses a key file called key3.db that is saved along the JSON credentials file itself. Anyone who has access to both files, can decrypt the passwords easily, using readily available tools like passwordfox, a small password recovery tool that allows to view the user names and passwords stored by the Firefox Web browser.

Chrome on Windows

Chrome appears to be safer. By default, it encrypts passwords on Windows machines using the WINAPI function, CryptProtectedData, with the user credentials (username and password) of the local user and the local computer itself. Even if an attacker has the user credentials, the passwords cannot be decrypted unless the attacker is on the local machine.

If we do have the user credentials and are on the local machine, here is how to access the password data.

• Use the actual browser or view offline using the SQLITE file called “Login Data” under the relative path of Chrome usually, “C:\Users\User\AppData\Google\Chrome\User data\Default\Login Data”. In either case, Windows credentials must be used to read the passwords.
• Opening the password database file with SQLITE browser, will not show the passwords in plain text since they are encrypted, but a simple script can be used to decrypt them; or alternatively, a tool like ChromePass.exe can be used to show them.

Chrome on Linux

On Linux, things get more interesting.

Chrome will encrypt passwords only if it finds an encryption method to work with. Chrome passwords on Linux machines that were installed with Gnome-Keyring or KWallet will have encryption enabled. In other cases—usually when people make a custom Linux install using advanced settings—there may not be a valid encryption mechanism available. In this case, passwords will be stored in plain text. Anyone with access to the machine files can see the passwords without needing to know the machine password.

In the Linux files we found on GitHub, most of the credentials (60%) were stored in plain text.

Now, even if the Linux system has Gnome-Keyring encryption, passwords are still not secure. For example, when installing a fresh Ubuntu desktop, we’re actually using the Gnome workspace. Gnome uses the Gnome-Keyring deamon to save openssh keys, certificates, and all kinds of services including Chrome passwords.

Gnome-Keyring uses the user machine password to lock the login.keyring file that saves all the passwords. To view the passwords in a GUI, you can use the Seahorse package that replaces the Gnome-Keyring Manager from GNOME 2.22. With Seahorse, all saved passwords are seen merely by using the password entered during log in to the system. If the user password is different than the one that encrypted the passwords, a lock icon is shown. Clicking on it will unlock those passwords manually.

The bottom line

Access to the machine password will easily show the other credentials. In addition, this is a way to test various machine passwords, by getting offline validation when the correct one is found.

To validate the machine password, we can take advantage of the Gnome-Keyring and some local files.  For that we need to first determine that the machine is using the keyring encryption. Then, look for the Firefox passwords and decrypt them. Using a tool like Seahorse with the Firefox passwords, helps to identify which is the machine password. Now, we have a validated machine password as well as all Firefox and all Chrome credentials.

Here are the details of the full attack chain for validating the machine password:

1. Find login.keyring file in GitHub by search “filename:"login.keyring" path:/.local”.
2. Search in the user directories of GitHub for the Firefox logins.json file.
3. Decrypt the passwords of Firefox.
4. Clone and replace the login.keyring to your .local/share/keyrings/.
5. Logout from your machine to load the new login.keyring.
6. Open the seahorse GUI and unlock the password manager with passwords of Firefox.
7. Congratulations, the machine password was found and validated!
8. With that we can now view Chrome passwords.

How to protect your passwords and credentials

1. Guard your passwords carefully like your data depends on them. It does. Don't use the default password manager for important accounts. Use a highly secure, third-party password manager instead of product defaults. When you are connected to Chrome, use Google credentials to encrypt the password. Use Master Password in Firefox.
2. Beware of what you upload. Open source communities are great, but they must not be allowed to become a cyberattack springboard into your network. Beware of what you’re uploading and give more thought to where you're uploading your private content. Don’t upload more than what you need to.
3. Diversify. Make sure you have a strong, unique password for each service. Your bank account password should be different from your work-computer password and different from your email password.
4. Assess your company’s password exposure. Periodically assess your company’s external password exposure. Try to find privileged information on your company, passwords and account data, on the web.