Vulnérabilité critique d'exécution de code à distance (RCE) Linux dans CUPS - Ce que nous savons et comment s'y préparer
Synthèse
Une chaîne de vulnérabilité critique d'exécution de code à distance (RCE), qui est supposée affecter de nombreux hôtes de type Unix, a été divulguée le 26 septembre 2024.
Le composant vulnérable est le Common Unix Printing System (CUPS), en particulier cups-browsed.
Une chaîne de quatre vulnérabilités est requise pour une exploitation réussie : CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 et CVE-2024-47177.
Dans cet article de blog, Akamai donne des détails sur cette vulnérabilité, analyse la divulgation technique et fournit des recommandations sur les mesures à prendre pour se préparer efficacement et atténuer les risques dans l'attente d'un correctif.
Introduction
Le 23 septembre 2024, la chercheuse en sécurité Simone Margaritelli a partagé sur les réseaux sociaux des informations sur la divulgation prochaine d'une vulnérabilité. Dans son article de blog, Mme Margaritelli décrit une vulnérabilité critique qu'il a révélée aux développeurs trois semaines auparavant - une vulnérabilité RCE non authentifiée qui peut potentiellement affecter toutes les machines GNU/Linux.
Le 26 septembre 2024, une divulgation technique complète a été publiée. Il existe quatre vulnérabilités au total :
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
L'objectif de ce billet de blog est d'aider les organisations à se préparer, afin que le processus de remédiation soit le plus fluide possible. À cette fin, nous proposons un résumé technique de la chaîne d'exploitation et quelques mesures d'atténuation (sous la forme de recommandations de segmentation) que les administrateurs de réseau peuvent utiliser en attendant le correctif.
Que peut-on faire pour s'y préparer ?
Pour qu'un attaquant puisse exploiter une vulnérabilité RCE, deux « composants » sont nécessaires : un logiciel vulnérable et (bien sûr) un accès à distance. Puisque nous savons que le composant vulnérable est CUPS, il suffit de le corriger (lorsque le correctif est disponible) ou d'appliquer des mesures d'atténuation spécifiques à ce composant, mais nous pensons que le meilleur plan d'action est de profiter de cette occasion pour aborder la question de l'accès à distance de manière plus générale.
Commençons toutefois par la question la plus urgente.
Expositions de CUPS et exploitations potentielles
Le composant vulnérable sur lequel porte notre discussion est CUPS, qui est un service permettant à un ordinateur d'agir en tant que serveur d'impression. Il est très populaire et se retrouve sur un grand nombre de machines de type Unix.
Ce service très courant constitue certainement une cible de choix pour l'exploitation, car il a tendance à être exposé à d'autres machines (et potentiellement à Internet) de par sa nature même. Les vulnérabilités précédentes dans les services d'impression, telles que CVE-2021-34527 (PrintNightmare) ou même CVE-2010-2729, ont démontré l'impact potentiel de ce vecteur d'attaque.
Avant même la divulgation « officielle », nous avions émis l'hypothèse que CUPS était le composant vulnérable. En consultant le compte GitHubde Mme Margaritelli, nous sommes tombés sur un détail intéressant, une duplication du dépôt CUPS Apple du 17 septembre 2024, soit quelques jours avant sa publication initiale (Figure 1).
Figure 1 : Une duplication du référentiel CUPS d'Apple, faite par Margaritelli une semaine avant sa publication sur la vulnérabilité
Il y a également un problème sur le sur le GitHub cups-browsed qui cite Mme Margaritelli (@evilsocket) à propos de ce qui est probablement un effet secondaire de la vulnérabilité principale. (Il y a également d'autres commentaires intéressants, alors n'hésitez pas à apporter du pop-corn. )
Analyse d'exploitation
L'attaque n'est pas particulièrement complexe, mais nécessite plusieurs étapes pour être exploitée avec succès. La Figure 2 illustre notre résumé du processus, mais nous vous encourageons à lire l'intégralité de l'article du blog sur la divulgation pour une explication plus complète.
Figure 2 : Chaîne d'exploitation réussie
Étape 1 : Tout d'abord, le daemon cups-browsed écoute les connexions UDP entrantes sur le port 631. Sa fonction est d'ajouter les imprimantes détectées au système. Un attaquant qui communique avec le daemon peut simplement contraindre la machine victime à enregistrer une adresse malveillante en tant qu'imprimante légitime ; il s'agit de la CVE-2024-47176.
Étape 2 : La phase suivante se déroule lors de l'enregistrement de l'« imprimante » malveillante. Dans le cadre de cet enregistrement, libcupsfilters envoie une requête sortante à l'attaquant, demandant les attributs de l'imprimante via le protocole d'impression Internet (IPP). Dans le cadre de ces attributs, les imprimantes peuvent définir des fichiers PPD (PostScript Printer Description) spécifiques qui, lorsqu'ils sont utilisés légitimement, définissent les capacités de l'imprimante. Ces informations sont ensuite écrites dans un fichier .ppd, sans assainissement et sans contrainte. Il s'agit des CVE-2024-47076 et CVE-2024-47175.
Nous disposons à présent d'un fichier .ppd malveillant. Mais comment exécuter des commandes par son intermédiaire ?
Étape 3 : Saisissez la directive cupsFilter2 dans le fichier PPD, qui exécute divers filtres (fichiers exécutables) à chaque création d'un nouveau travail d'impression. Nous utilisons la directive filter pour exécuter le filtre foomatic-rip , qui est vulnérable à une injection de commande arbitraire. Il s'agit de la CVE-2024-47177.
En savoir plus
En utilisant Shodan, nous avons pu constater qu'environ 75 000 machines dans le monde exposent CUPS à Internet, dans la plupart des cas en utilisant le port 631 par défaut (Figure 3).
Figure 3 : Environ 75 000 machines dans le monde exposent CUPS à Internet
Le filtre suivant peut être utilisé pour interroger Shodan sur les serveurs CUPS exposés :
product:"CUPS (IPP)"
Informations supplémentaires
Grâce aux connaissances uniques d'Akamai sur les données de trafic, nous avons constaté que le service CUPS s'exécutait sur un large éventail de plateformes, notamment Ubuntu, macOS, CentOS, Debian, Fedora, OpenShift, Oracle Linux Server, Red Hat, Rocky Linux, SUSE, openSUSE, AlmaLinux, Amazon Linux, etc.
Au total, 10,1 % des machines Linux de l'écosystème Akamai ont le port 631 (le port CUPS) ouvert. Cependant, seulement 3 % de ces machines reçoivent régulièrement du trafic externe sur ce port.
Bien que ces chiffres puissent indiquer que le service n'est pas couramment exposé à l'extérieur, il est néanmoins important que les organisations évaluent leur propre exposition et révisent leurs politiques de sécurité en conséquence.
Analyse de l'exposition à Internet
L'un des moyens les plus courants utilisés par les attaquants pour infiltrer les entreprises consiste à utiliser des services exposés à Internet. CUPS n'est qu'un exemple de ce type de service, mais le problème ne s'arrête évidemment pas là. Toujours grâce aux connaissances d'Akamai sur les données de trafic, nous avons évalué l'état d'exposition de différents services dans des milliers d'entreprises.
Selon les données d'Akamai, environ 5,4 % des machines Linux sont exposées à Internet et reçoivent du trafic entrant de sources externes (Figure 4).
Figure 4 : Exposition sur Internet des machines Linux
Lors de l'inspection des stratégies réseau qui affectent ce trafic, nous avons constaté que 19,3 % de ces machines autorisent le trafic Internet entrant par défaut, ce qui signifie qu'aucune politique réseau spécifique n'est en place pour restreindre ou contrôler le flux du trafic entrant.
Comme les services exposés peuvent facilement devenir un vecteur d'attaque, il est crucial pour les entreprises de revoir et de renforcer leurs contrôles d'accès.
Recommandations
Comme la vulnérabilité n'est pas encore publique et qu'il n'y a pas de calendrier de correctifs, la meilleure façon de se préparer à cette divulgation est de cartographier tous les points de « friction » de votre réseau, qu'il s'agisse d'une liste de toutes les machines Linux, de leur exposition à Internet ou même de l'utilisation de CUPS, ainsi que les politiques de segmentation les concernant.
Une fois cette cartographie établie, nous vous recommandons d'appliquer des politiques de segmentation afin de limiter le rayon d'action de toute attaque potentielle. Il s'agit d'une bonne pratique, quelle que soit la situation actuelle, car le mouvement latéral sous Linux ne se limite pas à SSH ou aux RCE.
Identifiez l'utilisation de CUPS dans votre entreprise
Pour identifier les instances de CUPS exécutées sur vos machines, vous pouvez rechercher des noms de services et de processus. D'après nos observations, qui couvrent un large éventail de systèmes et de distributions Unix, les processus suivants peuvent indiquer l'utilisation de CUPS :
cups-browsed (le processus concerné).
cupsd
cancel.cups
lpq.cups
cupsfilter
lpc.cups
lp.cups
cupsaccept
cups-lpd
lpstat.cups
lpr.cups
upsctl
Les entreprises qui déploient osquery peuvent utiliser les requêtes suivantes pour identifier l'utilisation potentielle de CUPS sur leurs systèmes (les clients Akamai Guardicore Segmentation peuvent exécuter ces requêtes à l'aide de la fonctionnalité Insight).
Détectez les machines écoutant sur le port 631 :
SELECT pid, port, protocol, family, address, path
FROM listening_ports
WHERE port = 631
Détectez les processus en cours d'exécution susceptibles d'être liés à CUPS :
SELECT name, parent, cwd, cmdline, pid, start_time, path
FROM processes
WHERE path LIKE '%cups%'
Déterminez l'exposition à Internet
Vous pouvez utiliser des services d'analyse de l'exposition tels que Shodan pour identifier les services exposés à Internet, y compris CUPS.
Les clients d'Akamai Guardicore Segmentation peuvent utiliser le filtre Connexion Internet de l'onglet Révéler pour visualiser tous leurs services et machines qui reçoivent du trafic en provenance d'Internet (Figure 5).
Figure 5 : Le filtre Connexion Internet révèle tous les services et machines qui reçoivent du trafic en provenance d'Internet
Utilisez la segmentation pour limiter le rayon d'action potentiel
Imaginez le scénario suivant : La vulnérabilité est divulguée, ce n'est pas ce à quoi nous nous attendions ni ce à quoi nous nous étions préparés. Quelqu'un crée un exploit fonctionnel et un acteur de menace malveillant l'utilise pour pénétrer dans votre réseau.
Et ensuite ? Peut-il se contenter d'accéder au contrôleur de domaine, d'infecter l'ensemble du réseau, de lancer son botnet/cryptomineur/ransomware/trojan et de s'en sortir sans être détecté ? Ou doit-il redoubler d'efforts, effectuer des scans de reconnaissance complexes, utiliser de multiples mouvements latéraux et être plus généralement proactif - ce qui vous donnerait amplement l'occasion de détecter la violation et d'y réagir ?
Les violations se poursuivent, d'où l'importance de la segmentation. S'il ne s'agit pas de ce RCE aujourd'hui, il s'agira d'une autre vulnérabilité Zero Day demain. Les réseaux plats sont des cibles faciles, mais si nous rendons la vie des attaquants plus difficile, nous pouvons les faire renoncer (et partir vers des contrées plus clémentes), ou les forcer à passer suffisamment de temps et à effectuer suffisamment d'actions pour qu'ils commettent des erreurs et soient détectés.
Renforcez votre environnement de sécurité en 2 étapes
Deux mesures relativement simples peuvent renforcer considérablement votre environnement de sécurité : la mise en place d'une zone démilitarisée (DMZ) et la segmentation de vos serveurs d'applications.
Mise en œuvre d'une DMZ. Les serveurs exposés à Internet présentent par nature un risque plus élevé ; ils ne devraient donc pas avoir un accès complet au reste du réseau. La mise en place d'une DMZ périmétrique pour ces serveurs, qui garantit que les serveurs ne peuvent pas accéder aux parties les plus sensibles du réseau, complique considérablement la vie des attaquants.
Segmentation des serveurs d'application. Il est généralement possible de segmenter des serveurs d'application similaires et de restreindre facilement leur trafic entrant et sortant en fonction de leur logique d'application.
Prenons le serveur CUPS, par exemple : Nous connaissons son port (UDP 631), son processus (cupsd) et le fait qu'il devrait techniquement générer du trafic uniquement vers les imprimantes. Cela nous permet de créer un segment d'application pour ces serveurs CUPS, autorisant l'entrée d'un trafic spécifique et empêchant l'entrée du reste du trafic.
De cette façon, tout attaquant qui réussit à exploiter CUPS pour pénétrer dans le serveur pourra uniquement se connecter à l'imprimante - et un canular d'impression n'est tout simplement pas si effrayant.
En savoir plus
Les entreprises peuvent appliquer d'autres solutions rapides via la segmentation afin d'améliorer leur niveau de sécurité. Découvrez-les dans notre article de blog sur les pratiques de segmentation.