Bitdefender Finds 'Hypervisor Wiretap' For Reading TLS-Encrypted Communications (helpnetsecurity.com) 86
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."
How. Does. It. WORK. (Score:3, Insightful)
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?
Re: How. Does. It. WORK. (Score:2, Insightful)
Yeah it does. Up until 2013 the FIPS implementation guide from NIST contained language that explicitly singled out any implementation of crypto on virtualized machines as insecure. It is gone now, but still has a deeply vailed language to that effect. If you are on virtual, only acceptable for of crypto is external HSM, but... With memory access you are toast anyway. It is not a coincidence that Thales developed technology that allows you to run applications inside the secure boundaries of the HSM (circa en
Re: (Score:1)
Any proof that anyone other than the owner of the PC can enable and use ME?
Any proof that anyone with access to ME can access memory?
References please.
Re: How. Does. It. WORK. (Score:2)
Re: (Score:1)
Re: How. Does. It. WORK. (Score:5, Informative)
Re: (Score:2)
One of the emulation programs, I think it was Bochs, used to give a warning on each startup not to depend on VMs for security.
Re: How. Does. It. WORK. (Score:2)
Re: (Score:3)
Give me the rundown. How does it work?
Two-sentence summary: You run your crypto and store your keys on a computer controlled by your opponent. Quelle surprise, this turns out to be insecure.
Re: (Score:1)
... Where are the Details?
It's all Classified! 8-P
P.S. How come you could use all caps, but I got an error?
Re:This isn't a big deal, it's fucking huge. (Score:5, Insightful)
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.
Re: (Score:2, Informative)
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.
Re: (Score:1)
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.
Re: (Score:3)
Re: This isn't a big deal, it's fucking huge. (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Craig Gentry's homomorphic encryption (Score:3)
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 [wikipedia.org].
Re: (Score:2)
Re: (Score:2)
And people decry slippery slope arguments.
Re: (Score:2)
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: w
Re:This isn't a big deal, it's fucking huge. (Score:5, Interesting)
Re:This isn't a big deal, it's fucking huge. (Score:5, Insightful)
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.
Re: This isn't a big deal, it's fucking huge. (Score:2, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 segr
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:1)
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, n
Re: (Score:2)
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 ke
You still need to sign your press releases (Score:2)
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.
Re: (Score:2)
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 t
Re:This isn't a big deal, it's fucking huge. (Score:4, Interesting)
Engineering Paper (Score:5, Insightful)
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.
Re:Engineering Paper (Score:5, Insightful)
The next reveleation is that with physical access to the host servers, employees at datacenters could access any of the hard drives in a cloud environment, or even crash our machines indefinitely resulting in data loss!
Re: (Score:1)
Intel SGX (Score:3)
Re: (Score:2)
A sidenote (Score:5, Informative)
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 [invisiblethings.org].
Re: (Score:2)
Re: (Score:1)
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.
Are you refering to the SSL/TLS RSA keys stored on the filesystem for web servers? Because if yes, then you are not entirely correct. There are cipher suites (preferred by browsers) that have Perfect Forward Secrecy such that even if you later obtain those keys you can't decrypt past traffic.
Re: (Score:3)
The hypervisor also has access to your memory and until calculations on encrypted data becomes feasible, whoever owns the physical memory can read it out. Hell, most hypervisors can attach a console to the machine or even clone a running machine onto another machine without the VM being any the wiser. Disk encryption is only useful for data at rest and on the move, once you have unlocked the data at boot time, whoever owns the machine can read it.
Re: (Score:2)
Re: (Score:2)
IF you trust Intel AND trust the hypervisors to be honest about the capabilities of the processor at all times AND use the features. If you trust the hypervisors then you never have any problems, this is about untrusted hypervisors, emulating a processor feature is trivial.
Re: (Score:2)
Re: (Score:2)
QEMU can emulate SGX. There is a paper somewhere that shoots holes in all the 'promises', it's basically TPM but for VM's, you have to code specifically for it and license it from Intel and only Intel can 'verify' (which as we know, no American company can be trusted when it comes to turning over their private keys to the state).
Re: (Score:2)
Re: (Score:2)
"Presumably you can solve this problem by using full disk encryption..."
No, you can't. If I am reading this correctly, this vulnerability is about the TLS session keys. RSA uses asymmetrical encryption, via the public/private key pair, to negotiate a symmetrical encryption key that is used for the data transfer session. That session key will be exposed in memory. DHE and ECDHE keys have capability called "perfect forward secrecy". If a man-in-the-middle attacker records all traffic between server and c
There is no cloud, just other people's computers. (Score:5, Insightful)
Cloud Providers and the Feds. (Score:2)
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
We need another President Johnson (Score:2)
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 [thehill.com].
Re: (Score:2)
Your privacy (Score:2)
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.
Does Microsoft's Guarded Fabric help? (Score:2)
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.
Huh. Never thought much about it...but AWS... (Score:2)
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?