image

'Secure Boot op honderden systemen Acer, Dell, Intel en Lenovo te omzeilen'

vrijdag 26 juli 2024, 11:38 door Redactie, 9 reacties
Laatst bijgewerkt: 26-07-2024, 15:39

De Secure Boot-functie op meer honderden modellen laptops, pc's, moederborden en andere apparaten van onder andere Acer, Dell, Gigabyte, Intel, Lenovo en Supermicro is te omzeilen, zo claimen onderzoekers van securitybedrijf Binarly op basis van eigen onderzoek (pdf). Secure Boot is een beveiligingsmaatregel in de Unified Extensible Firmware Interface (UEFI) die ervoor moet zorgen dat er tijdens het opstarten van het systeem alleen vertrouwde software draait. Hiervoor maakt Secure Boot gebruik van digitale handtekeningen die worden vergeleken met vertrouwde digitale sleutels opgeslagen in de UEFI.

Eind 2022 werd door iemand in een GitHub-repository een platform key van American Megatrends International (AMI) gelekt. Deze key beheert de Secure Boot-databases en de vertrouwensketen van firmware tot besturingssysteem. De private key van de platform key was beveiligd met een zwak wachtwoord van vier karakters en daardoor eenvoudig te kraken, zo stellen de onderzoekers. Meer dan tweehonderd apparaten maken gebruik van de gecompromitteerde platform key.

Daarnaast ontdekten de onderzoekers nog eens driehonderd andere apparaten die gebruikmaken van platform keys met de opmerking "do not ship" of "do not trust". Volgens de onderzoekers gaat het om test keys van AMI die tussen fabrikanten en leveranciers worden gedeeld en eigenlijk vervangen hadden moeten worden. "Wanneer dit niet gebeurt, worden apparaten geleverd met de originele niet vertrouwde keys."

Via de gecompromitteerde keys kunnen aanvallers niet vertrouwde code tijdens het bootproces uitvoeren, ook als Secure Boot ingeschakeld is. "Dit compromitteert de gehele beveiligingsketen, van firmware tot besturingssysteem. Aanvallers met toegang kwetsbare apparaten kunnen Secure Boot omzeilen door malafide code te signeren, waardoor ze elk soort UEFI-bootkit kunnen installeren, zoals de recent ontdekte BlackLotus."

De onderzoekers noemen de gevonden problemen PKfail. "Het is een zeer interessant incident, omdat het zoveel verschillende onderdelen met elkaar verbindt waar de software supply chain faalt", zo laten ze weten. De betreffende fabrikant had de key moeten intrekken, maar bleef die juist ondersteunen. Bij de ontwikkeling van firmware blijft de key daardoor in gebruik en belandt zo op allerlei apparatuur.

Volgens de onderzoekers is er niet veel dat gebruikers kunnen doen, behalve kijken of ze de kwetsbare firmware draaien en updates installeren als die beschikbaar komen. In het onderzoeksrapport staat ook een overzicht van kwetsbare modellen.

Reacties (9)
26-07-2024, 14:30 door Anoniem
Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors. Dat geeft mij de indruk dat dat hele secure boot vooral marketing is en niet eens is bedoeld om werkelijk iets van waarde toe te voegen.
26-07-2024, 15:19 door Anoniem
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors.

Hoe kom je daar nou weer bij? Er staat notabene daarboven wat er gebeurd is:
Eind 2022 werd door iemand in een GitHub-repository een platform key van American Megatrends International (AMI) gelekt.

Een externe auditor had dat nooit gevonden. Een auditor bekijkt procedures en documentatie, het is geen digitaal rechercheur die gaat onderzoeken of er misschien een key gelekt is via een repository!

Denken dat een auditor dit vindt is net zo iets als denken dat er geen bugs zitten in drivers die een Microsoft WHQL certificatie hebben.
26-07-2024, 15:52 door Anoniem
Zo secure is het dus niet...
26-07-2024, 16:02 door Anoniem
Voor fabrikanten:

Intrekken en vervangingen van kwetsbare sleutels:

Fabrikanten moeten onmiddellijk de gecompromitteerde sleutels intrekken en nieuwe, veilige sleutels implementeren. Dit voorkomt dat nieuwe apparaten met kwetsbare sleutels worden geleverd.
Regelmatige firmware-updates:

Verplichten dat apparatuur regelmatig firmware-updates ontvangt, zodat kwetsbaarheden tijdig kunnen worden gepatcht. Platforms zouden ook moeten worden ontworpen om eenvoudiger updates uit te voeren.
Beveiliging van private sleutels:

Het gebruik van sterkere wachtwoorden en multimodale verificatie voor private sleutels om te voorkomen dat ze gemakkelijk te kraken zijn.
Herziening van firmware-ontwikkelingsprocessen:

Het verbeteren van beveiligingscontroles tijdens het ontwikkelen en testen van firmware, zodat er geen testsleutels of andere onbetrouwbare componenten in de productieversies terechtkomen.
Educatie en transparantie:

Gebruikers en IT-ondersteuningen informeren over de risico's van onjuiste test-leveranciers en hen aanmoedigen om firmware-informatie goed te controleren.

Voor gebruikers:

Firmware en software bijwerken:

Controleer regelmatig of er updates beschikbaar zijn voor de firmware van je apparaten en installeer deze onmiddellijk.
Beveilig met antivirus- en beveiligingssoftware:

Gebruik robuuste antivirus- en endpoint-beveiligingstools die kwetsbare toepassingen monitoren en ongeautoriseerde wijzigingen aanbrengen. Monitoren van firmware-instellingen:

Controleer regelmatig de instellingen van Secure Boot en andere UEFI-instellingen om ervoor te zorgen dat deze correct zijn ingesteld en geen ongewenste wijzigingen zijn aangebracht.
Opleiding over beveiliging:

Zorg ervoor dat alle gebruikers, vooral in bedrijfsomgevingen, goed zijn opgeleid in het begrijpen van de beveiligingsinstellingen en hoe ze veilig kunnen werken met hun systemen.

Alsu A.I.
26-07-2024, 19:03 door Anoniem
Door Anoniem:
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors.

Hoe kom je daar nou weer bij? Er staat notabene daarboven wat er gebeurd is:
Eind 2022 werd door iemand in een GitHub-repository een platform key van American Megatrends International (AMI) gelekt.
Het beheer van die sleutels had moeten lijken op hoe een CA zijn sleutels beheert. Dat had omgeven moeten zijn met regels en procedures die hadden uitgesloten dat een private key ooit op GitHub was beland of zo'n zwak wachtwoord had gekregen. Als secure boot ook werkelijk secure had moeten zijn hadden daar hoge eisen voor gegolden en was daar ook controle op georganiseerd, inclusief regelmatige audits door interne en externe auditors.

Een externe auditor had dat nooit gevonden. Een auditor bekijkt procedures en documentatie, het is geen digitaal rechercheur die gaat onderzoeken of er misschien een key gelekt is via een repository!
Dat kan echt wel verder gaan dan alleen naar procedures en documentatie kijken. Ik heb een baan gehad waarin ik regelmatig naast interne ook door externe auditors ben geïnterviewd, en die gasten waren verdomd scherp, goed op de hoogte en ze wisten erg goed hoe ze iemand grondig moesten doorzagen. Goed genoeg om het heel moeilijk te maken voor mensen om het voor te doen alsof ze heel anders werken dan ze werkelijk doen. En er werd daar een ruime selectie van mensen uit alle lagen van de organisatie geïnterviewd, inclusief mensen die niet het spelen van politieke spelletjes als werk hadden maar inhoudelijk werk deden.

Absoluut waterdicht kan het natuurlijk onmogelijk zijn. Maar je het hebt over sleutels die essentieel zijn voor de integriteit van het bootproces van zeer grote aantallen computers van een aantal niet bepaald marginale merken. Dan mag je verwachten dat ze dit soort dingen bloedserieus nemen en daar past niet bij dat een belangrijke privésleutel zo zwak beveiligd is en zomaar in een publieke repository kan belanden. Dat hoort in een werkwijze verankerd te zijn die erop gericht is om dat soort ongelukken te voorkomen, compleet met goed georganiseerde scheidingen tussen zaken die niet door elkaar moeten gaan lopen, en daar zit dit hoe deze sleutels zijn gelekt zo ver vanaf dat een goed stel auditors echt wel luchtjes had moeten ruiken.

Het lijkt me duidelijk dat als het bij een hele rij fabrikanten niet goed zit, en als je kijkt naar de genoemde manieren waarop, dat noch de werkwijze, noch de audits op orde waren, als die er al waren, en dat betekent dat dat hele secure boot meer op me overkomt als securitytheater voor marketingdoeleinden dan als een beveiligingsmaatregel.
26-07-2024, 20:07 door Anoniem
>Gebruik robuuste antivirus- en endpoint-beveiligingstools die kwetsbare toepassingen monitoren en ongeautoriseerde wijzigingen aanbrengen.
Waarom mogen deze tools ongeautoriseerd wijzigingen aanbrengen?
26-07-2024, 21:43 door Anoniem
Door Anoniem:
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors.

Hoe kom je daar nou weer bij? Er staat notabene daarboven wat er gebeurd is:
Eind 2022 werd door iemand in een GitHub-repository een platform key van American Megatrends International (AMI) gelekt.

Een externe auditor had dat nooit gevonden. Een auditor bekijkt procedures en documentatie, het is geen digitaal rechercheur die gaat onderzoeken of er misschien een key gelekt is via een repository!

Denken dat een auditor dit vindt is net zo iets als denken dat er geen bugs zitten in drivers die een Microsoft WHQL certificatie hebben.


Hoe kan het volgende dan gebeuren:

Daarnaast ontdekten de onderzoekers nog eens driehonderd andere apparaten die gebruikmaken van platform keys met de opmerking "do not ship" of "do not trust". Volgens de onderzoekers gaat het om test keys van AMI die tussen fabrikanten en leveranciers worden gedeeld en eigenlijk vervangen hadden moeten worden. "Wanneer dit niet gebeurt, worden apparaten geleverd met de originele niet vertrouwde keys."


Blijkbaar gooien (een aantal) leveranciers er met de pet naar, en wordt dit niet via enige controle (liefst voordat die apparaten op de markt komen) opgemerkt.
Als de markt zichzelf niet goed kan controleren, dan moet het maar via een externe onafhankelijke partij (betaald door de leveranciers)
27-07-2024, 10:05 door Anoniem
Door Anoniem:
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors.

Hoe kom je daar nou weer bij? Er staat notabene daarboven wat er gebeurd is:
Eind 2022 werd door iemand in een GitHub-repository een platform key van American Megatrends International (AMI) gelekt.

Een externe auditor had dat nooit gevonden. Een auditor bekijkt procedures en documentatie, het is geen digitaal rechercheur die gaat onderzoeken of er misschien een key gelekt is via een repository!

Denken dat een auditor dit vindt is net zo iets als denken dat er geen bugs zitten in drivers die een Microsoft WHQL certificatie hebben.

De fabrikanten hebben verzuimd om keys en certificaten te vervangen...
Test keys hadden sowieso nooi bruikbaar mogen zijn.
28-07-2024, 16:22 door Anoniem
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors. Dat geeft mij de indruk dat dat hele secure boot vooral marketing is en niet eens is bedoeld om werkelijk iets van waarde toe te voegen.
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors. Dat geeft mij de indruk dat dat hele secure boot vooral marketing is en niet eens is bedoeld om werkelijk iets van waarde toe te voegen.
Door Anoniem: Dit betekent dat secure boot door de industrie is toegepast zonder dat er ook maar enige controle op de werkwijze en integriteit ervan plaatsvond door externe auditors. Dat geeft mij de indruk dat dat hele secure boot vooral marketing is en niet eens is bedoeld om werkelijk iets van waarde toe te voegen.

Amen … marketing heeft nog nooit iets voor de klant opgeleverd. Maar secure boot klinkt wel lekker …
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.