De-Clouding your Life: Things that should not go into the cloud.
A couple weeks ago, Dropbox announced that it invalidated some old "shared links" users used to share confidential documents, like tax returns [1] . The real question here is of course, how did these tax returns get exposed in the first place.
Dropbox usually requires a username and a password to access documents, and even offers a two-factor solution as an option. But regardless, the user may allow a document to be access by others, who just know the "secret" link.
As we all know, the problem is "secret" links easily leak. But as users rely more on cloud services to share files, and passwords for each shared file are way too hard to set up, this is going to happen more and more. Dropbox isn't the only such service that offers this feature. In a recent discussion with some banks, the problem came up in that more and more customers attempt to share documents with the bank for things like mortgage applications. While the banks do refuse to accept documents that way, the pressure exists and I am sure other businesses with less regulatory pressure, will happily participate.
For a moment, lets assume the cloud service works "as designed" and your username and password is strong enough. Cloud services can be quite useful as a cheap "offsite backup", for example to keep a list of serial numbers of your possessions in case of a burglary or catastrophic event like a fire. But as soon as you start sharing documents, you run the risk of others not taking care of them as well as you would. May it be that their passwords are no good, or maybe they will let the "secret link" you gave them wander.
Confidential personal, financial or medical information should probably not go into your cloud account. And if they do, encrypt before uploading them.
Here are a couple of steps to de-cloud your life:
- setup an "ownCloud" server. It works very much like Dropbox with mobile clients available for Android and iOS. But you will have to run the server. I suggest you make it accessible via a VPN connection only. Sharepoint may be a similar solution for Windows folks.
- run your own mail server: This can be a real pain and even large companies move mail services to cloud providers (only to regret it later ...?). But pretty much all cloud mail providers will store your data in the clear, and in many ways they have to. Systems to provide real end-to-end encryption for cloud/web-based e-mail are still experimental at this point.
- Offsite backup at a friends/relatives house. With wide spread use of high speed home network connections, it is possible to setup a decent offsite backup system by "co-locating" a simple NAS somewhere. The disks on the NAS can be encrypted and the connection can use a VPN again.
- For Apple users, make local backups of your devices instead of using iCloud. iCloud stores backups unencrypted and all it takes for an attacker to retrieve a backup is your iCloud username/password.
Any other tips to de-cloud?
[1] https://blog.dropbox.com/2014/05/web-vulnerability-affecting-shared-links/
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
New DNS Spoofing Technique: Why we haven't covered it.
The last couple of days, a lot of readers sent us links to articles proclaiming yet another new flaw in DNS. "Critical Vulnerability in BIND Software Puts DNS Protocol Security At Risk" [1] claimed one article, going forward to state: "The students have found a way to compel DNS servers to connect with a specific server controlled by the attacker that could respond with a false IP address. â??
So how bad is this really?
First of all, here is a the "TL;DR;" version of the vulnerability:
A domain usually uses several authoritative DNS servers. A recursive DNS server resolving a domain will pick a "random" authoritative DNS server for this particular domain. The real question is: How random? Actually as it turns out, it isn't random at all, and this is a features. BIND attempts to use the fastest name server, and has a special algorithm ( Smoothed Round Trip Time or SSRT algorithm) to figure out which server to use.
The vulnerability found here allows an attacker to influence the SSRT values in order to direct the name server to use a specific authoritative name server for a domain.
So the result is that the attacker can determine which authoritative name server is being used. BUT it has to be among the set of valid authoritative name servers. The attacker can not redirect the queries to an arbitrary name server of the attackers choosing.
So how does this make DNS spoofing easier?
The attacker has to guess three variables in order to spoof a DNS response:
- the query id (1/65535)
- the source port (theoretically 1/65535, but in most implementations more like 1/5000).
- the name server IP (average 1/4)
By pinning the name server IP, the attacker will only gain a marginal advantage. The issue may be more of a problem if one of the servers is compromised. But in this case, DNS spoofing isn't really your #1 priority.
Without DNSSEC, DNS spoofing is certainly possible, and this attacks makes it a bit more likely. But this attack is hardly a game changer and only provides a minor advantage to the attacker.
What should you do?
Relax... finish your coffee... read up on DNSSEC and apply BIND patches as they become available (because it is always good to patch.)
Also the original presentation/paper is available as well and a lot better then some of the news reports covering it.
How hard is it to implement DNSSEC? It isn't trivial, but more recent versions of BIND make it a lot easier by automating some of the re-signing tasks. It is easiest if your registrar supports it and you host your zones with them. For example the registrar I host a couple of my domains with automates the entire process for about $5/year.
[1] http://thehackernews.com/2014/05/critical-vulnerability-in-bind-software.html
[2] https://www.usenix.org/conference/woot13/workshop-program/presentation/hay
We also had another recent article covering some new DNS spoofing techniques:
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments