Sommaire
Sécuriser son site site web, pourquoi?
On pourrait se demander pourquoi perdre du temps à faire de la sécurité sur un site qui n’est peut-être qu’une vitrine.
Il y a plusieurs raisons pour cela :
- un site sécurisé est rassurant pour le client ;
- un site non sécurisé peut servir de zombie pour amplifier des attaques de type botnet ;
- un site non sécurisé est une cible privilégié pour le defacing (définition complète ici).
Notre terrain de jeu du jour
Les outils que je vais vous présenter peuvent dégrader les performances de votre site, et peuvent aussi être considérés comme des attaques automatisées si vous les lancez sur d’autres sites. Ainsi, il est conseillé de prendre les précautions suivantes :
- ne jamais tester un site qui ne vous appartient pas ;
- si vous avez des environnements hors production identiques à la production, ciblez plutôt ces derniers ;
- si votre site est hébergé chez un prestataire, il peut être préférable et parfois nécessaire contractuellement de le prévenir pour ne pas déclencher d’alarmes durant le scan ;
- si vous utilisez des protections antibot, il peut aussi être nécessaire de d'ajouter votre adresse IP dans votre liste d'adresses de confiance..
Pour ce billet, nous utiliserons une machine virtuelle non sécurisée comme cible de nos scans.
Installation de la cible des attaques
La machine virtuelle que nous allons utiliser est fournie par Rapid7, éditeur du logiciel MetaSploit, très réputé dans le domaine de la cybersécurité. Cette machine virtuelle nécessite VMWare player pour fonctionner. Il est donc nécessaire d’installer VMWare player sur votre ordinateur si vous souhaitez utiliser ce “hands on”.
Attention, sur Windows 10, dans le cas où vous utiliseriez Docker en backend Hyper-V ou un autre outil de virtualisation (comme VirtualBox), cela peut bloquer le fonctionnement de VMWare player en raison des mécanismes de protection de mémoire virtuelle.
Une fois que vous avez installé VMWare, il est nécessaire de télécharger l’image “metasploitable2” que vous trouverez sur SourceForge. Cette image peut paraître datée, c’est normal, c’est justement le but !
Une fois cette image téléchargée, décompressez l’archive puis lancez VMWare et importez l’image en cliquant sur “File” > “Open Virtual Machine”.
Avant de lancer l’image, nous allons juste faire une modification : changer la carte réseau par défaut de “NAT” à “Host-only”. Nous faisons ceci uniquement par sécurité. De cette manière, la machine virtuelle est uniquement accessible localement sur votre poste.
Pour ce faire, clic droit sur la machine virtuelle nouvellement créée puis “Virtual machine settings”. Ensuite, il suffit d’aller dans Network Adapter puis sélectionner “Host-only”
Nous pouvons maintenant lancer la machine en double cliquant dessus.
Si le message ci-dessous apparaît, pas d’inquiétude ! Cela vient du fait que la machine a été copiée depuis un autre système, cliquez simplement sur “I copied it”. Il est possible que vous ayez une information sur le swap si ce dernier est désactivé, cliquez simplement sur “OK”.
Une fois arrivé sur la page de login Ubuntu, connectez-vous avec les logins et mot de passe indiqués (attention : le clavier est en qwerty ! Sur un clavier azerty cela donne donc ,sfqd,in en login et mot de passe à taper).
Une fois connecté, nous allons simplement récupérer l’adresse IP de la machine virtuelle avec un simple
ip a #Utilisez la touche q pour obtenir un a depuis un clavier azerty
Pour sortir de la machine virtuelle, par défaut, il suffit de faire CTRL+ALT. En cas de doute, la touche est normalement indiquée en bas à gauche de la fenêtre.
Notez l’IP de votre machine, nous allons en avoir besoin par la suite !
Si vous ouvrez votre navigateur à cette adresse, vous avez normalement un site web qui s’affiche, avec des liens.
Le lien qui nous utiliserons est celui nommé DVWA : “Damn Vulnerable Web App”.
Avant de commencer avec les gros jouets
Avant de jouer avec les deux outils du jour, je vous propose déjà un simple test de port.
L’idée est de voir les ports ouverts sur notre machine qui peuvent se transformer en autant de vecteurs d’attaque.
Comme nous avons un site web, de manière logique, nous ne devrions avoir que les ports 80 (HTTP) et éventuellement 443 (HTTPS) d’ouverts.
Pour tester les ports, nous allons donc utiliser l’outil nmap. Ce dernier va scanner les ports les plus communs si on ne lui donne pas de paramètre, il est aussi possible d’indiquer une plage de ports à scanner.
Il est à noter que nmap peut parfois être bloqué par votre système ou par un simple WAF sur la cible, car détecté comme une “attaque par scan de port”.
Damned, tellement de ports ouverts !
Pour notre cas, c’est normal, la machine étant un terrain de jeu pour des tests d’intrusion, rien d’alarmant. Néanmoins dans un cas en production, cela permet de voir toutes les portes d’entrée à disposition de quelqu’un de malveillant.
Sortons l’artillerie lourde
Il existe des tonnes d’outils pour faire du test d’intrusion (ou pentesting en anglais), ils ne seront pas traités dans ce billet. Je vais me concentrer sur deux outils qui sont pour moi de vrais couteaux suisses, puis j’aborderai tout de même brièvement d’autres outils intéressants pour certains cas spécifiques.
Dans les cas dont je vous parlerai ci dessous, je suis parti d’une distribution Parrot Linux 4.10. Il est possible de reproduire ces tests depuis n’importe quel Linux, mais ils peuvent nécessiter des actions supplémentaires.
Notez également que vous pouvez exécuter Parrot dans une machine virtuelle. Pour cet atelier, nous aurons besoin de l’interface graphique de Parrot. Il est aussi possible d’utiliser Kali Linux, qui aura un comportement très similaire à Parrot.
Vega - Pentester HTTP universel
Vega est un outil créé par Subgraph, conçu pour “vous aider[a] à trouver et à corriger des attaques de type cross-site scripting (XSS), injection SQL, et plus encore.”
Vega va nous servir à éprouver la sécurité de notre site en observant les headers, le code envoyé à l’utilisateur, les code d’erreur, etc.
En prérequis, nous allons devoir activer un ancien repository Debian pour télécharger une ancienne version de GTK que Vega utilise pour son affichage.
echo “http://deb.debian.org/debian oldstable main non-free contrib” >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get install libwebkitgtk-1.0-0
De plus, Vega fonctionne avec Java8, ce qui n’est pas tout jeune, mais malheureusement, il n’a pas été porté sur des versions plus récentes.
Nous allons donc passer sur Java8 par défaut :
sudo update-alternatives --config java
Ne vous fiez pas au côté “vieillot” des deux prérequis ci-dessus, vous allez voir que cet outil nous remonte une mine d’informations et qu’il serait dommage de passer à côté à cause de ces détails !
Nous pouvons donc maintenant télécharger Vega depuis le site officiel. Une fois l’archive téléchargée, il suffit de la décompresser et de lancer l’application.
cd /home/ted/downloads/
unzip VegaBuild-linux.gtk.x86_64.zip
./vega/Vega
Une application similaire à celle-ci doit normalement s’ouvrir :
Nous allons donc pouvoir lancer notre premier test.
Cliquez sur le petit logo avec un “+” en haut à gauche ou faites un CTRL+N pour lancer un nouveau test.
Dans la fenêtre qui s’affiche, entrez l’adresse de votre site que nous avions mis de côté plus tôt.
Cliquez ensuite sur “Finish”, l’application vous demande si vous souhaitez suivre la redirection, répondez “Yes”.
Le scan va durer quelques minutes. Dans un premier temps, Vega va aller sur l’URL indiquée puis rechercher tous les liens présentés et suivre chacun de ces liens. Le but est de faire un inventaire complet des pages et assets de votre site.
Vega va maintenant tester les urls une par une pour voir les vulnérabilités possibles. Une fois les scans terminés, un rapport sommaire s’affiche avec la criticité des erreurs trouvées.
Sur le menu gauche, le rapport est aussi visible, et il est possible d’avoir le détail sur les vulnérabilités et des pistes de remédiation.
Attention toutefois, il est nécessaire d’avoir un regard critique sur ces alertes, qui peuvent aussi être des faux positifs.
Par exemple, un scan sur ce blog remonterait des alarmes sur la présence de chemins Linux visibles. En réalité, les chemins détectés sont des exemples contenus dans des billets, et cela n’a rien d’alarmant.
C’est là la partie la plus compliqué d’un test d’intrusion : séparer le bon grain de l’ivraie.
OWASP-Zap : Le “Top ten” de l’OWASP en une application
La seconde application que nous allons utiliser est donc OWASP-Zap. Comme son nom l’indique, nous allons pouvoir tester les points en rapport avec le sacro-saint top 10 de l’OWASP.
L’OWASP est une ONG établissant des bonnes pratiques et des modèles de sécurité applicative. Le top 10 de l’OWASP est souvent un document de référence dans tout audit de sécurité. Ce dernier référence en effet les 10 vecteurs d’attaque les plus critiques pour une application web.
Nous allons donc pouvoir jouer avec cet outil. Commençons par le lancer.
sudo owasp-zap
sudo owasp-zap
Après quelques secondes de chargement, une interface s’ouvre. Une fenêtre vous propose d’enregistrer votre session, libre à vous de choisir ce qui vous convient.
Cliquez ensuite sur “Automated Scan” puis entrez encore une fois l’adresse de notre site web.
Vous pouvez laisser les options par défaut. Cliquez ensuite sur “Attaquer”
Comme avec l’outil précédent, nous allons initier une séquence d’analyse et de récupération des URLs, puis le lancement du scan à proprement parler.
Une fois le scan terminé, il est possible de parcourir les alertes remontées.
Tout comme précédemment, ces alertes sont à regarder avec un oeil critique. Toutefois, étant données les règles du top 10, elles sont à mon sens primordiales car il s’agit bien des vecteurs d’attaque les plus courants aujourd’hui.
Il est à noter qu’il est aussi possible d’intégrer OWASP-Zap en tant que GitHub action dans un cycle DevSecOps par exemple, les actions sont disponibles via ces URL :
- https://github.com/marketplace/actions/owasp-zap-baseline-scan
- https://github.com/marketplace/actions/owasp-zap-full-scan
Les scanners spécifiques
Je ne vais pas les utiliser ici, mais il peut être utile de savoir qu’il existe des scanners de vulnérabilités conçus pour certaines cibles en particulier, comme par exemple :
- Pour Wordpress : wpscan
- Pour la plupart des CMS : droopescan
Pour aller plus loin, je ne me vois pas ne pas évoquer MetaSploit. Même si l’outil s’avère complexe à prendre en main, il s’agit d’un des outils les plus puissants pour tout pentesting.
Ce dernier va vous permettre de tester les exploit potentiel fonctionnant sur votre infrastructure web. Fourni avec des dizaines de modules et payloads, il permet d’éprouver la sécurité de beaucoup d’applications.
Pour terminer
Que ce soit clair, à l’issue de ce petit lab, vous ne serez pas des experts en cybersécurité. Toutefois, l’idée est de vous donner des éléments afin de comprendre la sécurité et de l’appréhender à chaque phase de la mise en place de votre application.
Les outils que j’ai présentés peuvent paraître simplistes, mais ils ont l’avantage d’être à la portée de beaucoup de par leurs interfaces graphiques et sont très simples à prendre en main.
Si vous voulez aller vers un modèle plus sécurisé, la bonne idée est de se fier au top 10 de l’OWASP qui est un excellent point de départ. Vous pouvez retrouver ce dernier en détail ici.