[C/C++] BruteForce
|
25-02-2013, 21h50
Message : #16
|
|
b0fh
Membre actif Messages : 210 Sujets : 17 Points: 309 Inscription : Jul 2012 |
RE: [C/C++] BruteForce
La récursion, apprenez a l'aimer !
Code C :
Comment, vous dites que la récursion c'est lent ? Code : max@truite:~$ gcc -O3 -o bf-gruik bf-gruik.c -lm |
|
25-02-2013, 22h02
Message : #17
|
|
InstinctHack
Posting Freak Messages : 1,366 Sujets : 184 Points: 299 Inscription : Dec 2011 |
RE: [C/C++] BruteForce
>_<""""
je lutte depuis 3 heures avec Code C :
fallait faire Code C :
Go me pendre Citation :un jour en cours de java j'ai attrapé les seins d'une fille mais elle m'a frappé en disant "c'est privé !!" |
|
26-02-2013, 03h04
Message : #18
|
|
k-otik
Membre actif Messages : 114 Sujets : 10 Points: 6 Inscription : Oct 2005 |
RE: [C/C++] BruteForce
Si je peux me permettre de faire un commentaire sans vous embêtez.
Il faut éviter les algorithmes de protection variable dans le temps ! Que ce soit des return ou break dans des boucles de comparison. Je dis ca, car quand on code des bruteforcers on apprend aussi à coder l'inverse. Un autre exemple que j'ai vu, ceci est une comparison octet par octet en python. Code : if h.hexdigest()==hash C'est comme ca qu'on pouvait (et peut encore http://www.cvedetails.com/cve/CVE-2009-3875/) bypasser par analyse temporelle statistique certains algorithmes d'authentification. |
|
26-02-2013, 04h38
Message : #19
|
|
InstinctHack
Posting Freak Messages : 1,366 Sujets : 184 Points: 299 Inscription : Dec 2011 |
RE: [C/C++] BruteForce
(26-02-2013, 03h04)k-otik a écrit : Si je peux me permettre de faire un commentaire sans vous embêtez. TOP 1 du jairiencompris ! \o/ return, break c'est quoi le mal ? if h.hexdigest()==hash, c'est quoi le probleme ? "analyse temporelle statistique" ça ressemble à du français, mais ça n'en n'est pas :p Tu peux expliquer plus en détail, s'il te plait ? Citation :un jour en cours de java j'ai attrapé les seins d'une fille mais elle m'a frappé en disant "c'est privé !!" |
|
26-02-2013, 10h32
Message : #20
|
|
gruik
gouteur de savon Messages : 757 Sujets : 44 Points: 482 Inscription : Oct 2012 |
RE: [C/C++] BruteForce
(26-02-2013, 03h04)k-otik a écrit : Si je peux me permettre de faire un commentaire sans vous embêtez. god que tu es embêtant non bien sûr c'est le principe d'un forum de partager ses avis et ses expériences donc tu peux allègrement te permettre sans embêter, je m'en porte garant personnellement, foi de veau ! Citation :Il faut éviter les algorithmes de protection variable dans le temps ! oui je crois voir ce que tu veux dire, et c'est très vrai effectivement même si ça s'applique essentiellement aux routines d'ident/authent, j'ai souvenir d'un exploit similaire au début des années 2000 contre PAM et/ou openssh sinon mignon ce CVE je m'en souvenais plus, mais k-otik, k-otik... tu serais pas du côté de montpellier toi par hasard ? |
|
26-02-2013, 10h48
(Modification du message : 26-02-2013, 10h56 par b0fh.)
Message : #21
|
|
b0fh
Membre actif Messages : 210 Sujets : 17 Points: 309 Inscription : Jul 2012 |
RE: [C/C++] BruteForce
Ben, ce type de problème est plutôt présent dans les cas ou on essaie de deviner une clef secrète ou un padding ou un sel; ici à priori on suppose que le hash est connu.
Mais admettons que le serveur aie du code comme Code : h == hash Le problème est que, en comparant des strings, le temps de comparaison est proportionnel au nombre de mots communs en début de la chaine. Donc plutôt que de devoir bruteforcer un hash complet, il peut essayer plusieurs h ayant des débuts différents, mesurer le temps de réponse du serveur, et garder le plus long; et ainsi reconstruire hash en temps linéaire plutôt qu'exponentiel. Pour éviter ça, il faut t'assurer que le temps de comparaison ne dépende pas de tes données. Et donc pas de break/continue, qui changent le nombre d'itérations de tes boucles. L'attaque fameuse était celle de S. Vaudenay contre OpenSSL, qui vérifiait qu'un paquet entrant était valide en testant qu'il avait un padding et un MAC correct. Mais dans les vieilles versions, le MAC n'était pas testé si le padding était incorrect, ce qui permettait de distinguer les deux erreurs en mesurant le temps de réponse. Et pour le mode CBC, ça permet de réaliser l'attaque dite du Padding Oracle, qui permet de casser un cleartext byte par byte a condition d'avoir a disposition une boite noire qui dise pour chaque ciphertext si le padding est correct ou pas. |
|
26-02-2013, 16h18
Message : #22
|
|
Dobry
Tueur de lamouz Messages : 206 Sujets : 25 Points: 73 Inscription : Aug 2011 |
RE: [C/C++] BruteForce
Je n'ai pas eu le temps de regarder les codes (même si je vais tenter celle en recursive avant de regarder la solution, un peu d'entrainement ne fera pas de mal). Mais merci pour cette explication sur l'analyse temporel statique, je n'étais pas du tout au courant de ce genre de procédé !
Aestuārium Erudītiōnis
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
|
|
28-02-2013, 01h52
Message : #23
|
|
k-otik
Membre actif Messages : 114 Sujets : 10 Points: 6 Inscription : Oct 2005 |
RE: [C/C++] BruteForce
b0fh a très bien répondu .
(26-02-2013, 10h48)b0fh a écrit : Le problème est que, en comparant des strings, le temps de comparaison est proportionnel au nombre de mots communs en début de la chaine. Donc plutôt que de devoir bruteforcer un hash complet, il peut essayer plusieurs h ayant des débuts différents, mesurer le temps de réponse du serveur, et garder le plus long; et ainsi reconstruire hash en temps linéaire plutôt qu'exponentiel. C'est une type de side-channel attack que je trouve très élégant. Avec des applications diverses si on élargit l'éventail au-delà de l'attaque de serveur de distribution de clé. Permet de vérifier rapidement la présence d'él'ements divers dans des bases de données (nom d'utilisateur, champs de table etc..). Des délais de quelques microsecondes sont facilement décelables statitisquement au milieu du bruit (fluctuations poisonniennes liées au changement de contexts du thread, le pigeon sur le fil qui modifie la dispersion du signal etc) si l'algorithme de comparaison des données du client et du serveur n'est pas constant dans le temps. En effet, Code : == Code : for(int i = 0; i <client_input_data_len; i++) Ici la comparaison est linéaire, tout dépend de l'algorithme. Mais en restant évasif, quelqu'un pourrait comprendre qu'en "bruteforcant" avec des entrées qui ont par exemple des distances de Levenshtein différentes à la valeur comparée, on peut mesurer en MOYENNE des écarts systématiques dans les délais de réponse du serveur. Le sujet est riche, en passant par le champ time-stamps du protocol TCP/IP, à d'autres protocoles modernes. En gros, tout traitement de données client-serveur qui n'est pas invariant dans le temps est intéressant Je pourrais partager l'idée peut-être qu'il existerait des banques qui utiliseraient des dispositifs QKD (quantum key distribution) pour la cryptographie et l'échange de données sur quelques kilomètres reposant sur l'intrication EPR entre des modes comprimés de la lumière. La création de clés a usage unique (non composites) étant le résultat de plusieurs mesures effectuées sur l'une des deux quadratures de la lumière (phase ou amplitude). Si vous êtes encore entrain de lire , le choix de la mesure de la phase ou de l'amplitude se faisant aléatoirement avec un phase-shifter de 90 degree, un attaquant pourrait reconstituer la séquence de mesures (phase amplitude amplitude phase phase etc..) car la bande passante des phase-shifter telecom est faible (cela prend un certain temps de passer d'une quadrature à une autre) .. enfin bref gruik j'espère que tu te portes garant pour le blabla que je pourrai raconter |
|
28-02-2013, 08h29
Message : #24
|
|
gruik
gouteur de savon Messages : 757 Sujets : 44 Points: 482 Inscription : Oct 2012 |
RE: [C/C++] BruteForce |
|
28-02-2013, 14h29
Message : #25
|
|
notfound
#!/usr/bin/env bash Messages : 687 Sujets : 47 Points: 271 Inscription : Sep 2012 |
RE: [C/C++] BruteForce
|
|
« Sujet précédent | Sujet suivant »
|
Utilisateur(s) parcourant ce sujet : 1 visiteur(s)