Coisas vulneráveis em execução em contêineres ainda são coisas vulneráveis

Já foi dito – e não só por mim – que código malicioso criptografado ainda é código malicioso. A criptografia não faz nada para mudar isso, exceto possivelmente prejudicar a segurança e a infraestrutura do aplicativo para seu transporte pela rede.

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

Os contêineres não são projetados para proteger aplicativos magicamente. Eles fornecem alguma segurança básica na camada de rede, mas a rede não é o aplicativo. Os aplicativos têm sua superfície de ataque, composta por seu código e interfaces (APIs), bem como os protocolos (HTTP, TCP) e a pilha de aplicativos que eles exigem. Nada disso muda ao adicionar uma entrada a uma tabela de IP ou restringir solicitações de entrada àquelas provenientes da entrada no ambiente em contêiner.

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

As duas primeiras partes dessa estatística — aplicativos e sistema operacional — me chamaram a atenção, porque são dois dos componentes de uma pilha de aplicativos totalmente realizada que não mudam necessariamente com base na localização ou no modelo operacional (nuvem, contêiner, virtualização, etc.). Um aplicativo ou API com uma vulnerabilidade SQLi ou XSS não é magicamente imbuído de proteção quando se move entre modelos. Essa vulnerabilidade está no código. O mesmo vale para plataformas, que são indiscutivelmente parte da pilha de segurança do aplicativo. Uma vulnerabilidade no tratamento de cabeçalhos HTTP no Apache quando executado no Linux ainda existirá se o aplicativo for movido de um modelo tradicional baseado em sistema operacional para um modelo em contêiner.

É importante – até mesmo imperativo – que continuemos a identificar vulnerabilidades em toda a pilha de aplicativos, independentemente de onde ou de que forma o aplicativo é implantado.

Também é igualmente importante manter as proteções de aplicativos já empregadas em aplicativos tradicionais ao migrar para contêineres. Um firewall de aplicativo da Web é tão benéfico para aplicativos implantados em contêineres quanto para aplicativos implantados na nuvem e em ambientes tradicionais.

Assim como outras ferramentas de segurança que a pesquisa descobriu serem usadas pelos entrevistados, como soluções de varredura estática e em tempo real ( SAST, DAST, IAST e RASP ). Embora o uso do firewall de aplicativo da web (WAF) exceda o de outras ferramentas, SAST e SCA (Análise de código-fonte) também são comuns. SCA é um meio estático de erradicar problemas antes da entrega. Vou me datar e observar que ferramentas como o lint se enquadram na categoria de ferramentas SCA e, embora não exponham vulnerabilidades resultantes da interação do código (e com os usuários) em tempo real, elas podem encontrar alguns dos erros mais comuns cometidos por desenvolvedores que resultam em vazamentos de memória, travamentos ou o infame estouro de buffer.

Eu sei o que você está pensando. Você deve estar 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 o JavaScript é interpretado, então todo esse estouro de buffer e vazamento de memória são apenas memórias ruins dos velhos tempos, quando você codificava em C/C++.”

Exceto que JavaScript – e outras linguagens interpretadas modernas – são, em última análise, implementadas em uma linguagem mais próxima da placa de circuito, como C/C++. E como já foi demonstrado no passado , se alguém for inteligente o suficiente, poderá usar esse fato para criar uma exploração do sistema.

E mesmo que isso não seja uma preocupação, há muitas outras vulnerabilidades em qualquer código com base em bibliotecas usadas ou em uma chamada de sistema mal utilizada que viola a segurança no lado do servidor. Pesquisas atuais dizem que 80% dos aplicativos são compostos de componentes de código aberto. A pesquisa da Sonatype observou ainda que houve um aumento de 50% em violações verificadas ou suspeitas relacionadas a componentes de código aberto de 2014 a 2017. Muitos deles são escritos em linguagens que se prestam a erros mais espetaculares, tanto porque são menos controlados quanto porque há 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 bloco de construção dos aplicativos, que são a cara do negócio hoje, é importante escaneá-los e protegê-los, não importa onde ou como eles sejam implantados.

Contêineres ou nuvem. Tradicional ou virtual. Todos os aplicativos devem ser verificados quanto a vulnerabilidades e protegidos contra explorações de plataforma e protocolo. Período.

Os aplicativos devem ser cuidadosamente escaneados e testados durante o desenvolvimento e depois testados novamente na produção. Ambas são necessárias, porque 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 aplicativos, considere o seguinte:

• Empregue ferramentas de análise de código e aplicativos no desenvolvimento. Incorpore-os ao pipeline de CI/CD, se possível.
• Teste novamente em produção, caso a interação com outros componentes/aplicativos apresente problemas.
• Esteja ciente das vulnerabilidades do protocolo e da plataforma , bem como daquelas descobertas em bibliotecas de terceiros que você pode usar
• Integre um firewall de aplicativo web à sua arquitetura. Mesmo que você não o utilize no modo de bloqueio, ele é um recurso inestimável no caso de uma vulnerabilidade de protocolo/plataforma ou biblioteca de dia zero ser descoberta.

Fique seguro!