Onderzoekers presenteren lekken in uefi-updateproces van Asus en ASRock

Onderzoekers van beveiligingsbedrijf Eclypsium hebben op Black Hat kwetsbaarheden uit de doeken gedaan in de uefi-firmware van Asus en ASRock, specifieker in de functie om een update via internet uit te voeren.

De onderzoekers, Jesse Michael, Oleksandr Bazhaniuk en Mickey Shkatov, gingen in hun presentatie in op aanvallen die op afstand op firmware uitgevoerd kunnen worden, zonder fysieke toegang. Ze hadden verschillende systemen onder de loep genomen en waren daarbij op lekken gestuit in de firmware van Asus en ASRock. Zo kwamen ze erachter dat deze een functie bieden om een bios-update via internet uit te voeren vanuit uefi zelf. Verschillende fabrikanten bieden een dergelijke functie aan in de vorm van een eigen implementatie. In het geval van de genoemde fabrikanten vindt het updateproces plaats via http, wat het voor een aanvaller bijvoorbeeld mogelijk maakt om verkeer naar de updateserver te onderscheppen zolang hij zich in een man-in-the-middle-positie bevindt.

Op die manier zou een aanvaller bijvoorbeeld een kwaadaardige update kunnen aanbieden, stellen de onderzoekers. Die zou vervolgens gebruik kunnen maken van lekken in de uefi-firmware om vervolgens een systeem over te nemen. Bij zowel Asus en ASRock vonden ze een dergelijk lek in de vorm van een buffer overflow. In een demo lieten ze zien hoe ze via een kwaadaardige update een shell konden openen binnen uefi door deze met de payload mee te leveren. In de demo was de shell zichtbaar, maar volgens de onderzoekers is het ook mogelijk om deze buiten het zicht van het slachtoffer te openen.

ASRock heeft inmiddels patches doorgevoerd. Een van de onderzoekers zei tegen Tweakers dat de fabrikant het kwetsbare uefi-onderdeel had uitgeschakeld, maar bijvoorbeeld niet tls had geïmplementeerd. De fabrikant zou wel aan een definitieve patch werken. Asus liet aan de onderzoekers weten dat het hun bevindingen niet als een beveiligingsprobleem beschouwde.

Hoewel het door de onderzoeker geschetste aanvalsscenario niet direct een risico voor een grote groep gebruikers vormt, wijzen ze erop dat uefi-varianten van steeds meer functies worden voorzien. Ze noemen voorbeelden als het toevoegen van bluetooth- en wifi-ondersteuning in bios. Een ander voorbeeld is dat HP een functie voor servers aanbiedt waarmee firmware en drivers direct vanuit uefi via internet gedownload kunnen worden. Dat zou systemen mogelijk blootstellen voor meer aanvallen op afstand.

In het kader van hun presentatie verwijzen de onderzoekers ook naar zogenaamde bmc's, oftewel baseboard management controllers. Dat zijn zelfstandige systemen met een eigen processor en geheugen die gebruikt kunnen worden om een server op afstand te beheren, bijvoorbeeld om temperatuur, spanning en ventilatoren in de gaten te houden. Deze systemen staan automatisch aan zodra de server voorzien is van stroom en beschikken zijn volgens de onderzoekers over een eigen networking stack.

In een andere Black Hat-presentatie, getiteld The Unbearable Lightness of BMC's, toonden onderzoekers aan op welke manieren een dergelijke bmc aan te vallen is, bijvoorbeeld om een server in een datacenter over te nemen of verder een netwerk binnen te dringen. Met betrekking tot uefi stellen de Eclypsium-onderzoekers voor om bijvoorbeeld beveiligingsmaatregelen als aslr te implementeren. Maar ook al worden die suggesties overgenomen, zou het nog lange tijd duren voordat deze uiteindelijk daadwerkelijk door fabrikanten worden overgenomen.

Reacties (25)

[The Zep Man]

n het geval van de genoemde fabrikanten vindt het updateproces plaats via http, wat het voor een aanvaller bijvoorbeeld mogelijk maakt om verkeer naar de updateserver te onderscheppen zolang hij zich in een man-in-the-middle-positie bevindt.

Dat zou niet erg hoeven zijn zolang er een controle plaats vindt op de authenticiteit en integriteit van het te ontvangen image, en zolang het downloadproces zelf maar veilig is.

Zelf update ik liever via een 'ouderwetse' USB stick of via SPI. Het geluk heeft dat moderne Asrock moederborden voor dat laatste gewoon een header hebben. Raspberry Pi eraan en gaan.

[MrBreaker]

Zie de gemiddelde gebruiker niet via SPI iets flashen. De meeste zullen niet eens de pinout snappen, laat staan de overige instructies.

[The Zep Man]

Zie de gemiddelde gebruiker niet via SPI iets flashen.

Een gemiddelde gebruiker flasht sowieso niet.

[Aardedraadje]

Dat gebeurt (gebeurde?) niet. Ik had ooit een Asus N55SF laptop waarop de AES-NI instructies vanuit de bios hardcoded uitgeschakeld stonden. Door de BIOS aan te passen heb ik toen die AES-NI enable bits aangezet en geflashed. Dat ging zonder geklaag.

[GebakkePizza]

Asus liet aan de onderzoekers weten dat het hun bevindingen niet als een beveiligingsprobleem beschouwde.

Oké, hier maakt Asus een heel duidelijk statement. Maar hoe durven ze, als één van de marktleiders op gebied van basis-componenten, deze houding aan te nemen? Hebben ze er geen zin meer in? Voor mij betekent dit dat ik in de toekomst extra ver van Asus ga blijven. Helaas moet ik het nou nog even doen met een Asus moederbord.

[Reactie gewijzigd door GebakkePizza op 29 juli 2024 01:30]

[MrBreaker]

Je vraagt je idd af waar zo'n stelling van Asus dan op is gebaseerd? Is dat naïviteit, gebrek aan inzicht, of weten ze iets wat de onderzoekers niet weten?

[unilythe]

Ik zou toch eerst even wachten met conclusies trekken tot er misschien verder wordt uitgelegd waarom dit geen probleem is volgens ASUS. Je trekt wel erg snel conclusies hier. Misschien heeft ASUS wel gewoon een goede reden om te zeggen dat er geen beveiligingsprobleem is.

[Bor]

ASRock heeft inmiddels patches doorgevoerd. Een van de onderzoekers zei tegen Tweakers dat de fabrikant het kwetsbare uefi-onderdeel had uitgeschakeld, maar bijvoorbeeld niet tls had geïmplementeerd. De fabrikant zou wel aan een definitieve patch werken. Asus liet aan de onderzoekers weten dat het hun bevindingen niet als een beveiligingsprobleem beschouwde.

Bijzonder om te zien dat de ene fabrikant die min of meer bekend staat als budget speler (Asrock) aangeeft aan een definitieve patch te werken terwijl Asus aangeeft het punt niet als beveiligingsrisico te zien.

Ik ben benieuwd of dat echter wel de hele statement van Asus is. Ik mis hier een behoorlijk stuk onderbouwing vanaf Asus. Welke risico's heeft men afgewogen en op basis van welke argumenten blijkt dit geen risico of probleem?

Verschillende fabrikanten bieden een dergelijke functie aan in de vorm van een eigen implementatie.

Zit hem in bovenstaande niet deel van het probleem? Verschillende eigen implementaties leidt tot verschillende oplossingen, geen standaardisatie en risico's als we nu zien waarbij de ene leverancier een kwetsbaarheid wil afdekken maar waarbij de andere min of meer aangeeft het wel goed te vinden zo.

[screenager]

Asrock is allang geen budget merk meer, Asus daarentegen vind ik wel een budget merk geworden.
De ondersteuning bij Asus is ondermaats en kwalitatief is het gewoon minder dan andere merken.

[Drannoying]

De kwaliteit van de vrm componenten etc van de Asus rog moederborden zijn een van de beste op de markt (zie actually hardcore overclocking) of (buildzoid) op youtube...

[Cerberus_tm]

Geldt dat ook voor de goedkopere moederborden van Asus?

[Drannoying]

Nee ik heb het hier over de “echte” rog moederborden dus de hero etc... Dit is ook exclusief de Rog Strix want deze moederborden zijn namelijk niet heel bijzonder op dat front.

[Cerberus_tm]

OK en je weet niet hoe het gesteld is met de vrm's van de goedkopere borden?

[Drannoying]

Daarvoor verwijs ik je liever door naar ''Actually Hardcore Overclocking''. Dit kanaal vergelijkt de kwaliteit van moederborden op vrm level. Ook van videokaarten trouwens .

[Cerberus_tm]

OK.

[lezzmeister]

Ik mijd Asus al een decennium omwille van slechte ervaringen met bios van hen.

[Niemand_Anders]

Asus lijkt de laatste tijd aardig wat steekjes te laten vallen.. Nu is het de online update mogelijkheid, maar eerder waren er ook issues met de load line calibration, zie ook deze video van OC3D: https://www.youtube.com/watch?v=hCAQpvFhiUs

Echter de steekjes zitten vooral op firmware niveau. De hardware zelf is nog steeds van uitzonderlijk hoge kwaliteit. ASRock is naar mijn mening zeker ook doorgedrongen tot de premium merken. Daarbij zijn ze niet bang om dingen anders te doen. Zo waren zij de eerste welke de X99 op een ITX board plaatste, maar ook de eerste welke 3 M.2 slots op een Z170 board plaatsen waarbij RAID 0 mogelijk was..

Ik had op een ASRock Z170 formula board twee Samsung SM961 (512GB) SSD's in RAID 0 staan. Sequencial read en write performance was fantastisch. Echter na ongeveer een jaar begon ik af en toe haperingen te merken in visual studio bij het laden van grote projecten. Maar ook al een paar keer bij het restoren van een database van een 50-100GB. Rond de kerst heb ik mijn werk PC opnieuw geinstalleerd en heb ik de RAID 0 veranderd in twee losse SSD's. Sindsdien geen issues meer met haperingen op de SSD's. Voor mij geen (onboard) intel raid meer. Daarbij doe ik ook niet elke dag een database restoren..

[_JGC_]

Asrock maakt allang geen goedkope zooi meer, hun borden zijn door de jaren heen duurder geworden terwijl de A merken budget borden zijn gaan maken.

In het verleden wel ACPI problemen gehad op linux door bugs in BIOS. Asus: het werkt op windows, zoek het maar uit. Asrock: hier heb je een beta bios, kan je voor ons testen?

[robvanwijk]

Ik ben benieuwd of dat echter wel de hele statement van Asus is.

Daar lijkt het wel op: ze hebben er "Dear sender" boven staan, "Best regards" eronder en geen enkele indicatie dat ze ergens geknipt hebben. Twee mogelijkheden: binnen hele korte tijd komt er een ontzettend kwade tweet (of whatever) van Asus waarin ze de onderzoekers erop wijzen dat je in een situatie als deze wel de volledige reactie moet tonen... of dit was echt de volledige onderbouwing.

Ik mis hier een behoorlijk stuk onderbouwing vanaf Asus. Welke risico's heeft men afgewogen en op basis van welke argumenten blijkt dit geen risico of probleem?

Als ik een gokje mag wagen: als het enige probleem de HTTP-verbinding is, dan vinden ze waarschijnlijk dat het niet "op commando" uit te buiten is, want het update-proces moet nog steeds vanaf de kant van de computer zelf gestart worden.

Normaal zou je nog denken dat ze hun image gesigned hebben (zelfs als je de HTTP-download aanpast, dan wordt de update alsnog niet geïnstalleerd), maar als ik het artikel goed lees hebben ze een demo gegeven van een werkende aanval, dus in dat geval wordt het heel simpel. Geen idee wat ze afgewogen hebben, maar ze hebben de afweging behoorlijk verprutst.

Verschillende eigen implementaties leidt tot verschillende oplossingen

Dat vergroot de kans dat een aantal systemen lek zijn, maar het verkleint de kans dat nagenoeg iedereen kwetsbaar is. Kijk naar Intel; als zij een lek hebben in hun Management Engine, dan is bijna de hele wereld in één klap kwetsbaar; dat is ook geen wenselijke situatie. Ik vrees dat geen van beide oplossingen (ieder voor zich vs één gezamenlijke standaard) echt ideaal is.

[freeco]

Off-topic: ik heb die functie om te updaten via internet al zien staan op mijn Asus Z170M-Plus, maar die is greyed out...
Ik download gewoon de zip van de support site, extract 'm ergens lokaal, en update dan vanuit de UEFI met die lokale file. Misschien iets omslachtiger, maar werkt prima...

[Username3457829]

Ook alle driver downloads van de Dell pagina's lopen via http valt mij al een tijd lang op.
Er staat dan wel weer altijd een MD1, SHA1 en SHA256 code met daarbij: Verifieer de checksum-waarde om de integriteit van uw download te garanderen.

Maarja hoe je dat dan controleert is weer een andere vraag

[Alex3]

Dat zal dan MD5 zijn, niet MD1, dat is wel erg antiek. Je kunt ze controleren door een programma te schrijven:
https://en.wikipedia.org/wiki/MD5
https://en.wikipedia.org/wiki/SHA-1
https://en.wikipedia.org/wiki/SHA-2
Je kunt ze ook op verschillende plaatsen downloaden.

[inferno96]

Is helemaal niet zo moeilijk. Je installeert een checksum tool zoals bv. http://code.kliu.org/hashcheck/
Je kan dan als je op eigenschappen klikt in Windows Explorer de checksums zien in een aparte tab en dan vergelijk je de twee checksums met elkaar.

[Knightwolf]

Net zoals altijd zou ik niet weten waarom ik vanuit de UEFI/BIOS direct via internet zou updaten. Je hebt totaal geen zicht over waar het bestand vandaan komt. Gewoon eerst via de website van ASUS de nieuwste BIOS downloaden en op een USB-stick zetten. Dan in de BIOS die gewoon selecteren en updaten. Zo'n ontzettend kleine moeite, en dit hele "beveiligingsprobleem" doet zich niet meer voor. Waarom moeilijk doen als het makkelijk kan?

[Zyphrax]

Wat mij betreft bieden ze BIOS updates aan via bestaande mechanismes zoals Windows Update. Door middel van signatures kun je garanderen dat de update wel bij ASUS, ASRock of welke leverancier dan ook vandaan komt.

Ik heb persoonlijk een hekel aan alle "tooltjes" van fabrikanten, allemaal weer met een eigen setup / rommelige layout / nukken en grillen. Anno 2018 moet het ook nog regelmatig in de root van je schijf geïnstalleerd worden.

Bij Apple zijn de firmware updates onderdeel van de OS updates. Al is het voor hen een stuk makkelijker omdat zij de firmware zelf van kop tot staart beheren.

De update vanuit de BIOS zou wel via HTTPS moeten lopen. Ik begrijp dat dit een stuk meer werk is voor de fabrikanten, want je hebt dan een SSL client implementatie nodig. Als dat te ingewikkeld is, dan denk ik nog steeds aan HTTP maar ook dan digital signatures.