Il a été récemment découvert dans PHP 7, la dernière version du langage, une faille de sécurité dangereuse et facile à exploiter, car elle permettrait même aux attaquants non techniques de prendre le contrôle des serveurs à distance. La vulnérabilité, qui a été corrigée la semaine dernière, est une exécution de code à distance (RCE) en PHP 7 permettant d’attaquer un serveur Web vulnérable en envoyant des requêtes spécialement conçues et en ajoutant "?a=" dans l'URL. Seuls les serveurs Nginx couplés à l’extension PHP-FPM sont vulnérables.Dans le registre des bogues de PHP, cette faille est désignée par CVE-2019-11043 et permet aux attaquants d'exécuter des commandes sur les serveurs simplement en accédant à une URL spécialement conçue. Le code d'exploitation de preuve de concept (PoC) public a été publié sur GitHub dans la semaine passée. Le hacker teste d’abord le serveur cible et s’il reçoit une réponse favorable, il peut maintenant lancer son attaque.
La vulnérabilité a été découverte par Andrew Danau, chercheur en sécurité chez Wallarm, une société de cybersécurité sise à San Francisco. Il est tombé sur un comportement inhabituel d'un script PHP lors de la résolution d'une tâche du FCT. Quand Danau a envoyé les octets %0a (newline) dans l'URL, la réponse du serveur était particulière. Il renvoie plus de données qu'il ne devrait y en avoir. De plus, Wallarm a précisé que la quantité de données supplémentaires renvoyées était liée au nombre d'octets après %0a à l'intérieur de l'URL.
« Le plus souvent, ce genre de réaction est lié aux attaques de corruption de la mémoire et nous nous attendions à ce qu'il y ait une attaque contre le type de divulgation de l'information. La divulgation d'informations est déjà assez mauvaise, car elle peut entraîner des fuites de données sensibles ou financières. Pire encore, de temps en temps, bien que très rarement, un tel comportement puisse indiquer une vulnérabilité d'exécution du code à distance », a décrit Wallarm dans un billet de blogue qui explique comment résoudre le problème.
Le script PoC inclus dans le référentiel GitHub peut interroger un serveur Web cible pour vérifier s'il est vulnérable ou non en envoyant des requêtes spécialement conçues. Une fois qu'une cible vulnérable a été identifiée, les attaquants peuvent envoyer des requêtes spécialement conçues en ajoutant « ?a= » dans l'URL à un serveur Web vulnérable. Dans certaines configurations Nginx + PHP-FPM, le bogue peut être déclenché de l'extérieur. Cela signifie qu'un utilisateur Web peut obtenir l'exécution de code si vous avez une configuration vulnérable.
Autrement dit, seuls les serveurs Nginx avec l’extension PHP-FPM sont vulnérables à cette faille. L’exploit ne fonctionne que sous la version 7 de PHP. En effet, le bogue est lié à un débordement de tampon (buffer underflow) dans PHP-FPM. Le buffer underflow en PHP-FPM est aussi présent dans PHP 5, mais l'attaquant peut exploiter une optimisation utilisée pour stocker les variables FastCGI, _fcgi_data_seg. Cette optimisation n'est présente que dans PHP 7.
Ainsi, cette faille n'existe que sur PHP 7. Néanmoins, il peut y avoir une autre technique d'exploitation qui fonctionne pour PHP 5. Pour l’heure, chaque administrateur se doit donc de mettre à jour PHP 7 pour éviter d’être la cible d’une attaque vers les versions les plus récentes, 7.3.11 et 7.2.24, publiées le même jour et incluant les correctifs pour CVE-2019-11043. Mais, il y a aussi des propriétaires de sites Web qui ne peuvent pas mettre à jour PHP ou qui ne peuvent pas passer de PHP-FPM à un autre processeur CGI en raison de contraintes techniques.
Si c’est le cas, le billet de Wallarm montre comment les webmasters peuvent utiliser l'utilitaire de pare-feu standard « mod_security » pour bloquer les octets %0a (newline) dans les URL des sites, et empêcher toute attaque entrante. Une règle « mod_security » pourrait ressembler à ceci : « SecRule REQUEST_URI “@rx %0(a|d)” “id:1,phase:1,t:lowercase,deny” ». Cependant, si vous avez une application de par-feu hérité et appliquez cette règle, le niveau de faux positifs sera élevé. Cela est assez commun pour les par-feux de première génération basés sur une expression RegEx.
D’après Wallarm, sans correction, ce problème peut devenir un point d'entrée dangereux dans vos applications Web, dont la plupart s'exécutent sur une infrastructure PHP. En raison de la disponibilité du code public PoC et de la simplicité d'exploitation de ce bogue, il est conseillé aux propriétaires de sites Web de vérifier les paramètres du serveur et de mettre à jour PHP dès que possible s'ils utilisent la configuration vulnérable.
Sources : PHP, Wallarm, PoC (GitHub)
Et vous ?
Qu'en pensez-vous ?Voir aussi
Quel langage de programmation comporte le plus de vulnérabilités en matière de sécurité ? Une étude de WhiteSource Une vulnérabilité inhérente à PHP met à risque des millions de sites web WordPress et l'équipe du CMS ne l'a toujours pas corrigée depuis 2017 Une vulnérabilité 0-day dans un plugin jQuery permettrait de télécharger et d'exécuter du code malveillant sur des serveurs PHP, et ce depuis 2010 
Envoyé par smobydick
.
.