Tag Archives: encryption

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

 

Encrypting DNS queries with DNSCrypt from OpenDNS

OpenDNS has just release a beta software to enable encryption of DNS queries called: DNSCrypt.

Not encrypting DNS queries can lead to two main type of attacks, as described by OpenDNS:
First, it prevents man-in-the-middle attacks which can cause malicious DNS responses to be used to trick you into visiting a dangerous website or send traffic to an unintended third party. Second, it prevents snooping by your ISP or any other intermediary who might want to sniff your DNS traffic to see what domains you are resolving.

DNSCrypt can significantly increase a user web security as until now there was no way to encrypt DNS queries. As stated by OpenDNS, DNSCrypt should be seen as complementary to Domain Name System Security Extensions (DNSSEC) because the later is not use to encrypt DNS queries, but to provide authentication and  chain of trusts.

DNSCrypt is not the answer to every DNS related threats though, as OpenDNS still acts as a relay to the real website’s IP to be accessed, and if the DNS servers it got some of its information from are compromised OpenDNS will still serve you the compromised IP. Also, one of the great advantage of OpenDNS is its ease of use, the fact you just have to point your Router to their DNS servers, with DNSCrypt you need a software to be installed on each machine you want to protect. It would be great to see future routers supporting/integrating DNSCrypt so it is seamless and would also protect any devices connected to that router, including smartphones, tablets, etc.

Nonetheless, this is definitely a step in the right direction! And although it is only available as a MAC Beta, a PC version should be coming up soon. Will it stay a free service, is also something that remains to be seen…

Twitter helping with Android’s Security

Twitter has just announced they will be opening the technology from Whisper Systems they just acquired. This is good news for Android users, and Google. Their technology allows text messages to be encrypted as well as providing full disk encryption, the later will only be made available, well, later!

This has the potential to bring security enhancement to the Android’s mass.

The source code is now available here: GitHub

New Dropbox Issues and a work around

More issues have been found with Dropbox, they were major issues and the researchers worked with the vendor to fix them before going public.
Although they are now fixed they highlight the time bomb Dropbox is for enterprise users as usage convenience and security risk ignorance means sensitive information is likely to be transferred centrally on Dropbox from many different companies and user profiles.

The 3 security issues discussed in the this article were:
– Hash value spoofing to access other customer’s data
– Stealing Dropbox hostID to access other customer’s data
– Potential replay attack when providing other customer’s data hash combined with any valid host ID (i.e.: the attacker’s host ID) to get access to the corresponding data.

One key point made in the article is that all this happens in the cloud, therefore the victims and/victims networks would be blind to these attacks.

There is no denial that Dropbox is very convenient, but those repeated security issues really means your data is at risk when hosted on their servers.

One solution, in this case, is encryption. I have listed a number of “on the fly” encryption solution in a previous post. But none of those solutions really ticked all the boxes so far, they either do not support enough OS, are not OpenSource and from very young and unknown companies, etc.

I have also previously said that using TrueCrypt would defeat the main attraction of Dropbox: seamless, streamlined and constant backups.

However, right now I see it as one of the only solution for securing Dropbox.

Why?
Because TrueCrypt is a well established encryption solution you can trust. Of course, other encryption tools such as PGP and co could fit the bill too, but I like TrueCrypt because it is free and OpenSource.

For using TrueCrypt with Dropbox and not trade off security for performance too much you would need to be more disciplined though…
In essence you need to break down your data into chunks in different containers so the TrueCrypt disks are as small as possible and the chunks of data that are not likely to change do not get sync up everytime you update a document which is unrelated to that data.

What worked for me is the following:
– Store data you consider as public into a public folder , you don’t have to share it with the world, but need to assume it could be.

– Separate your other data, the potentially sensitive one, into folders
i.e.: Subject1, Subject2, Subject3

– Within your folders create some subfolders about data that is likely to change and data that will not
i.e.: {Subject1_New, Subject1_Old} and {Subject2_New, Subject2_Old}, etc

– Keep the Change/New folders small

– Breakdown the Nochange/Old folders into sizes of around 500Mb or 1Gb maximum

– Create a TrueCrypt disk for each of the folders (Old and New).

– Ideally you will have a different passwords for each of the TrueCrypt disks but it depends on what process you use to remember those passwords!

– Store the public folder in Dropbox unencrypted

– Store all the TrueCrypt disks into Dropbox

Now, you will have access to your “public” data as before but for any potentially sensitive data you will have to mount the TrueCrypt disk before. You will also have to umount the disk before it can by synchronised back.

Because you have broken down your data into different chunks/encrypted disks, if you update or add a document into one of those disks it should not take long to synchronise back to Dropbox when you unmount it.
Also, the old/reference data which you are unlikely to change can be accessed by mounting those larger “old” disks without requiring for a large and lengthy re-sync.

What you are introducing with the method described above is added security through a check in/check out process while leveraging performance by dividing your data into chunks.

More importantly, you are securing your data without relying on Dropbox security.

Worrying trends with Dropbox

Dropbox is a very convenient way to synchronise data across locations and devices, it is one of the leader for in the cloud storage solutions. However, it has lately gathered some attention for the wrong reasons.

There has been a recent upset about the false claims (or incorrect depending where you stand on this) that no-one could decrypt your data on their data centre, including their staff. Well, it turned out it was no-one *excluding* their staff.

As explained in this article on TECHREPUBLIC

That’s fair enough, so as long as they have the right processes and due diligence in place your data should be safe into their hands, you can trust their staff.

Or can you?

Today, it appeared that while updating their backend code, anyone could connect to any user account without a password.

This, is pretty bad! one can question how really secure they are and will be! if the risk mitigation of their staff accessing your data is that they have good security processes in place how does that translate into testing and signing off their code. If anything, it shows a lack of robust basic QA processes at the core of their product!

Dropbox does provide some TIPS TO SECURE DROPBOX so you can use some 3rd party encryption tools such as EncFS (Free but only Linux and MacOS through MACFuse), SecretSync and BoxCryptor (only windows and Linux, but also compatible with EncFS).

I never thought this was really needed on Dropbox, until now!

There is also a mention of Truecrypt, but I don’t think it is a good option… As highlighted in the article, Dropbox’s performance is enhanced by the fact it only transfer delta changes. So for this storage technology not to be crippled, any encryption mechanism must follow the same delta changes update rule. With true crypt the whole encrypted volume will have to be updated and only after it has been unmounted.

An interesting attack on Voice Over IP Security

I just came accross an interesting attack on the Secure Real Time Protocol (SRTP) using Variable Bit Rate codecs (VBR). That protocol is used to secure voice or IP communication by encrypting the transmitted data.

The attack is described in this draft paper but for the the full details you should take a look at the very comprehensive white paper here which dates back to 2008.

It uses the phoneticpronunciation of words to identify patterns in the VBR encoding which can be used to bypass encryption and identify phrases as well as the language spoken. So this attack does not target individual words, but phrases or sentences.

Although the paper claims in some cases a success rate of 90% it has an average of 50% success, which is already good enough! What is the answer to this issue? padding!

What could be the impact of the RSA breach

In the past few months there seems to have been a rise in what is called Advance Persistant Threats (APT).
Wikipedia actually has a short but comprehensive description of what it means HERE.

An article on SC Magazine describes what seems to have been an APT against RSA affecting the security of their two factor authentication products.
It is not clear exactly what has been stolen at the moment, but RSA has admited that some sensitive information has been leaked/downloaded.

By reading some of the security community reactions (Help net security article) there seems to be 3 main concerns:
1. Security breach related to their pseudo random number generation, their product security would then be reduced to the security of the user’s passcode. Usually a simple 4 digits PIN.
2. The extend of their customer data that was stolen, could some of that data have an adverse effect of their customers (i.e.: password, name, addresses, etc)
3. What could be the security impact on the RSA 2 factor product users

The first concern is another example that security through secret is never good, and I am surprised RSA would only rely on some “secret fixed seeds” for their token code generation.

The second concern is typical of any data breach from a reseller/vendor who keeps large volume of customers data. The nature of the data and how it was protected will be of importance for RSA’s reputation.

Finally, the 3rd concern is what is of most significance. The common security community message seems to be: no need to panic.
Although I agree, I would add “but do not ignore it”.

It is important to remember that 2 factor authentication are used to improve the access security controls.
If the level of security it provides is reduced to a single factor authentication then there is an increased security risk towards what you were trying to protect in the first place.
This is even worse if that 2 factor authentication was the sole authentication method, as compromised tokens codes would then leave you with a very small 4 pin passwords.

Also, with todays popularity of “in the cloud” services many companies have replaced the physical security element where access was only accessible while on premises or from the company network, with a 2 factor authentication security control:
The “somewhere you are” requirement being replaced with a “something you have” requirement.

A compromised of the RSA token codes generation could have a very negative security impact on companies who are using RSA tokens to protect access to their cloud services.
They would indeed end up with portal accesses only protected by a userid and a 4 pin digits.
Now, if that is the case, this would be something to worry about and act upon.

What does SSD drives have to do with IPv6?

There has been a number of articles in the past few weeks about SSD drives proving to be difficult to securely wipe with conventional methods that are working on non SDD drives. Such as degaussing or repeated data overwrites.

It seems to have all come from the work of some californian researchers who have published a paper on that topic and available HERE.

And an easier to read summary is available on Macworld

It is not all bad though, one solution is to fully encrypt the disk and some companies such as Samsung are already offering SSD with Self Encrypted Drive (SED) technology.

But this is an example of a new technology that a company could deploy without fully understanding the security consequences.

So as the title of this post hints, what is the link between this issue and IPv6? Well, although IPv6 is generally thought to be a more secure protocol that the old IPv4, migrating to IPv6 could also bring some negative security consequences.

Indeed, not all your security technology controls may be ready for it. The most obvious one is the IDS/IPS, if the version you are using are not compatible with IPv6 then it could provide a covert channel for worms/viruses. But it could also blind some Data Leakage Prevention solutions.

SC Magazine was already asking a similar question back in January this year.

The point is, with technology changes some unexpected security issues may arise.

The rise of Memory Scrapping attacks and what it means to IRM, Disk Encryption and Thunderbolt

No matter how much layer of security you implement on a computer there always will be one area that is protected by a simple old access control, the memory.

You can have a complex password policy, dual factor authentication, full disk encryption, file encryption which could even be extended through the use of an Information Right Management solution, for that protected information to be accessed and manipulated it needs to be decrypted into memory.

The security of that data in memory then relies on memory access control and proper segregation, I am not sure we can talk about memory sandboxing but thats the same idea. The data will, of course, also rely on the physical security of the device it is hosted on.

Gaining administrator access on that device would therefore grant you access to the full memory.

This last point is of significance.

For IRM solutions, being an administrator on a device does not necessarily mean you also have access to the users IRM protected files. The same is true for simpler file encryption solution, it can be used to protect access to documents even from system administrators.

To some extend this could be true for some full disk encryption solutions, but you would then limit what a support staff could do. Having said that, it is possible to implement a full disk encryption only on the user data space and leave the minimum boot and system filesystem unencrypted or encrypted but only giving administrators access to the area where they can support the users, not on the user data disks. To be efficient this would require a good, and probably complex to implement, temporary files handling strategy.

So why is the fact that data gets unencrypted in memory of significance?

For two main reasons:
1) System administrators on those devices could then gain access to data in use which is not accessible to them while at rest or on the move

2) Those same system administrators could also get access to other sensitive information such as personal information (date of birth from an email being written, wife or pet names, etc) which could be used to attack the user password and/or full disk encryption key. In a worst case scenario it could also mean gaining access to an unencrypted password/key stored or cashed in memory…

So we may all trust system administrators (*caugh*), but a recent article I read from Networkworld.com was referring to a report by SANS who identified memory scrapping attack as one of the most dangerous new attacks on the rise.
This type of attack attempts to gather personal identifiable information and other useful information non encrypted in memory to do what I just described, access encrypted/protected information one is not suppose to be allowed to.

Another extension of this attack could be done through the use of the FireWire or the new Thunderbolt ports. Those technologies allow for full access to the memory. This article from The Register highlights the issue by comparing the secured master/slave USB protocol and the unsecured peer-to-peer FireWire/Thunderbolt protocol.
It would seem that on devices with FireWire/thunderbolt ports an attacker with no admin access is still able to conduct memory scrapping attacks as long as he has physical access to those devices.
The above referenced article mentions an attack through the display port of a Mac, it is because “Thunderbolt is based on Displayport technology” and it is easy to think of possible attacks:
– Leave your laptop (screen locked, turned on) unattended at work or in a conference and an attacker could just walk by and plug something into your new and shiny thunderbolt port (and probably unused for quite a while until vendors starts to produce compatible products)
– You plug you laptop to a screen which has been compromised and an attacker can then gain full access to your laptop memory while you are doing a presentation.

How do you protect against those attacks?
The simple answer is that it is difficult and that right now you cannot really be protected.
You would need to choose a laptop with no Firewire/Thunderbolt ports (goodbye Apple products) or being able to disable them.

But more importantly more work to segregate access to parts of the memory may be required by future Operating Systems.
Administrator Access should no longer mean full computer access, user data should be held in a container not accessible by admins but only from the data owner or auditors.
If done correctly:
– Sys admins would still be able to support the users and their computers
– User data would be better protected against the attacks described above
– Compliance requirements and data recovery would still be met without impacting the security of the system. A very basic example is an auditor role that may not be allowed to access the user system and just allowed access to user data. It would require the disk to be physically removed from the computer. That access for the auditors could require two auditors to provide credentials to be allowed to view the data, etc.

The Security around computer memory is an area which may need more attention from vendors in future.

Follow-up on Apple iOS Full Disk Encryption

Regarding my previous post I wanted to mitigate some of the risks I was describing.
In a nutshell, it is bad, but not that bad! :)

Escrow keybag
There is indeed a forensic issue with the escrow keybag feature, but because it requires the attacker to have both the targeted mobile device and the computer used to sync it with, That attacker would first need to break the computer’s security to access its filesystem.

Because that computer is used to sync the mobile device, most of the information it contains is likely to be on the computer as well.
For example, email accounts are likely to have been setup both on the computer and the mobile device, office files are likely to have been created on the computer, etc.

Therefore gaining access to the computer’s filesystem is likely to already give you access to most of the mobile device’s data.
Having said that, there is no garantee it will always be the case and some information such as call history, text messages, internet history, etc would only be available on the mobile device (and its hopefully encrypted backup).

The point is that although the Escrow Keybag can indeed be used to bypass a mobile device protection and is therefore a security risk, it should be put into context with the security risks related to successfully gaining access to it in the first place.
In other words, it is bad, but not that bad!

Full Disk Encryption
The statement that I reproduced about the level of security offered by the iOS full disk encryption control should also be put into a wider context.
Jonathan Zdiarski claims it was inadequate because it automatically decrypts data once requested for it, the way I undertand it is that its level of security is therefore dependant of the strengh of the passcode used and of the device’s OS security (sandbox, access control, etc).

But this is also true for any full disk encryption control, on any plateform.
If you gain knowledge or access to the passcode you can then access the data.
And if you get a malware running on your full disk encrypted device, it would not be prevented to access any data associated with your credentials.

I therefore do not believe this is an Apple specific security risk.
In other words, it is bad, but not that bad!