"Mais visibilidade é mais poder, mas mais vulnerabilidade". Ezra Furman

Nesse sétimo post falaremos sobre vulnerabilidades em bibliotecas. Se você trabalha com Java há algum tempo, creio que a vulnerabilidade do log4j possa ter te dado algumas dores de cabeça.

Como desenvolvedores, um ponto que falaremos é o que fazer quando descobrirmos um vulnerabilidade. Lembre-se que:

"Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada". H L Mencken

Esse artigo faz parte de uma série, abaixo é possível encontrar a lista completa de artigos.

Estamos nos baseando no curso Desenvolvimento web com Quarkus do @viniciusfcf.

O repositório que estamos utilizando é:

udemy / Desenvolvimento Web com Quarkus / ifood · GitLab

GitLab.com

gitlab.com

Vulnerabilidades

Em TI temos uma máxima de que não existe sistema perfeito! Mesmo soluções que funcionam sem nenhum problema aparente podem apresentar problemas desconhecidos ou novos problemas dado a evolução de outras bibliotecas ou mesmo outros problemas.

O cenário do Log4J aconteceu recentemente, e o pessoal do Coffee and IT até fez um vídeo explicando com um viés de desenvolvimento.

Algumas perguntas podem ficar em nossas cabeça:

• Como saber mais sobre vulnerabilidades de bibliotecas?
• O que fazer quando descobrir uma vulnerabilidade em meu código?
• Será que consigo automatizar de alguma forma a descoberta dessas vulnerabilidades?
• Dentre outras

OWASP e CVE

Um dos pontos de início pode ser a OWASP (The Open Web Application Security Project).

A OWASP é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Eles possuem Chapters em vários países, bem como realizam uma série de eventos com esse foco.

Uma de suas publicações mais conhecidas é o OWASP Top Ten em que são documentadas as 10 maiores vulnerabilidades dados um período de tempo.

Outro termo que falaremos também é o CVE (Common Vulnerabilities and Exposures). No Maven Repo é bem comum ver uma observação quando estamos buscando uma biblioteca.

Note que a versão 2.15.0.Final do Quarkus JUnit 5 nos apresenta alguns alertas:

Olhando um pouco mais para as versões do quarkus-junit5 podemos ver que para a versão 2 do Quarkus ainda não temos nenhuma correção para essas vulnerabilidades.

Estou vulnerável, e agora?

New Blood Showtime GIF by Dexter - Find & Share on GIPHY

Discover & share this Dexter GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Um insight legal que recomendo a todos desenvolvedores é: converse com pessoas de outras áreas para formar uma opinião.

Como desenvolvedores é bem comum acharmos vulnerabilidades e já pensarmos em subir novas versões ou já colocar a mão no código.

Há uns anos atrás tive uma conversa com o Bruno Almeida na ília Digital; ele por ter um background em segurança me fez exatamente essa pergunta, questionando sobre o que eu faria.

Falei que iria atualizar as bibliotecas, alterar o código e coisas do tipo.

Ele então me trouxe um outro ponto de vista bem interessante: Será que preciso atualizar o código? Será que a vulnerabilidade que tenho é passível de ser explorada? Algumas vezes trabalhamos com APIs e diversas camadas como microservices, API Gateway dentre outras, e pode ser que uma fez configurado algo em uma camada superior, não seja passível de se explorar a vulnerabilidade.

O ponto então que ficou em minha mente foi: é importante descobrir as vulnerabilidades que estamos expostos, em seguida entender se essas vulnerabilidades são passíveis de serem exploradas, e caso sejam passíveis de serem exploradas, analisar o impacto de correção nos pontos de nossa solução em que tal vulnerabilidade pode ser explorada.

Automatizando a descoberta de possíveis vulnerabilidades

A OWASP tem um projeto bem interessante, o Dependency-Check.

Ele possui uma série de plugins e integrações que podemos usar para descobrir CVEs no nosso projeto.

No arquivo build.gradle do nosso projeto podemos ver a primeira parte da configuração do plugin:

plugins {
    ...
    id "org.owasp.dependencycheck" version "$dependencyCheckVersion" apply false
}

...

subprojects {
    if (it.name != 'applications') {
        ...
        apply from: "$rootDir/plugins/security.gradle"
    }
}

E no arquivo plugins/security.gradle podemos ver a segunda parte da configuração:

apply plugin: "org.owasp.dependencycheck"

dependencyCheck {
    autoUpdate = true
    format = "ALL"
    outputDirectory = "build/reports/dependencyCheck"
}

Para a lista de demais configurações, acesse o link.

A task que iremos utilizar para executar o plugin será a dependencyCheckAnalyze

Essa task busca as vulnerabilidades associadas a nossas dependências e nos da um detalhamento.

Abrindo o arquivo dependency-check-report.html temos o seguinte:

Além de informar as bibliotecas que temos vulnerabilidades, o plugin consegue obter mais detalhes sobre o problema, situações em que ele acontece e às vezes até direcionamentos sobre a solução. No caso da venerabilidade no okhttp-3.14.9.jar temos:

In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069

Integração com SonarQube

Outra coisa que podemos fazer é instalar o plugin no nosso SonarQube e assim termos uma rastreabilidade de vulnerabilidades como parte do nosso relatório do projeto.

Ignorando falsos positivos

É possível ainda ignorar falsos positivos através da configuração suppressionFile.

Conclusão

O OWASP Dependency Check é um plugin fantástico que pode nos ajudar na descoberta de vulnerabilidades em nossos projetos. Uma consideração é avaliarmos o impacto de tais vulnerabilidades em nossos códigos, além do custo de correção caso seja o nosso caso.

No próximo post falaremos do último plugin utilizado no projeto. Ele será bem importante para formatação do nosso código Groovy, Java, SQL, dentre outros.

Esse post faz parte de uma série sobre Cursos que formaram meu caráter: Desenvolvimento web com Quarkus.

A série completa é:

• Talk is cheap show me the code
• Utilizando Gradle ao invés de Maven
• Plugins do Gradle: Gerenciador de versões de bibliotecas com Versions
• Plugins do Gradle: Saudades do Maven, relatórios com Project-report
• Plugins do Gradle: API First com o OpenAPI Generator
• Plugins do Gradle: API First com o OpenAPI Generator para APIs reativas
• Plugins do Gradle: Validação de vulnerabilidades de dependências com OWASP Dependency Check
• Plugins do Gradle: Lint com Spotless [não publicado]
• GitLab: Motivação para a escolha [não publicado]
• GitLab: Considerações sobre o Prettier em pipelines [não publicado]
• Gitmoji [não publicado]
• SDK Man [não publicado]
• Pré commit hook [não publicado]
• application.yml: Utilizando YML em propriedades de aplicação [não publicado]
• application.yml: Utilizando variáveis de ambiente [não publicado]
• application.yml: Sobrescrevendo opções em teste [não publicado]
• Mapstruct: Utilizando expressões para mapeamentos [não publicado]
• Microprofile SecurityScheme: Sobrescrevendo tokenUrl [não publicado]
• Prometheus: O problema simples que me custou algumas horas [não publicado]
• quarkus-hibernate-reactive-panache: Utilizando as vantagens do Hibernate em projetos reativos [não publicado]
• Testcontainers: Configuração para projetos reativos [não publicado]