Cercetătorii de securitate de la Binarly au descoperit o vulnerabilitate în modul de verificare a încărcării UEFI Secure Boot, afectând peste 800 de produse lansate de companii precum Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo și Supermicro. Problema a primit numele cod PKfail și este asociată cu utilizarea unui cheie de platformă (PK, Platform Key) nesigură în firmware-uri, generată de AMI (American Megatrends International) și livrată ca exemplu de testare. Cele mai vechi firmware-uri care au folosit cheia de testare au fost lansate în 2012, iar cele mai recente sunt din iunie 2024. Potrivit cercetătorilor, peste 10% dintre toate firmware-urile verificate sunt afectate.
În specificațiile cheii, s-a menționat că aceasta nu este de încredere și nu ar trebui livrată în produsele lor. S-a subînțeles că această cheie de testare ar trebui înlocuită cu una proprie, însă producătorii nu au ținut cont de avertisment și au folosit în firmware-urile finale o cheie comună standard livrată tuturor partenerilor și clienților AMI.
Partea privată a cheii de testare AMI, necesară pentru crearea semnăturilor digitale, a devenit publică după o scurgere de informații de la un producător de hardware, ale cărui angajat a publicat din greșeală în depozitul public de pe GitHub un cod ce conține această cheie. Cheia privată a fost plasată într-un fișier criptat, iar criptarea s-a realizat folosind o parolă simplă de 4 caractere, care a putut fi ghicită ușor prin metoda forțării brute.
Cheia de platformă este utilizată ca rădăcină de încredere pentru a valida bazele de date cu chei pentru Secure Boot. Obținerea părții private a cheii de platformă duce la compromiterea întregului lanț de încredere folosit pentru a verifica validitatea componentelor sistemului de încărcare — având cheia de platformă, se poate eluda protecția Secure Boot și se pot substitui componentele proprii prin manipularea cheii KEK (Key Exchange Key) și bazelor de date „db” (Signature Database) și „dbx” (Forbidden Signature Database). KEK este responsabilă pentru crearea lanțului de încredere între firmware și sistemul de operare, „db” conține certificatele și semnăturile pentru bootloader și componentele terță parte UEFI, iar „dbx” include semnăturile revocate ale componentelor malware cunoscute.
Pentru a efectua un atac, este suficient să generați noi chei și certificate pentru KEK și db, după care să folosiți cheia de testare a platformei care a ajuns în acces public pentru a o încărca în firmware-ul UEFI al certificatului KEK creat. După ce certificatul KEK este încărcat în firmware, puteți folosi cheia privată asociată pentru a încărca în baza de date db un nou certificat. După încărcarea certificatului db, cheia privată asociată poate fi utilizată pentru a semna componentele EFI încărcate. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY KEK\/" -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY db\/" -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Pentru a verifica corectitudinea cheii platformei, este suficient să rulați instrumentul „efi-readvar -v PK” din pachetul efitools și să vă asigurați că cheia platformei nu este o cheie de test: efi-readvar -v PK Variabilă PK, lungime 862 PK: List 0, tip X509 Semnătură 0, dimensiune 834, proprietar 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subiect: CN=DO NOT TRUST — AMI Test PK Emitent: CN=DO NOT TRUST — AMI Test PK
Sursa: opennet.ro
