Zero Day Threat é um termo para vulnerabilidades de desenvolvimento que ainda não foram descobertas. Tais vulnerabilidades podem ser exploradas por cibercriminosos, o que afetará a reputação da empresa. Os desenvolvedores enfrentam a tarefa de minimizar o número de defeitos no código que podem causar essa vulnerabilidade. Uma das ferramentas para ajudar a identificar falhas de segurança é o analisador de código estático PVS-Studio para C, C ++, C #, Java.
Ameaça de dia zero
Ameaça de dia zero é um termo que identifica lacunas e vulnerabilidades permitidas pelos desenvolvedores, mas ainda não foram descobertas. Até que a vulnerabilidade seja corrigida, ela pode ser usada para acessar redes, controlar remotamente um computador, manipular dados etc. Esse nome do termo está bem estabelecido devido ao fato de que os desenvolvedores não têm um dia para corrigir o defeito, já que ninguém o conhece ainda. No devido tempo, grandes empresas e softwares como
Adobe ,
Windows ,
navegador Tor e muitos outros sofreram com essas vulnerabilidades.
Algumas organizações tiveram sorte, sua vulnerabilidade foi encontrada por pessoas que não iam usá-la e simplesmente forneceram informações sobre o problema. Por exemplo, isso foi com o
MacOS . Ou houve uma atualização que, além dos novos recursos, também corrigiu acidentalmente a ameaça de dia zero.
No entanto, houve outras situações. Por exemplo, o Google Chrome precisou urgentemente corrigir uma
vulnerabilidade que permitia ao invasor executar remotamente código arbitrário no dispositivo da vítima.
O problema com essa ameaça é que é impossível se defender 100%, pois é difícil se defender contra o que você ainda não sabe. No entanto, existem maneiras de reduzir a probabilidade de tal ameaça em seu projeto, e as discutiremos mais tarde, mas para começar com um pouco de teoria.
Análise estática
A análise de código estático é o processo de verificar o código do programa pelo analisador sem iniciar o próprio programa. A análise estática pode ser considerada como um processo automatizado de revisão de código. Em alguns casos, a eficácia da análise estática é superior à revisão de código, mas não pode ser considerada como uma alternativa completa à revisão de código por vários programadores. Abaixo, tentei descrever brevemente os prós e os contras da revisão de código e análise de código estático entre si.
CVE e CWE
O Common Vulnerabilities and Exposures (CVE) é um banco de dados de erros de software que pode ser usado por criminosos cibernéticos. O CVE foi criado para otimizar defeitos de software conhecidos. A maioria das ferramentas de segurança da informação usava seus próprios bancos de dados e nomes e, para eliminar esse caos e adicionar compatibilidade com várias ferramentas, o MITRE em 1999 criou o CVE. No entanto, o CVE não foi suficiente para avaliar a segurança do código. Isso requer algo mais preciso, com uma descrição detalhada dos problemas e menos grosseira do que ela. Portanto, a base da Common Weakness Enumeration (CWE) foi criada para atender a esses requisitos. Se o erro estiver na lista do CWE, é provável que isso leve a uma vulnerabilidade que pode ser explorada pelo invasor e entrar na lista do CVE. Para maior clareza, você pode olhar o diagrama de Euler abaixo.
Alguns analisadores estáticos podem dizer ao desenvolvedor que, por exemplo, o projeto usa a biblioteca na qual a vulnerabilidade é encontrada. Isso permite que você escolha uma versão mais recente da biblioteca na qual a vulnerabilidade já foi corrigida e reduza a probabilidade de problemas com ameaças decorrentes do código de outra pessoa.
Com o advento do desenvolvimento de listas CVE e CWE, muitas ferramentas de segurança da informação cuidaram de seu suporte, incluindo analisadores estáticos. Esses analisadores podem ser considerados uma solução SAST. O SAST (Static Application Security Testing) permite que os desenvolvedores encontrem vulnerabilidades no código-fonte do aplicativo já nos estágios iniciais do ciclo de vida de desenvolvimento de software.
O uso do SAST no desenvolvimento é outra opção para minimizar a probabilidade de uma ameaça de dia zero. O analisador, classificando seus erros de acordo com o CWE, pode dizer onde está escondida uma possível vulnerabilidade. E, ao corrigir esses erros, o desenvolvedor torna seu aplicativo mais confiável e reduz a probabilidade de uma ameaça de um dia.
Existem várias ferramentas para testes de segurança estáticos. Para demonstrar os recursos ao lidar com vulnerabilidades, vamos nos concentrar na ferramenta
PVS-Studio . Os avisos deste analisador podem ser classificados como CWE. Vejamos alguns exemplos.
Aviso PVS-Studio:
CWE-561 : Código Morto (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
Esse código, inadvertidamente, causou um erro de digitação. Em duas condições, a mesma variável é verificada. A julgar pela exceção gerada, na segunda condição, a variável
outputPath deve ser verificada. Como resultado, parte do código está inacessível.
Tais erros parecem inofensivos à primeira vista. No entanto, essa impressão pode ser muito enganadora. Considere um erro muito simples e à primeira vista inofensivo relacionado à duplicação do operador
goto .
Ao mesmo tempo, esse erro causava uma vulnerabilidade no sistema operacional iOS.
Descrição da vulnerabilidade
CVE-2014-1266 : A função SSLVerifySignedServerKeyExchange em libsecurity_ssl / lib / sslKeyExchange.c no recurso Transporte Seguro no componente Segurança de Dados no componente Segurança de Dados no Apple iOS 6.x antes 6.1.6 e 7.x antes 7.0.6, Apple TV 6.x antes da 6.0.2, e o Apple OS X 10.9.x antes da 10.9.2 não verifica a assinatura em uma mensagem do TLS Server Key Exchange, que permite que invasores intermediários falsifiquem servidores SSL usando um servidor arbitrário. chave privada para a etapa de assinatura ou omitindo a etapa de assinatura.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
Devido ao duplo
goto , também surge uma situação com código inacessível. Independentemente das condições, a segunda
instrução goto será executada nas instruções
if . Isso leva ao fato de que a verificação da assinatura não ocorre. A função retorna 0, o que significa que está tudo bem com a assinatura e, em seguida, o programa recebe a chave do servidor, mesmo se houver um problema com a assinatura. Essa chave é necessária para criptografar dados durante a transmissão.
As consequências de um erro tão simples foram muito graves. Portanto, não faz sentido argumentar quão perigoso esse ou aquele erro é classificado como CWE. Ele só precisa ser corrigido, tornando o código mais seguro.
A propósito, o erro descrito pode ser facilmente detectado pelo analisador PVS-Studio. Ele daria dois avisos da CWE aqui imediatamente:
Vejamos outro exemplo. Em 2012, ficou conhecido o problema de segurança no MySQL, no qual um invasor poderia entrar no banco de dados MySQL. Fornecerei um trecho de código que serviu de razão para isso.
CVE-2012-2122 Descrição : sql / password.c no Oracle MySQL 5.1.x antes de 5.1.63, 5.5.x antes de 5.5.24 e 5.6.x antes de 5.6.6 e MariaDB 5.1.x antes de 5.1.62, 5.2.x antes de 5.2.12, 5.3.x antes de 5.3.6 e 5.5.x antes de 5.5.23, quando executados em determinados ambientes com determinadas implementações da função memcmp, permitem que atacantes remotos ignorem a autenticação autenticando repetidamente com o mesmo senha incorreta, que eventualmente faz com que uma comparação de token seja bem-sucedida devido a um valor de retorno verificado incorretamente.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
O tipo de retorno da função
memcmp é int e o tipo de retorno da função
check_scramble é my_bool , na verdade,
char . Como resultado, um
int é convertido em um
char , no qual os bits de alta ordem são descartados. Isso levou ao fato de que em cerca de 1 caso em 256, era possível conectar-se a qualquer senha, sabendo o nome de usuário.
Novamente, esse erro do CWE pode ser neutralizado e impedido de se transformar em um CVE, mesmo no estágio de gravação do código. Por exemplo, o analisador estático PVS-Studio gera o seguinte aviso:
CWE-197 (
V642 ): Erro numérico de truncamento.
Na continuação deste tópico, proponho olhar para o artigo "
Como o PVS-Studio pode ajudar a encontrar vulnerabilidades? "
Conclusão
Vulnerabilidades de 0 dia - algo contra o qual não há proteção garantida. Mas a probabilidade de sua ocorrência pode ser significativamente reduzida. Para isso, soluções SAST especializadas como o PVS-Studio podem ser usadas. Se o seu projeto detectar erros que podem ser classificados como CWE, você deve prestar atenção neles e corrigi-los. Apesar de apenas uma pequena quantidade de CWE preencher a lista do CVE, eliminando os erros do CWE, você protege seu aplicativo contra muitas ameaças em potencial.
Sitelinks
- Faça o download e experimente o PVS-Studio
- Tecnologias usadas no analisador de código PVS-Studio para procurar erros e possíveis vulnerabilidades
- Classificação de aviso do PVS-Studio de acordo com a Common Weakness Enumeration (CWE)
- Classificação de aviso do PVS-Studio de acordo com o padrão de codificação SEI CERT
Se você deseja compartilhar este artigo com um público que fala inglês, use o link para a tradução: Ekaterina Nikiforova.
Analisador estático PVS-Studio como ferramenta de proteção contra vulnerabilidades de dia zero .