Tag: security

Posted on
by

This post has a new edition.

Part #1 of the Data Liberation series

Although Google Chrome is a very fast browser, it lacks one key feature which seems designed to lock users in – any account migration facilities to support moving to other browsers.  This post is intended to help you move your saved passwords from Chrome to Firefox.

Firstly, you’ll need to have a read of this page: http://blog.catoblepa.org/2012/08/linux-how-to-export-google-chrome_28.html   – then come back here for more info!

While following the instructions in that post, take note of these steps below before you close your browser. If you have also set up a separate encryption password for your browser, don’t worry – this method still allows access.

  1. Image of Google Chrome settings
    Disconnect Google account in Settings

    In Chrome settings, as a precation, I disconnected my Google account before closing the browser. Therefore, any changes I could make to this temporary session wouldn’t ever be uploaded back to Google.

  2. Once you have the saved CSV file from Chrome, keep hold of it – we need to edit it. In Firefox, install the Password Exporter add-on: https://addons.mozilla.org/en-US/firefox/addon/password-exporter/?src=search
  3. Image of Password Exporter
    Exporting passwords

    Password Exporter allows you to import passwords too, so you can avoid the need to install any third-party workarounds like LastPass (which again require you to upload all your browser data).Firstly, though, using Password Exporter in Firefox (Tools > Add ons … Extensions > Password Exporter > Preferences), we can export a sample CSV file to see how Password Exporter expects its import data. Simply click “Export Passwords” and save the file to your home directory.

    NOTE: This requires that at least one password is saved in Firefox already.

  4. The headings in the exported file are as follows:

hostname username password formSubmitURL httpRealm usernameField passwordField

This is the format that Password Exporter will expect its import data.

The data’s headings that you have just exported from Chrome are a little different:

origin_url action_url username_element username_value password_element password_value submit_element signon_realm ssl_valid preferred date_created blacklisted_by_user scheme password_type possible_usernames times_used

We need to match up the firefox CSV headings with the corresponding Chrome CSV headings. To do this quickly, use a spreadsheet tool I used LibreOffice Calc.

This is what I arrived at:

(FF = Firefox; GC = Google Chrome)

FF: hostname username password formSubmitURL httpRealm usernameField passwordField
GC: origin_url username_value password_value action_url signon_realm username_element password_element

Once the fields are mapped, there’s a couple more important steps to undertake.

Export dialog
Export in the right format!

Firstly, when you come to exporting from your spreadsheet application, make sure you choose to edit the output filter. In the Export Text File dialog, make sure “Quote all text cells” does not have a check (tick) in the box.

For good measure, I also selected ASCII/US in encoding type,  as that is the format used by Password Exporter when exporting.   I think the importer should handle ISO-8859-1 and/or UTF-8, but your mileage may vary.

Now export it.

Remember seeing the additional header in the exported CSV file? It might have looked something like this:

# Generated by Password Exporter; Export format 1.1; Encrypted: false

In order to tell Password Exporter what format to expect its data in, this heading needs to be added back. However… the best way to do this is via a text editor, not in a spreadsheet program.

Open up GEdit, Emacs, Vi… whatever. Add that line to the top, but remove any trailing commas! It should now look like this:

# Generated by Password Exporter; Export format 1.0.4; Encrypted: false
"hostname","username","password","formSubmitURL","httpRealm","usernameField","passwordField"

One more step before you import!

A side-effect of exporting your CSV in LibreOffice is that empty cells are not quoted. In other words, the comma-separated values may appear like this:

"someusername","somepassword","someUrl",,"someusernameField"

Did you see those two commas with nothing between? The Password Exporter won’t like that when trying to import, so do a quick search-and-replace:

Search for ,, and replace with ,””,

Finally, save the file.  Again, ENSURE the file type is US/ASCII.

The importer dialog
Successfully importing passwords!

Now open up the Password Exporter dialog from Firefox and click Import Passwords – you should see progress in the dialog shortly.

CAVEAT #1: BUG WHEN IMPORTING v1.2-EXPORTED DATA

There is an import bug when the version header is declared as 1.1. However, you can get around this by “fudging” the import header to an older version (I used 1.0.4). If you have trouble importing, adjust your header in the file to look like this:

"hostname","username","password","formSubmitURL","httpRealm","usernameField","passwordField"

After importing, you may see that not all passwords were imported. This is because duplicates are not imported. You can view the details in the link.

CAVEAT #2: SOME LOGINS, PASSWORDS, ETC ARE QUOTED

So far I’ve not had time to find a way around this. It’s to do with the import format.

The adventurous can investigate the source code, here: https://github.com/fligtar/password-exporter/blob/master/passwordexporter/chrome/content/pwdex-loginmanager.js

Hopefully you have now successfully liberated your passwords!

Problems?  Comment below!

Posted on
by

I was recently asked to explain the difference between setting permissions on a directory to either 755 or 751.
In 751 mode, a user who isn’t the owner and isn’t in the group assigned to that directory can still execute anything within that directory, provided they know the name of the executable file.  They are unable to browse the contents of that directory to find the name.  Therefore, 751 is inherently more secure than 755.

The funky, geeky bit

For reference, each number of 7 5 1 is an octal representation of the number of permission bits set on the file/folder.  There are 3 bits per field.  
Taking the 7, from 751, this means all bits are set to 1.  This is how it works (think of it like a lookup table):
meaning:     r   w   x    (read, write, execute)
bit value:   4   2   1    (< - this is  the octal lookup bit)
bit set to:  1   1   1    == 4 + 2 + 1 == 7.
If you take the value 5, then this is how that’s set in the bit fields:
bit set to:  1   0   1      == 4 + 0 + 1 == 5.
Remember, there are three fields!  So each field – the “owner”, “group” and “others” fields – contains the sum of permission bits set for that field.  The “751” is actually a nice, easy way to see permissions.  The actual permissions set in a 751 situation are, in binary “nibbles”, 0111, 0101 and 0001. 

Demo – try it yourself!

As root, set up a test dir in /tmp/ called test, with 751 perms.  Then create a file within that called hello.sh which simply outputs “hello” on the command line when executed.  To achieve that, simply do this (as root, remember):

# mkdir /tmp/test

# touch /tmp/test/hello.sh

# chmod +x /tmp/test/hello.sh

Then edit /tmp/test/hello.sh and put these two lines in:
#!/bin/sh

echo Hello
/tmp/test is owned by root (rwx / 7) , has the root group (r-x / 5) and the "world" just has execute (--x / 1).  When using your own user account, trying to do a # ls /tmp/test - should tell you that permission was denied.  

However, you should be able to do # /tmp/test/hello.sh which outputs "Hello" as expected.  

If you bump that world permission to r-x / 5, you would be able to see that file because ls has the necessary permission to read the directory contents.

Posted on
by

Google is undoubtedly suffering from some adverse PR in respect of its new privacy policy.  While it may have considered itself on to a PR “winner” with its “privacy made simple” approach, there has been considerable backlash in opinion and re-consideration of the use of its services.

So, what could Google do to demonstrate that it still takes on-line security seriously?

How about setting up its own Certificate Authority, and issuing free SSL certificates?

Google has the infrastructure, manpower and, I’d argue, interest in doing such a thing.  In fact, in many ways, it already offers the flesh around this missing skeleton.

Perhaps it could support the CACert effort with funding and enough energy to get it through the audits required to have their root certificate included in Mozilla’s Firefox, as-shipped?  And, while Google are at it (restoring their image of benevolence, that is), they could include that root certificate in Chrome too.

Just saying…

Posted on
by

Scammers rely on your ignorance in order to fool you into clicking on their link and typically entering your bank details.

Don’t let them! 

DISCLAIMER:  DO NOT TRY TO VISIT THE EXAMPLE SCAM LINK GIVEN IN THIS POST.  YOU ALONE ARE RESPONSIBLE FOR YOUR ACTIONS.

When you receive a link in an email, you should analyse that link to determine the authenticity and legitimacy of that link, before you click on it.

I was recently forwarded a scam email to analyse.  If you have recently received a suspicious email with a link, here’s how to analyse that link.

Firstly, hover the mouse pointer over that link.  At the bottom of your email window (commonly called the status bar), you should see a web address appear.

In this example, a link was received purporting to be from the UK bank Cahoot.  But the link address is suspicious – so let’s analyse it…

http://ip270-c6.gi.digl.pl:8887/securebank.cahoot.com/servlet/com.aquariussecurity.bks.security.authentication.servlet.LoginEntryServletBKS/

… the bit in bold is what you’re interested in.  The rest is not really of interest.  However, when you come to inspect a link in the future, it’s worth knowing the following:

How to analyse a link in Thunderbird
(click for larger image)
  • http://

    This means the protocol that your browser will use.  A secure, encrypted browser connection begins https:// ; therefore, the link above will be unencrypted (not secure) between your computer and the server.  This is a tell-tale sign that it’s trouble.

  • ip270-c6.gl.digl.pl

    This is the domain name, like “bbc.co.uk“, “fedoraproject.org” and “google.com“.  This is the most important bit.  The best way to read this is actually from right to left.  The most right hand part, “pl“, is the top-level domain (TLD).  pl is the TLD for Poland.  tw is the TLD for Taiwan.  ru = Russia.  And so on.  For reference, you can find a list of TLDs here: http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

    The next two bits should really indicate the organisation of the originating email.  digl is meaningless; it’s been made up by a scammer to probably infer “digital” or something like that.  Likewise, gl is also meaningless.

    A meaningful alternative would be cahoot.co.uk, as it is registered with a UK TLD and represents the claimed originator of the message.

  • :8887

    The last bit of this link is what’s called a port number.  The (optional) use of this by scammers is again a visual distraction which makes it harder to read the real web address.  Apart from the fact that no bank would ever request your details by email anyway, if they were credible they most certainly wouldn’t use a web address with a non-standard port number.

    The best thing to do when reading an address is to ignore the port number but be aware of the fact that it’s been used. 

For more information, check out this PDF on avoiding email scams.

And for those who were paying attention and spotted the deliberate mistake, well done! 🙂

Enhanced by Zemanta

Posted on
by

Today is Document Freedom Day. To celebrate, many of us open source netizens are doing the right thing and rejecting email attachments sent in proprietary formats, such as Microsoft Word, Excel and Access – 95, 97-2003 and so on.

The campaign is quite simple: refuse locked-in file formats.

The Free Software Foundation has provided some interesting examples of “polite” rejections to send to people who have emailed an attachment with a proprietary file format.

It’s a difficult thing, to tell someone that you are rejecting their attachment through choice.  You fear that it comes across as being awkward.  Breaking the social “norm” and standing for something you believe in is rarely painless.

There are ways to deal with this though, and the best way is probably humour.  It’s a serious message, yes, but that doesn’t mean it has to be all haughty overtones and morally correct principles shoved in people’s faces.  Making it funny will make it stick just as well.

Here are a few of my suggestions for handling your email rejections with a bit of added spice.  It’s a safe assumption that your friend uses Microsoft Office, so you could include this link at the end (http://www.sun.com/software/star/odf_plugin/get.jsp):

  • “Thanks for your email attachment.  Unfortunately, my dog ate it. He likes anything that is completely unpalatable, especially proprietary file formats.  He doesn’t seem bothered at all with open standards formats like the ODF, though.  Could you re-send your file using that format please? “

 

  • “Thanks for the document.  Sadly, we do not use proprietary file formats any more as the internet has brought about a revolution in open document format usage.  It happened so quickly that no-one noticed!! Please could you re-send your file in Open Document Format (ODF)?..”
  • “Thanks for the information. Regrettably, I am unable to open this format of document because I have become enlightened.  In my new karmic state, I only desire peace and harmony, and closed-off formats disrupt my inner sanctum.  Please could you re-send this file in natural, organic and eco-friendly Open Document Format?”

 

And of course, you MUST MUST MUST include a link to the Document Freedom Day web site, or to the Free Software Foundation, or to the Electronic Frontier Foundation, or to the Open Rights Group, or …

Links:

Thanks for watching!

Posted on
by

I recently found myself having the need to revoke an old certificate. The steps are actually quite straightforward, but you do need to have your old revocation certificate to hand.

For more info, visit the GNU Privacy Guard site: http://www.gnupg.org/gph/en/manual.html

Simple follow these steps. In a terminal, issue:

  • gpg –import my-old-key@mydomain.com (0x712AC328) rev.asc
  • gpg –keyserver certserver.pgp.com –send-key 712AC328

That’s it!