Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: cloud

[DeepSec 2014] Trusting Your Cloud Provider. Protecting Private Virtual Machines – Armin Simma

DeepSecLogoTrusting Your Cloud Provider. Protecting Private Virtual Machines – Armin Simma

SECRETS: My talk is first and foremost about secrets.
Most people refer to data at rest or data in motion by the term “secrets”. When we talk about secrets usually we mean data at rest or data in motion. There are effective measures to protect these data, one of which is encryption. As you write in CfP 2013: “..uses encryption, access control…”. Concerning (IaaS-)clouds we have data IN EXECUTION. That is, the virtual image / virtual machine (VM) sent to the cloud provider is the secret to be protected. The problem is: this secret must execute on someone else’s system. Of course, we cannot simply encrypt the VM and send it to the provider. Homomorphic encryption would be a solution to this problem but at the time of writing it is academic i.e. it is not ready (and secure enough) to be used in real systems. In my talk (and our project) I want to show that it is possible to protect secrets (VM of the cloud customer) running on the providers host system using Trusted Computing technology.
FAILURES: Root users (superusers) usually have full control over and full access to a system. In our case the root user at the cloud providers site has full access to the provider’s host system. Thus he has full access to the guest image (i.e. the VM of the customer). What if root is doing wrong or malicious action? He could gain insight or manipulate the guest image. Here is potential failure. In my talk I want to show how to keep root users from failures.
VISIONS: In our project we were building a prototype to show that it is possible to build the proposed system. But the technical system is not enough. We need an “ecosystem” to bring our idea to real life. This is my vision: We have a trusted third party (I call it TTT trusted third tester) that vouches for a trustworthy (in that case thoroughly tested) system and publishes reference hash values to compare with the running system. The cloud customer can use these reference values plus attestation technology to check that a trustworthy system is running on the provider’s host. Using so-called sealing technology the VM will be decrypted on the provider’s site only if the provider’s system matches the reference hashes.

Cloud | Trust | Security

Security is the top inhibitor for companies not moving to the cloud

Problem Statement: Insider attacks within the cloud

There are a number of real-world examples of insider attacks on cloud based systems (including Salesforce.com leak of confidential information). These date back to 2007…

DBIR provides a classification of “insider attacks” as 18% – Quoted from Alex Hutton’s DeepSec keynote

How can we ensure that a [malicious] insider doesn’t have access to the customers VM.


  • no physical access
  • cloud provider is “partially” trusted at least


Encrypt the VM

Simple idea, but not possible as the provider will need to decrypt it in some way to run it. Decryption key must be known in some way to the provider.

Security based on trust

Assurance needs a kind of “proof”

Typically such “proofs” are given by service level agreements, but do not often cover security of the service. If any “proof” exists at all, it is done by an external audit or 3rd party certification of the cloud provider.

Suggested solution in a nutshell

Based on MAC (Mandatory Access Control) to allow more fine-grained policies and system-wide policies.

SELinux is an implementation of MAC for Linux

Dan Walsh gives many examples where SELinux would have prevented known vulnerabilities (e.g. shellshock, CVE-2011-1751)

By using SELinux it is possible to create a configuration to:

  • Restrict root from copying snapshots and VM images
  • Restrict root from doing other malicious things
  • Prevent logs from being removed or manipulated

SELinux policy files can however become VERY complex over time…

The conceptual problem is that an administrator must be able to perform maintenance and install new patches. This could allow an administrator to bypass protections. This can be prevented allowing only patches to be applied by a secondary root user who must validate and logon physically with hardware token. Reducing the possible exposure.

Privileged Identity Management –  a number of standards exist and should be taken into consideration (especially when it comes to logging actions)

TPM (Trusted Platform Module)

The second piece of the puzzle… used to store and protect keys against external attack and theft.

Tamper resistant, and relatively cheap hardware (1-2$). Currently over 600 million+ TPM chips exist

Version 2 is on the horizon

Root of Trust (RoT) gives an initial anchor for a security system

TPM was used in this solution for:

  • authentication / identification of the machine
  • storage of hash values
  • integrity measurement
  • attestation

TPM measured boot:

Before any component is executed, it is measured (i.e. hash is logged into the PCR) – Measure > Extend > Execute

After hashes are stored into the PCR a remote entity can implement reporting (attestation). This attestation can be compared against reference values (golden values) to ensure the process has not be altered.

POC for this was developed over the past few years, but now seems invalid due to the release of OpenAttestation

Overall ecosystem

A Trusted Third Tester (TTT) would need to publish signed integrity values for the “golden values” checks

A Cloud Attestor and Advisor (CAA) would need to have software on the customer site to perform the attestation

Related work

  • Intel
    • Mt. Wilson
    • Mystery Hill
  • Haven and SGX

Homomorphic Encryption

Main idea: Perform operations on the cipher-text, only person with the key can view the results decrypted

Would resolve all these issues if it’s fast/reliable enough

Problems with TPM-based solutions

  • Inefficiency problem
    • small micro-processor
  • Whitelist “golden values” –
    • Systems are NOT always the same, and therefore need/have different “golden values”.
    • Reference systems need to be 100% the same
  • Attacks on TPMs
    • Some are known (presented later at DeepSec)
    • Hardware and Software-based issues
    • Time Of Check, Time Of Use
    • Encryption of VMI using sealing
  • Cloud provider must disclose details of their platform
    • Necessary for attestation


[BruCON] Project Skylab 1.0: Helping You Get Your Cloud On

Project Skylab 1.0: Helping You Get Your Cloud On (Craig Balding)

The Cloud Security Broken Record

It’s time to stop talking the same stuff and start talking about what you can do.

Don’t just disengage when you hear cloud. It’s time to use it for something useful.

People are criticizing something they might not have ever used. Lots of people are making opinions about cloud without real experience.

It’s easy to read somebody else’s opinion… but what are you doing to keep up!


  • The hard disk space is always in the wrong place
  • The box you want is always busy
  • There’s no space

So how do you get around these issues?

What does your test lab need

  • Interoperability: Ability to interact with multiple cloud providers
  • Security: Protect your systems (pay per use is pricey if others are using it as a torrent site)
  • Visibility: You need to know what your tools are doing to the system (CPU usage, etc…)
  • Workshop: A place to do your testing

Startup mantra: Fail as fast as you can!

Because you don’t want to waste time on something that won’t work!


  • Learn
  • Get practical
  • Home server is RIP
  • Geekin’ Out
  • Open Source
  • Community Projects

Why not just use VMware for Skylab? Because tying yourself to a single provider is an invitation to fail.

3 Questions for you

  • Do you use cloud storage?
    • Answer: 33% YES
  • Have you booted a machine in a public cloud?
    • Answer: About 12 people
  • Have you played with cloud network overlays?
    • Answer: 1 person

These answers are typical for European conferences and show that few people played with cloud.

Use Cases

  • Target Practice
    • New tools
    • New attacks
  • Assurance Testing
    • Testing patches
    • New software interaction
  • During a Pen-Test
    • Random IP-Addresses

Skylab == Infrastructure as a Service

What else should it be!

  • Hit common use cases
  • On demand
  • Infrastructure as code (Configure your datacenter as a conf file)
  • Cost-conscious
  • Hardware re-use

Design principles

  • Hypervisor agnostic
  • Security test lab “features”
  • Freedom: Open-Source
  • Pragmatic: Don’t reinvent the wheel
  • Scriptable and Fun!

Sharing a whole VM is overkill. We should be able to convey what needs to be in a system without the need to download what we already have!

Shopping for a cloud platform

Things to look for –>Openness

  • API
  • Core
  • Source
  • Development
  • Decision Making

OpenNebula.org: The Open Source Toolkit for Cloud Computing

The ability to share and sell your Cloud systems to others.

Hybrid interaction with a range of other providers. Using OpenNebula and RedHats Delta-cloud. With a single command, you can start and manage remote cloud systems from any provider supported.

Pay as you go… Don’t forget to turn it off!

Terms of service… Check it allows what you need. TOS do change!

Cloud Networking

We need to simulate not only single isolated systems, but complete networks.

Amazon VMs only provide a single ethernet. Using Amazon Security Group you can divert traffic. However we just want to use routing!

Overlay Networks –> VPN infrastructure (e.g. Amazon VPC)

Some other providers don’t offer this as a solution… in this instance you can use a paid service like VPNcubed.

Configuration Management –> Configure/Script what you want your network to look like.

Various options to do this. Different languages.


“apache2” => {
“listen_ports” => [ “80, “443”]

Things still to do

  • Establish Amazon VPC Connection
  • Build Visibility VM (Splunk, Nagios, + extras)
  • Chef Recipes for Security Extras & CM
  • Build Range of Victim/Enterprise VMs
  • Create Easy “DC Creator” front-end script

Making it simple is the hard part!


[BruCON] The Belgian beer lovers guide to Cloud Security

Craig Balding – The Belgian beer lovers guide to Cloud Security

High-level talk covering cloud security with the goal to get people thinking about whats possible.

The CFO view on cloud computing purely bottom line. The less things appear on the balance sheet the better for the company. This isn’t always better for security.

Speed of provisioning makes it an easy sell to the CEO.

Not everyone is happy – IT Security people are cynical people. Same problems in a different guise. From a security standpoint though, we as security professionals need to know about it. The business wants the cloud, so we have to work with it.

Cloud is painting a vision that doesn’t yet exist. Marketing is out of sync with their engineering department. Easy to write it off, but it shouldn’t be that way.

Talking about the cloud is hard. There are so many different kinds. It’s like walking into a Belgian pub and asking  for a beer. Sure, but what kind of beer do you want ?

Cloud properties .:

  • Abstraction of Resources
  • On Demand
  • Elastic
  • Scalable
  • API
  • as a Service (aaS)

Virtualisation != Cloud != Virtualisation

Dynamic resources meet static security – The systems you have to secure as flexible, constantly growing and changing, so how does your security measures adapt to those issues.

Cloud != Outsourcing

You can visit an outsourcing company to check them out. Any large cloud company won’t be willing to show you around the data-center. Cloud is more of a black box solution, with an API interface.

Cloud Platforms are often stitched together open-source software with an API. These combinations and uses are all new. New doesn’t mean secure. Untested combinations are dangerous.

  • Infrastructure as a service (i.e. Virtual servers)
  • Platform as a service (i.e. Google AppEngine,…)
  • Software as a service (i.e. Salesforce.com,…)

Software as a service is no longer a dedicated machine or environment for your software. Shared platform amongst many companies.

Cloud Taxonomy and Ontology ==> More details can be found HERE
Jericho Cloud Cube ==> More details can be found HERE

Cloud can be public or private. Virtual private cloud solutions using VPNs to connect you to the cloud. The level of sharing here opens up attack vectors where moving from the public cloud to the private cloud could be possible. VPN driver vulnerabilities ?

Government clouds — Apps.gov offering cloud storage, software development, virtual machines for government use

Cloud specific security concerns .:

  • What are they hiding in the basement – Where is your data stored ?
  • Uptime – Is 99.9% enough ?
  • Lock-in – Can you get your VMs out if you need to ? What format are they in ? Apps coded to a specific API ?
  • Multi Tenancy – Shared systems with mixed security. Shared Databases with mixed customer data
  • Change Control – What did they change and when ? Do Google have change logs ? Are they public ?
  • Visibility – What logs do you have ? Can you see if somebody is brute-forcing your account ?
  • Cloud Layers – Services layered on-top of services. Subcontractors. What risk level do these dependencies introduce ?
  • Identity – Multiple accounts. Problems in-house, worse on the internet. SSO for the cloud ? Using your AD to authenticate in the cloud ?
  • SLAs – Have you read them ? How often are they changed ? Can you negotiate better SLAs ?
  • Terms of Service – If they screw up you get service credit ? is that ok if you’re down a week or more ?
  • Legal Issues – (Search & Seize) – What if the FBI takes the servers out of the datacenter ?
  • Auditor – They’ve only just learnt about virtualization, do they know what cloud is ?
  • Pay As You Go – Paying with a credit card. Where are your payment details stored ? Do they have anti-fraud systems ? Attackers driving up your CPU usage or bandwidth may cost you more. Can you set a limit?
  • Data Wiping – Can’t do it. You can delete them, but there’s no REALLYDELETETHIS API call.
  • Distributed Programming – Developers have to code to the API, are they experienced with distributed environments ? Race conditions.
  • Cloud APIs – Protected through SSL. Other options

How can a tester (PCI, PenTester,..) verify your security. Will the systems be the same today as they are tomorrow. It’s like changing a tyre at 70mph.

The cloud is like the wild-wild-west right now.

More researchers are needed to rally shed light on these security issues.

Cloud Security Aliance – Shape the future of Cloud

Cloudsecurity.org – Craig Baldings Blog