A quem se destina esse post ?
Desenvolvedores ou pessoas interessadas que desejam conhecer um pouco sobre o Pacu e queiram uma referência pontual sobre a ferramenta.
Pré-requisitos para este laboratório
Docker instalado
Sobre o Pacu
Pacu é um framework de código aberto desenvolvido e mantido pela Rhino Security Labs utilizando python3, direcionado à realização de testes ofensivos em ambiente de cloud na AWS. O Pacu traz consigo um conjunto de módulos para testes ofensivos com uma boa documentação, além de também ser possível a utilzação do aws cli diretamente através do seu console, como demonstrado na imagem a seguir. O framework possui uma variedade de módulos, além de gestão de sessões, exportação das credenciais, um banco de dados sqlite, ferramenta de busca, auto-complete e ainda possibilita a criação de modulos de uma forma simples, como será apresentado nesse artigo. Possui uma instalação simples para Unix e MacOS além de um Dockerfile para criação de imagens docker, o que facilita o ambiente de desenvolvimento, possibilitando também a utilização de containers em ambientes Windows. Somente a título de curiosidade Pacu é o nome de uma espécie de peixe encontrada no Amazonas, obrigado aos responsáveis pela referência a um peixe do meu país. :)
Exemplo: awc cli listando informações do usuário.
1
aws sts get-caller-identity
Próximos passos
- Criar usuários para teste na AWS
- Preparando o ambiente de desenvolvimento
- Build imagem docker
- Iniciando o ambiente
- Análise dos resultados
Criar usuários para teste na AWS
A documentação oficial do Pacu já demonstra a criação de um usuário na AWS, disponível aqui. Durante o desenvolvimento foram utilizadas duas (2) credenciais diferentes com políticas de acesso diferentes.
- Default : Privilégios administrativos
- Dev : Privilégios básicos
Preparando o ambiente de desenvolvimento
A seguir foi criado um diretório chamado “pacu_dev” e em seguida dentro desse diretório foi realizado um clone do repositório oficial.
1
2
3
malwarelab$ mkdir pacu_dev
malwarelab$ git clone https://github.com/RhinoSecurityLabs/pacu
malwarelab$ cd pacu/
Dentro do diretório “pacu” podemos visualizar alguns arquivos importantes que serão manipulados:
- settings_template.py
- Dockerfile
Foi realizada uma cópia do //settings_template.py// para //settings.py//
1
cp settings_template.py settings.py
Ao iniciar o Pacu ele irá verificar se existe o arquivo settings.py, caso exista, ele irá utilizar essas configurações, caso não exista ele irá utilizar as configurações do arquivo settings_template.py. Utilizando o vim foi editado o valor do parâmentro ERROR_LOG_VERBOSITY de ‘minimal’ para ‘high’ com o propósito de ter um log mais detalhado.
Opcional: O arquivo Dockerfile foi alterado apenas comentando/removendo o ENTRYPOINT e o CMD, o que não é necessário, apenas foi realizado esse procedimento para minimizar o uso de parâmetros na inicialização do container. Em resumo, não será mais preciso manipular o entrypoint na inicialização do container. Uma informação importante é o WORKDIR, esse diretório contém todos os arquivos do pacu e essa informação será utilizada durante a inicialização do container, que será abordada a seguir em “iniciando o ambiente”.
Build imagem docker
A seguir foi realizado o build da imagem docker.
1
docker build -t pacu_dev:lab .
Ambiente de desenvolvimento
Como prova de conceito foi criado um modulo básico que realiza uma consulta simples verificando se existe algum cluster EKS na região passada como parâmetro. Foi criado um diretório chamado eks_enum no diretório raiz do projeto pacu_dev e também mais dois arquivos dentro do eks_enum, init_.py e main.py.
1
2
3
4
5
malwarelab$ pwd
/.../pacu_dev
malwarelab$ mkdir eks__enum
malwarelab$ touch eks__enum/__ init__.py
malwarelab$ touch eks__enum/main.py
Fonte main.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
#!/usr/bin/env python3
import argparse
from botocore.exceptions import ClientError
from core.secretfinder.utils import regex_checker, Color
module_info = {
# Name of the module (should be the same as the filename)
'name': 'eks__enum',
# Name and any other notes about the author
'author': 'Pupilo Malwarelab',
# Category of the module. Make sure the name matches an existing category.
'category': 'ENUM',
# One liner description of the module functionality. This shows up when a user searches for modules.
'one_liner': 'Enumerates EKS info.',
# Description about what the module does and how it works
'description': 'The module is used to enumerate EKS clusters.',
# A list of AWS services that the module utilizes during its execution
'services': ['EC2'],
# For prerequisite modules, try and see if any existing modules return the data that is required for your module before writing that code yourself, that way, session data can stay separated and modular.
'prerequisite_modules': [],
# External resources that the module depends on. Valid options are either a GitHub URL (must end in .git) or single file URL.
'external_dependencies': [],
# Module arguments to autocomplete when the user hits tab
'arguments_to_autocomplete': [
'--regions'
],
}
parser = argparse.ArgumentParser(add_help=False, description=module_info['description'])
parser.add_argument('--regions', required=True, default=None, help='One or more (comma separated) AWS regions in the format "us-east-1". Defaults to all session regions.')
def main(args, pacu_main):
session = pacu_main.get_active_session()
args = parser.parse_args(args)
print = pacu_main.print
regions = args.regions.split(',')
print('---------------------')
for region in regions:
if region == 'us-west-1' or region == 'af-south-1' or region == 'eu-south-1':
print('EKS not available for ' + region + ' !')
print('---------------------')
else:
clusters = []
client = pacu_main.get_boto3_client('eks', region)
print('Region: ' + region )
response = client.list_clusters( maxResults=10 )
for cluster in response['clusters']:
clusters.append(cluster)
print (clusters)
print('---------------------')
As credenciais foram armazenadas no arquivo ~/.aws/credentials, durante o desenvolvimento foram utilizadas duas(2) credenciais diferentes com políticas de acesso diferente.
- Default : Privilégios administrativos
- Dev : Sem privilégios
Iniciando o ambiente
Foi utilizado o compartilhamento de volume do docker para os diretórios, .aws e o diretório do modulo em desenvolvimento o eks_enum. Dessa forma não será necessário realizar um build da imagem sempre que fizer uma nova alteração no código fonte do módulo.
1
docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd)/eks_enum:/usr/src/pacu/modules/eks__pacu_dev:lab sh
Caso não tenha customizado o Dockerfile utilize o seguinte parâmetro: –entrypoint sh
1
docker run --rm --entrypoint sh -it -v ~/.aws:/root/.aws -v $(pwd)/eks_enum:/usr/src/pacu/modules/eks__pacu_dev:lab
- docker run –rm : Iniciar um container e após ser finalizado este é descartado (–rm)
- -it : Ativa interação com o container solicitando o “sh”, o último parâmetro
- -v ~/.aws:/root/.aws : Compartilhar o diretório de credenciais da aws
- -v $(pwd)/eks_enum:/usr/src/pacu/modules/eks__enum : Compartilhar o diretório do módulo em desenvolvimento para o diretório que contém os módulos do pacu dentro do container.
- pacu_dev:lab : Imagem docker construida anteriormente Como o entrypoint foi removido/alterado é necessário iniciar o Pacu manualmente:
1
python3 pacu.py
Ao iniciar é solicitado o nome de uma nova sessão caso seja a primeira vez que tenha iniciado, o Pacu possui um banco de dados sqlite que é utilizado para salvar dados da sessão.
Em seguida foram importadas as credenciais:
1
pacu (malwarelab:No Keys Set) > import_keys --all
Ao listar os módulos com o comando “ls” é possível observar que o nosso módulo criado anteriormente está disponivel no menu do Pacu.
Com o ambiente configurado dessa forma é possível editar os arquivos do módulo externamente com qualquer editor/ide que desejar, e testá-lo diretamente no container sem a necessidade de que realizar build ou recriar o container. Ao iniciar o container dessa forma, não irá preservar as sessões e logs e após encerrar o container este será removido, mantendo assim um ambiente mais limpo para desenvolvimento.
Análise dos resultados
O módulo criado foi executado com um usuário sem privilégios
1
run eks__enum --regions us-east-1
A imagem a seguir demonstra o comportamento do processo realizado até o momento. Utilizando o usuário sem privilégios, não é possível listar o cluster EKS, é então retornanda uma mensagem de erro informando o diretório de destino do log de erro “error_log.txt” com o seu level como foi configurado anteriormente “HIGH”. Utilizando o comando docker ps, foi obtido o “CONTAINER ID” e em seguida acessado o container:
1
2
docker ps
docker exec -it CONTAINER_ID sh
Em seguida foram verificados os logs de erro gerados, podendo observar que os logs de erro são bem completos.
O diretório sessions do Pacu contém dados das sessões criadas separadas por subdiretórios com o nome respectivo da sessão. Para acessar o log de erro é imporante identificar a sessão utilizada. 
Foi então alterada a credencial de sessão para o usuário com maiores privilégios e então é executado o módulo para listar possíveis clusters na região eu-central-1. Tendo como resultado final a identificação do cluster “web_cluster”. 
A seguir foi realizada uma consulta a mais regiões, sendo que até o presente momento desse artigo algumas regiões na AWS não possuem disponibilidade do serviço EKS, como podemos visualizar na imagem a seguir. 
Conclusão
O Pacu é realmente uma ferramenta formidável para testes em ambientes AWS, além de possuir uma facilidade no desenvolvimento de seus módulos, possui modulos bastante relevantes para testes de segurança. Entretanto, se estiver realizando um teste em ambiente AWS com esta ferramenta certifique-se de se dedicar a documentação oficial da AWS sobre cada serviço que pretende testar e executar módulos. É possível, por exemplo, reiniciar um instância via Pacu e acabar tornando um serviço indisponível.