Het gebruik van Whitelists om Firmware beveiliging te verbeteren

Firmware is populairder geworden in de wereld van Computer security research. Aanvallen die op firmwareniveau werken, kunnen moeilijk te ontdekken zijn en hebben het potentieel om zelfs in Bare-metal herstelscenario ‘ s te blijven bestaan. Dit type hack is goed gedocumenteerd door onderzoeken van het HackingTeam en Vault7 exploits.

gelukkig zijn er methoden om dergelijke aanvallen op te sporen en te verdedigen. Firmware-gebaseerde aanvallen meestal proberen toe te voegen of te wijzigen systeem firmware modules opgeslagen in NVRAM. Hulpmiddelen van het Open source CHIPSEC-project kunnen worden gebruikt om hashes van deze modules te genereren en te verifiëren, zodat gebruikers ongeautoriseerde wijzigingen kunnen detecteren.CHISPEC, geïntroduceerd in maart 2014, is een raamwerk voor het analyseren van de beveiliging op platformniveau van hardware, apparaten, systeemfirmware, laag-niveau beschermingsmechanismen en de configuratie van verschillende platformcomponenten. Het bevat een set van modules, waaronder eenvoudige tests voor hardware beveiligingen en correcte configuratie, tests voor kwetsbaarheden in firmware en platform componenten, security assessment en fuzzing tools voor verschillende platform apparaten en interfaces, en tools verwerven van kritische firmware en apparaat artefacten.

de whitelist module (tools.uefi.whitelist) gebruikt CHIPSEC om een lijst van EFI uitvoerbare bestanden uit een binaire firmware image te extraheren, en bouwt een lijst van “verwachte” uitvoerbare bestanden en bijbehorende hashes (.JSON-bestand) later te gebruiken voor vergelijking. Documentatie is beschikbaar als onderdeel van de module broncode op github, en in de CHIPSEC handleiding.

het proces gaat ervan uit dat u begint met een “bekende goede firmwareafbeelding”, bij voorkeur een productieversie van de firmware die door de fabrikant wordt geleverd, en dat u CHIPSEC hebt gebruikt om bekende problemen op te sporen voordat u per ongeluk iets smerigs op de witte lijst plaatst. Dit voorbeeld gebruikt de open source UEFI firmware voor de MinnowBoard tarbot (release 0.97), voor een betere zichtbaarheid in het proces.

de volgende CHIPSEC opdrachtregel maakt een whitelist genaamd efilist.json gebaseerd op een” bekende goede afbeelding ” (platform_fw.bin):

python chipsec_main.py -i -n -m tools.uefi.whitelist -a generate,efilist.json,platform_fw.bin

dit proces toepassen op de x64″ release “en” debug ” images van de MinnowBoard tarbot 0.97 firmware produceert de volgende whitelists:

• MNW2MAX1.X64. 0097.D01.1709211100.bin (UEFI x64 firmware, debug mode) – X64D97_whitelist.json
• MNW2MAX1.X64. 0097.R01.1709211052.bin (UEFI x64 firmware, release mode) – X64R97_whitelist.json

(oefening voor de lezer: download de firmware images, voer CHIPSEC uit, kijk of je whitelist overeenkomt)

het is belangrijk op te merken dat het resulterende JSON whitelist bestand niet alleen een hash van het binaire bestand is, het bevat hashes van de uitvoerbare modules van de firmware image. CHIPSEC heeft de mogelijkheid om te scannen en catalogus individuele firmware componenten, die kunnen worden gebruikt om whitelist of blacklist specifieke uitvoerbare bestanden.

Whitelists plaatsen

als u een systeemfabrikant bent, kunt u deze whitelists publiceren voor klantverificatie. Het is echter het beste om bestanden te ondertekenen voor verificatiedoeleinden. Om ervoor te zorgen dat de door een eindgebruiker verkregen whitelist de officiële whitelist is, kan deze worden ondertekend met GPG met behulp van een losse handtekening:

gpg –detach-sign <file>

bovendien moeten gebruikers certificaten verifiëren voor een bekende domeinnaam voor de systeemfabrikant wanneer deze via HTTPS wordt geleverd. Het is ook aan te raden voor IT-organisaties om intern gegenereerde whitelists te ondertekenen om te voorkomen dat ongeautoriseerde lijsten worden gebruikt in audits.

Whitelists controleren

als een losse ondertekening beschikbaar is, kan GPG worden gebruikt om het whitelistbestand te controleren:

gpg –verify <file>

zodra de authenticiteit van de whitelist is geverifieerd, moet de gebruiker een afbeelding van de firmware van het platform maken met behulp van CHIPSEC. Deze opdrachtregel gebruikte het’ dump ‘ commando om user_fw te genereren.bin:

python chipsec_util.py spi dump user_fw.bin

nu CHIPSEC kan worden gebruikt om het platform firmware image te verifiëren tegen de bijbehorende whitelist. Dit voorbeeld verifieert tegen de x64″ release ” image voor Minnowboard tarbot 0.97:

python chipsec_main.py -i -n -m tools.uefi.whitelist -a check,X64REL_whitelist.json,user_fw.bin

op dit punt zal CHIPSEC een “geslaagd” of “waarschuwing” status retourneren. Als de test returns “geslaagd”, alle hashes werden gevonden in de whitelist en ze overeenkomen met de verwachte waarden. Als de test geeft “waarschuwing”, was dan iets anders. Merk op dat een” waarschuwing ” tegen niet onmiddellijk een veiligheidsbedreiging aangeeft (bijvoorbeeld: gebruiker kan zijn bijgewerkt naar de nieuwste firmware van de fabrikant), maar het vereist onderzoek om ervoor te zorgen dat de gewijzigde firmware-afbeelding niet te wijten is aan een poging tot aanval.

beperkingen

met behulp van hulpmiddelen zoals CHIPSEC kan dit de beveiliging verbeteren, maar geen enkel systeem kan absoluut veilig zijn, en deze procedures kunnen zich niet verdedigen tegen alle mogelijke aanvallen. Er zijn een aantal beperkingen te overwegen bij het interpreteren van whitelist resultaten:

• er kunnen aangepaste of eigen beeldverpakkingsmethoden zijn die CHIPSEC niet begrijpt. Dit kan ertoe leiden dat sommige modules worden uitgesloten, zodat overeenkomstige wijzigingen kunnen worden gemist tijdens een whitelist vergelijking.
• Software die draait op een reeds gecompromitteerd systeem kan voor de gek worden gehouden. Als een systeem al gecompromitteerd is, kunnen CHIPSEC en soortgelijke software geen betrouwbare indicatoren produceren.

samenvatting

de mogelijkheid voor CHIPSEC om whitelists te genereren biedt een methode voor het valideren van de firmware supply chain. Fabrikanten kunnen deze tools gebruiken om gebruikers te helpen bij het verifiëren van officiële firmware-releases, en IT-beheerders kunnen whitelists genereren voor interne audits op basis van vertrouwde afbeeldingen.