Editing Mozilla Firefox Container URLs

I really like Mozilla Firefox’s container system that’s been out for around a year now. There’s one issue though that’s bothered me on a daily basis and really annoyed me, I just never took the time until now to track down the fix for it. Hope this helps someone else!

I’m assuming that you use Mozilla’s Firefox browser and have already setup container groups and assigned specific websites to always open in container tabs. My issue was, I couldn’t figure out how to edit a URL once I set it up.

Well today I spent 10 minutes & figured out where Firefox stores the file that controls these URLs so you can manually edit them. The file is called storage.js and is stored in your Firefox profile which is typically in your user profile’s AppData folder (reachable at %AppData%). For me, this file is stored in:

%AppData%\Roaming\Mozilla\Firefox\Profiles\<PROFILE NAME>\browser-extension-data\@testpilot-containers

Before editing the file, close Firefox. You can open the file in any basic text editor (I personally use Notepad++ but regular Notepad works too) do a quick search for the offending URL and update it to the URL you want it to be, then restart Firefox and your URL should now redirect properly to the correct container group.

Note that the URL is only the top level domain. E.g. you can change outlook.login.com to live.login.com, however you don’t need to specify https://www before the domain name.

Increase your Firefox Productivity using about:config settings

My browser of preference is Firefox for many different reasons: Security, add-ons and customizability. Today’s post will focus on one of the lesser known aspects of Firefox’s customizability – the “about:config” settings.

To get to these settings, open a new tab in Firefox, type “about:config” into the URL bar (also called the “Awesomebar” in Firefox lingo) and load the page (hit Enter).

At the “This might void your warranty!” page – click the “I’ll be careful, I promise!” button. This will take you to a humongous list of undocumented settings. In addition to the ones listed – you can even create & add your own!

Disclaimer: You can easily break Firefox by changing settings that you don’t understand. Please reference the comprehensive list of about:config options here: http://kb.mozillazine.org/About:config_entries

This list is the basic list of settings that I immediately change/create whenever I setup a new instance of Firefox. All of them help me browse the web faster and/or safer.

Faster tips:

1: Disable the Delay When Installing New Extensions

When you install a new extension in Firefox, there is a countdown of 5 seconds delay before you can install the add-on. To regain those 5 seconds of your life, in the “Search” field on the about:config screen, search for security.dialog_enable_delay and set the value to “0”.

2: Don’t Close Firefox after Last Tab is Closed

One of my pet peeves in Firefox is that by default, it will close the entire program if you close the last tab. To stop this behavior, set the browser.tabs.closeWindowWithLastTab setting to “False”.

3: Open Search Results in a New Tab

If you use the default search box in Firefox (I actually disable mine & just search from the Awesomebar), you can force Firefox to open search results in a new tab so that it does not override the page you’re currently viewing.

To do so, search for browser.search.openintab and double-click the setting to change it to “True”.

4: Force Spell Checking in all Text Boxes

By default, Firefox only spell checks words that are typed in multi-line text boxes. To force Firefox to spell check words in all text boxes, search for layout.spellcheckDefault and set the value to “2”.

5: Preview Tabs

In Windows you can cycle through open programs using the “Alt”+”Tab” keys. In Firefox you can do the same thing with “Ctrl”+”Tab”. To preview a tab before viewing, set the browser.ctrlTab.previews setting to “True”. (Note: This only seems to work if you have 3+ tabs open, 2 tabs just switches without previews.)

Safer tips:

1: Show “http” in the Awesomebar

By default, Firefox cleans up the URL displayed in the Awesomebar. This makes it difficult to ensure that you’re on a https (secured) vs. http (unsecured) website. To show the http(s) section of a URL, set the browser.urlbar.trimURLs setting to False.

2: Turn off Geo-Location

Firefox is pretty good about alerting you when a website wants to know your location – if you’re like me & don’t want ANY websites tracking your location, you can force Firefox to never report (or annoy you by asking to report) your location to a website by setting the geo.enabled setting to “False”.

3: Set encryption preferences

When you connect to an “https” secure website, the server has a list of different types of encryption protocols and ciphers that it can handle. The server also “prefers” certain ones over others.

These preferences are set by the server admin and may be set to “prefer” a lower form of encryption for many reasons. They may want less powerful encryption to lower processing overhead on the server, or they may not understand what they are doing when they set it up, etc.

You can force Firefox to only use certain protocols and ciphers, however certain websites may fail to load in which case you will need to determine what type of encryption they allow and then turn that type back on. (See my articles on HTTPS Protocols and Ciphers and HTTPS Protocols and Ciphers Continued for more information).

Search for each of the following settings & modify every setting that’s returned as follows:

• tls Set all Boolean lines to “True”
• ssl2 Set all Boolean lines to “False” (Note: Newer versions of Firefox will not even list any ssl2 options.)
• ssl3 Set all Boolean lines to “False” EXCEPT lines that contain “aes_128” or “aes_256”. The AES encryption algorithm is much stronger than the RSA or RC4 ciphers.
• EXCEPTION: “security.ssl3.rsa_des_ede3_sha” Initially set this setting to “False” – however, this is the weakest cipher and may be needed for some older SSL sites so if you find certain sites are not working, this is probably the culprit – try setting this back to “True”.

HTTPS Protocols and Ciphers Continued

Yesterday I introduced you to HTTPS protocols and ciphers. Today we will focus on:

Which protocols and ciphers are (currently) best to use?

There are two types of protocols, SSL & TLS (SSLLabs checks both types).

SSL

• SSL 1.0 was never publicly released
• SSL 2.0 is considered insecure at this point
• SSL 3.0 is considered generally secure but highly depends on which cipher it’s using as well as if the browser protects against what’s known as “BEAST” (Browser Exploit Against SSL/TLS) attacks.

TLS

• TLS 1.0, like SSL 3.0 is considered generally secure but highly depends on which cipher it’s using as well as if the browser protects against BEAST attacks. In addition, TLS 1.0 allows for interoperability between TLS 1.0 & SSL 3.0, however this weakens the protection provided by TLS 1.0 and is not advised.
• TLS 1.1 is generally considered secure depending on the cipher used.
• TLS 1.2 is considered an enhanced version of TLS 1.1 and is again, secure depending on the cipher used.

So which ciphers are best?

Unfortunately, this is dependent on which protocol you are using. In general, all ciphers used with TLS 1.2 are secure except for RC4 (which is never considered secure, regardless of protocol). The main ciphers are as follows:

• AES CBC – secure when used with TLS 1.1 & TLS 1.2. Secure with TLS 1.0 depending on the browser used.
• AES CCM – secure when used with TLS 1.2
• AES GCM – secure when used with TLS 1.2
• 3DES CBC – secure when used with TLS 1.1 & TLS 1.2. Secure with TLS 1.0 & SSL 3.0 depending on the browser used. Insecure when used with SSL 2.0
• Camellia CBC – secure when used with TLS 1.2
• Camellia GCM – secure when used with TLS 1.2
• IDEA CBC – Secure when used with TLS 1.1, Secure with TLS 1.0 & SSL 3.0 depending on the browser used. Insecure when used with SSL 2.0
• DES CBC – Insecure with all protocols
• RC4 – Insecure with all protocols
• RC2 CBC – Insecure with all protocols

Once you know what type of protocol and cipher you need in order to connect to a website:

How do you change your browser to allow/disallow certain types?

I will focus on Mozilla Firefox, my browser of choice. Google Chrome & Internet Explorer allow you to change which protocols they use but you can’t specify the exact cipher.

In Firefox, you can allow / disallow specific protocols and ciphers by going to “about:config” in your URL “Amazingbar” (hit Enter).

Click the “I’ll be careful, I promise!” button to access the settings.

In the Search field, search for “ssl3” to view all SSL 3.0 options. You can double-click on each one to turn it on (TRUE) or off (FALSE).

To set your TLS settings, search for “tls”.

You will see two available settings that allow a range of 0 to 3:

• security.tls.version.min – specifies the minimum required/supported protocol version
• security.tls.version.max – specifies the maximum required/supported protocol version

For example, a min/max of 0 means that the minimum/maximum supported encryption protocol is SSL 3.0. A 1 indicates TLS 1.0, etc.

For more information, see the following article as a starting place: Wikipedia: Transport Layer Security

Questions/feedback? let me know in the comments below. Thanks!

HTTPS Protocols and Ciphers

To give a bit of background on this post –

I was researching different Firefox about:config settings for another article (to be forthcoming) and had changed a bunch of security settings to try and force Firefox to use higher grade encryption when accessing encrypted (HTTPS) websites.

Later in the day, I tried to access a website I visit very frequently and found that it wouldn’t load. I eventually realized that it must be because I had changed my Firefox security settings. The question I was stuck with was, “How do I figure out what encryption protocol and cipher a website is using in order to allow that encryption in Firefox?”. After some more research I was left with the following:

What is HTTPS & how does it work?

When you access a website, you are typically communicating over one of two protocols: HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol Secure (HTTPS). When you connect using HTTPS, all the information sent back and forth between you and the website is encrypted.

There are of course exceptions to this – for example, on your bank’s website, it may have a secure component for logging into the website but it may also have a third party advertisement that is not delivered encrypted to your browser. Depending on your browser, it may alert you when there is “mixed” content being loaded.

At a high level, when you access an HTTPS website, the server has a list of approved protocols and ciphers that it will allow communications to be encrypted with. This list is either the default list that the server comes enabled with (i.e. no one really thought about it, they just turned it on), or it’s a customized list that (hopefully) only allows the latest and greatest encryption methods.

Just like the server, your browser has a list of approved protocols and ciphers that it can use. When your browser contacts the server to load the HTTPS page, the server gives it a list of the approved encryption methods – this list is prioritized by the server’s “preference”.

Assuming your browser allows connections using one of the approved server’s methods, the browser and server conduct a “handshake” where the encryption method and a key are agreed upon and exchanged, allowing both the server & the browser to encrypt and decrypt communications between them. When the “handshake” is conducted, it is the most dangerous part of the communications process because it is done without encryption and (if done improperly) can allow for “man in the middle” (MITM) attacks or other attacks by an outside party. (I hope to cover different types of attacks and how they work in a future article.)

So what’s the difference between a protocol and a cipher? Think of encryption protocols as the method by which information is encapsulated and sent whereas ciphers are the way which information inside the capsule is scrambled (encrypted) to prevent anyone from reading the information.

Determining a Server’s allowed Protocols and Ciphers

This leads us back to my original question – if your browser does not accept the encryption types allowed by the server, how do you figure out which ones you need?

I found that there is a very handy website called http://www.ssllabs.com that has a SSL Server Test tool (available here: SSL Server Test) that allows you to plug in any website and it will determine if there are any available HTTPS connections to that website as well as give you a high level score and a very detailed breakdown of the site’s security protocols and ciphers.

There is also a Firefox plug-in available (called CipherFox) to give you this information every time you visit a website.

Tomorrow I will cover which Protocols and Ciphers are best to use & how to implement them in your Firefox browser.

Got questions or feedback? let me know in the comments below. Thanks!

Browser Search Tools

In addition to the search engine tips I posted about yesterday, here are some browser specific tips for speeding up your searches on an individual page:

Finding Words on a Page
Suppose I want to find out if Jabian is in the S&P 100. I navigate to Wikipedia & look up the S&P 100 list of companies. Instead of scanning through the entire list (and possibly missing an entry) I can use the built in search (find) function in my browser. In Firefox & Internet Explorer, press the “Ctrl” button in conjunction with the “F” Button (Ctrl+F).

This will bring up a search box in the browser where you can search (see area highlighted in pink in the picture above). As you can see, Jabian is not (yet) in the S&P 100.

Searching from the Address Bar

Did you know that instead of navigating to Google (or Bing, or whatever your favorite search engine is) – you can type your search criteria directly into the address bar of your browser? Firefox & Chrome default to Google while Internet Explorer defaults to Bing. You can usually change the default search engine in your browser’s options menu.

Type your query into the address bar & hit enter to load.

Your results will be automatically sent & loaded in your default search engine.

Think your browser hotkeys are safe? Think again…

Great article on how a hacker can use simple javascript to trick you into giving up your passwords. Become a Security “Thinker” and don’t fall for these tricks!

ArsTechnica: How script kiddies can hijack your browser to steal your password

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 5 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.
Part 3 of this series may be found here.
Part 4 of this series may be found here.

Safari

I must admit, I was pretty surprised by how hidden Apple made their security information. After years of hearing how horrible Safari is in terms of general security – their password security is actually pretty decent. unfortunately, it too is able to be hacked if you know what you’re doing.

Safari stores your usernames and passwords in a file called “keychain.plist” in the following folders:

Windows XP:
C:\Documents and Settings\[username]\Application Data\Apple Computer\Preferences

Windows Vista\7]
C:\Users\[username]\AppData\Roaming\Apple Computer\Preferences

Sorry Mac users, I don’t know where this is stored on a Mac… If someone wants to give me a Mac, I’ll be more than happy to research it for them… 🙂

The contents of this file are pseudo-encrypted because it’s stored in a “Binary Property List” file format which is an Apple format for storing binary data. If you just open the file it will look like garbage. However, Apple provides a tool called plutil.exe that can read this format and it’s actually provided with Safari in the following folders:

Windows x86:
C:\Program Files\Common Files\Apple\Apple Application Support

Windows x64:
C:\Program Files (x86)\Common Files\Apple\Apple Application Support

Run this program in DOS using the following commands:

plutil.exe -convert xml1 -s -o [Output Path\output_file.xml] [Path to keychain.plist file]

This will convert the .plist file into an XML file. In the XML file, everything will be decoded except for your password which will be inside an tag called

The encrypted password is encoded using the BASE64 algorithm. Bizarrely enough, the original password data stored in the keychain.plist file is not encoded with BASE64. It is only encrypted to BASE64 when converting the .plist file into XML using the plutil program. In the .plist file, the password is encrypted using standard Windows Data Protection (DPAPI), which provides the known functions of CryptProtectData and CryptUnprotectData for encrypting / decrypting of data using your Windows authentication password. When using CryptProtectData, Safari uses a standard, static salt for all passwords which is also stored in the keychain.plist file.

So to actually decode the XML file, you must first decrypt the BASE64 encrypted data, then decrypt the Windows DPAPI encrypted data. Easy right?

BASE64 encryption can easily be broken with free code available online. From there, you need to figure out the salt to use with the Windows DPAPI CryptUnprotectData function.

For the curious, the salt generation algorithm and decryption functions are available in the Apple supplied CFNetwork.dll file which can be found in the following folders:

Windows x86:
C:\Program Files\Common Files\Apple\Apple Application Support

Windows x64:
C:\Program Files (x86)\Common Files\Apple\Apple Application Support

The salt data in the .plist file is 144 bytes long and ends with “com.apple.Safari”. Once you find the Salt in the .plist file, you can easily decrypt the passwords using the CryptUnprotectData function (available on the Microsoft MSDN website).

As you can see, Safari is much more complicated than other browsers but in the end, it’s just as easy for someone who knows what they are doing to hack.

Summary

I think that all the browsers fall short in one area or another. Firefox comes the closest but only if you enable a Master Password. IE9 has good security for Autocomplete data, but only if you do not store website history. Chrome fails in terms of protecting your usernames and passwords from any key loggers. Opera fails completely because it uses a known, static salt. Safari surprisingly enough provides decent security from someone who doesn’t know what they are doing but a true hacker should be able to decrypt your passwords with some patience.

My recommendation? Use Firefox, keep it updated and enable a strong Master Password. Again, I refer you to check out XKCD’s Password Strength cartoon for tips.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 4 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.
Part 3 of this series may be found here.

Opera 10 and above

Opera stores the following information in an encrypted file called wand.dat:

• Login URL
• Main website URL
• Username field ID
• Username
• Password field ID
• Password

The wand file stores the data in encrypted blocks consisting of the following fields:

• Size of encrypted block (4 bytes)
• DES Key Length (1 byte)
• DES Key (8 bytes)
• Size of encrypted data (4 bytes)
• Encrypted data

Wand.dat is stored locally on your computer in the following locations:

Windows XP:
C:\Documents and Settings\[username]\Application Data\Opera\Opera\wand.dat

Windows Vista\Windows 7:
C:\users\[username]\AppData\Roaming\Opera\Opera\wand.dat 

The issue with Opera’s security is that it uses a static salt to encrypt the data. The salt is:

0x83, 0x7D, 0xFC, 0x0F, 0x8E, 0xB3, 0xE8, 0x69, 0x73, 0xAF, 0xFF.

To decrypt the data, a hacker simply retrieves the DES key (8 bytes) from each encrypted block of data in the wand file. They then compute the MD5 checksum of the byte stream consisting of the salt and the retrieved DES key. Next, compute another MD5 checksum of the byte stream consisting of the first MD5 checksum, the original salt and original DES key (in order). These two MD5 checksums are used to create schedule keys for decryption with a DES vector component comprised from the second MD5 checksum. Finally, the data can be decrypted using the known Triple DES decryption function. The decrypted data will be stored in Unicode but you can easily convert it into ascii.

End result – a hacker only needs a copy of your wand.dat file to easily decrypt all your usernames and passwords.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 3 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.

Firefox

Firefox by default has lousy security. However, if you enable the Master Password option (off by default), Firefox has the most secure security… go figure.

Firefox stores usernames and passwords in a SQLite database called signons.sqlite which can be found in the following folders:

Windows XP:
C:\Documents and Settings\[user_name]\Application Data\Mozilla\Firefox\Profiles\[random_name].default

Windows Vista\7:
C:\Users\[user_name]\AppData\Roaming\Mozilla\Firefox\Profiles\[random_name].default

In the SQLite database, the username and password are encrypted using Triple DES and BASE64 encryption algorithms. The decryption hash is stored in a file called key3.db in the same folder structure. By default, if a master password is not set, Firefox will allow any user to open up the signons.sqlite and key3.db files to view the usernames and passwords directly in the browser, no questions asked. As long as someone has a copy of the two files, they can transfer them to any machine and view the data.

However, if the Master Password is set, then Firefox will store a one way hash in the key3.db file and require you to input the password to generate a matching hash in order to decrypt the signons.sqlite database. Without the Master Password, no one can decrypt the data. Therefore, your data is as secure as your Master Password. Without it, there’s virtually no security on your data.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 2 of 5

Part 1 of this series may be found here.

Chrome

Chrome’s encryption in theory is great so long as you can ensure that there is no malware running on your computer. Considering the latest exploits of the Stuxnet and Flame viruses, I think it’s pretty obvious that cannot always be assured. Chrome stores usernames and passwords in a SQLite database called Login Data located in the following locations:

Windows XP:
C:\Documents and Settings\[username]\Local Settings\Application Data\Google\Chrome\User Data\Default 
	
Windows Vista\7:
C:\Users\[username]\Appdata\Local\Google\Chrome\User Data\Default

In the database, the only field which is encrypted is the actual password, URLs and usernames are not. The encryption used is the Triple DES algorithm using the Windows user’s login password as a seed. This allows only someone logged into that username / password combo on the computer to view the passwords. However, it cannot prevent any malware running on the system from stealing that user’s passwords.