Laboratório Pentest "Laboratório Pentestit Test 12" - passagem completa

A cada ano, o Pentestit lança um novo laboratório de testes de penetração, o Laboratório de Testes, e este artigo abordará o 12º laboratório, chamado “z 9r347 39u411z3r” ou, se decodificado, “O grande equalizador”.

Conexão ao laboratório

A conexão ao laboratório é feita através de uma conexão VPN (desde que eu estava passando no laboratório em uma máquina executando Linux, todas as etapas serão descritas para esta plataforma). Para entrar na rede privada, você deve executar as seguintes etapas:

1. Registre-se aqui .
2. Salve os arquivos de configuração daqui .
3. Vá para as configurações de rede e selecione "adicionar VPN".
4. Importar do arquivo (especifique o arquivo baixado com configurações).
5. Especifique o login e a senha da conexão (fornecida na guia "como conectar").
6. Nós nos conectamos à VPN e fazemos ping no gateway 192.168.101.1. Se o ping passar, você se conectou com sucesso ao laboratório.

Pesquisa alvo

Temos acesso à rede 192.168.101.X com uma máscara de 255.255.255.0. Primeiro de tudo, você precisa encontrar "hosts ativos" na rede. Isso pode ser feito facilmente com o utilitário nmap:

nmap -sn 192.168.101.0/24 

Então, encontramos três hosts, um dos quais já conhecemos (gateway):

1. 192.168.101.1
2. 192.168.101.12
3. 192.168.101.13

A segunda etapa é varrer os hosts descobertos em busca de portas abertas e fechadas.

 nmap -sV -Pn 192.168.101.12-13 -p- 

A partir dos relatórios, fica claro que 192.168.101.13 não está disponível; portanto, começamos a partir de 192.168.101.12. O servidor da web está girando na porta 80. Mas quando você tenta acessá-lo, ocorre um redirecionamento para o site.test.lab , que é desconhecido para nós (o DNS não está configurado para esse redirecionamento). A verificação é realizada usando um navegador e um utilitário de curvatura.

 curl http://192.168.101.12:80/ curl http://site.test.lab/ 

Faça uma entrada no arquivo / etc / hosts para site.test.lab. Agora, vamos com calma ao site.



O primeiro passo é coletar informações sobre o site. O mais importante é o mecanismo do site (CMS - sistema de gerenciamento de conteúdo). Para fazer isso, use o utilitário peruca.

 wig -u http://site.test.lab/ 

Para análise, obtemos um relatório - o Wordpress é usado. Vamos analisar a saída da peruca:

1. Entradas de IP e título.
2. Nome, versão e tipo de software.
3. Páginas importantes.
4. Utilitários que você pode usar.
5. Possíveis vulnerabilidades com links para o CVE.

Para verificar o CMS WordPress e, mais importante, os plug-ins instalados (eles são mais vulneráveis), o utilitário wpscan é mais adequado.

 wpscan --url http://site.test.lab/ --enumerate p --random-user-agent 

Obtemos as informações necessárias: a versão do WordPress, vulnerabilidades e plugins instalados. O fato é que essas vulnerabilidades não nos fornecerão o acesso desejado. É muito útil determinar quais plugins são usados. Nesse caso, é "wp-survey-and-poll". É importante entender que os scanners devem ser usados ​​apenas para obter informações sobre o software. Como não há um banco de dados único de vulnerabilidades, o scanner pode não mostrar todas as explorações existentes. Como resultado da digitalização, temos:

1. Versão WP: 4.9.8.
2. Vinte e dezessete: sim, v. 1.9
3. Plugins: wp-survey-and-poll v. 1.5.7

O utilitário searchsploit foi projetado para pesquisar convenientemente o maior banco de dados exploit-db exploit, que é baixado e salvo no seu PC. Para a versão 4.9.8, nenhuma vulnerabilidade foi encontrada no banco de dados. Se verificarmos o plugin, encontraremos duas vulnerabilidades.

 searchsploit "WordPress Survey Poll" 

Saiba mais sobre essas vulnerabilidades. Esta é uma injeção SQL de ligação regular em um cookie. Precisamos responder à pergunta e substituir nossa solicitação em cookies. A técnica é muito simples: (qualquer expressão) OR 1 = 2 retornará falso, então o DBMS, em vez de resolver nossa resposta, exibirá a segunda parte do UNION da solicitação combinada. Essas são todas as colunas, uma das quais (nº 10) será exibida na página. Mas a operação desse segmento de rede era impossível, como ficou conhecido mais tarde, porque bloqueia o WAF.

Token MAIL

Após uma falha no site, você precisa encontrar outros pontos de entrada. No site, você pode encontrar o login info@test.lab, que usaremos para selecionar as informações de autenticação. Vamos para outras portas. A web está girando no 8080, mas o token CSRF é usado. Com 25 smtp, a senha para a qual não funcionou. Restamos apenas a porta 143 - este é o serviço IMAP. Para brutus, usei a ferramenta hydra. Como se viu, a senha era muito simples.

 hydra -l info@test.lab -P '/root/rockyou.txt' imap://192.168.101.12 

Como encontramos o nome de usuário e a senha do e-mail, efetuamos login no 192.168.101.12:8080. Agora você precisa analisar corretamente todo o e-mail. Além disso, é necessário coletar todas as informações, pois podem ser úteis mais tarde. Aqui está o que eu encontrei:

1. Caixa de entrada: configurações de VPN.
2. Saída: Token para configurar MAIL.
3. Nome de usuário sviridov@test.lab

VPN sobre VPN

Precisamos expandir profundamente a rede da empresa. Temos uma configuração de VPN, mas não podemos desconectar da principal. Essa técnica é chamada VPN sobre VPN - quando conectamos uma VPN dentro de uma VPN dentro de uma VPN, etc. Para uma VPN, é necessário um nome de usuário e senha. Conhecemos apenas 2 usuários (info e sviridov) e a senha de um deles. Estamos tentando conectar usando um nome de usuário e senha conhecidos. Se não der certo, seremos brutais. Para conectar, execute as seguintes etapas:

1. Crie um arquivo userVPN.txt, em que a primeira linha é o nome de usuário e a segunda é a senha.
2. Adicione o caminho para este arquivo na configuração da VPN na coluna auth-user-pass
3. Você cria um script bash OverVPN.sh com o seguinte conteúdo: openvpn --config configuration_path_to_file_ &
4. Atribua direitos a ele: chmod 770 ./OverVPN.sh
5. Execute: ./OverVPN.sh

Temos sorte, o usuário info@test.lab está logado com sucesso e informamos que uma nova rede 172.16.0.0/16 está disponível.



Primeiro de tudo, você precisa encontrar "hosts ao vivo" na rede, como você fez da última vez:

 nmap -sn 172.16.0.0/16 

Então, encontramos quatro hosts.



Analise cada host. Em 172.16.0.1 nada foi encontrado. Atrevo-me a assumir que este é o nosso conhecido 192.168.101.13 em outra rede. É através dele que estamos conectados a esta rede. Em 172.16.0.10, apenas o servidor Web na porta 80 está disponível. Em 172.16.0.17, vemos todo um "campo de testes" para testes. Em 172.16.1.2 nada. Provavelmente este é outro serviço VPN.

Token DNS

Como o próximo na lista de tokens é DNS, começaremos a analisar o serviço DNS na porta 172.16.0.17 A principal vulnerabilidade é obter registros DNS - transferência da zona DNS (a chamada solicitação AXFR). Nós o executamos usando os utilitários nslookup e dig.

O primeiro a conhecer as zonas e os nomes dos servidores responsáveis ​​por essas zonas.

 nslookup > set type=ANY > set port=53 > SERVER 172.16.0.17 > test.lab 

O segundo fará a transferência.

 dig @172.16.0.17 ns1.test.lab axfr 

Este servidor DNS não está respondendo. Mas ele sabe sobre o resto do DNS na rede. O utilitário dnsrecon permite que você faça absolutamente qualquer operação com o dns. Obtenha o restante do DNS na rede e adicione-o ao arquivo / etc / hosts.

 dnsrecon -d test.lab -n 172.16.0.17 -t brt 

Ao verificar o host 172.16.0.17, obtemos o token.

 dnsrecon -d test.lab -n 172.16.0.17 -a 

Token de suporte técnico

Próxima tarefa na lista: suporte técnico. Encontramos e adicionamos um domínio semelhante. Além disso, este é o único serviço executado em 172.16.0.10. Existe uma forma simples de autorização, nenhum CMS é usado. Como sempre, tentamos fazer login como usuários conhecidos. E discretamente entramos no usuário info@test.lab. Vemos o formulário de solicitação; após a solicitação do token, não recebemos nada. Aparentemente, não temos, mas, como acontece em tais tarefas, está disponível para outro usuário. Após uma pequena revisão da página, encontramos a capacidade de alterar a senha.



Depois de digitalizar os formulários de busca e alteração de senha com vários scanners, não encontramos nada. Veja o código-fonte da página de alteração de senha. Se você atualizá-lo algumas vezes, notará que o campo oculto com o token CSRF não muda. Ou seja, não é um token CSRF. Isso é base64, decodifique e obtenha o número.





Como nenhum cookie é enviado, é óbvio que esse é o ID do usuário. O plano é o seguinte: alteramos senhas para todos os IDs e, para aqueles que obtiveram um resultado bem-sucedido, selecionamos um login usando nossa senha.


Apenas dois ID responderam com êxito à solicitação de alteração de senha. Agora resta escolher um nome de usuário. Raiz e administrador não deram resultado, mas sviridov@test.lab nos fornece um token.

Token de anúncio

Antes de você seguir o caminho da VPN, vejamos os serviços em 172.16.0.17. Digitar o teste do grupo de trabalho SAMBA (da análise do nmap). Primeiro de tudo, você precisa descobrir usuários no domínio:

 enum4linux -U 172.16.0.17 

O Enum4linux define domínios, usuários em domínios, seu livrar e outras informações. Entre os usuários, retiramos o token. A propósito, é melhor manter todos os logins.

Token de USUÁRIOS

No helpdesk, as tarefas descobriram que o usuário sviridov teve acesso à rede, ou seja, a configuração da VPN. Também pegamos a senha no helpdesk. Tentamos conectar a 192.168.101.13 usando a configuração existente, mas substituímos o nome de usuário e a senha do usuário em userVPN.txt.



Nada acontece. Então tentamos nos conectar ao 192.168.101.12. Estamos conectados e as redes 192.168.0.0/24 e 172.16.0.0/16 estão disponíveis para nós.



Agora, novamente, é necessário realizar o reconhecimento da rede. Temos duas redes 172.16.0.0 com uma máscara 255.255.0.0, onde encontramos oito hosts e uma rede 192.168.0.0/24, que não é varrida. Aparentemente, um firewall está ativado em todos os hosts. Digitalizamos com a opção -Pn, e no relatório obtemos absolutamente todos os hosts e portas são filtrados em todos os lugares. Percebemos que existem hosts na rede com a porta 22 aberta:

• 192.168.0.10
• 192.168.0.15
• 192.168.0.30
• 192.168.0.100
• 192.168.0.205
• 192.168.0.240

Como a única coisa que existe na rede 192.168.0.0/24 são seis hosts com portas ssh abertas, percorreremos todos eles para poder conectar-se a um dos usuários que conhecemos.



Como existem seis hosts, automatizamos a pesquisa usando o utilitário de estrutura metasploit. Usaremos o módulo auxiliar / scanner / ssh / ssh_login.

 > use auxiliary/scanner/ssh/ssh_login > set RHOSTS 192.168.0.10 192.168.0.15 192.168.0.30 192.168.0.100 192.168.0.205 192.168.0.240 > set USERPASS_FILE '/root/CTF/PT12/userspass.txt' > exploit 

Vamos a todos os hosts sob os dois usuários e procuramos informações. Após uma longa caminhada em 192.168.0.100, encontramos um erro nos direitos de acesso. O diretório inicial do usuário está disponível para visualização para absolutamente todos. Encontramos um sinal nele. Mas seu autor é sviridov. Faça logon em Svridov e entregue o token.



Nada mais interessante foi encontrado. A rota IP não tinha outras redes. No cron havia apenas um limpador. Em / tmp / muito incompreensível:

• 1.sh - não deu nada.
• Client.jar não inicia porque não há JVM. É estranho por que ele é necessário.
• Renomeie para DAGESTAN_SILA nmap.
• Duas peças para aumentar os privilégios.
• E muito lixo diferente.

Token de VPN

Na rede 172.16.0.0/16, a porta 80 está aberta em todos os hosts. Vale a pena navegar nos sites em todos os hosts:

• Em 172.16.1.10 , encontramos o token !!! Abordou a tarefa VPN. Aparentemente, a tarefa era adivinhar se conectar ao 192.168.101.12 como usuário sviridov.
• Em 172.16.1.12, o formulário de autorização.
• Na autenticação de base 172.16.1.15 .

Foi muito fácil, seguir em frente.

Token SIEM

Vamos para 172.16.1.12 . Lemos o que é Prewikka. Prewikka é a principal interface do usuário do sistema Prelude SIEM, implementada pela Web. O acesso à interface é feito através de um navegador da web. A autenticação é feita usando contas locais ou através de um diretório LDAP. Não foi possível encontrar explorações. Login e senha do Google por padrão. Falha, porque são indicados durante a instalação do sistema. Mas você pode tentar um exemplo da documentação: prelude: preludepasswd - não se encaixava. Vamos tentar os usuários que já conhecemos (e sabemos apenas as senhas de dois). Sviridov apareceu. É importante observar que apenas o administrador tem acesso ao sistema SIEM. Pode-se argumentar que definimos o administrador.

Observamos que os dados deste mês estão sendo exibidos. Traduzimos o diário um mês antes e vemos os dados registrados.



Apenas observe os domínios que adicionamos ao / etc / hosts:

• (admin.test.lab) 172.16.1.25
• (vpn-admin.test.lab) 172.16.1.10
• (repository.test.lab) 172.16.1.15
• (site.test.lab) 172.16.0.14

Entre os logs repository.test.lab, encontramos um token.



Como encontramos e adicionamos uma nova entrada para site.test.lab em / etc / hosts, vamos voltar e explorar a vulnerabilidade no site.

Token do site

Voltar ao site.test.lab, que agora corresponde a 172.16.0.14. Vamos ver se o WAF funciona para isso. Enviamos nossa carga do exemplo e obtemos a versão do DBMS. Em seguida, descobrimos qual banco de dados é usado. Se ele corresponder aos dados padrão, você poderá obter imediatamente o nome e o hash do usuário, pois, por padrão, a tabela com os usuários é: wp_users. O nome do banco de dados (wordpress) é o mesmo, portanto, descobrimos o nome de usuário e a senha. Infelizmente, isso não dá nada. A rolagem de senha também falhou.

Em seguida (não descreverei a técnica, estes são os princípios básicos), seguimos o caminho usual neste caso - obtemos os nomes de todas as tabelas. Entre eles, há a tabela necessária - ficha. Descubra quais são as colunas e os tipos de dados. Então entendemos que precisamos obter o valor do nome.

Token de repositório

No SIEM, encontramos os logs para repository.test.lab. Vamos tentar fazer login usando os dados encontrados. Você pode voltar novamente e procurar logs para absolutamente todos os serviços existentes.



Nós passamos, tentamos fazer login. Com sucesso !!! Vemos alguns arquivos e um token.

Token reverso

Além do token, havia mais dois arquivos no repositório. Um deles para especificar Reverse é um arquivo bin. Vamos realizar uma análise básica do arquivo executável:

• Strings - um utilitário que exibe todas as linhas de um arquivo. Nesse caso, vemos muitas linhas base64. Decodificação não dá nada.
• Ltrace é um utilitário que intercepta chamadas de função de biblioteca. Nesse caso, nenhuma função de biblioteca foi chamada.
• Strace é um utilitário que intercepta todos os syskols (chamadas do sistema). Não recebemos dados úteis.

Não recebemos dados úteis. Para tarefas desse tipo, prefiro usar o Angr para soluções automáticas (escreverei mais sobre a biblioteca do angr nos artigos subseqüentes). Eu dou o código em python.

 import angr import claripy proj = angr.Project('./bin') simgr = proj.factory.simgr() simgr.explore(find=lambda s: b"ACCESS GRANTED!" in s.posix.dumps(1)) s = simgr.found[0] print(s.posix.dumps(0)) 

Recebemos o token como resposta.

Token de banco de dados

Agora vamos descobrir o arquivo jar. Você precisa entender o que ele está fazendo. Java é uma linguagem descompilada, então obtemos o código fonte. Existem muitos programas que permitem fazer isso (o melhor: JAD, JD-gui, Javasnoop, Intellij Idea Decompiler, JD-plugin Eclipse). Eu uso o JD-gui para descompilação e o Intellij Idea para projetos de construção. Obtenha o projeto de origem seguindo estas etapas:

1. Execute o jd-gui. No Linux, há um problema de inicialização que pode ser resolvido assim - crie um arquivo bash com o seguinte conteúdo:
   java --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED -jar /usr/share/jd-gui/jd-gui.jar
2. Faça o download do client.jar e salve.
3. Abra Intellij Idea → Importar Projeto. Especifique o caminho para a pasta do arquivo.
4. Crie um projeto a partir de fontes existentes.

Vamos analisar o código do aplicativo para imaginar para que serve. A primeira etapa é definir os parâmetros de conexão e SSL. A chamada ocorre no endereço 172.16.0.55 na porta 5074. Em seguida, recebemos uma mensagem solicitando que você insira um dos números para selecionar uma solicitação. Dependendo disso, um determinado parâmetro é passado para a função Reqvest. A função Reqvest retorna a solicitação gerada no formato json. Enviamos uma solicitação e obtemos uma resposta.


Há uma dificuldade: o host 172.16.0.55 não está disponível para nós. Mas encontramos um aplicativo semelhante em 192.168.0.240 em Sviridov. Isso significa que o roteamento é configurado de forma que haja acesso ao servidor de aplicativos a partir do computador. Como temos acesso via SSH, podemos encaminhar a porta para nosso local. Para encaminhar a porta, use o utilitário sshuttle.

 sshuttle -r sviridov@192.168.0.240 172.16.0.0/16 

Como resultado, obtemos acesso à rede.



Agora estamos testando o aplicativo no modo de depuração, mas para alterar alguma coisa, você precisa reconstruir o projeto. Ao tentar executar o aplicativo através do F9, obtemos um erro. Para corrigi-lo, você deve:

1. Recorrência clara.
2. Erro no json. Exclua a pasta inteira do projeto.
3. Selecione o projeto no menu de contexto: Open Module Setting ou F4
4. Na guia Dependências, selecione "+" e especifique o arquivo jar. Portanto, a partir do projeto final, carregaremos as bibliotecas já montadas que o decompilador arruinou.

Agora, o aplicativo inicia com sucesso e podemos começar a procurar vulnerabilidades. A string de consulta, como descobrimos, é formada dentro da função Reqvest. Vamos mudar um pouco o código para entender como o sistema responde a qualquer uma de nossas informações. Nós adicionamos as linhas nas quais controlaremos o parâmetro retornado e o exibimos no console. Em seguida, realizaremos quatro consultas possíveis. Como podemos ver, a cadeia JSON é passada. E o sistema, um pouco remanescente do HelpDesk, retornará solicitações de usuário para nós. A propósito, aparentemente os bancos de dados estão girando no servidor, pois o aplicativo nos devolve o usuário sob o qual a solicitação foi feita.


Para tornar mais conveniente alterar e ajustar os parâmetros, fazemos com que a função retorne constantemente a mesma string.



Como o banco de dados é usado no servidor, a primeira coisa a verificar é a presença de injeção de SQL:

1. Enviaremos a carga mais inofensiva - a função de atraso. Uma solicitação com um atraso de 10 segundos leva muito mais tempo que um atraso de 0 segundos. Há uma injeção de sono.
2. Verifique se é vulnerável ao CEGO. Como a conclusão da condição correta não foi alterada, o aplicativo é vulnerável à injeção de BLIND.
3. Primeiro, você precisa descobrir o número de colunas na saída. Para fazer isso, estamos construindo uma solicitação conjunta da UNION. Classificamos o número de colunas até que não haja saída. Portanto, a saída aparece com 5 colunas.
4. Agora você precisa descobrir as informações de serviço: DBMS (@@ version) e nome do banco de dados (database ()). O nome do banco de dados é saber com o que entrar em contato e o DBMS é o ambiente com o qual operar. Então descobrimos que o MySQL é usado e o nome do banco de dados é "reqvest".
5. Agora, através do ambiente information_schema, descobrimos quais tabelas existem. Estamos interessados ​​em token.
6. Descobrimos quais colunas estão na tabela de tokens.
7. Exiba o conteúdo da tabela de tokens.

Essa tarefa acabou sendo tão interessante !!!

Token de API do usuário

Depois de descobrir seis hosts ocultos na rede 192.168.0.0/24, pensei no fato de que eles poderiam estar na 172.16.0.0/16. Execute a mesma varredura nas portas principais. Como a saída é muito grande, procuraremos a palavra-chave “aberto”. Encontramos mais dois hosts com a web aberta.



Bem, desde que eles tentaram esconder 172.16.1.20:8000 de nós, vamos a ele e vemos um aplicativo AJAX. Bem, como sempre, examinamos os diretórios. Tudo o que o dirb encontrou já está disponível para nós.



A página de contato é inútil para nós. A página de login requer autorização. E o suporte contém algum tipo de arquivo de código de barras. Parece ser stego, então vamos deixar por enquanto. A propósito, se você acessar esta página várias vezes, imagens diferentes serão exibidas. Vamos salvar tudo, existem apenas 4. Eles são decodificados como "support_team".

Vejamos quais diretórios existem. Observamos cinco diretórios: contac, get_user_list, recover_password, login, support. Portanto, se você olhar para o diretório get_user_list, eles nos dirão que existem dois parâmetros - a string de login e a string da senha. Olhamos, selecionamos usuários e senhas - isso não dá nada. Nos códigos de barras, o support_team foi tentado como login. E, novamente, a brutalidade não dá nada em lugar algum.



Ao inserir acidentalmente aspas, encontramos uma reação estranha.
login=support_team“&password=“ and “1=1“

E nos é mostrada uma lista de usuários.



Ao tentar fazer login como qualquer usuário, obtemos o mesmo erro. Encontre o par correto de usuário: login. Escreveremos um script que passará por todos os pares e selecionará aqueles que passarem no teste.


.



. , «+» , «&» . URLencode .

Image token

, . . file, binwalk hex- . , stegsolve. B 2- 1- rgb. LSB .



, stegsolve, . . PIL python . , – 0, 255 249. . 0 255 – , «0», 249 – «1». , . , , .

My token

. /etc/hosts my.test.lab, . . info, sviridov medvedev. info. . . , . wapiti . SQL-inj XSS . SSTI: {{7*7}}. , 49.



, . , (, , . .) . .



, Jinja2 Twig. : {{7*“7“}}. . Jinja2, {{self}}.





: {{config}}. , .

API token

, jinja2 . flask-session-cookie-manager . . info. .



, . . , . , . 2060 . token sviridov, , admin. - , .



RCE ( ) SSTI. , . . flask-cookie.

 {{"".__class__.__mro__[1].__subclasses__()}} 

, , python . Popen, .





/var/www/api/token. ( popen 94). B open, ( , WAF ) read().

 {{[].__class__.__base__.__subclasses__(+)[94].__init__.__globals__['__builtins__']['open']('/var/www'+'/api/token','rb').read(+)}} 

, , python . . file. *tar.gz . .

Admin token

. ssh. SIEM , .



, ( 600). , , .



, . , SHA , SIEM.



, ( ), , . , .



metasploit framework – scanner/ssh/ssh_login_pubkey. , sidorov.



token.

 find | grep token 

.

Conclusão

- «Pentestit Test lab 12».



, CTF . - - , - , . 13-…

Estamos em um canal de telegrama: um canal no telegrama .