How does the browser Store passwords?

I. Introduction

I have introduced dumpmon, a Twitter bot that monitors account dump, configuration files, and other information on many "post-code websites. Since then, I have been paying attention to the monitoring information. Next we will have a series of articles about dumpmon, and this article focuses on how browsers Store passwords.

Dumpmon is mentioned here because I accidentally found some codes. For example, this article should be a log of malware infected on the computer. I thought: I always think it is best not to let the browser store the password directly, but why? How easy does malware obtain passwords from infected computers? It is a little difficult to get all the desired information from one place, so I decided to post the results here and some simple code to extract the password from the password manager of each browser.

This document analyzes the following browsers on windows 8.

Ii. Chrome

Difficulty in getting a password: simple

We started with Chrome. Sadly, chrome is the easiest way to extract passwords. The encrypted key is stored in an SQLite database under % APPDATA % \ .. \ Local \ Google \ Chrome \ User Data \ Default \ Login Data. But how is it stored and encrypted? I obtained a lot of information about the Chrome password stored in Google Chrome, which was written four years ago. Although Chrome has made some changes since that article, I will use some fragments of Chromium source code in the same way to show you how the password is dumped.

Store encrypted passwords

When a user accesses a website, Chrome first checks whether the login is a successful logon and determines the code snippet:

If you log on successfully and use a new certificate that has not been generated by the browser before, Chrome will generate a prompt to ask if you need to remember the password:

To save space, I skipped the code for creating a prompt bar. When you click "Save Password", the "save" function of Chrome Password Manager is called to respond to the operation:

Simple. For a new session login, run the following code to save it:

For the control space, some content is cropped (for example, an operation review of whether the certificate belongs to a google website ). After this function is called, the task for executing the AddLoginImpl () function is called. This is used to make the interface fast response:

This function calls the AddLogin () function of the database object to check whether the operation is successful. The following is AddLogin () (I promise that we will soon see how the password is stored ):

There are some interesting things here. We use the user password to generate a string key. This code has been removed, but under the "SQL: Statement" line, an SQL query Statement is executed to store encrypted data in the login data file. The EncryptedString function simply calls the EncryptString16 function on an encrypted object (that is, the following ):

Finally, we can see that the password is encrypted by calling the Windows API function CryptProtectData. This means that the password can be restored only when the login certificate used for encryption is used. This is not a problem at all. malware is usually executed in the User Login environment.

Password cracking

Before discussing how to decrypt the password stored above, let's first use the Sqlite browser to view the data in the login file:

Our goal is to extract action_url, username_value, and password_value from this database (which is binary data, so the SQLite browser cannot display it ). To crack the password, you only need to call the CryptUnprotectData function in Windows API. Fortunately, Python has prepared a perfect library called pywin32 for calling Windows APIs.

Let's take a look at the PoC we use:

Run the above Code and you can see that the operation is successful!

Although it is a little troublesome to find out how the password is stored (you can also use other dynamic methods, but the analysis code will be more thorough), it is almost useless to decrypt the password. The only protected part is the password and only the current user is protected.

Iii. IE browser

Difficulty in getting a password: simple/General/difficult (depending on the version)

Basically, the password management of IE browser is the same as that of Chrome before IE10, but there are some interesting changes. For a comprehensive presentation, we will first briefly discuss the Password Storage of the IE7--IE9, and then discuss the changes in IE10.

IE7-9 Browser

In earlier versions of IE, different password types are stored in two different places:

Registry (form-based verification)-these passwords are submitted to sites such as Facebook and Gmail.

Certificate file-the HTTP Authentication password method, similar to the online login certificate.

Based on the needs of this article, we will discuss the certificate based on form verification, which is also the target of attacks that most attackers may choose. These certificates are stored in the following registry key locations:

HKEY_CURRENT_USER \ Software \ Microsoft \ Internet Explorer \ IntelliForms \ Storage2

You can use regedit (Registry Editor) to view the value, similar to the following:

As an example in Chrome, these certificates are encrypted and stored using the CryptProtectData function in Windows API. The difference is that this function adds additional entropy (entropy, entropy is the degree of confusion, used to describe the process of an event that is constantly moving towards chaos ). The entropy here is the registry key value, which is the SHA1 checksum of the website URL for the certificate.

This is very useful because when a user accesses a website, IE can quickly determine whether the certificate already exists based on the URL hash value, and then use this hash value to decrypt the certificate. If attackers do not know that the URL is used here, decryption of the certificate will become very difficult.

Generally, attackers can reduce the effect of this protection method by traversing the user's Internet access history, hashing each URL, and checking each storage certificate.

The complete code is not provided in this Article. You can obtain the complete example here. Now let's start to discuss IE10. IE10 Browser

IE10 changed the password storage mode. All automatically filled passwords are stored in a place called "web certificate" in certificate management, as shown in:

My personal understanding (I cannot find more information on this issue). These certificate files are stored in the % APPDATA % \ Local \ Microsoft \ Vault \ [random] Directory. You can find the files and their formats here.

What I know is that it is not difficult to obtain these passwords. In fact, it is very easy. To support the windows App Store, Microsoft provides a new Windows runtime to support more API access. This winRT provides an access interface for Windows. Security. Credentials namespace, which provides all functions used to traverse the user certificate.

In fact, there is a short C # script PoC. When executed in the user's environment, it will retrieve the Stored Password:

After the program is executed, the output is similar to the following:

Note: I have deleted some sites that I have disabled IE storage. In addition, I do not know why some creden are stored.

As you can see, as long as our program is executed in a specific user environment, it is a little complicated but simple to extract all the passwords used by the specified user. Next let's continue. Iv. Firefox

Difficulty in getting a password: Average/very difficult

Next, let's talk about the tricky Firefox. We mainly use the methods in these slides to obtain information about user data storage locations.

First, reveal the secret of Firefox Password Management. To meet the needs of developers to create applications that meet various Security standards, Mozilla developed an Open Source library called "Network Security Services" or "NSS. Firefox uses an API called Security Decoder Ring or SDR to encrypt and decrypt the account certificate. Although the name is very literary, let's take a look at how firefox uses it to encrypt. When a Firefox configuration file is first created, a random key called SDR and a Salt: salt, in cryptography, refers to inserting a specific string at any fixed position in the password, so that the hash result is inconsistent with the hash result using the original password, this process is called "adding salt") and will be created and stored in a file named "key3.db. Use this key and salt to encrypt the user name and password using the 3DES encryption algorithm. The ciphertext is base64-encoded and stored in an sqlite database called signons. sqlite. The Signons. sqlite and key3.db files are located in the % APPDATA % \ Mozilla \ Firefox \ Profiles \ [random_profile] Directory.

So what we need to do is get the SDR key. As explained here, this key is saved in a container named PCKS #11 software "token. The token is encapsulated into the "slot" of PKCS #11. Therefore, you need to access this slot to decrypt the account certificate.

There is another problem, this SDR is also encrypted with 3DES (DES-EDE-CBC) algorithm. The decryption key is the hash value of Mozilla's "master password" and the value of global salt corresponding to the key3.db file.

Firefox users can set the master password in the browser settings, but the key is that many users do not know this feature. As we can see, the integrity chain of the user's entire account certificate depends on the password selected in the security settings. It is the only value unknown to the attacker. If a user uses a strong master password, it is unlikely that the attacker wants to restore the stored certificate.

So -- if the user does not set the master password, the blank password will be used. This means that the attacker can extract the global salt, obtain the hash operation result with the empty password, and then use the result to decrypt the SDR key. Use the decrypted SDR key to endanger the user certificate.

This process looks like this:

For more information, see the source code. The main function responsible for certificate decryption is PK11SDR_Decrypt. The entire function is not displayed here. Only the called functions are listed as follows:

PK11_GetInternalKeySlot () // obtain the Internal key Slot

PK11_Authenticate () // use the primary password to authenticate the slot.

PK11_FindFixedKey () // obtain the SDR key from the slot

Pk11_Decrypt () // use the SDR key to decrypt Base64 encoded data

As for the example code for deciphering the password, the process is a bit complicated and I will not go into details here. This section describes two open-source projects that can complete this process:

FireMaster-brute force password cracking

Ffpasscrack-the Python solution is recommended. This solution uses the libnss. so library for load DLL. If it is used on Windows, cygwin DLL files can be used.

V. Summary

I hope this article will give you a clear picture of how the browser stores passwords and why they shouldn't be stored in some situations. However, this article cannot conclude that the password stored in the browser is not safe at all. For example, in the case of Firefox, it is very difficult to obtain the account details if a strong master password is used.

If you use other password management methods, such as LastPass and KeePass, this is an excellent solution. You can also use two-factor authentication, such as Yubkey.

* This article is written by the Texas Institute of Technology Security Team. IDF volunteers translated by Cheng jingbo and proofread chapter.