Securing applications on bare-metal instances

Conventional approaches to securing applications have relied primarily on software to provide protection. However good the software implementation may be, an attacker that can gain privileged access would conceivably be able to circumvent software defenses. Hardware technologies introduced into modern processors by Intel® (SGX) and AMD (SEV) can provide a significantly better security and privacy model. They essentially enables to run applications in a Secure Enclave — an environment that is isolated from the hypervisor and the host OS. It can help protect the confidentiality of sensitive data, and significantly raise the bar against attackers that exploit privilege escalation to obtain full control of the host.

Deploying application on bare-metal clouds requires you to take care of security from the hardware level up, including hardening and patching the operating system, managing access permissions, etc. Luckily, some providers like Packet give access to instances that support the Intel® SGX or AMD SEV technologies. Those can be used to secure your sensitive applications to the extent that even an attacker that gains root access to the bare-metal instance would not be able to access your data, or tamper with the produced output. Moreover, even the cloud provider itself would not be able to peek into it despite physical access to the hardware, and root access to the host OS.

Deploying an Intel® SGX enabled instance on Packet

Packet offers access to Xeon E3 processors supporting Intel® Software Guard Extensions (SGX) through c1.small.x86 instances. Here is documentation on how to deploy c1.small.x86 instances using a Packet account. Xeon E3 processors can power intensive workloads, and the security features can help ensure that data is protected, giving users the benefits of bare-metal with high-levels of confidentiality and privacy.

Securing Secrets and keys

One type of applications that requires particular attention is key-management applications. Key-management (sometimes also called secrets-management) solutions store, manage and provide access to secret parameters such as cryptographic keys, credentials, authentication tokens, etc. Development teams need to share data, configurations, and access keys across teams to cooperate on application development and testing. Automated build servers need access to source code control, API gateways, and user roles to accomplish their tasks. Servers need access to encrypted disks, applications need to access databases, and containers must be provisioned with privileges as they start up. Automated services cannot wait around for an administrator to type in passwords or provide credentials. Secrets management platforms address these requirements.

Some popular secrets management solutions include Hashicorp Vault, CyberArk Conjure, etcd and Square Keywhiz. These solutions are mostly open-source, with Hashicorp offering an enterprise version for Vault with features like HSM integration and more.

While the data used by secrets management platforms is typically secured at-rest and in-transit, secret information is in the clear and unprotected at runtime. Malicious actors can compromise secrets while the data is in use. For example, hackers or malicious insiders can parse data-in-use to obtain the encryption keys for data-at-rest or certificates for intercepting data-in-transit. To better understand the security model of Vault, and what is outside of it, refer to the Security Model in Vault's documentation , or to the following webinar on runtime protection for secrets management.

You can use secure enclaves to protect your keys and secrets on bare-metal instances using the Anjuna Runtime — a solution that enables seamless execution of applications inside enclaves, without the need to modify the application. As part of our Technology Partnership with Hashicorp, Anjuna provides a runtime-security solution for Vault, securing its master-key, unseal tokens and data in memory.

Protecting Byzantine Fault Tolerance with Trusted Execution

Protecting Byzantine Fault Tolerance with Trusted Execution

Byzantine Fault Tolerance (BFT) is a property of distributed protocols that guarantees that honest parties are “on the same page” (see that same state) despite the presence of attackers in the peer-to-peer (P2P) network. Compared to non-BFT consensus protocols, state of the art BFT protocols are secure when less than 1/3 of the nodes are dishonest or malicious. The Anjuna Runtime enables running Tendermint nodes inside a Trusted Execution Environment such as Intel® SGX or AMD SEV, making it extremely hard for an attacker to take over a validator node to propose, pre-vote, pre-commit or commit illegitimate transactions.

How do you avoid the Facebook passwords security issue and protect your customers’ secrets?

How do you avoid the Facebook passwords security issue and protect your customers’ secrets?

‘Krebs on Security’ recently published that hundreds of millions of Facebook users had their account passwords stored in plain text and searchable by thousands of Facebook employees, in some cases going back to 2012. Facebook issued an official statement, explaining how it protects user passwords by using a variety of signals to detect suspicious activity.

Runtime Protection for Secrets Management

Hashicorp Vault is one of the most popular secrets-management solutions. It helps manage secret parameters, cryptographic keys and authentication tokens and credentials centrally, providing visibility and control over access policies and tokens. While it solves the operational nightmare for DevOps teams, it is a high-value target for attackers. Instead of lateral movement within the organization and taking control over hosts one-by-one, gaining access to the host that runs the secrets-management solution could provide access to the whole infrastructure. While organizations invest much energy and resources into securing the hosts that run secrets-management solutions like Vault, it still doesn’t solve the runtime security problem. Hardening the host via traditional means would not protect the application from zero-day privilege escalation attacks, from an insider threat, or an untrusted infrastructure provider.

Runtime Protection for Vault and Consul

In this talk, we demonstrated a way to secure HashiCorp Vault from attackers that have complete control of the host server, by loading the application into a Secure Enclave. The user experience remains unhindered since all APIs and interaction with the Vault server remain as they were. Lastly, the talk will explain how to establish trust between the protected Vault instance and remote Vault clients using an attestation mechanism that is elegantly integrated into HTTPS.

Why protection against root users is important

Why protection against root users is important

Security company Qualys has recently disclosed vulnerabilities in Linux’s Systemd, the default service manager daemon for many Linux distributions [1]. They effectively enable a non-privileged user to obtain root privileges. This follows another disclosure, from about 7 months ago, related to a different Systemd vulnerability. Thus, an attacker would be able to access any sensitive workloads on the host by leveraging those vulnerabilities. The disclosures were assigned CVE-2018-15688, CVE-2018-15687 and CVE-2018-15686. Rather than discussing the specifics of these vulnerabilities, we want to talk here about the more general problem with relying solely on the OS to secure your sensitive applications.

SGX, or how I stopped worrying about the microchip hack

SGX, or how I stopped worrying about the microchip hack

Bloomberg Businessweek had recently reported on a hardware supply chain allegedly infiltrated by government sponsored hackers, who, according to the report, installed a malicious microchip into motherboards to spy on US-based companies.
The accused government has denied any involvement in this episode and the companies that, according to the report were targeted, denied finding evidence for it. No one has yet come forward to share the technical details of the implanted microchip. But even without these details, we can discuss the potential implications of such an attack, and how the technology developed by Anjuna can help customers regain confidence in their application security in light of similar threats.

Foreshadow

Foreshadow

Security researchers from KU Leuven, Technion, University of Michigan and University of Adelaide, have recently published their findings on an attack called Foreshadow, that compromises the security of Intel SGX enclaves. Once again, speculative execution was exploited in a manner similar to the Meltdown attack.
In our previous post, we explained how Intel Software Guard Extensions (SGX) protect against a Meltdown attack attempted from the untrusted part of a process hosting an enclave. However, the Foreshadow team showed how one can use a Meltdown-like technique to read the victim enclave's memory, conditioned on sensitive data already being in the cache. The official disclosure of the vulnerabilities, named L1 Terminal Fault by Intel, took place on August 14th, 2018, and they were filed as CVE-2018-3615, CVE-2018-3646 and CVE-2018-3647.
In this post, we explain the implications of the attack, its mitigations via microcode updates, and how Anjuna helps ensure that a backend application is running on an updated hardware secured against this attack.