Lek in webinterface Pi-Hole maakte remote code execution mogelijk

Een beveiligingsonderzoeker heeft een lek ontdekt in Pi-Hole waarmee een remote code execution mogelijk was. Inmiddels is dat opgelost. Aanvallers konden het lek ook uitbuiten van buitenaf als zij konden inloggen in de interface.

Het lek zat in de manier waarop gebruikers in de webinterface mac-adressen moesten invoeren. De onderzoeker schrijft dat de applicatie daarbij de input niet juist valideerde. Het was daardoor mogelijk in plaats van een mac-adres willekeurige code in te voeren. Er zitten wel wat obstakels aan die methode. Zo mag die code geen hoofdletters bevatten, terwijl Linux-commando's wel hoofdlettergevoelig zijn. Ook moet een aanvaller in de eerste plaats kunnen inloggen op de webinterface. Lang niet alle Pi-Hole-gebruikers hebben hun systeem naar buiten open staan..

De ontdekker vond naar eigen zeggen via Shodan 150 Pi-Hole-machines die vanaf het internet bereikbaar waren. Het lek zit in versie 4.3.2 van Pi-Hole. Dat is de versie uit september 2019. Inmiddels zijn nieuwere versies uitgebracht waarin het lek verholpen is, nadat de onderzoeker dat aan de makers vertelde.

Door Tijs Hofmans

Nieuwscoördinator

31-03-2020 • 07:31

69

Submitter: n9iels

Reacties (69)

69
67
40
1
0
19
Wijzig sortering
"Ook moet een aanvaller in de eerste plaats kunnen inloggen op de webinterface, wat lang niet bij iedere Pi-Hole-gebruiker het geval is."

Dat klopt, maar er is meer voor nodig. De aanvaller moet niet alleen kunnen inloggen, d.w.z. dat de webinterface benaderbaar is, hij moet ook het admin password weten. M.a.w. alleen als je ingelogd bent met het admin password was deze vulnerability te exploiten. Dat had wel iets duidelijker in het artikel gemogen imho.

Bron: https://www.reddit.com/r/...ecution_detailed/flqx9k2/

[Reactie gewijzigd door Freekers op 23 juli 2024 21:21]

Ik dacht al. Vind de titel van het artikel toch wel een beetje clickbait: er had bij moeten staan, "als hacker admin-wachtwoord heeft".
Hoe zit dit in geval van een docker container zonder root rechten? Voor zover ik weet is het dan niet mogelijk buiten de container te komen. Of zie ik iets over het hoofd?
Het is zeker wel mogelijk om uit een container te breken, daar zijn al artikels over geschreven.

Bijvoorbeeld:
https://unit42.paloaltone...explaining-cve-2019-5736/
Docker is helaas niet heilig, standaard draaien deze containers gewoon onder root, dus als je uit een container breekt dan heb je de volledige root rechten.
Podman (drop-in Docker replacement) zou deze ontwerpfout verhelpen. Moet er nog induiken..
Hoe zit dit in geval van een docker container zonder root rechten? Voor zover ik weet is het dan niet mogelijk buiten de container te komen. Of zie ik iets over het hoofd?
Containers do not contain. Dat is een ouder artikel, maar de principes gelden nog steeds.
Het lijkt me sowieso geen goed idee om Pi-hole openbaar te maken, maar desondanks wel een pijnlijke bevinding.
Niet openbaar maken? De bug zit in een php script, die is dus door zijn aard al openbaar.
Niet waar. Pi Hole is iets wat je op je lokaal netwerk draait. Het adminpaneel ervan stel je normaal gezien niet zomaar beschikbaar buiten je lokale netwerk. Het feit dat het een PHP script is, doet daar eigenlijk niet toe.
Inderdaad. Een pihole draait lokaal, achter een firewall en nat. Daar moet je helemaal niet bij kunnen komen.

"De ontdekker vond naar eigen zeggen via Shodan 150 Pi-Hole-machines die vanaf het internet bereikbaar waren"

Dit is ontgaat me totaal, hoe krijg je dit überhaupt voor elkaar?? Een pihole publiekelijk toegankelijk maken? Zit hardop te bedenken hoe je dit voor elkaar zou moeten krijgen???
In je router port 80 forwarden naar de machine waar pihole op draait, en dan nog wat extra configuratie om de web interface ook buiten je netwerk toe te laten. Het kan. Tijdens de installatie meen ik mij te herinneren dat die optie aangeboden werd (minus het port forwarden dan) maar dat er ook wel heel duidelijk bij stond dat het geen strak plan is.
Uiteraard kan je een poortje opengooien; mijn strekking was meer, waarom zou je dit willen? Alleen omdat je op afstand naar een interface-je kan bekijken ten koste van een enorm veiligheids risico? Met "hoe je dit voor elkaar zou krijgen" bedoel ik: standaard bij een consumenten setup zit de boel dicht. Dan gaat men dus bewust een port forwarden, firewall openzetten, om een grafiekje van een pi-hole op afstand te kunnen zien? 8)7
Vaak staat die optie standaard ook UIT.

in mijn Pi-hole heb ik dit tevens ook niet aangezet.
Want ik heb dit zelf niet nodig,

Wie gebruikt het eigenlijk? als je een nieuwe lijst van sites/domeinen hebt die je wilt blokkeren zet je de URL gewoon in een text file en voegt ze later toe zodra je weer in je thuisnetwerk zit.
Dit is ontgaat me totaal, hoe krijg je dit überhaupt voor elkaar?
Door native IPv6 te draaien, zonder firewalling. Dan is het heel goed mogelijk om onbedoeld poorten open te zetten naar 'Hello World'.
Ah, sorry. Ik vatte je opmerking op in de betekenis van open source vs closed source.
Er wordt met regelmaat lekken gevonden in geschreven code, zo pijnlijk vind ik het dus niet. Ik denk zelfs dat je bij ieder project wel minstens één of meer exploits vind door verkeerde validatie.

Het lek valt opzicht mee omdat de web interface bereikbaar moet zijn van buitenaf, al zou het ook voor LAN niet echt fijn zijn.
Goed dat het verholpen is. Ik zet niks open naar de boze buitenwereld. Behalve mijn vpn, iin mijn optiek de veiligste methode om toch bereikbaar te zijn van buiten af.
Pihole, en vele andere fijne programma's zijn gewoon niiet gebouwd om direct beschikbaar te zijn vanaf buitenaf.
Hoe intern is je intern netwerk als je het vol met smart apparatuur hangt of computers die mogelijk compromised zijn? Windows 10 heeft nog steeds zero day exploits.
Dan gebruik je toch gewoon een appart netwerk voor je smarthome, die via een Vlan en een extra router op een geheel ander subnet zit.
of als je echt paranoide bent een apparte router zonder netwerk toegang
Ik ken de oplossingen. Maar dat gaat iemand die denkt dat zijn intern netwerk veilig is niet doen.
Pihole, en vele andere fijne programma's zijn gewoon niiet gebouwd om direct beschikbaar te zijn vanaf buitenaf.
Daar hebben de beveiliginsexperts geen boodschap aan. Als zij een audit doen gaan ze iedere applicatie van dichtbij testen. Met het idee van: als je er direct niet in komt kom je er van buiten zeker niet in. In de wetenschap dat veel inbraken interne jobs zijn is dat m.i. de beste aanpak. Voor een thuissituatie uiteraard minder relevant maar alle software die bedrijfsmatig wordt gebruikt zou volgens die filosofie veilig moeten zijn.
Een XSS https://owasp.org/www-community/attacks/xss/ bug dus? Vreemd dat die er nu pas uitkomt, validatie van velden lijkt me nu geen code die elke versie aangepast wordt.

Nuja .. om dit echt te gaan exploiten moet je je pihole web interface toch al open staan hebben richting internet.

Edit: dat laatste stond in de titel zelf, oops :)

[Reactie gewijzigd door kristofv op 23 juli 2024 21:21]

Hoe je het ook noemt (ik zou gaan voor command injection), in ieder geval wordt er nagelaten input te valideren.
Gevolg is idd dat je ook een commando als input kan geven.

Regel 1 van software ontwikkelen is en blijft dan ook vertrouw je klanten/input niet en check de invoer!

[Edit: naam command injection toegevoegd]

[Reactie gewijzigd door Pep7777 op 23 juli 2024 21:21]

Hoe je het ook noemt (ik zou gaan voor command injection), in ieder geval wordt er nagelaten input te valideren.
Nee, er staat letterlijk dat dit wel aanwezig is,zie deze zin:
Er zitten wel wat obstakels aan die methode. Zo mag die code geen hoofdletters bevatten, terwijl Linux-commando's wel hoofdlettergevoelig zijn.

De code die de validatie uitvoert is gewoon slecht, wat het verhaal vreemd maakt. Je zou echt wel verwachten dat dit al veel eerder zou bovengekomen zijn.
Je hebt gelijk, er vond wel degelijk validatie plaats :)

function validMAC($mac_addr)
{
// Accepted input format: 00:01:02:1A:5F:FF (characters may be lower case)
return (preg_match('/([a-fA-F0-9]{2}[:]?){6}/', $mac_addr) == 1);
}

Pff hier had ik met codereview ook volledig langs kunnen kijken, probleem is als het begint met een mac-address dan matched het. En alles daarna word gewoon meegekopieerd (en dan naar hoofdletters omgezet).
Dus of de regex moet gedetallieerder of er moet een check op lengte van de input bij.

De HEX2BIN in het verslag is dan wel weer heel creatief :)
Had al zo'n vermoeden dat het om een brakke regex zou gaan :)

Its always regex bij die mac adres velden, vreselijk ding ook die regex.

Voor de geïnteresseerden , hier vind je de full writeup: https://natedotred.wordpr...le-remote-code-execution/
Ik zou de schuld niet aan de regex geven, eerder aan een developer die het niet goed gebruikt.
Als de dev /^([a-fA-F0-9]{2}[:]?){6}$/ van had gemaakt was het een stuk optimaler geweest. Dit controleert namelijk of de gehele reeks van begin tot eind waar is.
Regex is een geweldige stuk gereedschap in een gereedschapskist van een ontwikkelaar, maar net als een timmerman als je je ijzer gaat zagen met een houtzaag dan moet je er niet vreemd opkijken als er dingen kapot gaan.
Klopt, in de reactie van @Pep7777 zag ik gelijk al; daar zou een ^ aan het begin moeten en $ aan het einde.
Net als iets alleen cijfers mag bevatten:

/^\d+$/

Of alleen letters:

/^\w+$/

Of letters en streepjes

/^[\w-]+$/

Met ^ en $ dan matched ie die regex van begin tot eind. Zonder de $ matched ie zover ie kan matchen en kan je erachter zetten wat je wilt.

Zoals je al zegt, regex is geweldig van simpele tot complexe controles, maar je moet wel weten hoe je het moet gebruiken. Ook voor een complexe search & replace is het een geweldige tool.

[Reactie gewijzigd door xoniq op 23 juli 2024 21:21]

[quote]
Klopt, in de reactie van @Pep7777 zag ik gelijk al; daar zou een ^ aan het begin moeten en $ aan het einde.
[/quote
Let er wel op dat dat implementatie afhankelijk is, de meeste implementaties pakken standaard geen multi-lines mee, waardoor je met een new-line en dan de code het gewoon nog werkt.
Mee eens, maar een regulier input veld doet geen newlines. Je kan natuurlijk je invoer ook vooraf opschonen door zaken als newlines (zowel WIN als LIN newlines) te strippen en de invoer voorzien van een trim (L + R) zodat de invoer schoon is en klaar voor een regex check.
Mee eens, maar een regulier input veld doet geen newlines.
Tja, dan kan je je validaties ook met Javascript in de client doen, net zo veilig.
Je server accepteert wel gewoon newlines in een Get/Post input, oftewel daar moet je vanuit gaan...
Je kan natuurlijk je invoer ook vooraf opschonen door zaken als newlines (zowel WIN als LIN newlines) te strippen en de invoer voorzien van een trim (L + R) zodat de invoer schoon is en klaar voor een regex check.
Tja, waarom zou je het dan uberhaupt nog met een dure regex doen, waarom niet met een goedkopere check.
Dat is een beetje het nadeel met regexen, het begin is heel makkelijk, maar de finesses maken het onleesbaar en duur (en slecht controleerbaar)
[...]

Tja, dan kan je je validaties ook met Javascript in de client doen, net zo veilig.
Je server accepteert wel gewoon newlines in een Get/Post input, oftewel daar moet je vanuit gaan...
Pardon? Met Javascript net zo veilig? Je kan met een console gewoon een form submitten en HTML5
of Javascript validatie omzeilen. Dus nee, gewoon de POST afhandeling doorlopen. Eventuele HTML5 dan wel Javascript validatie doe je puur voor de UX, de klant direct info geven over een verkeerde invoer zonder dat het formulier eerst gesubmit word en je terug word gestuurd.

Front-end validatie !== validatie.
[...]
Front-end validatie !== validatie.
Oftewel ervan uitgaan dat een regulier input veld geen newlines doet is waardeloos...
Pak dan ook m'n andere stukje erbij, waarin ik dus beschrijf dat newlines in een reguliere input field niet voorkomen, maar dat je dit ook sowieso moet sanitizen:
Je kan natuurlijk je invoer ook vooraf opschonen door zaken als newlines (zowel WIN als LIN newlines) te strippen en de invoer voorzien van een trim (L + R) zodat de invoer schoon is en klaar voor een regex check.
Zeg ik ook niet hoor dat het niet zeer krachtig kan zijn, bij goed gebruik.

Maar dat goed gebruiken dat is en blijft een uitdaging.
Het komt nu in de media maar was al veel eerder aan de makers gemeld, in de nieuwste versies is het al lang verholpen.
Dat is hoe ethisch bughunten werkt ja ;-)
Tja jij vroeg waarom het nu pas naar buiten komt :) ik denk; laat ik het even uitleggen ;)
Ik bedoelde eerder waarom dit in oudere versie van pihole nooit opgemerkt geweest is, kan me niet voorstellen dat men nu opeens de validatiecode zitten wijzigen heeft voor dat veld :)
Op die fiets, ik las het anders :)
Nuja, ik had duidelijker moeten zijn ;-)
Dit is geen XSS. Bij XSS plaats iemand code in de website van de pihole en geeft de website die code terug aan een browser waardoor de browser de code gaat uitvoeren. In dit geval plaatst iemand code via de website op de pihole en gaat de pihole die code op het eigen systeem uitvoeren.
Yes i guess dat je gelijk hebt met deze poc, technisch gezien is het enkel xss als de code op een andere server staat.

Al vermoed ik dat een XSS aanval ook zou werken in dit scenario.
Als je pi-hole in een virtueel machine draait op windows, was remote code execution nog steeds mogelijk ?
Bor Coördinator Frontpage Admins / FP Powermod @solozakdoekje31 maart 2020 08:40
Een virtuele machine maakt in deze niets uit. Je voert alleen de code uit binnen de context van de VM (er van uitgaande dat men vanuit de VM de host niet weet te bereiken).
Uiteraard, dan verkrijgt men root op de VM. Niet op Windows, hoewel wel mogelijk uit de VM te breken is naar Windows.
er zijn voor VM's verschillende methodes. waarvan er vele duidelijk merkbaar zijn, maar andere minder merkbaar.

de meest merkbare is Ram-chip jumping. waarbij het ramgeheugen wordt volgeladen in de hoop dat de code overspringt op een chip die gedeeld wordt met het Host-systeem.
Voor de Home-Assistant gebruikers. Dit hangt niet samen met het depreciaten van de Addon.

Zie: https://twitter.com/Frenck/status/1233902986520387584
Wat zit die vent onnodig Pi-Hole af te zeiken zeg... :F Wat is zijn probleem precies :?

Zit ook reacties uit te lokken bij het Pi-Hole Team en zo... W-T-F ?!?!
Of gebruik de nextgeneration pihole, genaamd nextdns.io! Werkt super fijn ben pas overgestapt
Nee, dank je. Closed source, betalen boven bepaald aantal requests. Moet je weer afwachten tot de duimschroeven worden aangedraaid.
Ik denk dat een rasberry permaand meer kost dan die 1,99
Liever geld betalen en zelf hosten dan je privacy gratis weggeven.
Zijn dit puur lists of stuur je alles door naar hun netwerk? Zoals ik het zie is dit het laatste en is het de vraag in hoeverre zij jouw data safe stellen.
Eigenlijk een pihole in de cloud zegmaar en https://nextdns.io/privacy
Daarom heb ik pihole interface altijd achter een firewall hangen. Mijn pihole installatie draait tevens ook op een VM, waardoor je standaard meer moeite moet doen om alles veilig te houden.
En toch het beste stukje software wat ik in de afgelopen 2 jaar heb gevonden!

Op dit item kan niet meer gereageerd worden.