Heartbleed, do not panic!

The security issue related to OpenSSL has been all over the news in the last couple of days.

It is indeed a very bad issue, one that can let an attacker access the login details, including passwords, of registered users from vulnerable Websites/Servers. Yahoo mail, was one of those sites…out of nearly a million others!

This vulnerability has been around for 2 years, it affects servers using OpenSSL 1.0.1 through 1.0.1f (inclusive).

Those servers could be running consumer websites or other applications. For example, the Network Security Monitoring suit: Security Onion, was vulnerable until yesterday when a security fix/update was released. The same applies to the Penetration Testing platform Kali 1.06, which was vulnerable until today!

If those applications/environments were internet facing, userids and passwords may have been compromised in the last 2 years.

This issue allows the attacker to access the memory of a vulnerable server, it means that unless you have logged on recently to that server your credentials are unlikely to be in its memory. Although we don’t know who knew about the issue, now everyone knows! and a lot of people now have access to exploits to leverage this issue.

What does it mean?
It means that by blindly changing your passwords on all the websites you have registered in the past, you might end up making it worse for yourself!

Indeed, if the servers you are changing your credentials on are still vulnerable, all you would be doing is loading your shiny new passwords into the servers’ memory waiting to be hacked!

Therefore you should only change your passwords on servers/websites that are no longer vulnerable. To find out, you can ask the relevant webmaster or use one of those online/scripts checks available in the following links:

Heartbleed  information website
Tidbits article discussing the impacts (not just for mac users)

And if you own such servers and have access to its command prompt, a simple “openssl version” should give you the version you are running.

Below is a link to a first hand account as to how it was discovered and fixed in one company, it is a great story with great insight:

A day we won’t forget

What is important though, is not to panic. Stay calm, and carry on! You should soon receive emails from a lot of websites telling you they have patched their system and recommend you reset your password.

Along with those genuine emails, you can expect a lot of spam emails so it is even more important to take your time and check those “reset password links”.

EDIT – 11th of April:
As discussed in the link below, it is interesting to note this vulnerability is also impacting client applications using openssl to protect their connection. We have yet to see the full impact this issue will have for both servers and clients!

Sourcefire Article on OpenSSL clients impact

Also, as usual, xkcd has produced a great piece of comic describing the issue :)

Heartbleed Explained


Bluetooth under attack

I have heard of Ubertooth for a while now and it seems it use to attack bluetooth devices keep growing. Once recent attack described HERE can leverage the Ubertooth sniffing capability to crack the encryption algorithm used by the Bluetooth Low Energy (BLE) standard. BLE is also referred to as Bluetooth Smart.


Sure, BLE/Bluetooth Smart is different from Bluetooth, but it is supported by most recent mobile devices (i.e.: the latest iPads and iPhone as well as some Android devices), and will be increasingly used in “smart” appliances, from toothbrushes to fridge if you believe this ARTICLE.

Nonetheless, if you were not convinced before that Ubertooth was a very useful piece of kit, you should reconsider it. Bluetooth is a technology that hasn’t seen much successful attacks until now, mainly because the attack vectors were limited to expensive kit or dark magic knowledge. This, may be about to change and it is as much a good think for driving better security, as it is worrying for  the integrity of all our accessories and smart devices we use every day.

Apple Security in the Enterprise

There is a good document from the UK government describing the different security features available in Apple Mac OS X 10.8 and the ones you should consider if using a Mac as an enterprise end point:

OS X 10.8 UK Gov security guidance document. 

In light of all the noise created by the NSA and GCHQ surveillance programs you might be tempted to dismiss governments’ position and view when it comes to IT Security. However, I found that document quite good and high level enough to be understood by mid-level management at least :)

They do refer to an MDM solution for some of the controls without specifying which one, so I assume they are referring to a OS X Server Profile Management solution as described by Apple HERE.

A new look

It seems I refresh the look of this website every 3 years and 3 years was up so here the new look :)

I decided to go with a slick, low maintenance theme.

It has also been a few months since I updated this website, hopefully this should change soon!

Using a phone as a keylogger, next it will be a smartwatch!

There is an interesting paper from Georgia Tech College describing a clever proof of concept where a phone is used to eavesdrop on keystrokes.
This is done by leveraging the phone motion sensor capability and placing it next to a keyboard. They managed to create a dictionary of words/vibrations that is able to recognise words typed on a keyboard just by analysing the vibrations made from typing.
Of course, you are likely to notice someone’s else phone sitting next to your keyboard but what if your phone got hacked and that software loaded onto it?

They conducted their proof of concept on an iPhone 4 but this is likely to be also possible on other platforms/devices.

In fact, with upcoming smart watches this concept will be even more relevant! Now I can see a use for that Apple M7 chip! ;)

As I am typing this note, my phone is next to my keyboard. Maybe I should move it away…

New iPhone 5S Fingerprint reader, a step in the right direction!

Apple has just announced two new models of iPhones, one of them is the iPhone 5S which comes with a fingerprint reader. Like others I believe this is no silver bullet, but it is a step in the right direction in terms of helping the masses to secure their iPhones.

There are two main areas of potential security failures:
- Fingerprints can be copied and once compromised you can’t “change” for new ones;
- The Fingerprint reader security implementation will be very important, any defects or flawed could be exploited to gain unauthorised access.

Apple may not be the first company to provide an embedded fingerprint reader into their phones, but like it did for tablets and smartphones, it will be the company that will popularise its usage and set the direction for others to follow. This is likely to be emulated and we will soon see fingerprint reader probably everywhere.
Because it is actually a very convenient way to unlock/authenticate, it is very user-friendly if done right and somewhat secure/unique (as long as they are not compromised). It means users will love it, and prefer that way of authenticating over having to remember a very long password or a different one for each system they need to authenticate too. It makes sense for some kind of password safe to be release at some point, either by Apple or a 3rd party, that would leverage the use of a fingerprint reader to authenticate users to all their systems. In the background you would still be using long, random and unique passwords but as a user, all you would be asked for is to select which website/system you want to sign on and to authenticate with your fingerprint so it accesses that secret password for you and uses it to log you in.

All this is great, and I would love to use such a system. But as fingerprint readers become more and more popular and especially more and more available, so will be the points of failure…
If every device has a fingerprint “read-er”, every device could also act as a fingerprint “captur-er”!
And your precious fingerprints could be compromised through malware or social engineering by leveraging features like guest access, micro-payments, fun apps that pretend to predict your future by reading the shape of your fingerprints, etc.

More importantly, due to the very nature of smartphones today that are using “touch technology”, users’ fingerprints will be left all over the device’s touch screen. It means if someone steal your smartphone, they also steal the very information they need to gain access, your fingerprints. The challenge then becomes about “lifting” those fingerprints from the touch screen to re-use them.

Also, the more popular fingerprint readers become and the more embedded their usage will be in how the masses authenticate to different systems. It means, it will be increasingly attractive for attackers to target such means of authentication. There is already a hacking challenge that will do just that: Hackers iPhone5s bounty.

What Apple has just done is providing an answer to a problem people are increasingly aware off, protecting your password whilst making it simpler to authenticate in the process. This is bound to catch on.

To conclude, in the short term, this will be a huge security set-up for most people, “normal” people who do not handle state/corporate secrets. In the medium to long term, this may actually backfire, because fingerprint alone is no security silver bullet. However, combining fingerprint authentication with more traditional mechanisms such as passcodes or passwords might actually provide extra security through embedded dual factor authentication.

Nonetheless, well done Apple for aiming in the right direction!

Mobile Device Management Limitations

Current MDM frameworks, unless using some kind of container approach, will always play catch-up to hackers wanting to bypass the controls enforced to their phones, as highlighted in the following article describing how to get around Airwatch’s MDM restrictions.

The conclusion of that article is spot on:
MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.

An MDM container approach will only ensure your corporate data does not leave that secured container and stays safe within it. However, it does not ensure trojan/malware installed on the Operating System host has not made that hosting environment so “toxic” that low level API haven’t been compromised, i.e.: Bluetooth connection to a keyboard, ability to screenshot, access to memory, etc.

This is why a real improvement on today’s MDM solutions, will only occur when provided natively to the devices and offering OS level containers with specific containers/profiles according to the level of security required. One that needs to be provided through and by Apple/Google. Until then, MDM will just be a nice add-on that improves security against common miss-use but not against seasoned hackers. Depending on your business requirements, today’s MDM could be just enough!

The right (way) to disclose vulnerabilities

An article was discussed last month in The Guardian and The BBC explaining how a research paper from the University of Birmingham had been barred by a judge from being published because it discussed weaknesses in the security related to cars starting mechanisms from many manufacturers (BMW, Porsche, Fiat, Peugeot, etc).

This was already discussed publicly at the 21st Usenix Security Sympposium, where an online video is available. A quick search on Google also produces a PDF paper explaining how a car can be gone in 360 seconds through hijacking car key transponders. If that was the paper stopped from publication, then I don’t think it provided enough details that warranted those legal actions.

This opened a debate about free speech, the right to do and publish research versus responsible vulnerability disclosure.
But what is a “responsible way” to disclose vulnerabilities? It seems the common consensus among white hat hackers and researchers is about giving time for the vendor/manufacturer and eventually publishing the vulnerabilities. “Time” is usually 6 months, after which most hackers/researchers will argue the vendor is not reacting fast enough and for the greater good the vulnerability should be published to kick those vendors into action.

But is it really always for the greater good?

In this recent car hijacking example, the researchers have indeed notified the car manufacturers and very little was done 6 months later. All those cars could be hijacked in a few minutes with their knowledge of the vulnerability (and the right RFID equipment), so by publishing a paper describing how this could be done it would force those vendors to finally fix that flaw. But it would also give further knowledge to criminals to potentially steal cars!

How this could be considered responsible disclosure? putting further pressure on vendors, yes. But facilitating in the process further criminal activities, maybe not.

Being responsible in disclosing vulnerabilities is not just about waiting a set amount of time, it is also considering the impact this could have on all the parties involved, including the end users! And therefore trying to balance the need to put pressure on the vendors whilst still protecting users from a given vulnerability, isn’t it the main goal to do the research in the first place?

It is human nature wanting to shout to the world our accomplishments, our Eureka moments, discoveries we feel will have a major impact, etc. That “responsible disclosure” principle goes in the way of this urge to claim/inform others about what is important to us; taking the time to reflect on it is therefore often lost in the process.

A story about Password – The Wrong Formula

In this article I will first talk about some misconceptions regarding what is considered a secure password and then about how you can leverage different technologies to help protect your different credentials.

In the past few years there has been a sharp increase in websites being hacked and their users’ passwords/hashes stolen, in parallel we are using online services for almost everything: to pay for your local pizzeria delivery or your electricity bill, access your bank account, connect to your work email, etc.

The common advice is to use different passwords for each site you register to, but most people don’t. It means that hackers can often reuse credentials they obtained on one website to access another.

One way to counter that risk would be to use some kind of formula so you remember a different password for each site you have registered to. This *could* be the best solution, as remembering a password formula means you do not have to write it down. However, the question is how secure your formula really is? How easily could it be reverse engineered? It may not be possible for an attacker to do it with knowing only one password, but what about 2? or 3? or more? would a pattern start to emerge?

Let’s take an example of a simple password formula, by taking the first letters of an easy to remember sentence tailored to a given site, www.google.com in this example:

I Love My dog And I Like Google since 1997

The password would be: ILMdAILGs1997

At first, this looks pretty good… especially if you start adding punctuations and special characters.

But if you use the same formula somewhere else, this time for www.yahoo.com, the password would just have one different letter: ILMdAILYs1997

Even if you were to make your password “expire” by changing the last number on a regular basis, I.e. each January, a pattern would still to be easily identifiable if an attacker gets hold of several of your passwords…

Of course, this means someone would need to get your credentials from different sources, Google and Yahoo in this example. But the point is that with the increasing number of websites we subscribe to, we are also increasing the chances that our credentials get stolen and patterns get discovered.

Passwords need to be unique to each system they are used on and they need to be as random as possible.

Not writing your password down but remembering it feels like the most secure solution. Until you look a bit deeper at how all your different passwords are constructed and realise they are not truly random and unique…

The best way to use unique, random and strong passwords is to save them into a password safe, a software that acts as a safe for sensitive information by storing it into an encrypted database. All your passwords are then protected by a master key/password.

Password safes are not new, in fact one of the most popular has been around since 2002.


But what is new is how you can achieve the following requirements, so you do not compromise on usability:

- Passwords need to be accessible from all your devices;

- Passwords need to be backed up securely;

- Passwords need to be easy to reset.

This is where Cloud storage can help you.

You can use PasswordSafe from Sourceforge to create an encrypted list of strong passwords and store that list onto a cloud storage service such as Dropbox. Then synchronize that Dropbox folder/file on all your different devices.

Because PasswordSafe and Dropbox can be used on most operating systems and platforms, including mobile devices, you will be able to access your passwords from anywhere. More importantly, you will also be able to synchronise any changes from anywhere, securely.

You do rely however on how secure the implementation of Password Safe is on the different medium you install it and if someone installs a key logger on your computer then you could lose access to all your passwords!

The only password you need to remember is the master password to your safe which should not be reused anywhere else.

IT Security News & BUGS Cryptography Project