Come sfruttare un driver Windows vulnerabile

Exploit e Proof of Concept (PoC) per CVE-2020-15368. Asrock ha ricomprato il driver rweverything per il loro strumento di configurazione del controller RGB e lo ha firmato. Lo "proteggono" crittografando i loro ioctl... lol. Abbiamo trovato questa CVE per caso l'estate scorsa, e per quanto ne so il driver non è stato ancora patchato. L'impatto è ovviamente esecuzione arbitraria di codice nel kernel, ecc. Quindi godetevi questo "0day" lol.

Se volete discutere con me se è una VERA CVE BONA FIDE, sentitevi liberi di contattarmi su Twitter, possiamo fare una bella lite sui social media pubblici e sarà davvero eccitante per tutti i coinvolti! Comprerò anche un dominio per questo bug se siete inclini. È tutta una questione di marketing!!!!

Comunque, questo bug fa abbastanza schifo, quindi lo userò come tutorial su come pwnare il tipico driver vulnerabile. Quindi questo post è rivolto ai principianti. Imparerete come sfruttare un driver vulnerabile. Ci sono un sacco di altri driver scadenti là fuori come questo. Il mondo è vostro. Divertitevi

DICHIARAZIONE DI NON RESPONSABILITÀ: Questa pubblicazione è fornita solo a scopo educativo. È responsabilità del lettore rispettare tutte le leggi locali, statali e federali applicabili. Gli autori di questa pubblicazione non si assumono alcuna responsabilità e non sono responsabili per qualsiasi uso improprio o danno causato dal software contenuto in questa pubblicazione.

Retroscena

Bloccati in quarantena, io e i miei coinquilini (Pear0, Codetector) giocavamo con la nuova scheda madre Asrock di Pear0. I LED rossi brillanti erano estremamente fastidiosi e non era possibile configurarli su Linux. Quindi il nostro piano era di fare reverse engineering del driver Windows che la controllava e replicare le operazioni di I/O su Linux.

Per farla breve, non ci volle molto per capire che il driver è letteralmente solo un driver generico che concede accesso di lettura/scrittura arbitrario a qualsiasi cosa. Questo include registri di controllo come CR3, CR4, memoria fisica, ecc. Driver come questo sono pensati per essere usati come strumento di debug e il sito web del venditore lo dichiara chiaramente.

Abbiamo pensato che fosse estremamente divertente. È piuttosto emozionante la prima volta che fai fare a un computer un triple fault e un hard reboot dallo spazio utente. (Forse meno emozionante la ventesima volta.) Comunque, abbiamo segnalato il bug e poi ce ne siamo dimenticati per un anno.

Configurazione

Da pivello del kernel, mi chiedevo come caricare e interagire effettivamente con il driver. Si scopre che è estremamente facile.

Puoi semplicemente creare un servizio per il driver in Process Hacker (ovviamente, richiede admin per caricare i driver). Poi puoi fare clic con il tasto destro e avviarlo. Sì, è davvero così semplice.

Possiamo vedere il nostro oggetto Device in WinObjEx64.

Possiamo anche giocare con il dispositivo in FileTest.

Tutti questi 3 strumenti sono fantastici, specialmente PH e FileTest. Sono come un coltellino svizzero e dovrebbero essere nella cassetta degli attrezzi di ogni reverse engineer di Windows. Per esempio, da quanto ho capito Jonas L ha trovato innumerevoli vulnerabilità LPE di Windows semplicemente giocherellando con FileTest. Quindi Windows ha davvero alcuni ottimi strumenti per scherzare. Vorrei che ci fosse questa roba su Linux.

Bypass della "sicurezza"

Rweverything ha un ioctl che prende un ioctl come parametro, che controlla quale operazione eseguire (leggere memoria, scrivere memoria, leggere msr, ecc.), e una union di alcuni parametri specifici dell'operazione come indirizzo src, indirizzo dst, ecc. Quando confrontiamo il codice dei due driver:

🤔🤔🤔🤔🤔🤔🤔🤔🤔

Ciononostante, il driver fa un tentativo maldestro di sicurezza tramite l'oscurità richiedendo che tutte le chiamate ioctl siano opportunamente crittografate con una chiave AES hardcoded. Il codice (dopo una piccola pulizia) appare così:

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
}

Il driver consente alcune operazioni noiose che fanno un po' di PMIO, ma tutti i codici di controllo "divertenti" sono protetti da questa routine di decrittazione. Nonostante abbia questa esplicita allow-list, include ancora tutte le funzionalità pericolose di Rweverything. Invece di nascondere queste funzionalità pericolose, probabilmente avrebbero dovuto semplicemente rimuoverle del tutto.

Inoltre, cosa interessante, consente all'utente di specificare parte della chiave (???), per quale motivo non ne ho idea. Il codice è semplicemente scritto molto male.

Comunque, è relativamente facile scrivere il codice client per usare questa strana API crittografata e passarle chiamate ioctl arbitrarie a nostro piacimento. Non vi annoierò con i dettagli.

Comunicare con il driver

Apriamo un handle al driver e usiamo DeviceIoControl per chiamare l'ioctl, roba molto standard.

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);

Ora che siamo in grado di comunicare con la parte nascosta di Rweverything del driver, la prima cosa che volevo fare era provocare un crash per sapere che il mio client del driver funziona.