Slashdot Mirror
Bitdefender Finds 'Hypervisor Wiretap' For Reading TLS-Encrypted Communications (helpnetsecurity.com)
Orome1 quotes a report from HelpNetSecurity: Bitdefender has discovered that encrypted communications can be decrypted in real-time using a technique that has virtually zero footprint and is invisible to anyone except extremely careful security auditors. The technique, dubbed TeLeScope, has been developed for research purposes and proves that a third-party can eavesdrop on communications encrypted with the Transport Layer Security (TLS) protocol between an end-user and a virtualized instance of a server.
Bitdefender says the new technique "works to detect the creation of TLS session keys in memory as the virtual machine is running." According to HelpNetSecurity, this vulnerability "makes it possible for a malicious cloud provider, or one pressured into giving access to three-letter agencies, to recover the TLS keys used to encrypt every communication session between virtualized servers and customers. CIOs who are outsourcing their virtualized infrastructure to a third-party vendor should assume that all of the information flowing between the business and its customers has been decrypted and read for an undetermined amount of time."
Bitdefender says the new technique "works to detect the creation of TLS session keys in memory as the virtual machine is running." According to HelpNetSecurity, this vulnerability "makes it possible for a malicious cloud provider, or one pressured into giving access to three-letter agencies, to recover the TLS keys used to encrypt every communication session between virtualized servers and customers. CIOs who are outsourcing their virtualized infrastructure to a third-party vendor should assume that all of the information flowing between the business and its customers has been decrypted and read for an undetermined amount of time."
Guise, I'm really not interested in your breathless teasers.
Give me the rundown. How does it work? You know, the abstract, the overview, the quick so-and-so is what we did to make it work. If it's not in the summary then you're not doing your job. If it's not in the linked article, then you're just wasting my time. If it them might possibly maybe with a lot of luck be in a video of a conference that hasn't even been published yet, you're just taking the piss. I am not amused.
WHERE ARE THE DETAILS?
Skimmed the paper. It looks like a fair description of an engineering approach to exploit what we all already knew about hypervisors' access to their guests' memory and networking components. I don't see any revelations, just confirmation that you're not safe against a hostile hypervisor, with a somewhat practical attack method.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.
-SR
Yes, it is a big deal. But the key thing here is that the summary implies that this only works from the hypervisor to unwind encryption on a virtual machine which it is hosting. What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.
The truth is that all men having power ought to be mistrusted. James Madison
Not to mention the hypervisor has access to the VMs file system, and thus the private key.
The only thing to gain by extracting the private key from memory instead of the file system, is that often the VM needs to be either taken down or suspended to gain access to the file system.
But seeing as the hypervisors host system needs to occasionally be taken offline for maintenance anyway, its pretty trivial to cause a situation where the VMs migrations/reboots are delayed in a normal standard excusable way.
A possible mitigation?
What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.
What it really means is that IT managers need to do their jobs.
A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. They all have their risks, and those risks must be understood and considered before you start implementing any solutions.
It is extraordinarily lazy to simply discard an option with the excuse that "it cannot be secured", when what you really should be saying is that "it cannot be secured to meet my acceptable level of risk using the techniques of which I am aware". The latter description highlights the resolution to your problem: Do some research and learn about the risks and mitigation techniques available to you. Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release, and providing adequate recourse if they don't. Datacenters will often provide isolated space for your servers, with access restricted to only certain personnel, or even only your own employees. A cheap outsourced service provider may not provide any assurances of privacy... but you might not even need any such protection for your company's archive of already-released press releases.
In IT, this is your job. You must be aware of the risks inherent in every solution, and understand how they can be avoided, mitigated, or accepted. This analysis must happen not just for hosting consideration, but for every choice. Do you block a certain website in your firewall, or ban a particular application? How will the users respond? Will they be likely to work around the restriction in a riskier way? Will the new policy impact the business in a positive or negative way?
Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.
You do not have a moral or legal right to do absolutely anything you want.
While I commend the guys at BitDefender for finding this vulnerability its severity as a tad overstated.
Most if not all virtual machines are not encrypted, so your hosting provider has full access to your encryption keys which means there are easier ways to decrypt/intercept traffic.
Presumably you can solve this problem by using full disk encryption but then you need to find a way to pass your encryption password to your virtual host and you will surely do that through the means provided by your hosting provider, which means your password will be intercepted en route and again your hosting provider will have full access to the disk image.
In short you cannot trust anything you're not running from your own physically secured environment.
And even in your own fully secured physical environment you're still f*cked.
We live in the post Snowden world. Pretending its some sort of acceptable 'risk' when its clear 5 eyes countries have been datamining our comms and business secrets is to simply ignore what we already know. Cloud is backdoored. American and British kit is backdoored. Their satellites backdoored, their routers backdoored, its all shite kit.
The solution is to keep your servers in your control, so that your business secrets and customer secrets remain yours.
Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.
Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.
It's trivial to take a filesystem snapshot, mount and extract whatever files.
Or just extract it from the backup which is typically done by the hosting company.
A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. ...
Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.
The cloud is inherently insecure. Anytime you place all the parts needed for encryption outside your control, amazingly, it is no longer in your control. See any non-connected DRM for a long list of failures.
That said, the only cloud based services that can be "secured" are storage and communications if you externally encrypted the data. Externally means that the only thing the cloud service sees is an encrypted file or stream. There is no ability to decrypt that storage, no keys are associated with it, no algorithm is even evident on the service. Best yet, any number of current web services will suffice for this, including Google, MS, and DropBox. You can checkout OTR (Pidgin/Adium) and PGP plugins for a good idea of how these work and how to really secure your services. I predict that such approaches will happen sooner than later, as more and more problems with "it's the cloud" and other outsourcing options crop up.
The cesspool just got a check and balance.
Oh, no! As a financial institution, the government might get my customers' financial data! You know, that same data that we send to the IRS every year...
It doesn't matter what your data is or who you want to protect it from. You always need to do a critical risk analysis, and make conscious decisions about the cost of paranoia and the impact to your business. Just because a celebrity fugitive says that the government can read your data does not mean that you actually have a security problem.
You do not have a moral or legal right to do absolutely anything you want.
And those who own/operate those computers can, of course, eavesdrop whatever their "virtual" guests are doing. Seriously, how could anyone ever think otherwise?
I think you've missed the point.
Without defining the boundaries of what is "secure", you can't say something is "insecure". You have to determine what level of risk is acceptable to be "secure" before you start deciding that certain implementation options are "insecure".
To hijack your particular example, I could argue (with a suitable amount of paranoia) that Google, Microsoft, and DropBox could all inject malware into their client software to harvest encryption keys from your computer. You could put the keys on another server, but that would only add a layer of protection that a well-compensated mole could bypass.
Of course, that's rather ridiculous. We generally assume that Google, Microsoft, and DropBox are extremely unlikely to embed key-harvesting malware in their software, so we accept that remote risk and say their services are secure. By extension, then, any service that isn't compatible with client-side encryption is "insecure" in comparison.
Reining in the paranoia further, we must consider the sensitivity of the data being protected. For example, what is the actual risk that Google, Microsoft, or DropBox will be compromised (internally or externally) to access our data? Perhaps we're storing prototype designs. If stolen, there would be a business impact, but no regulatory or legal impact, and customers wouldn't be affected. In that case, it may not be worth the expense and hassle to require end-to-end encryption. While the risk is indeed higher than the fully-encrypted scenario, the risk is low enough that we can still consider the implementation to be "secure" against reasonable threats.
Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business. A cheap hosting provider may be the best option, even if their security only goes so far as a contract promising that if your repository is hacked, they'll pay for damages.
The problems with outsourcing come from a failure in properly assessing risk, or applying an existing implementation to something with different impact. For example, dropping medical records on a preexisting public-facing FTP site would be grossly insecure, but it's secure enough to use that public FTP site to host blank forms for patients and other agencies to download (and return via secure channels).
You do not have a moral or legal right to do absolutely anything you want.
Today there is a more recent story about the DEA spying on your medication list:
Unlike in cases of commercially-held data, where the Third Party doctrine allows police warrantless access, prescription drug monitoring databases are maintained by state-governments. The difference is lost to the Obama Administration, which argues that "since the records have already been submitted to a third party (a state's Prescription Drug Monitoring Program) that patients no longer enjoy an expectation of privacy."
You don't think they would apply the third-party doctrine to your data in the cloud, would they? Naw...
They don't need to break TLS. They just have to ask your provider "nicely" in a "youse got a nice restaurant here, it'd be too bad if it burned down" kinda way. Because you no longer own your data, they do.
Welcome to the police state. Thanks a lot, Tricky Dick, Ronnie Raygun, GHWB, Bill Clinton, Bob Graham (not a president, but he wrote most of the Patriot Act), GWB, Obama. (not sure about Carter expanding the drug war that Nixon started. Wouldn't surprise me if he did).
And it's guaranteed that Hills will continue the fine tradition.
In the unlikely event that Der TrumpenFuehrer gets elected, he's dumb and cowardly enough to be talked into also continuing the fine tradition. He'll be a patsy like GWB was.
Hills will be more direct.
We're fucked.
--
BMO
Well, yes. Those regulations are important, and regulatory compliance is part of what must be considered when finding an appropriate implementation.
As with all regulations, get a lawyer to determine exactly what is or is not necessary. I'm not an expert on the EU laws, but I wouldn't be surprised to find that they specifically exempt lawful searches by law enforcement personnel having jurisdiction, which would permit the US government to see your US-hosted data.
Those regulations may also be a reason to segregate your data. If it's cheaper to use a US-based cloud provider, you may be able to host only your private data in the EU in compliance with privacy laws, while hosting other assets with the cheaper American provider, reducing overall expenses.
Then again, maybe the simplicity of having everything in one place is the cost-effective option, with the labor savings outweighing the expense of having unnecessary protection.
I never said the analysis would be easy. I said it must be done. Nobody else can make your decisions for you and your data.
You do not have a moral or legal right to do absolutely anything you want.
Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.
That doesn't have to be the case. I know that at the very least two very large companies are working on fully encrypted computing, where nothing is ever decrypted on the server and all operations remain encrypted. *ALL* operations. One solution is apparently still slow as molasses (1 second for a multiplication or something in that order), but the one from ah... the other company, is a great deal faster. And it enables you to run fully secure in situations where you *know* the VM is untrusted.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Somehow, at some point, the hardware owned by the hosting provider has to physically do
a * b
In order to calculate the result.
No matter the encryption used, at that point the data is unencrypted.
It's gone.
For a determined party (FBI, CIA, NSA, etc etc) your privacy is merely an inconvenience, and not a terribly burdensome one at that.
Just cruising through this digital world at 33 1/3 rpm...
Makes me wonder if the Guarded Fabric/Shielded VMs in Hyper-V, coming in Windows Server 2016 is a definite answer to this type of attack, especially if it takes advantage of hardware RAM encryption in the latest AMD and Intel chipsets.
Not to praise MS, but it is interesting that they have a hardware based stack that might defend against this.
Nope. The method works by doing this operation encrypted. So if A is a-encrypted and B is b-encrypted, it can do A*B and give you an encrypted result C that, when decrypted, gives you the result of a *b.
Mathematically, it's feasible but very hard.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Not if it computes some f(a, b) that doesn't have a * b as a step but still has a distributive property such that decrypt(f(a, b)) == decrypt(a) * decrypt(b). See the explanation of Craig Gentry's Ph.D. thesis on "Homomorphic encryption" on Wikipedia.
US and UK isn't my government.
Please tell me this wasn't meant as "I got mine". Otherwise, how many refugees from the surveillance regime in US and UK is your government willing to absorb?
You could not comply with EU privacy laws if your put your customers data in a US cloud.
If two jurisdictions each have privacy laws with strong incentives for local storage, where should data about a transaction between a user in one such jurisdiction and a user in the other be stored?
Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business.
If the data is falsified and then released, it can still harm your business. For this you need signatures for authentication and integrity even if not encryption for confidentiality.
In the unlikely event that Der TrumpenFuehrer gets elected, he's dumb and cowardly enough to be talked into also continuing the fine tradition. He'll be a patsy like GWB was.
Hills will be more direct.
What we need is another President Johnson. Independents agree.
The filesystem could be encrypted though, unlocked with a password/key that is stored in memory. So yes, it is quite possible that memory extraction is necessary. And I would argue that the contribution of this paper is making the necessary memory introspection sufficiently quick and painless so that the VM cannot find out that something fishy is going on.
Other posters have mentioned homomorphic encryption but it could also be done inside a trusted enclave which is not able to be inspected by anything other than the executing process (even the operating system or hypervisor), see Intel Software Guard Extensions.
Anyone who has used 3rd party "web hosting"... should know this. At least my current web host has the decency to pretend they can't see my files without my password when I ask for support. :)
I hadn't thought about it much, but Amazon, through the sheer scale of AWS is trusted with a whole lot of data. What does their ToS say they can do with it?
And people decry slippery slope arguments.
The real "Libtards" are the Libertarians!
That's an important point, and allows for the server to be spoofed. But I think that the intent here is that active communications between server and client can be eaves dropped on. During the handshake, a symmetric cipher is selected and a key exchanged. It's this second key that normally cannot be accessed. Once a third party has access to this, they can see everything.
Have you seen what AMD is putting into its next server processors? http://amd-dev.wpengine.netdna... Tldr: It encrypts a guest's memory with a key that the hypervisor does not have. In theory, it should make a guest VM inaccessible to the hypervisor.
Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release,
The key word here being "illegal release" and what the definition of "illegal" is. "Oh, that wasn't an illegal release, a government agency provided us with a official letter telling us to release that information to them. How were we supposed to know that wasn't legal?"
This study shows what should have been obvious to everyone: if you put your data on someone else's server (the cloud), you are putting your data in their control. It is then your data only so long as it is in their best interests for you to have it.
I am confident that if someone else controls the hypervisor there will be a way for that someone else to access the data stored on any virtual machines running on that hypervisor. You say that the cloud is not any more inherently insecure than hosting your own servers. However, that is clearly not true, because if I host my own servers, I can determine exactly who has access to them (the fact that many IT departments do not keep their servers any more secure than if they were on the "cloud" does not mean that it is not possible). Further, you argue against something I never said. I never said that there was not a valid use for the "cloud", all I said was that it is inherently insecure. If you need a place to store data that does not need security, the "cloud" is perfectly acceptable.
The truth is that all men having power ought to be mistrusted. James Madison
However companies are free to setup here
Not if said companies' owners can't legally immigrate, or if engineers experienced with said companies' technology can't legally immigrate.
Human paranoia: massless pulley pomade and frictionless rope tallow repackaged in a rusty 1970s aerosol spray can as Universal Slope Lube (earth-destroying propellant undisclosed).
Step 1: assume adversaries reside in frictionless hyperspace
Step 2: notice what they can do
Step 3: apply Murphy's law
Step 4: adorn self with tin foil
Step 5: worry about whisker growth causing pin holes