The Heartbleed Vulnerability Panic?

 Computing, Security  No Responses »
Apr 092014
 

The interwebs are all a flutter over the latest vulnerability announcement – an OpenSSL vulnerability that has been termed the heartbleed vulnerability. But is it that serious? And what is it anyway?

What Is It?

OpenSSL is a very widely used software component that adds encryption – a web server will very likely use OpenSSL to allow it to encrypt communications between yourself and it. The vulnerable versions of OpenSSL come equipped with new functionality – a “heart beat” that is used to keep connections alive and open.

When this functionality is not disabled and you are using a vulnerable version of OpenSSL, an attacker can make a connection to your server and ready up to 64Kbytes of the process memory. For each and every request.

This is a classic information leakage issue, and the attacker can trawl through a collection of 64Kbyte “chunks” of binary data looking for interesting information. In theory, these chunks of information can contain anything the process (the web server, the mail server, etc) contains within itself. Some examples include :-

  1. A researcher has used this vulnerability to expose Yahoo Mail account passwords.
  2. It is believed to be possible to extract a server’s private key to allow an attacker to decrypt communications traffic and/or impersonate the server.

Whilst trawling through binary chunks of data looking for interesting data is the sort of activity that seems to normal people to be so difficult that it would be almost impossible for someone. However it is possible, and for something like passwords is even easy. And for private keys, there are hints out there on how to do it.

But How Does This Affect Me?

If you are not a server administrator, this will all seem a bit geeky and not have much meaning for you.

It is probably better to ask: What should I do about this? And the answer is to do nothing unless you are advised to do so by a trusted source. Whatever damage has taken place already and service providers will be busy fixing the vulnerability.

The only addition to that is to make sure you update your software on your computers – your laptop, phone, tablet, etc. Whilst the media is concentrating on the server side of the problem, OpenSSL is also used on client machines, and that means that your computers are vulnerable in some way – whilst no exploits are known to exist today, it is still worth being proactive in making sure you apply updates.

Because sooner or later, attackers will use this vulnerability to attack you directly rather than via servers.

But How Serious Is This?

Very.

But perhaps not as much as some of the more extreme possibilities might suggest.

There is a great deal of probability involved here. For example, was it possible that this vulnerability was known to the “bad people” before the announcement this week? The vulnerability has existed for a year or two so it is possible it was known about. But probably not widely known.

Was it exploited? Possibly, but it’s probable that it wasn’t widely exploited – the activities of “bad people” tends to leak. If it was exploited, it was quite possible that it was limited to the NSA and GCHQ.

As to over-reaction, there was a comment on a blog entry about this that claimed that his Yahoo Mail account password had been compromised three times in the last month by this method. Well, possibly but it seems far more likely that his password had been compromised via other methods – such as using a weak password. Using this method against Yahoo’s servers may reveal some account passwords, but it is likely to reveal random account passwords each time. Meaning that an attacker will find it quite hard to compromise the password for a single account more than once.

Going forwards, it is very likely that this vulnerability will be used by “bad people” – there are already indications that they may be starting to try this.

So it is important and urgent for server administrators to look at this problem and fix :-

  1. Update vulnerable OpenSSL versions.
  2. Revoke the old SSL certificates
  3. Issue new SSL certificates.
  4. If passwords are known to have been compromised, issue a notice to suggest people change their passwords.

It is also important that client machines are updated as and when fixes are released.

Password Security & Cracking ‘Em

 Computing, Security, Working Notes  No Responses »
Sep 182011
 

This blog entry is of the form of some working notes to help me get to grips with this area of security. Would welcome corrections!

There are two basic forms of password cracking :-

  1. Brute force cracking where every possible password combination is tried.
  2. Dictionary cracking where the password cracker uses a list of possible passwords to try … and optionally some algorithms for varying each word in the dictionary.
I’m more interested in brute force cracking for now, so I’ll just say a few words about dictionary cracking …

Password Hashes

Some people are under the mistaken impression that it is possible to protect against password cracking by preventing multiple login attempts – try to login more than 5 times in a minute, and the account is locked.

People trying to break into systems know about this of course, so they rarely if ever try it (the exception is multiple attempts against equipment that does not perform account lockouts). What they do is obtain the encrypted password in some way – grabbing the /etc/shadow file from a Unix system, dumping Windows password hashes, etc.

Once you have a password hash, or a number of password hashes, it is possible to attempt to crack the passwords. Not by trying to reverse the password encryption – that should be impossible, but by using the same algorithm for encrypting the password in the first place.

For instance if someone sets their password to “bad”, the password hash that gets stored in ActiveDirectory or in a Unix system’s /etc/shadow file may look something like “bae60998ffe4923b131e3d6e4c19993e” (actually it won’t but we’ll gloss over that detail for now). The password cracker starts encoding 1 character passwords, moving onto all possible 2 character passwords, 3, etc.

Eventually he or she finds one that matches that “hash” at which point they will have the account’s password.

Dictionary Cracking

Brute force password cracking has historically been thought of as too computationally intensive to try, so people resorted to restricting the amount of passwords to search through by observing that most people use either simple words, or words made slightly more obscure through some method.

For example, the following are some passwords picked from a list of frequently found passwords (but before getting smug about your password being nowhere near as this simple, you may want to check first) :-

  • password
  • letmein
  • xxxxxxxx
  • qwerty
  • 123456

In addition, people often take a simple word like “monday” and make it more complex by replacing certain letters with digits – l33t speak – so “monday” becomes “m0nday”. There is no point to this at all – it is one of the most common algorithms for supplementing a dictionary. Similarly adding digits to the end of a word, etc.

Brute Force Cracking

The option of brute force cracking is the process of going through every single password combination and trying each one in turn. This would seem to be a very slow process, but computers are becoming quicker and quicker. For example, with a GPU password cracker, my workstation can tackle around 380 million passwords a second … and it is not an especially quick GPU!

As to how fast password cracking could be today, it is hard to say … some of the more interesting hardware out there doesn’t come with benchmarks, and there’s some guesswork involved. But it is probably safe to say that nothing quite comes up to the 100 billion password attempts a second mark … yet.

It is relatively easy to calculate the number of possible passwords for any particular length … take the size of the character set used in the password, which can usually be assumed to be 96 (all ASCII without the control set) and raise to the power of the length of the password.

Length Passwords Time (380M/s) Time (100 billion/s)
2 9216 <1s <1s
3 884736 <1s <1s
4 84934656 0.2s <1s
5 8153726976 23s <1s
6 782757789696 37m 8s
7 7.5E13 59h 12m
8 7.2E15 5725h 20h
9 6.9E17 62 years 1916h
10 6.6E19 6035 years 20 years
11 6.4E21 577,845 years 2028 years
12 6.1E23 55473145 years 193297 years

 

There are several points to learn from this table :-

  1. The numbers of passwords gets very large very quickly. But not quickly enough to keep up with password crackers.
  2. Any password of less than 7 characters is trivial to crack … even with relatively modest hardware.
  3. Any password of less than 9 characters is trivial to crack if you have access to a large network of machines to work with.
  4. If you want to be safe for another decade or so (and policies can last quite a while), you will probably want to pick 12 characters as the minimum password length.
  5. These are the times to search the whole password space … it is not necessary to search through every single possible password to find the password you are looking for. That password might be found in 1/10 of the maximum time, or 3/4 of the maximum time. As long as the person generating the password has not been spectacularly dumb, it will still take a significant proportion of the total time to find the password.

If you look at the different brute force password cracking software out there, it quickly becomes apparent that there are simplistic password crackers that attempt each password combination in turn, and there are more sophisticated password crackers that attempt to tackle the most likely password combinations first. They do this by looking at passwords consisting of words, parts of words, pronounceable sequences that could be words, etc.

However good they are, all they do is increase the likelihood of obtaining the password in less than the maximum time. And possibly not by very much; let’s be generous and suppose that an intelligent brute force password cracker can produce the password on average after processing 25% of the possible passwords rather than 50% of the possible passwords. So for example for a 10 character password, an intelligent brute force password grabber could be expected to find the password after 1,500 years rather than 3,000 years (with a worst case scenario of 6,000 years in either case) … helpful, but not enough to make password cracking practical for 10 character passwords.

Poor Passwords

Everyone is obsessed with telling everyone what makes a strong password, so there’s no need for me to do likewise. But here’s my thoughts on what makes a weak password :-

  • Contains a single word in any language however it may have been deformed.
  • Common sequences of digits (i.e. “31415926”) or letters (“qwerty”) … they are effectively the same as words and appear in dictionaries of words to try for dictionary attacks.
  • Where letters have been changed into digits is no stronger than the password with the letters would have been – the classic “monday” -> “m0nday”.
  • Appending simple digits or symbols.
  • Anything short; an otherwise strong password is weak if it is too short (less than 10 characters; preferably 12).

In fact the list of what makes a password weak is so long that it’s always a good idea to test how strong your password is. Preferably with a hacking tool; and not with one of those web forms where they probably don’t test too well to avoid irritating potential customers.

Passwords Suck!

Ha! Yes you’re right … passwords are now a pretty poor way of demonstrating identity. However whilst there are many alternatives, none are universal so until someone comes up with a suitable replacement we are kind of stuck with them.

Corporate Email Leaks – Measuring The Stupidity

 Computing, Security  No Responses »
Sep 092011
 

I was alerted to this by an article on The Register which points to the Godai Group‘s investigation into what happens when you register domains “close” to a reputable company and grab all the emails that happen to pop by. It is hardly a surprise to anyone who has run an email system, but you will get tons of email delivered caused by email address typos. Specifically Godai Group looked at a specific type of typo – accidentally leaving out a “.”. For example, one of the domains that the Godai Group picked up on was some-person@ca.ibm.com where “someone” has registered caibm.com (no dot) … whether or not that person is sniffing those emails cannot be known, but they could.

Again, to those who have run email systems it is no surprise to learn that some of the emails contain “interesting” information not limited to :-

  • Trade secrets
  • Business invoices
  • Personal information about employees
  • Usernames and passwords!
  • Network diagrams.

What is not mentioned is that those Fortune 500 companies almost certainly have policies in place prohibiting acts such as sending passwords and other sensitive information by email. But of course there is a description for someone who reads all of the corporate policies – someone who isn’t doing their job!

There is an interesting list of mitigations in the Godai Group report, but it could be a lot more extensive :-

  • When sending out an email to an address where the left hand side would be a valid internal address, flag the destination in your logs. Use that information to build up a list of domains for which you should check for valid internal addresses and freeze (hold in the queue) any messages that match. As an example, if mike.meredith@ca.ibm.com were a valid address you might want to freeze any emails addressed to mike.meredith@caibm.com.
  • Use your email logs to build up a database of domains that you send email to. This will allow you to identify similar domains that may be practicing so-called “doppleganger domains” that you may want to take some action against. You may think you can guess what the domains would be, but there is a lot to be said for hard evidence.
  • Perform content filtering on outgoing email, and build up a set of rules to catch emails containing patterns that match certain kinds of emails you do not want leaving your organisation – to begin with a pattern matching “password [is] XXXXXX”. This could take considerable effort to build, and there will always be the chance of a false positive so you will want a sensible warning message when emails matching the relevant content filter get caught – “Please check that this email does not contain confidential information; please check the recipient address, and if necessary re-phrase the email”.
  • Encourage the use of end-to-end encryption such as PGP. Plain encryption is not sufficient – “walled garden” email systems such as GroupWise support encryption for internal emails, but this is about external (even if it isn’t intentionally so) email which is not encrypted with such corporate email systems. In fact systems such as GroupWise may be considered dangerous in this context – it comes with the word encryption on the tin, and even allows you to “take back” emails that you have sent that you regret. These facilities encourage dangerous practices.
  • Education, education, education. But this will not accomplish much – not only are the people who really need to be educated not listening, but these problems are mistakes – both in terms of accidentally sending emails to the wrong address, and in terms of emailing information that should probably not be sent via email.
  • Lastly, and perhaps for amusement value, you could try persuading senior managers that the danger of them sending inappropriate information accidentally out to third parties via email is so great that it justifies setting up a process by which all their email sent to external address is manually reviewed to ensure that it is not an accidental release of internal information. Good luck on that one!

Are eReaders A Security Risk ?

 Security  No Responses »
Jan 232011
 

Of course they are – everything is a security risk. The question should be whether ereaders pose enough of a risk to your organisation to justify taking some form of action to reduce or eliminate that risk. The risks that ereaders pose can be broken down into three areas :-

  1. Most ereaders are effectively USB memory sticks with a display on. As such the risk is much the same as with any USB stick – a malicious employee could steal data and remove it from your organisation. The countermeasures are the same too – implement a policy that prohibits the use of memory sticks from being used when plugged in.
  2. Ereaders have an additional danger in that it is far more likely for accidental leakage of confidential information. People are unlikely to carry out a paper document marked “COSMIC TOP SECRET”, but if they put such documents onto an ereader, they are far more likely to walk out the door with it through simple neglect – that ereader with the “COSMIC TOP SECRET” document on it also has the that harmless book “The Girl With The Dragon Tattoo” that I am reading in my spare time.
  3. Many ereaders (such as Amazon’s Kindle) device have a way of sending documents to the device over email – you email a special address on the supplier’s mail servers, and it trickles down to the ereader. Pretty convenient for the user, but not only does it make the leakage of information easier, but you also have to worry about how secure the supplier’s mail servers are.

If you need a certain level of security, that all makes it seem like ereaders should be banned at your organisation. That would be a shame because they can be useful – everyone knows how much paper can be wasted printing discussion documents and reports so they can be referred to in a meeting. An ereader means you can carry that pile of paper around far easier.

Rather than simply ban ereaders, simply provide them for the workers to use. And ban them from going offsite. Security is more palatable if it is served with a smile.

Passwords Are Dumb …

 Computing  No Responses »
Jan 142009
 

But not writing them down is dumber.

Supposedly we are not supposed to write down passwords, but who can remember hundreds of passwords ? In the distant past where the advice to not write down passwords was first suggested most users would have had just a few passwords.

Gradually things become more IT-orientated, and users would start complaining about the number of passwords they had to remember.

And we made things simpler for them by coming up with single-sign on mechanisms. Which was the wrong thing to do. Yes it makes things easier, but now a single compromised password will open up many different systems.

And of course we have the web with zillions of web sites that insist that each are important enough to have a unique account for. More passwords to “remember”.

Trying to tell people not to write passwords down is in the end going to reduce security. Firstly users will use the same password in many places so that they have fewer passwords to remember, and secondly they will write those passwords down. Why not let them do it right ?

So how can password be written down securely ? Well the first possibility is to use a secure password store so that passwords are held in an encrypted form. The second is to write them down using a consistent system to encode the passwords in some way (for example adding 1 to every digit, and moving each letter down 1) and splitting the usernames and passwords into seperate lists.

And of course encourage them to use different passwords in different places so that if one becomes compromised they will only have one site broken into.

But is it time to move on from passwords ?

We (as users) do not really want to enter passwords to use things. The login screen is an interruption in the flow of activities. We need something that will allow a distant server to establish the identity of ourselves without a login screen. Preferrably using something similar to Kerberos.

This will probably require an initial authentication process. Again the use of passwords should be avoided (except for critical services such as banking). Why not use some form of biometrics ?

 Older Entries