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.

Heartbleed’ing – what do I do?

With the Heartbleed bug in the news recently, a lot of folks have asked me for advice on what to do.

First off, here’s a quick description of what Heartbleed is:

Wikipedia states: Heartbleed is a security bug in the open-source OpenSSL cryptography library, which is widely used to implement the Internet’s Transport Layer Security (TLS) protocol. This vulnerability, classified as a buffer over-read, results from a missing bounds check in the handling of the Transport Layer Security (TLS) heartbeat extension, the heartbeat being behind the bug’s name.

In plain(er) English – this means that websites that use a certain version of encryption (aka OpenSSL), are vulnerable to sharing encrypted information with anyone who queries the website in a certain way. A website’s address that starts with https:// (note the “s”) use SSL to encrypt the transaction of data back and forth between the website and your browser.

To find out if a website is affected, you can use a bunch of different tools to check the version of OpenSSL used by a website. The easiest one that I’ve come across is LastPass’s Heartbleed checker available here.

When you plug-in a website it will tell you if the website uses OpenSSL & if so, if it’s safe to use the website or not. Here’s a screenshot of what the checker tells you about yahoo.com:

As you can see, LastPass says that Yahoo used to use the problematic OpenSSL but has since fixed it on their website and that it’s now time to change any Yahoo passwords that you may have.

If a website hasn’t updated their OpenSSL to a fixed version, there’s really no point in changing your password – I would recommend minimizing or ideally not using the website until it has been fixed. If possible, contact the website & tell them that you are not using their website until they get it fixed.

Hope this information helps explain what Heartbleed is & what to do about it – stay safe!

~Yosef

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.

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

Note: This is an update to my original article

With the release of IE10, Microsoft has changed how Internet Explorer stores passwords. Previously, for versions IE7 through IE9, the browser would store auto-completed passwords in the registry and
HTTP basic authentication passwords in the Windows Credentials Store (aka Vault). As a refresher: Auto-complete passwords are normal website login passwords such as gmail, Facebook, LinkedIn, etc. HTTP basic authentication passwords are network login passwords for LANs, etc.

The encryption method that IE7-IE9 used for storing auto-complete passwords was very difficult to defeat, whereas the Credentials Store was much easier to break into to recover passwords. Therefore I was very surprised to learn that in IE10, Microsoft now stores ALL passwords in the Windows Credentials Store – with no new security measures!

The Windows Credentials Store is only protected with the regular DPAPI, and can be (relatively) easily cracked. All private entries of a user can be found in his profile. By default, the folder
is in:
C:\Users\<USER NAME>\AppData\Local\Microsoft\Vault\<VAULT_UID>
where
<USER NAME> = user name &
<VAULT_UID> = Vault identifier. By default, the value is: 4BF4C442-9B8A-41A0-B380-DD4A704DDB28.

Each IE10 password entry is in a .vcrd (Vault Credential) file and the encryption key is stored in the same folder.

This moves IE10 into the same league as Google Chrome leaving Mozilla Firefox as the leader in terms of password security (providing you enable a strong Master password).

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.