umarfarook882/cve-2019-0708CVE-2019-0708 - BlueKeep (RDP)
Sequência de Conexão RDP: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/023f1e69-cfe8-4ee6-9ee0-7e759fb4e4ee
Análise da Vulnerabilidade do Serviço RDP: https://www.zerodayinitiative.com/blog/2019/5/27/cve-2019-0708-a-comprehensive-analysis-of-a-remote-desktop-services-vulnerability
Por favor, verifique os dois links acima para entender como a sequência de conexão RDP funciona e sobre a vulnerabilidade existente no driver do kernel RDP do Microsoft Windows - termdd.sys (MS_T120)
Depuração do Kernel Windows: https://medium.com/@straightblast426/a-debugging-primer-with-cve-2019-0708-ccfa266682f6
Sou um n00b em exploração e depuração de kernel :)
Dia 1:
Inicialmente, analisei o script PoC do scanner não autenticado CVE-2019-0708 "BlueKeep" - cve_2019_0708_bluekeep.rb para entender como implementaram o script poc. Então habilitei o modo verbose no datastore do metasploit e comecei a analisar a saída. Mas era muito difícil de entender. Pensei: vamos implementar o mesmo poc em python.
Dia 2:
Escrevi o scanner não autenticado CVE-2019-0708 "BlueKeep" em python, o que me ajudou muito a entender a sequência de conexão RDP e os pacotes. Depois comecei a brincar com pacotes rdp para descobrir a falha por 2 dias, falhei :(
Nota: cve_2019_0708_bluekeep.py é um PoC de scanner não autenticado CVE-2019-0708 "BlueKeep", não um exploit real.
Dia 4:
Percebi onde cometi o erro :) Em vez de usar o script poc existente, comecei a escrever o POC do zero com TLS para facilitar o envio de pacotes rdp.
Nota: Por favor, leia a documentação do MSDN corretamente, tudo está muito claro
Dia 5:
Finalmente consegui a falha, veja o vídeo de demonstração :)
Endereço de e-mail: [email protected] ou [email protected]
Youtube: Fools Of Security
Website: Comunidade Fools Of Security
