Résumé
- Notre analyse a conclu qu'il y a maintenant environ 28 910 hôtes qui montrent des signes de compromission en date du 25 octobre 2023.
- Les attaquants se sont adaptés et nos anciennes méthodes d'identification ne sont plus efficaces
- Les chercheurs ont trouvé un nouveau moyen (certes moins précis) de déterminer si les portes dérobées de ces appareils sont toujours actives
La semaine dernière, nous avons partagé des informations sur un événement en cours concernant les appareils Cisco et une porte dérobée installée sur des dizaines de milliers d'hôtes Cisco. Dans notre dernière mise à jour, nous avons constaté une baisse significative du nombre d'infections. Et croiriez-vous que ce nombre est tombé à zéro ? En quelque sorte...
Depuis lors, le groupe (ou l'individu) à l'origine de cette compromission massive a vu l'erreur et a tenté de la rendre publique en supprimant la configuration qui permettait aux chercheurs de déterminer si l'appareil était compromis. Ce faisant, les méthodes permettant de trouver ces compromissions sont instantanément devenues obsolètes.
À la base, ces appareils Cisco utilisent le serveur web Nginx, et (l'une des) configurations modifiées par les attaquants est le fichier de configuration Nginx de l'hôte. Un lecteur astucieux de Fox-IT a remarqué que dans la capture d'écran fournie par Talos, l'attaquant avait ajouté une autre directive de configuration de l'emplacement, qui peut encore nous donner une idée de l'installation ou non des portes dérobées sur l'appareil.
Une directive de localisation dans Nginx permet à un administrateur d'agir différemment au niveau d'un chemin d'URL HTTP, et cette directive ajoutée était une correspondance d'expression régulière insensible à la casse pour tout chemin comprenant le signe de pourcentage (%), et si ce signe de pourcentage est trouvé dans le chemin, il définit simplement quelques en-têtes et renvoie un 404.
Malheureusement, en raison de la manière dont Nginx gère les retours d'erreur 404, les en-têtes ajoutés dans cette directive ne sont jamais transmis au client, mais comme ces appareils Cisco semblent avoir un gestionnaire 404 personnalisé et que cette nouvelle directive de configuration remplace ce gestionnaire, nous obtenons un message d'état 404 différent (la version par défaut d'Openresty/Nginx) lorsque cette configuration est en place.
Nous nous trouvons en terrain instable lorsqu'il s'agit de déterminer l'état de cette porte dérobée, et nous ne sommes pas sûrs à 100 % qu'il s'agisse de la meilleure façon de mener ce type de tests, mais c'est le seul moyen dont nous disposons pour l'instant.
Quelle est donc la signification de ce signe de pourcentage ? Nous ne pouvons que supposer nos réponses car, dans la plupart des cas, un signe de pourcentage dans une URL peut traduire des caractères non imprimables en quelque chose qu'un serveur peut voir (par exemple, %41 == 'A'). Les attaquants tentent donc de cacher quelque chose, mais nous n'avons aucun moyen de le savoir avec certitude. Malheureusement, la plupart des organisations de sécurité comme Talos ne divulguent rien de plus que ce qu'elles publient, et c'est donc tout ce que nous savons.
Le 25 octobre, nous avons effectué un autre balayage secondaire de toutes les IP présentant des caractéristiques de type Cisco au cours des sept derniers jours (cela peut inclure la vérification de dispositifs qui ne sont pas spécifiquement Cisco XE, car nous examinons de manière plus générale tous les dispositifs de type Cisco, juste au cas où), à la recherche de tout dispositif qui répondra par le message 404 par défaut de Nginx/Openresty lorsque l'URI '/%25' est demandé. Notre liste d'entrée contenait plus de 135 000 dispositifs potentiels, et seuls 28 910 hôtes ont répondu avec ce qui ressemblait à un gestionnaire 404 par défaut d'Openresty/Nginx lors d'une requête '/%25', ce qui indique que la porte dérobée est installée.
Une fois de plus, nous ne pouvons pas dire avec certitude s'il s'agit d'un indicateur réel de compromission, mais ces appareils Cisco réagissent différemment lorsqu'ils demandent une ressource qui ne devrait pas exister sur ces hôtes. Par exemple :
Demande de /%25 sur un hôte précédemment compromis.
Demande d'un fichier aléatoire qui ne devrait pas exister sur un hôte précédemment compromis.
Ce qui intrigue dans cet incident, c'est à quel point tout était spécifique et ciblé. Cisco utilise Openresty, un serveur web basé sur Nginx qui permet de développer et d'intégrer Lua directement dans les fichiers de configuration - ce qui revient à déplacer le développement de l'application dans le serveur web lui-même ; cela ne sort pas de l'ordinaire puisqu'il y a actuellement environ 800 000 serveurs Openresty en ligne, ce qui n'est pas beaucoup, mais peut être considéré comme modérément populaire par rapport à d'autres technologies de serveur.
Bien qu'à première vue, il semble que ces attaquants aient brûlé leur jour zéro, il est évident qu'il s'agit d'une attaque coordonnée, bien planifiée et bien exécutée. Non seulement ils ont trouvé la vulnérabilité dans ces appareils (si la vulnérabilité n'a pas été achetée), mais ils ont également utilisé les technologies sous-jacentes fonctionnant sur ces appareils pour mettre en œuvre une porte dérobée. Cela signifie que des efforts raisonnables ont été déployés pour apprendre la technologie et mettre en œuvre les portes dérobées spécifiques au système.
Et bien que l'exécution n'ait pas été parfaite, ils ont appris de leurs erreurs et les ont rapidement corrigées. Nous avons déjà vu ce schéma à plusieurs reprises(Deadbolt, ESXiArgs) :
- Un incident se produit, l'information est rendue publique
- L'actualité et la recherche se propagent
- Les attaquants surveillent et adaptent leurs techniques pour déjouer l'identification et l'analyse.
- Répéter
Dans ce cas, nous avons reçu suffisamment d'informations pour trouver les premières compromissions, mais nous avons été rapidement bloqués lorsque les attaquants ont changé leurs méthodes et leurs techniques. Si cette nouvelle méthode de détection des compromissions est exacte, le nombre de dispositifs a considérablement diminué.
