Endpoint Protection

by Mikhael Felker

1. Introduction

This two-part paper presents an analysis of the security mechanisms, risks, attacks, and defenses of the two most commonly used password management systems for web browsers, found in Internet Explorer and Firefox. The article specifically addresses IE 6 and 7 and Firefox 1.5 and 2.0. Attention is devoted to the following areas:

• Password storage mechanisms: The means of safeguarding usernames and passwords on the local file system through encryption (addressed in part 1).
• Attacks on Password Managers: The methods of subverting or bypassing safeguards (partially addressed in part 1; continued in part 2).
• False sense of security: Users employing password managers without any awareness of the risk factors (discussed in part 2).
• Usability: Features that enhance or deter the usability of security features (discussed in part 2).
• Mitigation and Countermeasures: Actions that can be taken by users and corporations to reduce the risk (part 2).

Internet Explorer and Firefox together amass roughly ninety-five percent of all browser market share. [ref 1] AutoComplete [ref 2] and Password Manager [ref 3] are the features that store web form usernames, passwords, and URLs for Internet Explorer (since version 4), and Firefox (since version 0.7), respectively.

Each browser has helpful features to aid the user from being tasked with remembering different usernames and passwords as a means of authentication for web sites. Thus when navigating to a URL such as http://www.gmail.com where form input fields are present, both IE and Firefox will prompt the user if he or she wants to save their username and password. When the user re-visits the same web site the browser will automatically fill the fields.

Although these features greatly simplify the responsibility of the user, they also introduce security considerations that are addressed in the next few sections.

2. A case for password managers

The need for password managers is tied directly to the difficulty of memorizing numerous sets of usernames, and passwords for specific web sites. Indeed it can be noted that password managers can increase the overall security because they allow for greater entropy in the use of identifiers and passwords. Thus a user can generate many different usernames instead of relying on just one, making it more difficult for the attacker to guess.

The tradeoff is that the user has to trust the application to perform its role (securely storing, processing, and forwarding credentials to authorized entities). Password managers are not a panacea, however they leverage technology, effectively raising the bar for attackers, by improving the user interface to computing environments that routinely require authentication.

Users and businesses alike need to be ensured that password management systems are both properly implemented and used, including an awareness of risk factors that may be involved. This article can be used as a basis for the design of more secure password managers by reviewing possible attacks, thus acting a potential bulwark to future attacks.

3. Previous work

The use of the same username and password in multiple web sites increases the likelihood of compromise, whereby the attacker would only need to discover one username and password, to compromise all of the user's resources. The use of passwords, [ref 4] techniques of memorization, [ref 5, ref 6] and the dangers of password reuse [ref 7] all have been extensively studied. Additionally, extensions to Firefox have been studied to reduce the success of password guessing brute force attacks on its password manager. [ref 8]

4. Password storage mechanisms

The locations and mechanisms of storing usernames and passwords are described below. This information was used as the basis of studying attack vectors that are reviewed in section 5 (which spans both part one and two of this article).

4.1 Storage location

4.1.1 Internet Explorer 6 & 7

On Internet Explorer (versions 4 through 6) AutoComplete web form information is stored in the Registry in the following hive locations:

Encrypted usernames and passwords:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\SPW

Web addresses:

HKEY_LOCAL_MACHINE\Software\MicrosoftProtected Storage System Provider\

Cryptographic symmetric keys: [ref 9]

HKEY_CURRENT_USER\Software\Microsoft\ Protected Storage System Provider\

On Internet Explorer 7, AutoComplete information is stored in the Registry as well but in a slightly different location.

Encrypted Usernames and Passwords: [ref 10]

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

Entries in the registry are only created when the user is prompted to save login information (the username and password) for a web site. The acronym SPW is short for SavedPassWords.

4.1.2 Firefox 1.5 and 2.0

On Firefox, Uniform Resource Locators (URLs), usernames, and passwords are stored in a file called signons.txt:

Encrypted usernames, and passwords on Windows systems are stored in:

%userprofile%\Application Data\Mozilla\Firefox Profiles\xxxxxxxx.default\signons.txt

Where %userprofile% is the environment variable in Windows that shows the path to the user's home directory.

Encrypted usernames, and passwords on Linux systems running Firefox are stored in the following location:

~/.mozilla/firefox/ xxxxxxxx.default/signons.txt

Where the xxxxxxxx is randomly chosen when Firefox is installed. The signons.txt file is created the first time that any login for a website is saved. Subsequent logins for different URLs are inserted into the file. It is irrelevant to the password manager if the site is accessed using HTTP or HTTPS. URLs are not encrypted because they are used as a reference (lookup) for matching login credentials. More specifically, when a browser password manager needs to auto-fill the login for a particular site, that site's URL is referenced with the signons.txt file, if that URL exists, the respective username and password are filled into the login of the web site.

Continued on page 2...

[ref 1] C, Galvin. "Firefox doubles market share as IE slips," 2005, The Register.co.uk, (Accessed February 2006).
[ref 2] MSDN "Using AutoComplete in HTML Forms," 2005, msdn.microsoft.com/library (Accessed March 2006)
[http://www.mozilla.com/firefox/releases/0.7.html, (Accessed March 2006)
[ref 4] R. Morris and K. Thomson. "Password Security: A Case History," in Communications of ACM, vol.22 no.11, 1979, pp 594 - 597,.
[ref 5] A. Blackwell, A. Grant, R. Anderson, and J. Yan. "Password Memorability and Security: Emperical Results", IEEE Security & Privacy, 2004, pp 25-31
[ref 6] S. Jeyaraman and U. Topkara. "Have the cake and eat it too - Infusing usability into text-password based authentication systems," in Proceedings of the 21st Annual Computer Security Applications Conference, 2005, pp.473-482.
[ref 7] Ives, B., Walsh, K. R., Schneider, H. (2004). "The domino effect of password reuse," in Communications of the ACM, 47, 2004 pp. 75-78.
[ref 8] E. W. Felten, A. Halderman and B. Waters. "A convenient method for securely managing passwords," in Proceedings of the 14th international conference on World Wide Web Chiba, Japan, 2005.
[ref 9] NIST. Federal information processing standard (FIPS) 140-1 Documentation: Security Policy. Windows NT Operating System, Microsoft DSS/Diffie-Hellman Enhanced Cryptographic Provider, 1994.
[ref 10] "Passwords in Internet Explorer 7," http://www.nirsoft.net/articles/ie7_passwords.html (Accessed November 2006)

4.2 Storage and access mechanisms

4.2.1 Internet Explorer 6 & 7

Storage Construct: Registry
Format: Binary, stored as a pair of hex values in a REG_BINARY data type.
Encryption: TripleDES
Access: Protected Storage API (for IE 4-6); Data Protection API (for IE 7)
Requirements for Access: User logged in
Transient Storage: Symmetric keys zeroed from memory after use. [ref 9]

Internet Explorer versions 4-6 use the Protected Storage System Provider (PStore) to save and access user sensitive information including usernames and passwords entered on web forms in IE. [ref 10] PStore as defined by MSDN is an Application Programming Interface used to store information that is to be kept secure. [ref 11] In a recent publication of Microsoft Press [ref 12] it was noted that:

"...the Protected Storage service, which is no longer considered a secure method of storing secrets. The most significant Windows application that still uses the P-store is Microsoft Internet Explorer, which stores Auto-Complete information, including names and passwords used for forms-based authentication."

PStore data is encrypted with TripleDES and stored in a binary construct. Unencrypted data cannot be directly accessed via the registry. However, data security and access are logically tied to a user's Windows login credentials. Once the user is logged in, any program running under the context of the user can gain access to unencrypted PStore data by using the correct API calls. Different Windows user accounts cannot however access each others PStore data.

PStore is not exclusively used with Internet Explorer; it is also a commonly used mechanism of other Microsoft based products such as Outlook and MSN Explorer. These programs are also susceptible to the same weaknesses in the security design. A multitude of Spyware programs have been known to subvert PStore security through its easily programmable API and gain unauthorized access to information [ref 13] (also see section 5 on Attacks).

Internet Explorer 7 uses the Data Protection Application Programming Interface (DPAPI) [ref 14] however credentials can still be exposed and promulgated to external programs through API calls.

Cryptography for AutoComplete in IE7 is shown below using standard terminology: [ref 15]

EK - Encryption Key
RK - Record Key
CRC - Cyclical Redundancy Check
Hash - Secure Hash Algorithm (SHA)

Storing credentials:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {data}_EK
Store (C, V) is indexed by RK in the Registry, destroy EK

Retrieving credentials:
EK: URL
RK: Hash(EK)
Lookup RK in Registry, if match is found corresponding V contains encrypted data;
data: {V}_EK

The URL is therefore required to retreive credentials (data), as it composes the Encryption Key (EK).

4.2.1.1 Internet Explorer access concerns

IE AutoComplete works under the premise that a particular Windows user account has complete logical access to the password database. Therefore, if an unauthorized user has logical access to the computer, and the account is logged in or it is not password protected, the attacker can abuse account privileges, and illegitimately use passwords. Logical access can be obtained by having physical presence (walking up to the computer) or by using remote access client (VNC, Remote Desktop, etc.).

Thus if there is no enforcement of physical access (such as separate rooms with locks, or a password protected login for screen savers) - anyone in the vicinity can walk up and use the manager to gain access to any website that the password manager allows. An untrustworthy person gaining access to anything from one's personal email to banking accounts is considerably disheartening.

Additionally, in cases where multiple people have the same logical user account (a poor security practice), problems are bound to arise with illegitimate use. The aforementioned situations assume close proximity and might be far flung for some; remote mechanisms of gaining access are addressed in later sections and are equally as potent with additional stealth capabilities.

4.2.2 Firefox 0.7-1.5 and 2.0

Storage Construct: Text File (signons.txt)
Format: ASCII, using Base64 encoding (except URL and fields)

URL (clear text, i.e. www.gmail.com)
Field name (in cleartext, e.g. username, email, userid, etc.)
Encrypted and Base64 encoded value of above information
Field name (i.e. password, pass, etc.)
Encrypted and Base64 encoded value of above information
...etc... (Could have many entries for one URL)
.
(Each URL entry ends with period on separate to line)

Encryption: TripleDES (CBC mode) [ref 16]
Access: Network Security Services (NSS) API [ref 17]
Requirements for Access: User logged in and the Master Password (if set) Relevant files: Certificates (Signed Public Keys) stored as certN.db, Private Key Database stored as keyN.db, and Security Modules stored as secmod.db [ref 18]

Note that files locations were previously addressed in section 4.1.

Firefox uses the Network Security Services API to perform its cryptographic operations. As it relates to the Password Manager Firefox makes use of Public Key Cryptography Standard (PKCS) #11 [ref 19] which defines an API for third party security modules that are either software or hardware based. It also uses PKCS#5 for password based encryption. [ref 19] Firefox also has an option of using an alternative security module for the password manager that is Federal Information Processing Standard (FIPS) 140-1 compliant. [ref 20] The Master Password is used in conjunction with a salt (found in the keyN.db file) is used to derive a Master Key. The Master Key is then in turn used to decrypt the usernames, passwords that are stored in the Password Manager.

The NSS API, although not easily tackled, has some vital functions that let Firefox or a related program to gain access to the password database. Setting the password is handled by (PK11_SetPasswordFunc), decoding base64 data (NSSBase64_DecodeBuffer), and decrypting (PK11SDR_Decrypt) allows a related program to access usernames and associated passwords; this is of course a simplified example. The real code would need to initialize NSS, declare variables, manage buffers and so forth. The security of the entire system, however, weights on the cryptographic strength of the Master Password (created by the user), and accessibility to the key3.db file (which contains the salt), and is stored in the user's profile.

The FIPS 140-1 security module can be enabled by navigating to the following location:

Firefox 1.5 on Windows:

Tools | Options | Advanced | Security Devices | NSS Internal FIPS PKCS #11

Firefox 2.0 on Windows:

Tools | Options | Advanced | Encryption | Security Devices | NSS Internal FIPS PKCS #11

5. Attacks on password managers

This section will look at several attacks against password managers. Two attacks will be discussed, and then we'll conclude part one of this article series. The second part of this article will continue the discussion.

A common technique to find all the avenues of penetrating a system is by using an attack tree. The goal in the attack tree shown below in Figure 1 is the complete compromise of the password database.

Figure 1. Attack Tree for the Firefox Password Manager.

The result of gaining access to the database enables the attacker to obtain all the URLs, usernames and passwords used as authentication for web sites. The use of the compromised password manager enables the attacker to access anything from e-mail, to the user's insurance, healthcare, banking, or possibly even corporate intranet information. A sub goal (not listed in the attack tree) would be to compromise the login credentials for a particular web site. It is often easier to take a piece of the pie (one login) rather than the whole (complete compromise). As such, both goals are covered.

A password management system is composed of application and user elements. To compromise the password database or a particular login it is only required to attack the weakest element in the system. In this case the weakest link is usually the user, no cryptographic attacks, or implementation of software is reviewed. Attacks are based on interfaces either between the user and password manager, or between the password manager and the web browser.

5.1 Browser independent JavaScript attacks

Two JavaScript attacks will be discussed in this section before concluding the article: a standard attack and one using Ajax.

5.1.1 Standard JavaScript attack

Assumption: Attacker has logical access to user account.

Attack Result: Attacker has the ability to navigate to a site that has a previously saved login and 1) gain access 2) use JavaScript to reveal username and passwords.

Collateral damage: The use of the disclosed password(s) for accessing the password manager, or other applications and web sites that use the same password.

Using JavaScript, is possible to reveal saved passwords on any site via the Document Object Model (DOM). When a user visits a website that has their username and password saved, the password is usually hidden through a series of asterisks (*) or bullets (●). This is what the user sees; the browser stores the actual ASCII password and submit it when the submit action is invoked. The use of asterisks and bullets is a good design in preventing shoulder surfing.

To work around this preventative measure, a clever attacker can either use JavaScript embedded into the HTML page, or run a script after the page loads, allowing the attacker to determine the relevant username and password.

Figure 2. JavaScript Document Object Model (traversal to the password object).

The JavaScript code for this is easily accessible online. [ref 21] It can be embedded in HTML, or run as a bookmarklet. A bookmarklet is a small JavaScript program that can be stored as a URL and run locally on a web page after it loads.

Using programming logic, an attacker iterates through all password-based elements (as shown in Figure 2) of the Document Object Model; the values that correspond to those password objects are then retrieved, subverting the use of asterisks as an obfuscation mechanism. Any person or program that has logical to the web client (IE or Firefox) can 'click' on a link and disclose the password.

javascript:( function(){          var s,F,j,f,i;           s = "";           F = document.forms;           for(j=0; j

5.1.2 Ajax password grabbing

Assumption: Attacker has access to a web proxy that is either transparent, or configured for the web client.

Attack Result: Attacker has the ability to insert, remove, or modify page content including JavaScript enabling username and password grabbing on any site that has HTTP connections (even if SSL submit is used at a later time).

Collateral damage: Potentially using the same login to access the computer system, and/or other applications and web sites that use the same username and passwords.

In the scenario shown below in Figure 4, we have a user that opens up a web browser and wants to access his banking information on a remote server. The client requests the main web page of his or her provider (such as. American Express). The company server responds, however information in the response is modified through a proxy server. Proxy servers are typically placed to protect the identification of Internet Protocol addresses, content filtering, and so forth; they act as an intermediary of communication between the client and server usually for well-intentioned purposes.

Figure 4. Ajax password grabbing.

Since the attacker controls the proxy, he can imbed JavaScript that reveals and sends the username and password through an asynchronous request to the server (XMLHttpRequest). The username and password can either be obtained through JavaScript mentioned earlier (the password manager auto-fills the login), or through a timing mechanism that waits a certain time (e.g. five seconds) allowing the user to enter the information, and then JavaScript runs subsequently sending the login credentials to the attacker. The illustration in Figure 4 shows the web browser requesting a XML file that contains the login information itself (bobpassword). The server will ignore the request because it is invalid, but the attacker has already gained the login credentials at this point.

It is important to differentiate the process that authenticates the user to the server and the separate malicious code that sends just the username and password to the attacker. On certain web sites, login information is entered before a SSL connection is established. That is the key point of attack, if there is an SSL connection established prior to entering login credentials the proxy server cannot see the encrypted traffic. Nevertheless some very prominent sites that use SSL submit (such as Yahoo, AMEX, and so on) establish encrypted authenticated connections only after the original page is loaded. They are vulnerable to this type of attack. Variations of this attack are likely to come up and possibly have one or more attack vectors.

It would be poignant to now compare various password manager security features in the two major browsers.

For the last entry in the above table, note that it is debatable as to whether this is truly a feature or a security vulnerability, however sometimes there is no method for retrieving a web site password once it is forgotten.

Concluding part one

Part one of this article lay the ground work for addressing issues with password managers, but in fact addressed only the first two points set out at the beginning of this article - notably, it explained the password storage mechanisms of both Internet Explorer and Firefox, and then presented two JavaScript attacks that can be used against these browsers.

Part two of this article looks at more attacks on password managers - starting with the new Reverse Cross-Site Request attack that was found in Firefox's Password Manager implemention. Commercial password recovery products, along with malware that tries to steal IE and Firefox passwords, will also be discussed.

The second part of this article also addresses several major points of discussion, such as the false sense of security these password managers give to a user, and some usability issues with the technology. Part two will also discusses defensive strategies useful for both browsers that can be implemented by both individual users and across an enterprise. It will be published on December 11th.

Complete references for part one

[ref 1] C, Galvin. "Firefox doubles market share as IE slips," 2005, The Register.co.uk, (Accessed February 2006).
[ref 2] MSDN "Using AutoComplete in HTML Forms," 2005, msdn.microsoft.com/library (Accessed March 2006)
[ref 3] "Mozilla Firebird 0.7 Release Notes", 2003, http://www.mozilla.com/firefox/releases/0.7.html, (Accessed March 2006)
[ref 4] R. Morris and K. Thomson. "Password Security: A Case History," in Communications of ACM, vol.22 no.11, 1979, pp 594 - 597,.
[ref 5] A. Blackwell, A. Grant, R. Anderson, and J. Yan. "Password Memorability and Security: Emperical Results", IEEE Security & Privacy, 2004, pp 25-31
[ref 6] S. Jeyaraman and U. Topkara. "Have the cake and eat it too - Infusing usability into text-password based authentication systems," in Proceedings of the 21st Annual Computer Security Applications Conference, 2005, pp.473-482.
[ref 7] Ives, B., Walsh, K. R., Schneider, H. (2004). "The domino effect of password reuse," in Communications of the ACM, 47, 2004 pp. 75-78.
[ref 8] E. W. Felten, A. Halderman and B. Waters. "A convenient method for securely managing passwords," in Proceedings of the 14th international conference on World Wide Web Chiba, Japan, 2005.
[ref 9] NIST. Federal information processing standard (FIPS) 140-1 Documentation: Security Policy. Windows NT Operating System, Microsoft DSS/Diffie-Hellman Enhanced Cryptographic Provider, 1994.
[ref 10] "Passwords in Internet Explorer 7," http://www.nirsoft.net/articles/ie7_passwords.html (Accessed November 2006)
[ref 11] MSDN: "PStore," http://msdn.microsoft.com/library/default.asp?url= /library/en-us/devnotes/winprog/pstore.asp (Accessed April 2006)
[ref 12] Komar, B. and Smith, B. Microsoft Windows Security Resource Kit, 2nd ed. Microsoft Press, 2005, pp.86
[ref 13] A. Hackworth, "Spyware," CERT Coordination Center, 2005.
[ref 14] MSDN (2001): Windows Data Protection. MSDN Online Library, msdn.microsoft.com/library.
[ref 15] "Recovering Internet Explorer Passwords: Theory and Practice" http://www.passcape.com/html/internet_explorer_passwords.html (Accessed Novermber 2006)
[ref 16] "Netscape Communicator Key Database Format", http://www.drh-consultancy.demon.co.uk/key3.html (Accessed March 4), 2006.
[ref 17] B. Relyea, "Network Security Services", mozilla.org, (Accessed March 4th 2006). Formerly known as Netscape Security Services.
[ref 18] I. McGreer, "Using the Security Module Database", mozilla.org. The security module database (secmod.db) manages PKCS#11 modules with operations such as adding and deleting , changing passwords, and so on.
[ref 19] NIST. FIPS PUB 140-1, Network Security Services Security Policy, maintenance NSS 3.2.2
[ref 20] F. Hecker, "Mozilla Crypto/PKI Support", http://www.hecker.org/mozilla/mozilla-crypto-pki.pdf
[ref 21] J. Ruderman, "Form Bookmarklets", squarefree.com, April 5, 2004.

About the author

Mikhael Felker is a graduate student of Information Security Policy and Management at Carnegie Mellon University.

Reprints or translations

Reprint or translation requests require prior approval from SecurityFocus.

© 2006 SecurityFocus

Comments?

Public comments for Infocus technical articles, as shown below, require technical merit to be published. General comments, article suggestions and feedback are encouraged but should be sent to the editorial team instead.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.