stong/cve-2020-15368CVE-2020-15368, também conhecido como "Como explorar um driver vulnerável"
Exploit e Prova de Conceito (PoC) para CVE-2020-15368. A Asrock reempacotou o driver rweverything para sua ferramenta de configuração do controlador RGB e o assinou. Eles o "protegem" criptografando seus ioctls...lol. Encontramos essa CVE por acidente no verão passado, e até onde sei o driver ainda não foi corrigido. O impacto é, claro, execução arbitrária de código no kernel, etc. Então aproveitem esse "0day" lol.
Se você quiser discutir comigo se isso é uma CVE REAL DE BOA-FÉ, sinta-se à vontade para me contatar no Twitter, podemos ter uma briga enorme nas redes sociais públicas e será realmente emocionante para todos os envolvidos! Até comprarei um domínio para esse bug se você estiver tão inclinado. É tudo sobre marketing!!!!
De qualquer forma, esse bug é bem ruim, então vou usá-lo como um tutorial sobre como derrotar seu driver vulnerável típico. Portanto, este post é voltado para iniciantes. Você aprenderá a explorar um driver vulnerável. Existem toneladas de outros drivers ruins por aí assim. O mundo é a sua ostra. Divirta-se
AVISO LEGAL: Esta publicação é fornecida apenas para fins educacionais. É responsabilidade do leitor obedecer a todas as leis locais, estaduais e federais aplicáveis. O(s) autor(es) desta publicação não assume(m) nenhuma responsabilidade e não se responsabiliza(m) por qualquer uso indevido ou dano causado pelo software contido nesta publicação.
Presos em quarentena, meus colegas de quarto (Pear0, Codetector) e eu estávamos brincando na nova placa-mãe Asrock do Pear0. Os LEDs vermelhos brilhantes eram extremamente irritantes e não era possível configurá-los no Linux. Assim, nosso plano era fazer engenharia reversa do driver do Windows que o controlava e replicar as operações de I/O no Linux.
Em resumo, não demorou muito até percebermos que o driver é literalmente apenas um driver genérico que concede acesso arbitrário de leitura/escrita a qualquer coisa. Isso inclui registradores de controle como CR3, CR4, memória física, etc. Drivers como este são destinados ao uso como ferramenta de depuração e o site do fornecedor afirma claramente isso.
Achamos isso extremamente engraçado. É bem empolgante a primeira vez que você faz um computador dar triple fault e reiniciar bruscamente a partir do userspace. (Talvez menos empolgante na vigésima vez.) De qualquer forma, reportamos o bug e depois o esquecemos por um ano.
Como novato em kernel, eu me perguntava como realmente carregar e interagir com o driver. Acontece que é extremamente fácil.
Você pode simplesmente criar um serviço para o driver no Process Hacker (obviamente, exige admin para carregar drivers). Então você pode apenas clicar com o botão direito e iniciá-lo. Sim, é realmente assim tão simples.
Podemos ver nosso objeto de dispositivo no WinObjEx64.
Podemos até brincar com o dispositivo no FileTest.
Todas essas 3 ferramentas são incríveis, especialmente PH e FileTest. Elas são como um canivete suíço e deveriam estar na caixa de ferramentas de todo reverser de Windows. Por exemplo, pelo que entendi, Jonas L encontrou inúmeras vulnerabilidades LPE no Windows apenas mexendo no FileTest. Então o Windows realmente tem ótimas ferramentas para bagunçar. Eu queria que houvesse essa merda no Linux.
Rweverything tem um ioctl que recebe outro ioctl como parâmetro, o que controla qual operação será executada (ler mem, escrever mem, ler msr, etc.), e uma união de alguns parâmetros específicos da operação, como endereço src, endereço dst, etc. Quando comparamos o código dos dois drivers:
🤔🤔🤔🤔🤔🤔🤔🤔🤔
No entanto, o driver faz uma tentativa tosca de segurança por obscuridade ao exigir que todas as chamadas ioctl sejam devidamente criptografadas com uma chave AES fixa no código. O código (após alguma limpeza) é assim:
if ( IoControlCode == 0x22EC00 )
{
char enc_key[32];
memset(enc_key, 0, sizeof(enc_key));
memmove(enc_key, "C110DD4FE9434147B92A5A1E3FDBF29A", 32ui64);
memcpy(enc_key + 13, ioctl_args->key, 16);
size_t cb_decrypted = 0;
my_decrypted_cmd* decryptedCmd = NULL;
DWORD iv_size = ioctl_args->iv_size;
DWORD input_size = *(DWORD*)(ioctl_args + bufferLen - 6);
// really just calls BCrypt API to get an AES implementation
if ( (unsigned int)decrypt_ioctl_params(enc_key, 32, ioctl_args->iv, iv_size, ioctl_args + bufferLen - input_size - 6, input_size, &decryptedCmd, &cb_decrypted) )
{
// Decryption failed
if ( decryptedCmd )
ExFreePoolWithTag(decryptedCmd, 0);
irp->IoStatus.Status = 0xC000000D;
goto Fail_Out;
}
IoControlCode = decryptedCmd->opcode;
Rweverything_Args = &decryptedCmd->args;
}
else // not 0x22EC00
{
if ( IoControlCode != 0x22E858 &&
IoControlCode != 0x22E860 &&
IoControlCode != 0x22E800 &&
IoControlCode != 0x22E804 )// whitelisted control codes
IoControlCode = 0; // block everything else
}
O driver permite algumas operações chatas que fazem um pouco de PMIO, mas todos os códigos de controle "divertidos" são bloqueados por essa rotina de descriptografia. Apesar de ter essa lista de permissões explícita, ela ainda inclui todas as funcionalidades perigosas do Rweverything. Em vez de esconder esses recursos perigosos, eles provavelmente deveriam ter sido simplesmente removidos por completo.
Além disso, curiosamente, ele também permite que o usuário especifique parte da chave (???), e eu não faço ideia para quê. O código é simplesmente muito mal escrito.
De qualquer forma, é relativamente fácil escrever o código do cliente para usar essa API criptografada estranha e passar a ela chamadas ioctl arbitrárias que quisermos. Não vou entediá-lo com os detalhes disso.
Abrimos um handle para o driver e usamos DeviceIoControl para chamar o ioctl, coisa bem padrão.
HANDLE hDevice = CreateFileA("\\\\.\\GlobalRoot\\Device\\AsrDrv104", GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
// ... set up the encrypted ioctl data
BOOL result = DeviceIoControl(hDevice, 0x22EC00, ioctl_data, in_buf_size, out_buf, sizeof(out_buf), &bytes_returned, NULL);
Agora que conseguimos conversar com a parte oculta do Rweverything no driver, a primeira coisa que quis fazer foi provocar uma falha para saber se meu cliente do driver está funcionando.
A maneira mais direta de fazer isso é sobrescrever o CR3 com lixo. Sei que alguns de vocês que estão lendo são novatos, e tudo bem, então explicarei em detalhes. Eu também sou burro, então talvez isso ajude você a aprender. Se você sabe o que está fazendo, pode pular esta parte.