OpenWRT bevat beveiligingslek dat remote code execution mogelijk maakt

Het opensource-OpenWRT-besturingssysteem bevat een beveiligingslek dat remote code execution mogelijk maakt. Dit wordt deels veroorzaakt doordat updates voor OpenWRT worden verstrekt met http. Er zijn inmiddels beperkte mitigaties beschikbaar.

Security-researcher Guido Vranken ontdekte het beveiligingslek in OpenWRT, een opensource-besturingssysteem dat vooral wordt gebruikt in embedded apparaten, zoals routers. Hij publiceerde informatie over de kwetsbaarheid op ForAllSecure. Door de kwetsbaarheid kunnen hackers de update-verificatie van het besturingssysteem omzeilen, waardoor ze hun eigen, aangepaste update naar een apparaat kunnen sturen. Deze update wordt vervolgens automatisch geïnstalleerd. Via deze weg kunnen hackers bijvoorbeeld malware installeren die remote code execution mogelijk maakt.

De kwetsbaarheid wordt deels veroorzaakt doordat OpenWRT-updates niet worden verstrekt via https-kanalen, die het onmogelijk zouden maken voor hackers om met geleverde updates te knoeien. In plaats daarvan maakt OpenWRT gebruik van niet-versleutelde http-verbindingen. Volgens Ars Technica is dit vermoedelijk een bewuste keuze van OpenWRT, omdat misschien niet alle apparaten updates via https kunnen ontvangen. Om risico's te verkleinen, gebruikt het besturingssysteem wel sha256-checksums om de legitimiteit van updates te verifiëren, maar volgens Vranken kan die check van digitale signatures relatief gemakkelijk worden omzeild door een spatie aan het begin van een input-string toe te voegen. Deze bug is vermoedelijk al in februari 2017 ontstaan.

Volgens Vranken is het omzeilen van deze digitale signaturechecks erg gemakkelijk voor hackers met 'bescheiden ervaring', zo schrijft Ars Technica. Hij deelt daarbij een proof-of-concept die aantoont dat het uitvoeren van een aanval relatief simpel is op ForAllSecure. Vranken kon met deze exploit een server creëren die zich voordoet als de legitieme OpenWRT-updateserver.

Het lek heeft een enigszins beperkte omvang, omdat een hacker hiervoor een man-in-the-middle-aanval moet uitvoeren of de DNS-server die een apparaat gebruikt om updates te ontvangen, moet manipuleren. Dit betekent dat routers in een netwerk dat niet is geïnfecteerd en dat een veilige dns-server gebruikt, niet direct kunnen worden getroffen. Vranken speculeert dat packet-spoofing en arp-cachevergiftiging misschien ook mogelijk zijn, maar geeft tegelijk aan dat hij dat niet heeft getest.

De beheerders van OpenWRT hebben in februari updates uitgebracht met beperkte mitigaties. De mitigatie vereist nieuwe update-installaties om te worden verstuurd vanuit 'een goed gevormde lijst die hashverificatie niet kan omzeilen'. Tegelijk stelt OpenWRT dat dit geen oplossing is voor de lange termijn, omdat hackers ook een verouderde packagelist kunnen gebruiken om de aanval uit te voeren. De mitigaties zitten in OpenWRT-versies 18.06.7 en 19.07.1.

Door Daan van Monsjou

Nieuwsredacteur

01-04-2020 • 11:21

24

Reacties (24)

24
24
12
1
0
10
Wijzig sortering
Debian had hier een tijd geleden ook last van met de client implementatie van apt. Daar was ook code injectie in mogelijk via een man-in-the-middle aanval.

Conclusies:
1. Schrijf client-side code beter. Vertrouw nooit aangeleverde informatie.
2. Code signing is ondertussen de norm, niet de uitzondering. Implementeer het.
3. Het is 2020, niet 2002. Gebruik server-side enkel TLS en geen pure HTTP meer. Vanaf de volgende grote OpenWRT versie stopt men met het ondersteunen van apparaten met 4 MB opslaggeheugen. TLS ondersteuning moet dus eigenlijk een minimaal vereiste worden voor elk ondersteund apparaat.

Verder:
De mitigaties zitten in OpenWRT-versies 18.06.7 en 19.07.1.
Inmiddels zijn OpenWRT 18.06.8 en 19.07.2 al uit. Dit nieuws is ook al wat oud (van 24 maart).

Verder is de kans op misbruik van deze kwetsbaarheid minimaal. Hoe vaak worden zaken geïnstalleerd op OpenWRT via de package manager? Dat zal incidenteel zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:06]

Er zijn ook commerciële toepassingen van OpenWRT natuurlijk. Daar is de kans op een open verbinding of een slechte implementatie wat groter. Thuisgebruikers lopen eigenlijk geen echt risico

Code signing is goed punt, maar kun je net zo goed een foute implementatie van maken als de checksum implementatie die men nu heeft (genoeg voorbeelden waar de private signing key werd ge-upload naar github oid). Een goede checksum implementatie met size check is ook moeilijk te omzeilen onder normale omstandigheden.
GPG inzetten, hoef je zelf geen implementatie te bouwen.
Het probleem met de huidige vulnerability was dat ze de "standaard" checksum niet goed toepasten. Je kunt GPG inderdaad toevoegen aan je project, maar als je de juiste functie vervolgens niet uitvoert gaat dat ook niet helpen :P

Uit het originele artikel "If OpenWRT’s SHA256 verification had worked as intended, opkg would simply discard the package and not process it"
Punt is dat je zo'n functie (graag echte cryptografische signing dan wel, geen hashfunctie) dan uit de lib van GPG gebruikt en dus niet zelf een faalkans introduceert door iets te schrijven waar je focus helemaal niet ligt.
Heb je gecontroleerd hoe Openwrt de hashes publiceerd? Dat doen ze op de zeer gebruikelijke wijze: shaX hashes in een signed file.

https://openwrt.org/docs/...curity/release_signatures

Dit gebruik van hashes komt rechtstreekt uit he GPG handbook over hoe bestanden te signen: https://www.gnupg.org/gph/en/manual/x215.html
GPG is echt geen ruimte voor in de images van OpenWRT. Het is ongeveer 300KB + nog eens 250KB voor de deps (readline/ncurses) die niet standaard aanwezig zijn. Zelfs TLS ondersteuning via libmbedtls+certs (~260KB) is al een lastige zaak, ook al kan dat nog voor andere dingen nuttig zijn.

Veel routers hebben na bootloader & reserved space zo'n 6.5-7MB beschikbaar voor een hele Linux kernel, het hele root FS, de user configuratie en als het kan nog zo veel mogelijk ruimte voor user packages. Momenteel zijn stock images zo'n 4-5MB groot, maar er zijn ook devices waar ze al een stuk groter zijn. 500KB van de resterende 2.5MB wegpikken moet je een heel erg goede reden voor hebben.
Beveiliging op een correcte manier implementeren is zo'n heel erg goede reden.

En dan nog zou je voor toestellen met meer ruimte een GPG implementatie kunnen gebruiken, en voor toestellen met weinig ruimte een eigen braaksel, ik bedoel, eigen brouwsel.

Embedded software ontwikkelaars moeten maar eens wat minder zeuren en accepteren dat zo goed als al de toestellen de dag van vandaag gigabytes aan of RAM of storage of beide of whatever hebben en dat hun gemierenneuk over een paar kilobytes te besparen gewoon domweg idioot is. Het is zelfs zo dat SoCs en chips met nog steeds die kleine hoeveelheden duurder zijn, zelfs in massa aankoop, dan dingen te nemen die wel groot genoeg zijn. De dagen dat er van iets niet genoeg was (wanneer uitgedrukt in kilobytes), zijn voorbij. Al zo'n 15 jaar of langer.

Als alle OpenWRT routers onveilig werden gemaakt gewoon om voor een handvoel stokoude toestellen een paar kilobytes op de bootloader en/of reserved space te besparen, dan is dat zielig. Gewoonweg extreem slecht programmeerwerk. Dat hoort niet gevierd te worden. Daar moet boe naar geroepen worden.

Eigenlijk, vind ik, er is botweg geen reden meer om opkg te behouden en zou OpenWRT naar volwaardige dpkg moeten gaan. En stoppen met het prulwerk en gehak aan opkg.
Debian had hier een tijd geleden ook last van met de client implementatie van apt. ...

2. Code signing is ondertussen de norm, niet de uitzondering. Implementeer het.
3. Het is 2020, niet 2002. Gebruik server-side enkel TLS en geen pure HTTP meer.
Debian gebruikt signed packages (in plaats van signed executables). Omdat de packages signed zijn is er in principe geen bezwaar ze over plain HTTP te serveren, en plain HTTP maakt cachen op netwerk-niveau mogelijk.

(ik wil daarmee niet zeggen dat je geen punt hebt overigens, en die maatregelen hadden zeker wel kunnen helpen de apt bug die je noemt minder gevaarlijk te maken; ik probeer alleen aan te geven dat er wel redenen zijn voor de huidige constructie)
[...]

Debian gebruikt signed packages (in plaats van signed executables). Omdat de packages signed zijn is er in principe geen bezwaar ze over plain HTTP te serveren, en plain HTTP maakt cachen op netwerk-niveau mogelijk.
Je hebt de link niet gelezen. Er zat een kwetsbaarheid in de apt client waardoor zelf gekozen handtekeningen gebruikt konden worden.

HTTPS is niet 'de' oplossing. Het is 'een' oplossing die één beveiligingslaag toevoegt. Een goede beveiliging heeft meerdere lagen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:06]

Nope
Andersomgezegd meerdere lagen is niet automatisch een goede beveiliging.

B.t.w. Code signing is nooit bedoeld als beveiliging maar als verificatie. Fundamenteel anders.

[Reactie gewijzigd door pe0mot op 23 juli 2024 07:06]

Nope
Andersomgezegd meerdere lagen is niet automatisch een goede beveiliging.

B.t.w. Code signing is nooit bedoeld als beveiliging maar als verificatie. Fundamenteel anders.
Informatiebeveiliging is het geheel van preventieve, detectieve, repressieve en correctieve maatregelen alsmede procedures en processen die de beschikbaarheid, exclusiviteit en integriteit van alle vormen van informatie binnen een organisatie of een maatschappij garanderen, met als doel de continuïteit van de informatie en de informatievoorziening te waarborgen en de eventuele gevolgen van beveiligingsincidenten tot een acceptabel, vooraf bepaald niveau te beperken.
Wikipedia.

Code signing verifieert integriteit en authenticiteit. Dat is zeker informatiebeveiliging.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:06]

Je hebt de link niet gelezen. Er zat een kwetsbaarheid in de apt client waardoor zelf gekozen handtekeningen gebruikt konden worden.
Ik heb de link wel gelezen, en ben ook bekend met de bug hoor. Daarom zeg ik in mijn post ook dat er in principe geen bezwaar is tegen de constructie, en geef ik nog expliciet aan dat gebruik van HTTPS de bug in kwestie minder gevaarlijk had gemaakt.

Mijn post was vooral bedoeld om een stuk context te geven van waarom de constructie zo is als hij is, inclusief de keuze voor HTTP.
2. Code signing is ondertussen de norm, niet de uitzondering. Implementeer het.
Normaal als de packages gesigned zijn maakt het niet uit of je communicatie-kanaal onveilig is: de package manager installeert het gewoonweg niet.

In de eerste link die je gaf is men er in geslaagd (en dit is de echte bug, vind ik) om de file /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg te overschrijven. Dit is natuurlijk niet goed want dat is de signature van de Debian release. Maar had dat niet gelukt, dan had het niet zo geweest dat dpkg die forged packages zomaar zou installeren: het had aan de gebruiker waarschuwingen gegeven dat de package signature niet overeen komt.

Natuurlijk zijn er veel features uit ipkg (en haar fork, opkg) weggelaten t.o.v. dpkg (waarop ipkg en dus later opkg gebaseerd werden). Dus het zou me niet verbazen moesten ipkg en opkg fundamenteel kapot gemaakt zijn t.o.v. dpkg gewoon om een paar megabytes RAM geheugen te besparen. Bijvoorbeeld op die signature checking.

Megabytes die zelfs in het tijdperk van de iPAQ achtige handhelds (waarvoor ipkg gemaakt was) al irrelevant waren. Die toestellen hadden ook bijna allemaal 50MB of meer RAM geheugen. En dus een package manager die package per package serieel afhandelt een megabyte (of zo) laten besparen op een totaal van 50MB available was toen al onzin.

Maar goed. ipkg stripte allerlei features t.o.v dpkg (niet uit, want ipkg was een rewrite in C), en opkg forkte het toen/voor/als OpenWRT's gebruik. En de wereld der routers ging maar verder. Vermoedelijk heeft men al die features die ipkg wegliet t.o.v. dpkg één voor één moeten herimplementeren in opkg. En tja. Nu is het een knoeiboeltje in de package manager van de OpenWRT wereld.

De dag van vandaag hebben alle routers en alle embedded toestellen die een moderne OpenWRT kunnen draaien honderden megabytes aan geheugen, zelfs gigabytes. Het is dus tijd dat ze er gewone dpkg of rpm op gebruiken.
[...]


Normaal als de packages gesigned zijn maakt het niet uit of je communicatie-kanaal onveilig is: de package manager installeert het gewoonweg niet.
Normaliter wel, maar de werkelijkheid is zoals je het hierna omschrijft. Er zijn bugs.

In een ideale wereld is iets als address space layout randomization ook niet nodig als iedereen gewoon goede code schrijft. Zo is de werkelijkheid echter niet. De zwakheden van één beveiligingslaag moeten opgevangen worden door die van een ander.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:06]

Maar, forged packages niet installeren is een fundamental in de beveiliging van besturingssystemen hun package beheer. In de Debian fout die je gaf was dat niet fout maar was het wel mogelijk om de key waarmee nagekeken wordt zelf te overschrijven. Bij opkg blijkt de fout in de code te zitten die de signature van de package vergelijkt.

Stel dat ik van Microsoft een .msi heb en dat Microsoft helemaal geen enkele verificatie doe, dan kan ik als aanvaller vrij eenvoudig de IT afdeling van een bank overtuigen dat een forged .msi van Microsoft komt en dat ze die maar moeten installeren.

Dat is wat ze hier doen.

Bij OpenWRT is het momenteel dus eigenlijk zo dat de gehele signature-checking waardeloos is. Bij Debian is er enkel een probleem wanneer de key overschreven geraakte (wat inderdaad toch wel echt een zeer ernstig probleem is, als dat mogelijk is).

Het maakt m.a.w. normaal niet uit hoe die .msi (die .opk, die .deb. die .rpm) tot bij jouw is gekomen. Over HTTPS, over HTTP, per postduif, sneakernet of per brief.

Wanneer de aanvaller de HTTPS bron in handen heeft kan hij ook met HTTPS de aanval uitvoeren. Dat is bij signed packages niet zo: zelfs al is de bron van waar je de packages afhaalt gehacked, dan nog zal je besturingssysteem de packages niet installeren:omdat de signature verificatie zal falen.
Wanneer de aanvaller de HTTPS bron in handen heeft kan hij ook met HTTPS de aanval uitvoeren.
Klopt, maar je neemt één aanvalsvector weg met HTTPS. Laat perfectie niet de vijand van verbetering zijn.
Laat ik het zo zeggen:

Stel dat ik de NSA niet vertrouw. En ik wil toch Debian gebruiken. Dus ik vertrouw de Debian packagers wel. Want de Debian packagers die gebruiken de bron code die ik op GitHub kan vinden op een zorgvuldige manier.

We weten allemaal dat de NSA nogal eenvoudig een serverpark kan binnenvallen en een Debian mirror zou kunnen overnemen. Ze hebben daar desnoods machtiging voor. M.a.w. zij komen met een wapen, een badge, een bevelschrift en een stfu-bevel voor de eigenaar en medewerkers van het serverpark in handen naar het serverpark en zij nemen letterlijk de fysieke hardware van de Debian mirror over. Zij zetten nu forged Debian packages op die Debian mirror.

Welnu.

Mijn Debian zal die packages niet installeren. Niet zonder mij eerst te waarschuwen.

Dit is iets dat door de fout op OpenWRT momenteel wel kan. HTTPS of niet. M.a.w. OpenWRT's package signing is nu compleet waardeloos.

En de verbinding met HTTPS zou een OpenWRT beheerder kunnen doen denken dat hij of zij veilig is. Terwijl dat niet noodzakelijk zo is. M.a.w. schijnveiligheid.

Zo'n beetje zoals vinyl handschoentjes en een mondmasker dragen terwijl je 60 meter verwijderd van alle mensen aan het joggen bent dus.

@The Zep Man hieronder (edit, want we blijven maar doorgaan): "Dat zou enkel code signing ook kunnen zijn. Dat is geen goed argument."

Indien code signing goed geïmplementeerd wordt in een package beheerder, dan is code signing geen schijnveiligheid. Een HTTPS verbinding is dat in zeker zin wel (zoals ik zonet hierboven uitlegde, dat is een scenario waar de HTTPS verbinding een schijnveiligheid is). Een HTTPS verbinding is niet nodig bij goede code signing. Dat is het hem nu net. Het maakt letterlijk niet uit van waar de package komt: de signature moet overeen komen. Dus forged packages kunnen bij goede code signing niet, nooit (dit is trouwens ook zo bij Windows, met haar MSI packages, en/of NuGet ook). Merk op dat HTTPS met goede certificaten al heel wat minder een schijnveiligheid is. Maar ook certificaat-servers zijn al geforged geweest door bv. geheime diensten (dit is al wel heel uitzonderlijk natuurlijk). Bij signed packages maakt zelfs dat niet uit.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:06]

En de verbinding met HTTPS zou een OpenWRT beheerder kunnen doen denken dat hij of zij veilig is. Terwijl dat niet noodzakelijk zo is. M.a.w. schijnveiligheid.
Dat zou enkel code signing ook kunnen zijn. Dat is geen goed argument.

Zowel (goede) code signing (tegen gecompromitteerde pakketten) als HTTPS (tegen misbruik van bugs in de package manager software) zijn nodig om beveiliging op meerdere lagen toe te passen.

[edit]
Indien code signing goed geïmplementeerd wordt in een package beheerder, dan is code signing geen schijnveiligheid.
Je kan er niet vanuit gaan dat code signing 'goed' is geïmplementeerd. HTTPS biedt aantoonbaar bescherming tegen één aanvalsscenario, en heeft daarom in alle genoemde situaties toegevoegde waarde. Het is daarom geen schijnveiligheid. Verder moeten brakke beheerders geen excuus zijn om iets niet veiliger te maken.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:06]

Ik installeer al mn apps via de package manager.. hoe anders? Los downloaden en dan installeren en dan erachter komen dat je een verkeerde build hebt of oude versie..
Waarom zit er anders een uitgebreide package manager in ?

Dus nee incidenteel lijkt me niet
Ik vind de beschrijving van deze bug in de media bizar. De bug zit in de signatuur verificatie, wat op zich redelijk recht toe recht aan code is ... zeker ten opzichte van https.

Als extra laag bescherming had https wel aardig geweest maar het is niet de oorzaak van het probleem. Je zou bijna denken dat met deze berichtgeving geprobeerd word af te leiden van de feitelijke code die het probleem veroorzaakt. Code waarvan als ik naar de diff kijk mij toch afvraag van hoe dat heeft kunnen gebeuren ...
Hmm, wat een overdreven sensationele titel zeg. Om dit mogelijk te maken, moet je dus:
- handmatig packages installeren
- over http (bij mij loopt het over https)
- er moet een mitm plaatsvinden
- er moet een aangepaste package met malware geinstalleerd worden

Als dat allemaal gebeurt (wat me vrij lastig lijkt), dan zou het kunnen. Ik denk eigenlijk dat de meeste mensen die openWRT installeren niet met de hand packages installeren of updaten. En zij die dat wel doen, zullen op een recente versie zitten die het probleem niet heeft en/of bv https gebruiken, waardoor ze er ook geen last van hebben.

Het is zonder meer een kwalijke bug, maar om het nu direct als RCE weg te zetten gaat me wat ver, want dat is het niet!
... Wilde ik dus net OpenWRT op een a.p. zetten.
Dit lek is voor een normaal netwerk niet of nauwelijks uit te buiten. Een aanvaller moet ARP-spoofing of een DNS-overname doen op de verbinding tussen je router en je AP wil dit iets uitmaken. Dit is iets waar ik me in een bedrijf misschien zorgen over zou maken, maar in je thuisnetwerk zal het allemaal wel zijn gangetje gaan.

Wil je het probleem helemaal oplossen, kun je op je AP HTTPS aanzetten voor opkg. Hiermee voorkom je dat de MitM, die nodig is de aanval uit te voeren, mogelijk is.

Op dit item kan niet meer gereageerd worden.