Contournement de garde-barrière et Applets java

Fin juillet 2005, un chercheur allemand (Florian Weimer) a publié un article décrivant comment une applet java malicieuse pouvait contourner les protections définies par le garde-barrière de l'entreprise et permettre à un attaquant externe d'accéder illégalement à des services normalement filtrés.

Nous décrivons ici la méthode d'attaque proposée par Weimer et les recommandations que nous en tirons pour protéger l'entreprise contre ce type de vulnérabilité.

Le scénario d'attaque

Un pirate met en place sur un serveur web une applet Java malicieuse. Lorsqu'un internaute visite ce site, si son navigateur web autorise l'exécution d'applets Java, cette applet est alors automatiquement téléchargée puis exécutée.

Une telle applet s'exécute dans un environnement contrôlé ("sandbox" JAVA), qui limite les actions possibles, et l'on considère donc assez souvent qu'il n'est pas très dangereux d'autoriser les applets.

En l'occurrence cette applet est dangereuse, car elle a été codée pour simuler une connexion FTP vers le site web depuis lequel elle a été téléchargée (ce type d'action est autorisé par la "sandbox" Java). Schématiquement, la suite des commandes FTP lancées par l'applet est alors la suivante :

1.  OPEN www.site_malicieux.com
2.  PORT 445
3.  LIST

Elle indique qu'une session FTP est initialisée avec le serveur web et que les données de cette session seront reçues sur le port TCP 445 du poste local.

Si l'internaute (que nous appellerons désormais "victime" …) se trouve dans une entreprise protégée par un garde-barrière à "stateful inspection" (i.e. un garde-barrière évolué "classique") qui est configuré pour autoriser le trafic FTP "sortant", alors ce garde-barrière va (en voyant la commande "PORT" à l'intérieur de la session FTP) autoriser le trafic entrant provenant du serveur web et à destination du port TCP 445 sur le poste de la victime.

En fait, le port 445 sur le poste de la victime n'a rien à voir avec l'applet ; il s'agit en effet du port standard utilisé par Windows pour effecteur des échanges RPC (et des partages de fichiers via CIFS/SMB). L'objectif de l'applet malicieuse est donc de leurrer le garde-barrière en lui faisant ouvrir (sous prétexte de supposés échanges FTP) des autorisations vers des services potentiellement vulnérables sur le poste de la victime. Par exemple le port TCP 445 est celui qui a été utilisé par les vers Zotob (CERT-IST/AV-2005.301) et Sasser (CERT-IST/AV-2004.132) pour infecter des plates-formes Windows vulnérables.

Dans ce scénario, hormis le fait d'avoir autorisé au niveau du garde-barrière le trafic FTP sortant, personne n'est réellement fautif :

• Les spécifications JAVA et les règles de sécurité de la "sandbox" ont été respectées.
• Le garde barrière a effectué nominalement son travail de filtrage et l'adaptation dynamique de ce dernier.

Par contre la menace est réelle et la machine de la victime se trouve ainsi exposée à des attaques contre lesquelles on pensait qu'elle était protégée (elle n'est plus protégée par le garde-barrière).

Florian Weimer explique enfin que FTP et JAVA ne sont probablement pas les seuls couples de protocoles permettant ce type de contournement. Plus généralement tous les protocoles pour lesquels le garde-barrière effectue un filtrage adaptatif sont "à risque". Il cite ainsi : IRC/DCC, SUN-RPC et H323/SIP.
Un code de démonstration a été développé pour prouver la réalité de la menace et pour permettre de tester le comportement des gardes-barrières. Il contient :

• Une applet JAVA malicieuse (se comportant comme décrit ci-dessus)
• Et un faux serveur FTP, à installer sur le serveur web, qui dialogue avec l'applet JAVA.

Comment se protéger ?

Florian Weimer ne propose pas réellement de solution au problème qu'il soulève. Pour notre part, nous tirons deux "leçons" de la vulnérabilité qu'il décrit.

Tout d'abord, il faut limiter l'utilisation des Applets : même si une applet Java s'exécute dans un environnement protégé comme la "sandbox", il reste cependant un code "externe" non maîtrisé (l'applet est un code "binaire" dont on ne peut prédire facilement ce qu'il contient exactement).

Mais surtout, il faut interdire toute connexion entrante au niveau du garde-barrière, et ce même au travers du filtrage dynamique (le "stateful inspection" des gardes-barrières). Par exemple, si seul le FTP "passif" avait été autorisé par le garde barrière, l'attaque décrite n'aurait pas été possible (elle utilise un FTP "actif").

A défaut (ou en complément), il est enfin utile de surveiller les trafics sensibles. Ainsi, si l'on identifie les trafics FTP comme "à risque", et que l'on met en place une analyse des journaux pour déterminer qui utilise cette fonctionnalité, on sera alors sans doute à même de remarquer un comportement de type "Applet malicieuse" : si l'on détecte que le poste XXX de l'entreprise se met à générer du trafic FTP(alors que ce poste n'en avait jamais fait auparavant), ou si des ports inhabituels sont utilisés lors des transferts FTP, il y sans doute une anomalie potentielle à analyser.

Pour plus d'information

Article "The Java/Firewall vulnerability" de Florian Weimer : http://www.enyo.de/fw/security/java-firewall/