Joyeux Noël et bonnes fêtes! J’ai pris congé le jour de Noël pour rédiger le résumé de sécurité et suis venu un jour plus tôt au rythme de cette semaine pour éviter le jour de l’An. L’histoire de SolarWinds a continué de dominer l’actualité, alors approfondissons-la un peu plus.

Microsoft a publié leur analyse de Solorigateet les détails sont intéressants. Le code ajouté a été soigneusement écrit pour se fondre dans le reste du code en utilisant le nom OrionImprovementBusinessLayer.Initializece qui ressemble à une fonctionnalité parfaitement ennuyeuse mais légitime. La porte arrière réelle est obscurcie par la compression Zip et l’encodage Base64.

Une fois que ce code d’amorçage commence, il effectue une série de vérifications avant qu’une action malveillante ne soit réellement entreprise. Il attend 2 semaines après l’installation pour faire quelque chose, puis vérifie le nom de domaine du système pour les signes qu’il s’exécute dans un environnement de test. Il recherche ensuite certaines applications de sécurité comme Wireshark et refuse de s’exécuter si elles sont détectées. Cette série de vérifications semble être une tentative d’éviter la détection et ne doit être effectuée que dans un environnement déployé. Même l’URL de commande et de contrôle utilisée par la porte dérobée est conçue pour paraître inoffensive. De plus, il semble que le malware n’attendait que des instructions et n’effectuait aucune action automatisée. Toutes les attaques ont été menées manuellement.

L’un des effets secondaires de l’attention soudaine portée à l’équipement SolarWinds est qu’il détecte et corrige une foule d’autres problèmes, tels que: CVE-2020-10148, un contournement d’authentification. Le résultat le plus surprenant, cependant, est une * deuxième * porte dérobée en code SolarWinds surnommée Supernova. Il est possible que ce soit une porte dérobée précédente des mêmes acteurs que Solarigate, mais la théorie actuelle est qu’il s’agissait d’une porte dérobée qui a été installée par un autre attaquant indépendant.

Vulnérabilité dans les journaux pi-hole

Si vous avez un Raspberry Pi qui exécute le logiciel Pi-Hole, vous voudrez peut-être le patcher Une vulnérabilité d’interface d’administration récemment découverte. Le problème, CVE-2020-35659, est une vulnérabilité de script intersite qui pourrait permettre l’exécution arbitraire de JS en affichant le fichier journal. La charge utile est JS intégrée dans un nom DNS déclenché par la vue du journal. Bien que l’interaction de l’utilisateur soit requise pour afficher le fichier journal, il est extrêmement facile d’intégrer la requête DNS malveillante dans le journal. Il suffit d’une seule demande de ressource sur chaque site Web visité par un appareil sur le réseau. Le PoC n’a pas encore été publié pour donner à chacun le temps de se mettre à jour. Ce n’est pas une attaque sophistiquée. Une fois le reste des détails publiés, il devrait être facile d’adapter l’échantillon à une attaque du monde réel. Cependant, il n’est pas clair à quel point il est utile de pouvoir faire n’importe quel JS dans le contexte d’un pi-hole.

Bug de contournement du château gonflable

« Ne roulez pas votre propre cryptage » est toujours un principe valable, mais cela ne signifie pas que les implémentations populaires peuvent ne pas avoir de problèmes. Dans ce cas, l’implémentation Java de Bouncy Castle Un bug de codage dans les routines OpenBSDBcrypt. doCheckPassword est la fonction vulnérable et a un problème particulier. Notez donc d’abord que cette routine compare les hachages de mots de passe Unix encodés en base64 sous la forme de $y$j9T$fUtLoMA0qexwXogYTTY0K.$/jkWehjtTOASsLbYP5CVBxIiEY903Mukb7wtjjpIx4A. Jetez maintenant un œil au code Java vulnérable et voyez si le problème se produit:


boolean isEqual = sLength == newBcryptString.length();
for (int i = 0; i != sLength; i++)
{
    isEqual &= (bcryptString.indexOf(i) == newBcryptString.indexOf(i));
}
return isEqual;

Java n’est pas mon « premier » langage de programmation, mais ce code n’est pas particulièrement difficile à comprendre. La première ligne déclare la variable booléenne isEqual, qui sert de mémoire d’état pour la boucle. Cela renvoie toujours vrai car le code précédent non affiché ici vérifie déjà une longueur de 60. La viande de cet extrait de code est la boucle for qui itère de 0 à 59. Le problème est l’utilisation de indexOf(i). Le programmeur pensait apparemment que cette méthode renverrait le caractère à l’index i et comparerait les deux chaînes un caractère à la fois. Le problème est que indexOf effectue en fait une recherche pour le caractère donné et renvoie l’emplacement où il a été trouvé pour la première fois, ou -1 s’il n’existe pas. Lorsqu’un seul paramètre entier est affecté à cette méthode, il spécifie le caractère à rechercher en tant que valeur Unicode.

Ainsi, l’extrait de code ci-dessus compare en fait la position d’Unicode 0 (U + 0000) dans les deux chaînes, puis compare la position d’Unicode 1 (U + 0001) sur Unicode 59 (U + 0059). Unicode est un descendant de l’ASCII et hérite ses 128 premiers caractères directement de l’ASCII. Par conséquent, les caractères 0 à 31 sont des codes de contrôle qui ne font jamais partie d’un hachage de mot de passe. Les caractères 32-35, 37-45 et 58 et 59 sont des symboles qui ne feront jamais partie de la chaîne. 36 est le caractère « $ », et bien que ce caractère apparaisse dans les chaînes comparées, il est toujours dans la même position car les hachages de mots de passe Unix l’utilisent comme séparateur. Ainsi, le jeu de caractères que cette implémentation défectueuse vérifie réellement est le point, la barre oblique et 0-9. Et même dans ce cas, seule la première occurrence de chacun est vérifiée. Étant donné que « 2 » fait partie de la chaîne indiquant que le hachage utilise bcrypt, il est également effectivement ignoré indexOf() Renvoie uniquement la * première * position où un caractère a été trouvé. Cela nous laisse avec seulement 11 caractères sur 64 qui sont réellement vérifiés, et seulement leur première occurrence.

Les chercheurs de Synopsys ont découvert ce bug en octobre. Lors de leurs tests, ils ont découvert que tout mot de passe utilisant l’implémentation défectueuse de bcrypt de Bouncy Castle était vulnérable aux attaques. Ils estiment qu’environ 20% de ces hachages peuvent être contournés en moins de 1000 suppositions. La version 1.67 est sortie en novembre et corrige le problème. Ironiquement, la vulnérabilité était introduit dans un certain nombre de changements Ajout de comparaisons de constantes de temps. Le code est non seulement incorrect comme décrit, mais pas non plus constant dans le temps. Il a fallu presque un an à quelqu’un pour remarquer le problème, car la fonctionnalité fait * presque * la bonne chose.

Ceci et cela

Threatnix signale une nouvelle campagne de phishing, principalement axé sur les identifiants Facebook. Cette histoire particulière est intéressante car c’était la première fois que je me souvenais que des pages GitHub étaient utilisées pour héberger une telle campagne. Avec un peu de peine, les chercheurs ont pu télécharger la liste des identifiants de phishing, qui sont au nombre de plus de 600 000.

Au moins, les amis ne laissent pas leurs amis diffuser des images Docker peu fiables selon Prevasio. Là, les chercheurs ont mis en place un processus pour tester les quatre millions d’images sur Docker Hub pour les problèmes. Les résultats ne devraient pas surprendre. Environ la moitié de ces images contiennent des vulnérabilités de sécurité connues. Plus de 6 000 de ces images testées ont été classées comme malveillantes ou «potentiellement dangereuses».

Le CISA américano-américain a publié éventuellement en relation avec Solarigate moineau, un outil pour identifier une infrastructure Azure vulnérable. Parce que le code a été écrit par des employés du gouvernement, il est dans le domaine public.



Source link

Recent Posts