Coisas vulneráveis rodando em contêineres continuam sendo coisas vulneráveis

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Já foi dito – e não apenas por mim – que código malicioso criptografado continua sendo código malicioso . A criptografia não muda isso em nada, exceto, talvez, por impedir que a infraestrutura de segurança e de aplicativos detecte seu transporte pela rede.

O mesmo vale para aplicativos e plataformas executados em contêineres. Se o aplicativo for vulnerável, ele continuará vulnerável, seja executado sobre um sistema operacional, em uma máquina virtual ou, atualmente, em um contêiner. Se o aplicativo for vulnerável no data center, também será vulnerável na nuvem. E vice-versa.

Os contêineres não foram projetados para proteger aplicações como num passe de mágica. Eles oferecem alguma segurança básica na camada de rede, mas a rede não é a aplicação. As aplicações têm sua própria superfície de ataque, que inclui código e interfaces (APIs), bem como os protocolos (HTTP, TCP) e a pilha de software de que necessitam. Nada disso muda ao adicionar uma entrada a uma tabela de IP ou ao restringir, de outra forma, as solicitações de entrada àquelas provenientes do ponto de ingresso do ambiente conteinerizado.

O motivo pelo qual menciono isso é a Pesquisa DevSecOps de 2017 da Sonatype. Nela, 88% dos mais de 2.200 entrevistados concordaram que a segurança de contêineres era importante, mas apenas 53% utilizavam produtos de segurança para identificar aplicações, sistemas operacionais e configurações vulneráveis em contêineres.

Os dois primeiros elementos dessa estatística — aplicações e sistemas operacionais — chamaram minha atenção, pois são dois dos componentes de uma pilha de aplicações completa que não necessariamente mudam de acordo com o local ou o modelo operacional (nuvem, contêiner, virtualização etc.). Uma aplicação ou API com uma vulnerabilidade de SQLi ou XSS não passa a contar magicamente com proteção ao migrar de um modelo para outro. Essa vulnerabilidade está no código. O mesmo vale para as plataformas, que são indiscutivelmente parte da pilha de segurança da aplicação. Uma vulnerabilidade no processamento de cabeçalhos HTTP pelo Apache em execução no Linux continuará existindo se essa aplicação migrar de um modelo tradicional, baseado em sistema operacional, para um modelo em contêineres.

É importante — na verdade, é imprescindível — que continuemos identificando vulnerabilidades em toda a pilha do aplicativo independentemente de onde ou de que forma o aplicativo seja implantado.

Também é igualmente importante manter, durante a migração para contêineres, as proteções de aplicativos já utilizadas em aplicativos tradicionais. Um firewall de aplicações web é tão benéfico para aplicativos implantados em contêineres quanto para aqueles implantados na nuvem ou em ambientes tradicionais.

O mesmo vale para as outras ferramentas de segurança que, segundo a pesquisa, são usadas pelos entrevistados, como soluções de análise estática e em tempo real (SAST, DAST, IAST e RASP). Embora o uso de firewalls de aplicações web (WAF) supere o de outras ferramentas, SAST e SCA (análise de código-fonte) também são comuns. A SCA é uma forma de análise estática que permite eliminar problemas antes da entrega. Vou revelar minha idade ao observar que ferramentas como o lint se enquadram na categoria de ferramentas de SCA e, embora não revelem em tempo real vulnerabilidades decorrentes da interação do código (inclusive com os usuários), elas conseguem identificar alguns dos erros mais comuns cometidos por desenvolvedores que resultam em vazamentos de memória, falhas ou no famigerado estouro de buffer.

Eu sei o que você está pensando. Você está pensando: “Lori, acabei de ler os Resultados da Pesquisa de Desenvolvedores de 2017 do Stack Overflow, e JavaScript é, de longe, a linguagem preferida dos desenvolvedores. E como JavaScript é interpretado, toda essa história de estouro de buffer e vazamento de memória não passa de lembranças ruins dos velhos tempos em que você programava em C/C++.”

Só que o JavaScript — e outras linguagens modernas e interpretadas — é, em última análise, implementado em uma linguagem mais próxima do hardware, como C/C++. E, como já foi demonstrado no passado, alguém com engenhosidade suficiente pode se valer desse fato para criar um exploit para o sistema.

E, mesmo que isso não seja uma preocupação, há muitas outras vulnerabilidades em qualquer código, decorrentes das bibliotecas utilizadas ou do uso indevido de uma chamada de sistema que comprometa a segurança no lado do servidor. Pesquisas recentes indicam que 80% dos aplicativos são compostos por componentes de código aberto. A pesquisa da Sonatype também observou um aumento de 50% nas violações confirmadas ou suspeitas relacionadas a componentes de código aberto entre 2014 e 2017. Muitos desses componentes são escritos em linguagens mais propensas a erros graves, tanto por serem menos controladas quanto por haver cada vez menos desenvolvedores proficientes nessas linguagens.

A questão é que qualquer código está sujeito a conter vulnerabilidades. E, como o código é o elemento fundamental dos aplicativos, que hoje são a cara das empresas, é importante analisá-los e protegê-los, independentemente de onde ou como sejam implantados.

Contêineres ou nuvem. Tradicionais ou virtuais. Todos os aplicativos devem ser verificados em busca de vulnerabilidades e protegidos contra a exploração de falhas em plataformas e protocolos. Ponto final.

Os aplicativos devem ser minuciosamente verificados e testados durante o desenvolvimento e, depois, testados novamente em produção. Ambas as etapas são necessárias, pois a Falácia da Decomposição nos diz que a introdução de novos componentes altera a linha de base. Novas interações podem trazer à tona vulnerabilidades até então desconhecidas.

Para proteger os aplicativos, considere o seguinte:

• Use ferramentas de análise de código e de aplicativos durante o desenvolvimento. Se possível, integre-as ao pipeline de CI/CD.
• Teste novamente em produção, caso a interação com outros componentes/aplicativos revele problemas.
• Mantenha-se a par das vulnerabilidades de protocolos e plataformas, bem como daquelas descobertas em bibliotecas de terceiros que você possa usar
• Integre um firewall de aplicações web à sua arquitetura. Mesmo que você não o utilize no modo de bloqueio, ele será um recurso inestimável caso seja descoberta uma vulnerabilidade de dia zero em um protocolo ou plataforma, ou uma vulnerabilidade em uma biblioteca.

Mantenha-se seguro!

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie