MSI bevestigt cyberaanval, hackers claimen broncode te hebben gestolen

MSI bevestigt onlangs slachtoffer te zijn geweest van een cyberaanval en zegt dat de dagelijkse werkzaamheden inmiddels weer worden opgestart. Het bedrijf zegt niet of er data is gestolen. Een ransomwaregroep claimt MSI te hebben aangevallen en broncode te hebben gestolen.

Het bedrijf zegt na het ontdekken van de aanval 'de relevante securitymechanismes en herstelmaatregelen' in werking te hebben gezet. De aanval zou ook bij politiediensten en cybersecuritygroepen zijn gemeld. MSI zegt niet om wat voor aanval het gaat of wie er achter zaten. De aanval zou geen significante impact hebben op MSI's financiële zaken en de systemen worden geleidelijk aan weer in gebruik genomen.

Klanten krijgen van MSI wel het nadrukkelijke advies om alleen firmware- en biosupdates te installeren via MSI's officiële website. Het is niet duidelijk of MSI dit doet omdat er code bij de aanval gestolen zou kunnen zijn of als algemene veiligheidsmaatregel. Ransomwaregroep Money Message claimt namelijk volgens Bleeping Computer onlangs MSI te hebben gehackt, waarbij ze onder meer broncode, private keys en biosfirmware zouden hebben gestolen. Daarbij zouden ook bedrijfsdatabases zijn ingezien.

Money Message zegt 1,5TB data te hebben gestolen en eist vier miljoen dollar losgeld. De groep claimt met de gestolen data biosupdates te kunnen ontwikkelen en met de private keys deze te kunnen installeren. Het is niet duidelijk of MSI daadwerkelijk door Money Message gehackt is of door een andere partij.

Reacties (38)

[petermetroid]

Nou heb ik steeds het idee dat dit soort groepen nooit het geld krijgen wat ze willen. Of zijn er gevallen waarbij hackers wel losgeld kregen?

[wildhagen]

Ja hoor, er wordt heel vaak gewoon keurig netjes betaald door bedrijven:

- nieuws: Universiteit Maastricht betaalde 197.000 euro losgeld voor ransomware...
- nieuws: Nederlandse Colosseum Dental betaalt losgeld aan criminelen na ransom...
- nieuws: Wereldwijde vleesverwerker betaalde 11 miljoen dollar losgeld voor ra...
- nieuws: 'Colonial Pipeline betaalde bijna 5 miljoen dollar losgeld aan hackers'
- nieuws: Texaans schooldistrict betaalt half miljoen dollar losgeld na ransomw...
- nieuws: Antwerps IT-bedrijf betaalt 252.000 euro losgeld na ransomware-aanval...
- nieuws: Opnieuw betaalt Amerikaanse stad losgeld na ransomware-infectie
- nieuws: Amerikaanse stad betaalt 534.000 euro losgeld na ransomwareaanval
- nieuws: Amerikaanse universiteit betaalt ransomwarelosgeld ondanks aanwezighe...
- nieuws: RTL Nederland betaalt hackers 8500 euro na ransomwareaanval
- nieuws: Data ict-bedrijf Managed IT was versleuteld met Bitlocker en losgeld ...
- nieuws: 'HBO biedt hackers 250.000 dollar aan om uitstel voor betalen geëiste...

En zo nog wat meer.

Dat is ook één van de belangrijkste redenen dat die hacks door blijven gaan, en steeds verder toenemen: het is een winstgevend businessmodel, want bedrijven betalen toch wel, en de pakkans is klein. En de hoeveelheid moeite die men erin moet steken om de winst te behalen is relatief klein.

[Reactie gewijzigd door wildhagen op 22 juli 2024 17:07]

[petermetroid]

Bizar zeg. Dat bedrijven zo makkelijk betalen. Zo kan kunnen ze elke week wel gaan hacken bij hetzelfde bedrijf. Een soort Mafia achtige zaken. Hoe het toen bij Rockstar (Gta6) ging was een voorbeeld van hoe het wel zou moeten.

[field33P]

Dat bedrijven zo makkelijk betalen

Vrij simpel: die hebben het rekensommetje gemaakt en geconcludeerd dat de ransomware-makers betalen goedkoper is dan hun hele systeem opnieuw opbouwen.

[Helium-3]

Zou het lekken van deze broncode, de private keys en firmware ertoe kunnen leiden dat slimme engineers open source bios firmware (denk coreboot o.i.d.) kunnen ontwikkelen die compatibel is met alle huidige (MSI-)moederborden? Of compatible met alle moederborden tot nu toe, als nieuwe uitgebracht worden met een bijgewerkte CRL?

Of, minder positief, kan dit betekenen dat malware met deze keys bepaalde Microsoft Secure Boot elementen kan omzeilen of zichzelf ongezien kan nestelen in firmware/boot-onderdelen?

[HollowGamer]

Helaas niet, je mag (of beter gezegd, beter gesloten code niet kopiëren. Reverse engineering is anders, dan heb je niet de eigenlijke broncode/werking.

Secure Boot is niet zo fantastisch als wordt gedaan. Er zijn genoeg dingen mee mis en naar mijn weten gebruikt Linux ook een workaround die niet zo mooi is.

[field33P]

Secure Boot is nog steeds beter dan een systeem wat zomaar alles boot. Idealiter checkt een implementatie ervan dat alle drivers die erna ingeladen worden ondertekend zijn (dat doen Windows en macOS).

[blorf]

Waar zorgt het voor? Het enige wat ik eraan herken is dat je een PC niet kan opstarten van een ongebruikelijk medium als je het boot-wachtwoord niet weet en ook geen kans ziet om te batterij eruit te halen. Om het te "omzeilen" moet er sprake zijn van fysieke toegang maar dan niet zo ver dat je het gewoon uit kan zetten.

[R4gnax]

Secure Boot zorgt er voor dat alleen code die digitaal ondertekened is mbv een herkend certificaat, door de UEFI firmware gestart zal worden als bootloader voor een OS.

Dat wil zeggen dat de bootloader image zelf niet gemanipuleerd kan zijn om malware geinjecteerd te hebben gekregen. Het is de start van een lokale chain of trust waarbij de geverifieerd malware-vrije booteloader, van elke module die deze op zijn beurt wil inladen en starten, kan controleren of deze ook correct ondertekend is, etc.

Het zorgt er voor dat malware, theoretisch, geen kans krijgt om op een heel laag niveau in te grijpen, nog voor er tegenmaatregelen genomen kunnen worden zoals anti-virus onderdelen die op een zo laag/vroeg mogelijk niveau draaien en alles wat op hogere lagen gaat draaien, kan doorspitten en afstoppen - zonder dat malware, theoretisch, de kans krijgt om dit 'voor te zijn.'

Alleen, net zoals bij het gebruik van certificaten voor HTTPS-versleutelingen; het staat of valt bij de zwakste schakel. En in dit geval lijkt dat een private key van een moederbordfabrikant.

Dat is feitelijk zo ongeveer het Secure Boot equivalent van een root certificate authority die gecompromiteerd is.

[Reactie gewijzigd door R4gnax op 22 juli 2024 17:07]

[blorf]

Volgens mij heeft het iets van 2 jaar geduurd, toen kon elke obscure kernel een certificaat krijgen. Het was een actie tegen custom kernels, oftewel open source systemen. Dat moest kunnen wat het kan met telefoons ook. Vooralsnog mislukt. We hebben de PC nog steeds onder controle.

[R4gnax]

Het was een actie tegen custom kernels

Sinds de allereerste versie van de specificaties voor de UEFI standaard waar SecureBoot onderdeel van was, was een vereist onderdeel van die standaard dat het voor eigenaren mogelijk moest zijn om private keys naar keuze op te nemen in de door de firmware goedgekeurde lijst keys waarmee bootloaders ondertekend konden zijn om op te mogen starten.
Sinds dag één is bring-your-own-kernel dus vziw gewoon een ding geweest.

[blorf]

Het is ook altijd mogelijk geweest, maar het idee was het per machine een handeling vereisen. Treiteren van de OEM-loze PC's. Zelfde als rooten/jailbreaken van telefoons. Daar is het helemaal bij gelukt. Er draait alleen maar of Android of iOS op praktisch elk toestel. Het 'voordeel' is dat je daar geen fysieke hardware I/O hebt. Geen invoer = brick. Bij PC's gooit legacy 80x25 console roet in het eten. Als de bootloader het niet doet, ctrl-alt-del en iets anders proberen...

[Reactie gewijzigd door blorf op 22 juli 2024 17:07]

[Blokker_1999]

Ofwel laatje je ode tekenen door een erkende root, ofwel is er een handeling vereist. Hoe zou je dit anders oplossen?

[blorf]

Je kon niet meer een besturingsyssteem distribueren met een ge-automatiseerde installatie zonder secureboot handmatig uit te zetten in de BIOS/UEFI. Er werd gedaan alof je een beveiliging uit moest zetten voor alle non-Windows systemen.
Gelukkig heeft de OSS comunity er gehakt van gemaakt. Voordeel was dat die grap alle retailers van zelfbouw-hardware ook veel geld kostte, dus er was medewerking. Iets als Megekko had niet bestaan als dat erin was gebleven.

[Reactie gewijzigd door blorf op 22 juli 2024 17:07]

[batjes]

Linux gebruikt veelal de workaround: Microsoft levert sleutels voor verscheidene Linux distros mee aan OEMs.

Secureboot is op zich prima, kan ook prima standalone met Linux werken verder. Maar in de praktijk voegen fabrikanten alleen Microsoft toe als vertrouwde partij.

[Blokker_1999]

Er worden helemaal geen sleutel meegeleverd. Microsoft heeft bootloader ondertekend en die worden vertrouwd omdat ze door MS zijn ondertekend.

En iedereen kan investeren in het opzetten van de nodige infrastructure en het laten op nemen van hun root certs door fabrikanten, maar niemand, buiten MS, wil die investering doen

[Cageman1984]

gebruikt Linux ook een workaround die niet zo mooi is.

Wat voor workaround dan?

[R4gnax]

Wat voor workaround dan?

Ze chainen hun eigen bootloader achter een door MS gesigneerde bootloader.

[Cageman1984]

Oke... En MS vindt dat oke?? Op die manier is het nut van UEFI secure boot toch wel een beetje om zeep?

Dan zou je via die MS bootloader dus je eigen toolkit ook kunnen inzetten volgens mij.

Ik dacht oprecht dat 'linux' (verzamelnaam, klopt niet, weet ik) zijn eigen gesigneerde bootloader had.

Ik zit nu even de reacties verder te lezen. Kort samengevat, dat wist ik niet.

[Reactie gewijzigd door Cageman1984 op 22 juli 2024 17:07]

[R4gnax]

Oke... En MS vindt dat oke??

Dat is specifiek waarom MS die bootloader gesigneerd beschikbaar stelt.
Zie o.a. https://wiki.debian.org/SecureBoot#Shim

Dat Secure Boot vendor-lockin voor Microsoft Windows zou moeten bewerkstelligen, is een broodje aap verhaal. Toen Microsoft origineel de systeemeis voor Windows 8 opvoerde aan haar OEMs dat bij voorgeinstalleerde systemen SecureBoot aan moest staan, werd er een enorme hoop FUD verspreidt dat dit een poging was om het ecosysteem over te nemen. Maar Microsoft had toen al in haar systeemeisen expliciet opgenomen dat op voorgeinstalleerde x86/x64 apparaten het voor de consument mogelijk moest zijn om SecureBoot uit te schakelen of in de zgn. 'custom mode' te draaien waar het mogelijk moet zijn om eigen keys voor een toegestane bootloader a/d UEFI toe te voegen.

Die shim bootloader is een heel simpele bootloader waar een distro vendor een eigen private key aan vast kan hangen om de echte eigen bootloader mee te kunnen verifiëren. Het geheel kan men dan door MS laten signeren en daar zijn ze gewoon open en transparent over.

Die shim is er gekomen omdat dat voor consumenten gewoon veel makkelijker was. Zij hoeven dan niet eerst de UEFI in om SecureBoot uit te zetten of in custom mode te zetten en een key toe te voegen. Maar SecureBoot 'werkt gewoon' voor ze, ook onder Linux, out of the box.

Debian; Ubuntu; etc.
De grote distro's ondersteunen het gewoon.

[Reactie gewijzigd door R4gnax op 22 juli 2024 17:07]

[Cageman1984]

Oke, dankjewel voor de uitleg. Nooit gerealiseerd.

[i-chat]

in principe heb je gedeeltelijk gelijk, je mag gestolen code niet gebruiken, maar evengoed mag je ook gelicenceerde code niet reverse engeneeren, dat wil zeggen je mag maatregelen die daartoe zijn getroffen niet omzeilen om alsnog aan de inhoud te komen.

in tegenstelling tot wat veel mensen denken is de eerste stage in cleanroom rev-engeneering feitelijk ook gewoon hacken / cracken / stelen van broncode en/of intelectueel eigendom.

maar: zodra informatie openbaar is, en zolang die informatie niet draait om technieken die gepatenteerd zijn, kun je die code herontwikkelen en zorgen dat die compatible is met de hardware en signalering van apparaten. simpel gezegd moet je dan aan exact dezelfde regels houden als bij clean room reverse engeneering....

de 'juridische' exploit waar zulke onderzoekers van gebruik (misbruik) maken is dat kennisdeling geen heling kan zijn. ook niet als die kennis uit gestolen bron komt. dus of die 'bekende werking' nu uit data diefstal, uit hacken, of uit puur geluk komt, doet dan niet geheel ter zake.

[Reactie gewijzigd door i-chat op 22 juli 2024 17:07]

[psychicist]

Ik schakel Secure Boot altijd uit op mijn persoonlijke x86 systemen. Ik heb er helemaal niets aan en het belemmert me in mijn keuzevrijheid qua software die ik erop kan draaien. Ik draai ook nergens Windows, dus ik heb het ook nergens voor nodig.

[field33P]

Dat zou in theorie kunnen, maar ze mogen het niet uitbrengen. Sterker nog, zo’n project moet als de code op straat gegooid wordt zelfs uitkijken dat mensen geen daarvan afgeleide code toevoegen aan het project.

[R4gnax]

Of, minder positief, kan dit betekenen dat malware met deze keys bepaalde Microsoft Secure Boot elementen kan omzeilen

Dat kon al.
Men heeft in het verleden al eens een exploiteerbare bootloader gevonden die door MS ondertekend is met hun master key. Deze kan niet veranderd worden zonder dat de Windows bootloaders en alle andere bootloaders die aan die key vasthangen, onbootbaar worden, dus effectief: kan gewoon niet vervangen worden. Dat houdt ook in dat SecureBoot per definitie lek is. Het is altijd mogelijk om de boot loader te vervangen door deze compromiteerbare versie en van daar af te springboarden.

Zie o.a. 'BlackLotus', anno maart 2023 de eerste in het wild gesignaleerde malware 'bootkit.'
Nul-komma-niets tegen te beginnen, anders dan pogen om infectie op een hoger niveau al tegen te houden.

[Reactie gewijzigd door R4gnax op 22 juli 2024 17:07]

[Sahri]

Ik denk dat ze dit doen om malware te ontwikkelen die dat kan omzeilen zodat ze nog meer systemen kunnen infecteren.

[mutley69]

Die private keys zijn het ergst - want die kunnen malwaremakers misbruiken. Meteen te blokkeren door de makers van de OS-en stel ik dan!

[R4gnax]

Die private keys zijn het ergst - want die kunnen malwaremakers misbruiken. Meteen te blokkeren door de makers van de OS-en stel ik dan!

Weet eerlijk gezegd niet eens of er een standaard-operatie is binnen UEFI om certificaten die toestemming verlenen om firmware te flashen, op een revocatie-lijst te zetten en nieuwe certificaten toe te voegen die deze moeten gaan vervangen. Je bent waarschijnlijk overgeleverd aan de grillen van de hardware-fabrikant zelf, om dit te regelen. Als het überhaupt al mogelijk is om deze certificaten aan te passen.

Dit filteren op OS-niveau is te laat.
Malware die toegang tot de kernel heeft, kan UEFI-firmware flashen als het moederbord dit aan heeft staan. Op dat toegangsniveau van het OS bestaan er (in elk geval in Windows) geen losse accounts en losse toegangsrechten meer. Als je er bij kunt, kun je overal bij - en aangezien het allemaal één grote gedeelde proces- en geheugenruimte is, kun je ook alles wat je wilt bypassen. Een certificaat revocatie-controle op dat niveau is dus te laat; want kan gewoon omheen geprogrammeerd worden door de malware-auteur.


(Ik snap sowieso niet dat je zomaar direct vanuit de OS kernel de UEFI firmware zou mogen flashen. Waarom zit daar niet een hardware-killswitch tussen zoals een knopje op de rear-dash wat je bijv even in moet drukken om OK te geven?)

[Reactie gewijzigd door R4gnax op 22 juli 2024 17:07]

[field33P]

Niet bepaald een fijn idee dat er nu de mogelijkheid bestaat om een rootkit op UEFI-niveau te installeren mits je ring0-toegang hebt (tenzij MSI de mogelijkheid om vanuit Windows te flashen categoraal uitgezet heeft) en die niet verwijderd kan worden zonder een hardware flasher.

[R4gnax]

Beter dus even je UEFI settings er op nalopen of je firmware flashing vanuit de OS-zijde uit kunt zetten.

[Gemmeke]

Wat ik mij soms afvraag is hoe een groep een hackaanval claimt zonder gepakt te worden?

Elke vorm van communicatie is toch traceerbaar?

[Bergen]

Tot op zekere hoogte. Als jij gehackt bent, en je ziet een IP uit China/Rusland/Bangladesh/Iran/Colombia. Ik noem maar wat. Veel succes met de communicatie met de systeembeheerders van een subnet in zo'n land. En stel dat het je lukt om daar met iemand te praten. En dan blijkt dat een IP van een gehackte webcam te zijn, en het verkeer daarvan blijkt te komen van een IP uit weer een heel ander land, van een gehackte opgepatchte oude Solaris 5 host met alle logging uitgeschakeld. Zie maar eens iemand bereid te vinden om daar onderzoek voor jou te gaan doen.

Een goeie hacker maakt eerst een paar sprongetjes tussen een paar gehackte machines, en gaat dan pas op zijn doel af. Of je gebruikt Tor, maar dat is niet helemaal waterdicht geloof ik. Of hij het internet op via een openstaand wifi-netwerk van een ander. Of via een anoniem internetcafe. Manieren genoeg om niet of moeilijk traceerbaar te zijn.

[CivLord]

Een Webmail-service die niet logt, op een site in één van de door jouw genoemde landen, lijkt me al voldoende.

[renecl]

Hoe groot is de install base van MSI, en voor zover ik weet is MSI ook niet echt aanwezig binnen bedrijven.

Denk dat risico erg klein is m.b.t. aanvallen via of met behulp van bios/boot

[wildhagen]

Hoe groot is de install base van MSI, en voor zover ik weet is MSI ook niet echt aanwezig binnen bedrijven.

MSI heeft wel degelijk een zakelijke lijn voor Business Productivity. Laptops, tablets etc.

En MSI heeft in gaming laptops bijvoorbeeld een marketshare van 19 procent, dat is toch een vrij grote speler. Ook op het gebied van moederborden is het een van de 4 grote spelers (naast Asus, Asrock en Gigabyte).

[renecl]

Dat wist ik niet

[Schaarbakkes]

haha het is zeker een businessmodel.
Bij dergerlijke transacties zijn er zelfs tussenpersonen betrokken om de partijen te laten communiceren met elkaar. Dat is een job al op zijn eigen.