En janvier, nous avons couvert la nouvelle qu’Ubiquiti avait une violation de gravité non divulguée. Un lecteur a souligné que le compromis d’une poignée d’appareils était potentiellement lié. En l’absence de rapports similaires, je n’y pensais pas trop à l’époque. Maintenant, cependant, un lanceur d’alerte d’Ubiquiti a donné à Krebs les détails juteux.

Le «fournisseur de cloud tiers» auquel la divulgation initiale faisait référence était Amazon Web Services (AWS). Selon le lanceur d’alerte, à peu près tout était accessible, y compris les clés pour se connecter à n’importe quel appareil Ubiquiti sur Internet, tant qu’il était compatible avec le cloud. Les attaquants ont installé quelques portes dérobées dans l’infrastructure d’Ubiquiti et ont envoyé une menace de chantage de 50 bitcoins. À leur honneur, Ubiquiti a ignoré le chantage et a nettoyé le désordre.

À l’affirmation selon laquelle il n’y avait aucune preuve que les attaquants avaient accédé aux comptes d’utilisateurs, il semble que la base de données en question n’ait tout simplement pas de journalisation activée. Il n’y avait aucune preuve, car rien ne regardait. Jusqu’à présent, je n’ai vu que le seul rapport de compromission de l’appareil qui était potentiellement le résultat de l’attaque. Si vous aviez un appareil Ubiquiti devenu non autorisé entre décembre 2020 et janvier 2021, assurez-vous de nous le faire savoir.

Ransomware en mode sans échec

C’est une nouvelle astuce – Nous utilisons généralement le mode sans échec pour réparer les ordinateurs, mais une souche de logiciels malveillants en abuse pour les briser. L’idée semble être que votre antivirus ne fonctionne probablement pas en mode sans échec, de sorte que le processus de cryptage a plus de chances de réussir. D’un autre côté, le mode sans échec peut signifier que les dossiers partagés de votre serveur ne sont pas accessibles, limitant la destruction à un seul ordinateur.

Le truc sophistiqué pour faire ce travail est de mettre la charge utile dans un RunOnce clé de registre et préfixez le nom de la clé avec un astérisque. Cette incantation signale à Windows qu’il doit fonctionner même en mode sans échec. Le processus de cryptage retarde le lancement de explorer.exe, de sorte que la machine semblera se bloquer sur l’écran vide «Mode sans échec».

Brèche PHP Git

Un commit malveillant a été introduit dans le code de PHP le 27 et a été rétabli environ cinq heures plus tard. Le compte de développeur qui a transmis le mauvais code a été supposé être compromis et l’accès a été révoqué. Quelques heures plus tard, la réversion a été annulée par un autre compte développeur. Cette fois, le mauvais code était présent pendant moins de deux heures avant d’être rétabli avec le message de validation humoristique de Revert "Revert "Revert "[skip-ci] Fix typo""" Le consensus est que le serveur hébergeant le code PHP a probablement été compromis d’une manière ou d’une autre, et la décision a été prise de déplacer le processus de développement PHP vers GitHub.

Le code malveillant était assez simple. Il a vérifié une chaîne magique dans le useragent en-tête, et a exécuté le code PHP à partir de cet en-tête s’il est trouvé. Si une version de PHP avait été livrée avec ce code intact, les dégâts seraient stupéfiants, car il s’agirait d’une porte dérobée simple à utiliser dans chaque service Web utilisant PHP. Il convient de souligner que la nature open source du projet PHP a conduit à une découverte très rapide du code injecté, et en raison de cette vitesse, les dommages réels de cette attaque seront probablement essentiellement nuls. Cela ne semble pas être une attaque particulièrement sophistiquée, et elle n’a même pas été déguisée pour ressembler à du code innocent. Était-ce juste un essai?

Via Phoronix

Failles OpenSSL

OpenSSL vient de corriger une paire de bogues sérieux dans sa version 1.1.1k. Le premier est CVE-2021-3449, qui permet à une demande de renégociation malveillante de planter le serveur OpenSSL. C’est un déréférencement de pointeur nul, qui est notoirement difficile à transformer en un RCE complet, mais pas impossible.

Le deuxième bogue, CVE-2021-3450, est moins ennuyeux, mais potentiellement plus grave. Si OpenSSL est configuré pour vérifier un certificat et qu’un certain indicateur de mode strict est activé, un certificat auto-signé peut être accepté comme un certificat signé. Cela se produit car la vérification du mode strict peut écraser les résultats de la vérification de l’autorité de certification approuvée.

Malheurs de masque de réseau

Il y a une petite bizarrerie dans la façon dont les adresses IP sont écrites. Nous écrivons normalement une adresse IP au format «décimal pointillé». Considérez les trois adresses IP suivantes: 10.0.0.1, 010.0.0.1, et 0x10.0.0.1. Les deux premiers sont identiques et le dernier est une adresse invalide, non? En fait ça dépend. Si vous vous en tenez à ce qui est considéré comme un décimal pointé «standard», alors oui. Mais une des premières implémentations BSD de la notation décimale à points incluait également l’hexadécimal et l’octal. Cela est devenu une norme concurrente et apparaît de temps en temps. Voir l’image à droite pour un exemple surprenant.

Maintenant, qu’en est-il d’une bibliothèque comme celle de NPM netmask, qui vérifie si une adresse IP donnée fait partie d’un réseau défini? Masque de réseau .contains La fonction prend une chaîne en pointillé comme entrée et renvoie vrai ou faux selon que l’adresse IP se trouve dans le sous-réseau donné. Dans les versions antérieures à 2.0.0, il comprenait la notation décimale et la notation hexadécimale, mais ignorait le «0» dans le cas contraire. Cela signifie qu’une représentation octale serait plutôt comprise comme décimale. C’est un problème lorsque d’autres parties de votre application voient l’IP comme octale. Le contrôle de cohérence du masque de réseau pense que l’adresse IP fait partie du réseau local (10.0.0.1), alors qu’elle appartient vraiment à Level 3 Communications (8.0.0.1). Le front-end de sécurité voit la connexion comme venant du réseau local, alors qu’elle vient vraiment de l’extérieur.

Cette petite bizarrerie a été découverte par [Victor Viale], et corrigé par un groupe de chercheurs dont nous avons déjà examiné les travaux. En fait, il s’agissait des correctifs précédents du private-ip package qui a conduit à cette découverte. Ce paquet considère 0127.0.0.1 être une adresse privée. C’est correct… à moins que votre code ne comprenne 0127.0.0.1 être équivalent à 81.0.0.1. Faisons une petite expérience. Essayez de naviguer vers cette adresse IP ou envoyez un ping à cette adresse IP avec le 0 en tête. Comment votre navigateur ou votre terminal la comprend-elle? Le format octal est étonnamment largement accepté.

Maintenant, voici le kicker. Comment réparez-vous ceci? N’oubliez pas qu’il n’y a pas de RFC qui définit explicitement le fonctionnement de la notation en pointillés des adresses IP. Je suis convaincu que certains packages sur NPM ignorent les zéros non significatifs dans les adresses IP, et certains systèmes d’exploitation font probablement de même. Si vous changez netmask pour comprendre la notation octale, ces applications sont désormais vulnérables exactement de la manière que vous essayez de corriger. Quoi qu’il en soit, quelque chose va se briser.

Le versionnage sémantique aide ici, bien que ce ne soit pas une solution miracle. NPM utilise un système à 3 chiffres, commençant par 1.0.0 pour les versions initiales. Pour les corrections de bogues qui sont par ailleurs rétrocompatibles, incrémentez le troisième nombre. Pour les mises à jour avec de nouvelles fonctionnalités, mais qui ne brisent pas la compatibilité, incrémentez le deuxième nombre. Et enfin, pour les changements majeurs qui cassent la compatibilité ascendante, le premier nombre obtient la bosse. Netmask n’est plus rétrocompatible, donc le correctif a été publié en tant que 2.0.0. De nombreuses applications sont écrites avec une section de dépendances flexible, permettant une mise à jour automatique à la volée lorsque des correctifs de bogues sont publiés, mais pas de changement automatique des versions principales. Cela ne résout pas automatiquement le problème, mais encore une fois, ce n’était pas vraiment possible.

Remboursement du ransomware?

Bleeping Computer raconte l’histoire d’une campagne de ransomware qui fait quelque chose d’inattendu: rembourser la rançon aux victimes. Eh bien, c’est la revendication. Aucun bitcoin n’a encore été remboursé. L’affirmation est que les auteurs de logiciels malveillants ont peur des mesures d’application de la loi et prévoient de devenir des chercheurs légitimes après avoir remboursé la rançon. Vous m’excuserez si je suis un peu sceptique, mais cela semble trop beau pour être vrai. Le temps nous dira s’il s’agit d’une seconde arnaque ou d’un véritable changement d’avis.

Campagne de recherche Redux

Vous vous souvenez de l’APT nord-coréen qui ciblait les chercheurs avec une fausse société de sécurité et des liens malveillants? Les gens de Google qui gardent une trace de ces choses, le Threat Actor Group, ont averti que cette campagne était de retour sous un nom différent. «SecuriElite» est la nouvelle fausse société, et un nouveau gang de faux chercheurs est actif sur Twitter et LinkedIn. Autrement dit, ils étaient actifs jusqu’à ce que le TAG de Google déclenche l’alarme. Les attaquants iront probablement au sol pendant une semaine ou deux, puis surgiront ailleurs.