Le 23 juillet, plusieurs services liés à Garmin ont été mis hors ligne, notamment leur centre d'appels et les services liés à l'aviation. Grâce aux informations divulguées par les employés de Garmin, nous savons que cette panne de plusieurs jours a été causée par la campagne de ransomware Wastedlocker. Après quatre jours, Garmin a pu démarrer le processus de restauration des services.

Il a été rapporté que la rançon demandée s'élevait à 10 millions de dollars. On soupçonne que Garmin a effectivement payé la rançon. Un programme de déchiffrement ayant subi une fuite confirme qu'ils ont reçu la clé de déchiffrement. L’attaque était apparemment très répandue sur le réseau de Garmin, car il semble que les postes de travail et les serveurs publics aient été touchés. Espérons que Garmin a appris sa leçon et renforce ses pratiques de sécurité.

KeePass

KeePass a publié une mise à jour cette semaine traitant de quelques failles dans le service KeePassRPC. L'annonce de la mise à jour est légère sur les détails, mais heureusement, nous avons l'histoire complète directement de (Philipp Danzinger), l'étudiant qui a découvert les vulnérabilités. Les deux vulnérabilités résident dans la mise en œuvre du protocole d'échange de clés SRP-6 (a).

Le composant vulnérable est le RPC. KeyPass est essentiellement une simple base de données contenant des mots de passe. Cette base de données est chiffrée à l’aide du mot de passe de l’utilisateur. Les mots de passe contenus ne peuvent donc pas être récupérés sans ce mot de passe principal. Lorsqu'un utilisateur lance KeePass, il ou elle est d'abord invité à entrer ce mot de passe principal, et la base de données est déchiffrée à l'aide de ce mot de passe. Le service KeePassRPC permet à d'autres processus, comme un plugin de navigateur, d'accéder à la base de données maintenant décryptée. La première fois qu'un nouveau client tente d'accéder au service RPC, une paire de clés est générée et l'utilisateur est invité à autoriser la nouvelle connexion. La clé publique est stockée et marquée comme approuvée, ce qui permet à ce client de demander à nouveau des mots de passe à l'avenir, tant que la base de données a été déverrouillée.

Le protocole d'authentification est similaire à un échange de clé DH. Une valeur partagée est élevée à la puissance de la clé secrète résultant en une valeur appelée UNE. Ceci est envoyé dans le cadre de l’échange de clés et la spécification formelle indique qu’il n’est jamais autorisé à être égal à 0. Le problème est que KeePassRPC ne vérifie pas correctement que UNE ! = 0. Quand UNE est mis à 0, tout l'échange de clé échoue, car toutes les valeurs finissent par égaler 0, car 0 ^ x est toujours 0. Cela signifie que tout client peut usurper un client déjà autorisé.

La deuxième vulnérabilité est un générateur de nombres aléatoires faible utilisé côté serveur pour générer la clé secrète b. Cette clé est basée sur la date et l'heure actuelles, exécutée via une fonction pseudo-aléatoire. Comme cette fonction est connue, si un attaquant peut deviner la valeur de temps exacte utilisée, alors la clé secrète est facilement calculée. Ce n’est pas aussi simple qu’il y paraît, car la valeur du temps est mesurée en «ticks», chaque tick étant de 100 nanosecondes. Il faudrait un peu de conjectures et quelques milliers de suppositions pour atterrir sur la bonne valeur, mais sans aucune limitation de débit, ce processus ne prendrait que quelques secondes.

Ce qui rend cette attaque très sérieuse est le fait que les navigateurs Web modernes permettent à Javascript de s'exécuter sur une page Web pour tenter de se connecter à localhost. Si votre base de données KeePass est déverrouillée et que vous chargez une page exécutant un JS malveillant, elle pourrait accéder au port RPC et usurper le plugin de navigateur KeePass autorisé et télécharger toute votre base de données KeePass. Heureusement, ce bogue a été divulgué en privé et KeePassRPC a été mis à jour à 1.12.1, ce qui ferme les deux vulnérabilités. De plus, la version 1.13 a depuis été publiée avec des garanties supplémentaires contre cette attaque et des attaques similaires.

Twitter

Twitter a commencé à afficher un avertissement de sécurité pour certains utilisateurs. Les détails sont extrêmement rares, mais voyons quels détails nous pouvons dégager. Tout d'abord, l'avertissement spécifie que le problème en question était une vulnérabilité dans l'application Twitter Android, mais qu'il était lié à une vulnérabilité Android, puis des liens vers la mise à jour de sécurité Android d'octobre 2018. En examinant les vulnérabilités révélées, il ne semble pas y avoir de candidat évident pour la vulnérabilité associée.

KDE Ark

Nous avons vu une technique très simple apparaître dans d'innombrables histoires de sécurité: le chemin transversal. C’est simple, vous pouvez inclure un ".." dans le chemin du fichier pour remonter dans un répertoire. Souvent, cela peut être inclus dans des endroits inattendus pour contourner les restrictions de sécurité ou faire d'autres choses involontaires. Les fichiers d'archive ne font pas exception, et rien n'empêche une archive zip d'avoir de tels chemins. La plupart des programmes d’archivage détectent ce comportement et ne permettent pas à l’archive de s’extraire telle qu’elle est écrite. La vénérable commande unzip se plaint comme ceci:

# unzip relative2.zip 
Archive:  relative2.zip
warning:  skipped "../" path component(s) in tmp/../../moo
 extracting: tmp/moo

KDE Ark, jusqu'à récemment, ne traitait pas ces chemins comme spéciaux et extrayait volontiers les fichiers vers le chemin auquel il était demandé. La mise à jour ne semble pas être officiellement publiée au moment de la rédaction de cet article, alors méfiez-vous de l'extraction aveugle d'archives jusqu'à ce que cette mise à jour soit disponible. Il existe un référentiel d'archives utile qui peut être utilisé pour tester divers problèmes transversaux, et j'ai confirmé celui-là en particulier (fichier zip inoffensif contenant tmp/../../moo) démontre le problème dans Ark.

Et enfin…

Tu te souviens de Boothole? Plusieurs fournisseurs ont poussé des correctifs à cette vulnérabilité de démarrage sécurisé Linux, et une poignée de systèmes non amorçables en a résulté. Pour le cas de RHEL et CentOS, une autre série de packages mis à jour a été publiée, corrigeant le problème et rendant à nouveau les systèmes amorçables.

Et que fait un criminel avec une violation de base de données? Apparemment, après les avoir vendus, ils les libèrent gratuitement. S'il ne s'agissait pas de données volées, j'appellerais cela une victoire. Une fois qu’une violation a rapporté autant d’argent que le vendeur pense qu’elle est susceptible de générer, il n’est pas rare que les données soient diffusées gratuitement. Ce ne sont pas des sites ou des services très populaires, mais cela peut valoir la peine de vérifier si vos données ont été incluses dans la version.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici