Vulnérabilité critique dans Apache Struts

La semaine dernière, l’actualité concernant les vulnérabilités était remplie de technologies web avec des noms intrigants, comme Apache, Struts, Java, Jakarta et OGNL.

NB : Au cas où vous vous poseriez la question, OGNL est l’abréviation de : Object-Graph Navigation Language, qui est difficile à expliquer brièvement, et ce même pour des personnes l’utilisant souvent, mais nous y reviendrons dans un instant.

Nous commencerons par un glossaire succinct :

• • • Apache HTTPD est un serveur web open source très populaire et très utilisé. Pour être franc, la notion d’utilisation étendue dépend bien sûr à qui vous demandez et comment vous mesurez, mais il est juste de considérer qu’entre un tiers et la moitié des sites web dans le monde l’utilise.
    • Java, à ne pas confondre avec JavaScript, est un langage de programmation populaire, mieux connu pour le développement d’applications pour entreprises, d’applets pour navigateur (bien que rarement utilisées à l’heure actuelle) et des servlets, qui sont des programmes simplifiés qui génèrent des pages web personnalisées en temps réel lorsque les utilisateurs visitent votre site.

• • • Struts est un addon Apache qui vous permet d’utiliser des servlets Java pour gérer et diffuser le contenu de votre site. Notez que Struts est une technologie côté serveur : il ne concerne pas ce qui fonctionne dans les navigateurs de vos utilisateurs, mais plutot ce qui fonctionne sur votre serveur pour générer les pages web qu’Apache fournit.
    • Jakarta est le nom générique d’un certain nombre de projets de programmation basés sur Java, et qui ont été exécutés pour la communauté par Apache.
    • OGNL est une bête curieuse qui est destinée à vous permettre de spécifier comment le contenu de vos pages web peut provenir de diverses bases de données stockées en coulisses. Mais OGNL est aussi un langage de programmation à part entière, car il peut être utilisé pour définir Java et d’autres commandes qui seront utilisées dans le processus.

La semaine dernière, les discussions autour de tous ces noms, concernaient une vulnérabilité de sécurité qui s’appelle modestement CVE-2017-5638, ou encore “un possible Remote Code Execution lors de l’uploading d’un fichier basé sur Jakarta Multipart parser”.

Autrement dit, les serveurs web utilisant le logiciel Apache Struts 2 intègrent un composant pour gérer les uploads sur le web, ce qui est généralement le cas lorsqu’un utilisateur remplit un formulaire sur internet au niveau de votre site et clique sur [Soumettre] :

Les uploads de formulaires web sont généralement acheminés à l’aide d’une requête HTTP appelée POST.

NB : Comme son nom l’indique, un POST est essentiellement le contraire d’une requête GET, qui définit la façon dont vous téléchargez des pages web, des fichiers et d’autres contenus.

Par exemple, une page web contenant un formulaire comme celui-ci …

… produira une réponse multipart/form-data dans laquelle chaque champ de saisie dans le formulaire sera packagé et uploadé dans une section dédiée, de la même façon que les emails multipartites (par exemple les messages avec des pièces jointes) sont formatés :

La théorie nous dit que l’envoie des données soumises, et le codage des champs séparément avant de les soumettre, est moins sujet à erreur que le packaging global dans une masse binaire tout-en-un et l’uploading de celle-ci ensuite.

La partie du logiciel côté serveur Apache Struts 2 qui traite les requêtes web de ce type est désignée par Jakarta based file upload Multipart parser, et son travail, très simplifié, consiste à vérifier l’en-tête Content-Type de multipart/form-data, puis de tester les données envoyées (POSTed) au niveau de ses multiples parties.

Si le Content-Type est incorrect, l’analyseur de Jakarta est censé répondre avec un message d’erreur qui explique ce qui est erroné, ce qui signifie prendre les données Content-Type non valides et les traiter de manière à extraire des informations qui seront utiles pour résoudre le problème.

Contenu à distance non fiable

Vous pouvez probablement deviner où cela nous amène : un bug dans le traitement de contenu distant erroné et non fiable, conduisant à une vulnérabilité exploitable.

Il s’avère que si l’en-tête Content-Type est un fragment de code OGNL, l’analyseur Jakarta ne le traite pas comme du texte mais comme un “programme” OGNL et le code OGNL peut contenir des composants qui spécifient des commandes qui doivent être exécutées sur le serveur lui-même, lorsque ces données sont traitées.

En d’autres termes, vous pouvez intégrer des commandes de serveur dans un en-tête POST de Apache Struts 2, déclenchant ainsi délibérément une erreur, et le serveur exécutera vos commandes, ironiquement, tout en essayant de traiter avec efficacité l’erreur.

Ce type d’exploit est bien connu sous le nom RCE, ou Exécution de code à distance (Remote Code Execution), et il signifie exactement ce qu’il dit et est toujours synonyme d’ennuis, dans ce cas, avec un E majuscule.

Sans ouvrir de session, sans récupérer la page de formulaire web d’origine et sans même avoir des données de formulaire à uploader, un cybercriminel peut être en mesure de déclencher ce bug simplement en visitant la page web répertoriée dans le champ “action" de n’importe quels de vos formulaires web.

Par exemple, les clients web en ligne de commande bien connus WGET et cURL peuvent générer des requêtes POST avec les en-têtes de votre choix comme ceci :

L’en-tête Content-Type mal-formée dont vous avez besoin n’est pas facile à trouver par vous-même, mais malheureusement, vous n’en avez pas besoin, car des exemples opérationnels écrits dans ce que vous pourriez appeler un code source OGNL “pseudo-Java” ont déjà été mis à disposition de nombreux sites web :

Quoi faire ?

Mettez à jour le plus tôt et le plus souvent possible !

Si vous utilisez Apache Struts 2 quelque part dans votre réseau, et que vous n’avez toujours pas installé le dernier patch, vous devriez vraiment le faire maintenant, car cette vulnérabilité est facile à exploiter par quiconque voudrait juste essayer.

Malheureusement, l’expérience montre qu’il existe souvent des pirates ambitieux qui veulent leurs “15 minutes de gloire”, même s’ils n’ont pas d’objectif criminel particulier et même s’ils ne le feraient certainement pas contre des sites officiels.

La CRA (Canada Revenue Agency), par exemple, en a fait la difficile expérience en 2014, lorsqu’un étudiant de 19 ans a été accusé d’avoir utilisé la vulnérabilité Heartbleed contre le site web de l’Agence. Il aurait extrait 90 numéros de sécurité sociale sur une période de six heures, juste pour prouver qu’il en était capable.

Cette fois-ci, la CRA a agi rapidement, en rendant leurs systèmes indisponibles pour appliquer le patch vital le week-end précédent, même s’il s’agissait de la période des impôts au Canada.

Si la CRA peut trouver un moyen de gérer une interruption imprévue de ce genre, vous pouvez aussi !

Billet inspiré de How a serious Apache vulnerability struts its stuff, par Paul Ducklin, Sophos NakedSecurity.