My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

De-Clouding your Life: Things that should not go into the cloud.

Published: 2014-05-07. Last Updated: 2014-05-20 14:03:12 UTC
by Johannes Ullrich (Version: 1)
10 comment(s)

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

10 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

I agree and I think that storing sensitive or personal information in the cloud is a big risk for many reasons:

- Hacking, data breaches, etc.
- Do you trust the sys admins that work at these cloud providers?
- Would you even know if your data has been compromised?
- Is your data backed up should their datacenter flood, etc.?
- What if you wake up one morning only to see a headline on the news that your cloud provider has been compromised and all data lost. Do you have your own, up-to-date backup available to recover your data?

I think the verdict is still out for cloud services in general, and they have a long way to go before they gain the confidence of IT/security professionals such as ourselves. In addition, it's only a matter of time before they are subject to regulations (HIPAA, PCI, etc.) - since they do in fact store this information due to users uploading medical and financial files to the cloud.

I agree that setting up your own cloud service at home is better than using one of the hosted services- if you are technically capable and have the time to do it (and keep the systems secure & patched).

Personally, if every cloud service were free and offered unlimited storage along with guarantees of excellent security, I still wouldn't use them (not for me personally nor would I recommend them to my company). After trying out and testing a few cloud services (all the big names) late last year, I came to the conclusion that even though the services were convenient and worked pretty well, I just couldn't shake the idea of my data being stored in some datacenter across the country (or in a different country) that I had no control or oversight of. This is the same reason that I wouldn't give a copy of my house-keys to a person/company/service that "promises" to keep them secure.

So I completely agree with this post and that "de-clouding" your life is an excellent task to take on.
Agreed and great writeup.. Working with various medical individuals at both their office and home locations I have tried to stress backup to a sanitized box, "iron key" or like. I know of 4 Dr's that called me to preen their accomplishments, they backed up to Mozy, Carbonite, or other cloud service. Later, two of them were "jacked" because the kids love to play on the net.

My world is redundant, Laptop HD (enterprise type) that is crypto, a Iron Key USB that is Cryto and NAS box that is Crypto. The drive and Iron Key are stored in a safe that is fire rated, the NAS is attached.

As we know, part of the battle is getting the to BU, the other part is what media.. and with the constant commercials of set it and walk away can only lead to problems.
> 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.

I don't understand why banks don't offer a simple (no sign-in) form on their (https) website for sending material to them. It could just be, from/to/subject/body/attactments (with appropriate search options for "to"). On the server, the file could be encrypted appropriately and forwarded.
ICI2Eye:

Exactly. Also, I think another troubling issue is that people become complacent/lazy with respect to backups when they use a cloud service- thinking that their data is properly backed up by having it in the cloud. Then, as you pointed out, when something happens to the system connected to the cloud service (malware, kids, etc.), their data goes bye-bye.

It always goes back to the basics: everyone should have up-to-date and real (not cloud) backups. This has been important for 30+ years and is still important today- if not more important due to the ever increasing number of cyber "problems".
Illegal access seems to be the most mentioned reason to be careful about your data in the cloud. But something seldom mentioned is what about the cloud provider or host going away? As in out of business with the datacenter dark and the IT staff gone. In the event of a hack, your data is usually still available. But with a dead cloud provider your on-line data or virtual system would not be quickly and easily available or even at all.
Anonymous:

Good point. A cloud service provider going out of business (which is likely to happen given the number of cloud services competing for pennies but with ever growing demands) is another good reason to have "real" backups. Sure, you can accept the risk and store your data in the cloud. But, you should still have a backup of that data.

Another point, what are the odds of a bankrupt cloud service provider spending the necessary $ to have all of their drives properly wiped/sanitized? The odds are pretty bad and the servers, along with their drives, would probably be quickly erased (not sanitized) and sold at auction.
First off, my life has never been cloudy; I have preached the dangers of the cloud for years. Another problem with cloud based backups is time. I average 10 to 20 GB per night of incremental backups to a client and server deduped backup server. It is 3-way RAID mirrored and whole drive LUKS encrypted, so I can quickly pull a drive and replace it with a blank one (fully tested with badblocks -wvv). When a 3 TB drive fills up, I yank it and hand carry it to the bank and put it in the safety deposit box. If I ever need to go way back in time, a simple trip to the bank can time travel me up to 7 years, and I have over 100 mb/sec bandwidth to restore the files with. I have been running this way since 80 gb drives were over $200.00, and now that 3 TB drives are $129.00, I have given up on tapes and DVDs entirely. How long will it take you to retrieve a filesystem for one of your machines from February 29, 2008? Network bandwidth limits your speed in a very big way. Do you even keep historical backups for every machine for every night for 7 years?
A very good point. Having your cloud data storage provider go out of business could ruin your whole day, to say the least. Consider what happened to Nirvanix in September of 2013. According to press reports at the time, customers were given two weeks from the announcement that Nirvanix was shutting down to download their data, but the available bandwidth would not allow all hosted customer data to be downloaded within 2 weeks.

Even worse would be the sudden loss of a SAAS provider. It is possible to mitigate the risk of a data hosting provider's going out of business by keeping local copies of your data, but I see no such measure to protect against the loss of a critical, cloud based software provider.

With traditional software running on your own servers, if the software publisher goes out of business, you only loose the ability to get updates; you can still run the software until you find and implement a replacement, including any necessary data migration. However, if a SAAS provider goes out of business, you could loose access to the application (and probably the data as well) with no warning. You would then loose the functionality of the sofware until you get a new solution in place.

In some cases, it might be possible to have a backup solution, with at least the most critical functionality, in place and ready to go in case the provider disappears, but often that is just not practical. In my personal opinion, SAAS is not appropriate for most critical uses, unless the provider makes a locally hosted emergency solution and local data backups available, which AFAIK do not.

As an example, I heard some time ago -- even before anyone was talking about "the cloud," about a company that was using a remote logistics solution to plan worldwide deliveries of it's products, including replacement parts. In that case, the provider did not go out of business, but pulled the plug on it's customer because of a dispute over payment of license fees. The company's trucks were not able to make any deliveries, until the company aquiest to the provider's demands. I am not even sure whetehr the story is true, but regardless, it does illustrate how dependency on a remotely hosted software can lead to serious business disruptions in the worst case.
You state

iCloud stores backups unencrypted and all it takes for an attacker to retrieve a backup is your iCloud username/password.

Perhaps you could elaborate on that. Apple provide a detailed document on Security in their systems, including iCloud.

Content that is unencrypted on the iDevice (Data Protection None) is encrypted via iCloud, but of course in a manner that is accessible with username and password. Data that is encrypted on the iDevice is backed up in that state.

Interested in what you see the vulnerability to be here ?
http://www.theregister.co.uk/2014/05/20/github_oversharing_snafu_nbc_private_keys/

Diary Archives