Trop de services CUPS : la menace des attaques DDoS
Commentaires éditoriaux et additionnels de Tricia Howard
Synthèse
Les chercheurs d'Akamai ont confirmé l'existence d'un nouveau vecteur d'attaque utilisant CUPS qui pourrait être exploité pour lancer des attaques par déni de service distribué (DDoS). (CVE-2024-47850)
L'étude montre que, pour lancer l'attaque, il suffit au système attaquant d'envoyer un seul et unique paquet au service CUPS vulnérable et exposé disposant d'une connexion Internet.
L'équipe SIRT (Security Intelligence and Response Team) d'Akamai a constaté que plus de 198 000 terminaux sont vulnérables à ce vecteur d'attaque et sont accessibles depuis l'Internet public ; environ 34 % d'entre eux pourraient être utilisés pour des attaques DDoS (plus de 58 000).
Sur plus de 58 000 terminaux vulnérables, des centaines présentaient une « boucle infinie » de requêtes.
Le nombre très restreint de ressources requises pour lancer une attaque réussie met en évidence le danger sous-jacent : quelques secondes seraient suffisantes à un attaquant pour récupérer tous les services CUPS vulnérables actuellement exposés sur Internet et cela lui coûterait moins d'un cent de dollar américain sur les plateformes hyperscaler actuelles.
Les CVE
Le 26 septembre 2024, la chercheuse en sécurité evilsocket a révélé l'existence de vulnérabilités d'exécution de code à distance (RCE) dans le Common Unix Printing System (CUPS). En bref, un attaquant pourrait manipuler les URL de protocole d'impression Internet (IPP) à distance pour exécuter des commandes malveillantes. Il pourrait y parvenir en enchaînant quatre vulnérabilités différentes.
CVE-2024-47176 dans cups-browsed, qui impose une requête à une adresse contrôlée par l'attaquant
CVE-2024-47076 dans libcupsfilters, qui ne valide pas ou n'assainit pas les données renvoyées par le serveur de l'attaquant, et les transmet au reste du système CUPS
CVE-2024-47175 dans libppd, qui, une fois de plus, n'assainit pas les données saisies et les écrit dans un fichier temporaire
CVE-2024-47177 dans cups-filters, qui permet l'exécution d'une commande arbitraire
En savoir plus sur l'histoire de CUPS
Lors de l'examen du compte-rendu technique sur les vulnérabilités, nous avons découvert qu'un autre vecteur d'attaque n'avait pas été abordé : DDoS. Les attaques DDoS continuent d'être un vecteur d'attaque viable utilisé pour harceler et perturber les victimes sur Internet, qu'il s'agisse de grandes industries, de gouvernements, de petits créateurs de contenu, de boutiques en ligne ou de joueurs. Bien que l'analyse initiale se soit concentrée sur la vulnérabilité RCE, dont les conséquences pourraient être plus sévères, l'amplification DDoS est également facilement détournée dans ce cas.
Le problème survient lorsqu'un attaquant envoie un paquet contrefait spécifiant l'adresse d'une cible en tant qu'imprimante à ajouter. Pour chaque paquet envoyé, le serveur CUPS vulnérable générera une requête IPP/HTTP plus importante, partiellement contrôlée par l'attaquant et dirigée vers la cible spécifiée. En conséquence, non seulement la cible est affectée, mais l'hôte du serveur CUPS devient également une victime, car l'attaque consomme sa bande passante réseau et ses ressources CPU.
Exploitation
Un simple script peut être utilisé pour envoyer le paquet UDP malveillant à une instance vulnérable de CUPS. La charge utile contrefaite demande à CUPS d'envoyer une requête IPP/HTTP à la cible et au port spécifiés par l'attaquant. La vulnérabilité apparaît lorsque cups-browsed tente de récupérer l'URI spécifié pour télécharger le fichier d'attributs IPP.
L'URI de ce fichier PPD est quelque peu arbitraire et peut être modifié par l'attaquant. Lors des tests, nous avons constaté que cette charge utile URI peut être complétée par 989 octets. Ce remplissage est inclus deux fois dans la requête IPP/HTTP : une fois dans les en-têtes HTTP, et de nouveau dans les données POST qui seront dirigées vers le système ciblé.
En utilisant cette technique de remplissage, les attaquants pourraient encore aggraver l'impact des attaques DDoS sur CUPS en consommant de la bande passante et des ressources supplémentaires sur les réseaux et systèmes ciblés. La figure 1 représente ce à quoi cela ressemblerait.
Fig. 1: Network diagram of attack flow
Système attaquant
L'une des facettes les plus troublantes de cette menace est le peu de ressources nécessaires à l'attaquant pour l'exécuter. Les figures 2 et 3 montrent qu'il suffit au système attaquant d'envoyer un seul et unique paquet à un service CUPS vulnérable et exposé disposant d'une connexion Internet pour que le système exécutant CUPS commence l'attaque.
./cups.py [CUPS_IP] [TARGET_IP]:1337 attacker_controlled-payload%20goes.here
Sending UDP Payload to target [TARGET_IP] and port 1337
Bytes Sent: 78
Figure 2 : Exploitation de staging
09:05:03.072432 IP 192.168.12.143.43937 > X.X.X.X.631: UDP, length 78
0x0000: 4500 006a 1991 4000 4011 2ed5 c0a8 0c8f E..j..@.@.......
0x0010: xxxx xxxx aba1 0277 0056 bb25 3020 3000 .......w.V.%0.0.
0x0020: 6874 7470 3a2f 2fxx xxxx 2exx xx2e xxxx http://xxx.xx.xx
0x0030: 2exx xxxx 3a31 3333 372f 7072 696e 7465 .xxx:1337/printe
0x0040: 7273 2f61 7474 6163 6b65 725f 636f 6e74 rs/attacker_cont
0x0050: 726f 6c6c 6564 2d70 6179 6c6f 6164 2532 rolled-payload%2
0x0060: 3067 6f65 732e 6865 7265 0goes.here
Figure 3 : Paquet UDP sortant (modifié pour devenir une charge utile non fonctionnelle)
Système cible
Au final, le service CUPS tente de récupérer ce qu'il croit être un fichier d'attributs IPP, mais qui est en réalité ce que l'attaquant a spécifié. La cible spécifiée dans le paquet UDP commence à recevoir des connexions TCP entrantes du système exécutant CUPS (Figure 4).
Fig. 4: CUPS service establishing a connection to the target
Si nous examinons de plus près les deux paquets reçus qui contenaient les données de requête réelles, nous pouvons voir la requête IPP brute, et les données POST qui l'accompagnent, partiellement contrôlées par l'attaquant, provenant du service CUPS (Figure 5).
Fig. 5: IPP/HTTP request received by the target
Les journaux du deamon cups-browsed montrent que les tentatives de navigation pour récupérer les attributs IPP sont à l'origine des requêtes adressées à l'hôte ciblé (Figure 6).
Fig. 6: Cups-browsed logs
Impact et exposition
Pour garantir une analyse complète, nous avons testé et observé différents modèles de machines à la fois dans le laboratoire contrôlé et sur Internet. Ces modèles ont un impact considérable sur les scénarios d'attaque et les facteurs d'amplification.
Le SIRT d'Akamai a scanné et analysé le trafic Internet mondial pour identifier les terminaux vulnérables à cette faille et accessibles sur l'Internet public (plus de 198 000), en se basant sur les données fournies par evilsocket. Sur la base de ces données, nous avons constaté qu'environ 34 % de ces terminaux (plus de 58 000) étaient vulnérables à cette attaque.
De plus, nos tests ont montré que certains de ces serveurs CUPS actifs renvoient des balises de manière répétée après avoir reçu les demandes initiales, certains d'entre eux semblant le faire sans fin en retour à des réponses HTTP/404. Des centaines de ces systèmes « in the wild » ont individuellement établi des milliers de requêtes et les ont envoyées à nos systèmes de test.
Cela montre que l'amplification potentielle de cette vulnérabilité est assez importante et pourrait causer des problèmes majeurs aux organisations qui exécutent ces serveurs affectés. Nos tests nous ont également permis de confirmer que certains des serveurs CUPS vulnérables étaient en mesure d'effectuer des négociations TLS (Transport Layer Security) à partir de nos tentatives de sondage contre des sites Web valides protégés par HTTPS. La possibilité d'affecter le TLS jette également de l'huile sur le feu, car cela génère une pression supplémentaire sur le matériel serveur et une surconsommation de ressources du fait des processus de négociation et de chiffrement/déchiffrement.
Les technologies obsolètes frappent à nouveau
Notons que beaucoup de ces machines identifiées fonctionnaient sur de très anciennes versions de CUPS, comme la version 1.3, initialement publiée en 2007. Il n'est pas rare que certaines organisations laissent des machines fonctionner avec du matériel et des logiciels extrêmement obsolètes, et il est peu probable que ces terminaux soient mis à jour de sitôt. Cela représente une opportunité majeure pour les acteurs malveillants : ils peuvent tirer parti du matériel obsolète pour l'amplification DDoS, ou (compte tenu du RCE dans ce scénario) créer des botnets à de nombreuses fins, y compris pour des attaques DDoS.
Estimations d'amplification
Les taux d'amplification pouvant varier considérablement, nous avons examiné à la fois un scénario moyen et un scénario catastrophe pour aider les lecteurs à évaluer la menace potentielle.
En fin de compte, c'est l'instruction target qui dicte la taille de cette charge utile, mais pour les calculs de base, nous utiliserons un paquet UDP viable d'une taille minimale de 30 octets et, dans le scénario catastrophe, un paquet UDP de 1 028 octets rempli au maximum. Ce paquet utilise l'instruction URI IPP et la remplit avec 989 octets (le maximum identifié lors des tests), qui sont dupliqués et inclus dans le trafic d'attaques résultant.
Dans le scénario catastrophe, nous avons observé ce qui semblait être un flot sans fin de tentatives de connexion et de requêtes à la suite d'une seule sonde. Ces flux semblent être sans fin, et se poursuivent jusqu'à ce que le deamon soit mis en échec ou redémarré. Cela peut être considéré comme une amplification infinie dans ce scénario. Au cours des tests effectués sur plus de 58 000 répondants, quelques centaines d'entre eux ont présenté ce schéma.
Environ 62 % des systèmes (plus de 35 900) ont envoyé au moins 10 requêtes TCP/IPP/HTTP à notre système cible en réponse à notre paquet UDP. Dans l'ensemble, le nombre de réponses parmi plus de 58 000 répondants (y compris les répondants infinis à l'échelle du temps) s'élevait en moyenne à 45, ce qui nous servira à calculer les taux d'amplification potentiels.
Dans le scénario de sonde viable minimale (30 octets), nous constatons que la machine cible a reçu une connexion TCP complète et deux paquets avec des charges utiles. Le premier paquet contient la requête HTTP et les en-têtes ; le second contient les données POST pour la requête (Figure 7).
Fig. 7: Minimal viable amplification flow
Ces paquets (226 octets et 174 octets) totalisent 400 octets. Si nous supposons que nous obtiendrons ces connexions et requêtes 45 fois par réflecteur CUPS, cela représente 18 000 octets de trafic pour chaque sonde de 30 octets, soit un facteur d'amplification d'environ 600 pour une tentative moyenne.
Une amplification plus faible ne signifie pas un impact plus faible
Le scénario catastrophe révèle des résultats différents en dehors de la taille du paquet. Si nous exécutons ce même exercice en utilisant des charges utiles UDP remplies au maximum avec 1 028 octets (Figure 8), nous observons des flux beaucoup plus importants en direction de la cible, mais une amplification plus faible.
Fig. 8: Maximally padded attack payloads arriving at the target
Dans ce scénario, notre charge utile de deux paquets arrive encore, mais leurs tailles respectives sont maintenant de 1 217 octets et de 1 164 octets, soit 2 381 octets au total. En supposant que l'on conserve la même moyenne de 45 réponses par réflecteur, nous obtenons un total de 107 000 octets de trafic par sonde de 1 028 octets, et notre taux d'amplification chute à 104 fois par tentative.
Bien que le taux d'amplification ait chuté, la bande passante consommée sur le réseau cible est près de 6 fois la charge utile minimale viable. Cela nécessite également pour le serveur HTTP ciblé d'allouer des ressources pour la gestion et le traitement de ces requêtes. Ainsi, bien qu'il n'améliore pas les taux d'amplification, ce scénario présente une attaque plus problématique (et réaliste) pour les défenseurs.
Évolutivité de ces possibilités
Si nous supposons que les 58 000 hôtes CUPS identifiés sont regroupés dans la même campagne, cela peut entraîner un déluge de 1 Go de trafic d'attaque entrant par paquet UDP en prenant l'exemple avec remplissage minimal. Un scénario de remplissage maximal pourrait entraîner un flot de trafic de 6 Go. Bien que ces chiffres de bande passante ne soient pas considérés comme choquants, ils entraîneraient tout de même la nécessité pour la cible de gérer environ 2,6 millions de connexions TCP et de requêtes HTTP dans les deux scénarios.
Options DDoS dans CUPS
Les attaques de cette nature s'inscrivent dans la tendance inquiétante à la diminution constante de la barrière technique à l'entrée qui empêchait auparavant les acteurs malveillants de mener ces attaques consistant à diriger des systèmes vulnérables à travers Internet pour envoyer des flux soutenus de trafic vers les victimes. Pour aggraver les choses, il suffit pour cela d'envoyer un seul paquet aux services CUPS exposés sur Internet. Quelques secondes seraient suffisantes à un attaquant pour récupérer tous les services CUPS vulnérables actuellement exposés sur Internet et cela lui coûterait moins d'un cent de dollar américain sur les plateformes hyperscaler actuelles.
Comme l'a souligné l'étude d'evilsocket, il existe un peu plus de 198 000 terminaux sur Internet qui répondent aux sondes UDP – et parmi ceux-ci, le SIRT a constaté qu'environ 34 % d'entre eux (plus de 58 000) ont réagi à notre sonde UDP d'une manière qui pourrait facilement être utilisée pour des attaques DDoS.
Un attaquant distant utilisant une charge utile contrefaite pourrait exploiter cette vulnérabilité pour faire en sorte que le daemon cups-browsed établisse des connexions TCP sortantes vers un tiers. Si cette cible exécute un serveur HTTPS sur le port ciblé, le serveur devra dépenser des cycles et des ressources à essayer d'analyser et de gérer ces requêtes et données, ce qui rendra l'attaque encore plus efficace. Dans le cas des CDN et de la mise en cache, il est peu probable que les URL spécifiées dans la requête POST existent, ce qui entraîne une erreur 404 qui contourne les accès au cache et transfère ces charges utiles aux serveurs d'origine.
D'après l'étude menée par evilsocket, de nombreuses distributions et versions de CUPS ont été impactées. En définitive, la vulnérabilité se trouve dans « cups-browsed » associé à « cups-filters » lors de la réception d'une requête d'ajout d'imprimante via UDP. Il semble que plusieurs distributions Linux proposent des solutions permettant de lier cups-browsed à localhost ou de désactiver complètement l'écoute de cups-browsed.
Atténuations des vulnérabilités CUPS
La décision d'effectuer une mise à jour vers la dernière version de CUPS ou de supprimer complètement CUPS dépend des besoins spécifiques de votre système. Si votre système repose sur la fonctionnalité d'impression, la mise à jour vers la dernière version de CUPS garantit une sécurité, des performances et une prise en charge améliorées pour les terminaux actuels. Cependant, si l'impression n'est pas nécessaire pour votre configuration, la suppression de CUPS peut simplifier votre système, réduire les vulnérabilités potentielles et vous permettre d'économiser des ressources.
En définitive, cette décision doit être basée sur le caractère essentiel des fonctionnalités d'impression pour votre environnement et sur l'importance de maintenir un système sécurisé et à jour. À tout le moins, si la suppression ou la mise à jour du logiciel CUPS n'est pas viable, les défenseurs doivent mettre en place un pare-feu sur les ports de service (UDP/631), surtout s'ils sont accessibles depuis Internet.
Les acteurs malveillants sont souvent prompts à exploiter les vulnérabilités nouvellement signalées, de nombreuses nouvelles versions étant exploitées dans les sept jours suivant leur divulgation initiale. L'application de correctifs prend du temps et les pirates sont impatients de profiter de cette période de transition vulnérable. De nombreuses organisations omettent également la mise à jour de certains de leurs anciens logiciels, ce qui peut être particulièrement lucratif pour les pirates qui en profitent pour exploiter de nouvelles vulnérabilités telles que celle-ci.
Atténuation des attaques DDoS pour les victimes
Pour les victimes d'attaques DDoS lancées à partir de systèmes CUPS vulnérables, certaines caractéristiques du trafic permettent d'alerter, de confirmer et d'éliminer le trafic d'attaques sur le réseau ou au niveau du pare-feu d'application Web (WAF).
Toutes les requêtes provenant du service CUPS commencent par POST /printers/ ou POST /classes/ et si la charge utile après la chaîne /printers/ est contrôlable par un attaquant, la partie initiale de la charge utile ne l'est pas. En outre, les chaînes CUPS User-Agent sont très informatives et utilisent le format CUPS/[VERSION], ainsi qu'une référence à l'IPP. Ce sont des chaînes vraiment uniques dans l'UA et elles ne sont généralement pas observées dans le trafic organique.
Il existe également des éléments statiques dans les en-têtes HTTP et les données POST. L'en-tête Content-Type de l'application/ipp et la charge utile printer-uri dans les données POST sont deux valeurs statiques que nous avons identifiées pendant les tests (Figure 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
Pour aider les défenseurs, nous avons également inclus une règle Snort qui devrait aider à identifier ces flux qui entrent dans votre réseau via des sockets en texte clair (Figure 10).
alert http any any -> any any (msg:"CUPS Reflected DDoS IPP Request";
pcre:"/POST \/printers\/|POST \/classes\//"; http_method;
content:"Content-Type: application/ipp"; http_header;
content:"User-Agent: CUPS/"; http_header;
content:"printer-uri"; http_client_body;
metadata:service http;
reference:url,https://akamai.com/blog/security-research/2024/october-cups-ddos-threat;
sid:100004; rev:2;)
Figure 10 : Règle Snort pour le trafic d'attaques CUPS
Comme nous l'avons indiqué, nous avons identifié des systèmes « in the wild » qui compléteraient les négociations HTTPS avant de livrer leurs charges utiles HTTP, de sorte que les défenseurs qui utilisent HTTPS devraient envisager d'implémenter ces règles de correspondance dans les configurations des WAF plutôt que sur leurs systèmes de surveillance réseau.
Conclusion
De nouveaux vecteurs d'attaque DDoS sont parfois trouvés, et souvent rapidement exploités, par des attaquants opportunistes peu qualifiés. Cette vulnérabilité de CUPS et le grand nombre de terminaux susceptibles d'être détournés de cette manière nous amènent à penser qu'il est probable que les défenseurs rencontrent des attaques basées sur CUPS.
En attendant que les efforts de messagerie et de nettoyage permettent de réduire le nombre de terminaux vulnérables et exposés sur Internet (actuellement plus de 58 000), nous pensons que ce vecteur sera détourné « in the wild ». Nous espérons que les défenseurs, les opérateurs de réseaux et les administrateurs système entendront le message et que, pour le bien de tous, ils géreront leurs expositions respectives rapidement, ou au moins seront prêts à identifier et à repousser les attaquants qui pourraient tirer parti de ces expositions à l'avenir.
Nous tenons à remercier evilsocket (Simone Margaritelli) pour son aide précieuse et sa contribution. ♥️
