Encrypting DNS queries with DNSCrypt from OpenDNS

 Blog  No Responses »
Dec 272011
 

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

 Blog  No Responses »
Dec 242011
 

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

 Blog  No Responses »
Aug 182011
 

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

 Blog  No Responses »
Jun 222011
 

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

 Blog  No Responses »
Mar 212011
 

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

 Blog  No Responses »
Mar 182011
 

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?

 Blog  No Responses »
Mar 102011
 

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

 Blog  No Responses »
Mar 072011
 

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

 Blog  No Responses »
Feb 072011
 

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!

Apple and their elusive Full Disk Encryption solution

 Blog  No Responses »
Jan 252011
 

I have been researching how Apple has been implementing their full disk encryption control over the weekend and what I found puzzled me:

Although technically Apple provides a hardware full disk encryption solution, from a traditional security sense of the term, there is no full disk encryption available on the iPhone/Ipad currently! It sounds like a paradox? let me explain…

The closest analogy I can think of, would be if someone was selling you a house and claiming that the full house was protected with alarms in each room. The only problem, is that the alarm would only work when nobody was in the house… meaning the only protection your house effectively had was a simple front door key.

The following information can be found in the following article:
http://anthonyvance.com/blog/forensics/ios4_data_protection/
iPhone full disk encryption seems to have been implemented with one purpose in mind: fast/instantaneous remote wipe as it just erase the 256-bits encryption key.
Jonathan Zdiarski found that “the iPhone OS automatically decrypts data when a request for data is made, effectively making the encryption worthless for protecting data”
This is where the new iOs4.x “data protection” security feature comes into play, it allows for an app to derive a key from the user’s passcode/password and encrypt the app’s data. But so far it is only done by the built-in email app. APIs are available but each apps needs to use them if they want their data encrypted.
From the article referenced at the beginning of this post, I found the following two characteristics of that API the most interesting::
- Positive: There is a protection against brute force attack as an attacker can only guess about 20 passwords per second due to how keys are generated (which compares well to other software such as encrypted PGP files where 900 passwords can be guessed per second.)
- Negative: There is however a security weakness called the “Escrow Keybag, which is a collection of keys necessary to decrypt every file on the device without requiring the user’s password. This was done to allow computers to sync with the iPhone without asking the user for the password”. A company called ELCOMSOFT may be using this weakness in their iphone password recovery solution
The last point is of forensic significance. If both the iOS device and the computer used to sync it with are either seized or stolen then it is possible to find the plist/lockdown files on the computer and bypass the passcode used on the iOS device and dump all its data for analysis, unencrypted.
This is true for the latest iphones (3GS and 4G) with the latest firmware. For older model/versions there are other easier techniques to obtain the data.
Windows 7 is not better though:
http://advice.cio.com/shane_oneill/14875/windows_phone_7_and_droids_the_exchange_connection_disconnect
Their might be some lights for Android based phone with the Motorola enterprise offering: http://www.networkworld.com/news/2010/100710-droid-pro-enterprise.html
The link below needs to be read with a warning as I don’t really agree with the author’s message that sounds as if all those phones are very secure and enterprise ready. They can be, but companies need to be aware of the limitations of the security controls that have been implemented. He still provides a good overview of each type of mobile phone capabilities (page 3) hence why I am providing the link:
http://www.infoworld.com/d/mobilize/mobile-management-how-iphone-android-windows-phone-7-and-the-rest-stack-184?page=0,2
Finally, those guys have a nice white paper on iphone forensics which was updated recently in November 2010:
VIAFORENSICS
 Older Entries