
O objetivo é triar ataques bem conhecidos e aprender como as equipes de segurança respondem rapidamente.
Para este laboratório, o objetivo era fazer a triagem de outra vulnerabilidade real bem conhecida, desta vez o EternalBlue, a falha do SMBv1 que ficou famosa por ser explorada no surto do ransomware WannaCry.
Acessei o National Vulnerability Database e procurei o CVE:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
Pesquisei por CVE-2017-0144 e abri a página de resultados.
Após ler a descrição, respondi a algumas perguntas básicas para entender o que está realmente em risco:
Encontrei a pontuação CVSS e a string do vetor listadas na página:
Analisei a string do vetor parte por parte para entender o que cada item realmente significava:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Este exige uma pequena quantidade de privilégio para ser explorado (diferente do ProxyLogon, que não exigia nenhum), mas ainda assim não requer interação do usuário, e um ataque bem-sucedido ainda compromete totalmente a confidencialidade, a integridade e a disponibilidade. Essa combinação é uma grande parte do motivo pelo qual o EternalBlue era tão perigoso quando combinado com um worm de autopropagação como o WannaCry.
Verifiquei a seção de Enumeração de Fraquezas na página do NVD para este CVE, mas nenhuma CWE foi listada para ele.
Considerei se eu trataria isso como risco maior ou menor em dois cenários diferentes.
Cenário 1: O software vulnerável está ativo e acessível. Risco maior. Esta vulnerabilidade permite que um invasor acesse remotamente o servidor, execute código e acesse arquivos.
Cenário 2: O software vulnerável está instalado em uma máquina que está desligada e não acessível. Risco menor. Sem energia ou conexão de rede, não há como um invasor alcançar o servidor para explorar a vulnerabilidade em primeiro lugar.
Comparando isso com a triagem do ProxyLogon, é um bom exemplo de como duas vulnerabilidades críticas ainda podem diferir nos detalhes: o EternalBlue exige privilégios baixos, enquanto o ProxyLogon não exigia nenhum, mas ambos ainda caem na categoria de "tratar como alto risco" quando se observa o quanto de dano uma exploração bem-sucedida poderia causar. Assim como antes, o risco real ainda se resume ao contexto: a mesma vulnerabilidade é muito menos perigosa em uma máquina que está offline e inacessível.