Insomni’Hack : un résumé des confs que nous avons vu

jeanstacklabs — Fri, 08 Apr 2022 14:09:59 +0000

Breaking SecureBoot with SMM

Pendant la conférence Insomni'Hack 2022, nous avons pu assister à une présentation de Itai Liba & Assaf Carlsbad sur un hack d'une partie peu connue de notre processeur X86, le System Management Module (SMM).

SMM est un firmware, permettant de faire passer le processeur d’un mode à un autre. Il est la clé de voûte de tout démarrage d’OS, en exécutant des opérations avec un très haut niveau de permission (considéré comme ring -2 ). Il possède un accès complet à l'entièreté de la mémoire physique ainsi qu’au BIOS.
SMM possédant sa propre mémoire SMRAM (system management RAM ),et n’est accessible qu'à travers le SMI (système management interruption) qui peut être appelé par le kernel à travers un buffer de communication.
En regardant de plus près, Itai Liba & Assaf Carlsbad ont découvert sur une architecture x86 (Dell) que le firmware SMM contenait certaines vulnérabilités accessibles à travers la partie userland (utilisateur).
Ils ont dans un premier temps cherché les différentes surfaces d’attaques de ce firmware et on découvert que son fonctionnement à travers le SMI et le buffer de communication n'était pas sécurisé. Il permettait d’effectuer une attaque de type nested pointer (pointeur non sanatize) couplé à une attaque ROP (Return Oriented Programming) afin d’exécuter du code au niveau SMM.

Sans rentrer dans les détails, il ont alors pu à partir d’un utilisateur root, bypasser toute protection mise en place au niveau BIOS, et donc par la même occasion désactiver le Secure Boot de l'ordinateur.

Ransomware Encryption Internals: A Behavioral Characterization

Nous avons pu assister à une présentation de Antonio Cocomazzi sur la détection comportementale des ransomware.

Les ransomwares ont évolué sur plusieurs aspects pour échapper aux antivirus, mieux énumérer les ressources et données sensibles à chiffrer et devenir plus performant.

On voit par exemple l’abandon de l’utilisation de clé RSA, au profit de ECDH qui a l’avantage de ne pas laisser de trace de la clé privée sur la machine de la victime.

Dans ce contexte le chercheur Antonio Cocomazzi nous présente ses recherches sur des heuristiques de détection d’activités malveillantes permettant de détecter un ransomware et donc de mettre à mal certaines évolutions des ransomwares.

Practical bruteforce of military grade AES-1024

Nous avons pu assister à une présentation unique sur une conférence sécurité, car rassemblant les deux parties d'une vulnérabilité, avec d'un coté l'attaquant et chercheur en cryptographie Sylvain Pelissier, et de l'autre le responsable opérationnel du produit chez ENCSecurity Boi Sletterink .

Dans un premier temps la conférence s'est axée sur la vulnérabilité découverte dans les logiciels fournis par Sony, SanDisk, et Lexar permettant de chiffrer le contenu du disque de manière transparente.
Ce logiciel peu connu, développé par ENCSecurity est brandé comme un logiciel de chiffrement de niveau militaire utilisant de l’AES 1024.
Cependant suite à une étude de Sylvain Pelissier, il s’est avéré que le logiciel contenait certains problèmes diminuant drastiquement son niveau de sécurité.
Pour mieux comprendre ces différents problèmes il faut revenir au fait que l’AES 1024 n’est pas définie dans les standards de cryptographie (NIST). Les utilisations standards d’AES sont 124, 192, et 256 avec respectivement 10, 12 ou 14 tours. Ils ont donc dû développer eux mêmes un moyen de faire de l’AES 1024, et là est le problème.
Car sans rentrer dans les détails, mais en développant leur propre version d’AES 1024, il n’ont malheureusement pas atteint un niveau de sécurité militaire.

Dans un second temps la conférence s'est axée sur la partie remédiation, car la vulnérabilité a engendré plein de problèmes pour l'éditeur. Comme la montée en version sur tous les softwares.

Cloud vulnerability

jeanstacklabs — Mon, 21 Dec 2020 10:24:17 +0000

This article will make an overview of different Cloud vulnerabilities that appeared over the past year. First of all, before talking about Cloud vulnerability, we should define what is a vulnerability in Cloud context.

What is a Cloud vulnerability ? It’s essential to consider this question, because it allows us to identify a real cloud vulnerability from a simple misconfiguration.
A miss-configuration is the consequence of the use of a service without the security means set up by the Cloud Provider. Whereas a Cloud vulnerability is a weakness in a Cloud service allowing an attacker to undermine the integrity of this service, and therefore its normal operation.
It should be noted that during this Year, AWS, Azure and GCP released a lot of new services. Most of these services are audited and certified (PCI-DSS, ISO 27001, ....). However, these certifications do not mean that the services are infallible. It informs about the minimum level of security that can be achieved with a good use of the service.

Vulnerability Azure

The first vulnerability we are going to talk about is not a 2020 vulnerability, but it is one of the most critical for Azure over the last two years. It appears on October 08, 2019, with a magnificent score of 9,5 on the NVD website. This vulnerability affects the Azure App service.

Azure App Service is a service allowing to create and host web applications, mobile back ends and RESTful APIs, without having to manage any infrastructure. It offers automatic scalability and high availability, supports both Windows and Linux, and allows automated deployments from GitHub, Azure DevOps, or any Git repo.

The 2019-1372 vulnerability is critical because it allows an attacker to execute non-privileged code in an NT AUTHORITY/SYSTEM context.
The NT AUTHORITY/SYSTEM context is the highest level of your computer, they have full access rights on your computer, and allows you to install software with a very high level of privileges.

This vulnerability is critical and is due to Azure forgetting to clean up user entries. Without going into details, it can be exploited through a Heap overflow allowing the attacker to execute his code. ( Here is an article detailing how to use this RCE_Azure vulnerability).

So we saw a vulnerability on the Azure cloud provider, however Azure is not the only one to be affected, Google Cloud Platform too.

Vulnerability GCP

In this chapter we will talk about vulnerabilities on GCP and more specifically on the GKE service. Several vulnerabilities on the GKE service have been released during the year 2020, however as explained in the introduction we will only focus on the vulnerability specific to the service and not to the operating system (such as Windows with Netlogon, and the Linux kernel).
These two medium criticality vulnerabilities are CVE-2020-8559 and CVE-2020-8555 .

The CVE 2020-8559 is rated 6.4. It allows an attacker to perform a Man In The Middle between a Kubelet and the client.

A Man In The Middle is an attack that aims to intercept communications between two parties, without either party suspecting that the communication channel between them has been compromised. It is often used to obtain the victim's identification tokens and thus steal the victim's identity. However, it is normally difficult to do because it requires being on the same subnetwork as the victim. For example a wifi hotspot at a train station or an Internet cafe.

In our case it is only effective if the attacker has already compromised a node, and your cluster has an authentication method such as a certificate or authentication credentials. The attacker will be able to steal these tokens and pretend to be the victim to the kubernete instances.

This first vulnerability allows a better understanding of why it is very important to use secure communication channels. However, it should be noted that this vulnerability is very hard to exploit, because the requirements are difficult to obtain in the GKE context.

The CVE 2020-8555 is a vulnerability noted 6.3. It affects the kube-controller-manager in its version v1.0-1.14. and allows to extract up to 500 bits of information per request on an unprotected endpoint of the host network by performing a Server Side Request Forgery (SSRF).

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with.

In order to be able to use this attack the attacker must follow these steps:

An attacker with permissions to do so creates a pod
The attacker attaches a volume to the pod. This volume can be one with certain built-in Volume types (GlusterFS, Quobyte, StorageFS, ScaleIO). An attacker with permissions to create a StorageClass can use this capability to the same effect.
By using the volume attachment or storage class creation, the attacker makes the kube-controller-manager k8s component make GET requests or POST requests without an attacker-controlled request body from the master's host network.

This attack still requires sufficient rights to create a pod. It is therefore not necessarily so obvious to use. Thanks to these two vulnerabilities we have seen a rough outline of the diversity in attack that can exist on GCP. However it should be noted that these attacks are mostly difficult to execute because it requires a high level of access.

Conclusion

We have seen that there are vulnerabilities on the different cloud providers, although they are limited at the moment. Cloud providers such as GCP, AWS, Azure are globally and for the moment well secured. By comparison, there have been at least more than 350 vulnerabilities on windows since 2019.
The Cloud brings a new way of looking at security, with security shared between the cloud provider and the user (company or individual). The Cloud provider is the owner of the infrastructure, the hypervisor and the physical network. The company remains the owner and responsible for the data, applications, virtual network, operating system and account/environment access.

It is important to see security in the Cloud as a whole with the application part, data encryption, role and access management with IAM and Role Based Access Control (RBAC).
However, as with any technology, security depends essentially on how it is used.

Source :

https://github.com/kubernetes/kubernetes/issues/92914
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8559
https://nvd.nist.gov/vuln/detail/CVE-2020-8559
https://nvd.nist.gov/vuln/detail/CVE-2020-8555
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8555
https://blog.alcide.io/new-kubernetes-control-plane-vulnerability-cve-2020-8555
https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1372
https://cloud.google.com/kubernetes-engine/docs/security-bulletins

DEV Community: jeanstacklabs