Des millions de sites et de web apps vulnérables à des attaques par timing, d'après deux experts en sécurité

**Katleen Erna** · 19/07/2010, 07h13

Des millions de sites et de web apps vulnérables, les attaques par timing sont-elles une menace sérieuse ?

Nate Lawson (fondateur de Root Labs) et Taylor Nelson sont deux experts en sécurité informatique qui viennent d'annoncer avoir découvert une faille de sécurité très répandue dans les applications Web utilisées quotidiennement par des millions d'internautes, et qui pourrait être exploitée par une attaque cryptographique populaire dans les milieux du hacking.

Des dizaines de bibliothèques équipant des softwares open-source servant à vérifier les mots de passe et les noms d'utilisateur seraient ainsi concernées, dont celles des logiciels qui implémentent les standards OAuth et OpenID (ce sont les types d'authentifications utilisées par Twitter par exemple).

D'après les chercheurs, certaines versions de ses systèmes de login seraient vulnérables aux attaques de type "timing" (qui sont connues depuis près de 25 ans par les cryptographes).

Les "timing attacks" sont réputées être difficiles à mettre en oeuvre sur un réseau, et pourtant... Elles nécessitent juste une exacte précision dans les mesures. Pour rappel, elles fonctionnent en mesurant le laps de temps nécessaire à un ordinateur pour répondre à une demande de login. Dans certains systèmes, la machine vérifiera tous les caractères d'un mot de passe en une seule fois en renvoyant un "login failed" dès qu'elle détectera une lettre ou un signe erroné dans la combinaison.

Alors forcément, à force d'essayer encore et encore, un programme spécifique aura vite fait de mesurer le temps de réponse de l'ordinateur et ainsi de deviner les premiers caractères du mot de passe jusqu'à le déchiffrer en entier.

Il y a trois ans, cette technique avait été utilisée pour hacker le système Microsoft de la Xbox 360.

Certains développeurs Web réfutent ces thèses et affirment que d'autres facteurs (les "network jitter") ont une influence sur le temps de réponse d'un PC et peuvent soit l'accélérer, soit le ralentir. DE ce fait, et selon eux, il serait impossible d'obtenir un résultat assez précis (de l'ordre de la nanoseconde) pour réaliser une timing attack sur Internet.

Lawson et Nelson veulent prouver que ceci est faux et que ces risques sont trop souvent sous-estimés par les professionnels. Ils ont réalisé des tests sur ce type d'attaques sur le Net, mais aussi dans des environnements Cloud et sur des réseaux locaux. Dans les trois cas, ils ont été capables de cracker des mots de passe à l'aide d'algorithmes qui annulaient les effets du network jitter.

Ceci leur a permis de découvrir que les programmes écrits avec des langages interprétés (comme Python ou Ruby) étaient plus vulnérables que les autres, car ils génèrent des réponses plus lentes.

Les deux experts ont avertis les responsables et développeurs des programmes affectés par le problème. Ils ne dévoileront pas la liste des produits atteints tant qu'ils ne seront pas patchés. La solution qu'ils proposent : reprogrammer le système pour qu'il envoie une réponse d'un temps égal en cas de mot de passe correct comme de mot de passe erroné, ce qui ne prendrait que 6 lignes de code d'après Lawson.

Source : L'annonce de la présentation de Lawson et Nelson à la Black Hat de Las Vegas, où ils donneront davantage de précisions.

Beaucoup pensent que les timing attacks sont impossibles à réaliser. Pensez-vous qu'ils ont raison, ou qu'au contraire ils sous-estiment ce problème qui est plus sérieux qu'on ne le croit ?

**randriano** · 19/07/2010, 07h50

Toutes failles sont graves mais il semble qu'encore plus de 90% des sites web contiennent toujours les failles populaires: XSS et Injections SQL
En tant que développeur, j'admets que ce chiffre est vrai car moi-même, je n'ai jamais codé des codes évitant ces failles

**bombseb** · 19/07/2010, 09h38

T'as développé quoi comme site ?

**randriano** · 19/07/2010, 09h48

C'est vrai que ce j'ai dit c'est

Ce sont surtout les forums qui présentent à 90% des failles mais il est vrai que vBulletin comme ici est assez sécurisé

**zoonel** · 19/07/2010, 10h33

je comprends toujours pas pourquoi ils ne font pas comme gmail pour les login et passwords:
x essais, si x est dépassé alors on demande en plus un captcha.
Et ajouter un temps d'attente de plus en plus long entre chaque essais, du type exponentiel.(je sais pas si gmail fait ca par contre)
Bref un système pour empêcher le brute forcing en gros, ce qui devrait limiter ce genre d'attaque même si la méthode n'est pas parfaitement adaptée au problème.

**FailMan** · 19/07/2010, 10h54

Envoyé par zoonel

Bref un système pour empêcher le brute forcing en gros, ce qui devrait limiter ce genre d'attaque même si la méthode n'est pas parfaitement adaptée au problème.

Il me semble que vBulletin te mets un délai de 15 minutes au bout de 5 mots de passe erronés, cependant pas de captcha.

**jblecanard** · 19/07/2010, 11h53

Envoyé par zoonel

je comprends toujours pas pourquoi ils ne font pas comme gmail pour les login et passwords:
x essais, si x est dépassé alors on demande en plus un captcha.
Et ajouter un temps d'attente de plus en plus long entre chaque essais, du type exponentiel.(je sais pas si gmail fait ca par contre)
Bref un système pour empêcher le brute forcing en gros, ce qui devrait limiter ce genre d'attaque même si la méthode n'est pas parfaitement adaptée au problème.

En effet, ce n'est pas adapté, puisque ce n'est pas du bruteforcing. Il suffit de revenir le lendemain pour déchiffrer la suite.

Moi je dis que ces experts ont raison et que ne serait-ce qu'au nom du principe de précaution, tout le monde devrait rajouter ces 6 lignes de code.

Cela dit, je suis surpris de la technique car dans un système bien fait, les mot de passes sont cryptés, et la comparaison ne se fait donc pas caractère par caractère. Mot de passe stocké en clair => appli à éviter ! Ce seul fait les rend vulnérables, c'est bien connu et on a eu un bel exemple avec skyrock il n'y a pas longtemps.

**Antoine_935** · 19/07/2010, 12h03

Envoyé par jblecanard

Cela dit, je suis surpris de la technique car dans un système bien fait, les mot de passes sont cryptés, et la comparaison ne se fait donc pas caractère par caractère. Mot de passe stocké en clair => appli à éviter !

Pas forcément. Mettons que tu "cryptes" le mot de passe avec un hash de type sha. Tu devras alors comparer 2 chaines de 40 caractères (dans le cas du sha1). Ici encore la comparaison se fait caractère par caractère.

Cela dit, un petit sleep avec un temps aléatoire devrait supprimer la faille, à mon sens.

**FailMan** · 19/07/2010, 12h05

Envoyé par jblecanard

Mot de passe stocké en clair => appli à éviter !

Je pensais que ça faisait 10 ans qu'on ne stockait plus les mots de passe en clair...

**Marco46** · 19/07/2010, 12h21

Ce que je comprends pas c'est comment ils font pour écrire leur algo.

Je veux dire, pour déterminer le temps d'exécution de la procédure de vérification du mot de passe il faut bien déterminer le temps de circulation des messages sur le réseau. Les fonctions réseaux disponibles donnent des durées en milli-secondes, or il est indiqué dans la news qu'ils ont besoin d'une précision en nano-seconde.

Donc je dis, balèze.

**S(ô.Ô)B** · 19/07/2010, 12h58

Envoyé par Antoine_935

Cela dit, un petit sleep avec un temps aléatoire devrait supprimer la faille, à mon sens.

Ou alors tout simplement au lieu de t'arrêter dès que tu vois que les 2 chaînes ne sont pas identiques, tu testes jusqu'à la fin et tu rends le résultat une fois que tu as tout parcouru.
Et là je pense qu'au lieu de rajouter 6 lignes de code comme ils disent, tu en enlèves une

**jblecanard** · 19/07/2010, 13h14

Envoyé par Antoine_935

Pas forcément. Mettons que tu "cryptes" le mot de passe avec un hash de type sha. Tu devras alors comparer 2 chaines de 40 caractères (dans le cas du sha1). Ici encore la comparaison se fait caractère par caractère.

Oui, mais il n'y a pas de correspondance avec le caractère du mot de passe entré. Si tu tapes le bon premier caractère du mot de passe, les premiers caractères du cryptage ne vont pas systématiquement correspondre, donc ça ne marche pas...

**rg77140** · 19/07/2010, 14h36

Bonjour,

Une question que je me pose est ce que PHP ou SQL font de la comparaison caractère par caractère ?

C'est à dire si dans nos applications on a des choses du genre

SELECT * FROM user WHERE username = '".$_POST['username']."' AND password = '".$_POST['password']."';

if(rowCount() ==1){
//connection
}else{
//erreur
}

est ce que ce problème nous concerne ?

Merci d'avance pour vos réponses

PS : Je n'ai pas échappé les variables ici c'est juste pour l'exemple.

**10_GOTO_10** · 19/07/2010, 14h57

Envoyé par jblecanard

Oui, mais il n'y a pas de correspondance avec le caractère du mot de passe entré. Si tu tapes le bon premier caractère du mot de passe, les premiers caractères du cryptage ne vont pas systématiquement correspondre, donc ça ne marche pas...

Peu importe, le but du pirate est d'entrer dans un système, pas d'avoir ton mot de passe. Donc s'il arrive a trouver le hash de ton MDP plutôt que le MDP lui-même, le résultat est le même.

**CIFQ_Drew** · 19/07/2010, 15h00

Pour ma part je ne comprends pas vraiment comment cette technique peut-être utilisé avec des fonction de hash tel PASSWORD de MySQL par exemple. Si j'écris 'LOL' le résultat c'est *F6D37B11A6853D08BC1B65921397F95A5A154E67. Quelqu'un qui écrit 'LOTERIE' aura un résultat *20BAFE4D6919B48742ED969E7FF2070260BFAAE9 : il n'y a pas de correspondance entre le début LO de mon LOL et LO de LOTERIE après hashage.

De plus, si notre site Web ajoute utilise un SALT (une chaine de caractère que notre site en début ou fin de chaine du mot de passe), alors on assure une meilleur sécurité, parce que même si un vilain hacker réussi à avoir une liste d'utilisateur avec leur mot de passe hasher, il pourrait ce construire une table de correspondance de mot de passe potentiel, (genre LOL, lol, maman, toutes les combinaisons de date par exemple) et ainsi avec accès à un certains pourcentage de compte. Cependant avec un SALT, la table ne sert plus à rien.

j'admets que ce chiffre est vrai car moi-même, je n'ai jamais codé des codes évitant ces failles

P.S. Pour éviter l'injection SQL le plus simple selon moi c'est de traiter ta chaine avant de faire quoi que se soit !

**10_GOTO_10** · 19/07/2010, 15h11

Envoyé par CIFQ_Drew

Pour ma part je ne comprends pas vraiment comment cette technique peut-être utilisé avec des fonction de hash tel PASSWORD de MySQL par exemple. Si j'écris 'LOL' le résultat c'est *F6D37B11A6853D08BC1B65921397F95A5A154E67. Quelqu'un qui écrit 'LOTERIE' aura un résultat *20BAFE4D6919B48742ED969E7FF2070260BFAAE9 : il n'y a pas de correspondance entre le début LO de mon LOL et LO de LOTERIE après hashage.

Parce que le pirate ne va pas entrer ni "LOL" ni "LOTERIE", mais "F6D37...". Le hashage est fait en local, donc rien n'empêche de faire une appli (et j'imagine qu'il faut de toutes façons en faire une pour mesurer précisément le timing) qui ne fait que le POST final (dans le cas d'une appli web, par exemple).

**CIFQ_Drew** · 19/07/2010, 15h31

Envoyé par 10_GOTO_10

Parce que le pirate ne va pas entrer ni "LOL" ni "LOTERIE", mais "F6D37...". Le hashage est fait en local, donc rien n'empêche de faire une appli (et j'imagine qu'il faut de toutes façons en faire une pour mesurer précisément le timing) qui ne fait que le POST final (dans le cas d'une appli web, par exemple).

Tant qu'à moi dans mon PHP je fais un select du genre (ne vous inquiété pas c'est pas exactement comme ça) mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT pkusername FROM user WHERE pkusername = 'bob' and passwd = PASSWORD('LOL')

. Si mon select me retourne une donnée, alors le passwd est bon, sinon il y a erreur.

**10_GOTO_10** · 19/07/2010, 15h41

Ça veut donc dire que "LOL" a circulé en clair sur le réseau ? Ou bien je ne comprends pas comment tu fais.

**CIFQ_Drew** · 19/07/2010, 15h47

Euh... Je crois que tu comprends pas vraiment l'exemple.

Nous avons une belle connexion SSL sécurisé entre un client (mon navigateur FireFox disons) et mon Serveur (mon facebook, disons).

J'inscris dans la boite 'username' : bob.
J'inscris dans la boite 'passwd' : LOL.

J'envoie ça par POST à mon serveur.

Mon serveur fait quelque chose du genre (il y a du traitement à faire avant on s'entend) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$result = mysql_query("SELECT pkusername FROM user WHERE pkusername = $_POST['username'] AND passwd = $_POST['passwd']);
if (!$result) {
    // traitement erreur
} else {
    // traitement succès
}

Ce que le serveur reçoit c'est le LOL et non la chaine déjà hasher. De plus PHP n'a même pas connaissance de la chaine hasher, c'est SQL qui s'occupe de faire la correspondance. Ainsi, si quelque tape le F6blablabla elle sera hasher puis comparer, ce qui donnera forcément un retour négatif.

Est-ce que c'est plus clair?

**Antoine_935** · 19/07/2010, 16h01

Envoyé par CIFQ_Drew

Ce que le serveur reçoit c'est le LOL et non la chaine déjà hasher.

Donc, comme le soulève boucle inf... "10 GOTO 10" pardon

, le "LOL" se balade en clair sur le réseau entre le serveur web et MySQL. Ça va s'ils sont sur la même machine, mais c'est rarement le cas.

Intéressante remarque, soit dit en passant, je n'y avais jamais pensé

Edit:
En réponse à

Une question que je me pose est ce que PHP ou SQL font de la comparaison caractère par caractère ?

Si tu veux dire qu'ils s'arrêtent à la première différence, c'est très probable.