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 !

Une faille OpenSSH rend les serveurs vulnérables aux attaques par force brute
Après une modification du nombre d'essais pour une authentification

Le , par Stéphane le calme

68PARTAGES

4  0 
Une faille dans OpenSSH, l’un des logiciels les plus populaires pour les accès sécurisés à distance aux systèmes UNIX, permettrait à des attaquants de contourner la restriction des tentatives d’essai d’authentification afin d’avoir une plus grande latitude pour trouver le bon mot de passe suite à de nombreuses conjectures.

Par défaut, le service de chiffrement n’autorise que six essais. Cependant, cette vulnérabilité permettrait aux attaquants de tester autant de mots de passe qu’ils le souhaitent, et qui seraient limités par un réglage « login grace time », initialisé à deux minutes par défaut. Ce qui signifie donc qu’un attaquant pourrait écrire un script qui essaye des milliers de combinaisons dans cette période sans que la connexion ne soit interrompue.

C’est un chercheur en sécurité qui a utilisé l’alias Kingcope qui le fait savoir dans un billet, précisant que les systèmes FreeBSD sont affectés par cette vulnérabilité parce qu’ils ont l’authentification interactive clavier activée par défaut. Pour illustrer ses propos, il a donné un exemple de commande qui permettrait de changer la limitation du nombre de mots de passe et de le faire passer à 10 000 durant le « login grace time ».

Code : Sélectionner tout
ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x 10000'` targethost

« La partie cruciale est que si l’attaquant demande 10 000 dispositifs de claviers interactifs, OpenSSH va gracieusement exécuter la requête et la demande sera à l’intérieur d’une boucle qui va accepter les mots de passe jusqu’à ce que le nombre de dispositifs prévu vienne à être dépassé ».

Dans son billet, il a écrit le code d’un exploit qui pourrait être utilisé avec la dernière version d’OpenSSH qui est la version 6.9. Dans un autre billet, le même auteur a expliqué que le même exploit a fonctionné face à une version d’OpenSSH intégrée dans une version du système d’exploitation FreeBDS publiée en 2007. Bien entendu, il affirme être déjà entré en contact avec les responsables qui lui ont signifié qu’ils assigneront un CVE (Common Vulnerabilities and Exposures), un dictionnaire des informations publiques relatives aux vulnérabilités de sécurité, et travailleront sur un correctif.

D’un certain angle, la gravité de la vulnérabilité pourrait être considérée comme légère. Mais cela suppose que les utilisateurs d’OpenSSH se servent d’une clé de chiffrement pour l'authentification. Avec une telle configuration, seuls les ordinateurs possédant la clé privée seront en mesure d'accéder au serveur. En plus de cela, les serveurs eux-mêmes devraient être configurés de sorte que le nombre de tentatives de connexion soit limité, une mesure qui pourrait grandement limiter la portée de ce vecteur d’attaque.

D’un autre côté, la vulnérabilité a le potentiel de créer de sérieux problèmes. Les attaques par force brute contre des machines où SSH est activé sont des événements réguliers d’après des études comme celle du spécialiste en sécurité Sucuri ; des études qui suggèrent que suffisamment de serveurs restent vulnérables à ce type d’attaque.

« Malheureusement, les attaques SSH par force brute restent une menace crédible sur internet, alors cette vulnérabilité va les rendre encore plus faciles et plus efficaces », a avancé Jon Oberheide, Directeur Technique du fournisseur de services d’authentification à deux facteurs Duo Security. « C’est l’un de ces bugs qui n’affecteront pas les serveurs bien configurés, mais les autres serveurs, qui étaient déjà vulnérables face à un faible débit d’attaques par force brute, le seront plus encore ».

Source : blog Kingscope, requête de Kingman pour un CVE, blog Sucuri

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

Avatar de herzleid
Membre confirmé https://www.developpez.com
Le 23/07/2015 à 22:02
Logiquement sont touché les serveurs Unix et Linux qui utilisent openssh non ? (je n'ai pas trop compris pourquoi ça ce limitait dans le texte à openbsd et freebsd)

Sont aussi touché tous les systèmes qui utilisent openssh sans le dire (licence bsd inside)

Cette faille est une raison supplémentaire d'utiliser fail2ban. L'exploitation de la faille devient tout de suite moins évidente !
0  0 
Avatar de abriotde
Membre expérimenté https://www.developpez.com
Le 24/07/2015 à 6:57
J aime knock pour ajouter une couche de securite sur les serveurs les plus exposes.
0  0 
Avatar de DarkHylian
Membre habitué https://www.developpez.com
Le 24/07/2015 à 10:52
Citation Envoyé par herzleid Voir le message
Cette faille est une raison supplémentaire d'utiliser fail2ban. L'exploitation de la faille devient tout de suite moins évidente !
D'après l'article, je pense que fail2ban ne fera rien dans ce cas : le tout se fait dans une seule fenêtre de connexion, fail2ban lui aurait besoin de voir plusieurs tentative de connexion d'une même ip au service, alors que là, il s'agit clairement d'une seule tentative de connexion à ssh

Et apparement, quelqu'un d'autre y a déjà pensé, en allant sur l'article original et fouillant les commentaires, je suis tombé sur ceci :

Fail2ban will add a new rule to your firewall as configured, but whether it mitigates depends on your firewall config.

Taking linux as an example, if your INPUT chain looks like this

-A INPUT -m state –state related,established
-A INPUT -j fail2ban-ssh

Then the attackers existing connection won’t be blocked (so they’ll get 10,000 attempts). New connections will fail.

If you aren’t giving established connections a pass before checking fail2bans chain then it will mitigate.

On BSD, pf tends to be stateful (assuming you havent used ‘nostate’) so will give established connections a pass

Edit :
Le temps de lire la suite, et je m'aperçois qu'avec une configuration plus poussée, apparemment, f2b ferait bien son taf. J'ai pas tout compris mais il semble existait des règles pour ce genre de cas (je connais f2b... de loin ... de très loin )
0  0 
Avatar de laloune
Membre averti https://www.developpez.com
Le 27/07/2015 à 9:08
Mais cela suppose que les utilisateurs d’OpenSSH se servent d’une clé de chiffrement pour l'authentification. Avec une telle configuration, seuls les ordinateurs possédant la clé privée seront en mesure d'accéder au serveur.
Euh, c'est pas le minimum pour avoir un serveur un tant soit peu sécurisé?

Qui laisserait son serveur accessible sans chiffrement?
0  0 
Avatar de Ottakar
Membre régulier https://www.developpez.com
Le 31/07/2015 à 9:57
Je penses que tu mélanges la notion de chiffrement avec celle clé de chiffrement...
La clé permet une authentification sans utiliser de mot de passe, en revanche dans ce cas il est conseillé de sécuriser sa clef avec une passphrase qui sera vérifiée localement...
0  0 
Avatar de lingtalfi
Nouveau membre du Club https://www.developpez.com
Le 23/07/2015 à 15:43
malin le gars, malin...
0  1