Piratage de l'infrastructure LineageOS via une vulnérabilité dans SaltStack

Développeurs de plateformes mobiles LineageOS, qui a remplacé CyanogenMod, averti sur l'identification des traces de piratage de l'infrastructure du projet. Il est à noter qu'à 6 heures du matin (heure locale) le 3 mai, l'attaquant a réussi à accéder au serveur principal du système de gestion de configuration centralisé. SaltStack grâce à l’exploitation d’une vulnérabilité non corrigée. L'incident est actuellement en cours d'analyse et les détails ne sont pas encore disponibles.

Aurait seulement que l'attaque n'a pas affecté les clés de génération de signatures numériques, le système d'assemblage et le code source de la plateforme - les clés étaient situés sur des hôtes complètement distincts de l'infrastructure principale gérée via SaltStack, et les builds ont été arrêtés pour des raisons techniques le 30 avril. À en juger par les informations sur la page statut.lineageos.org Les développeurs ont déjà restauré le serveur avec le système de révision de code Gerrit, le site web et le wiki. Le serveur avec les assemblys (builds.lineageos.org), le portail de téléchargement de fichiers (download.lineageos.org), les serveurs de messagerie et le système de coordination des transferts vers les miroirs restent désactivés.

L'attaque a été rendue possible grâce au port réseau (4506) permettant d'accéder à SaltStack n'était pas bloqué pour les requêtes externes par le pare-feu - l'attaquant a dû attendre qu'une vulnérabilité critique dans SaltStack apparaisse et l'exploite avant que les administrateurs n'installent une mise à jour avec un correctif. Il est conseillé à tous les utilisateurs de SaltStack de mettre à jour de toute urgence leurs systèmes et de rechercher des signes de piratage.

Apparemment, les attaques via SaltStack ne se sont pas limitées au piratage de LineageOS et se sont généralisées - au cours de la journée, divers utilisateurs n'ont pas eu le temps de mettre à jour SaltStack célébrer identifier la compromission de leurs infrastructures avec le placement de code minier ou de portes dérobées sur les serveurs. Y compris сообщается à propos d'un piratage similaire de l'infrastructure du système de gestion de contenu Ghost, qui a affecté les sites Web et la facturation de Ghost(Pro) (on prétend que les numéros de carte de crédit n'ont pas été affectés, mais les hachages de mots de passe des utilisateurs de Ghost pourraient tomber entre les mains d'attaquants).

Le 29 avril était Publié Mises à jour de la plateforme SaltStack 3000.2 и 2019.2.4, dans lequel ils ont été éliminés deux vulnérabilités (les informations sur les vulnérabilités ont été publiées le 30 avril), qui se voient attribuer le niveau de danger le plus élevé, car elles sont sans authentification permettre exécution de code à distance à la fois sur l'hôte de contrôle (salt-master) et sur tous les serveurs gérés via celui-ci.

  • Première vulnérabilité (CVE-2020-11651) est dû à un manque de vérifications appropriées lors de l'appel des méthodes de la classe ClearFuncs dans le processus salt-master. La vulnérabilité permet à un utilisateur distant d'accéder à certaines méthodes sans authentification. Y compris via des méthodes problématiques, un attaquant peut obtenir un jeton pour accéder avec les droits root au serveur maître et exécuter n'importe quelle commande sur les hôtes servis sur lesquels le démon est exécuté. sel-sbire. Le correctif éliminant cette vulnérabilité a été publié Il y a 20 jours, mais après l'avoir utilisé, ils ont refait surface régressif changements, entraînant des échecs et une interruption de la synchronisation des fichiers.
  • Deuxième vulnérabilité (CVE-2020-11652) permet, grâce à des manipulations avec la classe ClearFuncs, d'accéder aux méthodes en passant d'une certaine manière des chemins formatés, qui peuvent être utilisés pour un accès complet à des répertoires arbitraires dans le FS du serveur maître avec les droits root, mais nécessitent un accès authentifié ( un tel accès peut être obtenu en utilisant la première vulnérabilité et utiliser la seconde vulnérabilité pour compromettre complètement l'ensemble de l'infrastructure).

Source: opennet.ru

Ajouter un commentaire