Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 05:33:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-printers/cross-site-printing.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

11 KiB
Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Vous pouvez faire envoyer une requête HTTP POST à plusieurs adresses IP pour essayer d'atteindre un port d'impression brute ouvert. Si trouvé, l'en-tête HTTP est soit imprimé en texte brut, soit ignoré en fonction des paramètres de l'imprimante. Les données POST peuvent cependant contenir des travaux d'impression arbitraires tels que des commandes PostScript ou PJL à interpréter.

Impression croisée améliorée

Vous pouvez utiliser des objets JavaScript XMLHttpRequest (XHR) tels que définis dans pour effectuer des requêtes HTTP POST vers des imprimantes internes. Une limitation de l'approche d'impression croisée discutée jusqu'à présent est que les données ne peuvent être envoyées qu'au périphérique, pas reçues en raison de la politique de même origine. Pour contourner les restrictions de la politique de même origine, vous pouvez faire en sorte que le serveur réponde avec une fausse mais une réponse HTTP valide permettant les demandes CORS (y compris Access-Control-Allow-Origin=*). Un aperçu schématique de l'attaque est donné ci-dessous :

Impression croisée avancée avec spoofing CORS

Dans une variante améliorée de XSP - combinée à un spoofing CORS - un attaquant web a un accès complet à la réponse HTTP, ce qui lui permet d'extraire des informations arbitraires telles que des travaux d'impression capturés à partir du périphérique d'impression. Un extrait de code JavaScript de preuve de concept est présenté ci-dessous :

job = "\x1B%-12345X\r\n"
    + "%!\r\n"
    + "(HTTP/1.0 200 OK\\n) print\r\n"
    + "(Server: PostScript HTTPD\\n) print\r\n"
    + "(Access-Control-Allow-Origin: *\\n) print\r\n"
    + "(Connection: close\\n) print\r\n"
    + "(Content-Length: ) print\r\n"
    + "product dup length dup string cvs print\r\n"
    + "(\\n\\n) print\r\n"
    + "print\r\n"
    + "(\\n) print flush\r\n"
    + "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
  if (x.readyState == 4)
    alert(x.responseText);
};

Limitations de l'impression inter-sites

Notez que PCL en tant que langage de description de page n'est pas applicable pour le spoofing CORS car il ne permet qu'un seul nombre à être échoé. PJL ne peut pas être utilisé car malheureusement il ajoute @PJL ECHO à toutes les chaînes échoées, ce qui rend impossible de simuler un en-tête HTTP valide. Cela ne signifie cependant pas que les attaques XSP améliorées sont limitées aux travaux PostScript : PostScript peut être utilisé pour répondre avec un en-tête HTTP spoofé et l' UEL peut être invoqué pour changer la langue de l'imprimante. De cette façon, un attaquant web peut également obtenir les résultats pour les commandes PJL. Deux pièges d'implémentation existent et méritent d'être mentionnés : premièrement, une Content-Length correcte pour les données à répondre doit être déterminée avec PostScript. Si l'attaquant ne peut pas prédire la taille globale de la réponse et que le codage par tronçons n'est pas une option, elle doit définir une valeur très élevée et utiliser un rembourrage. Deuxièmement, l'ajout du champ d'en-tête Connection: close est important, sinon les connexions HTTP/1.1 sont maintenues actives jusqu'à ce que le client web ou le périphérique d'impression déclenche une temporisation, ce qui signifie que l'imprimante ne sera pas accessible pendant un certain temps.

Si le périphérique d'impression prend en charge l'impression de texte brut, l'en-tête de la requête HTTP de la XHR est imprimé en dur - y compris le champ d'en-tête Origin contenant l'URL qui a invoqué le JavaScript malveillant, rendant ainsi difficile pour un attaquant de rester silencieux. Cela est inévitable, car nous ne prenons pas le contrôle de l'imprimante - et dans certaines circonstances, nous pouvons désactiver la fonctionnalité d'impression - jusqu'à ce que le corps HTTP soit traité et que l'en-tête HTTP ait déjà été interprété en texte brut par le périphérique d'impression. Si la réduction du bruit est une priorité, l'attaquant peut cependant essayer de désactiver d'abord la fonctionnalité d'impression avec des commandes PJL propriétaires comme proposé dans PJL jobmedia en utilisant d'autres canaux XSP potentiels comme IPP, LPD, FTP ou le serveur web intégré de l'imprimante. Bien que tous les protocoles aient pu être testés avec succès pour déployer des travaux d'impression en utilisant des variantes de scripting inter-protocoles, ils ont certains inconvénients au-delà de ne pas fournir de commentaires en utilisant des en-têtes CORS spoofés :

  • L'accès inter-protocole aux ports LPD et FTP est bloqué par divers navigateurs web
  • Les paramètres pour l'impression directe sur le serveur web intégré sont spécifiques au modèle
  • La norme IPP exige que le Content-type pour les demandes HTTP POST soit défini sur application/ipp, ce qui ne peut pas être fait avec des objets XHR - il appartient cependant à l'implémentation de se soucier réellement des types incorrects

Une comparaison des canaux d'impression inter-sites est donnée ci-dessous :

Canal Port Pas de commentaires Impression non sollicitée Normalisé Bloqué par
Brut 9100 - ✔ ✔ -
Web 80 ✔ - - -
IPP 631 ✔ - ✔ -
LPD 515 ✔ - ✔ FF, Ch, Op
FTP 21 ✔ - ✔ FF, Ch, Op, IE

Un problème majeur de XSP est de trouver l'adresse ou le nom d'hôte correct de l'imprimante. Notre approche consiste à abuser de WebRTC qui est implémenté dans la plupart des navigateurs modernes et qui a la fonctionnalité d'énumérer les adresses IP pour les interfaces de réseau local. Étant donné l'adresse IP locale, des objets XHR sont ensuite utilisés pour ouvrir des connexions au port 9100/tcp pour les 253 adresses restantes afin de récupérer le nom du produit de l'imprimante en utilisant PostScript et le spoofing CORS, ce qui ne prend que quelques secondes dans nos tests. Si l'imprimante est sur le même sous-réseau que l'hôte de la victime, son adresse peut être détectée uniquement à l'aide de JavaScript. WebRTC est en développement pour Safari et est pris en charge par les versions actuelles de Firefox, Chrome et Microsoft Edge. Internet Explorer n'a pas de support WebRTC, mais VBScript et Java peuvent également être utilisés pour divulguer l'adresse IP locale. Si l'adresse de l'interface locale ne peut pas être récupérée, nous appliquons une approche de force brute intelligente : nous essayons de nous connecter au port 80 du routeur de la victime en utilisant des objets XHR. Pour cela, une liste de 115 adresses de routeur par défaut provenant de diverses ressources accessibles sur Internet a été compilée. Si un routeur est accessible, nous balayons le sous-réseau pour trouver des imprimantes comme décrit précédemment.

Preuve de concept

Une implémentation de preuve de concept démontrant que les attaques avancées d'impression inter-sites sont pratiques et constituent une menace réelle pour les entreprises et les institutions est disponible sur hacking-printers.net/xsp/

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥