CowCloud

uma solução serverless para distribuir cargas de trabalho na AWS

O CowCloud foi originalmente criado para executar ferramentas de reconhecimento (recon) e varreduras de vulnerabilidades de forma distribuída; por exemplo, um caso de uso pode ser por caçadores de bug bounty. Esta solução tem como objetivo abstrair os usuários finais do trabalho subjacente necessário para distribuir cargas de trabalho na AWS. O CowCloud fornece aos usuários uma interface web amigável para visualizar e criar novas tarefas que, posteriormente, são consumidas por código Python executado nos nós de trabalho (instâncias EC2). A intenção é que o código Python seja personalizado, bem como as AMIs EC2. Como exemplo, digamos que você queira executar varreduras Nmap. Nesse caso, você pode simplesmente escolher uma AMI do Catálogo de AMIs e atualizar o campo image_id em Terraform/ec2_module/ec2_module.tf. Em seguida, o arquivo ec2py/template.py teria que ser atualizado para personalizar os argumentos da varredura Nmap (-Pn, -p 443, etc). Por fim, o campo user_data no arquivo de configuração Terraform/ec2_module/ec2_module.tf teria que ser atualizado para instalar o Nmap e suas dependências.

Outra opção é instalar e executar várias ferramentas comerciais; nesse caso, talvez você queira criar sua própria instância EC2 ou snapshot. Nesse caso, você instalaria todas as dependências e ativaria as licenças para poder usar essa AMI como gold image para seus workers

O CowCloud pode ser dividido em três componentes principais:

• uma configuração do Terraform
• um front-end em React JS
• um aplicativo Python que é executado nos nós de trabalho

Estas são as principais funcionalidades:

• A solução usa o Amazon Cognito (com um user pool) para que os usuários possam se cadastrar e entrar no webapp
• Aplicativo React JS como o aplicativo front-end. O front-end exibe as tarefas e os workers e permite adicionar novas tarefas
• API Gateway com integração Lambda para lidar com o CORS e interagir com algumas das funções Lambda para criar e obter informações do DynamoDB
• CloudFront para gerenciamento de SSL e cache
• WAF com regras e condições de endereços IP para restringir o acesso ao webapp (opcional)
• Buckets S3 para armazenar os resultados da execução e o aplicativo front-end; um bucket S3 separado é usado como repositório de código para o aplicativo Python
• Um aplicativo Python como núcleo para executar tarefas nas instâncias EC2 (workers), as ações da ferramenta podem ser divididas em várias etapas:
  • O aplicativo Python consome mensagens
  • executa varreduras
  • compacta a saída
  • e criptografa a saída com AES256-CBC e uma senha
  • e envia o resultado para um bucket S3
• Sempre que um novo worker é criado, o repositório Python é obtido (pulled) de um bucket S3 e, em seguida, o arquivo ec2py incluído nele é executado
• Sempre que um novo worker é criado, um EIP pode ser atribuído automaticamente à instância (opcional)
• Grupos de logs do CloudWatch para armazenar os logs de várias fontes, como erros do Lambda, exceções que ocorrem na ferramenta Python ec2app, o API Gateway, logs do Docker e muito mais
• Lifecycle hooks para alterar o status dos workers no DynamoDB e impedir que os workers sejam encerrados enquanto uma tarefa ainda estiver em execução
• Estratégia de autoscaling baseada no número de tarefas na fila e na configuração definida (mais informações sobre como o algoritmo funciona podem ser encontradas em autoscalingStrategy.py)
• Mapeamento de fonte de eventos do Lambda vinculado à tabela de tarefas no DynamoDB, para gerenciar as ações de autoscaling quando os itens no banco de dados aumentam ou diminuem
• SNS para enviar novas mensagens (tarefas) para um SQS; essas mensagens são posteriormente lidas pelos nós de trabalho
• O serviço Step Functions é usado para criar uma contagem regressiva e excluir os grupos de logs do CloudWatch após a expiração de retention_time
• Se o ec2py executar ferramentas (ex.: Nmap) dentro de contêineres Docker, o stdout pode ser registrado no CloudWatch e visualizado pelo front-end; confira a variável no arquivo (isso é explicado na seção Administrador/mantenedor abaixo)

Diagrama:

As seguintes opções estão disponíveis na configuração do Terraform:

Como resultado da execução do Terraform, um novo arquivo é criado (config.js);, que contém a configuração necessária para o aplicativo React JS autenticar no diretório do user pool do Cognito. Depois que a infraestrutura for implantada, você precisa compilar o aplicativo React e enviar a pasta build. Além disso, você precisa enviar o código Python para um bucket S3 que atua como repositório de código. Esse processo foi automatizado em dois scripts setup.bat e setup.sh para que você não precise se preocupar com isso; isso é apenas para resumir esta etapa.

Etapas de instalação:

A infraestrutura é implantada na região us-east-1 por padrão, embora isso possa ser alterado no arquivo locals.tf dentro da pasta Terraform.

Etapas:

• Você deve criar um usuário com privilégios de administrador na sua conta AWS
• (Opcional) Crie uma AMI ‘golden’ com as ferramentas que desejar
• Vá para a pasta Terraform e atualize o variables.tf; a variável ami deve apontar para uma AMI EC2 existente, que pode ser sua AMI golden ou uma do Catálogo de EC2
• Baixe e instale o aws-cli, NPM, Yarn e Terraform no seu computador
• Configure o aws-cli para usar sua conta AWS com aws configure. Verifique se você o configurou corretamente executando este comando: aws sts get-caller-identity; quando configurado corretamente, isso não deve retornar erro
• (Opcional) Gere um par de chaves SSH para as instâncias EC2. Se você não planeja usar SSH nos workers, atualize o módulo ec2_module de acordo aws ec2 create-key-pair –key-name cowCloud –query “cowCloud” –output text > ec2_module/cowCloud.pem

git clone [email protected]:nccgroup/cowcloud.git
# Deploy the infra
cd cowcloud
cd Terraform
terraform init
terraform plan
terraform apply --auto-approve

• Anote o valor (website) exibido na saída do Terraform; este é o URL para acessar o front-end
• Depois que a infraestrutura for implantada, basta executar setup.sh ou setup.bat para compilar e enviar o código do front-end e do ec2py

Agora você está pronto para começar! Cadastre-se, entre e crie uma nova tarefa!

Fluxo do usuário final

Depois que tudo estiver implantado e o front-end acessível, siga estas etapas:

• Visite o site e clique no botão de login (para se cadastrar, você precisará fornecer um e-mail válido, nome de usuário e senha)
• Valide o e-mail clicando no link que você receber na sua caixa de entrada
• Entre com o e-mail/nome de usuário e senha
• Clique na aba chamada “adicionar uma nova tarefa” e atualize o documento JSON para especificar o domínio alvo e envie o formulário; você receberá um ID de tarefa, um link e uma senha que serão exibidos abaixo.
• Volte para o dashboard e aguarde para ver como uma nova instância EC2 é criada e a tarefa é executada pelo nó de trabalho
• Se a tarefa for executada em um contêiner Docker, o stdout pode ser visualizado pela interface web
• Após a conclusão da tarefa, a tarefa é movida para a tabela de arquivo; agora você pode visitar o link fornecido, baixar o resultado, descriptografá-lo com a senha fornecida e descompactar a saída ou o resultado da ferramenta CowCloud\ec2py> python .\decypt_file.py 2e8cf87c-5389-11ec-abec-d6d1f378b18d
• O worker é encerrado automaticamente assim que a tarefa é concluída

Administrador/mantenedor

• A pessoa responsável por implantar e manter a infraestrutura deve sanitizar e validar adequadamente as entradas dos usuários finais fornecidas pelo webapp. Em outras palavras, garantir que o código em ec2py/template.py não seja vulnerável a injeção de comandos do sistema operacional. Este ponto é destacado por ser o aspecto mais crítico do sistema. Cuidados especiais foram tomados para limitar o escopo das permissões e da exposição do worker e, assim, reduzir os riscos associados. No entanto, é responsabilidade do administrador cuidar desse aspecto da segurança do sistema. As políticas de função (role policies) anexadas ao perfil das instâncias EC2 estão listadas no arquivo readme.md dentro da pasta Terraform

  • Além disso, há uma função Lambda chamada workers_manager.py que é chamada pela ferramenta ec2py para executar ações mais privilegiadas. Essas ações foram movidas para uma função Lambda para limitar o risco caso alguém comprometa a chave de acesso da função (role) anexada ao perfil EC2. Ela funciona com IMDSv2, no entanto. As políticas de função (role policies) anexadas à função Lambda workers_manager.py estão listadas no arquivo readme.md dentro da pasta Terraform

• Se você quiser capturar o stdout e exibi-lo pela interface web enquanto as tarefas estão sendo executadas, vá para o ec2py/template.py e siga estas etapas::

  • A variável extra_docker_params inclui as informações necessárias para que seus contêineres Docker enviem o stdout para os grupos de logs do CloudWatch. Você precisará incluir essa variável na linha de comando quando quiser visualizar o stdout pelo front-end.
  root@kitploit:~

  cmd = f"docker run {extra_docker_params} --rm -v {tmp_folder}target.txt:/root/Tools/reconftw/target.txt -v {tmp_folder}reconftw.cfg:/root/Tools/reconftw/reconftw.cfg -v {tmp_folder}Recon/:/root/Tools/reconftw/Recon/ six2dez/reconftw:main -l target.txt -w".split(' ')
  

Desinstalação

Você pode destruir a infraestrutura executando este comando simples: terraform destroy --auto-approve; isso removerá todos os recursos existentes. Nota: não interrompa esse processo, pois isso pode deixar alguns elementos remanescentes na nuvem, que você teria que identificar e remover manualmente.

Fluxo do usuário final

Fluxo principal

Notas de desenvolvimento

• Se você fizer uma alteração no aplicativo ec2py, lembre-se de sincronizar as alterações com o repositório S3; você deve então encerrar as instâncias atuais e iniciar uma nova para obter as alterações mais recentes
• Quando um componente do módulo gateway é alterado, talvez seja necessário reimplantar a REST APi; para fazer isso:
  • terraform destroy --auto-approve -target module.gateway_module.aws_api_gateway_deployment.lambda
  • terraform apply --auto-approve -target module.gateway_module

Agradecimentos especiais a:

• Sabrina MM https://www.linkedin.com/in/sabrina-marisol-martinez-a4bb54181/
• Ricardo Martinez Martin (NCC Group)
• Conor McErlane (NCC Group)
• Simon Harraghy (NCC Group)