'Secure Boot op honderden systemen Acer, Dell, Intel en Lenovo te omzeilen'
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.
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.
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.
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.
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.
Waarom mogen deze tools ongeautoriseerd wijzigingen aanbrengen?
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)
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.
Amen … marketing heeft nog nooit iets voor de klant opgeleverd. Maar secure boot klinkt wel lekker …
Je bent niet ingelogd 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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
