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.

logo_anjuna_default.png
 

380 Portage Avenue
Palo Alto, CA 94303 USA
info@anjuna.io