'Hackers hebben private keys en Intel BootGuard Keys gestolen bij aanval op MSI'

Securitybedrijf Binarly claimt dat hackers die in april een cyberaanval hebben uitgevoerd op de systemen van MSI zowel private keys als Intel BootGuard hebben buitgemaakt. De hackers hebben deze keys gepubliceerd en dat zou gevolgen hebben voor andere pc-fabrikanten.

Alex Matrosov, de ceo van Binarly, schrijft op Twitter dat 57 producten van MSI gebruikmaken van de gelekte private keys. Deze keys worden gebruikt om MSI-firmware op apparaten te signeren en is een belangrijke maatregel om de beveiliging van apparaten van het bedrijf te garanderen. Het uitlekken ervan kan tot kritieke beveiligingslekken leiden want het geeft aanvallers de mogelijkheid om schadelijke software alsnog te signeren.

Volgens de man maken ook 116 MSI-producten gebruik van de uitgelekte Intel BootGuard Keys. Via Intel BootGuard wordt de opstartprocedure van een computer met een Intel-cpu geverifieerd. De software zorgt ervoor dat malware of andere niet-geautoriseerde software geen aanpassingen kan doen aan de UEFI-firmware van een apparaat waardoor diens integriteit gewaarborgd blijft.

Matrosov schrijft dat het lek van de Intel BootGuard Keys bij MSI ook gevolgen heeft voor andere bedrijven uit de industrie. Die zouden immers dezelfde keys gebruiken waardoor hun apparaten nu ook een verhoogd risico lopen.

Begin april bevestigde MSI dat het slachtoffer is geworden van een cyberaanval. MSI vertelde toen niet over welke soort aanval het ging en wie er achter zat. Klanten van MSI kregen wel het nadrukkelijke advies om alleen firmware- en biosupdates van de officiële website van MSI te installeren. BleepingComputer kreeg te horen van ransomewaregroep Money Message dat zij achter de aanval zaten. De groep claimde 1,5TB aan data te hebben gestolen en eiste vier miljoen dollar van MSI.

Reacties (103)

[5pë©ïàál_Tèkén]

Ik heb even de officiele whitepaper van Intel Hardware Shield erbij gepakt om iets meer te concretiseren wat er nou aan de hand is. Meer dan een paar websites roepen 'aaah paniek security', zonder nou concreet te zeggen wat dit betekend. Voor mij is de kreet 'schadelijke software' te generiek. Mensen kunnen dan (terecht) denken 'ja maar daar heb ik toch Windows Malicious Software Removal Tool (MSRT) voor?' Als we het zouden hebben over firmware, dan zouden een hoop mensen al denken dat dat iets anders is dan 'gewoon' software. En firmware komt vandaag de dag niet meer alleen van de fabrikant zelf - er zijn ook clubs die zelf firmware maken voor apparaten. Bijvoorbeeld DD-WRT & Openwrt voor routers en Coreboot.

Wanneer een moederbord de fabriek verlaat, krijgt het (ergens ver weg verstopt) een private public key mee. Met deze key kan het moederbord de afkomt van een firmware update checken. Nu de keys gelekt zijn, kan iedereen met deze keys neppe firmware maken en deze presenteren als authentiek. De gevolgen voor verkeerde firmware zijn ernstig - het bricken van moederborden behoort tot de mogelijkheden, maar ook voltage schommelingen en de gevolgen daarvan. Het 'grappige' van dit scenario is dat veel mensen altijd zeiden dat het ergste scenario bij een verkeerde BIOS update is dat je PC het 'gewoon' niet meer doet, en dat andere scenario's nagenoeg onmogelijk zijn juist vanwege deze keys. Nu kan het dus lijken alsof alles OK er, terwijl er op de achtergrond allerlei poortwachterfuncties zijn weggevallen. Daardoor ben ik 'benieuwd' hoe creatief kwaadwillige firmwaremakers kunnen zijn.
Dit probleem zou niet zo groot zijn als het updaten van een BIOS niet zo laagdrempelig was gemaakt. HP bijvoorbeeld zegt het volgende over BIOS updates;

Updating the BIOS is recommended as standard maintenance of the computer. It can also help to improve computer performance, provide support for hardware components or Windows upgrades, or install specific BIOS updates.

[bron]. Terwijl Intel zelf zegt

There’s one thing to know up front: Unlike updating Windows or graphics drivers, a BIOS update isn’t routine. It’s recommended only when your PC or motherboard manufacturer advises it, or when you’ve diagnosed a problem that a BIOS update is known to fix.

[bron]. Er is dus geen consensus wat betreft hoe nodig/serieus een BIOS update is.

Tl;dr - Alles wat in de whitepaper van Intel Hardware Shield staat op losse schroeven. En misschien is het een open deur, maar AMD CPU gebruikers hoeven zich geen zorgen te maken.

@The Zep Man thx!

[Reactie gewijzigd door 5pë©ïàál_Tèkén op 23 juli 2024 09:06]

[Xander2]

Dit probleem zou niet zo groot zijn als het updaten van een BIOS niet zo laagdrempelig was gemaakt.

Wat stel je dan voor? Dat de halve wereld zijn mobo terugstuurt als er een security issue gevonden is in de firmware? Mogen drivers geen firmware meer bevatten?

Dit akkefietje heeft niets met UEFI update beleid te maken en alles met sleutelbeheer. MSI heeft hier geblunderd en ik ben benieuwd of dit op te lossen is, want de ACM hash zit ingebakken...

[FreezeXJ]

Dan breng je even een BIOSUEFI-update uit die dat fikst, toch? Moet ook aanpasbaar zijn welke keys ie checkt, juist voor dit soort gevallen.

Het komt er vooral op neer dat je moet weten dat wat je installeert veilig is. De fabrikant kan dat nu even niet meer standaard laten checken, dus moet je het zelf doen. Als mensen dat niet kunnen doen, en alleen maar op het knopje kunnen klikken, moeten ze het risico niet nemen (maar wie ben ik om ze dat te vertellen?).

[R4gnax]

Wat stel je dan voor? Dat de halve wereld zijn mobo terugstuurt als er een security issue gevonden is in de firmware? Mogen drivers geen firmware meer bevatten?

Wat dacht je van dezelfde oplossing als bij een FIDO-authenticator:
user attestation.

Gewoon een klein knopje op de achterkant van je mobo dat je tijdens het proces moet indrukken om hardware-matig toestemming te verlenen en de firmware tot de volgende boot te unlocken.

[Xander2]

Dat klinkt goed, de issue is alleen dat secure boot/boot guard juist bedoeld is om lokaal knoeien op hardware niveau onmogelijk te maken, niet om degene ter plaatse te laten bepalen wat erop komt.

Om dat goed te laten werken zal de fabrikant/intel de betrouwbaarheid van de firmware moeten garanderen, dat is de kern van secure boot en dus ook rekening houden met sleutelverlies.

[R4gnax]

Het grootste probleem met het wegvallen van de betrouwbaarheid van de firmware signing keys is niet dat gebruikers niet meer 100% verzekerd zijn van dat wat ze installeren, ook echt van de fabrikant afkomstig is en niet mee gerommeld is.
Het grootste probleem met het wegvallen van de betrouwbaarheid van die signing keys, is dat als malware administrator permisssies weet te verkrijgen, het zonder verdere prompt die tussenbeide zou komen, malicious firmware op het moederbord zou kunnen zetten.

Door altijd te vereisen dat de eindgebruiker bewust een firmware-flash knopje indrukt op de achterzijde v/h mobo, maak je het onmogelijk dat dat covert gebeurt. Daarmee haal je 99% van de ontvankelijkheid van het aanvalsoppervlak weg; en daarmee maak je het in één klap totaal onattractief voor criminele groepen om te pogen het wijdverbreid in te zetten.

[Xander2]

Het grootste probleem met het wegvallen van de betrouwbaarheid van de firmware signing keys is niet dat gebruikers niet meer 100% verzekerd zijn van dat wat ze installeren, ook echt van de fabrikant afkomstig is en niet mee gerommeld is.

Dat is exact het doel van secure boot/bootguard, verzekeren dat firmware van een betrouwbare partij komt via hardware signing, een trusted root van hardware tot laden van (signed) software.

Het is juist niet bedoeld om de gebruiker 100% grip te geven op wat er op het bord komt want dan kan "ik" niet veilig remote plaatsen, er kan dan altijd lokaal gesideload worden maar ook remote via kernelpatches.

Een firmware-knop verkleint het aanvalsoppervlak maar de issue is hier sleutelbeheer; als een private key niet ingetrokken kan worden na een lek is secure boot nutteloos.

[R4gnax]

De firmware signing keys worden naar alle waarschijnlijkheid gebruikt om te voorkomen dat niet-authentieke firmware op het moederbord geinstalleerd kan worden. En hebben niets met Secure boot te maken.

De keys die Secure boot gebruikt, zijn er om te controleren dat de bootloader - niet de UEFI firmware - vertrouwd is. Secure boot is namelijk bedoeld om te zorgen dat wat er in de kernel v/h OS geladen wordt, vertrouwd kan worden.

Die keys kunnen overigens gewoon gerevoked worden. Dat is een vereist onderdeel van de UEFI specificatie als je Secure boot wilt aanbieden. Verder is een onderdeel van Secure boot dat je de key storage in de zgn 'custom mode' kunt zetten en je eigen toegestane keys kunt ondersteunen. Het 'sideloaden' van je eigen bootloader is een officiële feature. Microsoft stond ten tijde van de release van Windows 8 toen ze met Secure boot begonnen, officiële OEMs die voorgeinstalleerde machines leverden niet eens toe om machines te leveren die custom mode niet ondersteunde. (Tot dusver dus het broodje aap verhaal uit de open-source hoek dat Microsoft het grote kwaad is dat andere partijen buiten probeerde te slutien.)

[Reactie gewijzigd door R4gnax op 23 juli 2024 09:06]

[HollowGamer]

Waarom hoeven AMD gebruikers zich geen zorgen te maken? Die hebben net zozeer BIOS upgrades nodig, zie bijvoorbeeld het probleem met hun AM5-socket waarbij burn-in problemen waren (als het goed is opgelost).

Tevens bevatten BIOS upgrades tegenwoordig meer dan enkel 'wat fixes'. Security updates bijvoorbeeld, of wat dacht je van nieuwe features en/of betere stabiliteit met bepaalde RAM modules?

Verder zijn er tegenwoordig recovery utilities en zijn er moederborden die een dual bios hebben. Is het altijd nog een risico? Ja, maar niet meer zo groot als vroeger. De drempel is ook lager, juist doordat het via het OS zelf kan en niet meer via een floppy of USB, met corruptie als gevolg.

Verder snap ik helemaal niets van het moderatie systeem hier op T.net. heb het al vaker aangegeven, ik vind bijvoorbeeld niet dat je reactie een +2 verdient, er zijn er die meer informatie geven en die worden gedownvote. Jullie moeten echt eens gaan kijken naar het comment systeem, want alle interessante berichten staan veel verder onderaan (wat nogal gek is voor een mod systeem).

[EnigmA-X]

De gelekte keys zijn van Intel Boot Guard.
Dat is een systeem van Intel en alleen compatible met Intel CPU's.

Bij AMD heet dit Platform Secure Boot (PSB) of AMD Pro security.

Update: met iets meer nuance, zie mijn bericht hieronder.

[Reactie gewijzigd door EnigmA-X op 23 juli 2024 09:06]

[R4gnax]

De gelekte keys zijn van Intel Boot Guard.
Dat is een systeem van Intel en alleen compatible met Intel CPU's.

Er zijn keys gelekt voor Intel Boot Guard die naar schatting 116 producten van MSI compromiteren, alsmede van andere partijen. EN er zijn firmware-signing keys gelekt die naar schatting 57 MSI producten compromiteren.

We weten vziw niet of dat ook firmware-signing keys betreft voor AMD producten; of enkel de Intel-zijde. Als iemand toevallig ergens een concrete lijst heeft van de getroffenen product type nummers, dan zullen we het snel genoeg weten...

[Reactie gewijzigd door R4gnax op 23 juli 2024 09:06]

[EnigmA-X]

Je hebt gelijk. Mijn reactie was meer in de scope van het hele BIOS gebeuren, maar we weten idd niet om welke MSI producten het exact gaat en waar die signing-keys voor gebruikt worden.

Er is overigens wel een lijst gepubliceerd:
https://github.com/binarl...MSI/MsiImpactedDevices.md

[pmeter]

Kunnen zulke bios updates alleen van een bootable medium worden gestart, waarbij je dus bewust enkele stappen moet doorlopen? Of kan een kwaadwillende een biosupdate vermommen als een Windowsprogramma dat je ergens download waardoor je misschien zelfs je bios update zonder dat door te hebben?

[mjz2cool]

Dat laatste. Firmware updates kunnen vanuit het OS worden geïnstalleerd.

[uiltje]

Dat is nogal een generieke white paper, en als je denkt dat je gesignde content controleert met een private sleutel ipv een publieke sleutel dan heb je het zelf nog niet helemaal gesnapt. Ik wil wel eens weten waarom je denkt dat AMD update & boot process anders verloopt.

[fevenhuis]

De oplossing hiervoor is dus verfieer (trust but verify) of firmware die u wilt installeren echt van de hardware maker vandaan komt.

De mogelijkheid dat er een sleutel ergens in wereld van uw huisdeur is gestolen wil nog niet zeggen dat er bij u ingebroken gaat worden.

Er zijn dus nog veel meer factoren voordat dit tot concreet misbruik leid.

Almetal is het altijd een flinke klap voor hardware fabrikanten als hun sleutels gestolen worden, maar het gaat hier nog steeds maar over een zeer beperkt aanbod van producten.

DON'T PANIC! DON'T PANIC! DON'T PANIC!

Deze zaken gebeuren regelmatig en in een wereld die inmiddels bijna als een mesh netwerk functioneerd betekend dit dat alles ook open staat voor gewilde en ongewilde toegang.

[Verwijderd]

Door Kuusje:

[...] AMD CPU gebruikers hoeven zich geen zorgen te maken.

Helaas is de AMD firmware-TPM kraakbaar, zie https://arxiv.org/abs/2304.14717 (bron (Duitstalig)).

[FreezeXJ]

TPM is weer iets anders, dat gaat om hoe je UEFI zelf dingen kan bijhouden voor je OS, of voor jou, en zich kan identificeren. Een stukje dat ik niet in mijn computer wil, zeg maar. Die gaat namelijk even bepalen dat ie niet meer opstart als ik 4x een nieuwe videokaart inbouw, want nieuw systeem, dus opnieuw betalen voor je licenties graag! Hoe kapotter dat systeem is, hoe beter, misschien dwingen politici ze om het af te schaffen als we op afstand hun computer kunnen faken, zonder dat ze snappen hoe.

In dit artikel gaat het om hoe je computer uberhaupt alleen opstart als er een Intel in zit, dankzij BootGuard. En da's nu te spoofen.

[The Zep Man]

Wanneer een moederbord de fabriek verlaat, krijgt het (ergens ver weg verstopt) een private public key mee. Nu de private keys gelekt zijn, (...)

Fixed.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:06]

[CAPSLOCK2000]

Securitybedrijf Binarly claimt dat hackers die in april een cyberaanval hebben uitgevoerd op de systemen
van MSI zowel private keys als Intel BootGuard hebben buitgemaakt

Hoe kan dat nou weer? Waarom zaten die keys niet in een hardware security module? Een bedrijf zo groot als MSI moet toch weten dat het niet verstandig is je private keys in software te bewaren. Dat is best wel onhandig maar je zal toch moeten als er zo ontzettend veel systemen afhankelijk zijn van zo'n sleutel. Mijn vragen waren dan ook een beetje retorisch van aard, want ik kan talloze redenen bedenken waarom het verschrikkelijk is om je keys alleen in hardware te hebben. Bijvoorbeeld omdat een ander goed IT-principe is dat je backups moet hebben van al data en dan is het makkelijk om te denken dat je ook je private keys moet backuppen.

Pragmatisch gezien snap ik dat maar het is eigenlijk niet compatible met het security model dat er van uit gaat dat private keys ook echt altijd prive zijn en eigenlijk niet kunnen uitlekken en/of dat gelekte sleutels onmiddelijk worden ingetrokken. Dat intrekken van keys is overigens best lastig in praktijk en om te controleren of een key is ingetrokken heb je internet nodig en dat zal er niet altijd zijn.

Ook als er wel internet is dan is het intrekken van zo'n sleutel nog niet zo makkelijk omdat het betekent dat apparatuur van miljoenen mensen onbruikbaar wordt omdat de handtekening onder driver ongeldig is verklaard. Dat zullen die klanten niet leuk vinden.

Het is ook niet moeilijk om te zien hoe riskant het is om "alles" af te laten hangen van een enkele geheime sleutel die je niet mag backuppen.

Gelukkig is er een betrekkelijk eenvoudige oplossing voor zowel het backup- als het intrekprobleem: meerdere private keys. In plaats van één unieke key maak je meerdere unieke keys aan en je ondertekent je drivers met alle keys. Als er één key uitlekt dan kun je die gewoon intrekken zolang omdat die andere keys blijven werken. Technisch gezien kan dat prima, daar zijn hooguit kleine aanpassingen voor nodig want werken met meerdere keys is iets wat die systemen op zich al kunnen.

Als je toch al zo'n systeem hebt dan wordt het ook haalbaar om drivers door meerdere partijen te laten signen. Bijvoorbeeld door zowel MSI als door Microsoft als door een onafhankelijke derde partij die gespecialiseerd is in software security. Als één van die partijen zou wegvallen dan kun je vertrouwen op de handtekening van andere partijen. Nog mooier zou het zijn als we onze clients gaan instrueren dat één handtekening niet genoeg is, maar je bijvoorbeeld minimaal handtekeningen van twee onafhankelijke partijen wil zien voor je een driver accepteert.

Als een crimineel zo'n sleutel te pakken krijgt dan is het nog steeds niet genoeg om zelf drivers te signen. Die zouden immers maar één vertrouwde handtekening hebben. Dan moet zo'n crimineel al sleutels stelen van verschillende partijen en gebruiken voor iemand ontdekt dat zo'n sleutel is gestolen.

Ook mooi aan zo'n systeem is dat je niet langer blind vertrouwen hoeft te hebben in alle hardware fabrikanten (en Microsoft en nog wat andere grote bedrijven) maar ook informatie uit andere bronnen kan gebruiken. Zo zou de overheid een dienst kunnen opzetten die zelf drivers op veiligheid controleert en de handtekeningen publiceert. De overheid zou dan een regel maken dat overheidscomputers alleen met goedgekeurde drivers mogen werken om spionage te voorkomen.

Anderen (consumenten) kunnen daar vrijwillig gebruik van maken. Op het eerst gezicht klinkt het misschien eng om je drivers door de overheid te laten keuren maar omdat er in mijn voorstel altijd handtekeningen van meerdere partijen nodig zijn kan een foute overheid daar geen misbruik van maken door drivers te veranderen. Sterker nog, ik zou er dan voor kiezen om alleen drivers te gebruiken die zijn goedgekeurd door de Nederlandse regering én de Russische én de Chinese én de Amerikaanse. Als die vier overheden het eens zijn dat een driver te vertrouwen is dan geloof ik het ook wel. Geen van die partijen zou ik blind willen vertrouwen maar je moet wel heel paranoide zijn om te geloven dat al die partijen samen werken aan een hack. Het gebrek aan onderling vertrouwen houdt ze eerlijk.

Owja, hoe die controle moet werken mogen de landen zelf uitzoeken en dat is nog best lastig, maar dat probleem heb je sowieso dus daar wil ik nu even niet op in gaan. Alles beter dan niks.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 09:06]

[closefuture]

Gelukkig is er een betrekkelijk eenvoudige oplossing voor zowel het backup- als het intrekprobleem: meerdere private keys. In plaats van één unieke key maak je meerdere unieke keys aan en je ondertekent je drivers met alle keys.

Je zou ook een certificaat ongeldig kunnen verklaren vanaf een bepaalde datum. Dus bijvoorbeeld de datum nadat je weet dat het key pair van het certificaat gecompromitteerd was. Dan blijven oude gesigneerde drivers werken. Volgens mij is dit ook al eerder gedaan met het uitlekken van bepaalde secure boot keys.

Hoe kan dat nou weer? Waarom zaten die keys niet in een hardware security module?

Het is sowieso al raar dat Intel niet vereist dat je dat doet. Of dat Intel de keys niet gewoon uitlevert op een HSM.

Dat intrekken van keys is overigens best lastig in praktijk en om te controleren of een key is ingetrokken heb je internet nodig en dat zal er niet altijd zijn.

Opzich is het vrij makkelijk omdat de update maar eenmalig gedaan hoeft te worden waarin een nieuwe "shitlist" zit met daarop de ingetrokken keys. Echter zullen ze bang zijn dat brakke implementaties misschien er raar op kunnen reageren. Beetje hetzelfde als apparaten met firmware updates waarbij downgrades verhinderd kunnen worden door het opblazen van een efuse. Als er iets misgaat zal de recall je een hoop geld kosten. Dus in de praktijk is iedereen huiverig om die uit te voeren.

[Reactie gewijzigd door closefuture op 23 juli 2024 09:06]

[DavidAxe]

Je zou ook een certificaat ongeldig kunnen verklaren vanaf een bepaalde datum. Dus bijvoorbeeld de datum nadat je weet dat het key pair van het certificaat gecompromitteerd was.

Is het dan niet mogelijk om datum even een jaartje terug te zetten bij het signeren van malware?
Indien het signeren standalone plaats kan vinden, dan is dat niet te voorkomen.

[Reactie gewijzigd door DavidAxe op 23 juli 2024 09:06]

[closefuture]

Is het dan niet mogelijk om datum even een jaartje terug te zetten bij het signeren van malware?

Nee, voor timestamping word bij code signing gebruik gemaakt van een losse timestamping service van een derde partij (dit alles is ook weer cryptografisch geborgt [1]). De controle op expiry date van het geen ge-signed is vind plaats op of het code signing certificaat niet verlopen was op de tijd van signing van de code. Anders zou je ook continue alles opnieuw moeten signing (aangezien je code signing certificaat ook maar een paar jaar geldig is).

Anders zou je als de keys van een verlopen code signing certificaat ooit alsnog uit zouden lekken deze ook kunnen gebruiken. Maar dat kan je niet.

Offtopic; Beetje raar dat mijn bovenstaande reply als "Irrelevant" gemod word...

[1] https://en.wikipedia.org/wiki/Trusted_timestamping

[Reactie gewijzigd door closefuture op 23 juli 2024 09:06]

[Kabouterplop01]

Check, dat was exact wat ik bedoelde. Zo lijkt het sterk op een certificate chain, (maar dan met wat anders dan intermediate certs) of op een pgp key signing party. Werken met meerdere (trusted)keys.

[Reactie gewijzigd door Kabouterplop01 op 23 juli 2024 09:06]

[kodak]

Het doel van een root vertrouwen is dat je het wel of niet geheel vertouwd op inhoud en aantal, niet slechts een beetje op aantal of inhoud.

MSI, of welke vertrouwde root dan ook, heeft niet voor niets alleen verantwoordelijkheid: omdat daarmee duidelijk is dat ze zelf grote verantwoordelijkheid dragen als het bij hun mis is. Juist ook om te zorgen dat een of meer partijen na samen garant willen staan niet gaan slacken omdat anderen de gevolgen wel op zouden vangen. Dat verdelen versimpelt vooral het nog minder hoeven doen aan voorkomen en oplossen, terwijl dat comstant al een probleem lijkt als een root eigenlijk al geen vertrouwen meer heeft.

Ook om schade te beperken is het geen redelijke uitgangspunt voor de tussenpartijen of eindgebruikers. Als je het eerst gaat accepteren dat alle ondertekeningen te vertrouwen moeten zijn, om het bij een te verwachten probleem dan af te zwakken naar een stelling dat er best één niet te vertouwen mag zijn, dan lijkt dat op afzwakken omdat je geen zin in de negatieve gevolgen hebt van strenge eisen. De eisen zijn niet voor niets zo streng. Het is eerder logisch om te zorgen dat je je daar dan aan aanpast door een bedrijf als MSI en je leveranciers verantwoordelijk te houden dat ze niet te vertrouwen zijn en je laten bungelen met de risico's.

Het lijkt me ook niet redelijk om wel vanaf het begin te doen alsof niet alle ondertekeningen belangrijk zijn, ook al voldoen ze aan stenge voorwaarden. Ook dan zijn die strenge voorwaarden er kennelijk meer voor het gemak dan als belangrijke minimale grens.

Je zult toch ergens een grens horen te stellen die niet eerst om inhoud gaat en daarna om aantal. Doe je dat wel, dan is de simpelheid dat het niet om de strenge eisen te doen is, maar om het afzwakken van de huidige voorwaarden.

[Deux]

Niet te begrijpen van zo'n groot bedrijf. Schande.

[latka]

Als mobo fabrikanten het beveilingsniveau van banken zouden volgen dan wordt je mobo 2x zo duur. Dan gaan ze dus failliet. Het is met hardware altijd een race to the bottom.

[TheVivaldi]

Want dit lek is goedkoper dan vooraf goede beveiliging? Toegegeven dat je niet 100% kunt weten of het gaat lekken, maar je moet altijd rekening houden met dit soort dingen. En dit lek oplossen lijkt me ook niet goedkoop.

[latka]

Het punt is dat goede beveiliging vrijwel niet te doen is zonder dat je het hele proces onder de loep neemt en alle stappen beveiligd. Er wordt gesuggereerd dat een HSM het oplost. Maar dan moet je die koppelen aan je build-omgeving (of CI server). Heb je dat gedaan dan moet je zorgen dat er alleen software op de CI server staat die van een betrouwbare bron komt. Dat is al lastig, maar stel we zorgen ervoor dat er alleen gepulled wordt uit een lokale git-server (uiteraard pullen met ssh en niet met http). De CI server mag alleen scripts draaien die gecontroleerd zijn om te voorkomen dat er data wordt gepulled uit een verkeerde repo. De code in de repo mag alleen door geauthoriseerde ontwikkelaars geschreven zijn. Dus alle commits moeten signed zijn of moeten gepushed zijn via ssh. De ontwikkelstations moeten ook allemaal gecontroleerd zijn en niet geinfecteerd. Voor thuiswerkers moeten we dan nog wel even kijken hoe we het regelen. Er zit vaak ook 3rd party code in een UEFI (bijv. Agesi of de Intel ME firmware). Die blobs moet je ook alleen betrekken uit een betrouwbare bron (dus niet downloaden van de leveranciers website of FTP'en ofzo). Als je de hele supply chain naloopt en veilig wilt maken dan is dat best complex en niet beperkt tot je eigen toko. Combineer dat met mensen willen niet te veel voor hardware betalen en je krijgt Diginotar achtige praktijken (google voor het geval je die vergeten bent).

[FreezeXJ]

Lijkt me prima om je proces af en toe eens onder de loep te nemen, en cryptographic vaults op je CI-server zijn sowieso al een beter idee dan lekker alles plaintext rondschuiven. Vergeet niet dat je CI/CD-servers gewoon productie-kritisch zijn, en ook zo moeten worden behandeld.

[Plofkotje]

Ja, maar een YubiHSM 2 om dit beveiligd te doen kost ongeveer 800 euro. Dat zijn de kosten dus niet. Dan was dit niet gebeurd.

Uiteindelijk wordt je mobo duurder van dit lek dan dat iemand een YubiHSM 2 gekocht had en de key daarin gezet had

[latka]

Hardware zal hier het probleem niet zijn. Awareness en procedures. Wellicht werkt het als intel de keys alleen via een hsm verspreid, maar vermoedelijk mailen zie die dingen gewoon.

[Gamebuster]

Moederborden zijn al 2x zo duur!

[Frame164]

Slecht argument om je beveiliging dan maar niet op orde te hebben. Dan kan een bank ook wel wat losser gaan werken en tegen bodemtarieven bancaire diensten gaan aanbieden. Blijkbaar mag dat dan...

Maar buiten dat: security hoeft niet duurder te zijn als je security-by-design toepast. Maar het is te vaak nog iets wat achteraf gedaan wordt. En dan is het duur.

[Reactie gewijzigd door Frame164 op 23 juli 2024 09:06]

[latka]

Nee, dan verliezen ze hun banklicentie en daarbij: vertrouwen komt te voet en gaat te paard. Iig. bij banken. Ik denk dat geen consument msi laat liggen door dit voorval.

[TheVivaldi]

Het is sowieso moeilijk voor mensen om vertrouwen te verliezen bij een ingeburgerd merk. Hoeveel mensen zijn Intel gaan wantrouwen na Spectre, Meltdown, etc.? En hoeveel mensen zijn Volkswagen en Mitsubishi gaan wantrouwen nadat bekend was dat ze hadden gesjoemeld met de uitstootcijfers?

[blorf]

Ik weet niet, het lijkt me allemaal overdreven. Wat wordt door Bootguard uitgesloten wat user-level software niet kan? Volgens mij gaat dit alleen maar over fysieke toegang. Iemand die met de computer rommelt als niemand kijkt...

[Reactie gewijzigd door blorf op 23 juli 2024 09:06]

[R4gnax]

Wat wordt door Bootguard uitgesloten wat user-level software niet kan?

Basaal gesteld: Bootguard is SecureBoot voor de UEFI firmware zelf.
Bootguard zit op extreem laag niveau in de Intel Management Engine en controleert de cryptografische validiteit van de UEFI firmware zelf, alvorens deze mag starten. De keys en instellingen van dit gedrag worden middels programmable fuses afgesteld. Dat moet met extreem directe hardware toegang gebeuren en is een proces dat op meer manieren dan één, niet voor herhaling vatbaar is.

Bootguard is/was Intel's antwoord op UEFI firmware malware binnen zakelijke hardware-parken, waar je liever hebt dat een machine niet meer boot - dan dat deze een gecompromiteerde firmware boot.

[blorf]

Wat volgens mij niet meer kan: iemand die fysiek aanwezig is en ongemerkt de firmware overflasht en ook de hash/fingerprint van het aangepaste bestand bij de security-afdeling update zodat het ermee strookt. Eenmaal opgestart is daar niks meer van adresseerbaar vanuit het OS.
Ze zouden ook een partij foute hardware direct uit de verpakking kunnen hebben neergezet, maar dan valt er meteen iets op op het moment dat iemand verzint om de aanwezige firmware tegen die van de fabrikant aan te houden.

[Reactie gewijzigd door blorf op 23 juli 2024 09:06]

[uiltje]

Als je veiligheid van meerdere sleutels afhangt dan moet je wel al die sleutels heterogeen opslaan. Als ze op een homogene manier zijn beveiligd dan is de toegang tot de ene sleutel even makkelijk als toegang tot de andere. HSM's gebruiken is een makkelijkere en waarschijnlijk betere keus.

[kaas-schaaf]

... maar je zal toch moeten als er zo ontzettend veel systemen afhankelijk zijn van zo'n sleutel.

Iedere grote HSM boer bied nethsm's aan. Gewoon sleutel wegstoppen in een HSM met een brug naar een server applicatie en pkcs11 module op de client, alleen toegang is dan wel iets flexibeler (lees: makkelijker) dus je moet dan de toegang beter afschermen.

edit: er zijn veel betere oplossingen (enkele al aangegeven in andere posts) maar bij veel van dit spul is legacy de state-of-the-art, maar zelfs dan zijn er redelijke oplossingen.

[Reactie gewijzigd door kaas-schaaf op 23 juli 2024 09:06]

[Nappie]

Bijvoorbeeld omdat een ander goed IT-principe is dat je backups moet hebben van al data en dan is het makkelijk om te denken dat je ook je private keys moet backuppen.

Als je een HSM gebruikt, dan kunnen backups geregeld worden via een andere HSM. Ik heb ooit in wat meer detail naar de HSMs van Thales Group (toen nog SafeNet) gekeken. En die hebben dat soort mogelijkheden. Hun concurrenten waarschijnlijk ook.
Backups zijn dus geen reden om geen HSM te gebruiken. Dan blijft natuurlijk staan dat het wel echt lastiger werkt met goede HSMs, maar dat hoort erbij: ik zou mijn huis ook makkelijker in kunnen als er geen slot op de deur zat, maar ik vind het toch fijn om een slot te hebben.

[Kabouterplop01]

En zijn de keys al revoked?

[Kees]

Ik weet niet of dat zin heeft, de check of een certificaat revoked is zal wel niet tijdens de boot gedaan worden, en als je de check wel doet zonder dat je verplicht moet updaten dan boot het systeem niet meer.

Dus moet je nieuwe firmware instaleren, maar die kun je eigenlijk niet vertrouwen, want wie zegt dat de update die geinstalleert word niet gesigned is met een key die door de hackers is buitgemaakt? Vanuit de 'chip' gezien moet je maar hopen dat het de gebruiker is die een update aan het instaleren is.

De enige mogelijkheid die er is is om nieuwe producten te voorzien van nieuwe sleutels en hopen dat die niet opnieuw gelekt worden. Bestaande producten zul je moeten updaten, als die mogelijkheid er al is en men firmware updates instaleert en het systeem nog niet voorzien is van een malafide gesigneerde firmware.

[Reactie gewijzigd door Kees op 23 juli 2024 09:06]

[Kabouterplop01]

Dit is dan inderdaad desastreus. En ook een flaw. Er moet dan een mechanisme zijn wat er voor zorgt dat mocht er ergens een "certificate error" zijn deze altijd vervangen moet kunnen worden. Bijvoorbeeld door een backup key, die ergens in een kluis wordt bewaard. Zodat het revoken voor zulke situaties wél werkt. Ik snap dat er dan inderdaad een update moet zijn.
(al is het alleen om dezelfde driver gesigneerd met de nieuwe key, op te halen)

Al met al kan ik een oplossing bedenken, maar dat het uiterst complex is daar valt niet over te twisten.
Veel succes voor MSI en Intel.

[bwerg]

En wat doe je als de key in die kluis uitlekt? Bovendien, als die backups key op dezelfde manier gebruikt wordt heeft MSI ook toegang nodig tot die key. Dat lost dus niks op...

Een private key die zo fundamenteel in hardware over de hele wereld wordt ingebakken had dus al die key moeten zijn die in die kluis ligt. Spreekwoordelijk, want hij moet toch die kluis uit als je iets wil signeren.

Ik snap dan ook niet dat een private key van Intel schijnbaar bij alle hardware-bakkers rondslingert. Laat ze hun firmware maar naar Intel opsturen om gesigneerd te worden...

[Reactie gewijzigd door bwerg op 23 juli 2024 09:06]

[Xander2]

Ik snap dan ook niet dat een private key van Intel schijnbaar bij alle hardware-bakkers rondslingert. Laat ze hun firmware maar naar Intel opsturen om gesigneerd te worden...

Geen enkele hardware fabrikant zal dat accepteren, dat betekent dat Intel je productrelease en -datum bepaalt...

[field33P]

Intel heeft zeker in het verleden maar tegenwoordig nog steeds genoeg gewicht om met zoiets weg te kunnen komen. AMD misschien wat minder.

[Xander2]

Nee, dat gaat echt niet gebeuren want dat is een oneigenlijk concurrentievoordeel (Intel levert ook moederborden).

Wat @bwerg voorstelt is ook geen oplossing, los van lekken is er uiteindelijk geen garantie dat het gebruikte algoritme en sleutel veilig zijn op termijn..

[field33P]

Microsoft is ook nooit aangeklaagd voor WHQL. Daarnaast stelt de moederbordenbusiness van Intel sinds 2015 vrij weinig meer voor.

[RJG-223]

Er moet dan een mechanisme zijn wat er voor zorgt dat mocht er ergens een "certificate error" zijn deze altijd vervangen moet kunnen worden

Ik denk dat dat misschien wel onmogelijk te realiseren is. Je kunt niet verwachten dat alle computers voor het opstarten een online controle van de sleutels kunnen doen. Dus moet de sleutel in de computer zitten, en moet de controle offline plaatsvinden. En dan kan de sleutel dus gecompromitteerd zijn zonder dat de computer daar bij het opstarten weet van heeft.

Daarnaast kan de BIOS ook gecompromitteerd zijn, dus moet de code die de eventuele online controle doet in de hardware zelf zitten. In de CPU, of in de chipset. En die code moet dan dus in staat zijn om de hardware te initialiseren, en een internet-verbinding te leggen om die sleutel te controleren. Dat is precies wat de BIOS doet, dus eigenlijk heb je de BIOS nodig, maar die is dus nog niet beschikbaar, want je weet nog niet of je die kunt vertrouwen.

En als er dan een 'certificate error' is. hoe weet je dan dat de vervangende code te vertrouwen is ? Je certificaat is niet geldig, dus die kun je niet gebruiken om te controleren of het nieuwe certificaat geldig is.

Misschien is het op te lossen met meerdere sleutels, maar dan moet je alle procedures zeer zorgvuldig ontwerpen, en grote kans dat je toch ergens tegen een theoretisch of een praktisch probleem aanloopt. Het is makkelijk roepen dat het 'opgelost moet worden', maar dat is vergelijkbaar met de politicus die roept dat de wetenschappers gewoon moeten zorgen voor een veilige vorm van encryptie die wél door de politie te decoderen is als er sprake is van een misdrijf...

[Kabouterplop01]

Heel goede punten. Ik was maar wat aan het brainstormen. Als ik slim genoeg was om dit te fiksen dan had ik een andere functie gehad

[meowmofo]

Wat denk je dat er gebeurd als je keys revoked van bestaande firmware, drivers, etc. zonder hier eerst updates voor te verschaffen?

[Blokker_1999]

Niets, op voorwaarde dat ze timestamped zijn. Op die manier is het mogelijk om de keys te blijven vertrouwen tot op het moment dat de revocation ingaat.

Er zijn dus mechanismen ingebouwd om alles goed te laten verlopen, maar dan moet je ook wel alles goed doen. Ik mag hopen dat MSI die keys al lang teruggetrokken heeft.

[RJG-223]

Niets, op voorwaarde dat ze timestamped zijn. Op die manier is het mogelijk om de keys te blijven vertrouwen tot op het moment dat de revocation ingaat.

Het lijkt me dat als een sleutel gecompromitteerd is, de aanvaller nieuwe certificaten kan genereren met een datum in het verleden. Dus vanaf het moment dat de revocation ingaat is dan geen enkel stuk software dat met die key gecertificeerd is meer te vertrouwen.

Als we kijken naar BootGuard: de sleutel daarvan is zo te zien niet te vervangen. Dus revocation heeft ook geen zin. Het lijkt er dus op dat alle computers die die BootGuard sleutels gebruiken nu permanent kwetsbaar zijn voor ongeautoriseerd vervangen van de BIOS...

Er zijn dus mechanismen ingebouwd om alles goed te laten verlopen, maar dan moet je ook wel alles goed doen. Ik mag hopen dat MSI die keys al lang teruggetrokken heeft.

Dit klopt voor het normale gebruik van sleutels, waarbij de sotfware in staat is om een online sleutel-controle te doen, en waarbij de sleutels ook makkelijk vervangen kunnen worden. Als het echter om sleutels gaat die bij het boot-proces betrokken zijn, dan ligt het niet zo simpel, en dan bestaan dat soort mechanismen misschien wel helemaal niet (?).

Bedrijven die computers gebruiken die afhankelijk zijn van die sleutels, zijn nu dus permanent kwetsbaar, of misschien kan een BIOS-update het probleem verhelpen, maar dan moet dat bedrijf heel goed controleren dat de BIOS-update ook te vertrouwen is, want de sleutel is niet meer voldoende. Ook moeten ze dan hopen dat een aanvaller ze niet is voor geweest met de BIOS-update...

[sprankel]

Daar heb je trusted timestamping voor, iets waar ik vanuit ga dat het in dit geval gebruikt is. Kort samengevat komt het er op neer dat de timestamp van een 3de partij komt dus tenzij je EN de private key EN de 3de partij hebt gaat het niet lukken.

https://en.wikipedia.org/wiki/Trusted_timestamping

[RJG-223]

iets waar ik vanuit ga dat het in dit geval gebruikt is

Dat lijkt me een nogal optimistische aanname. Nog afgezien van het feit dat de hardware niet eerst een internetverbinding op kan zetten om een revocation list te raadplegen, zodat die sowieso niet kan bepalen of een bepaalde sleutel 'revoked' is, laat staan per wanneer dat was.

En nogmaals (maar in andere woorden): alle veiligheid staat of valt met een 'root of trust'. Het normale gebruik van sleutels en dergelijke in software (in het OS dus), en dus ook van trusted timestamps, gaat uit van een systeem dat te vertrouwen is. Dat vertrouwen begin strikt genomen bij aanvang van het boot-proces, en zit in de hardware (als firmware of zo). Bijvoorbeeld met zo'n BootGuard sleutel. Dat aanvangsvertrouwen kun je niet extern valideren, want daarvoor is ook weer vertrouwen nodig, en dat was er nu juist nog niet.

Als het aanvangsvertrouwen wegvalt, dan staat elk volgend vertrouwen op drijfzand. Ook het vertrouwen op de correctheid van een trusted timestamp.

[Kabouterplop01]

Dat je geen nieuwe met de zelfde keys kunt installeren waarmee je de boel behoorlijk veilig hebt.
Of doet je machine het dan gewoon niet meer?
edit: typo

[Reactie gewijzigd door Kabouterplop01 op 23 juli 2024 09:06]

[CH4OS]

De keys worden o.a. gebruikt bij het opstarten, zou je hals over kop de key intrekken, dan brick je de nodige computers inderdaad, zeker als ze geen alternatief nog 'weten'.

[Reactie gewijzigd door CH4OS op 23 juli 2024 09:06]

[aadje93]

Alsof een pc niet op wil starten als er geen netwerk is om de key te verifiëren....

[CH4OS]

Componenten als netwerk worden _na_ het starten van de firmware pas geïnitieerd.

[kodak]

Dat is precies waarom de fabrikanten en gebruikers dat updaten dus op orde horen te hebben. Je kan niet voor een systeem kiezen waarbij het kunnen lekken en moeten intrekken van private keys de basis van het vertrouwen is, maar dan handelen alsof je daar geen rekening mee hoeft te houden.

Het is onduidelijk wie in dit geval nu wat wist en wanneer, maar ik heb niet de indruk dat de gekozen manier van updaten gemaakt is om te voorkomen dat systemen last van criminelen hebben.

[bwerg]

Gerevoked uit alle firmware van alle PC'S met een Intel-CPU? Nee, ik denk het niet...

Nog los van dat revoken er dus voor zorgt dat heel veel PC'S niet meer booten.

[Reactie gewijzigd door bwerg op 23 juli 2024 09:06]

[RJG-223]

Nog los van dat revoken er dus voor zorgt dat heel veel PC'S niet meer booten.

Dat niet. Want de PC kan niet weten dat een sleutel ge-revoke-d is. Daarvoor heeft die namelijk een internetverbinding nodig, en daarvoor moet ie eerst booten... Dat nog afgezien van het feit dat er ook veel computers zijn die überhaupt geen internetverbinding hebben uit veiligheidsoverwegingen...

[bwerg]

Het is maar hoe je het ziet, je zou ook kunnen stellen dat zulke keys gewoon effectief nauwelijks te revoken zijn. Intel raadt namelijk niet aan om regelmatig je BIOS te updaten, dus dan is er effectief geen mechanisme voor revoken.

[Kabouterplop01]

ja dan is dat inderdaad niet de manier. Als machines daardoor niet meer booten.
Maar goed, dan is dit dus een flaw in het mechanisme. (uiteindelijk)

[CH4OS]

Ik denk dat dit alléén kan middels een firmware update. Er zit volgens mij geen online check op validiteit van de keys.

De oplossing is in elk geval niet zo simpel als even de key ongeldig maken in dit geval.

[Reactie gewijzigd door CH4OS op 23 juli 2024 09:06]

[naaitsab]

Er valt niet zo veel te revoken gezien het een systeem is wat in je UEFI huist en niet iets is als een publiekelijk toegankelijke crypto, zoals SSL. Intel geeft niet zo veel informatie erover, dus de vraag is even in hoeverre je de keys kan updaten met een firmware update. Zonder dat je apparaat gebricked raakt. Of dat dit echt hardcoded keys in de chip zijn.

De keys zijn al vaker uitgelekt, o.a. vanuit Lenovo. Hier wat leeswerk voor de geïnteresseerde: binarly.io

[R4gnax]

De keys zijn al vaker uitgelekt, o.a. vanuit Lenovo. Hier wat leeswerk voor de geïnteresseerde: binarly.io

Dat waren, bleek later, niet productie-sleutels maar sleutels bedoelt voor testen en debuggen. Staat ook in het artikel wat je aanhaalt.

Dus betekende dat uiteindelijk niet zo veel voor alle hardware die er verbonden aan de grote boze internet-wereld stond te stampen over de hele globe. Alleen wat onhandigheid voor firmware-ontwikkelaars en een kostenpost voor tzt nieuwe ontwikkel-hardware.

Maar als deze keer de echte sleutels, de productie-sleutels, er uit geglipt zijn - dan zijn de rapen nu wel gaar.

[Reactie gewijzigd door R4gnax op 23 juli 2024 09:06]

[Stijnvi]

BleepingComputer kreeg te horen van ransomewaregroep Money Message dat zij achter de aanval zaten. De groep claimde 1,5TB aan data te hebben gestolen en eiste vier miljoen dollar van MSI.

Mocht dit kloppen dan had dit alles dus voorkomen kunnen worden door 4 miljoen dollar te betalen.
Voor een bedrijf als MSI, wat vorig jaar 325 miljoen dollar winst maakte, is dat peanuts.
Ik kan de keuze om niet te betalen dan ook echt niet begrijpen.
Natuurlijk waren de keys dan nog steeds gecompromised geweest, maar dan waren ze zo goed als zeker niet nu al gepubliceerd, en had het dus waarschijnlijk veel minder gevolgen gehad.

[dr.cody]

Zo goed als zeker? Laat me niet lachen. Hoe ongelofelijk naïef. Waar je vanuit kunt gaan bij dit soort volk is dat ze alsnog alles zullen dumpen onder de categorie “Don’t give a f*ck”. 4 miljoen van MSI en dan nog 1 miljoen via de darkweb.
We don’t negotiate with terrorists!

[Stijnvi]

Dit soort grote groepen kunnen dat één keer flikken, waarna niemand ooit meer zal betalen.
Dat is al vaak genoeg besproken.
Grote hackersgroepen houden zich over het algemeen gewoon prima aan hun afspraken, omdat ze weten dat hun hele businessmodel wegvalt als ze dat niet doen.

EDIT:
Nou is 'Money Message' erg nieuw, dus is het inderdaad maar de vraag of ze zich aan de afspraak hadden gehouden.
Maar aan de andere kant weten ze ook dat als nu al uitkomt dat ze zich niet aan de afspraak houden dat ze nooit een reputatie zullen krijgen dat ze 'betrouwbaar' zijn, en bijna niemand dus zal betalen om publicatie te voorkomen.

[Reactie gewijzigd door Stijnvi op 23 juli 2024 09:06]

[field33P]

Bovendien zijn er genoeg bieders buiten MSI om die wel heel erg veel interesse hebben in de mogelijkheid om alle MSI-borden te kunnen compromitteren - en die hebben mogelijk meer dan vier miljoen ervoor over.

[GameNympho]

Je kan het ook eens omdraaien, ik heb jouw gegevens en foto`s en wil daar €10.000 voor, wat ga je doen dan? Betalen werkt deels, want je moet op blauwe ogen vertrouwen, dat men het niet doorverkoopt. Want diegene dan met bruine ogen, melkt je leeg.
Gewoon never nooit betalen en je verlies lijden en voor de volgende keer, beter je software op orde hebben.
Laat dat dan een dure les zijn voor je.

[uiltje]

Erger is dat ze dit kunnen voorkomen door geschat ~200k uit te geven voor goed sleutelbeheer. Als de sleutel in een HSM zou zitten zou het in ieder geval niet gekopieerd kunnen worden (wel misbruikt, maar da's tijdelijk en er valt beter tegen te beveiligen). Ik denk dat je voor zo'n situatie iets van 4 HSM's nodig hebt en natuurlijk mensen die weten hoe je die dingen moet gebruiken. Een FTE en wat organisatie er omheen kom je al ver mee.

[Mushroomician]

Het mooie is dat het nu gelekt is door een partij die het heeft gepubliceerd. En de mens heeft geen flauw idee op dit moment hoe dit op te lossen.

Stel je eens voor dat dit door een overheidsorgaan zoals de NSA of FBI was gestolen en stil gehouden. Zouden we het ooit weten? Keys moeten gewoon in beheer zijn van hardwareeigenaren en nooit van leveranciers. Wil je het uitbesteden? Dan huren met een SLA.

[Reactie gewijzigd door Mushroomician op 23 juli 2024 09:06]

[Sissors]

Hoe had jij dat voor je gezien? Iedereen moet zijn eigen bios firmware schrijven? Deze keys zorgen ervoor dat alleen MSI hun bios'en kan (oké kon) signen, en je moederbord weet dat dat legitieme firmware is. Wat schiet er er dan mee op wanneer jij in je eigen moederbord keys gaat zetten? Wil je hun update niet installeren, dan doe je dat toch niet? Ja je zou hem nodig hebben als je je eigen firmware wil schrijven, maar dat lijkt mij niet echt een standaard iets. En los daarvan zou je dan nog steeds het probleem hebben: Hoe kan MSI nieuwe bios'en signen als ze geen keys ervoor hebben? Gewoon alles unsigned doen? Dan heb je dus precies de huidige situatie.

[Mushroomician]

Een cryptografisch systeem waarvan je de sleutels niet kunt intrekken zonder grootschalige interruptie is geen goed cryptografisch systeem.

Key management is net zo belangrijk, zo niet belangrijker:
Heb je een zwakke sleutel die lekt/breekt, maar wel een goed keymanagement? dan kun je keys roteren.

Heb je een sterke sleutel maar slechte key management? Als je sleutel lekt kun je niets meer.

[Sissors]

En dan moeten de gebruikers zelf de key rotatie gaan doen? Want dat is het punt waar ik op in ging, dat jij wil dat de eigenaar van de hardware de verantwoordelijkheid daarvoor neemt.

[Frame164]

Ik denk eerlijk gezegd dat uitbesteden de voorkeur moet hebben en alleen als je er echt verstand van hebt kan je het in eigen beheer doen. Ik denk niet dat de gemiddelde PC gebruiker (= de hardwareigenaar) dit kan.

[BytePhantomX]

Persoonlijk ga ik er vanuit dat de NSA allang die keys heeft als ze vinden dat ze die nodig hebben. Danwel door MSI te hacken (wat blijkbaar niet zo ingewikkeld was), via een medewerker, of door ze te 'vragen'.

[ari3]

Ben ik nu de enige die vind dat er een jumper op het moederbord moet zitten die het BIOS flashgeheugen read-only maakt? Alleen voor het moment dat je het BIOS wilt updaten heb je reden om het flashgeheugen schrijfbaar te maken, in alle andere gevallen moet het fysiek onmogelijk zijn het BIOS te overschrijven.

[Houtenklaas]

En welk probleem lost dit precies op? Flashen van een bios gaat nog steeds niet vanzelf, daar moet je zelf iets voor in gang zetten. En als je die actie al in gang wilt zetten met "aangepaste firmware", dan zet je die jumper ook wel om. Ten tweede, als jij 500+ pc's in beheer hebt wil je niet 500X een jumper moeten omzetten. 't Is een aardig idee, maar praktisch onbruikbaar.

[ari3]

Je gaat er dan van uit dat iemand dat handmatig een BIOS update start. Het probleem is juist dat, nu de sleutels gelekt zijn, potentieel alle executables (leuk_spelletje.exe) zonder gebruikerinteractie het BIOS kunnen aanpassen. Als het BIOS fysiek niet schrijfbaar is dan is het risico van ongewilde BIOS aanpassingen er niet meer.

Het kunnen flashen van een BIOS vanuit een besturingssysteem was altijd al twijfelachtig. Het beschermingsmechanisme was dat het BIOS image voorzien was van een handtekening. Nu die handtekening niet meer de vertrouwen is, hebben we een probleem.

[Reactie gewijzigd door ari3 op 23 juli 2024 09:06]

[Houtenklaas]

Je slaat de spijker op zijn kop. Als je "leuk_spelletje.exe" opstart die je van een shabby site hebt geplukt, kan er allerhande andere ellende meekomen. Dan hoef je de bios niets eens meer te flashen. Let wel dat het flashen van je bios meerdere keren opstarten betekent, dat gaat echt niet zonder dat jij dat ziet. En als je dan toch al een payload hebt zitten in "leuk_spelletje.exe", dan heb je als hacker je doel waarschijnlijk al bereikt dat jouw PC onderdeel wordt van een botnet.

Het kunnen flashen van een BIOS vanuit een OS is de enige werkbare manier om security patches vlot uit te kunnen rollen. Bij mij in het bedrijf hebben we duizenden kantoormachines. Met een jumper kost dat vele, vele maanden werk om een bios te upgraden. Dan is het middel (jumper) erger dan de kwaal (niet upgraden vanwege kost teveel tijd).

Het toverwoord is hier net als bij phishing mail "gezond verstand". Als een gebruiker een gedownloade executable afsteekt, dan is die bij mij al af. Als je dan geen onraad ruikt als je pc 2 keer opnieuw opstart ben je ook af. En ben je Tinus Nitwit die helemaal niks door heeft, dan heb je niet eens in de gaten dat je een probleem hebt.

MSI moet hoe lastig het ook is, de keys zo snel mogelijk terugtrekken. En voor dit scenario zou er een risk assessment gedaan moeten zijn me daarin de vraag hoe je acteert bij dit soort calamiteiten, wat je mitigerende maatregelen zijn, etcetera. Er pas nu over nadenken is rijkelijk laat ...

[habbekrats]

Nou ik heb hier een redelijk nieuw lenovo laptopje, die installeert een nieuwe bios op de achtergrond. Daarna komt de melding dat de pc opnieuw gestart moet worden.

Een malware bios sloopt de laatste melding er natuurlijk uit, de gebruiker denk dan shit PC weer vast gelopen.

[bwerg]

En als je dan toch al een payload hebt zitten in "leuk_spelletje.exe", dan heb je als hacker je doel waarschijnlijk al bereikt dat jouw PC onderdeel wordt van een botnet

Maar als die .exe je BIOS/firmware niet kan aanpassen ben je er na een herinstallatie in ieder geval vanaf.

Ik ben ook wel benieuwd wat Intel's draaiboek nu zegt. Want als schijnbaar elke moederbordfabrikant toegang heeft tot Intel's private key dan kan dit scenario niet als een verrassing komen.

[Reactie gewijzigd door bwerg op 23 juli 2024 09:06]

[Frame164]

Maar hoe los je dan het probleem op wat Houtenklaas noemt?

[field33P]

Die exe's moeten nog altijd ring0 binnen zien te komen - daar hebben ze ofwel een exploit voor nodig, ofwel een gebruiker die administratorrechten geeft aan het programma zodat die een ring0-driver kan inladen (ziedaar waarom je UAC aan moet laten staan!).

[blinchik]

Dat was vroeger zo. En dat was inderdaad een heel goed idee, misschien iets te technisch voor sommige mensen (je moest de computer openhalen om te updaten, maar het zou evengoed een knopje ergens buiten op de computer kunnen zijn).

Ik herinner me nog dat fabrikanten die jumper hebben afgeschaft. Een paar maand later bracht VLAD (Virus Labs and Distribution, een magazine dat nieuwe techniek over virussen bracht) een virus uit dat automatisch de BIOS kon infecteren.

Edit: ik denk dat het de deze was

[Reactie gewijzigd door blinchik op 23 juli 2024 09:06]

[Kabouterplop01]

Helemaal eens, ook met onderstaande. Als er geen verificatie mogelijk is dan mag het BIOS nooit schrijfbaar zijn. Overigens zou dat ook een prima optie zijn voor bijv een SSD, RO maken met een jumper. Voor bijv kritische systemen zeer interessant.

[vinx77]

Is de detector in de gelinkte Twitter-thread wel veilig? Ze hebben na de scan je IP, naam en email.

[oef!]

In principe kunnen ze het IP adres van je internetprovider zien. Dat zal praktisch nooit het IP adres van de getroffenen pc zijn, die zit achter je router verstopt in een eigen, afgescheiden netwerk.

[The Zep Man]

Dat zal praktisch nooit het IP adres van de getroffenen pc zijn, die zit achter je router verstopt in een eigen, afgescheiden netwerk.

Met IPv6 is dat helemaal niet altijd vanzelfsprekend. Dat is afhankelijk van zaken als privacy extensions, omdat anders je MAC adres lekt als onderdeel van het IPv6-adres van je computer. Gelukkig staan die extensions meestal aan.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:06]

[Dreamvoid]

Ook zonder privacy extensions lekt je MAC adres niet, sinds 2015 hebben we RFC 7217: https://www.rfc-editor.org/rfc/rfc7217

Maar het punt blijft idd dat IPv6 eerder beter dan slechter is voor privacy en security dan IPv4.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 09:06]

[The Zep Man]

Maar het punt blijft idd dat IPv6 eerder beter dan slechter is voor privacy en security dan IPv4.

Privacy? Zeker zonder de nodige (client-side) voorzorgsmaatregelen.

Security? Niet echt. NAT is schijnveiligheid.

[Dreamvoid]

Eh, dat is toch wat ik zeg?

[The Zep Man]

Maar het punt blijft idd dat IPv6 eerder beter dan slechter is voor privacy en security dan IPv4.

IPv6 is niet onveiliger t.o.v. IPv4.

Verkeerd gelezen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:06]

[Dreamvoid]

Maar het punt blijft idd dat IPv6 eerder beter dan slechter is voor privacy en security dan IPv4.

??? Waar haal je hieruit dat IPv6 slechter zou zijn?

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 09:06]

[markoverklift]

Oops. dat is wel groot. Dat is niet heel makkelijk goed te breien voor alle pc's die al in de omloop zijn. Het helpt ook alle veiligheid die er in Win 11 zit zo om zeep.

[field33P]

Matrosov schrijft dat het lek van de Intel BootGuard Keys bij MSI ook gevolgen heeft voor andere bedrijven uit de industrie. Die zouden immers dezelfde keys gebruiken waardoor hun apparaten nu ook een verhoogd risico lopen.

Het meest voor de hand liggende is natuurlijk dat OEM-moederborden die door MSI ontworpen zijn dus ook gehackt zijn. Of de private keys van Intel gelekt zijn is niet duidelijk (en waarom zou Intel deze overhandigen aan OEM's?)

[Reactie gewijzigd door field33P op 23 juli 2024 09:06]

[Roel1966]

Zit mij eigenlijk af te vragen hoe het kan dat er dan dus maar 1 key gebruikt word en niet b.v. een combinatie van meerdere keys. Dus in het geval dat dan zoals nu keys gestolen worden dat alsnog een 2de key nodig blijft. Zal wel technisch gezien te ingewikkeld zijn maar bij bijna alles zie je tegenwoordig 2 tot 3 authenticatie methodes dus waarom niet bij een bios.