Hello
 
je voulais savoir ou je pourai trouver un soft qui fasse du brute force sur ssh, ce n'est pas du tout pour hacker c'est juste pour pouvoir prouver que les password à 3 carractères c'est mal...
 
Merci

Utiliser des mots de passe sur ssh c'est pas secure    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
-> []  

bah y a peut etre une option ki interdit de se loguer apres un certain nb d echec d authentification

john the ripper mais c'est pas spécialement pour ssh et il doit être assez vieux. M'enfin un password à trois caractères il va te prouver que c'est vraiment de la merde
 
CHaiCA

bah ca fais pas bcp de possibilites 3 char
 
a 1000 pass/sec, ca va vite

 
Tu m'étonnes
 
CHaiCA

Tiens au fait c'est quoi le "sshnuke" qu'on voit dans le film Matrix 2 ? Ca existe ?

un tit buffer overflow ??

surtout qu'il se passe 3 secondes, par défaut, entre chaque tentative  

pas si tu tombes rapidement sur le bon pass

 
J'en ai déjà entendu parler mais c'est quoi un buffer overflow ? Un buffer (zone mémoire) qui se rempli trop ? Qui dépasse sa capcité maximale ? En quoi cela peux il consituer une faille ?
 
Au fait je ne sais pas si ssh utilise le même principe, mais lorsqu'on se loge avec le programme login, si on se trompe de passe, il y a un petit temps. Est-ce justement pour éviter qu'un programme ne teste ou bien c'est une vérification qui met du temps ?

1. buffer overflow : depassement de tampon
tu ecrases les donnes jusqu a ecrire sur l adresse de retour de la fontion. En s y prenant bien, tu lances un shell en root
plus d info : www.phrack.org
voir le numero 45 ou 49 je crois (Smashing The Stack For Fun And Profit)
 
 
2. le truc c est k un mdp faux est tjs plus long (bcp plus ) a etre verifie k un mdp correct, car le prog doit se tapper tous les mdp pour verifier s il est bon ou non
c est bizarre kan meme, car une faille existe sur ce principe (du tps), et la correction consistait justement a faire du tps constant
 
bon apres avec un pass de + de 8 char avec les char etendus, et c est bon, brute force tu oubli

 
Merci pour ces explications    
 
Donc tu veux dire que le laps de temps quand on rentre un faux password n'est pas du tout voulu pour éviter une brute force mais uniquement car il faut du temps le vérifier ? Tu me parles de temps constant ? Moi je pensais justement que c'était une protection car ce temps est identique sur mon Pentium 200 et sur un Pentium 4.

 
t'as pas compris, il veut dire qu'entre chaque tentative il s'écoule 3 sec, alors si tu teste en brute force d'une manière séquentielle entre aaa et zzz (par ex) et que le pass est zzz tu te tapes nb possibilitées * 3 sec

 
je crois que tu raconte des conneries au niveau du 2°    
 
Le temps c'est juste pour éviter le brute force et ses [beaucoup] tentatives/seconde, d'ailleurs ca se paramètre dans /etc/login.def (FAIL_DELAY)
 
C'est sûrement pas le temps de tester le pass qui est long, puisque login crypte le mot de passe donné dans un algo non-réversible (cad on peut crypter un pass mais pas l'inverse, obtenir le pass a partir du truc crypté) et le compare à celui stocké dans /etc/passwd ou /etc/shadow, si c'est le même résultat, c'est que les pass de départ en clair sont les mêmes.

Merci. C'est bien ce que je pensait. Et ssh utilise login et le meme principe ?

je ne sais pas trop comment ils ont voulus le faire pour ssh ou su
surtout ke logiquement, le pass devrai etre verifie suivant le login rentre

sisi
 
mais bon, comme il le prenait de haut

 
Apparement quand j'essaye de me logguer par ssh, en cas de mauvais mot de passe ca met aussi 3 sec d'attente (comme pour le login en console).
 
Donc c'est probable que tout ce qui est système d'authentification qui utilise /etc/shadow utilise les paramètres /etc/login.defs
 
Je regarderais ce soir plus en détails

oui je sais, mais en fait ce ke je disais s applique surtout au tel portable
 
par contre, il n y a pas ke du cryptage, y a aussi du hashage
 
mais sinon pour rendre encore plus innoperent le brute force, tu mets le nb de login faux a 3 puis impossible ensuite
mais bon, ca devient du DOS la

 
je capte plus rien a tes posts, tu pourrais me réexpliquer ? suis paumé là    
 
et sinon pour le shell root c'est de moins en moins possible, au mieux tu te retrouve avec les droits du daemon, et au pire avec les droits du daemon dans un chroot.

je disais ke logiquement, pour verifier un mdp, il faut le faire suivant le login donne juste avant, c tout
 
sinon, pour les buffer overflow : bah oui normal koi

Je crois justement qu'il y a là une faille à ssh, en effet, on doit attendre 3 secondes mais rien interdit de faire plusieurs requêtes à la fois je pense

ah mon avis tu devrais prévenir les développeurs, ils n'ont surement pas pensé à mettre des options pour limiter les tentatives ou demandes de connection.
 
d'une part c'est sur on se rend compte de rien quand on a 1 000 000 demandes de login à la seconde, d'autre part le réseau suis très bien, enfin le pc rame pas du tout à faire 1 000 000 connections en rsa 1024 bits

mais ca suffit, tu peux eviter de tout prendre de haut pour faire une remarque

D'autant qu'on parle de passwords de 3 caractères  

 
et quand t'as choisis ton pass de 3 caracteres; tu t'as pas fait méchemment insulté par passwd ?

si t avais lu depuis le depart, tu aurai appris ke justement il voulais demontrer k un pass de 3 char ct de la merde

oui je sais lire meci, mais la démonstration de l'insulte c'est suffisant...

 
 
-> insulté  
 
quand il parle de l'insulte il veut dire que en choisissant un pw pourrave normallement on te le dit "password too short" ou "week password"
 
 

 
Si t'es root et que tu décide de ne plus avoir de password ou mettre un password de me*de le system te laissera faire (encore heureux )
Un passwd -d root et c'est fini.
 
Pour en revenir à l'overflow en lui même, lors de l'éxécution d'un programme (ce n'est que du code machine interpretté par l'OS) tu peux "forcer" l'OS à lire une zone mêmoire suite à un B.O.
 
En fait ton overflow s'exécute et généréalement la suite un un morceau de code. Une fois le BO achevé le soft est qui tourne est "perdu" et exécute ce qu'il a sous la main (donc le bout de code en question) qui lui peut être 'simplement' un appel à "passwd -d root".
 
Si ce programme tournait en tant que root, non chrooté (donc possible d'éxécuter la commande passwd et aussi d'atteindre /etc/password) tu te retrouve avec une machine sans password root    
 
En pratique les BO sont utilisé pour aller chercher sur un site qui met à dispo un soft ave backdoor par exemple. (avec netcat entre autres)
 
Bon tout ceci n'est pas de la science pure mais ce que j'ai pu constaté en suivant des traces d'attaques (réussies ou non).
Il peut donc y avoir des choses qui ne sont pas sure ou mal interprétées

 
lancez un peu xchat en root pour tester  

+1 toutafedaccord

po bien de lancer des applis utilisant X en root