Onderzoekers vinden uefi-rootkit die actief misbruikt wordt

Onderzoekers van beveiligingsbedrijf ESET hebben een uefi-rootkit aangetroffen. De malware blijft in de firmware, ook na een nieuwe installatie van het besturingssysteem of het wisselen van de harde schijf. De rootkit wordt in het wild misbruikt.

Volgens ESET waren er al wel eerder berichten over het bestaan van uefi-rootkits, zoals in een Vault7-release van WikiLeaks en via een uitgelekt document van Hacking Team, maar een dergelijke rootkit zou nog nooit bij een daadwerkelijk besmette computer aangetroffen zijn. Volgens de ESET-telemetrie werd de malware nauwelijks gebruikt en is deze ingezet tegen overheidsinstanties in de Balkan en Centraal- en Oost-Europa. Verder zouden er aanwijzingen zijn die naar gebruik door Sednit leidden, de groepering die ook APT28, Sofacy, Strontium en Fancy Bear genoemd wordt en die in verband gebracht wordt met de Russische spionagedienst.

ESETs onderzoek begon bij een versie van LoJack of Computrace, die was voorzien van een trojan. LoJack is antidiefstalsoftware van het bedrijf Absolute Software, die opviel door het gebruik van een uefi-module, waarmee een dief de software niet kon omzeilen door het OS opnieuw te installeren. De versie met malware, die ESET LoJax noemt, maakte echter verbinding met een onbekende command & control-server in plaats van die van Absolute Software.

De malware bleek echter ook code te bevatten om een uefi-image te onttrekken, deze aan te passen en de versie met trojan weg te schrijven naar het spi-geheugen. Hoewel deze eigenschap van de uefi-rootkit op bepaalde firmware gericht is, noemt ESET het een krachtige tool voor aanvallers, vanwege de persistentie, de lastige detectie en het feit dat opnieuw flashen geen alledaagse bezigheid is voor de gemiddelde gebruiker.

Bootproces van een systeem dat geïnfecteerd is door uefi-rootkit

Reacties (85)

[glennscholten]

Sommige fabrikanten bieden een dubbel uitgevoerde UEFI aan om een eventueel mislukte flashpoging af te vangen. Je moet dan handmatig een jumper omzetten om te schakelen naar de tweede UEFI. Is dit nog bruikbaar om een eventuele infectie te lijf te gaan, of is dit dan ook niet meer te vertrouwen?

[keranoz]

Bij mijn Gigabyte moederbord is het zo dat de eerste schip altijd wordt gebruikt tenzij het systeem er niet mee kan booten. In dat geval wordt het systeem gestart met de backup chip en wordt een de firmware op de backup chip gekopieërd naar de hoofdchip.

Als ik dit goed begrijp betekent dat een rootkit gewoon zou blijven bestaan want het systeem kan er gewoon mee booten.

Source: https://www.gigabyte.com/.../tech_081226_dualbios.htm

[Marty007]

Als je secure boot aan hebt staan in je bios is deze beschermd tegen infecties ... echter als je al geïnfecteerd bent helpt dit niet. Een 2e bios starten en dan de eerste volledig wissen en overschrijven zou het virus moeten wissen. Echter kan ik hier geen duidelijke bevestiging vinden die na te trekken is

[vinkjb]

Zou het opnieuw flashen van je bios een uitkomst zijn of niet?

[Sandor_Clegane]

Snap uberhaupt niet waarom er zo'n complex boot proces nodig is, je zou verwachten dat het OS de meeste taken wel op zich kan nemen en dit ook nog beter kan omdat het dan volledig controle over de hardware heeft en eventuele issues beter kan afhandelen.

[RJG-223]

Als een computer aan gezet wordt kan ie zo goed als niets. Alléén de CPU werkt. De rest niet. Harddisk niet, PCI bus niet (videokaart dus ook niet), geheugen óók al niet. Om nog maar niet te spreken van netwerkkaart, USB devices (toetsenbord, USB CD-drive, USB disk) etc. etc.

Wat de BIOS moet doen, is alle devices (dus ook het geheugen!) zodanig initialiseren en configureren dat de BIOS überhaupt zelf normaal kan draaien (normaal draaien is een beetje lastig zonder geheugen), en daarna het OS kan vínden, en daarna natuurlijk het OS laden. Daarbij wil de gebruiker ook F2 (of zo) kunnen drukken om de BIOS te configureren, of om een ander boot-device te selecteren.

Het OS is al die tijd nog niet eens in beeld. En ja, het OS kan die meeste taken wel op zich nemen, maar niet allemaal, en de taken die het wel kan, kan het alleen doen als het in spi-geheugen staat (waar dus normaal de BIOS staat). Nadeel van dat geheugen is dat er weinig ruimte is, waardoor bijv. windows er niet in z'n geheel in past. Nadeel is ook dat je dan bij elke OS update het spi-geheugen opnieuw moet flashen. En je kunt er niet meerdere OSen tegelijk installeren.

Daarom is er dus een BIOS. Een simpel OS, dat alleen bestaat om alle hardware die nodig is voor het laden van het OS te initialiseren, en om daarna het gewenste OS te laden.

[Verwijderd]

Dat verklaart niet waarom UEFI zoveel complexer moet zijn dan BIOS. Je kan heel goed een casus maken dat minder complex een beter idee is, en dat er dus niet meer gedaan zou moeten worden dan een boot device vinden, initialiseren, genoeg daarvandaan laden dat het OS het verder zelf wel kan, en het is wel goed. Okee, het is ook wel handig iets van invoer en uitvoer te hebben, wat vroeger op servers en nog steeds wel op embedded apparaten met een serieel poortje gedaan wordt. Al het andere kun je wel doen maar doet het OS eigenlijk toch nog wel een keertje over, dus waarom die moeite doen? Dat is de eigenlijke vraag, en zeggen "er moet vanalles", nou eigenlijk is dat op de keper beschouwd lang niet zo belangrijk als het lijkt.

In het geval van UEFI was het heel belangrijk dat fabrikanten vooral extra features konden toevoegen en dat de muis ook gebruikt kon worden om op de menuutjes te klikken en dat ze er dan mooi gelikt en grafisch uitzagen. Ondertussen is de boot-interface tussen OS en UEFI ook een stuk ingewikkelder: In plaats van "hier is je disk, veel plezier ermee" is het "oh ja je moet ook eerst een fat32-filesystem kunnen lezen." En zo zijn er nog wel meer details die mij sterk aan het second system effect doen denken. Ik zou dan dus ook zeggen dat UEFI een stukje complexer is dan strikt noodzakelijk voor het simpele doel "een OS starten".

Het is dan ook niet raar dat er regelmatig problemen mee opduiken zoals wat we nu hier zien. Hoe meer complexiteit, hoe meer gaten. En dat maakt misbruik ook weer makkelijker.

[RJG-223]

Dat verklaart niet waarom UEFI zoveel complexer moet zijn dan BIOS.

Het verklaart het deels. Een ander deel wordt verklaard met dezelfde verklaring als waarom windows 10 zoveel complexer is dan windows 3.11, dat weer zoveel complexer is dat MS-DOS.

Je kan heel goed een casus maken dat minder complex een beter idee is

Minder complex betekent in ieder geval minder kans op fouten. Aan de andere kant minder complex betekent ook minder mogelijkheden. En mensen willen mogelijkheden. De meesten hoeven geheugentimings niet te configureren, maar een aantal wel, en die willen er genoeg voor betalen dat de feature erin gestopt wordt. Zelfde voor booten van netwerk, booten van USB device, etc. etc. etc.

en dat er dus niet meer gedaan zou moeten worden dan een boot device vinden, initialiseren, genoeg daarvandaan laden dat het OS het verder zelf wel kan, en het is wel goed.

Boot device vinden betekent voor jou (1e SATA harddisk vinden) iets anders dan voor de technische dienst van de PC-winkel (1e externe USB drive vinden), of voor een server operator (1e of 2e helft vinden van de gemirrorde SAS disk), of voor een eigenaar van een clouddienst die 1000 nieuwe machines moet uitrollen (boot-server vinden op het netwerk).

Okee, het is ook wel handig iets van invoer en uitvoer te hebben, wat vroeger op servers en nog steeds wel op embedded apparaten met een serieel poortje gedaan wordt.

...en de meesten hebben geen seriële terminal, of terminal server, maar enkel een toetsenbord en monitor. Dus: die moeten voor invoer en uitvoer gebruikt kunnen worden.

Al het andere kun je wel doen maar doet het OS eigenlijk toch nog wel een keertje over, dus waarom die moeite doen? Dat is de eigenlijke vraag, en zeggen "er moet vanalles", nou eigenlijk is dat op de keper beschouwd lang niet zo belangrijk als het lijkt.

Even een lijstje van wat er moet:

• Initialiseren CPU
• Initialiseren chipset
• Detecteren en initialiseren werkgeheugen (anders is het werkgeheugen niet toegankelijk!)
• Detecteren en initialiseren PCIe controllers. Toekennen van IO ranges aan elk.
• Detecteren van alle devices op de PCIe bus.
• Een device op een PCIe bus kan een andere PCIe controller zijn (of een PCI controller). Ga twee stappen terug voor die PCI(e) controller.
• Toekennen van IO ranges en eventueel geheugen-ranges aan minimaal de IO devices die we nodig hebben. Zoals: SATA controllers, SAS controllers, USB controllers: elk daarvan kan het boot-device bevatten. En dan heb ik het nog niet eens over SAN controllers. (maar als we toch bezig zijn, kunnen we net zo goed IO-ranges en geheugen ranges toekennen aan alle PCI(e) devices die we vinden)
• Initialiseren van eventuele SATA controllers. Detecteren van alle sata disks
• Initialiseren van eventuele SAS controllers. Detecteren van alle sas disks
• Initialiseren van alle USB controllers. Sommige controllers doen zowel USB1, USB2 als USB3. Die functies moeten waarschijnlijk afzonderlijk geïnitialiseerd worden.
• Detecteren van alle USB devices op het systeem (o.a. disks, toetsenbord)
• (Eventueel) Initialiseren van grafische kaart voor feedback naar gebruiker. De USB devices hebben we al, dus een toestenbord kunnen we dan ook gebruiken.
• Nu we weten welke disks er zijn, weten we ook welke daarvan we moeten hebben om van te booten. Dat kunnen we dan eindelijk doen.

Natuurlijk kun je dit alles vereenvoudigen, door een eenvoudig, vast boot-device te gebruiken (geen PCIe, etc). Daar moet je er dan wel twee van hebben (voor mensen voor wie redundancy belangrijk is), en tevens de mogelijkheid om een alternatief OS te selecteren (voor als een OS update misloopt). Daarmee wordt het al complexer.

Als je het dan zo eenvoudig mogelijk gemaakt hebt, dan zijn de mensen niet tevreden, omdat ze hun OS op een zelf-gekozen flash-drive, sata-disk, etc. willen zetten. Of ze willen SAN boot, of netwerk boot. En ze willen dit en dat etc. etc. etc. Dus weet je zeker dat er een mini-OS geschreven wordt, voor op het eenvoudige boot-device, dat al die features die niet meer in de BIOS zitten bevat. Dat mini-OS zorgt dan dat het eigenlijke OS geladen wordt, op de manier zoals de gebruiker dat wil.

Et voilà: wat vroeger jouw complexe UEFI BIOS was, is nu jouw complexe mini-OS, met dezelfde features. De volgende stap is natuurlijk dat dat mini-OS direkt in de flash-ROM gebakken wordt, en dan zijn we weer terug bij af: een complexe BIOS.

In het geval van UEFI was het heel belangrijk dat fabrikanten vooral extra features konden toevoegen en dat de muis ook gebruikt kon worden om op de menuutjes te klikken en dat ze er dan mooi gelikt en grafisch uitzagen.

Dat is wat de gebruikers uiteindelijk willen. De fabrikanten gaan echt geen gelikte grafische interface bouwen als niemand dat nodig heeft, en niemand daarvoor wil betalen. Dat kost geld, en dat geld kunnen ze wel beter gebruiken. Dat jij zoiets niet nodig hebt, betekent niet dat andere mensen dat ook niet willen, en er niet voor willen betalen.

Ondertussen is de boot-interface tussen OS en UEFI ook een stuk ingewikkelder: In plaats van "hier is je disk, veel plezier ermee" is het "oh ja je moet ook eerst een fat32-filesystem kunnen lezen." En zo zijn er nog wel meer details die mij sterk aan het second system effect doen denken.

Ingewikkelder, maar tevens eenvoudiger. De software in complexer, maar het is bijvoorbeeld een stuk eenvoudiger om van een ander soort device (externe USB drive, SAN, netwerk) te booten. Ook is het een stuk makkelijker om meerdere verschillende OSen te installeren zonder dat ze elkaar in de weg zitten. dat was in de oude BIOS-tijden wel anders...

Ik zou dan dus ook zeggen dat UEFI een stukje complexer is dan strikt noodzakelijk voor het simpele doel "een OS starten".

Net zoals Windows, of Linux, etc., een stuk complexer is dan strikt noodzakelijk voor het gebruik wat ieder individueel persoon er van maakt. Als je het OS echter eenvoudiger zou maken, precies goed voor jouw gebruik bijvoorbeeld, dan zouden er wellicht 1000en versies zijn, zoniet meer, een voor elk soort gebruik, en dat zou véél duurder zijn, en al met al juist een stuk complexer om te maken en te onderhouden dan één versie van dat OS die voor de meeste mensen bruikbaar is.

Het is dan ook niet raar dat er regelmatig problemen mee opduiken zoals wat we nu hier zien. Hoe meer complexiteit, hoe meer gaten. En dat maakt misbruik ook weer makkelijker.

Inderdaad. En dat is jammer. Maar dat is onvermijdelijk En dat geldt ook voor het OS, en voor heel veel dingen: de complexiteit neemt toe, waardoor de problemen ook toenemen. Maar nogmaals: het zou een stuk duurder zijn om het anders te doen (zie uitleg boven).

[jhnddy]

Perfecte uitleg. Ik weet eindelijk wat een Bios doet.

[Reactie gewijzigd door jhnddy op 29 juli 2024 19:24]

[RJG-223]

Voor de volledigheid: er zijn nog twee vervolgstappen voordat het OS draait, die wenselijk zijn, maar die niet per sé moeten (als we het zo eenvoudig mogelijk zouden willen houden). De (UEFI) BIOS doet die dus wel:

• Vinden / lezen van de EFI partitie op het boot device
• Laden van de bootloader (= een bestand op de EFI partitie) van het OS, en die uitvoeren. De bootloader zorgt er daarna voor dat het OS eindelijk geladen wordt, want die weet precies hoe dat moet.

[Verwijderd]

Is niet noodzakelijk.

[locke960]

Je hebt gelijk, maar wel een aanmerking:
Als je de UEFI BIOS zo ingewikkeld maakt dat het op een compleet OS begint te lijken, zorg dan ook voor afdoende bescherming en recovery mogelijkheden. Bij een gewoon OS kan je tenminste je harde schijf leeg vegen en opnieuw beginnen met de zekerheid dat het virus weg is. Dat moet voor de BIOS ook mogelijk zijn.
dwz. een fysieke jumper op het moederbord dat "terug naar default fabrieksinstellingen vanuit een ROM" doet. En om problemen te voorkomen ook nog een fysieke knop op het apparaat die je in moet drukken tijdens elke aanpassing aan de UEFI, want anders gaat het gewoon niet.

Vroeger was zoiets normaal. Maar onder het mom van "dat is gebruikersonvriendelijk", en om een paar centen goedkoper te zijn dan de concurrent, zijn we daar van af gestapt. Die houding is helaas epidemisch in de computerindustrie.

[rickboy333]

De belangrijkste reden is dat UEFI gebruik kan maken van GTP en je dus niet meer afhankelijk hoeft te zijn van het ouderwetse MBR.

Verder is het makkelijker voor de producenten om een UEFI te schrijven gezien je die in C kan schrijven terwijl je een BIOS altijd in Assembly moet schrijven.

Dat zijn de voordelen zo uit mijn hoofd buiten het feit dat het voor de casuals toegankelijker is.

[indigo79]

Verder is het makkelijker voor de producenten om een UEFI te schrijven gezien je die in C kan schrijven terwijl je een BIOS altijd in Assembly moet schrijven.

C code compileert tot machinecode net zoals assembly tot machinecode compileert (al is de compiler in het geval van assembly veel eenvoudiger). Voor de CPU maakt het niet uit hoe de code er origineel uit zag.

In de praktijk zijn een aantal zaken in het BIOS waarschijnlijk in assembly geprogrammeerd, maar zijn ook grote stukken in C geïmplementeerd. Bron: o.a. https://softwareengineeri...d-to-write-a-bios-program.

[goarilla]

Je moet toch helemaal geen gebruik maken van MBR althans toch niet de PC-DOS partitie layout. Je weet wel die 4 entries voor partities waarvan 1 "actief" is om te booten. De eerste sector van de bootdisk word ingeladen in het geheugen en in real mode uitgevoerd. That's it !!!

[KopjeThee]

Hoe meer complexiteit, hoe meer gaten.

Zo is het. Er zijn juist beveiligings opties voorzien in Eufi. Maar ook nog een heleboel meer. Dat is uiteindelijk vragen om problemen.
Do one thing, and do it well.
Keep it simple.
Simplicity is prerequisite for reliability.
We weten het allemaal al tientallen jaren, en nog passen we het niet toe.

[Heidistein]

Ik ben het volledig het je reactie eens, maar wil toch even opmerken over deze zin:

Dat verklaart niet waarom UEFI zoveel complexer moet zijn dan BIOS.

Een UEFI is ook een BIOS namelijk, normaal hebben we het over UEFI of Legacy BIOS.

[batjes]

Dat verklaart niet waarom UEFI zoveel complexer moet zijn dan BIOS

Zoals RJG ook al aangeeft. Als je de geschiedenis van de PC goed genoeg zou kennen, zou je daar het antwoord vinden waarom het zo complex moet.

Hardware ondersteuning is tot na het millennium echt een hels karwij geweest. Het is niet leuk hoe verschikkelijk veel moeite je moest doen om bepaalde hardware of configuraties een beetje te laten draaien. Zelfs het instellen van je audio in een game kon je 2 weken mee bezig zijn. Welke van de 10 werkt, en welke van de duizend instellingen heb je nodig. De generatie voor mij had het nog moeilijker en mocht het systeem zelf gaan vertellen "Dit stukje hardware zit in slotje 4, moet dit kunnen, daar staat de -soortvan- driver. Oh shit, dat ook nog eens proberen weg te stoppen in high memory, achter de muis en voor het keyboard anders crashed de flikkerbende, shit nog een stukje hardware? Maar je gebruikt alle 4 de beschikbare slots al, gl&hf".


Het BIOS heeft over de jaren heen een enorme hoeveelheid extra functies gekregen om dat hardware initializeren in ieder geval al op te vangen. Het OS doet het instellen ervan vandaag de dag.

UEFI heeft een aantal extra taken op zich genomen die de OSen zelf moesten regelen en men hoopte een beetje vooruit te denken door het een setje extra mogelijkheden mee te geven. Dit maakt de hele bende misschien wel een stuk complexer, maar ook makkelijker te gebruiken.

Ik ben zo blij dat we het BIOS achter ons hebben kunnen laten, UEFI ging wat stroef op de eerste generaties moederbordjes, maar ondertussen... Wat een verademing en wat een enorme vooruitgang.

[the_stickie]

Een belangrijke motivatie voor de ontwikkeling (U)EFI was bizar genoeg security. Uefi maakt het onder ander mogelijk om zowel de hardware als de software cryptografisch te beveiligen, zodat alleen "vertrouwde" code kan draaien op "vertrouwde" hardware.
Sowieso is het een feit dat de bios configuratie tools ook de spuigaten begonnen uit te lopen en het dus wel goed leek om zaken zoals beveiligd updaten via netwerk aan te bieden.
UEFI biedt inderdaad ook juist méér opties aan het OS wat betreft hardwareconfiguratie (zoals stroombesparing en virtualisatietruukjes).
Dit wil niet zeggen dat ik je geen gelijk geef: het KISS principe is hier duidelijk geschonden, met an sich te verwachten gevolgen.

[cdwave]

Dat "secure" deel is marketingblabla voor de consument. De echte reden is vendor lock-in. Dankzij die secure constructie is het niet mogelijk om die UEFI bloatware te vervangen door een eigen bootloader zoals Coreboot, en zit je aan de fabrikant vast.

[The Zep Man]

Een belangrijke motivatie voor de ontwikkeling (U)EFI was bizar genoeg security. Uefi maakt het onder ander mogelijk om zowel de hardware als de software cryptografisch te beveiligen, zodat alleen "vertrouwde" code kan draaien op "vertrouwde" hardware.

Als dat waar was dan zouden de eerste UEFI implementaties ondersteuning hebben voor zaken als Secure Boot. Dat hebben ze niet.

Beveiliging, zoals Secure Boot, is er pas achteraf bijgekomen.

[The Zep Man]

De belangrijkste reden voor UEFI was control. Microsoft wil de alleenheerschappij over de computer, en daarin past niet dat de gebruiker 'zomaar' een willekeurig OS kan installeren en daarmee Windows buiten spel zet. Dat moet dus zo moeilijk mogelijk worden gemaakt.

Zet 'Secure Boot' uit op je standaard x86-gebaseerd UEFI systeem en je kan gewoon andere besturingssystemen opstarten. Zo moeilijk is het niet.

[GuntherDW]

Spijtig genoeg zijn er laptops (geweest) waar die functie helemaal niet uit te zetten valt.
Hieronder vallen bijvoorbeeld de surface range. Daarop kon je (indertijd toch) niet secure boot uitschakelen.

Dan ben je wel min of meer verplicht om een workaround te gebruiken die redhat indertijd beschikbaar gemaakt had.
Die hadden een kleine bootloader geschreven welke signed werd om zodoende toch Linux te kunnen laden.

[Stoelpoot]

Windows is niet de enige daarin, echter. Linux, Android, alle OSen buiten Linux distros willen hun marktaandeel op die manier vergroten en vastleggen.

[cdwave]

Er zijn open source alternatieven voor UEFI, zoals Coreboot, en NERF. Op de ELCE vorig jaar was er een mooie presentatie over, "Replace Your Exploit-Ridden Firmware with Linux" ( Ronald Minnich, Google):
https://www.youtube.com/watch?v=iffTJ1vPCSo

"UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a “Ring -2 hypervisor"). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs.
Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs."

[The Zep Man]

Er zijn open source alternatieven voor UEFI, zoals Coreboot, en NERF. Op de ELCE vorig jaar was er een mooie presentatie over, "Replace Your Exploit-Ridden Firmware with Linux" ( Ronald Minnich, Google):
https://www.youtube.com/watch?v=iffTJ1vPCSo

Hoe goed is het een alternatief als alleen maar een klein deel van enkel techneuten dat op een klein deel van alle systeemmodellen kan installeren?

"UEFI is a proprietary and closed-source operating system,

UEFI is geen besturingssysteem maar een specificatie. Er is ook een open-source implementatie die men kan gebruiken in combinatie met CoreBoot.

Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs."

En nu ervoor zorgen dat fabrikanten dat omarmen.

[Sandor_Clegane]

Mooi verhaal, alleen legt het nog niet uit waarom het zo complex moet zijn. Je legt alleen maar uit hoe het nu is, ik vraag me af waarom het zo is zoals het nu is en wat daar de noodzaak voor is. Het initialiseren van apparatuur kan ik me nog voorstellen, maar zelfs dat is met hotswap componenten weer een vraagteken aangezien het OS dan toch al de complexe interacties moet doen.

Een Basic Input Output System was zo gek nog niet en ik durf wel te stellen dat we beter af waren geweest als we deze nog meer basic hadden gemaakt ipv UEFI.

[RJG-223]

Zie mijn reactie hierboven

Edit: samengevat dus: de software is complex omdat de hardware complex is, en omdat de mensen veel features willen in hun BIOS. De hardware is complex omdat mensen veel features willen in hun hardware én omdat eenvoudige hardware de zaken juist moeilijker kan maken: je krijgt dan vaste IO-ranges per device, en vaste geheugen-ranges. Die ranges kunnen eigenlijk te klein zijn, waardoor de hardware weer complexer moet worden om daarmee om te gaan, of te groot, waardoor resources verspild worden. Je bent dan ook beperkt in het aantal devices dat je aan kunt sluiten, omdat de IO-ranges vast zijn.

In het verleden hadden we interrupt conflicten, IO-poort conflicten, etc. Erg lastig te diagnostiseren en op te lossen. Verder maximaal 4 COM poorten. Dat is allemaal opgelost door IO-ranges etc. per device configureerbaar te maken, zodat je nooit een conflict hebt. nadeel is dat je dat alles wel éérst moet configureren voordat je een device kunt gebruikten. Voor geheugen is de voornaamste reden waarschijnlijk dat het anders bijna niet mogelijk is om verschillende soorten geheugen met verschillende capaciteiten en verschillende timings (en eventueel nog ECC bijv.) te ondersteunen.

[Reactie gewijzigd door RJG-223 op 29 juli 2024 19:24]

[Sandor_Clegane]

Volgens mij valt het wel mee wat mensen in hun bios willen. Ik zit zelf niet te wachten op een commandprompt in mijn bios en nog wel een paar andere dingen.

Er is niets in je verhaal wat een complexe bios afdwingt in mijn optiek. Een simpele bootstrapper die een bootdevice doorgeeft aan het OS en deze alles laat initialiseren lijkt me een stuk simpeler. Ben je ook van het geneuzel van brakke implementaties af die pas de fout in gaan als je een keer een functie aanspreekt.

[RJG-223]

Er is niets in je verhaal wat een complexe bios afdwingt in mijn optiek

Het lijkt erop dat we elkaar niet begrijpen ? Jij hebt blijkbaar een stukje complexiteit in gedachten die niet verklaard wordt door mijn verhaal.

Kun je vertellen waar in jouw optiek de complexiteit zit die redelijkerwijze uit de BIOS verwijderd zou kunnen worden omdat het OS die net zo goed of beter zelf kan doen ?

[Sandor_Clegane]

Zoals ik al zei: een simpele bootstrapper moet voldoende zijn, dat moet in een paar honderd regels wel te doen zijn. De rest is volgens mij allemaal ballast. Dus waar deze complexe firmware vandaan komt is mij echt een raadsel. Het legt de grootte in elk geval niet uit.

Als ik mij niet vergis is na het booten de bios in principe overbodig omdat het OS dat allemaal zelf voor zijn rekening neemt.

[RJG-223]

Zoals ik al zei: een simpele bootstrapper moet voldoende zijn, dat moet in een paar honderd regels wel te doen zijn

Je herhaalt alleen je bewering, en maakt hem zelfs nog fantastischer. Dus waarschijnlijk ben je aan het trollen. Als dat zo is: gefeliciteerd ermee. Ik hoop dat je vandaag voldaan naar bed gaat !

Als je werkelijk meent wat je zegt, dan moet je maar eens uitleggen hoe je dat in een paar 100 regels doet zonder hulp van een BIOS of een OS. Kijk mijn lijstje nog eens na van alles wat er moet gebeuren. Booten vanaf nul in een paar 100 regels code: dat kon in de jaren 70 van de vorige eeuw misschien (of waren het de jaren 60 ?), maar nu echt niet meer.

Of anders zou je je eens in het onderwerp kunnen verdiepen (dwz: systeemprogrammeren, direkt aansturen van controllers, etc.), want het lijkt erop dat je daar niet zoveel van weet. Of dacht je dat het net zo eenvoudig was als het openen van een bestand en het lezen van de inhoud ervan ? Dat is alleen maar eenvoudig omdat er een OS is, en allerhande libraries, die samen het ingewikkelde stuk voor hun rekening nemen. Maar die heb je dus allemaal nog niet als je aan het booten bent. In dit geval heb je zelfs nog geen BIOS om het makkelijker te maken.

[Sandor_Clegane]

Yay, toffe eerste alinea. Dickhead much?

Je hebt nog steeds niet uitgelegd waar die enorm complexe bios voor nodig is. Een raspberry pi heeft geen bios, die is een stuk simpeler dan een gemiddelde server dat geef ik toe, maar ik zie niet in waarom dat zelfde principe niet voor een reguliere server/pc kan werken. Ook met insteekkaarten en andere randapparatuur.

Ik zie werkelijk niet in wat daar nu zo enorm anders aan is dan een gemiddelde pc, grofweg zijn het dezelfde principes en ik ben van mening dat hetzelfde principe prima voor een gewone pc kan werken.

Dat dat op het moment niet zo is wil niet zeggen dat het niet kan. En op die manier haal je een enorm stuk complexiteit uit het systeem.

Het hele UEFI riekt naar feature creep, net zoals die management engines in cpus. Het is the gift that keeps on giving. Is gewoon overbodig, eruit met die troep.

[Reactie gewijzigd door Sandor_Clegane op 29 juli 2024 19:24]

[RJG-223]

Ik heb een heleboel uitgelegd, en een heleboel feiten gegeven. Kom jij nu maar eens met feiten in plaats van meningen, en leg jij nu eerst eens zelf maar eens een keer iets uit: bijvoorbeeld hoe je in een paar 100 lijnen code een moderne CPU boot, en een OS van een SATA disk leest, in plaats van zomaar dingen te roepen, en er voorbeelden bij te halen die jouw bewering eerder ontkrachten dan ondersteunen.

En lees al mijn reacties bij dit artikel nog maar eens door als je niet begrijpt wat een BIOS allemaal doet, en dat die dus daarom noodzakelijkerwijs enigszins complex moet zijn.

[Sandor_Clegane]

Enjoy: https://www.youtube.com/watch?v=iffTJ1vPCSo

Als je hierna nog denkt dat er niet teveel meuk in de firmware zit dan weet ik het ook niet meer.

[RJG-223]

Als je hierna nog denkt dat er niet teveel meuk in de firmware zit dan weet ik het ook niet meer

Nu heb je het ineens over de firmware in z'n geheel. We hadden het over UEFI. De oorspronkelijke vraag was:

Snap uberhaupt niet waarom er zo'n complex boot proces nodig is, je zou verwachten dat het OS de meeste taken wel op zich kan nemen

Het onderwerp van het artikel, het bijbehorende plaatje, én die reactie gaan allemaal over UEFI. Dat bevestig je nog in een latere reactie:

Een Basic Input Output System was zo gek nog niet en ik durf wel te stellen dat we beter af waren geweest als we deze nog meer basic hadden gemaakt ipv UEFI

Laat ik het dus om te beginnen even bij UEFI houden. Als je in de video kijkt vanaf 17:00, dan zie je dat deze man alleen de laatste paar stappen in UEFI vervangt door een linux kernel en een verzameling programma's geschreven in Go. Het eerste deel van UEFI (wat ook complex is) blijft. En Linux + een verzameling programma's is óók complex, en al met al vermoedelijk minstens tussen de 100.000 en 1.000.000 regels code. Daarnaast: Linux heeft óók een volledige IPv4 stack, een IPv6 stack, een USB stack, etc. etc. etc. Echter: het grote voordeel van Linux is dat de software veiliger is, en beter getest wordt (= minder bugs) dan de UEFI kernel en de verzameling drivers die daar bij horen. Het andere grote voordeel is dat niet langer een deel van de UEFI BIOS actief blijft na het booten.

Nu zou je (als het mogelijk was op moderne processoren) het eerste deel van UEFI ook door eigen code kunnen vervangen. Dat is dan waarschijnlijk veiliger etc, maar alle taken daarvan moeten nog steeds uitgevoerd worden, en als dat in minder dan 1000 regels code kon, dan had deze man (of iemand anders) dat zelf wel gekund, en dan ook gedaan.

Als we de discussie dan breder trekken dan het oorspronkelijke onderwerp, en naar de hele firmware kijken, dan ben ik met je eens dat het iets complexer is dan nodig. Zoals deze man ook bijvoorbeeld zegt: fabrikanten misbruiken bijv. SMM om eigen functionaliteit in te stoppen, o.a. voor vendor lock-in. Maar ook hier geldt weer dan een groot deel van de complexiteit onvermijdelijk is, als je de bijbehorende features nodig hebt. En een deel van de features heeft iederéén nodig. Andere features hebben alleen sommige mensen nodig. De management engine bijvoorbeeld, is essentieel voor server operators. Je zou echter willen dat die gewoon open is, en compleet vervangen kan worden door een linux distributie, maar dat maakt hem niet minder complex. Alleen veiliger en beter getest.

Al met al: er zit zeker spul in UEFI dat onnodig is (bijv het gedeelte dat na het booten nog blijf draaien), onnodige 'features' zitten ook in de SMM code (en die is misschien wel (bijna) geheel overbodig), en voor de meeste consumenten zitten in UEFI ook mogelijkheden die ze nooit zullen gebruiken (netwerk boot bijv.), maar die hebben anderen dan weer wel nodig. En de meeste consumenten hebben de ME ook niet nodig. Een computerfabrikant weet echter niet vooraf door wie het apparaat gebruikt gaat worden, dus moeten die zaken die voor sommige mensen niet nodig zijn er wél in zitten. Het is namelijk veel te duur om een aparte versie van UEFI te maken voor elk soort gebruik. Maar daar heb ik het al eerder over gehad. En mensen zouden het ook behoorlijk vervelend vinden als ze voor een familielid een handig 2e hands PCtje op de kop tikten, en er dan achter kwamen dat ie alleen van netwerk kan booten, of dat hij alleen van de (ene) interne harddisk kan booten (dus niet van USB, niet van CD, etc.).

Ik blijf er dus bij dat complexiteit in UEFI, maar ook in de hele firmware, nodig is, en deels onvermijdelijk, alhoewel niet iedereen alles zal gebruiken. Net zoals met Linux en Windows. Het zal zeker iets minder complex kunnen, maar booten in minder dan 1000 regels code is onmogelijk. En als we (grote) delen vervangen door Linux (dat op zich al complex is!), dan blijft het complex, zeker als het dezelfde essentiële mogelijkheden moet hebben (booten van SATA, SAS, RAID, USB, Netwerk, boot device selectie, boot manager, remote management, etc. etc. etc.). En dat zijn allemaal dingen die sowieso niet in het OS kunnen zitten, want dat moet dan nog geladen worden. Als deze zaken niet in de BIOS/firmware zitten, dan zal daarvoor een apart OS ontwikkeld (moeten) worden, dat draait vóór het echte OS, en dat die features wel bevat. En dat dan dus feitelijk een nog-steeds-complexe UEFI vervanger is.

[Reactie gewijzigd door RJG-223 op 29 juli 2024 19:24]

[Sandor_Clegane]

Toffe reply, om heel eerlijk te zijn gaat zijn verhaal mij nog niet ver genoeg. Als je toch al de bios vervangt voor Linux, waarom heb je deze dan nog nodig? Dan kun je net zo goed direct Linux booten en het laten voor wat het is. Linux om Linux te booten lijkt me op zo'n matroesjka oplossing.

Het actief zijn van Eufi terwijl het OS geboot is waardoor je dus invloed op het OS kunt uitoefenen zonder dat deze daarvan op de hoogte is een domme zet. Dit heeft tot gevolg dat je nooit met zekerheid kunt zeggen dat wat OS voor waar aanneemt ook daadwerkelijk waar is aangezien EUFI gewoon tegen het OS kan liegen.

Wat betreft Linux als bios, zoals de man aangeeft krijgt de Linux kernel veel meer te verduren en wordt veel beter getest dan een bios. Je zou dus kunnen stellen dat het implementeren van Linux als bios wel complex is, maar dat deze complexiteit veel beter bekend is en ook veel meer getest is dan een proprietary bios van Intel of AMD of wie dan ook.

Edit: dat van die regels code is geen vast getal en was een beetje hyperbolisch. Het ging me er meer om dat de complexiteit voor wat een bios moet doen toch wel wat gemakkelijker en simpeler moet kunnen in minder regels dan wat we nu hebben.

[Reactie gewijzigd door Sandor_Clegane op 29 juli 2024 19:24]

[orvintax]

Netwerkkaart wel, als je WOL hebt aanstaan

[RJG-223]

De netwerkkaart werkt wél, en níet. Hij heeft een eigen processor die werkt, net zoals heel veel andere hardware (grafische kaart, IO controller, harddisks, toetsenbord, etc. etc. etc.) elk een eigen embedded processor hebben. Al die eigen processoren werken natuurlijk zodra ze stroom krijgen. Maar de CPU kan niet met ze communiceren omdat de chipset, de PIC(e) bussen, en de controllers niet geïnitialiseerd zijn. Ik heb dat vereenvoudigd als 'niets werkt', om de uitleg niet al te complex te maken.

Met z'n eigen processor kan de netwerkkaartprocessor een pakketje ontvangen, en dan een signaal sturen naar het moederbord of naar de voeding waardoor de rest van de hardware aangezet wordt. Dat is gewoon een simpel electrisch pulsje, dat bijvoorbeeld ook van een eenvoudig drukknopje kan komen.

[habbekrats]

Waarom geen write protect jumper om MB ? zo vaak flash je je bios toch niet?

[InsanelyHack]

Uefi is geen bios. Het is een bootloader die wat basale settings via nvram inleest. Kijk maar eens op je disk naar je partities. Daar vind je een EFI partitie met ook een .efi bootfile (Microsoft / Linux of macOS). Daar nestelt zich de rootkit. Niet in een stukje firmware die je evt zou beveiligen met een jumper ofzo.

[wica]

de versie met trojan weg te schrijven naar het spi-geheugen.

Dit is niet meer op je disk. Maar op je MB.

/edit
uit de bron

As we will describe later: in its current state, the tool is only able
to write to the BIOS region of misconfigured or fairly old systems (on motherboards older than Platform
Controller Hub chipsets introduced around 2008)

[Reactie gewijzigd door wica op 29 juli 2024 19:24]

[terradrone]

Een heel akelige ontwikkeling; malware wat in uefi firmware nestelt. Dus inderdaad, diskjes wisselen of wipen heeft geen effect meer. Je mag hopen dat je door een efi reflash weer een schone firmware hebt. En dan is de efi nieteens de enige firmware op een mb. Bedenk je dat intel's amt , wat ook een eigen firmware draait, ook lek blijkt te zijn. Daarmee zijn de dagen van een "virus" infectie door een wormpje in windows voorbij; dit is een heel akelige (verontrustende) ontwikkeling.

[CMG]

Dit soort dingen is niet nieuw, in het verleden werd ook al in de firmware van HDDs en SSDs malware geplaatst die zichzelf blijft persisten na wipe van het OS. Alles is een attack vector, niks is veilig.

[Verwijderd]

Eerst moet je dan een schone uefi firmware image hebben wat dus al moeilijk is sinds er weinig fabrikanten checksums en signed images leveren en je mag ook in je handjes klappen als je het kan downloaden over https.
En ook geen reproducible builds

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:24]

[Knakworst007]

Wake up bro! Don't be fooled. Die zijn allang Voorbij!
Onder andere:

Veil Framework
https://github.com/Veil-Framework/Veil-Evasion

Unicorn
https://github.com/trustedsec/unicorn

Venom
https://github.com/rapid7.../wiki/How-to-use-msfvenom

[Z80]

In 1998 was er al een virus dat de bios aanviel. Het chernobyl bios virus.
https://en.wikipedia.org/wiki/CIH_(computer_virus)

[Verwijderd]

spi-geheugen

Dit is trouwens een flash chip op je moederbord. Toegang naar deze chip gaat via een SPI bus. Een "spi-geheugen" bestaat niet.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:24]

[wica]

Tweakers maakt dat er van.

[jdh009]

Vraagje, hoe kan het dan dat bij een wissel van de harde schijf de rootkit nog steeds actief/aanwezig is? Je zou verwachten dat het probleem dan zou zijn opgelost na vervanging van de harde schijf.

[Reactie gewijzigd door jdh009 op 29 juli 2024 19:24]

[Stannieman]

Omdat de UEFI firmware wel degelijk op een chip op het moederbord staat. Het is net zoals een BIOS, maar dan moderner, uitbreidbaar, nieuwer, beter, ondersteuning voor secure boot en fastboot, een "echte" UI in plaats van dat zwart-blauwe BIOS scherm, en noem maar op...

Net zoals met een BIOS-begaseerd system heeft het OS nog steeds een bootloader nodig, en dat is die .efi file waar @InsanelyHack het over heeft.
Nu werkt dat wel net iets anders: Een BIOS begint (dacht ik) gewoon de bootsector van je schijf uit te voeren en daar staat als het goed is een bootloader, anders gebeurt er gewoon niks.
UEFI heeft echter wel notie van een bestandssysteem waar die .efi file staat en zal echt specifiek die file inladen en uitvoeren. Die .efi file bevat nog steeds de code die Windows zelf gaat aanzwengelen. Dit is dus nog steeds de brug tussen UEFI en Windows waardoor de firmware zelf geen OS specifieke dingen moet implementeren.
Dit doet er nu echter niet toe, wat belangrijk is is dat UEFI nog steeds firmware is op een chip op het MB.

[axe0]

Omdat de rootkit zich in het firmware van de moederbord nestelt, het enige wat je ertegen kan doen is de firmware flashen of secure boot aanzetten in de firmware (heb engels talige versie) om jezelf ertegen te beschermen. De rootkit heeft namelijk geen signed onderdelen waar bij secure boot op wordt gecontroleerd.

[Aardedraadje]

Secure boot is uiteraard een functie van de firmware. Is die firmware gecompromitteerd, dan is secure boot ook niet meer te vertrouwen.

[arcadios2007]

En hoe detecteren we dat onze computers hiermee zijn geïnfecteerd?

[Skywalker27]

Niet hier moet je specifiek naar zoeken, de enige manier is als je raar gedrag waarneemt, maar ja dat kan meerdere oorzaken hebben.

[D11]

Mij lijkt het makkelijkste om daarvoor een transparante sniffer te gebruiken. Deze bekijkt al het netwerk verkeer van en naar jouw computer. Je zult dan zelf moeten uitzoeken wat valide internet verkeer is en wat niet.

Maar als het virus zich rustig houd en zelden/nooit contact zoekt met het internet, dan wordt het erg lastig.

[Skywalker27]

Das leuk maar met 65.000 nodes is dat niet te doen

[D11]

Als je 65.000 nodes hebt/beheerd ga ik ervan uit dat je ook wel een goede firewall hebt die verdacht verkeer voorbij ziet komen.

[Skywalker27]

Dat hebben we DPI maar dan moet je als nog weten waarnaar je zoekt 95% pakje er uit maar die laatste 5% moet je je echt zorgen over maken dat zijn meestal ook de echte rotzakken.

[Aardedraadje]

Niet of nauwelijks. Softwarematig (dus via software op een mogelijk gecomprommiteerd systeem) uitlezen van de firmware (een dump maken van de inhoud van de flash-chip) zou uitkomst kunnen bieden - een kwaadaardige firmware moet dan doen alsof een goedaardige firmware aanwezig is op de flash-chip om de detectie te foppen. Dit betekent dat naast de kwaadaardige firmware ook nog de originele firmware op de chip moet bestaan en dat neemt uiteraard meer ruimte in, wat het voor kwaadaardige firmwares lastig maakt om uit te voeren, maar niet onmogelijk.

De flash-chip direct uitlezen via SPI, en vergelijken met de data van de versie die je verwacht te zien is de enige zekere manier om er achter te komen. Dat zou je al met een simpele Arduino kunnen doen.

[mark.waarden]

Je hebt het niet helemaal begrepen , het staat niet meer op je harddisk maar hij schrijft een aangepaste file weg waarin instructies staan voor de bios dus op de chip op je moederbord.

[Reactie gewijzigd door mark.waarden op 29 juli 2024 19:24]

[musiman]

Niet voor de bios, maar voor de uefi.

[swhnld]

Ik heb een Dell XPS laptop en daar vliegen de bios updates je om de oren, elke paar maanden is er wel een via hun update tool. Geen idee van het nut, maar de recente lekken in processors lijken daarmee afgesloten te worden voor misbruik.
Eerlijk denk ik dat je het nooit helemaal dicht krijgt, zeker niet voor overheden of georganiseerde misdaad die er genoeg geld tegenaan willen en kunnen gooien.

[BikkelZ]

Ik heb een Dell XPS laptop en daar vliegen de bios updates je om de oren, elke paar maanden is er wel een via hun update tool.

Uh ja logisch juist met dit soort en CPU exploits.

[Verwijderd]

Simpel, security vs. usability. We moeten gebruikers instructies geven om te flashen i.v.m. meltdown, spectre, etc. Als we ze dan ook nog moeten gaan uitleggen hoe de PC/laptop/whatever open te schroeven om ergens een piep klein jumpertje om te gaan zetten dan flashed vrijwel niemand z'n bios meer.

[Verwijderd]

Je hoeft niet te flashen voor meltdown / spectre.
Meltdown is software fix en spectre kan je fixen met microcode updates en software fixes.
Meeste besturingssystemen laden microcode in het boot proces en hoeft de gebruiker alleen de updates te installeren van het OS.

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

Omdat security vaak pas prioriteit heeft wanneer het al een probleem is. Ook omdat veel mensen 'braaf' alle updates binnen halen die er zijn - waaronder Uefi/BIOS updates. Of alle Uefi/BIOS updates noodzakelijk zijn is iets anders.

[Aardedraadje]

Dit zie je ook op sommige PC's, zoals mijn Shuttle DH110, waarop een *S25* type flash-IC zit. Dat IC heeft een WE (write enable) pin, en weigert data aan te passen wanneer die pin laag is.

Nadeel van de implementatie van mijn Shuttle PC is dat de UEFI de status van die pin regelt. In principe dus wel veiliger dan helemaal géén write protection, maar een exploit en een stukje malware dat die pin laag maakt en je kunt alsnog de flash overscrhijven met je eigen firmware.

Een jumper is dan nog véél veiliger inderdaad; alleen een backdoor in de flash IC kan dan nog leiden tot geschreven data.

[Reactie gewijzigd door Aardedraadje op 29 juli 2024 19:24]

[Azerox]

Ik kreeg laatst een bios update via windows update, deed herstart, zag het niet, schrok me rot.

[Skywalker27]

HP doet dat ook dat is inderdaad freaky het duurde ook even voordat ie weer ging booten ik dacht even dat m'n nieuwe elitebook gebricked was.

[Rev-anche]

Zo simpel kan het zijn!

En vooral voor bedrijven lijkt me dit een geniale oplossing,
nu de fabrikanten overhalen om een de(r)(g)elijke betaalbare toepassing
toe te voegen op haar producten en we zijn klaar, zou je zeggen?

Liever veilig dan kleurtjes

[Videopac]

Wat was ook alweer het voordeel van UEFI t.o.v. BIOS?

[MPAnnihilator]

Muis kunnen gebruiken, resolutie hoger dan 800x600 enzo, niet ?

[rickboy333]

Het belangrijkste wat ik me kan bedenken is dat UEFI GPT kan gebruiken terwijl BIOS dit niet kan. GPT heeft veel voordelen tov MBR zoals geen geouwehoer met schijven die groter zijn dan 2 TB, je kan ongelimiteerde partitions maken en het is makkelijker om een GPT block te fixen dan een MBR block.

Verder is BIOS gelimiteerd tot 1MB terwijl UEFI in flat mode draait.

En als laatste kan je een EUFI in C schrijven (wat makkelijker is voor de producenten) terwijl je BIOS alleen in Assembly kan schrijven.

[Reactie gewijzigd door rickboy333 op 29 juli 2024 19:24]

[arcadios2007]

Was het dan niet veel eenvoudiger geweest om BIOS zodanig uit te breiden of te herschrijven zodat het al die dingen opeens wél kan, ipv iets nieuws en veel groters dat lekt te maken?

[Rieverst]

Dat is ook gebeurt en noemen ze UEFI.

[keranoz]

Kleine correctie, het is GPT, niet GTP. GUID Partition Table (kon het niet laten).

[t_captain]

Hoe komt zo’n malware op je PC? Moet de aanvaller fysiek toegang hebben?

[LethalRabbid]

Asking the real question here
Tenzij je heel foute dingen begint uit te steken snap ik trouwens in het algemeen al niet hoe een persoon, met meer dan gemiddelde notie van een pc, er in slaagt om enige vorm van malware binnen te trekken...

Een bios/uefi update wordt - naar zover ik merk - ook niet opgedrongen, dus een leek zou dat op die manier ook niet kunnen binnenkrijgen lijkt me....

Aan de andere kant... PC leken kunnen me soms doen verbazen over hun vernielingscapaciteiten..

[keranoz]

Jij en ik gebruiken natuurlijk een ad blocker, maar de gemiddelde denk ik niet. En laat ads nu net een veelgebruikte manier om malware te plaatsen d.m.v. een exploit ofzo..

[MPAnnihilator]

Gewoon via een verkeerde executable file te uitvoeren, via mail ontvangen als meest simpele voorbeeld...
( denk aan bios flash tools die je vanuit Windows kan runnen, maar dan de evil versie )

[Sfynx]

Tja helaas, dit is simpelweg de prijs die we nu betalen voor het nodeloos ingewikkeld maken van firmware wat min of meer een compleet OS is geworden met enorm veel interfaces en bijbehorende aanvalsvectoren. Dan was het BIOSje dat simpelweg een sector op je harddisk uitvoerde en de rest aan het OS overliet toch beter, veel meer controle van de eindgebruiker over wat er allemaal uitgevoerd werd op je systeem, en een geïnfecteerde harde schijf kan je tenminste nog lostrekken. Binnenkort vast een rootkit waarbij de enige fix een SOIC klem en een externe programmer is

[Reactie gewijzigd door Sfynx op 29 juli 2024 19:24]

[CriticalHit_NL]

Tja alles nodeloos ingewikkeld en bloated maken is de mode deze dagen en uiteindelijk raakt het toch wel lek, dan lijken me die problemen ook steeds moeilijker op te lossen ook voor de eindgebruikers.

Wat is er nu zo moeilijk aan dit soort low-level zaken zo simpel mogelijk te houden en elke vorm van schrijf-toegang te blokkeren op de hardware chips zelf.
Misschien denk ik te simpel maar het gebruik van jumpers e.d om bepaalde 'banen' te ontkoppelen zodat het niet meer mogelijk kan zijn lijkt me juist meer dan logisch.

Het is 'leuk' als de software geïnfecteerd raakt van een OS, maar als de firmware van hardware het slachtoffer wordt gaat het wel vele malen verder dan even een simpele image terug zetten, grote kans dat het ook veel meer gaat kosten.

Ze zijn een beetje aan het doorslaan vind ik.

[kodak]

Dit zat er wel aan te komen. In de afgelopen jaren is er al vaker in de security wereld beschreven dat naast bios, firmware, os, applicaties ook uefi gewoon software is dat kwetsbaarheden kent en en dus ook risico geeft dat het mis kan gaan.

Dit is waarschijnlijk niet alleen een actief misbruikte uefi rootkit maar ook een van de eerste actieve rootkits voor uefi die publiek bekend zijn.