Uma vulnerabilidade de dia zero (0 dia) é uma vulnerabilidade de software de computador introduzida durante o processo de desenvolvimento e ainda não descoberta pelos desenvolvedores. Vulnerabilidades de dia zero podem ser exploradas por hackers, afetando a reputação da empresa. Os desenvolvedores devem procurar minimizar o número de defeitos que levam a essas vulnerabilidades. O PVS-Studio, um analisador de código estático para códigos C, C ++, C # e Java, é uma das ferramentas capazes de detectar problemas de segurança.
Vulnerabilidades de dia zero
Uma
vulnerabilidade de dia zero (também conhecida como
vulnerabilidade de dia zero ) é uma vulnerabilidade de software de computador desconhecida ou não corrigida por aqueles que deveriam estar interessados em atenuar a vulnerabilidade (incluindo o fornecedor do software de destino). Até que a vulnerabilidade seja atenuada, os hackers podem explorá-la para afetar adversamente programas, dados, computadores adicionais ou uma rede. O termo significa que os desenvolvedores não têm um único dia para corrigir o defeito, porque ninguém sabe ainda. Alguns dos fornecedores e produtos de software conhecidos, como
Adobe ,
Windows ,
navegador Tor e muitos outros, foram afetados por vulnerabilidades de dia zero no passado.
Alguns tiveram a sorte de ter uma vulnerabilidade encontrada e relatada por pessoas que não a explorariam. O caso do
MacOS é um exemplo. Em alguns outros casos, os próprios desenvolvedores produziram um patch com o qual, ao adicionar novos recursos, também corrigiam uma vulnerabilidade de dia zero sem conhecê-lo.
Outros tiveram menos sorte embora. Por exemplo, há pouco tempo, o Google Chrome precisou corrigir urgentemente uma
vulnerabilidade que poderia ser explorada para executar remotamente códigos arbitrários.
O problema é que você não pode garantir 100% de proteção contra essas vulnerabilidades, pois não pode combater efetivamente uma ameaça que você nem conhece. No entanto, existem maneiras de tornar esses defeitos menos prováveis de ocorrer no seu programa - este será o tópico deste artigo, mas devemos examinar primeiro algumas teorias.
Análise estática
A análise estática é um método de verificar o código fonte de um programa de software usando um analisador sem executar o próprio programa e pode ser visto como uma revisão automática de código. Às vezes, a análise estática pode ser muito mais eficaz que a revisão de código por pares, mas não pode substituí-la completamente. Tentei resumir os prós e os contras da revisão de código e análise estática entre si na tabela a seguir:
CVE e CWE
Vulnerabilidades e exposições comuns (CVE) é um banco de dados de vulnerabilidades e exposições de segurança da informação. Seu objetivo inicial era organizar defeitos de software conhecidos em uma lista coerente. No passado, a maioria das ferramentas de segurança da informação usava seus próprios bancos de dados e nomes para esses defeitos, e era para trazer ordem a esse caos e estabelecer compatibilidade entre as diferentes ferramentas que a MITRE Corporation desenvolveu o CVE em 1999. No entanto, o CVE acabou por ser insuficiente para estimar a segurança do código. Era necessário algum outro sistema, com classificação mais refinada e descrições mais detalhadas. Foi assim que a Enumeração de Fraqueza Comum (CWE) surgiu. Se um defeito estiver listado no CWE, poderá causar uma vulnerabilidade explorável e ser adicionado à lista do CVE também. O diagrama de Euler abaixo mostra as relações entre os padrões.
Alguns analisadores estáticos podem informá-lo se, por exemplo, seu projeto emprega uma biblioteca que contém uma vulnerabilidade. Sabendo disso, você pode baixar uma versão mais recente da biblioteca, com o defeito corrigido, para tornar seu código menos suscetível a ameaças à segurança causadas por um erro no código de outra pessoa.
Como os padrões CVE e CWE foram adotados pela comunidade de desenvolvedores, eles também foram suportados por muitas ferramentas de segurança da informação, incluindo analisadores estáticos. Os analisadores que suportam essas classificações podem ser vistos como soluções SAST. O SAST (Static Application Security Testing) permite que os desenvolvedores detectem vulnerabilidades no código-fonte dos programas nos estágios iniciais do ciclo de vida de desenvolvimento de software.
O SAST é mais uma prática para minimizar a probabilidade de ocorrência de vulnerabilidades de dia zero no seu projeto. Um analisador que suporta o padrão CWE pode dizer onde está uma vulnerabilidade em potencial, para que você possa corrigi-la para tornar seu aplicativo mais confiável e com menor probabilidade de conter uma ameaça de um dia.
Há uma variedade de ferramentas SAST. Vou
usar o analisador
PVS-Studio como exemplo para mostrar como essas ferramentas podem ajudar a combater vulnerabilidades. Os avisos deste analisador são classificados como CWE. Alguns exemplos são dados abaixo.
Mensagem de diagnóstico do 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"); } .... }
Este código contém um erro de digitação: as condições de ambas as instruções
if verificam a mesma variável. A mensagem que acompanha a exceção sugere que a segunda condição deve verificar a variável
outputPath . Este erro tornou parte do código inacessível.
Erros como esse podem parecer inofensivos, mas essa impressão está errada. Vamos dar uma olhada em outro bug trivial e aparentemente inofensivo que tem a ver com uma declaração
goto duplicada.
Este bug causou uma vulnerabilidade no iOS.
A 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; }
Como no primeiro exemplo, o duplicado
goto aqui levou a um código inacessível: quaisquer que sejam as condições das instruções
if , a segunda instrução
goto seria executada de qualquer maneira. Como resultado, a assinatura não seria verificada, a função retornaria 0, significando que a assinatura estava OK e o programa receberia uma chave do servidor, mesmo que a verificação da assinatura falhasse. Essa chave é usada para criptografar os dados que estão sendo transmitidos.
Esse bug trivial teve implicações drásticas. O incidente ilustra por que não faz sentido especular se esse ou aquele defeito da CWE é perigoso ou não - você só precisa corrigi-lo para garantir a segurança do seu código.
A propósito, o PVS-Studio poderia facilmente encontrar esse bug, relatando-o com dois avisos do CWE de uma vez:
Aqui está outro exemplo. Há muito tempo, em 2012, um problema de segurança foi descoberto no MySQL, que poderia ser explorado por um invasor para entrar no banco de dados MySQL. Abaixo, você verá o fragmento de código defeituoso, onde a vulnerabilidade ocorreu.
A vulnerabilidade
CVE-2012-2122 : 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 certas implementações da função memcmp, permitem que atacantes remotos ignorem a autenticação autenticando repetidamente com o mesma 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); }
A função
memcmp retorna um valor do tipo
int , enquanto a função
check_scramble retorna um valor do tipo
my_bool , que na verdade é
char . O valor
int é convertido implicitamente em
char , com os bits mais significativos truncados. Isso causou cerca de 1 em 256 tentativas de logon com uma senha arbitrária para um nome de usuário conhecido ter êxito.
Novamente, esse defeito do CWE poderia ter sido neutralizado e impedido de se tornar uma vulnerabilidade do CVE muito antes, no estágio de codificação. Por exemplo, o PVS-Studio o reporta como
CWE-197 (
V642 ): Erro de truncamento numérico.
Consulte o artigo "
Como o PVS-Studio pode ajudar na detecção de vulnerabilidades? " Para obter mais informações sobre o tópico.
Conclusão
Você não pode ter 100% de certeza de que seu programa está protegido contra vulnerabilidades de 0 dia. Mas você ainda pode torná-los muito menos propensos a ocorrer. Isso é feito usando ferramentas especializadas do SAST, como o PVS-Studio. Se o seu projeto contém defeitos classificados como problemas do CWE, corrija-os. Embora alguns dos defeitos do CWE acabem na lista do CVE, corrigi-los ajuda a proteger seu programa contra muitas ameaças em potencial.
Referências
- Baixe e avalie o PVS-Studio
- Tecnologias usadas no analisador de código PVS-Studio para encontrar bugs e possíveis vulnerabilidades
- Classificação dos avisos do PVS-Studio de acordo com a Common Weakness Enumeration (CWE)
- Classificação dos avisos do PVS-Studio de acordo com o padrão de codificação SEI CERT