Photo de Nick Bolton sur Unsplash La vulnérabilité log4j est apparue il y a deux ans environ, presque jour pour jour, gâchant les vacances de nombreux informaticiens de tout poil. Pour rappel, cette faille béante avait un score CVSS 3.0 de 10 (note maximale), car elle permettait à n’importe qui d’exécuter du code arbitraire sur n’importe quel serveur utilisant cette bibliothèque logicielle servant à la gestion des logs.
- Log4shell : les jours d’après
- Log4Shell : derrière l’importante faille, l’éternelle question du soutien au logiciel libre
Les impacts potentiels étaient si graves que même des organismes tels que le FTC (Federal Trade Commission) avaient brandi la menace de sanctions contre les entreprises ne se protégeant pas efficacement contre l’exposition à Log4Shell.
Aujourd’hui, fin 2023, on devrait donc être dans une situation stable et sans nuages. Eh bien, figurez-vous que non.
Pour l’instant, ça va ?
Cela ne surprendra pas ceux qui travaillent dans l’IT, qui savent que tout changement est problématique et que la marche vers la sérénité est longue et laborieuse. Pourtant les correctifs sont bel et bien disponibles !
Il y a bien eu quelques hésitations, mais on peut convenir qu’ils ont été rapidement mis à disposition, et comme il s’agissait d’une bibliothèque Java, on pouvait raisonnablement penser que mettre en place la version corrigée n’allait requérir qu’un effort modéré, surtout face aux risques encourus.
Patatras : une étude de la société Veracode réalisée entre les mois d’août et novembre de cette année nous apprend que, parmi ses clients (représentant 38 278 applications), une application sur trois utilisant log4j emploie encore une version vulnérable à la faille !
Le diable est dans le détail (des versions)
Regardons quand même de plus près les résultats :
-
- 2,8 % des applications utilisent une version vulnérable (de 2.0-beta9 à 2.15.0). Sur celles-ci, log4j pourrait s’appliquer sans problème ;
- 3,8 % utilisent une version plus récente (2.17.0) qui n’est pas vulnérable à Log4Shell mais qui est touchée par une autre faille, la CVE-2021-44832. Veracode explique ce chiffre par le fait que les équipes auraient voulu patcher très rapidement, mais sont vite passées à autre chose, oubliant ainsi de vérifier que le patch devait lui aussi être patché car vulnérable ;
- 32 % utilisent encore… la version 1, vulnérable et qui n’est plus maintenue depuis des années ! Et donc logiquement, cela veut dire que les 68 % restants sont en version 2.
D’autres éditeurs surveillent log4j : ainsi, Sonatype scrute également l’état des installations, avec de jolis graphiques en prime.
Cela illustre le phénomène de fenêtre d’attaque : un système reste vulnérable depuis la découverte jusqu’à l’installation du patch (ou de mesures d’atténuation), d’où l’intérêt pour un particulier (un utilisateur final) de faire des mises-à-jour constantes de son système pour réduire la durée de cette fenêtre.
Un patch peut certes toujours introduire une nouvelle vulnérabilité, mais qui nécessitera un autre mode d’attaque qui demandera du temps d’adaptation du côté des attaquants, donnant malgré tout un peu de répit (par rapport à la situation où on laisse une vulnérabilité connue non corrigée).
Dans une autre étude (State of Software Security v11), Veracode nous apprend aussi que 8 fois sur 10, l’équipe de développement ne met jamais à jour les logiciels tiers.
Et quand les mises-à-jour sont faites, elles s’arrêtent souvent aux versions mineures, car le gap à franchir entre versions majeures est souvent important : regardez la marche à suivre pour passer de log4j 1.x à 2.x, vous verrez qu’il n’y a rien de trivial et que cela représente donc une charge importante pour les équipes de développement.
Veracode pointe souvent le manque de ressources (de développeurs) ou d’information pour expliquer le manque de suivi et d’application des mises-à-jour.
On comprend mieux pourquoi c’est dans les vieux pots que les pirates font les meilleures confitures : les techniques d’attaque (d’exploitation des vulnérabilités) ont largement le temps d’être construites, testées, éprouvées et diffusées !
Sachez d’ailleurs que certains chercheurs s’amusent à faire une météo des attaques, un peu comme pour suivre le déplacement des nuages, mais en cherchant à suivre la diffusion des tactiques et des procédures dans le temps et l’espace géographique. Ça n’est qu’indicatif, mais cela illustre souvent les relations entre groupes d’attaquants.
Il y a vraiment des attaques ?
Cisco Talos attribue au groupe APT Lazarus (lié à la Corée du Nord) deux chevaux de Troie et un downloader exploitant la vulnérabilité Log4Shell en mars 2023.
Donc oui, tant que ça marchera, les pirates attaqueront !
Back to the future
Jetons maintenant un œil vers l’avenir. La CISA (Cybersecurity and Infrastructure Security Agency, chargée d'assurer la sécurité et la résilience contre les menaces liées à la cybersécurité aux États-Unis) s’est fendue de communications multiples et a fourni des outils pour aider à lutter contre cette vulnérabilité particulière :
Certains analystes nous prédisent même une bonne dizaine d’années avant de se débarrasser de ce problème. Un remède de bon sens consiste à automatiser la surveillance des vulnérabilités, surtout pour les bibliothèques tierces qu’on a trop tendance à oublier. Et bien sûr, une sécurité en profondeur, en plusieurs couches, est également une idée incontournable à l’heure des systèmes ultra-ouverts.
À condition de maîtriser ce qu’on fait, pas comme cette entreprise qui a mis à jour ses règles WAF (Web Application Firewall) juste avant l’attaque, la préservant ainsi de Log4Shell. Avant de s’apercevoir dans la foulée qu’aucune autre règle n’avait été activée depuis l’installation de l’outil…
Commentaires (12)
#1
M'en rappelle.
Me rappelle avoir pissé dans un violon devant des chefs de projets qui étaient uniquement pilotés par le métier et refusaient d'entendre toute considération technique. Leurs applications n'avaient quasi jamais de budget pour la maintenance du socle technique.
Me rappelle qu'aujourd'hui ça n'a pour ainsi dire pas changé.
Donc le constat ne m'étonne pas. Les projets de développement IT axés uniquement par le prisme du métier qui ne considèrent pas la technique sont une catastrophe.
Cela rappelle l'image récurrente qu'on voit lors des piratages médiatiques avec les trois jarres : mon budget sécu IT avant un piratage (pot quasi vide), mon budget sécu IT après un piratage (pot plein), et ma variante favorite : coût de la fuite de données (un pot rempli 3x plus gros).
#1.1
On se retrouve avec X logiciels installés dans les VLAN Office qui font exactement la même chose fonctionnellement parlant. Codé et installé avec le c... non connecté en SSO avec des comptes génériques de partout. Bref l'éclate totale en tant qu'archi quand ta mission c'est de remettre d'équerre le SI groupe. Gouvernance inexistante = SI de m... même avec la meilleure volonté du monde
#1.3
Complètement ce que je vis aussi
Et c'est grâce à ça qu'on découvre qu'on a des souscriptions AWS qui sont littéralement des fuites à thunes et données d'entreprise (avec tout en public et YOLO) car truc mis en oeuvre par un alternant à un moment et depuis plus maintenu, mais qui est devenu critique. Et n'oubliez pas le moment où les credentials de la sub se font poutrer que que vous vous retrouvez avec 500k€ de dépense en un mois car un russe a eu envie de miner du bitcoin sur votre compte (on aurait identifié la personne on aurait voulu l'embaucher, elle a su faire pop en une nuit 50 fois - sans exagération - plus de VM que les "experts" du domaine nous le vendaient au prix fort).
Autre cas courant : l'achat indésiré de licenses logicielles. Ah oui c'est facile de souscrire à un produit SaaS avec son mail d'entreprise en utilisant les offres "Personal". De le faire monter en puissance, en charge, en criticité. Puis un jour, on reçoit la facture.
Beaucoup ne se rendent pas compte que le Shadow-IT coûte une fortune dans le temps. Ah oui, à court terme c'est cool et ça fait un delivery immédiat, le TTM pète les scores. Mais hélas, le cliché du politique qui ne voit que son échéance électorale existe dans le privé aussi. Le décideur s'en fout car dans 3 ans il sera à un autre poste et ça ne sera plus sa responsabilité. Quant au prestataire, pareil, il aura changé de client.
Les gens avec une vraie conscience professionnelle sont une denrée rare. Et comme ils passent pour des chieurs, des bloqueurs, des empêcheurs d'avancer, ben ils deviennent encore plus rares.
#1.2
#2
Ca plus les gens qui pensaient être vulnérables car ayant log4j-api, alors que cet artefact est nullement impacté par la faille.
Bref, folklorique, et pour paraphraser ce que dit SebGF : l'informatique étant déjà un des enfants pauvre de l'industrie, la sécurité est elle-même l'enfant pauvre (façon tiers monde) de l'informatique.
C'est comme les masques FR (vs chinois) ou la pollution après le confinement, on reprend avec joie les vieilles mauvaises habitudes. Juste que désormais les recruteurs ne cherchent plus des devops mais des devsecops (et dans 3 mois, ajoutez "ai"). A mourir de rire.
#2.1
#2.2
J'en peux plus de ces clowns qui croient qu'une culture de travail est un métier perso. J'ai arrêté de compter les bots sur Linkedin qui me proposent un "poste de devops" (bullshit job qui n'existe pas) pour écrire de scripts Terraform.
/facepalm
#3
#4
Maintenant, il y a aussi reload4j pour éviter les problèmes de ce type pour log4j 1.
Par contre, si mes infos sont obsolètes et que log4j 1 est vulnérable "par défaut", je veux bien être détrompé. ^^
#5
Mieux : ils utilisent la library pour un truc dans une version, puis empilent les versions de library au fur et à mesure des version de la plateforme sans supprimer l’ancienne library (parce j’ai bout d’un moment personne ne sait plus si elle est appelée ou pas, dans un des méandres labyrinthiques des couches et surcouches du bordel. Les fichiers restent, d’install en install, actifs ou pas. Le « ça peut servir on sait jamais » et ça gène personne finalement : qui verra ça dans les 4589076 fichiers organisés en 8789 dossiers et sous dossiers.
Dès lors que la sirène sonne l’alerte générale, les IT de l’infrastructure se démènent comme des beaux diables : les scans sont lancés pour voir si « on a pas ça chez nous » et foutu malchance ils détectent le machin qui craint sa mère bien sûr : carabouilleSec 2.56.5B : houlala il faut vite agir. Ah mais y a aussi carabouilleSec 1.49.6F et CarabouilleSec 34H56, punaise des bois, on va tous mourir non ? c’est concerné ? etc etc. Un mec dit : pas grave on est en sécurité derrière le firewall. Un autre dit t’es fou on sait jamais. Au final c’est Bistouille 3.2 qui est utilisé pour le même besoin. Mais tout le monde s’excite car pas grand monde ne sait grand chose et personne ne veut couper la prod trop longtemps quand même. On monte des war room, des réunions de crise, des conf call à 60. Le métier ne veut pas qu’on arrête sa prod, accros qu’ils sont comme un camé au crack à leur bouzin, font vraiment chier les IT avec leurs conneries. L’IT gueule sur le business parce qu’ils se rendent pas compte ces cons, c’est pas le moment de faire chier, déjà qu’on risque de rater la dinde aux marrons avec leur merde de plate-forme qui nous les casse déjà assez comme ça en run., hein.
Bref la vie quoi
#6
On avait fait un audit de toutes nos applis, mis à jour et voilà.
L'avantage étant peut-être qu'on peut plus prendre le temps si un sujet super important déboule.
#7
En désespoir de cause, on a placé le restant derrière des reverse-proxies, avec des front sécurisés autant que possible (on a fait de même pour d'autres services applicatifs dont les serveurs d'application à jour n'étaient pas supportés). Quand on ne peut pas corriger la faille, on rajoute juste des champs de mines et du camouflage autour, en espérant que ça passera...