Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des millions de sites et de web apps vulnérables selon 2 chercheurs
Les attaques par timing sont-elles une menace sérieuse ?

Le , par Katleen Erna

0PARTAGES

1  1 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de zoonel
Membre habitué https://www.developpez.com
Le 19/07/2010 à 10:33
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.
4  0 
Avatar de randriano
Membre éprouvé https://www.developpez.com
Le 19/07/2010 à 7:50
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
1  0 
Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 19/07/2010 à 15:41
Ça veut donc dire que "LOL" a circulé en clair sur le réseau ? Ou bien je ne comprends pas comment tu fais.
1  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 20/07/2010 à 14:12
Citation Envoyé par jblecanard Voir le message
C'est tout à fait exact, mais l'abus de langage n'est pas si choquant à partir du moment ou on ne peut pas retrouver le mot de passe original à partir du hash.
Si, on peut retrouver le mot de passe original avec un dictionnaire.

Tu prends le mot "toto". Il sera toujours haché de la même manière. Alors qu'avec un algo de chiffrement c'est la clef qui détermine l'output donc du coup tu n'auras pas le même output en fonction de la clef.

-> rien à voir.
1  0 
Avatar de henolivier
Membre actif https://www.developpez.com
Le 22/07/2010 à 7:39
Citation Envoyé par StreamEarth Voir le message
Moi je dirais que c'est un peu le code qui rime à rien, le système qui vérifie par une boucle caractère par caractères...

Pourquoi ne pas vérifier simplement la chaine si a = b et renvoyer la réponse positif ou négatif. Là au moins il n'y a pas de temps de réponse etc.
Ce n'est pas aussi simple, la plupart des langages lorsque tu leurs donnes à comparer 2 chaines de caractères vont comparer les caractères un par un, tu auras donc l'impression d'une comparaison globale alors que ce sera une comparaison caractère par caractère (avec arrêt au premier différent).

Java en est un très bon exemple. il te suffit de regarder le code source de la méthode equals de String pour comprendre, alors que c'est exactement cette méthode que tu appellerais pour vérifier 2 chaines.
1  0 
Avatar de bombseb
Membre expérimenté https://www.developpez.com
Le 19/07/2010 à 9:38
T'as développé quoi comme site ?
0  0 
Avatar de randriano
Membre éprouvé https://www.developpez.com
Le 19/07/2010 à 9:48
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é
0  0 
Avatar de FailMan
Membre expert https://www.developpez.com
Le 19/07/2010 à 10:54
Citation Envoyé par zoonel Voir le message

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.
0  0 
Avatar de jblecanard
Membre expert https://www.developpez.com
Le 19/07/2010 à 11:53
Citation Envoyé par zoonel Voir le message
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.
0  0 
Avatar de Antoine_935
Membre éprouvé https://www.developpez.com
Le 19/07/2010 à 12:03
Citation Envoyé par jblecanard Voir le message
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.
0  0