Dans ce tutoriel, nous allons apprendre à installer un serveur IIS sur une machine Windows 11, car oui IIS est disponible sur les versions desktop de Windows et pas seulement sur Windows Server ! D'ailleurs, ce n'est pas nouveau, car on peut le faire depuis l'époque de Windows Vista, c'est-à-dire IIS 7.0. Aujourd'hui, c'est IIS 10 qui sera installé sur la machine Windows 11, comme sur Windows Server 2022, et vous allez voir que c'est très simple. Cette version de IIS est déjà disponible depuis plusieurs années, comme nous le rappelle la documentation Microsoft.
Lorsque l'on veut mettre en place un serveur Web sous Windows, il n'est pas nécessaire d'installer "Apache for Windows" puisque l'on peut utiliser IIS, la solution développée par Microsoft. Si l'on tient à utiliser Apache, il me semble intéressant de partir sur une base Linux en s'appuyant sur WSL 2 pour monter un serveur LAMP (voir tutoriel ci-dessous).
À partir du menu Démarrer (1), recherchez "fonctionnalités" (2) afin de faire apparaitre l'entrée "Activer ou désactiver des fonctionnalités Windows" (3), car c'est ce menu qui va permettre d'installer IIS.
Ensuite, dans la liste recherchez puis cochez "Internet Information Services". Cela va permettre de cocher tous les éléments nécessaires par défaut, notamment "Console de gestion IIS" qui se trouve sous "Outils d'administration Web", puis toutes les fonctionnalités indispensables pour IIS. La partie "Serveur FTP" ne sera pas cochée par défaut (à vous de voir). Par la suite, vous pouvez revenir sur ce menu pour ajouter (ou supprimer) des fonctionnalités à votre IIS.
Cliquez sur "OK" et patientez pendant l'installation.
Une fois que l'installation est effectuée, vous pouvez ouvrir la console IIS, c'est-à-dire la console nommée "Gestionnaire des services Internet (IIS)". En cliquant sur le bouton "Aide" puis "A propos de Internet Information Servies (IIS) Manager", vous allez obtenir cette fenêtre :
Voilà, c'est officiel, IIS est opérationnel sur la machine Windows 11 ! Pour aller plus loin et commencer à manipuler la console IIS si vous n'êtes pas familier avec ce serveur Web, je vous invite à lire les autres tutoriels sur le site ! Voici quelques exemples :
Si vous rencontrez l'erreur "sudo: unable to resolve host" lors de l'exécution de la commande "sudo" sur une machine Linux, en l'occurrence Debian dans mon cas, je vous invite à suivre ce tutoriel pour obtenir la solution à ce léger problème. La bonne nouvelle, c'est que ça va être très rapide !
Tout d'abord, il y a des chances que ce problème soit survenu sur votre machine après avoir renommé le système. Une opération anodine en soit, qui va venir modifier le contenu du fichier "/etc/hostname". Alors, pourquoi cette erreur est-elle obtenue ?
II. Corriger l'erreur "unable to resolve host"
Tout d'abord, il faut récupérer le nom actuel de la machine, via la commande suivante :
hostname
Le nom de l'hôte sera retourné, par exemple "nom-serveur". Quant au message "unable to resolve host", il signifie qu'il n'est pas possible de trouver l'adresse IP correspondante à la machine "nom-serveur". Donc, puisque le nom d'hôte de la machine n'est pas forcément renseigné sur un serveur DNS, il faut s'appuyer sur la résolution de nom locale via le fichier "/etc/hosts" pour s'attaquer à la résolution de ce problème.
Ensuite, passez en root sur le serveur :
su -
Puis, ouvrez le fichier hosts :
nano /etc/hosts
Dans ce fichier, il y a des chances pour que vous ne voyiez pas le nouveau nom de votre serveur ! Peut-être que vous avez ceci :
127.0.0.1 localhost
ou encore ceci :
127.0.0.1 localhost
127.0.0.1 ancien-nom
Il va falloir apporter une modification au fichier afin d'indiquer que le nom du serveur, en l'occurrence "nom-serveur", corresponde à l'adresse IP "127.0.0.1" pour que la machine puisse se trouver elle-même via le nom grâce à son adresse IP de loopback. Il suffit d'ajouter la ligne à la suite de celle "localhost" qu'il faut conserver impérativement :
127.0.0.1 localhost
127.0.0.1 nom-serveur
Ce qui donne :
Si l'ancien nom du serveur se trouve dans le fichier "hosts", remplacez-le directement par le nouveau nom plutôt que d'ajouter une ligne.
Voilà, enregistrez le fichier et le tour est joué ! Désormais, la commande "sudo" ne doit plus retourner cette erreur!
L'entreprise Palo Alto Networks a informé ses clients que certains de ses produits, notamment les firewalls, étaient vulnérables à une faille de sécurité importante dans OpenSSL. Il s'agit de la vulnérabilité CVE-2022-0778 découverte il y a plusieurs semaines.
Pour rappel, lorsque la vulnérabilité CVE-2022-0778 est exploitée elle entraîne une "boucle infinie" qui mène à un plantage du serveur. Présent dans le paquet OpenSSL, cette faille se situe dans une fonction appelée BN_mod_sqrt() qui est utilisée pour réaliser un calcul mathématique. OpenSSL a publié un bulletin de sécurité au sujet de cette faille le 15 mars 2022.
Dans la pratique, une personne malintentionnée pourrait exploiter cette vulnérabilité afin de réaliser une attaque de type déni de service sur l'équipement Palo Alto ciblé. De son côté, Palo Alto Networks vient de mettre en ligne des informations pour indiquer comment se protéger de ce bug de sécurité. L'entreprise américaine précise : "Les logiciels PAN-OS, GlobalProtect app et l'agent Cortex XDR contiennent une version vulnérable de la bibliothèque OpenSSL et la disponibilité des produits est affectée par cette vulnérabilité. Pour le logiciel PAN-OS, cela inclut les pare-feu matériels et virtuels, les appliances Panorama ainsi que les clients Prisma Access.". Concernant l'agent Cortex XDR et GlobalProtect, l'exploitation est plus difficile, car il faut réaliser une attaque man-in-the-middle pour réussir son coup.
Palo Alto précise que ce bug de sécurité impact PAN-OS de la version 8.1 à la version 10.2, ainsi que toutes les versions de l'agent Cortex XDR et de l'app GlobalProtect. A l'inverse, deux produits ne sont pas touchés : Prisma Cloud et Cortex XSOAR. Au sein du bulletin de sécurité, c'est précisé : "Nous avons l'intention de corriger ce problème dans les versions suivantes : PAN-OS 8.1.23, PAN-OS 9.0.16-hf, PAN-OS 9.1.13-hf, PAN-OS 10.0.10, PAN-OS 10.1.5-hf, PAN-OS 10.2.1, et toutes les versions ultérieures de PAN-OS. Ces mises à jour devraient être disponibles au cours de la semaine du 18 avril 2022.".
Les hotfixes pour PAN-OS sont toujours en cours de développement, mais les clients avec la licence "Threat Prevention" peuvent activer les protections avec les ID 92409 et 92411 pour bloquer les attaques liées à cette vulnérabilité, et réduire la possibilité d'utiliser les exploits connus.
Même si l'impact de cette vulnérabilité se limite à un déni de service, cela peut rapidement générer de fortes perturbations sur un élément aussi central qu'un pare-feu.
Dans ce tutoriel, nous allons voir comment la solution open source CrowdSec peut nous aider à protéger un serveur sous Windows en bloquant les attaques informatiques de différents types : brute force sur la connexion "Bureau à distance" (RDP), scan d'un site Web IIS, etc...
Ce n'est pas la première fois que je vous parle de CrowdSec, car c'est une solution qui monte clairement en puissance depuis plusieurs mois. Par contre, c'est la première fois que je vous parle de CrowdSec sur Windows et pour cause la version Alpha est disponible ! Une version stable devrait voir le jour prochainement, mais en attendant, n'hésitez pas à tester de votre côté et à remonter les éventuels bugs aux équipes de CrowdSec (il y a un Discord à disposition).
Pour le moment, CrowdSec est capable de surveiller les services suivants :
RDP et SMB pour les attaques brute force (exemple : tentative de connexion malveillante sur un partage de fichiers)
IIS pour les attaques HTTP/HTTPS notamment les scans de sites à la recherche de vulnérabilités
SQL Server pour les attaques brute force
Pare-feu Windows pour les scans réseau
Note : cette version Windows supporte la majorité des services déjà pris en charge sur Linux puisque les journaux sont générés selon les mêmes formats. Par exemple, Nginx va générer les mêmes journaux sous Linux et sous Windows.
Avant de rentrer dans le vif du sujet, voici les liens vers mes autres articles CrowdSec :
Aujourd'hui, nous allons nous intéresser à deux cas de figure :
Le blocage d'une attaque brute force sur une connexion RDP (à partir du client "Bureau à distance" de Windows, par exemple)
Le blocage d'un scan d'un site web hébergé sur un serveur IIS
Pour mon lab', je vais utiliser :
Une machine à protéger avec CrowdSec : un serveur virtuel sous Windows Server 2022 (mais vous pouvez utiliser une autre version de Windows) hébergé sur le Cloud Azure
Une machine qui sert à simuler des attaques : un serveur virtuel sous Kali Linux avec quelques outils (une machine Kali Linux via WSL fonctionnera aussi)
III. Mise en place de CrowdSec sur Windows
Commençons par télécharger les sources d'installation de CrowdSec. Pour le moment, les sources ne sont pas disponibles sur GitHub mais à cette adresse : Crowdsec pour Windows.
A. Installation de CrowdSec sur Windows
Lorsque le MSI est installé sur une machine Windows, il va permettre d'installer CrowdSec dans "C:\Program Files\CrowdSec\", mais aussi de télécharger la collection Windows, d'enregistrer l'instance auprès de l'API Centrale et de créer le service CrowdSec (afin qu'il démarre automatiquement en même temps que Windows).
Je ne vais pas m'attarder sur l'installation, car quelques clics suffisent pour en venir à bout.
B. Installation du bouncer Pare-feu Windows
Avant de lancer l'installation du bouncer, il faut que l'on installe une dépendance : .NET 6 Runtime. Sinon, l'installation du bouncer ne va pas se dérouler correctement. Par la suite, cette dépendance sera intégrée au package du bouncer pour que ce soit plus simple, mais je vous rappelle qu'il s'agit d'une version alpha.
Il est important de télécharger le ".NET Runtime" et non un autre élément, puis de bien prendre la version Windows au format "Installer". En l'occurrence en x64 dans la colonne "Installers" pour mon serveur Windows en 64 bits.
L'installation est également très simple, il suffit de suivre l'assistant...
Une fois que c'est fait, on peut enchaîner sur l'installation du bouncer "Windows Firewall" en exécutant le package correspondant. Suivez l'assistant afin de l'installer et nous en aurons terminé avec les installations de packages.
Ouvrez une console sur la machine Windows et listez les bouncers :
cscli bouncers list
La commande retourne "windows-firewall-bouncer", ce qui est une bonne nouvelle !
CrowdSec est prêt à l'emploi, nous allons pouvoir le tester dans différents cas de figure.
IV. Tester la protection CrowdSec
Pour tester l'efficacité de CrowdSec et voir sa capacité à protéger le serveur Windows, je vais prendre deux exemples :
La protection d'un serveur Web "IIS"
La protection de l'accès RDP (Bureau à distance)
A. CrowdSec et IIS
Avant de tester CrowdSec, on va s'intéresser au serveur IIS en lui-même, car il faut bien faire les présentations. C'est un serveur tout simple, avec le site par défaut et une page qui affiche un texte, le tout accessible sur une adresse IP publique en HTTP. En image, cela donne :
Quant aux logs de ce serveur IIS, ils sont stockés dans es fichiers de logs à l'emplacement par défaut.
Avec IIS, on peut stocker les logs dans des fichiers, dans l'observateur d'événements ou bien aux deux endroits. Pour connaître l'emplacement des logs du serveur, il faut ouvrir la console IIS, cliquer sur le serveur en haut à gauche, puis sur "Journalisation". Une fenêtre apparaît et il y a deux champs particulièrement intéressants :
Répertoire : le chemin vers les fichiers journaux
Destination des événements de journal
Voilà, vous en savez un peu plus sur la configuration de mon serveur IIS. Désormais, il est grand temps de passer à l'action.
Actuellement, CrowdSec n'est pas suffisamment configuré pour protéger notre serveur IIS. D'ailleurs, on peut le vérifier assez facilement... Tout d'abord, on va lister les décisions actives afin de voir les adresses IP actuellement bannies :
cscli decisions list
Tiens, il y a quelques adresses IP... Cela signifie que CrowdSec a déjà bloqué des attaques. Concernant la raison, on peut voir "windows-bf", ce qui correspond à du brute force Windows, en l'occurrence ici sur l'accès RDP, car je l'ai volontairement exposé sur Internet (pour le second test).
En revanche, depuis une machine distante, je peux scanner mon serveur IIS avec différents outils tels que Nikto sans être bloqué par CrowdSec !
nikto -h http://ip-publique-serveur-iis
Je tiens à vous rassurer : c'est normal. Il va falloir que l'on modifie la configuration de CrowdSec afin de lui indiquer où se situent les journaux de IIS, et lui faire comprendre qu'il doit surveiller ce service sur le serveur Web. Avant cela, nous devons installer la collection IIS sur le serveur grâce à cette commande :
cscli collections install crowdsecurity/iis
L'installation va s'effectuer en quelques secondes...
Vous pouvez vérifier que c'est OK grâce à la commande suivante :
Vous pouvez voir la présence d'un chemin "dynamique" : "C:\inetpub\logs\LogFiles\*\*.log". Cette valeur va permettre à CrowdSec de trouver et lire les fichiers de logs situés dans "C:\inetpub\logs\LogFiles\W3SVC1" et de les analyser. Si vous utilisez un autre chemin, voire même un autre volume pour les logs, vous devez adapter cette valeur.
Dans le bout de code que l'on vient d'ajouter, il y a un paramètre sur lequel je souhaite attirer votre attention : use_time_machine. IIS n'écrit pas les logs en temps réel dans le fichier journal, mais il écrit les nouveaux événements en bloc, chaque minute. Grâce à ce paramètre, CrowdSec va lire la date et l'heure de chaque ligne pour se repérer et traiter les événements chronologiquement.
Par contre, si vous n'utilisez pas les fichiers de logs mais l'observateur d'événements, vous devez utiliser ce bout de code et non celui mentionné précédemment :
Enregistrez le fichier acquis.yaml et vous pouvez le fermer. Pour finir, nous devons redémarrer le service CrowdSec, comme ceci :
Restart-Service crowdsec
Je vous propose que l'on revienne à la charge depuis l'hôte distant et Nikto.
nikto -h http://ip-publique-serveur-iis
Cette fois-ci, les choses se gâtent... Nikto affiche une erreur et il m'indique "can't connect (timeout)". Intéressant.
Sur le serveur IIS protégé par CrowdSec, je vais lister les décisions actives pour voir...
cscli decisions list
Tout s'explique : mon hôte distant est banni par CrowdSec ! On peut voir la raison "http-probing", ce qui signifie bien que l'attaque cible le service Web et donc IIS.
Mon hôte distant n'a plus accès à mon serveur, ce qui explique le "timeout" dans Nikto.
Puisque l'on utilise un bouncer qui s'appelle "Windows Firewall", on devrait en toute logique retrouver des informations sur les adresses IP bannies directement dans les règles de pare-feu Windows. C'est bien le cas, il y a plusieurs règles créées et gérées par CrowdSec. En recherchant dans l'une des règles, je suis parvenu à retrouver l'adresse IP de mon hôte distant depuis lequel j'ai émis le scan Nikto.
Quand une machine est bloquée, elle est totalement bloquée c'est-à-dire sur tous les ports et tous les protocoles.
Note : par défaut, une machine est bannie pour une durée de 4 heures, mais si vous souhaitez ajuster cette valeur, il suffit de modifier le paramètre "duration" du fichier "profiles.yaml". Pensez à redémarrer le service CrowdSec pour appliquer la modification.
B. CrowdSec et RDP
Parlons de notre second cas : la protection de l'accès RDP. Pour les raisons de cette démo, j'ai fait quelque chose de mal : j'ai publié mon serveur sur Internet, sur le port 3389 correspondant au port par défaut du protocole RDP. Ainsi, il est à la merci des bots en tout genre.... Ce qui explique pourquoi mon instance CrowdSec a rapidement banni quelques adresses IP (comme vu précédemment).
Pour effectuer un brute force RDP, on pourrait tout simplement ouvrir le client Bureau à distance de Windows et effectuer des tentatives en boucles. Pour que ce soit un peu plus cool, nous allons utiliser l'outil Crowbar. Nous avons le droit à un match : CrowdSec VS Crowbar. Crowbar est un outil pour faire du brute force qui supporte plusieurs services : RDP, OpenVPN, SSH et VNC.
Afin d'utiliser Crowbar sur ma machine où se situe Nikto et qui tourne sous Kali Linux, je dois installer le paquet :
sudo apt-get install crowbar
Ensuite, il ne reste plus qu'à cibler mon accès RDP de cette façon :
La commande ci-dessus cible l'adresse IP publique de mon serveur, et va essayer l'utilisateur "florian" avec le mot de passe "MonMotDePasse1". Pour que ce soit plus réaliste, on peut utiliser un dictionnaire de mots de passe... Pour ce faire, je crée un petit dictionnaire "dico.txt" sur ma machine :
Puis, je repars à l'assaut de mon serveur en utilisant ce dictionnaire (l'option -c est remplacée par -C). Cette fois-ci, on va effectuer une réelle attaque brute force car Crowbar va tester tous les mots de passe de mon dictionnaire.
Visiblement, il n'est pas parvenu à se connecter...
Par contre, il s'est fait repérer par CrowdSec ! Du coup, l'adresse IP publique utilisée par l'hôte Crowbar est bannie à son tour !
cscli decisions list
Pour détecter les attaques par brute force sur l'hôte Windows, CrowdSec regarde l'observateur d'événements de la machine, et plus particulièrement les événements avec l'ID 4625 du journal sécurité. En effet, une ouverture de session en échec génère un événement de ce type.
Fin de partie : le grand gagnant de ce duel est CrowdSec !
Nous venons de voir, au travers de ces deux exemples, l'intérêt de mettre en place un outil de sécurité tel que CrowdSec sur un serveur Windows afin d'augmenter le niveau de sécurité. Le portage de CrowdSec sur Windows s'annonce prometteur et l'outil fonctionne bien même s'il ne s'agit que d'une version alpha.
Même si j'ai simulé des attaques provenant de l'extérieur et que tous les serveurs Windows ne sont pas publiés sur Internet (surtout en RDP comme je l'ai fait), CrowdSec peut très bien vous protéger contre une attaque qui émane de l'intérieur de votre réseau local. Sinon, pour en revenir à IIS, CrowdSec peut s'avérer très utile pour protéger les applications qui utilisent ce serveur Web comme c'est le cas du webmail d'Exchange (Outlook Web Access).
FFDroider est un nouveau malware pour Windows qui cherche à voler les identifiants et les cookies enregistrés dans le navigateur de ses victimes afin de compromettre leurs comptes sur les réseaux sociaux.
Plusieurs malwares ont pour habitude de chercher à compromettre des comptes sur les réseaux sociaux, car c'est un terrain de jeu idéal pour diffuser du contenu malveillant aux contacts de la victime. Par exemple, le pirate peut distribuer aux contacts Facebook d'une personne un lien qui mène tout droit au téléchargement d'un logiciel malveillant.
FFDroider, un voleur d'identifiants
Aujourd'hui, nous allons parler de FFDroider, un malware découvert et analysé par les chercheurs en sécurité de chez Zscaler qui suit cette logique : voler des informations permettant d'accéder aux réseaux sociaux de la victime. Pour se propager sur Internet, il utilise des canaux classiques : crack de logiciels, jeux, etc... disponibles via Torrent.
Le malware FFDroider se cache au sein d'un installeur qui prend l'apparence de Telegram Desktop, une application permettant d'accéder à Telegram depuis son PC. Une fois en place, il crée une clé de Registre sur la machine infectée : "Software\ffdroider\FFDroider".
Lorsqu'il entre en action sur la machine infectée, il va chercher à dérober des données au sein des navigateurs. Plus précisément, il va voler les identifiants et les cookies enregistrés dans Google Chrome (et tous les navigateurs basés sur Chromium), Mozilla Firefox, Internet Explorer et Microsoft Edge.
Par exemple pour les navigateurs basés sur Chromium, il va lire les bases SQLlite utilisées pour enregistrer les cookies et les identifiants. Ces bases sont normalement sécurisées, mais il parvient à les déchiffrer en exploitant la fonction CryptUnProtectData de l'API Windows Crypt. Pour les autres navigateurs, le mode opératoire est similaire, si ce n'est qu'il doit exploiter des fonctions différentes.
Grâce à cette méthode, le malware parvient à récupérer des noms d'utilisateur et des mots de passe en clair afin de les exfiltrer vers un serveur C2 (Command & Control). Une simple requête POST en HTTP lui permet de soumettre les informations au serveur. D'ailleurs, dans le cadre de la campagne analysée par Zscaler, l'URL utilisée était la suivante : http[:]//152[.]32[.]228[.]19/seemorebty.
En exploitant les cookies d'authentification, le malware peut agir sur les réseaux sociaux en utilisant l'identité de la victime sans avoir à connaître le mot de passe du compte. D'après l'analyse menée par les chercheurs en sécurité, il exploite la connexion aux réseaux sociaux pour dérober d'autres informations sur la victime : adresse e-mail, numéro de téléphone, informations de paiement sur Facebook Ads, etc.
À quels réseaux sociaux s'intéresse FFDroider ?
Concrètement, même s'il pourrait dérober l'ensemble des identifiants mémorisés dans le navigateur, ce malware semble faire un focus sur les réseaux sociaux et les sites de e-commerces. Il s'intéresse à différents sites, dont Facebook, Instagram, Amazon, eBay, Etsy, Twitter, ou encore le portail WAX Cloud.
Moralité de l'histoire : attention avec les téléchargements illégaux.
