Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Encryption Bug Cloud Security

Bitdefender Finds 'Hypervisor Wiretap' For Reading TLS-Encrypted Communications ( 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."
This discussion has been archived. No new comments can be posted.

Bitdefender Finds 'Hypervisor Wiretap' For Reading TLS-Encrypted Communications

Comments Filter:
  • by Anonymous Coward on Saturday June 11, 2016 @01:35PM (#52295509)

    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.


    • by Anonymous Coward

      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

      • by Anonymous Coward

        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.

    • by Bruce Perens ( 3872 ) <> on Saturday June 11, 2016 @04:50PM (#52296375) Homepage Journal
      The host reads the virtual guest's memory and process state. This is absolutely no surprise, it was always implicit in virtualization systems.
      • by dbIII ( 701233 )
        It's a surprise to all those people who thought virtual machines would provide some sort of security by obscurity, which is probably just about every "cloud" customer out there unfortunately.
        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.
        • In other words, businesses that did not have a systems programmer or didn't listen to one. My customers are often embedded systems companies and often they have no idea how people can look inside their systems. One stripped their executable symbol tables to keep them from scrutiny. I showed them how the evil hacker tool "strings" would reveal their hidden menus :-)
    • 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.

    • ... Where are the Details?

      It's all Classified! 8-P

      P.S. How come you could use all caps, but I got an error?

  • Engineering Paper (Score:5, Insightful)

    by bill_mcgonigle ( 4333 ) * on Saturday June 11, 2016 @01:44PM (#52295547) Homepage Journal

    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.

  • by WorBlux ( 1751716 ) on Saturday June 11, 2016 @02:07PM (#52295643)
    A possible mitigation?
  • A sidenote (Score:5, Informative)

    by Artem Tashkinov ( 764309 ) on Saturday June 11, 2016 @02:26PM (#52295737) Homepage

    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 [].

    • The researchers actually admit [] (actual PDF) what I'm saying: "Actually, if you're not in control of the bare metal all bets are off"
    • 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.

    • by guruevi ( 827432 )

      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.

      • Intel Software Guard Extensions are designed to address exactly this situation. A process can run code in a trusted enclave such that no other process (even the operating system or hypervisor) can inspect the contents of that process. If you trust that Intel has implemented it correctly, then you actually can securely deploy things on untrusted servers.
        • by guruevi ( 827432 )

          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.

          • No you don't have to trust the hypervisor, there is a method for the processor to cryptographically attest that it supports SGX in a way that the hypervisor cannot "fake" an SGX container. You are completely right that you have to trust Intel though.
            • by guruevi ( 827432 )

              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).

              • QEMU can emulate using OpenSGX, where you generate the certificates yourself. This allows people to test out SGX code but it is NOT able to transparently impersonate an SGX processor, which would attest with a certificate signed by Intel. And I'm not sure what you mean by licensing SGX, it is free and the SDK is GPL.
    • "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

  • by ffkom ( 3519199 ) on Saturday June 11, 2016 @03:03PM (#52295917)
    And those who own/operate those computers can, of course, eavesdrop whatever their "virtual" guests are doing. Seriously, how could anyone ever think otherwise?
  • 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

  • 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.

  • 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.

  • 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?

Hold on to the root.