Bucket
Difficulty: Medium | OS: Linux | Amazon S3 - Amazon DynamoDB
Last updated
Difficulty: Medium | OS: Linux | Amazon S3 - Amazon DynamoDB
Last updated
Análise passiva das tecnologias que estão nessa página web:
Analisando o código-fonte da página, encontramos as imagens linkadas em um outro subdomÃnio chamado: s3.bucket.htb
Podemos então colocar esse novo subdomÃnio no /etc/hosts para podermos ter rota para ele.
Analisando melhor via Burp a response, vimos que no cabeçalho da response temos algumas informações que indicam ser um serviço Amazon S3.
Pesquisa rápida no google conseguimos confirmar a nossa premissa.
Vamos então descobrir qual o bucket desse amazon S3
Descobrimos então, como no código-fonte que o bucket se chama adserver
Vamos listar todo o bucket adserver
Conseguimos listar, então tentamos também escrever nesse bucket, enviando uma poc simples.
Após confirmarmos que ele fez o upload com sucesso, podemos entrar na aplicação web via browser e confirmar a nossa poc
IMPORTANTE: o alvo limpa rapidamente o nosso arquivo, caso não funcione de primeira, tente novamente, mas seja rápido, pois ele limpa.
Como vimos no inicio que nossa página tem tecnologia php , podemos então fazer um upload de um reverse shell em php
Após isso fazemos o mesmo procedimento anterior de realizar o upload para o alvo.
Antes de executar deixe um listening na porta escolhida, no meu caso foi a porta 443
E conseguimos acesso ao alvo.
Vamos melhorar esse shell para que possamos ter mais liberdade de execução de comandos.
Fomos no local que é comum ter a flag de user.txt, ela estava na pasta pessoal do usuário roy
Porém, não temos permissão de leitura, apenas o usuário roy pode ler a flag.
Começamos então a fazer uma enumeração do alvo, a fim de tentar escalação de privilégio horizontal para o usuário roy
Ainda na pasta do usuário roy , temos uma pasta que foge do padrão, chamada project
Nela temos um arquivo chamado db.php que nos chama a atenção, pois pode ser dado do banco de dados, e com isso podemos encontrar credenciais.
Não temos credenciais em hardcode, mas temos uma informação importante. É um arquivo de configuração para se comunicar com o DynamoDB
Amazon DynamoDB é um serviço de banco de dados NoSQL gerenciado pela AWS
Podemos então tentar listar as tabelas do banco de dados com o comando abaixo.
Caso você receba esse erro, irá precisar configurar um profile para a aws cli.
Utilize o comando abaixo para configurar o perfil para a AWS CLI.
Observe que recebemos um erro ao terminar de configurar, pois ele tenta salvar no arquivo /var/www/.aws que não temos permissão alteração.
Alteramos então a variável de ambiente HOME para que ele salve esse arquivo em um diretório que possamos editar.
Obs: observe que apenas a região e o formato de saÃda eu defini. A região fica fácil, pois estava no arquivo de configuração db.php o formato de saÃda não importa pra gente, mas eu quis colocar json.
Podemos tentar listar novamente as tabelas do banco de dados
Agora obtivemos sucesso nessa listagem, e temos apenas a tabela Users
Vamos então descobrir todos os valores que temos na tabela users:
Observe que conseguimos listar a tabela Users, e encontramos diversas senhas com alguns usernames.
Algo bem comum e que podemos tentar é o reaproveitamento de senhas.
Vamos tentar autenticar com o usuário roy com uma dessas 3 senhas encontradas.
Após as tentativas, conseguimos logar com uma das senhas no usuário roy e conseguimos ler a primeira flag user.txt
Vamos agora continuar nossa enumeração, dessa vez com o usuário roy
Analisando as portas que temos no alvo, temos algumas portas rodando apenas do lado do alvo (127.0.0.1)
4566 vimos que é a do DynamoDB, mas ainda temos a porta 8000
Realizamos um Reverse Port Forward com o chisel
Aqui podemos confirmar que foi aberto a porta 8000 no nosso Kali, ou seja, ela está com o trafego do alvo sendo redirecionado para ela.
Podemos entrar no nosso navegador e acessar a porta 8000 através do nosso localhost.
Executando um Fuzzing, encontramos alguns caminhos interessantes como: files, index.php, server-satatus e vendor
Em /files/ temos um index of aberto.
Na nossa enumeração inicial, encontramos a pasta bucket-app em /var/www/ pasta padrão de webroot.
E nela encontramos um arquivo index.php , que normalmente é o arquivo principal de um site.
Analisando o mesmo, encontramos algo interessante:
Análise do código:
1 - Podemos ver que ele também está fazendo uma comunicação com o banco de dados Amazon DynamoDB
2 - Ele faz um verificação se o método http é POST se sim, ele passa para outra condicional. Dentro dessa requisição POST, ele informa o parâmetro, chamado action e verifica se foi enviado uma ação chamada get_alerts . Ou seja, só executa se a ação for essa.
3 - Configura o cliente do DynamoDB para se conectar com o banco de dados de forma correta.
4 - Consulta ao DynamoDB $iterator = $client->getIterator('Scan', array( ... )); , na tabela chamada alerts
'TableName' => 'alerts' → indica a tabela a ser consultada
'FilterExpression' => "title = :title" -> Filtra os resultados para encontrar itens onde o "title" é igual a um valor especÃfico.
'ExpressionAttributeValues' => array(":title"=>array("S"=>"Ransomware")): Define que o valor especÃfico a ser procurado é "Ransomware".
Basicamente, ele está buscando todos os alertas cujo tÃtulo é "Ransomware".
5 - Processa os resultados, ele faz uma iteração para cada alerta encontrado. Cada um que ele encontra, ele gera um HTML com nome aleatório e salva o conteúdo do alerta ( que esta no campo data do item do banco de dados) em um arquivo html
Após isso, ele executa um comando java que pega o arquivo html criado e o converte em um arquivo pdf
Ok, agora que entendemos o código, vamos analisar novamente as tabelas que temos no nosso banco de dados
E como vimos, só temos a tabela users
Ou seja, se tentarmos enviar uma requisição POST com a ação esperada, como não existe a tabela no banco de dados, vamos receber um status code 500 de erro interno do servidor.
Vamos então criar uma nova tabela no banco de dados. Podemos usar como auxÃlio a documentação da Amazon DynamoDB oficial.
Porém, quando pensamos em CLI, temos um problema nessa documentação. Pois, os parâmetros --attribute-definitions, --key-schema e --provisioned-throughput precisam que os dados sejam fornecidos como listas JSON.
E eu coloquei essa opção --provisioned-throughput ,pois ela permite que você controle a capacidade da tabela.
Criar tabela:
Aqui conseguimos confirmar que a tabela foi criada.
Obs: faça rápido, pois as rotinas do alvo limpam as mudanças que fizemos.
Agora vamos criar um alerta de Ransomware, pois vimos no código index.php que ele só vai triggar quando encontrar um alerta de Ransomware.
Alerta criado.
Vamos agora fazer uma requisição POST com a ação de get_alerts para que a cadeia de ações do código do index.php seja executada.
E aqui conseguimos ver que ele realmente salvou em /files/ os arquivos criados.
O html com um nome aleatório como dizia o código, e com o html foi criado um arquivo pdf.
Bom, já vimos que estamos conseguindo executar e toda a chain necessária.
Vamos então tentar ler um arquivo interno da pasta root para podermos conseguir ler, vamos usar a tag <iframe com uma origem src , e vamos apontar para a chave privada do usuário root
Refazemos todos os passos. Lembre-se de fazer rápido, pois o alvo limpa as nossas alterações.
Nesse caso, o meu html deu errado, talvez pq não coloquei todas as tags de um script html.
Porém, o pdf criado com o conteúdo do html foi sucesso, e trouxe o arquivo de chave privada id_rsa que solicitamos.
Salvamos essa chave privada em um arquivo em nossa máquina.
Há a necessidade da alteração das permissões da chave privada, senão o utilitário ssh não irá aceitar.
Podemos então nos conectar com o usuário root passando a chave privada que obtivemos.
E conseguimos acessar como usuário root no alvo.
E podemos ler a última flag root.txt
Pessoal, há outras formas de fazer essa máquina. Principalmente na hora que estamos enumerando o DynamoDB. Porém, acredito que a enumeração via AWS CLI seja a mais indicada pois nem sempre teremos uma interface gráfica para podermos usufruir. Lembre-se: há uma automação de limpeza das nossas ações no alvo, então talvez você faça o uploade de um arquivo para o Bucket S3, ele vai exibir quando você listar o bucket, mas talvez não apareça na página web. Isso é normal nessa máquina, então tente novamente que irá funcionar! E tenha atenção na hora da criação da tabela, do alerta, da requisição e obtenção da informação do pdf. Pois, isso acaba sendo chato pela limpeza da máquina. Crie um script para que ele faça toda essa cadeia de forma automática, assim não vai ter tantos problemas.
