Um Guia para Vulnerabilidades de Escalação de Privilégios em Container

Uma das muitas promessas dos contentores é o isolamento.

Através do uso cuidadoso de namespaces e cgroups do Linux, os contentores criam uma área restrita onde é possível executar processos independentemente uns dos outros. Isso, combinado com uma experiência agradável para o programador, fez com que os contentores ganhassem popularidade entre engenheiros e profissionais de segurança. 

Mas será que isso é realmente suficiente?

E pode afirmar com certeza que as suas cargas de trabalho estão seguras caso uma delas seja comprometida?

Bem, neste artigo, abordaremos o sonho de todo invasor e o pesadelo de todos os administradores de sistemas, explicando como e por que isso acontece, além de maneiras de evitar que isso ocorra antes que você acabe na primeira página do Hacker News. Para saber mais sobre vulnerabilidades container Docker, consulte: As 9 principais vulnerabilidades Container Docker.

Container e as suas falhas de segurança

Um detalhe importante que muitas vezes é ignorado em relação aos contentores é que todos eles partilham o mesmo host. Isso significa que cada container tão seguro quanto o seguinte. Se o host ou um único container comprometido, isso pode significar um desastre para a sua infraestrutura.
Isso não significa que deva descartar os contentores por completo. Não. O importante aqui é compreender os detalhes.

O isolamento começa a ser quebrado quando os invasores encontram uma maneira de escalar privilégios. Escalar privilégios é uma das ações mais emocionantes, porém desafiadoras, em ataques de segurança ofensivos. Isso transforma um ponto de apoio com privilégios baixos em um comprometimento total do sistema. 

As vulnerabilidades de escalonamento Container tornam a violação das barreiras de segurança menos desafiante e muito mais vantajosa, pois container um único container para obter acesso a um host. 

Isso não é apenas teoria; a infame vulnerabilidade runC de 2019 (CVE-2019-5736) permitiu que invasores sobrescrevessem o binário runC do host e obtivessem acesso root ao host.

Esses ataques estão longe de ser instantâneos, e é por isso que você pode se deparar com perguntas como esta:

Mais recentemente, vulnerabilidades como CVE-2024-21626 e ataques sutis baseados em camadas mostraram-nos que mesmo contentores não root podem tornar-se perigosos quando se usa indevidamente os recursos do Linux, montagens ou camadas do sistema de ficheiros.

É por isso que, com base no nosso guia anterior sobre vulnerabilidades do Docker, exploraremos como esses ataques funcionam, os CVEs recentes que destacam os seus riscos crescentes e como evitá-los.

Vulnerabilidades recentes de escalonamento Container 

Embora nem todas container levem à escalação de privilégios, as mais perigosas geralmente o fazem. Algumas vulnerabilidades contornam container e obtêm privilégios elevados como nenhuma outra. 

A seguir estão três vulnerabilidades recentes de escalonamento container . 

CVE-2024-21626: Fuga do diretório de trabalho do runC

CVE-2024-21626 é umaescape container de alta gravidade que afeta o container amplamente utilizado, runC. A vulnerabilidade surge de uma utilização insegura da chamada prctl PR_SET_NO_NEW_PRIVS com execve, permitindo que um invasor contorne o sinalizador no_new_privs quando o container iniciado com montagens ou capacidades excessivamente permissivas. 

O sinalizador no_new_privs é uma das principais medidas de mitigação contra a escalação de privilégios que muitos container utilizam para sandboxing. 

A falha foi introduzida nas versões do runC a partir da v1.1.11 e foi corrigida na v1.1.12.

CVE-2023-2640 e CVE-2023-32629 no módulo OverlayFS do kernel do Ubuntu

O OverlayFS é um dos blocos fundamentais dos contentores e do Kubernetes. Ele sobrepõe dois diretórios (lowerdir e upperdir) em um único host Linux e os apresenta como um único diretório, proporcionando melhor desempenho para comandos do Docker relacionados a camadas, como docker build e docker commit.

CVE-2023-2640 e CVE-2023-32629 permitem que um agente malicioso use um container sem privilégios de root container montagem de volume para escalar privilégios. Isso é possível porque as montagens de volume são tratadas como discos separados e podem ser usadas para criar OverlayFS, que existe fora da container . Isso permite que os invasores contornem container padrão container e manipulem atributos de ficheiros estendidos em volumes montados, que são então copiados para a camada superior com recursos elevados (como CAP_SETUID ou CAP_SYS_ADMIN) intactos.

CVE-2022-0492

Em 4 de março de 2022, pesquisadores de segurança descobriram uma falha crítica no kernel Linux cgroup_release_agent_write que tinha o potencial de permitirescape container escape assumir o controlo de todo o nó no qual o container .

Cloud e as distribuições Linux agiram rapidamente. Foram lançados patches e publicados avisos. Mas, por baixo da superfície, a complexidade permaneceu. Ao contrário de outros softwares, o kernel Linux não possui um esquema de versões padronizado entre as distribuições. 

Ou seja, a aplicação destes patches e a atualização das imagens base demoraram meses. Durante esse período, os ambientes permaneceram suscetíveis a potenciais ataques.

Prevenção de escalonamentos de privilégios no Docker e no Docker Compose

A melhor maneira de evitar ataques de escalonamento de privilégios dentro de um container Docker container configurar as aplicações container seu container para serem executadas como utilizadores sem privilégios e, em seguida, certificar-se de que os contentores não têm acesso privilegiado.

Na prática, para evitar a escalada de privilégios no Docker, é necessário fazer o seguinte:

• Bloquear escalonamento de privilégios
• Defina um usuário não-root adequado
• Eliminar capacidades do kernel Linux‍

Tem duas opções: durante a execução ou na configuração do Docker Compose. 

Em tempo de execução, utilize os seguintes sinalizadores:

docker run \     
--read-only \     
--security-opt=no-new-privileges \    
--network your-isolated-network \      
--cap-drop ALL     
--cap-add CHOWN \      
--pids-limit 99 \    
--user=your-user \ # seu utilizador não root.    
...                 # OUTRAS OPÇÕES VÃO AQUI      
your-app:v1.0.1

Com o Docker Compose, a configuração será:

serviços:       
webapp:           
imagem: your-app:v1.0.1       read_only: true       security_opt:          
- no-new-privileges:true       redes:          
- your-isolated-network        cap_drop:         
- ALL        cap_add:           
- CHOWN                
# OUTRAS OPÇÕES VÃO AQUI          
...

Executando contentores que requerem acesso de utilizador root

Existem casos (execução de utilitários do sistema, serviços legados, etc.) em que um container precisar de acesso root para funcionar. Nesses casos, pode remapear esse utilizador para um utilizador com menos privilégios no host do Docker.

O remapeamento de container garante que, mesmo que o container está a ser executado como root, ele realmente opera como um utilizador sem privilégios da perspectiva do host, o que reduz o risco de container e comprometimento do host. 

Pode consultar a documentação do Docker sobre remapeamento do namespace do utilizador para obter etapas detalhadas e práticas recomendadas.

Prevenção da escalada de privilégios no Kubernetes

No Kubernetes, a melhor maneira de evitar a escalação de privilégios é durante container , usando a configuração spec.containers.securityContext. Isso porque, uma vez criado um container privilégios excessivos, ele não pode ser atualizado em tempo de execução, e você terá que excluí-lo e recriá-lo. 

O seguinte securityContext protege o container da aplicação container a escalação de privilégios, mesmo com versões Linux do CVE-2022-0492 sem patch, conforme mencionado acima. 

contentores: 
- nome: app    imagem: myapp:bullseye-20230912   securityContext:     
runAsUser: 1000 # Utilizar um ID de utilizador não root     runAsGroup: 1000 # Utilizar um ID de grupo não root      
runAsNonRoot: true # Imponha explicitamente a execução não root     allowPrivilegeEscalation: false # Impede que o processo  obtenha mais privilégios     readOnlyRootFilesystem: true # Impede gravações no sistema de ficheiros raiz     capabilities:       
drop:          
- ALL # Elimine todos os recursos para minimizar a superfície de ataque        add:          
- NET_BIND_SERVICE # Adicionar de volta apenas os recursos necessários para a aplicação      seccompProfile:       
type: RuntimeDefault # Usar o perfil seccomp padrão do tempo de execução do container 

Outra ótima maneira de impedir a escalação de privilégios no Kubernetes é impedir que Pods sem um contexto de segurança sejam agendados. Os controladores de admissão do Kubernetes permitem interceptar solicitações ao servidor API, por exemplo, uma implementação, e validar se determinadas condições foram atendidas antes de serem processadas. 

Para casos de uso mais avançados, pode escrever um controlador de admissão do zero; no entanto, soluções de código aberto como o Kyverno permitem escrever políticas para todo o cluster que podem corrigir implementações que não têm um contexto de segurança definido. Normalmente, isso se parece com o seguinte:

apiVersion: kyverno.io/v1kind: ClusterPolicymetadata: 
name: add-default-securitycontext annotations:   
policies.kyverno.io/title: Adicionar securityContext padrão    
policies.kyverno.io/category: Amostra    
policies.kyverno.io/subject: Pod    
policies.kyverno.io/minversion: 1.6.0   
policies.kyverno.io/description: >-      
Uma entrada de securityContext do Pod define campos como o utilizador e o grupo que devem ser usados para executar o Pod.
Às vezes, escolher  valores padrãopara os utilizadores em vez de bloquear é uma alternativa melhor para não impedir      tais definições do Pod. Esta política irá alterar um Pod para definir  os campos `runAsNonRoot`, `runAsUser`, `runAsGroup` e       `fsGroup` dentro do Pod securityContext , caso ainda não estejam definidos.spec: 
rules:  
- name: add-default-securitycontext   match:     
any:      
- resources:          
kinds:          
- Pod    mutate:     
patchStrategicMerge:        
spec:          
securityContext:            
+(runAsNonRoot): true           
+(runAsUser): 1000           
+(runAsGroup): 3000           
+(fsGroup): 2000

O manifesto acima usa a definição de recurso personalizado (CRD) ClusterPolicy para corrigir pods por meio de mutate.PatchStrategicMerge e um contexto de segurança com um utilizador não root. 

Os contentores seguros são construídos, não presumidos

Embora os contentores proporcionem isolamento e uma forma fiável de criar e executar aplicações, a natureza em constante mudança da container significa que não se pode confiar apenas em medidas preventivas. Em vez disso, deve-se usar uma estratégia que permita responder rapidamente aos incidentes à medida que eles ocorrem. 

Essa estratégia começa com uma análise proativa.

Com Aikido, pode verificar automaticamente container para descobrir pacotes vulneráveis, tempos de execução desatualizados ou instruções Dockerfile arriscadas antes que eles cheguem à produção. O seu verificador de dependências de código aberto amplia essa proteção, verificando as suas bibliotecas em busca de CVEs exploráveis e até mesmo vulnerabilidades corrigidas silenciosamente que os invasores podem usar para obter privilégios elevados.

Essas verificações são reforçadas por IaC e verificações de configuração que sinalizam configurações inseguras do Kubernetes ou Docker, e por segurança CI/CD que aplicam políticas de privilégios mínimos no nível do pipeline. E como a prevenção nunca pode ser perfeita, Aikido adiciona proteção em tempo de execução detectar e responder a container anormais container em tempo real.