Lições aprendidas de vulnerabilidades de alto impacto em 2014

Parece que 2014 será lembrado no setor de TI pelas diversas vulnerabilidades graves afetando servidores. Em abril, uma vulnerabilidade grave, que ficou conhecida como Heartbleed (CVE-2014-0160), no software de criptografia OpenSSL – muito utilizado para proteger o tráfego dos sites abalou o sector, deixando centenas de milhares de sistemas abertos a ataques de cibercriminosos. Mais de seis meses depois, milhares de sites e dispositivos continuam vulneráveis.

Em setembro, várias vulnerabilidades críticas (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2.014-6.277 e 2.014-6.278 CVE) foram relatadas no GNU Bourne-Again Shell (Bash), o shell de linha de comando usado em muitos sistemas operacionais Linux/Unix e Mac OS X. As falhas nos sistemas da Apple possibilitavam a um invasor executar remotamente comandos shell, anexando o código malicioso em variáveis de ambiente utilizadas pelo sistema operacional.

Semelhante ao Heartbleed, estas falhas afetam uma ampla gama de sistemas, incluindo, mas não limitado a servidores Apache, servidores web rodando scripts CGI, e sistemas que abrangem qualquer propósito, desde sistemas de controle à dispositivos médicos. Especialistas em segurança alertaram que o impacto do bug do Bash é ainda maior do que o Heartbleed, já que a abrangência do Bourne-Again Shell GNU supera a do OpenSSL.

Então, em meados de outubro, três pesquisadores do Google descobriram uma falha (CVE-2014-3566), conhecida como POODLE, que permite que criminosos cibernéticos possam explorar o desenho do protocolo SSL 3.0 para descriptografar informações sensíveis, incluindo cookies de sessão secreta, resultando na possível aquisição de contas de usuários. O impacto do POODLE é considerado por muitos especialistas em segurança como menos grave, porque muitas organizações têm abandonado SSL 3.0, uma vez que é considerado inseguro, à favor do TLS. Embora menos impactante do que as outras vulnerabilidades de segurança, o POODLE é apenas mais um exemplo de bibliotecas de código aberto e de terceiros amplamente implantados que têm o potencial para colocar aplicativos e sistemas de software em risco.

Finalmente, no dia 11 de Novembro, a Microsoft divulgou um total de 33 vulnerabilidades no Windows, Internet Explorer e Office, sendo a MS14-066 (CVE-2014-6321) a mais crítica, possibilitando a execução remota de código através do Secure Channel (Schannel). Essa falha implica que todos os principais stacks TLS, incluindo Apple SecureTransport, GNUTLS, OpenSSL, NSS, e agora o Microsoft SChannel, tiveram uma vulnerabilidade grave este ano.
Durante anos, a comunidade de fornecedores de software e desenvolvedores de aplicativos internos têm contado com bibliotecas de código aberto e de terceiros para atingir o tempo de chegada ao mercado mais rapidamente. Muitas vezes, assumiu-se que os testes de segurança para essas bibliotecas de terceiros foram conduzidos pelos prestadores e que apenas testes aleatórios foram realizados como parte do processo de ciclo de vida do produto. Então, que lições podemos aprender com essas vulnerabilidades?

1. Aumentar a granularidade de avaliações de gestão de risco do fornecedor

Realizando um processo padronizado de gestão de risco do fornecedor como parte de operações normais de negócios é um passo importante para garantir a cadeia de fornecimento e a minimização de exposição ao risco no que diz respeito a vulnerabilidades de software introduzidas via bibliotecas de código aberto ou de terceiros. Como resultado, as organizações devem aumentar a granularidade de seus programas de avaliação de riscos.

2. Aumentar a frequência de testes de penetração e vulnerabilidades

Uma vez que a base de código de aplicações e firmware de dispositivos estão em constante mudança, as organizações têm de aumentar a frequência de suas varreduras de vulnerabilidades e testes de penetração para identificar eventuais lacunas que podem levar a uma exposição de segurança.

3. Aplicar testes de vulnerabilidade como parte do processo do fornecedor

Com base no aumento do risco colocado por vulnerabilidades em tecnologia de terceiros, as organizações também estão começando a virar a mesa sobre os seus fornecedores. Em vez de usar suas próprias equipes de operações de segurança para avaliar possíveis vulnerabilidades, algumas empresas estão exigindo que os fornecedores usem serviços de verificação independentes para testar aplicações de software mediante à aquisição e implantação.

4. Contextualizar os resultados e automatizar ações de mitigação

Considerando o fato de que as organizações, mesmo de médio porte, devem corrigir milhares de vulnerabilidades por mês, não é de se estranhar que leva tanto tempo para as equipes de segurança validem e corrijam falhas. Como resultado, muitas organizações estão contando com várias ferramentas para produzir os dados necessários de avaliação de vulnerabilidades. Isso só contribui para o volume, velocidade e complexidade dos feeds de dados que devem ser analisados, normalizados e priorizados.

Fonte.

Com essas lições aprendidas, pode-se ter uma noção melhor sobre o assunto acessando o material de artigos e webinars da Clavis. Dentre os que separamos são:

Importância das auditorias de testes de invasão

Segurança ofensiva: ponto de vista do atacante

Vulnerabilidades em aplicações web no modelo OWASP

Teste de invasão em redes sem fio

Nova Lei de Cibercrimes

Auditorias e testes de invasão para proteção de redes corporativas