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 :

Un bogue dans Java et Python permettrait à des attaquants de contourner les défenses des pare-feu


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 383
    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 383
    Points : 196 425
    Points
    196 425
    Par défaut Un bogue dans Java et Python permettrait à des attaquants de contourner les défenses des pare-feu
    Un bogue dans Java et Python permettrait à des attaquants de contourner les défenses des pare-feu,
    selon des chercheurs en sécurité

    Des chercheurs ont rapporté l’existence d’une faille dans Java et Python qui permettrait à des attaquants de contourner les défenses fournies par les pare-feu. Alexander Klink et Timothy Morgan ont assuré que la principale vulnérabilité s'est produite parce que Java ne vérifie pas la syntaxe des noms d'utilisateurs dans son protocole FTP.

    « Le code (probablement ancien) a un bogue : il ne vérifie pas la syntaxe du nom d'utilisateur. RFC 959 spécifie qu'un nom d'utilisateur peut se composer d'une séquence de n’importe lequel des 128 caractères ASCII sauf <CR> et <LF>. Devinez ce que les exécutants de JRE ont oublié ? Précisément de vérifier la présence de <CR> ou <LF>. Cela signifie que si nous mettons %0D%0A n'importe où dans la partie nom d’utilisateur de l'URL (ou dans la partie mot de passe), nous pouvons terminer la commande USER (ou PASS) et injecter une nouvelle commande dans la session FTP », a expliqué Klink.

    Pour rappel, CR et LF désigne respectivement le retour chariot (Carriage Returns - caractère 13 (0x0D)) et le saut de ligne (Line Feeds caractère 10 (0x0A)).

    Aussi, si nous avons par exemple l’intention de nous servir de la commande USER sur un serveur mail au lieu d’un serveur FTP, nous obtiendrons une génération d’erreur (étant donné que USER n’est pas une commande SMTP valide), mais notre session va continuer. Combiné avec le bogue mentionné, un attaquant sera alors en mesure de lancer des commandes SMTP arbitraires qui vont forcer l’envoi de courriels.

    « Cette attaque est particulièrement intéressante dans un scénario où vous pouvez accéder à un serveur de messagerie interne sans restriction sur une machine faisant du parsing XML. De plus, cette attaque va vous permettre d’envoyer des pièces jointes étant donné que la taille de l’URL semble ne pas être limitée en dehors de la limite imposée par la quantité de RAM disponible », a estimé Klink.

    La vulnérabilité peut également être exploitée pour faire du parsing de fichiers JNLP malveillants, conduire des attaques man-in-the-middle (MiTM) ou des campagnes SSRF (Server-Side Request Forgery).

    Selon Morgan, « cette injection de protocole FTP permet de tromper le pare-feu d'une victime en autorisant des connexions TCP d'Internet vers le système de l'hôte vulnérable ».

    Dans le cas de Java, l'attaque peut être effectuée contre des utilisateurs de desktop même s'ils n'ont pas le plugin de navigateur Java activé.

    Le chercheur dit également qu'un bogue « presque identique » existe aussi dans les bibliothèques urllib2 et urllib de Python. Cependant, bien que la faille de sécurité Java ne soit pas limitée aux attaques basées sur des noms de répertoires répertoriés dans des URL malveillantes, le bogue Python semble être limité de cette manière.

    Morgan affirme que les fournisseurs ont jusqu'à présent échoué à réparer le bogue, bien que l'équipe de sécurité de Python ait été informée en janvier 2016 et que l'équipe d'Oracle ait été informée en novembre 2016.

    Le chercheur recommande la désactivation du mode classique FTP par défaut et propose que les applications en entreprise soient auditées pour vérifier si elles sont vulnérables à ces attaques.

    Source : billet Alexander Klink, billet Timothy Morgan
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 414
    Points : 1 508
    Points
    1 508
    Par défaut Une petite pincée de FUD
    En fait ce bug n'en est pas vraiment un. Celui qui code en Java ou en Python pour aller faire de l'injection FTP sait très bien ce qu'il fait et n'a pas besoin de ce bug pour envoyer les commandes qu'il a envie. Et de toute façon, FTP n'a pas été conçu à une époque où l'on s'occupait de sécurité. L'utiliser aujourd'hui c'est s'exposer à bien des problèmes.

  3. #3
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    C'est un peu plus compliqué que ça. Il n'y a pas d'objet officiel pour se connecter directement en FTP dans la bibliothèque standard Java. Mais on peut bien en faire de manière indirecte via l'objet URLConnection. Si on ne fait pas les contrôles adéquats, il y a donc moyen de faire une injection en utilisant une URL de type FTP en remplacement de http par exemple.

  4. #4
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2005
    Messages
    262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2005
    Messages : 262
    Points : 665
    Points
    665
    Par défaut
    J'ai rien compris en lisant l'article en Français, donc si quelqu'un qui a le même cerveau que moi passe par ici, voilà plus de détails à partir du billet de Klink.

    Où est le bug ?

    Le bug est que java ne s'occupe pas des cr/lf lorsqu'il parse les urls de type:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ftp://foo:bar%0d%0aINJECTED%0d%0a@example.net/dir/file.png
    Donc si on demande à java de se connecter à un serveur FTP en utilisant cette url, il va se connecter normalement sur le serveur FTP de example.net, utiliser 'foo' comme nom d'utilisateur, 'bar' comme mot de passe, mais en plus il va exécuter la commande 'INJECTED'.

    Java gère mal les cr/lf à la fois dans le use/mdp mais aussi dans les noms de répertoires :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ftp://foo:bar@example.net/dir%0d%0aINJECTED%0d%0a
    Python se contente de mal gérer les cr/lf uniquement au niveau des noms de répertoires.

    Après, il se trouve que comme SMTP est proche de FTP, on peut utiliser la même url en ftp: pour faire exécuter des commandes sur un serveur SMTP.

    Que vient faire le contournement de firewall dans l'histoire ?

    Alors là c'est bien tordu...
    En gros en FTP, deux connections sont utilisées, une de contrôle avec le port 21 côté serveur, et une autre pour les données, donc avec des ports différents.

    Et "bien sûr" les pare-feu sont fait pour supporter ça ! En gros ils lisent les commandes de la connexion de contrôle FTP pour savoir quelle port est choisi et autorisent le trafic sur ce port. Donc sous prétexte de nous simplifier le boulot (D'avoir à autoriser le port pour les données à la main), le pare-feu fait sauter automatiquement une restriction sur un port donné.

    Pour exploiter les requêtes FTP vont ressembler à ça :
    On ne demande plus de se connecter à un serveur FTP chez la victime.
    evil.com est au contraire un serveur géré par l'attaquant.
    La commande PORT demande normalement au serveur de se connecter (Pour la connection de données) à la machine client sur un port donné.
    Le pirate doit y mettre l'IP (Interne, gare au NAT) de la victime et un numéro de port au choix (Mais supérieur à 1024).
    C'est cette commande que le pare feu va voir et il va donc autoriser les connections sur le port décrit (Par exemple 8080).
    Le pirate peut alors se connecter au port 8080 de la machine victime (Qui peut par exemple être ouvert par une appli Java) depuis l'extérieur, magique.

    La vulnérabilité peut également être exploitée pour faire du parsing de fichiers JNLP malveillants
    Non en fait le JNLP est simplement un vecteur d'attaque proposé en alternative aux applets qui ne sont pas utilisables si les victimes "n'ont pas le plugin de navigateur Java activé". A priori il y aurait moyen de mettre les urls directement dans le fichier JNLP donc la victime n'a même pas besoin d'utiliser l'application Java correspondant au JNLP.

    Un autre vecteur intéressant est les "XML eXternal Entities". Si on met correctement les urls ftp dans des fichiers xml et que le parseur xml en java est "mal" configuré (Ce qui est bien souvent le cas par défaut), le parseur va se connecter automatiquement en utilisant les requêtes FTP pour "résoudre les entitées externes".
    Donc en gros une appli java dans un serveur web parsant des fichiers xml venant de l'extérieur est vulnérable (Dans le sens ou on peut lui faire faire des requêtes FTP, qui plus est avec des commandes additionnelles).

Discussions similaires

  1. Réponses: 0
    Dernier message: 03/09/2010, 12h16
  2. Réponses: 13
    Dernier message: 22/04/2009, 17h43
  3. Réponses: 0
    Dernier message: 14/04/2009, 00h40
  4. Réponses: 4
    Dernier message: 16/08/2006, 10h19
  5. Réponses: 1
    Dernier message: 21/07/2006, 06h56

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