Gmail security? Well at least start with customizegoogle

I’ve been looking around certain Gmail topics, including how to wipe out everything from your Inbox (I will talk about that in my next post) and one of the things I was interested in was ’security’.

If you are a gmail user and you are a firefox user, then consider taking a look at customizegoogle.com

I’m not affiliated with that site by any means, and I dislike the fact that it looks more commercial than good, but the reality is that along with their promises of being spyware-free, it really does a good job when it comes to protecting your communication with gmail.

Included with that firefox plugin are lots of other features, such as disabling google ads while you search @ google or while you’re inside gmail. But the one I care the most is a feature that forces SSL everytime you surf your mail @ gmail.

Why do you need that? Simple. Head your browser to www.gmail.com - you will find that you are automatically redirected to the SECURE version, yes. However, the point of that is for protecting your username and password while logging in (otherwise it would be sent in plaintext through the network)

The problem starts right after you have logged in. You will notice that you’re no longer in a secure version under SSL but rather back to the standard http:// protocol. You can switch back to the secure version manually, that is, by modifying the Url and adding that extra ’s’ after http, making it https:// - However once is ok, twice.. fine, but three times, or every single time you log into gmail remembering to switch back to the secure version is a freaking pain in the behind. Not to mention that once you’ve realized you are in the insecure version, your e-mail headers (that e-mail list with extracts from the e-mails you received) have already been sent plaintext to you.

If you add to that my other post where I mention FireGPG and GPG4Win (http://www.penetrationtests.com/blog/2008/05/07/it-looks-like-the-gpgfirefoxwindowsgmail-puzzle-is-solved/) then you have plenty of security added to the default gmail package.

Check it out, it’s worth it!

Good luck.

 

Posted in Hardening, Tools on 05/29/2008 07:15 am by Consultant
 

Protecting/Encrypting sensitive data with Winzip

I just found this somewhat excellent article on Winzip encryption by Dave Whitelegg who took the job of analyzing the different types of encryption provided by Winzip and proceeded to test them out to see how efficient they really are in real-world usage.

The url of the article is the following:

http://blog.itsecurityexpert.co.uk/2008/01/winzip-encryption-password-security.html

I fully recommend going through the entire article. The question on whether using Winzip encryption is fair or not tends to come up when talking about deliverables. If you have to send a series of deliverables that carry sensitive information (a draft or final report, slides, anything) to a client who doesn’t really use pgp/gpg nor any kind of secure communication channel, then you’re looking at either crafting a self-decrypting archive through PGP Desktop, some other option, or using Winzip encryption.

The article discusses what you need to be aware of, if you are planning on going for Winzip encryption.

Basically the main points are:

  • Don’t use Winzip encryption prior to Winzip version 9. Earlier versions carried a home-grown implementation that was broken several times.
  • Use AES, and go for the key-size of your will (the bigger the better you could say)
  • Your password NEEDS TO BE (and don’t break any of these rules, cause that’s what makes the protection strong):
    • At least 12 characters in length
    • Be random not contain any dictionary, common words or names
    • At least one Upper Case Character
    • Have at least one Lower Case Character
    • Have at least one Numeric Character
    • Have at least one Special Character e.g. $,£,*,%,&,!
  •  Even if a file is protected/encrypted, Winzip permits you to browse around the directory structure, having access to the names of the encrypted files. Therefore it wouldn’t make sense to protect your super-secret client in bananas.zip if inside you’re going to find Report - Super Secret Client Name here - 2008.pdf

And that’s it. I guess one final comment would be that Winzip is not free. Have that in mind, we’re talking about a commercial application here.

Enjoy your day!

Posted in Hardening, Tools on 01/24/2008 05:15 am by Consultant
 

Disabling binaries in shared hosting scenarios

This a quick note and probably offtopic, probably not. But if you ever have a server dedicated to hosting multiple clients - you’ll want to remember this. It is very common for clients to install buggy software that ends up posing a threat to your hosting server. Either because a new vulnerability was disclosed and is unpatched, or simply because the installed software lacks any security at all.

As a result, one or more of your clients get hacked by worms. Worms tend to use the following commands while exploiting vulnerable software in order to download large pieces of payload that later get executed in order to mess things up even more. So we could say there’s stage 1 when the script gets hacked and let’s say a ‘command injection’ vulnerability is exploited, and stage 2 when the first small exploit downloads and executed the real thing, the malicious payload.

If you get to stage 2, then you’re lucky or in a big problem (start identifying the damage) - but the idea is to prevent one or more stage 2 situations. You don’t end up fixing a vulnerable script, no, but at least you lower the impact of the first automatic exploit.

The binaries that I tend to chmod to null (000)  and by experience (ouch!) used by worms are:

  • wget
  • curl
  • lpdownload
  • GET
  • links
  • lynx

It *really* helps prevent large disasters.  By NO MEANS this is the solution, no, but just a tip for webmasters.

Enjoy!

Posted in Hardening on 01/03/2008 04:00 pm by Consultant
  •  
 
   
  • © 2009 penetrationtests.com