IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Une faille OpenSSH rend les serveurs plus vulnérables aux attaques par force brute


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 440
    Points : 197 458
    Points
    197 458
    Par défaut Une faille OpenSSH rend les serveurs plus vulnérables aux attaques par force brute
    Une faille OpenSSH rend les serveurs plus vulnérables aux attaques par force brute,
    en permettant la modification du nombre d'essais pour une authentification

    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 - Visualiser dans une fenêtre à part
    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2014
    Messages : 18
    Points : 28
    Points
    28
    Par défaut
    malin le gars, malin...

  3. #3
    Membre confirmé Avatar de herzleid
    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Juin 2002
    Messages
    393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Directeur des systèmes d'information

    Informations forums :
    Inscription : Juin 2002
    Messages : 393
    Points : 509
    Points
    509
    Par défaut fail2ban
    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 !

  4. #4
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    J aime knock pour ajouter une couche de securite sur les serveurs les plus exposes.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  5. #5
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2013
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 53
    Points : 168
    Points
    168
    Par défaut
    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 )

  6. #6
    Membre éclairé Avatar de laloune
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    Mai 2005
    Messages
    484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : Mai 2005
    Messages : 484
    Points : 873
    Points
    873
    Par défaut
    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?
    laloune
    Consultant B.I.
    Spécialité(s): Excel, SQL, Business Intelligence (Jedox Palo, Talend)

    "A problem worthy of attack proves its worth by fighting back." Piet Hein

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    63
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 63
    Points : 103
    Points
    103
    Par défaut
    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...

Discussions similaires

  1. FREAK : une faille permettant d’espionner les connexions chiffrées
    Par Hinault Romaric dans le forum Actualités
    Réponses: 9
    Dernier message: 20/03/2015, 10h05
  2. Réponses: 2
    Dernier message: 01/11/2011, 03h11
  3. Les serveurs du noyau Linux compromis par un malware
    Par Hinault Romaric dans le forum Linux
    Réponses: 13
    Dernier message: 11/09/2011, 19h12
  4. Réponses: 47
    Dernier message: 23/07/2010, 14h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo