Worker
Difficulty: Medium | OS: Windows | SubVersion(SVN) - Azure DevOps Server
Last updated
Difficulty: Medium | OS: Windows | SubVersion(SVN) - Azure DevOps Server
Last updated
Em breve ...
Apenas página default do IIS. O que caracteriza que estamos em um Windows Server
Através de uma pesquisa passiva pelas tecnologias com Wappalyzer podemos confirmar isso também.
Porém, no nosso escaneamento por versões e serviços, encontramos uma página de autenticação com o domínio devops.worker.htb, vamos colocar isso no arquivo /etc/hosts para termos rota e vamos testar.
Se cancelarmos o login, ele exibe uma mensagem de erro, onde informa que não podemos acessar com o modo anônimo esse recurso.
Ele também exibe em baixo, que se trata do Azure DevOps Server, uma plataforma de desenvolvimento de software que permite que equipes colaborem e gerenciem projetos de software.
No nosso escaneamento também encontramos o serviço do SubVersion (SVN Server)
Ele é um sistema de controle de versão, utilizado para desenvolvimento de software. É como se fosse um Github.
Podemos então iniciar uma enumeração nesse sistema:
Vamos listar o conteúdo desse repositório:
Aqui encontramos um arquivo.txt e mais um possível subdomínio que é uma pasta nesse sistema.
Vamos baixar esse repositório para nossa máquina
No arquivo moved.txt descobrimos que o repositório está sendo migrado, e podemos encontrar a última versão dele em devops.worker.htb o mesmo repositório que encontramos no nosso escaneamento que necessita de uma autenticação para acesso.
Vamos colocar no /etc/hosts o domínio que encontramos antes dimension.worker.htb
Temos mais uma página web no sistema.
Analisando o seu código-fonte, encontramos mais alguns subdomínios:
Vamos colocá-los também no /etc/hosts
Podemos criar um arquivo de texto, copiar toda essa parte do código fonte, e ai filtramos para termos os domínios certinhos.
Bom, eles não tinham nada de interessante que nos desse um entrypoint para o nosso alvo. Vamos continuar nossa enumeração do serviço SVN
Ver os logs do repositório:
Observe, estamos na revisão 5, e na revisão 2 ele tinha adicionado um script de deploy que não encontramos na versão 5.
Podemos então retornar a essa versão com o seguinte comando:
Observe que “atualizando” para a revisão 2, temos uma adição do arquivo deploy.ps1 , se listarmos o nosso diretório que baixamos o repositório, iremos verificar que ele mudou. Ele deletou o arquivo moved.txt e adicionou o deploy.ps1
E conseguimos obter uma credencial nesse arquivo.
Na nossa análise, encontramos um local para podermos logar, mas também precisamos lembrar que temos a porta 5985 que é do WinRM, será que conseguimos logar nela com essas credenciais ?
Não podemos conectar com essas credenciais no WinRM.
Vamos retornar então para a aplicação da porta 80 que está rodando o Azure DevOps Server
Após utilizarmos as credenciais obtidas no arquivo deploy.ps1 conseguimos conectar nessa aplicação.
Em vista temos um projeto chamado SmartHotel360
Podemos clicar nele para entendermos mais sobre ele.
Analisando o projeto, podemos ver que fazemos parte do time SmartHotel360 Team
Se analisarmos a Pipeline do projeto, conseguimos ver onde que é a pasta alvo dele no servidor.
Ou seja, a pasta do servidor que esse repositório esta colocando como Target é w:\sites\
Se analisarmos o repositório, vamos ver que já caímos no repositório chamado Spectral que é um dos subdomínios que encontramos anteriormente. Ele esta na branch de master nesse repositório e não há outra.
Ao tentarmos criar um novo arquivo nesse repositório ele funciona normalmente, mas ao tentar realizar o commit recebemos um erro. Esse erro refere-se a não termos permissão de editar essa branch(master) e como o erro nos orienta, temos que usar um pull request para podermos atualizar essa branch.
Vamos criar então essa branch para atualizarmos a branch principal.
Em Work Items to link, coloque qualquer um, eu usei o referente ao User Registration e clique em Create Branch
Refaça oq fizemos anteriormente, crie um novo arquivo agora na nova branch e depois clique em commit. Após isso, selecione o Work Items to link e clique em commit
Após “commitar” vai aparecer uma mensagem acima já dando a possibilidade de criarmos um pull request . Pode clicar no link.
Podemos clicar em Create
Agora que fizemos o pull request ele foi para revisão do time de desenvolvedores do projeto. Como fazemos parte, então podemos aprovar essa alteração:
Após aprovação, podemos clicar em Complete
Pode escolher o tipo de Merge eu mantenho no Squash e vai deletar a nossa branch criada após esse merge.
Se der tudo certo, vai aparecer assim:
Se retornarmos a branch master do projeto, vamos ver que o nosso arquivo foi inserido com sucesso.
Se fizermos o mesmo procedimento, colocando em html, podemos ver de uma forma mais legal via Web no subdomínio spectral.worker.htb que é o repositório que alteramos.
Entendido isso, que podemos alterar a aplicação web do alvo, commitando com uma nova branch para atualizar na master. E o alvo se tratando de um Windows Server, podemos então colocar um webshell em aspx para podermos explorar essa misconfiguration e obter um acesso ao alvo.
Vamos usar um payload de webshell aspx disponível publicamente no github
Repetimos todos os passos feitos anteriormente para criar uma branch, criar um arquivo no repositório, commitar, e realizar o pull request. Só que dessa vez com a intenção de realizar o upload do reverse shell.
Feito isso, basta acessar o caminho na url e teremos o nosso webshell funcional.
Já temos um webshell, podemos então criar um payload com msfvenom para obter um shell reverso. Ou podemos usar reverse shell em powershell também, a gosto do freguês aqui.
Agora abrimos um webserver em python na nossa máquina para servir esse payload. E baixamos no alvo via webshell.
E não se esqueça de abrir um listening com o netcat.
O comando para baixar no alvo fica o seguinte:
Podemos confirmar que o alvo fez um GET para obter o arquivo do nosso servidor.
Se listarmos vamos ver que ele foi salvo com sucesso
Só executarmos ele agora que vamos receber nosso reverse shell
Utilizei o rlwrap antes do nc para deixar o shell mais interativo. No contexto de máquinas Windows, eu gosto dessa trick.
Não conseguimos entrar no único usuário diferente do padrão no alvo, ou seja, temos que acessar ele para podermos pegar a primeira flag de user.txt
Na nossa enumeração do Azure DevOps, descobrimos que o caminho alvo do repositório, estava em: w:\sites
Como estamos em um contexto do powershell, alguns comandos de linux funcionam aqui, então, mas eu desconfio que estamos dentro de um contexto de WSL também.
Pelo motivo do link para /c/users
Bom, isso era só curiosidade da enumeração. Podemos então utilizar o comando df -u para listar os Filesystems e vamos ver que realmente temos um W:\
Por algum motivo eu não estava conseguindo entrar nesse diretório, mas eu consigo listá-lo normalmente.
Ao fazer uma enumeração manual, entro na pasta de repositórios do SVN, e encontro uma pasta bem chamativa conf e db
Em conf temos um arquivo chamado passwd , um nome bem sugestivo.
E o arquivo informa que é o name e senha de cada usuário, um por linha.
Podemos então salvar essa lista em um arquivo de texto, formatar ela apenas com os usuários e apenas com as senhas e fazer um teste com cada credencial.
Podemos usar o Crackmapexec, pois ele informa quando temos uma saída esperada de um usuário que pode executar comandos no sistema. E como temos um serviço de WinRM aberta no alvo, podemos usar ele para confirmar.
E agora podemos fazer a tentativa de login com o protocolo WinRM com o Crackmapexec, sem fazer bruteforce.
E após a execução, realmente tínhamos uma senha correta para o usuário robisl que encontramos no alvo.
Podemos então agora logar com o Evil-WinRm
E assim conseguimos a nossa primeira flag.
Enumeramos o alvo como usuário robisl e não encontramos nada que nos ajudasse a escalar privilégio para administrador do sistema para ler a última flag.
Podemos tentar reutilizar as credenciais do usuário robisl na aplicação Azure DevOps que exploramos anteriormente.
Conseguimos logar com ele na aplicação, e vemos que temos um outro Projeto, agora chamado PartsUnlimited
Uma boa enumeração começa em descobrir quais grupos que o nosso usuário faz parte nesse projeto. Nesse caso, descobrimos que estamos no grupo de Administradores desse projeto, ou seja, temos poder total.
Verificando também as configurações das Pipelines, o agent Hamilton11 esta sendo executado no alvo com o username WORKER$
E o hostname do alvo se chama WORKER, ou seja, nossas definições de compilação estão sendo executadas como SYSTEM
Vamos criar uma pipeline para confirmar isso, vamos colocar etapas de execução gerenciadas por nós.
Há muitas coisas prontas, vamos usar um editor clássico, onde podemos deixar as coisas mais genéricas.
Podemos apenas avançar, pois iremos utilizar o repositório da própria Azure.
Na seleção do template, colocamos Empty pipeline pois como a descrição informa, iniciamos a pipeline zerada e adicionamos nossas próprias etapas.
Selecionamos o Agent pool como Setup , pois é o único que aparece.
E vamos criar um nova job para o nosso agent. Nesse caso quero uma tarefa de powershell, pois que o sistema execute comandos de powershell.
Então selecionamos o tipo de comando do powershell como in line pois quero que execute uma linha de comando. Após isso, eu crio um novo usuário e depois adiciono esse usuário ao grupo local de administradores. Se o processo estiver mesmo sendo executado como SYSTEM teremos a permissão de colocar esse usuário nesse grupo.
Após isso, clique em Save & Queue para que a pipeline seja executada.
Depois de um certo tempo, podemos confirmar que o usuário foi criado e esta no grupo de administradores.
Então conectamos via WinRM novamente, e conseguimos entrar na pasta do administrador e pegar a última flag root.txt
