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)

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

© 2006 SecurityFocus

Comments?