Comment pirater une application Web non sécurisée

Dans cet article, je voudrais démontrer à quel point il est facile d’obtenir des informations confidentielles à partir d’une application Web qui… eh bien, ne prête pas trop attention à la sécurité. Ce que je vais travailler avec est un exemple d’application Java que j’ai créée dans Spring Boot à des fins de démonstration. Mais les attaques effectuées sont valables pour tout autre langage de programmation ou framework. Certaines vulnérabilités et problèmes de sécurité qui seront démontrés comprennent:

• Injection SQL
• Exposition aux données sensibles
• Journalisation insuffisante
• Authentification brisée

La configuration

Nous allons travailler avec une application Web fictive qui vous permet de vous connecter en tant qu’utilisateur faisant partie d’un groupe. En fonction du rôle de l’utilisateur, il peut consulter des données de base ou confidentielles. Dans ce cas, vous verrez une liste des employés d’une entreprise, leur statut, etc.

Vous pouvez trouver les sources de cette application dans mon Github: https://github.com/rapasoft/hackme.

Attaque #1: L’homme au milieu attaque

Imaginez que vous êtes assis dans un restaurant et que vous souhaitez vérifier quelque chose dans l’application ci-dessus. Vous vous connectez au Wi-Fi du restaurant, ouvrez la page de connexion, entrez les informations d’identification et obtenez les informations que vous souhaitez (par exemple, la liste des employés spécifiques). Ce que vous pourriez ne pas faire maintenant, c’est que vos informations d’identification ont été compromises. Examinons de près la page de connexion:

Cette application n’utilise pas SSL / TLS (par exemple, pas de connexion https://). Cela signifie que toute information envoyée peut être considérée comme du texte brut par toute personne ayant accès à la communication entre le client et le serveur.

C’est exactement ce qui se passe dans ce qu’on appelle l’attaque de l’homme au milieu. Plus précisément, dans ce cas, l’usurpation d’ARP a été utilisée comme moyen d’empoisonner tout le réseau afin que l’attaquant soit au courant de tout ce qui se passe et puisse renifler tous les paquets. Je ne vais pas entrer dans les détails sur le fonctionnement de l’usurpation d’ARP, mais je le démontrerai sur cette vidéo:

Vous devrez peut-être ouvrir cette vidéo Youtube dans une nouvelle fenêtre et en plein écran pour voir plus de détails

Ce que vous pouvez voir ci-dessus, c’est que j’ai démarré Ettercap, qui est une suite complète pour les attaques MITM, et effectué une usurpation d’ARP sur mon réseau local. En attendant, lorsque l’utilisateur (moi via iPad) entre les informations d’identification, elles sont visibles à la fois dans Ettercap et dans Wireshark (outil d’analyse du trafic réseau).

Attaque #2: Injection SQL

Poursuivant notre rôle d’attaquant de cette application, nous avons maintenant les informations d’identification pour l’utilisateur hgraves avec le mot de passe P4SSW0RD. Vous pouvez voir que non seulement cette application n’utilise pas TLS, mais elle a une politique de mot de passe très faible permettant aux utilisateurs de choisir des mots de passe vraiment horribles.

Nous nous connectons en utilisant les informations d’identification ci-dessus et pouvons voir un champ de saisie avec option pour rechercher la liste des personnes. En appuyant sur Search, nous obtiendrons la liste complète des personnes. Si nous mettons « Fra » par exemple, nous obtiendrons des résultats filtrés en fonction de la recherche. Et si on y mettait un caractère illégal ? Il est évident qu’il y a une base de données derrière cette application, alors essayons le caractère ':

Non seulement cela a échoué, mais nous pouvons voir que la requête POST a échoué avec un message d’erreur très spécifique qui expose la structure de l’ensemble de l’instruction SQL. On peut voir que WHERE P.NAME LIKE '%'%' est utilisé à la fin.

Hacker qualifié n’a pas besoin de plus. L’ajustement de la chaîne de recherche peut, après quelques tentatives, donner ces résultats:

L’injection dans ce cas a créé l’instruction union to select qui récupère les noms d’utilisateur et les mots de passe ainsi que leur rôle. Non seulement cela a été un succès, mais nous avons réussi à l’afficher dans l’application cliente d’origine.

Nous avons maintenant les informations d’identification de tous les utilisateurs et leurs rôles (affichés par l’entier dans la colonne « Âge »). Si hframe a le rôle 1, rgraves doit donc être un utilisateur plus important avec le rôle 3.

Attaque #3: Attaquer les mots de passe faiblement hachés

Nous avons appris lors de la première attaque qu’il n’y a probablement pas de stratégie de mot de passe définie pour cette application. Cela nous donnerait l’espoir que rgraves ne prête pas trop attention non plus à la sécurité.

Le moyen le plus simple de casser le hachage du mot de passe qui utilise un algorithme de hachage insuffisant (comme MD5 dans ce cas) consiste à effectuer une attaque par dictionnaire ou par table arc-en-ciel. Il existe de nombreuses possibilités, mais la plus simple consiste à utiliser des services Internet qui disposent déjà d’une grande base de données de combinaisons mot de passe-hachage:

Le premier est hframe, le second est rgraves. smorgan semble utiliser des mots de passe plus forts que les autres, car ils ne sont pas dans le dictionnaire.

Vous pouvez voir que le mot de passe pour rgraves est l’espadon, ce qui signifie qu’il ne sait pas à quel point il est important de choisir un mot de passe non-dictionnaire;). Maintenant, rien ne nous empêche de nous connecter en tant qu’utilisateur et de découvrir la section « admin » et les informations confidentielles:

Ne lisez pas ceci si vous êtes allemand 🙂

Comment résoudre ce problème?

Vous pourriez dire que tout cela pourrait être facilement évité. Vous pourriez dire que ce sont des erreurs de débutant. Eh bien, cela peut être vrai, mais ce qui est également vrai, c’est que le projet Open Web Application Security répertorie l’injection comme vulnérabilité #1 dans les applications Web (et c’est comme ça depuis plusieurs années).

Donc, si vous vous demandez comment éviter tout cela, récapitulons:

• Utilisez toujours SSL / TLS lorsque vous envoyez quelque chose au serveur. Il ne doit pas nécessairement s’agir de références, il est actuellement considéré comme une bonne pratique en général. Même si vous n’avez aucune entrée sur votre page! Le moyen le plus simple est de fournir un certificat via des services tels que Let’s Encrypt.
• Rappelez-vous que les certificats auto-signés peuvent atténuer le problème de l’exposition aux données, mais n’empêchent pas l’attaquant MITM de simuler tout le site avec son propre certificat auto-signé.
• Lorsqu’il s’agit de requêtes SQL, les paramètres d’échappement obtenus à partir du client sont toujours utilisés. La façon la plus simple de le faire est d’utiliser les capacités de votre framework, par exemple au printemps, vous pouvez utiliser NamedParameterJdbcTemplate, ce qui est également bon pour la lisibilité.
• Soyez paranoïaque. Validez toute entrée utilisateur. Encore une fois dans le monde Java/ Spring, vous pouvez ajouter des règles de validation à l’aide de l’implémentation de validation de bean JSR-380 comme le validateur Hibernate et les paramètres d’annotation, par exemple @Pattern(regexp = "*") String name empêcherait d’entrer '.
• Enregistre toutes les tentatives de transmission d’une entrée non valide dans l’application. De plus, en cas d’erreur, n’exposez aucune information spécifique à l’implémentation au client.
• Améliorez votre authentification.
  • Si possible, utilisez au moins une authentification à 2 facteurs.
  • N’implémentez pas d’algorithmes de stockage de mots de passe ou de cryptage personnalisés. C’est extrêmement difficile à faire par vous-même et vous échouerez certainement. Il existe des solutions éprouvées comme BCrypt.
• Lisez et signet OWASP TOP 10. Commencez par là, puis parcourez leur liste de meilleures pratiques.