En marge des Assises de la Sécurité, Proofpoint, société leader en cybersécurité et conformité, dévoile aujourd’hui une nouvelle étude menée en collaboration avec l’institut Cybersecurity at MIT Sloan (CAMS), groupe de recherche interdisciplinaire.
The post Étude Proofpoint/MIT : les conseils d’administration sont-ils préparés à faire face à la menace cyber first appeared on UnderNews.Octobre marque comme tous les ans le mois de la cybersécurité. L’occasion de se pencher sur l’évolution des cybermenaces, les succès de l’année écoulée, mais aussi les causes des échecs. En effet, de nombreux préjugés, qui perdurent au sein des entreprises, continuent d’alimenter des vulnérabilités pouvant pourtant être facilement gommées.
The post Mois de la cybersécurité : se défaire des idées reçues first appeared on UnderNews.Sur plusieurs centaines d'instances SQL Server, des analystes en sécurité ont la découverte d'une nouvelle porte dérobée nommée Maggie ! Grâce à elle, les pirates exécutent des commandes à distance sur l'hôte compromis à l'aide de requêtes SQL malveillantes.
Tout d'abord, il faut savoir que ce sont les analystes en sécurité Johann Aydinbas et Axel Wauer de chez DCSO CyTec qui ont fait la découverte de cette backdoor. Une fois en place sur un serveur qui exécute une instance SQL Server, la porte dérobée Maggie est contrôlée grâce à des requêtes SQL qui lui donnent des instructions, notamment pour exécuter des commandes ou interagir avec des fichiers. Elle peut également servir à effectuer des attaques par brute force sur d'autres instances SQL.
En s'appuyant sur les données de télémétrie, les chercheurs en sécurité de chez DCSO CyTec ont pu créer une heatmap qui montrent où se situent les serveurs infectés par cette porte dérobée. On peut voir que les instances infectées se situent partout dans le monde, même s'il y a quelques pays plus touchés comme l'Inde, le Vietnam, la Russie, la Corée du Sud, l'Allemagne ou encore les Etats-Unis.
Sur un total de 600 000 serveurs analysés au niveau mondial, il s'avère que 285 serveurs sont infectés par la porte dérobée Maggie.
D'après l'analyse effectuée par Johann Aydinbas et Axel Wauer, cette porte dérobée se déguise sous la forme d'une DLL "Extended Stored Procedure" nommée "sqlmaggieAntiVirus_64.dll" ajoutée à SQL Server.
Ainsi, des fonctions supplémentaires sont ajoutées à SQL Server afin de prendre en charge de nouvelles commandes exécutables via une API à distance : Maggie apporte un ensemble de 51 commandes ! Il y a la possibilité de lire le contenu de fichiers, de mettre en place une redirection de ports, un reverse shell ou encore d'activer le Bureau à distance sur le serveur. La liste fait également référence à 4 exploits mais ils ne sont pas inclus avec la porte dérobée donc les chercheurs en sécurité n'ont pas pu les tester.
Par ailleurs, Maggie sert de relais pour atteindre n'importe quelle machine du réseau que l'hôte SQL Server est en mesure de contacter ! Ceci est possible grâce à une fonctionnalité de redirection TCP. Les analystes précisent : "Lorsqu'elle est activée, Maggie redirige toute connexion entrante (sur n'importe quel port sur lequel le serveur MSSQL est en train d'écouter) vers une IP et un port précédemment définis, si l'adresse IP source correspond à un masque IP spécifié par l'utilisateur".
Pour le moment, il reste des informations à déterminer : quel est le groupe de cybercriminels à l'origine de ces attaques ? Quelle est ou quelles sont les vulnérabilités exploitées initialement pour compromettre l'instance SQL Server afin de déployer la porte dérobée ?
The post Cyberattaques : des instances SQL Server infectées par la porte dérobée Maggie first appeared on IT-Connect.
Avec certains outils OSINT comme Blackbird que je vous ai présenté il y a quelques jours, il est possible de trouver des comptes en ligne à partir d’un simple pseudo. Mais l’information retournée n’est pas forcément fiable, car n’importe qui peut avoir le même pseudo que vous (j’en sais quelque chose).
Alors que faire ?
Et bien grâce à cet outil nommé holehe, vous pourrez analyser plus de 120 sites à la recherche de comptes à partir d’une simple adresse email. Évidemment, l’adresse email étant unique, pas de risque de taper à côté.
Mais comment s’y prend ce script pour trouver les comptes utilisant telle ou telle adresse email ?
Et bien c’est assez simple. Il vérifie qu’une adresse email est attachée à un compte en ligne en utilisant tout simplement la fonctionnalité « J’ai perdu mon mot de passe » de ces sites. D’ailleurs, sont présents dans cet outil, uniquement les sites qui ne préviennent pas immédiatement les utilisateurs qu’une demande de mot de passe perdu a été initiée.
C’est malin. Évidemment, ce n’est à utiliser qu’avec vos propres adresses email, sinon vous irez en prison comme d’habitude.
Vert c’est OK, rose y’a pas de compte et rouge on ne sait pas, car timeout. Rassurez-vous, ça peut détecter par exemple qu’un compte Twitter existe pour votre adresse email, mais l’outil ne vous donne pas le fameux compte Twitter.
Pour l’installer, vous pouvez utiliser PyPi :
FreshRSS 
pip3 install holeheOu cloner le dépôt comme ceci :
git clone https://github.com/megadose/holehe.git
cd holehe/
python3 setup.py installEnsuite, il n’y a plus qu’à appeler le script avec l’adresse email de votre choix :
holehe [email protected]Et si le site divulgue d’autres infos sur vous (nom complet, numéro de téléphone…etc.), le script vous informe également.
Il n’est pas rare de constater dans certaines entreprises que la mise à jour des serveurs est un sujet qui a été longtemps délaissé et dans le pire des cas, durant plusieurs années… La conséquence de cet oubli ? Une exposition accrue aux cyberattaques qui peut être d’autant plus coûteuse. A l’image des postes de travail, […]
The post Mise à jour des serveurs : mieux vaut se poser les bonnes questions first appeared on UnderNews.Depuis une décennie, octobre annonce le mois européen de sensibilisation à la cybersécurité. Maintenant plus que jamais, ses enjeux restent focalisés sur la protection des données à caractère personnel, et ses messages s’adaptent annuellement aux dangers numériques qui augmentent. C’est aussi l’occasion pour les consommateurs de s’y sensibiliser pour permettre une meilleure optimisation de celle-ci. […]
The post 10e édition du mois de la cybersécurité : en 2022 optez pour la biométrie first appeared on UnderNews.Globalement, on estime qu’une majorité des attaques qui frappent les entreprises concernent des données situées dans des environnements IT et solutions héritées. Dans de nombreux secteurs stratégiques comme l’industrie, les systèmes hérités fonctionnent sur des équipements souvent vétustes qui utilisent des OS complexes à mettre à jour, mais pourtant incontournables. Toutefois, pour prolonger la durée […]
The post La nécessité de sécuriser les systèmes critiques hérités first appeared on UnderNews.Octobre vient de démarrer et marque cette année encore le début du mois de la cybersécurité, un événement très important pour le secteur, en France mais aussi au niveau international. Son objectif est clair : sensibiliser les particuliers mais aussi les professionnels aux cybermenaces.
The post Mois de la cybersécurité : aller plus loin dans la sensibilisation et l’action first appeared on UnderNews.Des chercheurs en cybersécurité pour la protection des entreprises et plateformes internet viennent de publier un rapport sur de nouveaux virus. Une centaine d’applications ont été infectées au cours de ces trois dernières années par des virus sur Google Play Store et sur l’App Store d’Apple. En tout, cela représenterait environ 13 millions de téléchargements et cela ne choque plus personne. Les malwares ont été nommés Scylla et Charybde. Ils découlent du virus déjà connu appeler Poséidon. Dans les catalogues […]Dans ce tutoriel, nous allons apprendre à chiffrer un mot de passe dans un script PowerShell en utilisant le SID de l'utilisateur qui va générer la chaîne sécurisée. C'est une façon, parmi d'autres, de ne pas écrire le mot de passe en clair dans un script.
Ce mot de passe chiffré sera ensuite utilisable pour réaliser diverses actions : s'authentifier auprès de Microsoft 365, auprès d'Azure ou encore pour créer un compte Active Directory qui utilise ce mot de passe (cas d'un mot de passe par défaut que l'on attribue à tous les nouveaux utilisateurs.
Dans cet article, je vais utiliser deux commandes incontournables lorsque l'on manipule des chaînes de caractères sécurisées (SecureString) :
L'objectif va être de chiffrer le mot de passe "MonSuperMotDePasse" pour que l'on puisse l'utiliser dans le script sans qu'il soit visible en clair. Tout d'abord, on crée une chaîne sécurisée à partir de notre mot de passe qui est un texte brut, ce qui implique d'utiliser l'option "-AsPlainText". Le paramètre "-Force" est nécessaire lorsque l'on utilise "-AsPlainText" sauf si l'on utilise PowerShell 7+ (mais ça fonctionne quand même, car c'est toujours accepté pour des raisons de compatibilité).
$MotDePasse = "MonSuperMotDePasse" $MotDePasse = ConvertTo-SecureString -String $MotDePasse -AsPlainText -Force
Si l'on essaie de lire le contenu de cette variable ou que l'on regarde son type ($MotDePasse.GetType()), on voit qu'il s'agit d'une SecureString. C'est tout bon.
System.Security.SecureString
Ensuite, nous allons récupérer sous forme de texte la chaîne chiffrée, mais sans dévoiler notre super mot de passe :
$MotDePasse | ConvertFrom-SecureString
Une valeur est retournée dans la console. Par exemple :
Il s'agit du mot de passe chiffré : c'est cette valeur que nous allons utiliser dans la prochaine partie de cet article.
Maintenant, toujours à partir du même compte utilisateur, on va utiliser ce mot de passe et on peut aussi définir un nom d'utilisateur. La variable $Utilisateur contient le nom d'utilisateur, tandis que la variable $UtilisateurMdp contient le mot de passe sous la forme d'une SecureString. On utilise ConvertTo-SecureString sans le paramètre "-AsPlainText", car ici ce n'est pas un texte brute mais une chaîne déjà chiffrée que l'on veut stocker dans une SecureString.
Ce qui donne (on réutilise bien la valeur précédente) :
$Utilisateur = "[email protected]" $UtilisateurMdp = 01000000d08c9ddf0115d1118c7a00c04fc297eb010000006c76e757249edf429fc0ee5c2acb5b710000000002000000000010660..... | ConvertTo-SecureString
Ensuite, on peut vérifier que $UtilisateurMdp est bien une SecureString.
Il ne reste plus qu'à l'utiliser dans notre script !
Par exemple, nous pouvons créer un utilisateur dans l'Active Directory qui va hériter de ce mot de passe :
New-ADUser -Name "TestMdp" -AccountPassword $UtilisateurMdp
Dans le même esprit, pour s'authentifier sur Azure AD, sur Microsoft Teams, etc.
$Creds = New-Object System.Management.Automation.PSCredential($Utilisateur,$UtilisateurMdp) Connect-AzureAD -Credential $Creds Connect-MicrosoftTeams -Credential $Creds
Tout cela pour montrer que l'on peut utiliser la SecureString pour définir un mot de passe lors de la création d'un compte ou comme mot de passe dans le cadre de l'authentification sur un service.
Grâce à cette méthode, vous êtes capable de stocker un mot de passe chiffré dans un script PowerShell en utilisant une SecureString et sans qu'il soit visible en clair dans le code ! Il faut savoir que la chaîne chiffrée que l'on a générée dans cette mise en pratique est liée à l'utilisateur et à l'ordinateur, donc il faudra penser à la générer sur l'environnement cible directement pour éviter les dysfonctionnements (et mauvaises surprises). Pour que ce soit "portable", il faudrait s'appuyer sur une clé externe comme une clé AES, par exemple.
Si le sujet du chiffrement avec PowerShell vous intéresse, je vous recommande de regarder du côté de la commande PowerShell "Protect-CmsMessage" (associée à une méthode basée sur de la cryptographie asymétrique).
The post PowerShell : comment chiffrer un mot de passe dans un script ? first appeared on IT-Connect.Sébastien Vachon-Desjardins, ancien affilié au groupe de ransomware Netwalker, vient d'être condamné à 20 ans de prison suite aux cyberattaques contre plusieurs entreprises auxquelles il a participé. Il doit également renoncer à son gain de 21,5 millions de dollars.
Dans le rapport de jugement de Sébastien Vachon-Desjardins, nous pouvons lire : "Le défendeur est par la présente placé sous la garde du Bureau des prisons des États-Unis pour être emprisonné pour une durée de DEUX CENT QUARANTE (240) MOIS.", soit 20 ans de prison !
Cette lourde peine se justifie par plusieurs chefs d'accusation. En effet, Ce Canadien de 34 ans a été condamné par un tribunal de Floride après avoir plaidé coupable de "conspiration en vue de commettre une fraude informatique", de "conspiration en vue de commettre une fraude électronique", de "dommages intentionnels à un ordinateur protégé" et de "transmission d'une demande en relation avec des dommages à un ordinateur protégé".
Pour lui, les problèmes ne s'arrêteront pas après ces 20 années passées derrière les barreaux puisqu'à sa sortie, M. Vachon-Desjardins devra également purger trois ans de liberté surveillée. Pendant cette période, il n'aura pas le droit d'occuper un emploi dans le domaine de l'IT, ni d'utiliser un ordinateur connecté à Internet, un smartphone, une console de jeux ou un appareil électronique !
Et pour finir, le juge a pris la décision de lui confisquer son argent : 21,5 millions de dollars ! Il s'agit sans aucun doute d'une somme qu'il a obtenue grâce à ses activités malveillantes.
Sébastien Vachon-Desjardins a été arrêté au Québec le 27 janvier 2021, à cause de son affiliation au groupe de ransomware Netwalker (un ransomware-as-a-service) lancé en 2019. Lors de cette arrestation, les forces de l'ordre ont pu mettre la main sur 719 Bitcoins et 790 000 dollars canadiens. Ensuite, Vachon-Desjardins a été extradé vers les États-Unis en mars 2022.
À voir si cette lourde peine fait réfléchir certaines personnes qui participent aux activités de groupes ransomwares...! Quel est votre avis sur la question ?
The post Ransomware Netwalker : 20 ans de prison pour cet affilié canadien de 34 ans ! first appeared on IT-Connect.Il y a quelques jours, l'enseigne McDonalds France a-t-elle subi un piratage informatique donnant lieu à la divulgation d'une base de données avec 3 millions d'enregistrements ? Il s'agirait d'une fausse alerte... Mais à quoi correspondent ces données ?
À en croire l'article publié sur le site Zataz, McDonalds France serait dans la sauce... Plusieurs pirates informatiques ont échangé au sujet d'une base de données qui contiendrait 3 millions d'enregistrements correspondants à des informations de clients de McDonalds France. Parmi ces informations, il y aurait : nom, prénom, adresse e-mail, date de naissance et un historique des transactions PayPal (ce qui est surprenant). Le tout dans un fichier de 385 Mo.
La bonne nouvelle, c'est que les informations contenues dans cette base sont chiffrées, et sans la clé de déchiffrement, il n'est pas possible de visualiser les informations en claires. C'est appréciable de voir que McDonalds France traite ses données de cette façon ! De ce fait, tout cela n'est qu'hypothèse... Et ces informations proviendraient de l'application officielle de chez McDo.
Ensuite, Damien Bancal du site Zataz a pris le temps de contacter le service communication de McDonalds France, qui affirme qu'il y a eu une enquête et une analyse de cette base de données. Voici ce qu'il faut retenir de la réponse obtenue :
Pour le moment, les pirates cherchent à déchiffrer les données contenues dans cette base de données. Si les affirmations de McDonalds France sont vraies, alors on ne devrait pas avoir de mauvaises surprises s'ils parviennent à déchiffrer les données, et on peut considérer qu'il s'agit d'une fausse alerte !
The post Piratage de McDonalds France : une fausse alerte ? first appeared on IT-Connect.Dans cet article, nous allons apprendre à utiliser Locust, un outil de test de charge pour les services et serveurs web. L'idée du test de charge est d'évaluer la réaction et le comportement d'un serveur ou service web, d'un pare-feu, reverse-proxy, load-balancer ou même d'une solution de cache face à la navigation de plusieurs utilisateurs (10, 100, 1000) en même temps. Nous pourrons par exemple découvrir que lorsque 100 utilisateurs accèdent à la même page au même moment, notre serveur web montre des signes de faiblesse (temps de réponse allongé).
Locust se veut simple d'utilisation, sans interface graphique complexe. Il se paramètre et s'utilise majoritairement via du code Python. Ce dernier sert en effet à définir le comportement des utilisateurs que nous voulons simuler et à lancer le test de charge. Une interface web permet ensuite d'ajuster les derniers paramètres puis de suivre le test de charge et surtout d'obtenir des rendus sur les résultats obtenus.
Nous pouvons utiliser le gestionnaire de module Python pip pour installer locust (Python3) :
$ pip -V
pip 22.2.1 from /home/itc/.local/lib/python3.10/site-packages/pip (python 3.10)
$ pip install locust
Nous pourrons ensuite importer locust dans nos scripts Python :
$ python3
Python 3.10.5 [GCC 11.3.0] on linux
>>> from locust import *
Nous voilà prêts à réaliser notre premier script de test de charge avec Locust !
Pour commencer, faisons simple. Je vais ouvrir un mini serveur web HTTP avec Python dans un terminal :
python3 -m http.server
Cela me permettra d'avoir une cible pour mon script Locust, mais aussi de rapidement voir les journaux HTTP et constater si mon script se comporte comme je le souhaite. Créons un script simple, que je nomme /tmp/loc.py :
from locust import HttpUser, between, task
class WebsiteUser(HttpUser):
wait_time = between(3, 6)
def on_start(self):
self.client.get("/")
@task
def task1(self):
self.client.get("/")
@task
def task2(self):
self.client.get("/operation.php")
Première chose, pas besoin de spécifier l'URL/domaine cible dans le script, ce paramètre est géré plus tard via l'interface web. Nous allons à présent détailler notre premier script :
from locust import HttpUser, between, task
Importation du module Python locust est des fonctions utiles.
class WebsiteUser(HttpUser):
Création d'une classe WebsiteUser provenant du module Locust. Une instance de cette classe représente un utilisateur, qui pourra réaliser plusieurs requêtes/actions au cours du test.
wait_time = between(3, 6)
Délai d'attente de l'utilisateur entre chaque action, la valeur est ici sélectionnée aléatoirement entre 3 et 6 secondes. Au cours du test, nos utilisateurs seront créés tous en même temps ou au fur et à mesure et réaliseront des actions en boucle, avec un délai d'attente aléatoire entre chaque action.
def on_start(self):
self.client.get("/")
Définition du comportement de l'utilisateur lors de sa création, il ne réalisera cette action (ici, se rendre sur la racine de la cible web) qu'une fois.
@task
def task1(self):
self.client.get("/")
@task
def task2(self):
self.client.get("/operation.php")
Création de deux tâches, qui, elles, seront exécutées en boucle :
Ces tâches sont identifiées par le décorateur @task. Il faut bien noter qu'à la suite de la tâche réalisée, le script observe un temps d'attente (paramétré entre 3 et 6 secondes ici), puis sélectionne une autre tâche et la réalise.
Maintenant que nous avons un script, assez simple, il nous suffit de le lancer. Si vous avez installé Locust via pip, il y a de bonnes chances pour que le binaire locust se situe dans votre dossier bin/ personnel (~/.local/bin/locust). Si vous l'avez installé via apt/yum, il doit être dans le dossier des binaires standard (/usr/bin) donc déjà dans votre PATH :).
$ /~/.local/bin/locust -f /tmp/loc.py
[2022-10-01 15:29:52,466] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 15:29:52,481] itc-test/INFO/locust.main: Starting Locust 2.12.1
Nous pouvons à présent nous rendre sur l'interface web http://0.0.0.0:8089 :
Ici, on peut paramétrer le nombre total d'utilisateurs que nous souhaitons simuler et le nombre de créations d'utilisateurs par seconde. Par exemple, si je souhaite simuler 200 utilisateurs avec une création de 20 par seconde, j'aurai tous mes utilisateurs au bout de 10 secondes et chacun d'entre eux feront des boucles avec un délai d'attente de 3 a 6 secondes, puis une requête sur / ou /operation.php, tel que défini dans mon script.
Dans Advanced Options, le paramètre Run time permet de paramétrer une durée du test, utile pour faire des tests d'une durée équivalente entre plusieurs sites ou pour comparer des paramétrages différents côté service web.
Nous pouvons ensuite cliquer sur Start swarming, un tableau apparaîtra et détaillera le nombre de requêtes faites par point d'entrée, le nombre de fails, et différentes données sur les tailles et durée de réponse obtenue (à noter que RPS signifie request per second) :
Pour avoir des résultats parlant et contourner les limitations de capacité de mon environnement (voir chapitre "Limitations") j'ai donc monté une VM Linux avec 200 Mo de RAM, qui aura du mal à répondre à de multiples requêtes sur un réseau local d'hyperviseur. Également, j'ai créé sur ce service web une page index.html standard, et une page operation.php qui fait des opérations de chiffrement. Cela afin de simuler l'activité d'un serveur qui effectue des opérations dans une base de données afin de générer une réponse pour chaque requête. Je vous partage ici mon script pour information :
<?php
$s = "Welcome";
$ciphering = "AES-128-CTR";
$iv_length = openssl_cipher_iv_length($ciphering);
$options = 0;
$encryption_iv = '1234567891011121';
$round = rand(30,50);
for ($i =0; $i < $round; $i++)
{
$encryption_key = rand(1000000000,10000000000000);
$s = openssl_encrypt($s, $ciphering, $encryption_key, $options, $encryption_iv);
}
echo "s : $s\n";
?>
Pendant et à la fin de l'exécution d'un test de charge, il est possible de visualiser les données dans le tableau exposé plus haut, mais également dans trois graphiques (menu Charts).
Le dernier graphique montre la montée en charge des tests avec le nombre d'utilisateurs simulés en même temps (ici 5000 utilisateurs avec une création des utilisateurs par lot 50/seconde).
Le premier graphique indique en vert le nombre de requêtes par seconde et en rouge, nombre d'échecs par seconde (erreur HTTP/500 ou timeout). Le graphique du milieu décrit le temps de réponse médian (ligne verte) et pour le 95eme centile (ligne jaune). C'est le graphique le plus intéressant, car sans causer d'erreur, une surcharge du serveur web va entraîner des temps de réponse de plus en plus longs. Ce que l'on observe dans mon graphique ci-dessus.
Pour rappel, la moyenne est la moyenne arithmétique d'une série de chiffres. la médiane est une valeur numérique qui sépare la moitié supérieure de la moitié inférieure d'un ensemble (50% des requêtes obtiennent un temps de réponse supérieur au temps médian, 50% un temps de réponse inférieur
En statistique le quatre-vingt-quinzième centile est la valeur telle que 95 % des valeurs mesurées sont en dessous et 5 % sont au-dessus.
Le menu Failures permet d'avoir une idée du nombre de message d'erreur reçu et de la réponse du serveur :
Ici, on peut identifier des échecs de réponse côté serveur (pas de réponse/timeout).
Nous avons fait un script assez simple contenant deux tâches et des requêtes GET. En parcourant la documentation Locust. Vous remarquez qu'il est possible de faire des choses plus complexes.
Si l'on souhaite orienter le comportement de nos utilisateurs, il est possible de mettre un "poids" assigné à chaque tâche :
class WebsiteUser(HttpUser):
wait_time = between(3, 6)
def on_start(self):
self.client.get("/")
@task(1)
def task1(self):
self.client.get("/")
@task(3)
def task2(self):
self.client.get("/operation.php")
Avec ces valeurs (@task(1), @task(3)), les utilisateurs auront trois fois plus de chance de sélectionner la tâche 2 plutôt que la tâche 1, ce qui permet de simuler une tendance des utilisateurs à aller plus sur une page que sur une autre.
Si vous souhaitez simuler les comportements d'utilisateurs envoyant des données (par exemple : authentification), cela est également possible
@task
def task3(self):
self.client.post("/login", json={"username":"foo", "password":"bar"})
Il est également possible de répartir la charge de travail lors du test à l'aide de nœuds esclaves. Il faut pour cela lancer une instance en mode master :
$ ~/.local/bin/locust -f loc.py --master
[2022-10-01 10:27:47,041] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 10:27:47,056] itc-test/INFO/locust.main: Starting Locust 2.12.1
Les autres instances doivent être démarrées en mode worker et indiquer l'adresse IP du master:
$ /~/.local/bin/locust -f loc.py --worker --master-host=192.168.56.3
Lorsqu'un worker se connecte au master, le message suivant apparaît au niveau du master :
[2022-10-01 10:29:22,021] itc-test/INFO/locust.runners: Worker debian_77b92f24a7a54ac09ceeae99588e984b (index 0) reported as ready. 1 workers connected.
Attention cependant, dans ce cas, le master n'effectuera plus de requête lui-même. Il vous faudra donc au minimum deux workers pour avoir un gain de performance.
Je vous invite à consulter la documentation de Locust pour découvrir toutes ses possibilités : https://docs.locust.io/. Il est par exemple possible de lire le contenu des réponses puis d'afficher un message spécifique quand les résultats (menu Failures) afin d'avoir un tri plus personnalisé des messages d'erreurs et réponses du serveur.
Sans avoir testé toutes ses fonctionnalités, l'outil me paraît facilement personnalisable tant sur la partie test (comportement des utilisateurs) que sur la présentation des résultats.
Il est important de noter que des limitations peuvent exister dans vos environnements de test et empêcher Locust d'atteindre les charges demandées. Votre système n'est à lui seul pas en capacité de lutter contre un serveur digne de ce nom (à moins de trouver une vulnérabilité permettant de décupler votre force de frappe, type amplification). Ce dernier comporte des limitations comme le nombre de fichiers pouvant être ouverts en même temps, ou le nombre de connexions en attente pouvant être active en même temps. Par exemple, voici ce que j'obtiens si je souhaite simuler 10 0000 utilisateurs avec Locust sur une machine virtuelle (4 Go de RAM) :
À première vue, mon test a permis de faire tomber le serveur web, le nombre de "fail" ne fait qu'augmenter ! Cependant, si je regarde le menu Failures pour avoir les détails des messages d'erreurs obtenus, j'obtiens cela :
C'est mon système qui limite les tests (OSError - Too many open files), il ne parvient plus à ouvrir de fichier (il crée certainement un fichier socket par connexion ou utiliser un fichier pour stocker le résultat de chaque requête de façon temporaire). Mon système ici n'est tout simplement pas calibré pour simuler autant de connexions. D'ailleurs, Locust nous prévient rapidement de cette limitation :
# /home/itc/.local/bin/locust -f /home/itc/Documents/loc.py
WARNING/locust.main: System open file limit '1024' is below minimum setting '10000'.
It's not high enough for load testing, and the OS didn't allow locust to increase it by itself.
See https://github.com/locustio/locust/wiki/Installation#increasing-maximum-number-of-open-files-limit for more info.
En effet, vous pouvez toujours essayer de créer 2000 requêtes par seconde, si votre système ou l'infrastructure réseau n'est pas fait pour supporter une telle charge, Locust ne parviendra au maximum des capacités paramétrées et cela faussera vos tests.
Les limitations de vos tests peuvent également provenir de votre environnement réseau. Par exemple, j'ai fait mes premiers tests depuis une VM VirtualBox dont l'interface était paramétrée en mode NAT, ce qui impacte très durement les capacités réseau (Locust ne parvenait qu'à faire 9 requêtes par seconde). Le passage en bridge m'a permis de passer à 60 requêtes par seconde. Le tout pour un site situé sur Internet, chemin par lequel d'autres éléments peuvent freiner mon test (mon routeur, mon architecture réseau, etc.).
Également, si votre poste est en Wifi, il risque d'être rapidement limité par les capacités du point d'accès qui acheminera vos paquets jusqu'au serveur web testé.
Il faut donc être conscient de tout cela lorsque l'on fait un test.
Pour contourner ces limitations techniques, le plus simple semble de louer un serveur à haute capacité (réseau et système) chez un hébergeur cloud (OVHcloud, Azure, Google Cloud Platforme, AWS, etc.). Directement exposé sur Internet et profitant d'infrastructures musclées, ce serveur ne subira les freins et ralentissements éventuels de vos réseaux internes et vos tests ne perturberont pas vos utilisateurs.
Une deuxième option lorsque vous hébergez vos serveurs web dans votre propre Datacenter est de se brancher directement au serveur en question pour avoir un test qui sera le plus "violent" possible.
Dans un contexte réaliste, il ne faut pas oublier de tester non seulement le serveur web, mais aussi tous les composants qui peuvent y mener dans le cadre de l'utilisation de normale de ce dernier. Par exemple, lorsqu'un utilisateur parcourt votre site web depuis internet, il passe par votre routeur périphérique, votre pare-feu, potentiellement un système anti-DDOS, un reverse-proxy, etc. Ces éléments peuvent chacun constituer un point faible au niveau du test de charge : qu'est-ce qu'un SPOF ?
N'hésitez pas à poser vos questions et partagez vos expériences dans les commentaires ou sur notre Discord.
The post Serveur Web : tests de charge en Python avec Locust first appeared on IT-Connect.L'éditeur de solutions de sécurité Anozr Way a mis en ligne la 4ème édition de son baromètre d'évaluation de la menace ransomware. Un rapport qui montre à quel point la France est impactée par les attaques de type ransomwares.
De manière générale, si l'on regarde les chiffres de janvier à août 2022, l'Amérique du Nord reste la région du monde la plus touchée, avec 43% des attaques contre 35% pour l'Europe. Sur le Vieux Continent, l'ensemble des pays sont touchés, avec en tête l'Allemagne (7%) suivie par la France (5%) et l'Italie (4%).
D'après Anozr Way, 70% des attaques de ransomwares en France sont attribuées aux ransomwares LockBit 2.0 et LockBit 3.0 ! Une domination écrasante qui est inquiétante dans le sens où elle montre le niveau d'efficacité de ce groupe de cybercriminels. Dernièrement, le ransomware LockBit 3.0 a touché le Centre Hospitalier de Corbeil-Essonnes. Au niveau mondial, ce ransomware serait à l'origine de 41% des attaques !
Alors que le groupe Conti s'est éteint, les entreprises françaises ont dû faire face à de nouveaux groupes de cybercriminels comme Bl00dy, Cheers!, ou encore Red Alert.
Au total, et uniquement pour les entreprises françaises, la perte de chiffre d'affaires cumulé entre le 1er janvier et le 31 août 2022 atteint 1,06 milliard d'euros ! Ce chiffre énorme correspond uniquement aux pertes liées aux attaques par ransomwares : même si elles sont majoritaires, ce ne sont pas les seules attaques. Ceci ne tient pas compte non plus du paiement éventuel d'une rançon ! En moyenne, le montant s'élève à 128 000 euros par entreprise !
Que ce soit en France ou en Europe, ce sont les TPE-PME et les organisations du secteur public qui sont les plus touchées. Pour les TPE-PME, on parle d'une attaque sur deux, au niveau européen. Au niveau mondial, le nombre d'organisations victimes de ransomware est en augmentation et il devrait dépasser le niveau atteint en 2021. En effet, d'après Alban Ondrejeck, directeur technique et co-fondateur d'Anozr Way : "En 8 mois seulement, le nombre d'organisations victimes de ransomware dans le monde est déjà égal à 85% de l’ensemble de l’année 2021".
Vous pouvez télécharger le rapport de la société Anozr Way à cette adresse :
Le téléchargement implique de compléter un formulaire.
The post Les ransomwares en France : 70% des attaques attribuées à LockBit ! first appeared on IT-Connect.Suite à la divulgation des deux failles de sécurité zero-day dans Microsoft Exchange, la firme de Redmond a mis en ligne 2 mesures d'atténuation pour que les entreprises puissent se protéger en attendant un correctif de sécurité. Problème, des chercheurs en sécurité sont parvenus à bypasser ces mesures préventives. Faisons le point.
Depuis vendredi 30 septembre 2022, les failles de sécurité CVE-2022-41040 et CVE-2022-41082 font beaucoup parler d'elles, et visiblement, cela n'est pas prêt de s'arrêter avec ce nouveau rebondissement. Pour rappel, c'est l'entreprise GTSC qui est à l'origine de la découverte de ces vulnérabilités signalées à Microsoft par l'intermédiaire de la Zero Day Initiative. Toutes les versions d'Exchange 2013, Exchange 2016 et Exchange 2019 sont affectées, que ce soit les instances on-premise ou en mode hybride connecté à Exchange Online (dans le cas où le serveur Exchange on-premise est exposé sur Internet).
Suite à la publication d'un rapport au sujet de ces failles de sécurité, Microsoft a réagi en confirmant qu'elles étaient utilisées dans quelques attaques. Ensuite, l'entreprise américaine a partagé des solutions temporaires à appliquer pour limiter le risque d'exploitation de ces vulnérabilités.
Premièrement, il convient de bloquer les accès sur les ports 5985 et 5986 associés à la gestion à distance via PowerShell (connexion WinRM). Deuxièmement, il y a une règle à créer dans la configuration de IIS pour bloquer certaines requêtes malveillantes (plus de détails ici). Ceci peut être déployé à l'aide du script officiel EOMTv2.
Le chercheur en sécurité Jang affirme que cette règle dans IIS est trop limitée et après quelques efforts, il est parvenu à bypasser la règle afin d'exploiter ces vulnérabilités. De son côté, Will Dormann, analyste chez ANALYGENCE, est d'accord avec Jang et il affirme que le "@" dans l'URL fournie par Microsoft "semble inutilement précis, et donc insuffisant.". Pour valider les travaux de Jang, ce sont les chercheurs en sécurité de chez GTSC, à l'origine de la découverte de ces vulnérabilités qui ont validé que la protection n'était pas suffisante.
Pour que la règle soit en mesure de bloquer un plus grand nombre de requêtes malveillantes, elle doit être un peu moins précise. Jang suggère d'utiliser plutôt cette valeur d'URL dans la règle IIS :
.*autodiscover\.json.*Powershell.*
Si vous avez mis en place la règle dans IIS, vous n'avez plus qu'à adapter votre configuration. Microsoft n'a pas confirmé pour le moment qu'il fallait ajuster la règle dans IIS, et un correctif se fait toujours attendre.
La suite au prochain épisode...
The post Zero-Day dans Microsoft Exchange : la mesure d’atténuation déjà contournée ! first appeared on IT-Connect.En 2021, le groupe de cybercriminels Lazarus a utilisé une tactique d'attaque qui s'appuyait sur une vulnérabilité dans un firmware Dell pour déployer un rootkit sur Windows. Pour rappel, il s'agit d'un groupe sponsorisé par la Corée du Nord.
Les chercheurs en sécurité de chez ESET ont découvert et analysé des outils malveillants utilisés par le groupe de pirates Lazarus pendant l'automne 2021. Basée sur des e-mails aux couleurs d'Amazon, cette campagne du groupe Lazarus a ciblé un employé d'une entreprise néerlandaise spécialisée dans l'aérospatial, ainsi qu'un journaliste politique belge. Cette campagne est associée au nom "Bring Your Own Vulnerable Driver".
Dans ce rapport publié par ESET, on apprend que l'un de ces outils exploite la vulnérabilité CVE-2021-21551 qui affecte le pilote DBUtil, lié directement au BIOS (firmware) des machines Dell. Cette faille de sécurité a été corrigée par Dell en mai 2021 (voir cet article : Dell - 5 vulnérabilités découvertes dans le pilote DBUtil, utilisé depuis 2009).
En exploitant cette faille de sécurité avec leur outil FudModule, les cybercriminels du groupe Lazarus sont en mesure de désactiver toutes les fonctionnalités de protection de la machine Windows compromise. Les chercheurs d'ESET précisent : "Il utilise des techniques contre les mécanismes du noyau de Windows qui n'ont jamais été observées dans un logiciel malveillant auparavant." - Un rootkit particulièrement redoutable, même si l'exploitation de vulnérabilités dans les pilotes et les firmwares n'est pas nouvelle en soi.
Dans le cadre de cette campagne, le groupe Lazarus a utilisé d'autres outils malveillants, notamment leur porte dérobée "HTTPS" surnommée "BLINDINGCAN" (connue aussi sous les noms AIRDRY et ZetaNile). Grâce à elle, le pirate peut contrôler un système précédemment compromis, car elle lui sert de point de connexion.
Les différents outils et techniques utilisées par le groupe Lazarus montrent une nouvelle fois qu'ils sont bien organisés, et qu'ils sont agissent dans trois domaines de la cybersécurité : la recherche du gain financier, le cyber-espionnage et le cyber-sabotage.
The post Le groupe Lazarus a exploité une faille dans un pilote Dell pour déployer un rootkit first appeared on IT-Connect.
— Article en partenariat avec Surfshark —
Vous devez tous savoir ce qu’est le RGPD maintenant, non ?
En application depuis 2018, ce Règlement Général sur la Protection des Données vise à encadrer tout ce qui touche au traitement des données à caractère personnel sur le territoire de l’Union européenne. En gros cela permet à tous les citoyens (vous et moi) de faire valoir ses droits si une de ses données est utilisée à mauvais escient et hors du cadre prévu.
Et ce qui entre dans la catégorie « donnée personnelle » est assez vaste puisqu’il s’agit de tout ce qui permet de vous identifier. Des choses comme votre nom et prénom, votre adresse, votre email, une donnée biométrique ou votre numéro de sécu par exemple. Mais aussi des informations moins directes comme un identifiant sur un site web, vos géolocalisations, vos habitudes de surf, etc. Bref absolument tout ce qui permet de remonter jusqu’à vous, rapidement ou via le croisement de plusieurs données.
En France toute entreprise doit respecter ce règlement. Petit, grande, publique, privée, association, collectivité, sous-traitant … même une société étrangère qui exporte ou livre des produits en France doit s’y plier. Le citoyen (vous, moi, elle, lui et les autres) a donc une certaine maitrise sur ses propres données et cela à plusieurs niveaux.
Déjà parce que le service que vous utilisez (boutique e-commerce, outil web, inscription à une newsletter …) doit vous fournir une série d’informations avant même d’y souscrire. En général le truc barbant plein de mots que personne ne lit jamais, mais auquel tout le monde consent par flemme. Qui gère le traitement de vos données ? Dans quelles conditions ? Avec quelle finalité ? Est-ce que les données sortent à un moment de l’espace européen ? Etc.
C’est peut-être bête à dire, mais si vous ne voulez pas que vos données personnelles soient mal utilisées … la première chose à faire est de voir si le service en question annonce bien noir sur blanc qu’elles ne seront pas mal utilisées.
Maintenant nous sommes tous humains. On ne va pas chaque fois passer 5-10 minutes à vérifier que le site respecte bien les recommandations RGPD alors qu’on a encore 3,4 millions de vidéos de chats à regarder sur YouTube. Il faut choisir ses combats. Heureusement, même si vous vous rendez compte d’un souci par la suite, il existe ce qui s’appelle des droits. Et vous en avez plusieurs à votre disposition :
Bref il y a beaucoup d’options selon les cas, pas toujours simple de savoir quoi faire. Et je ne parle même pas de la prise de tête pour trouver les bonnes personnes à contacter, les bons documents à fournir, le temps de réponse entre chaque communication, etc., etc. Travail à multiplier par plusieurs dizaines de fois si vos données perso se trimballent dans plusieurs de ces services (appelés data brokers) où ils ne devraient pas être présents.
Plus vous passez de temps en ligne, plus vous balancez vos infos à gauche et à droite … et plus vous aurez de chances de vous retrouvez avec des utilisations non voulues de vos donnés. Le plus souvent sans même le savoir ou vous en rendre compte, hormis peut-être via un SMS ou un email d’un projet auquel vous êtes certain de ne jamais avoir donné vos infos.
Et c’est là qu’apparaît, baignant dans son halo de lumière, votre sauveur : Incogni.
Il y a quelques jours j’ai publié un article basé sur mon test du service Incogni. Je vous laisse le lire, mais vous y apprendrez que c’est quasi une centaine de demandes qui ont été gérées en mon nom via le service proposé par Surfshark. Je n’imagine pas les journées entières que j’y aurai passées si j’avais dû tout faire à la main. Donc depuis la date de mon test presque 1/3 des brokers contactés ont agi.
Alors oui le service est payant (moins de 6€/mois, ça reste correct), mais il rend un vrai service. Et lorsqu’un responsable des données reçoit une demande d’un service pro, cela a probablement plus de « poids » que votre mail personnel pour le motiver à appliquer les modifications nécessaires.
Gros avantage aussi, Incogni vous propose un tableau de bord via lequel vous pouvez suivre en temps réel l’avancée du nettoyage. Et connaître ce que chacun de ces data brokers avait comme infos sur vous et comment ils les utilisaient. Il me semble que ces derniers doivent répondre et faire les modifs en 30 jours. De plus l’outil surveillera que vos données ne réapparaissent pas comme par magie dans la base des services après quelques mois.
Cerise sur la tartiflette si vous habitez en Amérique du Nord, Incogni ne fait pas respecter que la réglementation européenne au niveau des données personnelles. Il gère aussi les lois CCPA et PIPEDA, sorte d’équivalent du RGPD en Californie et au Canada.
Microsoft a publié des informations supplémentaires au sujet des failles zero-day dans Microsoft Exchange. Faisons le point.
Désormais, ces deux failles de sécurité zero-day Exchange ont une référence CVE associée et nous savons quelles sont les versions de Microsoft Exchange affectées : Microsoft Exchange 2013, Microsoft Exchange 2016, et Microsoft Exchange 2019. À chaque fois, toutes les versions sont affectées, c'est-à-dire peu importe le "CU" qui est installé.
Sur son site, Microsoft précise : "La première vulnérabilité, identifiée comme CVE-2022-41040, est une vulnérabilité de type SSRF (Server-Side Request Forgery), tandis que la seconde, identifiée comme CVE-2022-41082, permet l'exécution de code à distance (RCE) lorsque PowerShell est accessible à l'attaquant". En résumé, nous avons donc :
D'après Microsoft, et c'est une précision importante, il convient d'être authentifié pour compromettre le serveur de messagerie Microsoft Exchange en exploitant ces deux vulnérabilités. Une attaque passe par l'exploitation des deux vulnérabilités, car la faille CVE-2022-41040 peut permettre à un attaquant d'exploiter la faille CVE-2022-41082 à distance, grâce à une requête malveillante.
L'entreprise américaine a confirmé que ces vulnérabilités étaient utilisées dans le cadre d'attaques.
Au sein de son article lié à ces failles de sécurité, Microsoft a mis en ligne des indications pour permettre aux entreprises de se protéger. Tout d'abord, la firme de Redmond a repris la solution proposée par la société GTSC, à savoir bloquer certaines requêtes sur le serveur IIS.
Même si tout cela est détaillé sur le site de Microsoft (avec des images plus ou moins visibles), voici en résumé :
1 - Sur le serveur Autodiscover frontend, ouvrez la console IIS, accédez au module URL Rewrite et Request Blocking (blocage de requêtes).
2 - Ajoutez la chaîne ".*autodiscover\.json.*\@.*Powershell.*" pour le chemin de l'URL
3 - Choisissez la condition d'entrée (input) suivante : {REQUEST_URI}
Si vous utilisez Microsoft Exchange, il est recommandé de mettre en place cette mesure protectrice dès que possible. Pour vous aider, Microsoft a mis en ligne son script "EOMTv2" sur GitHub.
Pour les administrateurs qui souhaitent vérifier si leur serveur Exchange a déjà été compromis, voici la commande PowerShell à exécuter (en précisant le chemin vers les journaux IIS, qui est par défaut "%SystemDrive%\inetpub\logs\LogFiles") :
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200
Ceci permet d'analyser les logs de IIS à la recherche d'une requête malveillante qui serait le signe d'une tentative d'exploitation.
En complément, et ça c'est nouveau par rapport aux informations publiées en fin de semaine dernière, Microsoft recommande de bloquer les ports associées à WinRM et à la gestion à distance via PowerShell, à savoir :
L'objectif étant d'éviter que l'attaquant puisse accéder au serveur à distance via PowerShell, car ceci est possible en exploitant ces deux vulnérabilités.
Le prochain Patch Tuesday sera mis en ligne par Microsoft le mardi 11 octobre 2022. Mais, il y a des chances pour qu'un correctif soit mis en ligne avant cette date afin de permettre aux entreprises de sécuriser leur serveur de messagerie dès que possible.
The post Zero-day Exchange : Microsoft donne des précisions et confirme la présence d’attaques ! first appeared on IT-Connect.
Similaire à Sherlock ou Nexfil dont je vous ai déjà parlé, Blackbird est un outil d’OSINT développé en Python qui permet de trouver tous les comptes de sites grand public liés à un pseudo.
Alors évidemment, si votre pseudo c’est « Bob », vous n’aurez pas de résultats exceptionnels. Mais si vous vous appelez GeraldZizipapan59300, vous taperez dans le mille, car c’est beaucoup plus spécifique.
Pour installer Blackbird, ouvrez un terminal et faite :
git clone https://github.com/p1ngul1n0/blackbird
cd blackbirdPuis lancez le serveur web comme ceci :
python3 blackbird.py --webVous pourrez alors accéder à une interface web via l’URL locale suivante :
http://127.0.0.1:9797Vous pourrez alors entrer n’importe quel pseudo et l’outil ira le tester sur plus de 570 sites web.
L’outil peut également s’utiliser en ligne de commande comme ceci :
python3 blackbird.py -u usernameEt récupérer un JSON qui contient toute la tambouille web lié au pseudo. Bref, de quoi beaucoup apprendre d’une personne.
