[IMPORTANT] Le plantage de cette nuit (merci pour votre aide et vos retours)

[steiner]

Bon allez puisque pour une fois je vais pouvoir vous expliquez quelque chose, j'en profite :

Ce dont parle Guepi c'est l'attaque Rainbow Table. Elle n'exploite en aucun cas une faille des algo de hashage, mais exploite l'idée du comprimis temps/mémoire. Le but de l'attaque est de trouver un password générant un  hash donné (i.e. on choppe le hash dans la DB mysql, et on récup un password donnant le même hash)
On part du constat que :
- générer tt les password et calculer les hashs correspondant : prend trop de temps
- stocker tous les hashs possibles avec un mdp associé : prend trop de place
=> il faut un comprimis temps/mémoire.

Comment qu'on fait ?
On va calculer UNE FOIS POUR TOUTE cette table-ci, où
" --> hx " : résultat de l'algo de hashage
" => y " : résultat d'une fonction de réduction (R1, R2 ou R3, selon la colonne), c-a-d une fonction à caractère aléatoire qui prend en entrée un hashé (genre de fct inverse d'une fct de hashage, mais ça veut pas dire que Reduction(hash(x)) = x hein ^^ ce serait trop facile )
Ci-dessous le nombres sont des caractères en clair, et les hx des hashés :


0 --> h0 => 6 --> h6 => 3 --> h3 => 9
2 --> h2 => 3 --> h3 => 5 --> h5 => 6
4 --> h4 => 8 --> h8 => 1 --> h1 => 1

Cette table est volontairement petite pour l'exemple, mais dans la réalité elle est très grande et prend énormément de temps  à calculer, mais on ne fait ce calcul que une fois.
On ne peut évidemment pas tout stocker, on ne stocke donc que la première et la dernière colonne (compromis mémoire).
Ici on stocke donc :
0 : 9
2 : 6
4 : 1

Ensuite qu'est ce qu'on fait ?
Donc comme annoncé on part d'un hashé, disons hx et on cherche un password qui produit le hashé hx.
1) On calcule la réduction R3 de hx
2) Le résultat est-il dans la dernière colonne ?
- oui : on recalcule la chaine à partir de son point d'entrée et on obtiendra la chaine initiale.
  Ex: si la réduction H3 de hx donne 9, on repart de 0 et on calcule : 0 --> h0 => 6 --> h6 => 3. On obtient le password "3" qui une fois hashé donne h3 = hx. Notez qu'on a du calculer qu'une seule ligne de la table (compromis temps)
- non : On applique R2 puis hash() puis R3 à notre hashé hx. Le résultat est-il dans la dernière colonne ?
   - oui : on recalcule la chaine à partir du début
   - non : on lui applique R1 puis hash() puis R2 puis hash() puis R3
etc.

Si on ne trouve aucun résultat c'est que la table n'est pas suffisamment grande.

Des tables de ce genre sont disponibles sur internet (cf. ce qu'a dit guepi j'imagine).

Voilà dsl pour le hors sujet (je le ferai plus )

Si certains sont intéresés mais n'ont rien compris à mon explication je suis dispo en MP

[mcroger]

Si certains sont intéresés mais n'ont rien compris à mon explication je suis dispo en MP

Mais il est un peu tard, donc partie remise.

[Origin]

Arnaud> merci pour l'éclairage . Effectivement quand je parlais de "faille dans les algos de hashage" c'était par construction, pas du tout vis à vis d'un manque quelconque de fiabilité ou de randomisation des système

[symaski62]

%SystemRoot%\system32\cmd.exe

C:\Users\jonathan>tracert forum.boinc-af.org

Détermination de l'itinéraire vers webservice.originet.eu [87.98.187.164]

12    56 ms    55 ms    55 ms  webservice.originet.eu [87.98.187.164]

hé  admin     

[Poulpito]

et ca apporte quoi un tracert ? 

[Douglas Riper]

C'est pour connaitre le nombre de connectés

[jm@rc]

C'est pour connaitre le nombre de connectés

on fréquente les même forums

[Origin]

%SystemRoot%\system32\cmd.exe

C:\Users\jonathan>tracert forum.boinc-af.org

Détermination de l'itinéraire vers webservice.originet.eu [87.98.187.164]
12    56 ms    55 ms    55 ms  webservice.originet.eu [87.98.187.164]

hé  admin     

oué, et donc quoi ?

[philmo]

euh ping trop gros ? pas bon pour poster plus vite que son ombre ? 

[symaski62]

OPOPOP les gars, je viens d'avoir ça en allant sur le forum


Faites bien attention, je crois que vous avez du boulot maintenant, le serveur est probablement infecté ! 

EDIT: ah bah j'ai eu la même ! Sauf que moi par mesure de professionnalisme (lol) j'ai fait un screen

oué, et donc quoi ?

oui  ^^ 

IP
87.98.187.164   contre  216.218.195.101 (phishing)

C:\Users\jonathan>tracert 216.218.195.101

Détermination de l'itinéraire vers 216.218.195.101 avec un maximum de 30 sauts.

13   203 ms   205 ms   200 ms  216.218.195.101

[Origin]

je comprends pas tu veux dire quoi symask ?

vous comprenez vouzot'

[Origin]

C'est pour connaitre le nombre de connectés

arf, p'tin je l'avais loupé celui là, doug

[symaski62]

je comprends pas tu veux dire quoi symask ?

vous comprenez vouzot'

à un handicap général de 80% et il fait beaucoup d'efforts pour la communauté et pour s'expimer, merci d'être compréhensif.

[Origin]

Mais c'était pas une critique, je veux juste comprendre ce que tu pointais !

[Black Hole Sun]

@symaski62 :
Un tracert permet de suivre le chemin qu'un paquet de données (paquet IP) va prendre pour aller de la machine locale à une autre machine connectée au réseau.
http://fr.wikipedia.org/wiki/Traceroute

Le ping sert quant à lui à déterminer le temps mis par des paquets pour atteindre une autre machine connectée au réseau.

Ces deux commandes n'ont aucune autre utilité. Dans le cas présent, on ne comprend pas à quoi elles peuvent servir. En l'occurence, à rien d'ailleurs.
Je pense que tu veux montrer quelque chose mais que tu n'utilises pas les bonnes commandes ou que tu as mal compris à quoi tracert et ping servent.

[overclockman]

Mais c'était pas une critique, je veux juste comprendre ce que tu pointais !

D'après ce que j'ai compris avec mes très petite connaissance en la matière, il s'agit d'une redirection pour du poissonage sauvage, c'est ça ?

[[AF>Libristes] Guepi]

La tracert de symaski62 sert à prouver qu'il n'y a pas de fishing chez lui.

Une telle commande chez un "infecté" permettrait de savoir si l'infection provient de sa machine (couche réseau touchée) ou de son navigateur... 
amha 

[overclockman]

La tracert de symaski62 sert à prouver qu'il n'y a pas de fishing chez lui.

Une telle commande chez un "infecté" permettrait de savoir si l'infection provient de sa machine (couche réseau touchée) ou de son navigateur... 
amha 

pareil keskejaidit mais en mieux, merci guepi

[Black Hole Sun]

euh, je ne suis pas certain qu'un tracert permette de visualiser ça.
dans le cas d'un phishing où un serveur relais sert de proxy entre l'hôte local et le web, ok
mais à moins de collecter une tonne de données qui devront être ensuite analysées, je pense qu'il est nécessaire de filtrer les adresses à faire passer par le proxy de phishing.
Une telle mise en oeuvre sert généralement à capturer des codes de cartes bleues ou des données sensibles bien spécifiques. Mettre ça en place pour viser le forum de l'AF, ça me parait un peu compliqué non ?

[Jim PROFIT]

C'est pour connaitre le nombre de connectés

Je l'adore....

[Poulpito]

il est pas mal ce tit kevin la avec son tracert (celui de youtube ein  )

non en fait effectivement
ce que voulait montrer symaski62

quand nous on se connecte sur forum.boinc-af.org ou qu'un fait un tracert du dns  -> on se dirige sur le serveur (ou la passerelle enfin bref  ca pointe vers) 87.98.187.164 qui fait parti du pool d'origin (webservice.originet.eu)

par contre si on regarde le screen de sivade
chrome lui dit que le site forum.boinc-af.org  correspond à 216.218.195.101

soit un soucis de dns chez sivade   soit cette ip a un lien qqconque avec google chrome 
en tout cas tu n'es pas le seul sivade :
http://www.google.fr/search?hl=fr&q=216.218.195.101+chrome&btnG=Rechercher&meta=&aq=f&oq=


comme ca  pour ceux qui n'avaient pas compris  j'espère que c'est plus clair 
donc aucun lien direct avec l'af ou un résidu qqconque

[jm@rc]

tu as parfaitement résumé ce que symasky62 pointait du doigt 

[Pascal94]

tout de suite, on comprend mieux 

merci poulpi 

[philmo]