J’ai quelques autres writeups sur le feu mais j’ai finalisé aujourd’hui celui de la machine Broker sur HackTheBox. Il s’agit d’une machine classée dans la catégorie “facile”. Au regard de ce qui se fait dans la vie réelle, j’ai également envie de dire qu’il s’agit d’une machine “réaliste”.

Scan

PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ+m7rYl1vRtnm789pH3IRhxI4CNCANVj+N5kovboNzcw9vHsBwvPX3KYA3cxGbKiA0VqbKRpOHnpsMuHEXEVJc=
|   256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOtuEdoYxTohG80Bo6YCqSzUY9+qbnAFnhsk4yAZNqhM
80/tcp open  http    syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  basic realm=ActiveMQRealm
|_http-title: Error 401 Unauthorized
|_http-server-header: nginx/1.18.0 (Ubuntu)
Device type: general purpose
Running: Linux 5.X
OS CPE: cpe:/o:linux:linux_kernel:5
OS details: Linux 5.0 - 5.14

Le scan basique ne montre pas grand chose. Comme d’habitude on se garde le SSH sous la main au cas où (parce que depuis x2 (enfin les jeunes ne jurent que par les CVE, ici c’est CVE-2001-0144) au début des années 2000, j’ai pas vu d’exploit OpenSSH réellement utilisable). A priori pas d’exploit public utile pour nginx 1.18 non plus. On voit un realm d’authentification ActiveMQRealm.

On relance en parallèle un scan plus complet et on y repère d’autres ports ouverts dont :

  • 61613 (port ActiveMQ)
  • 61616 (ActiveMQ OpenWire transport 5.15.15)
22/tcp    open  ssh
80/tcp    open  http
1883/tcp  open  mqtt
5672/tcp  open  amqp
8161/tcp  open  patrol-snmp
44149/tcp open  unknown
61613/tcp open  unknown
61614/tcp open  unknown
61616/tcp open  unknown

On revient au port 80/tcp. On a une auth basique lorsqu’on y accède. La doc ActiveMQ nous dit que généralement c’est admin/admin :

Doc ActiveMQ avec creds par défaut

Ici ça fonctionne, en filant ces identifiants depuis notre navigateur on est accueilli par la page suivante :

admin/admin ça passe

ActiveMQ est un “message broker”, ce qui explique probablement le nom donné à cette machine sur HackTheBox. Qu’est-ce qu’un Message Broker ? C’est un mécanisme de communication inter-services permettant à des services variés de pouvoir communiquer entre eux (ibm).

Ça semble être une version 5.15.15 d’ActiveMQ (confirmé via le port 61616). Cette version est affectée par une vulnérabilité de 2023 : CVE-2023-46604

On trouve des codes d’exploitation publics pour cette vulnérabilité :

La vulnérabilité a cette description :

The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath. Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue.

En gros, il y a un broker qui attend des données sérialisées, mais on peut y instancier n’importe quelle classe, dont celles qui permettent l’exécution de commandes shell (comme java.lang.ProcessBuilder).

Exploitation

L’exploit s’utilise vraiment de manière simpliste. Il prend une paire ip/port cible, ainsi qu’une ip/port locaux sur lesquels le ActiveMQ cible viendra se connecter pour récupérer le fichier XML contenant la commande shell à exécuter :

Exploitation de la vulnérabilité ActiveMQ

Post-exploitation et élévation de privilèges

Après des années de pentest, le cas le plus réaliste que je rencontre c’est une élévation de privilèges via sudo (je dis pas, il y a bien des trucs un peu tordus à certains endroits sur la planète, mais la réalité dans 90% des cas c’est des admins qui font tourner des trucs en root dans des dossiers world writeable).

Après avoir jeté un œil dans un éventuel fichier d’historique et des fichiers de configuration directement trouvables, j’enchaine généralement par un sudo -l pour déterminer quelles commandes mon utilisateur courant peut potentiellement exécuter avec des droits plus élevés, et avec un peu de chance sans avoir à fournir de mot de passe (le principe du rasoir d’Occam s’applique pour les élévations de privilèges).

Apache ActiveMQ$ sudo -l
Matching Defaults entries for activemq on broker:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User activemq may run the following commands on broker:
    (ALL : ALL) NOPASSWD: /usr/sbin/nginx

Ici, il semblerait que mon utilisateur courant (activemq) puisse exécuter le binaire nginx sans avoir à fournir de mot de passe.

Dès qu’on voit un binaire dans un sudo -l on fonce sur gtfobins pour voir comment on peut en tirer parti. Il y a plusieurs possibilités.

On va tenter la technique du chargement d’une bibliothèque partagée (entre temps j’ai ouvert un reverse shell qui revient vers un nc -l parce que le pseudo shell de l’exploit activemq est pas génial):

$ cat >/tmp/test.conf <<EOF
load_module /tmp/lib.so;
EOF

sudo nginx -t -c /tmp/test.conf> > $ $ 

id
uid=0(root) gid=0(root) groups=0(root)

Et on a un shell root. Plus qu’à récupérer le flag.

Conclusion

Comme prévu, c’était vraiment une machine facile, mais terriblement réaliste (service exposé publiquement, version obsolète, identifiants par défaut, configuration de sudo trop laxiste). Il y a quelques semaines, The DFIR Report a publié un write-up d’une compromission d’entreprise sur laquelle ils ont investigué et dont le point d’entrée du groupe d’attaquants (ici LockBit) était une instance ActiveMQ (mais sur un serveur Windows, le payload c’était un certutil qui téléchargeait un implant de type Meterpreter).