Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-03 01:50:21 +00:00

Translator workflow c928d8e52e Translated to Portuguese

2023-06-06 18:56:34 +00:00

16 KiB

Raw Blame History

☁️ 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? Confira 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 suas técnicas de hacking enviando PRs para o repositório hacktricks e hacktricks-cloud repo.

Este conteúdo foi retirado de https://www.errno.fr/artifactory/Attacking_Artifactory

Conceitos básicos do Artifactory

Usuários e senhas padrão

As contas padrão do Artifactory são:

Conta	Senha padrão	Notas
admin	password	conta comum de administração
access-admin	password (<6.8.0) ou um valor aleatório (>= 6.8.0)	usada apenas para operações de administração local
anonymous	’’	usuário anônimo para recuperar pacotes remotamente, não habilitado por padrão

Por padrão, nenhuma política de bloqueio de senha está em vigor, o que torna o Artifactory um alvo principal para ataques de preenchimento de credenciais e pulverização de senhas.

Autorizações

Idealmente, isso é o que você deve ver ao se conectar ao Artifactory:

Por outro lado, se você for recebido com algo mais parecido com isso:

Significa que o "Acesso anônimo" foi habilitado no painel de administração, que é uma configuração comum usada para permitir que aplicativos recuperem artefatos sem problemas, mas permite que você, o atacante, veja mais do que é preferível.

Verificando os direitos da conta

Às vezes, devido a uma má configuração, o acesso anônimo é permitido para implantar arquivos em alguns repositórios!

Para verificar em quais repositórios o usuário anônimo pode implantar, use a seguinte solicitação:

curl http://localhost:8081/artifactory/ui/repodata?deploy=true
{"repoList":["artifactory-build-info","example-repo-local"]}

Se houver entradas repoKey na solicitação, qualquer pessoa pode implantar nelas, o que é realmente muito ruim. Você definitivamente deve estar autenticado para implantar quaisquer arquivos.

Isso pode ser generalizado para outras contas assim que você obtiver uma senha ou token para elas.

Listando usuários

Por algum motivo, listar usuários é um direito reservado apenas para administradores. Eu encontrei uma maneira alternativa de listar usuários (aqueles que estão implantando ativamente pelo menos) que depende do valor "Implantado por" dos artefatos:

Este script simplesmente tenta encontrar recursivamente todos os usuários que implantaram artefatos. Observe que pode levar um tempo para ser concluído se houver muitos repositórios (> 1000).

./artifactory_list_users.py http://127.0.0.1:8081/artifactory
There are 23 repositories to process
Found user admin
Found user test
Found user user
Found user test_deploy

Permissões

Aqui estão as permissões básicas e sua utilidade:

Gerenciar: ?
Excluir/Sobrescrever: interessante para pentest
Implantar/Cache: interessante para pentest
Anotar: necessário para CVE-2020-7931
Ler: geralmente uma permissão padrão

Vulnerabilidades conhecidas

Aqui está uma lista selecionada de vulnerabilidades públicas de alto impacto:

CVE-2016-10036: Upload de arquivo arbitrário e RCE (<4.8.6)

Detalhes aqui.

Este é um pouco antigo e é improvável que você encontre uma versão tão desatualizada do Artifactory. No entanto, é bastante eficaz, pois é uma simples travessia de diretório que permite a execução de código arbitrário no nível do Tomcat.

CVE-2019-9733: Bypass de autenticação (<6.8.6)

Advisory original aqui.

Em versões mais antigas do Artifactory (até 6.7.3), a conta access-admin usava uma senha padrão password.

Esta conta local normalmente é proibida de acessar a interface do usuário ou a API, mas até a versão 6.8.6 do Artifactory, era possível enganá-lo para acreditar que a solicitação emanava localmente se o cabeçalho HTTP X-Forwarded-For fosse definido como 127.0.0.1.

CVE-2020-7931: Injeção de modelo do lado do servidor (Artifactory Pro)

Advisory original aqui.

Aqui está uma ferramenta que escrevi para automatizar a exploração dessa vulnerabilidade.

Esses são os requisitos para a exploração:

um usuário com direitos de implantação (criar arquivos) e anotação (definir filtrados)
Artifactory Pro

A vulnerabilidade é bastante simples: se um recurso implantado for definido como filtrado, ele será interpretado como um modelo Freemarker, o que dá ao atacante uma janela de ataque SSTI.

Aqui estão as primitivas implementadas:

leituras básicas do sistema de arquivos
gravações limitadas do sistema de arquivos

Isso deve ser suficiente para dar a você a execução remota de código de várias maneiras, da mais fácil/silenciosa à mais difícil/barulhenta:

lendo um segredo no sistema de arquivos que permite que você pivote (/home/user/.bash_history, /home/user/password.txt, /home/user/.ssh/id_rsa …)
adicionando uma chave SSH ao usuário
implantando um arquivo .war para executar um servlet
implantando um script de usuário Groovy do Artifactory

Histórias .war: manobras de renomeação Java renameTo()

Esta é uma pequena história de como bati minha cabeça contra a parede por horas, se não dias, durante um pentest. Encontrei um Artifactory desatualizado que sabia que era vulnerável ao CVE-2020-7931. Implantei o modelo SSTI original do advisory e comecei a percorrer o sistema de arquivos. Parecia que o Artifactory havia sido instalado em um local não padrão, o que não é muito incomum, já que os administradores gostam de manter partições separadas entre binários de aplicativos, dados, logs e configuração (isso é uma coisa boa!). Não havia chaves SSH ou senhas no diretório home do usuário que me fornecessem um pivô fácil, então chegou a hora de ser menos discreto e escrever no sistema de arquivos. O envio da carga útil inicial (uma chave pública) para o diretório de upload do Artifactory correu bem, mas eu simplesmente não conseguia movê-la para o diretório de chaves SSH. Então voltei para minha sandbox de exploração, testei novamente e, eis que funcionou bem. Então, tinha que haver uma configuração diferente que me impedisse de concluir o método renameTo(). Neste ponto, é sempre uma boa ideia verificar a documentação ... que claramente afirma que você não pode renomear arquivos em diferentes sistemas de arquivos, o que faz sentido dependendo da implementação do método, ou seja, se ele funciona em um nível de inode. Arg.

Lembre-se do que eu disse sobre os administradores gostarem de partições? Bem, este é um caso de um administrador que endureceu sua configuração sem saber contra minha exploração! Então, tive que cavar em uma espécie de prisão Java para encontrar outro método que me permitisse gravar um arquivo no disco. E isso não foi nada divertido, já que não estou familiarizado com nada do que está envolvido: modelos FTL, Java, Tomcat/Catalina. Descobri rapidamente que as fugas regulares da prisão Java simplesmente não funcionariam, pois a instância de novas classes era proibida. Depois de horas lendo a documentação das classes Java e Catalina, finalmente encontrei um método write() em um objeto ao qual eu poderia chegar. Mas estava limitado ao caminho base da aplicação da web... Então, pensei em combinar a gravação em outro sistema de arquivos e o renameTo() através deste novo sistema de arquivos acessível para, esperançosamente, poder gravar em qualquer lugar? E funcionou mais ou menos. Consegui gravar fora do diretório de upload temporário ... mas não tão longe dele, pois agora estava preso em outro sistema de arquivos que era o ponto de montagem para todas as coisas do Artifactory: configuração, aplicação e coisas do tipo. Então, ainda sem chave SSH para mim.

Ok, eu poderia gravar na pasta raiz do artifactory, com certeza eu poderia fazer algo aqui? Ei, o Tomcat padrão automaticamente implanta arquivos WAR escritos em seu caminho de aplicação, não é? Então usei o msfvenom para gerar um shell da web JSP embalado em um arquivo WAR e testei na minha sandbox... bem, ele foi implantado corretamente, mas não me deu execução de comando. Parece que o Tomcat padrão não lida com JSPs. Ugh. Ficando cada vez mais frustrado, procurei outra maneira de executar código no Tomcat e encontrei outro método de execução usando servlets. Não consegui encontrar uma carga útil apropriada, então dane-se, estou tudo dentro neste ponto e criei o meu próprio que você pode encontrar aqui. Testei na sandbox, funciona, ok. Coloquei no alvo, implantei e ... nada. Acontece que havia um proxy na frente do artifactory que reescrevia todos os URLs para /artifactory. Então, mesmo que minha porta dos fundos estivesse implantada e em execução, não havia como acessá-la... Se houvesse alguma execução remota de código a ser alcançada neste ponto, teria que ser no contexto do Artifactory, não do Tomcat.

Na manhã seguinte, estou chorando em minha mesa olhando pela última vez a documentação do Artifactory em vãs esperanças de uma epifania. E então as palavras mágicas "scripts Groovy" apareceram. A

cat artifactory.hashes
user:1f70548d73baca61aab8660733c7de81${CAFEBABEEBABEFAC}
john artifactory.hashes --format=dynamic_1
Loaded 1 password hash (dynamic_1 [md5($p.$s) (joomla) 256/256 AVX2 8x3])
password         (user)

O outro tipo de senha bcrypt não requer nada especial, é apenas um hash bcrypt padrão:

cat artifactory_bcrypt.hashes
admin:$2a$08$EbfHSAjPLoJnG/yHS/zmi.VizaWSipUuKAo7laKt6b8LePPTfDVeW
john artifactory_bcrypt.hashes
Loaded 1 password hash (bcrypt [Blowfish 32/64 X2])
password          (admin)

Segredos remotos

O Artifactory pode precisar armazenar segredos para se identificar em serviços remotos. Esses segredos não são hash, é claro, eles são armazenados criptografados no disco, com a chave ao lado deles. Existem dois tipos de segredos mencionados na documentação oficial.

Formato antigo (<5.9): DES-EDE

TODO. Abra um problema se você tiver dados criptografados de amostra.

Novo formato (>=5.9): criptografia AES128-CBC, armazenada como base58

Os segredos externos (como senhas de servidores remotos) são encontrados nos descritores de configuração, por exemplo, /var/opt/jfrog/artifactory/etc/artifactory.config.latest.xml e parecem:

<keyStorePassword>AM.25rLQ.AES128.vJMeKkaK6RBRQCUKJWvYEHUw6zs394X1CrRugvJsQGPanhMgQ5be8yjWDhJYC4BEz2KRE</keyStorePassword>

Onde:

AM sempre denota um segredo criptografado do Artifactory
25rLQ é o identificador do segredo que deve corresponder ao identificador da chave
AES128 obviamente é o algoritmo usado
vJMeK...KRE é a codificação base58 de IV_SIZE|IV|secret|CRC

Mais segredos podem ser encontrados (tokens, backups de configuração...) usando a seguinte expressão regular:

grep -r 'AM\..*\.AES128\.' /var/opt/jfrog/artifactory/

A chave é armazenada em /var/opt/jfrog/artifactory/etc/security/artifactory.key e se parece com:

JS.25rLQ.AES128.7fcJFd3Y2ib3wi4EHnhbvZuxu