DevSecOps na Prática: Análise Detalhada dos Desafios do CyberCamp
Explore os desafios práticos do meetup CyberCamp, onde especialistas em segurança desvendaram problemas complexos em ambientes de contêineres e aplicações bancárias. Descubra as armadilhas, as soluções e os cenários reais por trás de cada desafio.
MundiX News·09 de julho de 2026·21 min de leitura·👁 1 views
Em março, o segundo episódio do meetup DevSecOps CyberCamp trouxe desafios práticos em cibersegurança, utilizando a plataforma Jet CyberCamp. Três tarefas, cuidadosamente elaboradas para simular cenários reais enfrentados por especialistas em segurança de aplicações, foram apresentadas. Este material detalha cada um desses desafios, revelando as ideias por trás de sua criação, as armadilhas intencionalmente inseridas pelos autores e os casos de uso práticos que inspiraram sua concepção.
Desafio 1: Perfil de Insegurança
O cenário envolvia a análise de um perfil AppArmor (/etc/apparmor.d/task-b-66) em um cluster Kubernetes com um servidor web Apache HTTP Server. O objetivo era identificar e corrigir falhas no perfil para garantir o funcionamento correto do servidor e bloquear atividades maliciosas dentro do contêiner. O acesso era restrito, permitindo apenas a observação do estado da carga de trabalho via k9s e o gerenciamento do perfil AppArmor via sudo apparmor_parser, com reinicialização de pods. O acesso direto ao contêiner era proibido.
Ao examinar os logs, a primeira pista surgiu: rm: Permission denied. A investigação revelou que o contêiner utilizava a imagem httpd:2.4.66-alpine3.23, e o script de inicialização httpd-foreground continha um comando rm -f /usr/local/apache2/logs/httpd.pid antes de executar o servidor HTTP. O problema residia no fato de que imagens baseadas em Alpine Linux não possuem o binário rm diretamente; em vez disso, utilizam um link simbólico para /bin/busybox. A correção inicial envolveu ajustar o perfil AppArmor para permitir a execução de /bin/busybox em vez de /usr/bin/rm.
Após a primeira correção, o pod reiniciou, mas um novo erro surgiu: Server unable to reinitialize, or getaddrinfo fail. Isso indicava um problema de rede. A análise do perfil AppArmor revelou que, embora o acesso à rede IPv4 estivesse permitido, o acesso IPv6 estava negado. O stack de rede do Alpine requer requisições IPv4 e IPv6 durante a inicialização do servidor. A solução foi permitir o uso de rede IPv6 no bloco de configurações gerais e no protocolo UDP para o httpd no bloco de configurações privadas. Com essas alterações, o pod entrou em estado Running.
O último obstáculo foi a ausência da página web, apesar do servidor estar em execução. A tarefa exigia a identificação e bloqueio de uma atividade maliciosa que substituía o conteúdo padrão da página. A suspeita recaiu sobre o script de entrypoint modificado. Ao analisar as permissões de acesso ao sistema de arquivos, notou-se a permissão de escrita (rw) para /usr/local/apache2/htdocs/**. A correção final foi restringir a escrita nesta diretório, alterando a permissão para leitura (r), impedindo assim a modificação maliciosa do conteúdo da página web.
Desafio 2: No Início Era a Palavra F*
Este desafio focou na análise de Software Composition Analysis (SCA) para identificar vulnerabilidades em uma imagem de contêiner (cybercamp:latest). Foi fornecida a ferramenta trivy e um arquivo flags.dat com possíveis flags. O primeiro passo foi executar um SCA na imagem principal, revelando um grande número de vulnerabilidades. Em seguida, analisou-se um arquivo de imagem base (node:20.18.1-bookworm.tar) para identificar quais vulnerabilidades foram introduzidas após a construção da imagem base. Utilizando a ferramenta jq, as vulnerabilidades presentes na imagem base foram subtraídas da lista da imagem principal, resultando em 8 CVEs que correspondiam ao número de flags a serem encontradas. Cada CVE foi então correlacionada com o arquivo flags.dat para extrair as flags.
Desafio 3: Bloqueie o Roubo Perfeito
Neste desafio, o participante atuou como um especialista em segurança para analisar uma aplicação bancária e configurar um pipeline de segurança, cobrindo o máximo de defeitos possível. Ferramentas de SAST, SCA e DAST foram disponibilizadas, mas com possíveis erros de configuração. O primeiro flag foi obtido ao corrigir um erro no docker-compose.yaml que impedia o levantamento da aplicação, especificamente a configuração de rede entre os serviços backend e frontend. O segundo flag foi encontrado ao identificar um cabeçalho (X-Debug-User) que permitia contornar a autenticação, explorando uma falha de Insecure Direct Object Reference (IDOR) no arquivo transfers.py. O terceiro flag foi descoberto ao localizar um endpoint de API (accounts/{account_id}) que permitia a leitura de contas de outros usuários através de IDOR, também no arquivo transfers.py. O quarto flag exigiu a identificação de uma classe (UsersResponse) no arquivo users.py que expunha hashes de senha sem autenticação. Finalmente, o pipeline de segurança foi configurado, e os relatórios foram enviados para o SecObserve. O quinto flag foi obtido ao otimizar a configuração do scanner SAST Opengrep, selecionando o pacote de regras standart_rules_pack que resultou em 382 defeitos encontrados com 608 regras aplicadas. O sexto flag envolveu a análise da configuração do scanner Bandit, identificando e corrigindo as regras de exclusão (B104, B105, B608) para incluir mais defeitos na análise, resultando em 7 novos defeitos e 5 atualizados, com os CWEs correspondentes sendo 605, 259 e 89.
O evento CyberCamp continua a evoluir, com o próximo formato sendo um festival ao ar livre em 17 de julho em Moscou, o "Лето в Киберкэмпе 2026", com novas ciber-exercícios, palestras sobre IA, DFIR e networking.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Em março, o segundo episódio do meetup DevSecOps CyberCamp trouxe desafios práticos em cibersegurança, utilizando a plataforma Jet CyberCamp. Três tarefas, cuidadosamente elaboradas para simular cenários reais enfrentados por especialistas em segurança de aplicações, foram apresentadas. Este material detalha cada um desses desafios, revelando as ideias por trás de sua criação, as armadilhas intencionalmente inseridas pelos autores e os casos de uso práticos que inspiraram sua concepção.
Desafio 1: Perfil de Insegurança
O cenário envolvia a análise de um perfil AppArmor (/etc/apparmor.d/task-b-66) em um cluster Kubernetes com um servidor web Apache HTTP Server. O objetivo era identificar e corrigir falhas no perfil para garantir o funcionamento correto do servidor e bloquear atividades maliciosas dentro do contêiner. O acesso era restrito, permitindo apenas a observação do estado da carga de trabalho via k9s e o gerenciamento do perfil AppArmor via sudo apparmor_parser, com reinicialização de pods. O acesso direto ao contêiner era proibido.
Ao examinar os logs, a primeira pista surgiu: rm: Permission denied. A investigação revelou que o contêiner utilizava a imagem httpd:2.4.66-alpine3.23, e o script de inicialização httpd-foreground continha um comando rm -f /usr/local/apache2/logs/httpd.pid antes de executar o servidor HTTP. O problema residia no fato de que imagens baseadas em Alpine Linux não possuem o binário rm diretamente; em vez disso, utilizam um link simbólico para /bin/busybox. A correção inicial envolveu ajustar o perfil AppArmor para permitir a execução de /bin/busybox em vez de /usr/bin/rm.
Após a primeira correção, o pod reiniciou, mas um novo erro surgiu: Server unable to reinitialize, or getaddrinfo fail. Isso indicava um problema de rede. A análise do perfil AppArmor revelou que, embora o acesso à rede IPv4 estivesse permitido, o acesso IPv6 estava negado. O stack de rede do Alpine requer requisições IPv4 e IPv6 durante a inicialização do servidor. A solução foi permitir o uso de rede IPv6 no bloco de configurações gerais e no protocolo UDP para o httpd no bloco de configurações privadas. Com essas alterações, o pod entrou em estado Running.
O último obstáculo foi a ausência da página web, apesar do servidor estar em execução. A tarefa exigia a identificação e bloqueio de uma atividade maliciosa que substituía o conteúdo padrão da página. A suspeita recaiu sobre o script de entrypoint modificado. Ao analisar as permissões de acesso ao sistema de arquivos, notou-se a permissão de escrita (rw) para /usr/local/apache2/htdocs/**. A correção final foi restringir a escrita nesta diretório, alterando a permissão para leitura (r), impedindo assim a modificação maliciosa do conteúdo da página web.
Desafio 2: No Início Era a Palavra F*
Este desafio focou na análise de Software Composition Analysis (SCA) para identificar vulnerabilidades em uma imagem de contêiner (cybercamp:latest). Foi fornecida a ferramenta trivy e um arquivo flags.dat com possíveis flags. O primeiro passo foi executar um SCA na imagem principal, revelando um grande número de vulnerabilidades. Em seguida, analisou-se um arquivo de imagem base (node:20.18.1-bookworm.tar) para identificar quais vulnerabilidades foram introduzidas após a construção da imagem base. Utilizando a ferramenta jq, as vulnerabilidades presentes na imagem base foram subtraídas da lista da imagem principal, resultando em 8 CVEs que correspondiam ao número de flags a serem encontradas. Cada CVE foi então correlacionada com o arquivo flags.dat para extrair as flags.
Desafio 3: Bloqueie o Roubo Perfeito
Neste desafio, o participante atuou como um especialista em segurança para analisar uma aplicação bancária e configurar um pipeline de segurança, cobrindo o máximo de defeitos possível. Ferramentas de SAST, SCA e DAST foram disponibilizadas, mas com possíveis erros de configuração. O primeiro flag foi obtido ao corrigir um erro no docker-compose.yaml que impedia o levantamento da aplicação, especificamente a configuração de rede entre os serviços backend e frontend. O segundo flag foi encontrado ao identificar um cabeçalho (X-Debug-User) que permitia contornar a autenticação, explorando uma falha de Insecure Direct Object Reference (IDOR) no arquivo transfers.py. O terceiro flag foi descoberto ao localizar um endpoint de API (accounts/{account_id}) que permitia a leitura de contas de outros usuários através de IDOR, também no arquivo transfers.py. O quarto flag exigiu a identificação de uma classe (UsersResponse) no arquivo users.py que expunha hashes de senha sem autenticação. Finalmente, o pipeline de segurança foi configurado, e os relatórios foram enviados para o SecObserve. O quinto flag foi obtido ao otimizar a configuração do scanner SAST Opengrep, selecionando o pacote de regras standart_rules_pack que resultou em 382 defeitos encontrados com 608 regras aplicadas. O sexto flag envolveu a análise da configuração do scanner Bandit, identificando e corrigindo as regras de exclusão (B104, B105, B608) para incluir mais defeitos na análise, resultando em 7 novos defeitos e 5 atualizados, com os CWEs correspondentes sendo 605, 259 e 89.
O evento CyberCamp continua a evoluir, com o próximo formato sendo um festival ao ar livre em 17 de julho em Moscou, o "Лето в Киберкэмпе 2026", com novas ciber-exercícios, palestras sobre IA, DFIR e networking.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.