Sikkerhedsnøgler til bundkort på lavt niveau lækket i MSI-brud, hævder forskere

For omkring en måned siden skrev vi om en underretning om brud på data udgivet af den største bundkortproducent MSI.

Virksomheden sagde:

MSI blev for nylig udsat for et cyberangreb på en del af dets informationssystemer. […] I øjeblikket har de berørte systemer gradvist genoptaget normal drift uden væsentlig indvirkning på den finansielle forretning. […] MSI opfordrer brugere til kun at få firmware-/BIOS-opdateringer fra deres officielle hjemmeside og til ikke at bruge filer fra andre kilder end den officielle hjemmeside.

Virksomhedens mea culpa kom to dage efter, at en cyberafpresningsbande, der går under navnet Money Message, hævdede at have stjålet MSI-kildekode, BIOS-udviklingsværktøjer og private nøgler.

På det tidspunkt var forbryderne stadig i nedtællingstilstand og hævdede, at de ville "offentliggør stjålne data, når timeren udløber":

Uret stoppede

"Afsløringstimeren" i skærmbilledet ovenfor udløb 2023-04-07, for lidt over en måned siden, men Money Message-webstedet på det mørke web er ellers uændret siden bandens første opslag:

Ikke desto mindre hævder forskere hos sårbarhedsforskningsfirmaet Binarly ikke kun at have fået fat i de data, der blev stjålet i bruddet, men også at have søgt igennem dem efter indlejrede crpyotgraphic nøgler og fundet adskillige hits.

Indtil videre gør Binarly krav på Github , Twitter at have udtrukket adskillige signeringsnøgler fra de data, den er i besiddelse af, herunder hvad den beskriver [2023-05-09T14:00Z] som:

• 1 Intel OEM nøgle. Tilsyneladende kan denne nøgle bruges til at styre firmware-fejlretning på 11 forskellige bundkort.
• 27 billedsigneringsnøgler. Binarly hævder, at disse nøgler kan bruges til at signere firmwareopdateringer til 57 forskellige MSI bundkort.
• 4 Intel Boot Guard-nøgler. Disse lækkede nøgler styrer tilsyneladende runtime-verifikation af firmwarekode til 116 forskellige MSI-bundkort.

Hardwarebaseret BIOS-beskyttelse

Ifølge Intels egen dokumentation, kan moderne Intel-baserede bundkort beskyttes af flere lag af kryptografisk sikkerhed.

Første kommer BIOS Guard, som kun tillader kode, der er signeret med en producent-specificeret kryptografisk nøgle, at få skriveadgang til den flash-hukommelse, der bruges til at lagre såkaldte Indledende opstartsblokeller IBB.

Som navnet antyder, er IBB det sted, hvor den første komponent af bundkortleverandørens opstartskode bor.

At undergrave det ville give en angriber kontrol over en inficeret computer, ikke kun på et niveau under et hvilket som helst operativsystem, der senere indlæses, men også under niveauet for eventuelle firmwareværktøjer installeret i den officielle EFI (udvidet firmwaregrænseflade) diskpartition, muligvis selvom denne partition er beskyttet af firmwarens eget digitale signatursystem med Secure Boot.

Efter BIOS Guard kommer Støvlebeskytter, som verificerer den kode, der er indlæst fra IBB.

Ideen her ser ud til at være, at selvom BIOS Guard skulle forhindre uofficielle firmwareopdateringer i at blive flashet i første omgang, ved at nægte skriveadgang til useriøse firmwareopdateringsværktøjer...

…det kan ikke fortælle, at firmware "officielt" signeret af bundkortleverandøren ikke kan stole på på grund af en lækket firmware-billedsigneringsnøgle.

Det er her, Boot Guard træder ind og giver et andet niveau af attestering, der sigter mod at detektere, ved kørsel under hver opstart, at systemet kører firmware, der ikke er godkendt til dit bundkort.

Opbevaring af nøglen én gang

For at styrke niveauet af kryptografisk verifikation leveret af både BIOS Guard og Boot Guard, og for at knytte processen til en specifik bundkort- eller bundkortfamilie, bliver de kryptografiske nøgler, de bruger, ikke i sig selv gemt i genskrivbar flashhukommelse.

De er reddet, eller sprængt, i jargonen, ind i hukommelsen til at skrive én gang, der er indlejret på selve bundkortet.

Ordet sprængt stammer fra det faktum, at lagerkredsløbet er konstrueret som en række nanoskopiske "forbindelsesledninger" implementeret som bittesmå elektriske sikringer.

Disse forbindelser kan efterlades intakte, hvilket betyder, at de vil blive læst op som binære 1'ere (eller 0'ere, afhængigt af hvordan de fortolkes), eller "blæst" - smeltet med andre ord - i en one-shot modifikation, der vender dem permanent til binære 0'ere (eller 1'ere).

At udløse bit-brændingsprocessen er i sig selv beskyttet af en sikring, så bundkortsleverandøren får en engangs chance for at indstille værdien af ​​disse såkaldte Feltprogrammerbare sikringer.

Det er den gode nyhed.

Når først BIOS Guard og Boot Guard kryptografiske verifikationsnøgler er skrevet til den smeltelige hukommelse, er de låst inde for altid, og kan aldrig undergraves.

Men den tilsvarende dårlige nyhed er selvfølgelig, at hvis de private nøgler, der svarer til disse offentlige nøgler, der er sikre-indtil-universets ende nogensinde bliver kompromitteret, vil de indbrændte offentlige nøgler kan aldrig opdateres.

På samme måde giver en OEM-nøgle på debug-niveau, som nævnt ovenfor, en bundkortleverandør en måde at tage kontrol over firmwaren, mens den starter op, herunder at se den instruktion for instruktion, justere dens adfærd, spionere på og ændre dataene det holder i hukommelsen og meget mere.

Som du kan forestille dig, er denne form for adgang til og kontrol over opstartsprocessen beregnet til at hjælpe udviklere med at få koden lige i laboratoriet, før den bliver brændt ind på bundkort, der vil gå til kunderne.

Intels dokumentation viser tre fejlfindingsniveauer.

Grøn angiver fejlretningsadgang tilladt for alle, hvilket ikke er meningen at afsløre nogen hemmeligheder på lavt niveau eller tillade, at opstartsprocessen ændres.

Orange angiver fuld, læse-skrive-fejlretningsadgang tilladt for en person, der har den tilsvarende leverandørs private nøgle.

Rød betegner det samme som orange, men henviser til en privat hovednøgle tilhørende Intel, der kan låse op for enhver vnedors bundkort.

Som Intel ret åbenlyst og ligefrem udtaler i sin dokumentation:

Det antages, at platformsproducenten ikke vil dele deres [Orange Mode]-godkendelsesnøgle med andre sæt af debuggere.

Desværre hævder Binarly, at skurkene nu har lækket en Orange Mode-tast, der kan aktivere lav-niveau boot-time debugging på 11 forskellige bundkort leveret af HP, Lenovo, Star Labs, AOPEN og CompuLab.

Pas på bootkittet

Binarlys påstande synes derfor at antyde, at med en firmware-signeringsnøgle og en Boot Guard-signeringsnøgle, kan en angriber muligvis ikke kun narre dig og dine firmwareopdateringsværktøjer til at installere, hvad der ligner en ægte firwareopdatering i første omgang...

…men også være i stand til at narre et bundkort, der er blevet hardwarelåst via Boot Guard-beskyttelse, til at tillade den slyngelstatiske firmware at indlæse, selvom opdateringen patcher selve den indledende opstartsblok.

Ligeledes kan det at være i stand til at starte en stjålet computer op i firmware-fejlfindingstilstand give en hacker mulighed for at køre eller implantere slyngelkode, udtrække hemmeligheder eller på anden måde manipulere opstartsprocessen på lavt niveau for at efterlade et offers computer i en upålidelig, usikker og usikker stat.

Kort sagt kan du i det mindste i teorien ende ikke bare med en rootkit, Men en støvlesæt.

A rootkit, i jargonen, er kode, der manipulerer operativsystemets kerne for at forhindre selve operativsystemet i at opdage, rapportere eller forhindre visse typer malware senere.

Nogle rootkits kan aktiveres efter at operativsystemet er indlæst, typisk ved at udnytte en sårbarhed på kerneniveau til at foretage uautoriserede interne ændringer af selve operativsystemkoden.

Andre rootkits omgår behovet for et sikkerhedshul på kerneniveau ved at undergrave en del af den firmware-baserede opstartssekvens med det formål at få en sikkerhedsbagdør aktiveret, før operativsystemet begynder at indlæse, og dermed kompromittere noget af den underliggende kode, som systemets egen sikkerhed afhænger.

Og a støvlesæt, løst sagt, tager den tilgang endnu længere, så lavniveau-bagdøren bliver indlæst så tidligt og så uopdageligt som muligt i firmware-bootstrap-processen, måske endda før computeren overhovedet undersøger og læser noget fra harddisken.

Et bootkit nede på det niveau betyder, at selv at slette eller udskifte hele din harddisk (inklusive den såkaldte Udvidet firmwaregrænsefladesystempartition, forkortet EFI eller ESP) er ikke nok til at desinficere systemet.

Som en analogi kan du tænke på et rootkit, der indlæses efter operativsystemet, som lidt ligesom at forsøge at bestikke en jury til at frikende en skyldig tiltalt i en straffesag. (Risikoen for, at dette sker, er en af ​​grundene til, at kriminelle juryer typisk har 12, 15 eller flere medlemmer.)

Et rootkit, der indlæses sent i firmwareprocessen, er lidt som at forsøge at bestikke anklageren eller hovedefterforskeren til at gøre et dårligt stykke arbejde og efterlade i det mindste nogle bevismæssige smuthuller, som de skyldige kan vride sig igennem.

Men et bootkit er mere som at få lovgiveren til selv at ophæve den lov, som den tiltalte er sigtet efter, så sagen, uanset hvor omhyggeligt beviserne blev indsamlet og fremlagt, slet ikke kan fortsætte.

Hvad skal jeg gøre?

Boot Guard offentlige nøgler, når først de er brændt ind på dit bundkort, kan ikke opdateres, så hvis deres tilsvarende private nøgler er kompromitteret, er der ikke noget, du kan gøre for at løse problemet.

Kompromitterede firmware-signeringsnøgler kan trækkes tilbage og erstattes, hvilket giver firmware-downloadere og opdateringsværktøjer en chance for at advare dig i fremtiden om firmware, der blev signeret med en nøgle, der ikke er tillid til, men dette forhindrer ikke aktivt, at de stjålne signeringsnøgler bruges .

At miste signeringsnøgler er lidt som at miste den fysiske hovednøgle til hver etage og hver suite i en kontorbygning.

Hver gang du skifter en af ​​de kompromitterede låse, har du reduceret anvendeligheden af ​​den stjålne nøgle, men medmindre og indtil du har skiftet hver enkelt lås, har du ikke løst dit sikkerhedsproblem ordentligt.

Men hvis du straks udskifter hver enkelt lås i bygningen natten over, låser du alle ude, så du ikke vil være i stand til at lade ægte lejere og arbejdere blive ved med at bruge deres kontorer i en henstandsperiode, hvor de kan bytte deres gamle nøgler for nye.

Dit bedste bud i dette tilfælde er derfor at holde sig nøje til MSI's oprindelige råd:

[O]indhent kun firmware/BIOS-opdateringer fra [MSI's] officielle websted, og [brug ikke] filer fra andre kilder end det officielle websted.

Desværre koger det råd nok ned til fem ikke helt hjælpsomme ord og et udråbstegn.

Pas på derude, folkens!

---

Opdater. Intels PR-firma sendte os en e-mail for at fortælle os, at virksomheden "er opmærksom på disse rapporter og undersøger aktivt." Det bad de os også om at gøre opmærksom på "Intel Boot Guard OEM-nøgler er genereret af systemproducenten, [så] disse er ikke Intel-signeringsnøgler." Forkortelsen OEM er en forkortelse for producent af originalt udstyr, et lidt forvirrende men veletableret udtryk, der ikke refererer til leverandøren eller leverandørerne af de enkelte komponenter, der er indbygget i et produkt, men til leverandøren, der har fremstillet det komplette system. For eksempel, når du køber, hvad du måske refererer til som et "Intel bundkort" fra MSI, er MSI OEM, mens Intel er leverandøren af ​​processorchippen og måske andre chipsætkomponenter i hjertet af det færdige produkt. (Hvis dit bundkort var et cykelsikkerhedskabel, så ville Intel have lavet låsen, men OEM ville have svejset kablet op, dækket produktet med dets beskyttende belægning og valgt numrene for kombinationen.) [2023-05 -09T22:45Z]

---

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoAiStream. Web3 Data Intelligence. Viden forstærket. Adgang her.
• Udmøntning af fremtiden med Adryenn Ashley. Adgang her.
• Køb og sælg aktier i PRE-IPO-virksomheder med PREIPO®. Adgang her.
• Kilde: https://nakedsecurity.sophos.com/2023/05/09/low-level-motherboard-security-keys-leaked-in-msi-breach-claim-researchers/