Mise à jour : Les versions Apache Struts 2.3 et 2.5 ont maintenant leurs correctifs officiels.
Nous avons mis à jour nos conseils ci-dessous en conséquence [07/09/17]
Nous avons l’impression que c’était hier, mais en fait c’était il y a déjà six mois, que nous avions écrit à propos d’une sérieuse faille de sécurité dans Apache Struts.
Malheureusement, l’histoire se répète, avec une faille semblable qui peut être exploitée de la même manière.
Voici quelques explications.
Apache Struts est un outil logiciel pour créer des applications web basées sur Java, et qui fonctionnent sur votre serveur web.
Apache Struts peut être utilisé pour la construction de services internet tels que des boutiques en ligne ou des forums de discussion : avec Struts, vous pouvez générer des pages web à la volée, du contenu web sur mesure et adapté à l’utilisateur qui est en train de visiter votre site, répondre à des formulaires en ligne remplis par vos visiteurs, et bien plus encore.
Vous pouvez indiquer ou doit aller ce flux de données, étant donné qu’une partie importante de toute structure d’une application web doit gérer les risques implicites liés à la sécurité au niveau de la requête, de l’acquisition et de la réponse aux données téléchargées par des personnes externes.
Et c’est justement ici que se trouve le bug Apache Struts, connu sous le nom de CVE-2017-9805.
Toutes les applications doivent traiter les données en entrée comme potentiellement hostiles, même si elles proviennent d’une source interne qui est supposée être sous votre contrôle. Mais lorsque les données proviennent de sources externes non fiables, vous devez aller encore plus loin et partir du principe qu’elles sont activement hostiles, à savoir qu’elles sont piégées par un moyen quelconque, et ce jusqu’à ce vous ayez de bonnes raisons de penser le contraire.
Quel est ce bug dans Apache Struts ?
Avec un plugin appelé Struts REST, votre application web peut interagir avec les visiteurs au moyen du Representational State Transfer (REST en abrégé).
Un service web basé sur REST, connu de façon familière comme un service RESTful car il est considéré comme inoffensif d’un point de vue programmation, ne possède pas une URL de recherche élargie, avec des données codées comme suit :
Au lieu de cela, il possède une URL standard à utiliser pour les transactions, avec les données nécessaires à la requête web ou à la réponse, qui sont mises “RESTfully” dans le corps HTTP.
Les requêtes web RESTful sont généralement soit GET (par exemple, pour afficher un enregistrement de base de données), PUT (pour mettre à jour un enregistrement), PATCH (pour changer un champ dans un enregistrement) ou POST (pour créer un nouvel enregistrement), avec la syntaxe suivante :
Notez que le processus REST ne spécifie pas la manière avec laquelle vous êtes censés représenter ou coder les données que vous souhaitez envoyer ou recevoir, cette partie dépend donc de vous.
Dans l’exemple ci-dessus, nous avons utilisé le langage HTML de base (plus précisément, le XHTML), mais il existe de nombreuses façons de transformer des structures de données complexes en lignes de texte, qui seront alors sécurisées et adaptées à une requête web.
Les formats populaires incluent JSON (JavaScript Object Notation) et XML (Extensible Markup Language).
Struts REST prend en charge XML à l’aide d’une librairie de programmation appelée XStream, qui s’avère être plus puissante que nécessaire, pour échanger des données entre navigateurs et serveurs.
En effet, XStream vous permet de coder n’importe quel type d’objet Java en XML (c’est une technique qui dans le jargon s’appelle serialisation, car elle convertit arbitrairement des séries complexes de données binaires structurées, en un ensemble de chaînes de caractères texte), et pas seulement en utilisant des nombres et du texte.
Dans quelle mesure ce bug Apache Struts me concerne ?
Comme la documentation de sécurité XStream l’explique plutôt platement :
Par design, il existe peu de limites aux types d’objets que XStream peut gérer. Cette flexibilité a un prix. […] Le XML généré par XStream contient toutes les informations requises pour créer des objets Java de presque n’importe quel type. Cela pose un problème de sécurité potentiel.
[Les données XStream XML] peuvent être manipulées en injectant la représentation XML [des objets Java qui ne sont pas supposés être présents]. Un cybercriminel pourrait en profiter pour exécuter des codes arbitraires ou des commandes shell au niveau d’un serveur exécutant le processus XStream.
En bref, toute application qui utilise XStream, et donc par association, toute application RESTful Struts qui utilise XML pour son échange de données, doit veiller à ne pas permettre à des cybercriminels d’y intégrer des données piégées.
Malheureusement, jusqu’à Apache Struts 2.5.13 (sortie mardi 05 septembre 2017) et Apache Struts 2.3.34 (sortie jeudi 07 septembre 2017), un XML piégé pouvait alimenter un serveur Struts, permettant ainsi à des cybercriminels d’intégrer des commandes dans ce qui était supposé être des données basiques.
En effet, un cybercriminel bien informé pourrait présenter des données codées en XML à Struts, qui seraient ensuite traitées comme des commandes lors du décodage des données, dans un premier temps.
En d’autres termes, au moment où votre application Struts est sur le point de valider les données qu’elle vient de recevoir, par exemple pour vérifier que le numéro de téléphone n’est pas faux ou que l’URL du site web n’est pas rempli d’exploits ou de malwares, le mal est certainement déjà fait !
Ce type de bug est connu sous le nom de RCE, (Remote Code Execution), et il signifie en général que les cybercriminels en question peuvent prendre automatiquement le contrôle de votre serveur à distance.
Par exemple, des cybercriminels peuvent entreprendre une action qui semble tout à fait innocente : une recherche de produit ou une vérification du niveau de stock, mais cette dernière déclenche en réalité délibérément une action secondaire malveillante, comme duper votre serveur pour qu’il divulgue des données, agissant ainsi comme un point de distribution de malwares, ou ouvrant une faille afin de permettre aux cybercriminels de revenir plus tard au sein de votre réseau.
Quoi faire ?
Les découvreurs de cette vulnérabilité affirment avoir un “simple exploit opérationnel” comme preuve de concept.
Ils prétendent que “au moment de l’annonce [05/09/2017], il n’y avait pas de raison de penser qu’il existait un exploit publiquement accessible, mais il est probable que cela soit le cas à l’avenir”, ce qui implique que les cybercriminels vont mettre en place leurs propres astuces assez facilement.
- Si vous utilisez Apache Struts, installez immédiatement le patch. Les versions Struts de 2.1.2 à 2.3.33 inclus, et de 2.5 à 2.5.12 inclus sont concernées. Des patchs officiels sont disponibles pour les versions Struts 2.3 et Struts 2.5.
- Si vous utilisez Apache Struts mais n’utilisez pas REST, supprimez le plugin Struts REST. Ainsi vous réduirez votre surface d’attaque potentielle en donnant aux cybercriminels moins d’opportunité pour vous cibler à l’avenir.
- Si vous utilisez Apache Struts REST mais n’utilisez pas XML, désactivez le support XML. Apache liste les paramètres de configuration dont vous avez besoin (ironiquement, la configuration est elle-même spécifiée à l’aide de XML) afin que le plugin Struts REST ne fonctionne qu’avec des pages web simples ou avec des données JSON, qui ne sont pas traitées par XStream.
- Si vous utilisez des services d’hébergement ou de développement externes, demandez à vos fournisseurs s’ils ont installé les patchs appropriés. Vous pouvez externaliser vos opérations, mais pas votre responsabilité !
- Pour les applications web futures, envisagez de vous limiter à JSON au lieu de XML pour l’échange de données. Les bibliothèques de programmation qui gèrent JSON ne sont pas à l’abri de ce genre de problèmes de sécurité, mais en comparaison la simplicité de JSON par rapport à XML en fait souvent un meilleur choix car elle réduit votre surface d’attaque.
Les lecteurs réguliers de notre blog cybersécurité savent que lorsqu’il est question de renforcer la sécurité en éliminant les plugins que vous avez installés, en limitant les options que vous avez activées et en simplifiant les technologies que vous avez sélectionnées …
…on finit souvent par citer M. Miagi dans “Karate Kid” : la meilleure façon d’éviter un coup de poing, c’est de ne pas être là !
Billet inspiré de Apache Struts “serialisation” vulnerability – what you need to know, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.