Beveiligingsbedrijf: veel iot-apparaten zijn kwetsbaar voor dns-rebinding

Beveiligingsbedrijf Armis, bekend van het Blueborne-lek, stelt dat een groot aantal iot-apparaten kwetsbaar is voor een zogenaamde dns-rebinding-aanval. Op basis van eigen onderzoek schat het dat wereldwijd 496 miljoen apparaten kwetsbaar zijn in zakelijke netwerken.

Volgens het bedrijf gaat het onder meer om routers, printers, camera's, tv's en telefoons, voornamelijk in zakelijke netwerken. Een aanval via dns-rebinding vindt plaats doordat een doelwit bijvoorbeeld een site bezoekt die is opgezet door een aanvaller en die kwaadaardige JavaScript bevat. Een ander vereiste is dat de aanvaller een kwaadaardige dns-server in zijn beheer heeft.

Als het doelwit de site bezoekt, antwoordt de dns-server eerst met het daadwerkelijke adres van de site, maar met een zeer korte ttl zodat het adres maar kort in de cache wordt opgeslagen. Bij een tweede lookup, die snel volgt door de korte ttl, geeft de dns-server echter een ander adres door, bijvoorbeeld een ip-adres op het lokale netwerk. Daarbij kan een aanvaller onder meer een kwaadaardig commando meesturen. Een dergelijke aanval is niet nieuw en werd al in 2008 beschreven.

Armis claimt dat een aanvaller op deze manier bijvoorbeeld informatie kan verzamelen over apparaten op een lokaal netwerk, dat normaal gesproken is afgesloten door een firewall. Zo zouden bijvoorbeeld beheerdersinterfaces te benaderen zijn via upnp of http. Een aanvaller kan vervolgens een iot-apparaat verbinding laten maken met een externe command-and-control-server, aldus Armis.

De waarschuwing van het bedrijf lijkt op die van een andere onderzoeker, Brannon Dorsey, die onlangs een blogpost over zijn bevindingen publiceerde. Zo toonde hij aan dat het mogelijk was om via dns-rebinding apparaten als een Google Home of een Sonos-speaker aan te vallen. De verschillende fabrikanten gaven toen aan patches te willen ontwikkelen. Ook eerder kwam de techniek al tot inzet bij kwetsbaarheden in de FritzBox-firmware, de uTorrent-client en de Blizzard Update Agent. Deze voorbeelden zijn vrij recent, maar in 2010 waarschuwde een onderzoeker al dat bepaalde routers kwetsbaar waren.

Reacties (81)

[woekele]

Heb even bij andere bronnen moeten zoeken hoe DNS-rebinding nou precies werkt. In dit artikel en het filmpje is het nogal onduidelijk. Ik heb https://medium.com/@brann...ns-rebinding-ea7098a2d325 gebruikt als bron.

Wat er gebeurt: je surft vanaf je laptop naar nu.nl. Op nu.nl staat een malicious advertentie, die je browser javascript laat uitvoeren die gehost wordt op bijvoorbeeld evil.com. Normaal gesproken kan deze javascript alleen verzoeken sturen naar evil.com, andere adressen worden geweigerd door je browser. Stel bijvoorbeeld dat de javascript van evil.com probeert om een request te doen naar outlook.com, dan wordt dat geblockt. Zo kan evil.com normaalgesproken dus geen requests sturen naar outlook.com via je browser en dus geen gegevens van jou op outlook.com achterhalen.

Maar.... De eerste keer dat je browser contact legt met evil.com, moet hij een DNS-verzoek doen. Dit domein is namelijk nog niet bekend in je browser. Ze zorgen dat het DNS-verzoek wordt beantwoord en netjes het juiste publieke ip-adres van evil.com teruggeeft, bijvoorbeeld 82.83.84.85. Je browser kan dan netjes de javascript op evil.com laden en gaan uitvoeren. Stel dat deze javascript om de 5 seconden een request doet naar evil.com... nog geen probleem.

Maar dan de truc. Het DNS-antwoord was voorzien van een zeer korte TTL (time to live). Dit zorgt ervoor dat je browser na een bepaalde tijd opnieuw een DNS-verzoek gaat doen om opnieuw te kijken wat het IP van evil.com is. Deze keer antwoordt de DNS-server echter niet netjes met het publieke IP van evil.com, bijvoorbeeld 82.83.84.85... maar met een lokaal ip-adres, eentje die wel eens je slimme thermostaat zou kunnen zijn, bijvoorbeeld 192.168.1.50. Vanaf dat moment gaan alle verzoeken die het draaiende javascript uitvoert niet meer het internet op naar evil.com, maar naar je slimme thermostaat in je lokale netwerk. Je browser 'denkt' echter dat de requests gewoon nog naar evil.com gaan en staat de requests dus toe. Mits de javascript de juiste requests doet, kan het bijvoorbeeld je temperatuurinstelling in huis aanpassen.

Door weer hetzelfde DNS-tructje uit te halen, zou je op den duur de requests weer terug kunnen laten komen op het echte internet IP-adres van evil.com en op die manier de lopende javascript dus ook de gevonden informatie in het lokale netwerk terug kunnen laten sturen.

Wat ik mij al met al afvraag... waarom zit er niet 'gewoon' een betere beveiliging in de browsers? Als een IP van een site ineens wijzigt van een internet-adres naar een lokaal adres, waarom dan niet alerten/blocken? Als de browser beter beveiligd is, komt het minder aan op de beveiliging van alle apparaten in je lokale netwerk (alhoewel eigenlijk beide in orde moeten zijn natuurlijk...)

Andere mogelijke beveiliging: laat je DNS-server lokale IP-adressen weigeren als antwoord op DNS-verzoeken voor externe domeinen. Op die manier krijgen je clients de malicious DNS-antwoorden überhaupt nooit binnen.

[Reactie gewijzigd door woekele op 22 juli 2024 17:03]

[Dreamvoid]

Telkens weer dat ellendige javascript. Het wordt tijd dat browsers alleen nog maar JS van het pagina domain zelf toelaten, of beter nog, helemaal uitschakelen en enkel nog HTML5/CSS. Die extra page reloads zijn vervelend, maar dat is het wel waard tov de security ellende. Helaas zijn er te weinig sites waarvoor een functionele JS-vrije versie is gemaakt, onnodige zuinigheid.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 17:03]

[djwice]

Telkens weer dat ellendige javascript. Het wordt tijd dat browsers alleen nog maar JS van het pagina domain zelf toelaten

Dat kunnen websites zelf instellen met de Content-Security-Policy http-header, als je onderstaande header aan je pagina toevoegt kun je alleen zelf nog rotzooi op je site gooien:

content-security-policy default-src 'none' ; frame-ancestors 'none' ; base-uri 'self' ; connect-src 'self' ; img-src 'self' ; font-src 'self' ; form-action 'self' ; manifest-src 'self' ; style-src 'self' ; worker-src 'self' ; require-sri-for script ; script-src 'self'

[Verwijderd]

In aanvulling: www.securityheaders.io

[djwice]

Nog mooier: https://observatory.mozilla.org/analyze/www.teusink.eu
Je kunt tot 135/100 punten gaan, bijvoorbeeld met:

Set-Cookie __Host-IP=34C70CCC1F5DCD78; Path=/api/; Secure; HttpOnly; SameSite=strict
content-security-policy default-src 'none' ; frame-ancestors 'none' ; base-uri 'self' ; connect-src 'self' ; img-src 'self' ; font-src 'self' ; form-action 'self' ; manifest-src 'self' ; style-src 'self' ; worker-src 'self' ; require-sri-for script ; script-src 'self'
referrer-policy same-origin
strict-transport-security max-age=63072000; includeSubdomains; preload
x-content-type-options nosniff
x-frame-options DENY
x-ua-compatible IE=edge
x-xss-protection 1; mode=block

Deze is verdraait goed:
https://www.ssllabs.com/s...161&hideResults=on&latest

Het is de eerste keer dat ik hem zo goed zie! Petje af! Jammer alleen van het gedeelde certificaat...

[Reactie gewijzigd door djwice op 22 juli 2024 17:03]

[Verwijderd]

Dank! Je hebt gelijk, je ziet het niet vaak inderdaad . Helaas kan mijn CSP niet veel strakker ivm blogspot en werkt het Let's Encrypt certificaat niet lekker icm Cloudflare. Vandaar dat gedeelde ding idd.

SRI kan helaas ook niet bij alle scripts (blame hoster), maar heb al wel de nieuwe Security Headers Feature-Policy live

Het is een soort sport geworden om overal een A of A+ rating te krijgen. En het is nog veiliger ook .

Edit: ik zal je suggesties ff nalopen deze week! thanks

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:03]

[djwice]

Nu deze nog:
https://developer.mozilla...Security-Policy/report-to

[Reactie gewijzigd door djwice op 22 juli 2024 17:03]

[woekele]

alleen JS toestaan van het domein van de pagina waar je op zit helpt in elk geval niet als je iemand verleidt naar een malicious website te surfen.

[Dreamvoid]

In de praktijk is het bijna altijd geinjecteerde JS code van ads (gehost op externe domeinen) die dit doet. Uiteraard zou de JS afkomstig van de website zelf dit ook kunnen doen, maar daarvoor moet je eerst expliciet naar een malafide website surfen.

[Durandal]

Ze zorgen dat het DNS-verzoek wordt beantwoord en netjes het juiste publieke ip-adres van evil.com teruggeeft

Ja, hier raak je me kwijt. Hoe komt jouw browser op de DNS van de aanvaller terecht?

[WhiteDog]

Niet. Je browser vraagt het aan de door jou ingestelde DNS server, doorgaans je router of een adres van je provider/google. Die gaan het antwoord via via zoeken bij de malafide DNS server voor het domein evil.com (de ingestelde nameserver).

In feite zou je in jouw DNS server een beveiliging kunnen inbouwen waarbij een extern IP niet zomaar een intern IP mag worden. Of nog beter, gewoon alle interne IP-adressen die vanaf het internet komen negeren. Voor een thuis-omgeving zou dat geen problemen morgen veroorzaken.

[Durandal]

Ja maar dat is de vraag een stap verder leggen. Hoe komt mijn provider's DNS bij de malafide DNS terecht?

Dan kan je zeggen 'die kunnen ze zelf instellen' maar dan heb je hoogstens met een heel gerichte aanval te maken want ze moeten het evil.com IP dan specifiek voor jouw anders instellen, en dan kunnen ze niet tegelijk anderen aanvallen want hun requests komen ook bij jouw terecht

Verder kan het wel even duren voor een DNS wijziging propageert. Is het ook niet zo dat je provider DNS bindings langer vast houdt en niet kijkt naar de TTL?

[woekele]

Als je een domein claimt, geef je op welke DNS-servers over dat domein gaan. Daar geef je dan dus je eigen malafide DNS-server op.

Als een slachtoffer dan jouw domein opvraagt via DNS, komt dat verzoek eerst bij de DNS-server van het slachtoffer (daarop heb je geen invloed). Deze DNS-server kent jouw malafide domein nog niet en gaat dus bij een top-level DNS-server (bijvoorbeeld die van .com-domeinen, daar heb je ook geen invloed op) opvragen welke DNS-server hem verder kan helpen. Deze verwijst de DNS-server van het slachtoffer door naar jouw malafide DNS-server. Deze geeft vervolgens een malafide antwoord. De DNS-server van het slachtoffer geeft dit malafide antwoord weer door aan je slachtoffer.

Over TTL heb je een punt. Maar blijkbaar worden korte TTL's toch toegestaan en is het toepasbaar. Korte TTL's onmogelijk maken is niet echt praktisch als je bijvoorbeeld je site wil verhuizen met zo min mogelijk down-time etc.

[Reactie gewijzigd door woekele op 22 juli 2024 17:03]

[Ventieldopje]

De TTLs zijn het probleem ook niet. Het ligt aan de lekke CORS implementatie waardoor javascript requests zomaar naar je lokale netwerk gemaakt kunnen worden.

Dit soort gedrag zou je specifiek moeten whitelisten in plaats van standaard toestaan.

[Plofkotje]

Korte TTL’s onmogelijk maken zouden CDN (Content Distribution Network) en DNS based loadbalancing (GSLB) oplossingen onmogelijk maken. Aangezien elke grote dienst zoiets gebruikt is het niet praktisch om dat te verbieden.

Zoals hieronder al gezegd door Ventieldopje is de falende CORS implementatie in de devices het probleem, niet de korte TTL in de DNS.

[Reactie gewijzigd door Plofkotje op 22 juli 2024 17:03]

[defixje]

DNS wordt altijd geraadpleegd als je een domein bezoekt waarvan jou netwerk nog niet weet welk IP adres er bij hoort.

DNS zet domein namen om naar IP adressen, daarbij kan je in de DNS ook de TTL opgeven. Dit betekend time to live.

Of te wel, als jou DNS een TTL van 300 seconden heeft, dan vraagt jou netwerk na 5 minuten opnieuw aan DNS servers om het IP van het domein.

De eerste keer klopt dus, de tweede keer dat jou netwerk om het IP vraagt is hij ineens gewijzigd naar een lokaal IP.

[henk717]

Is dit dan niet heel makkelijk te ondervangen op een centraal punt door in je lokale DNS server een minimum expire tijd in te stellen? Als je eigen device dit cached voor bijvoorbeeld 30 minuten ongeacht de TTL lijkt mij de exploit onmogelijk.

[Cyb]

Dan kan die aanval toch alsnog plaatsvinden na de 30 minuten?
Simpelste oplossing: gebruik een DNS server die niet resolved naar lokale adressen. OpenDNS deed dat in 2008 al, maar OpenDNS vertrouw ik wat minder kwa privacy.

[scsirob]

Dat kan, maar hoe lang blijft dat Javascript draaien? In het voorbeeld niet langer dan dat die pagina met malafide advertentie open staat. Er zijn niet zoveel web pagina's, of zelfs maar sites waar iemand 30 minuten blijft hangen zonder onderbreking.

[Cyb]

Javascript kan zo lang draaien als het maar wilt, mits de pagina of zelfs website open blijft staan. Als iemand even een lunch pauze neemt, terwijl de website open blijft staan, is het al te laat.

[henk717]

Dat is een goede inderdaad, mijn netwerk maakt hier lokaal al gebruik van op alle devices omdat de DNS server in mijn router DNS rebinding in zijn geheeld blokkeerd (Ook als op het lokale device van bijvoorbeeld een gast een andere DNS resolver ingesteld staat gezien deze poort altijd naar mijn lokale DNS wordt geroute).

[Cyb]

Ook als op het lokale device van bijvoorbeeld een gast een andere DNS resolver ingesteld staat gezien deze poort altijd naar mijn lokale DNS wordt geroute

Dat is wel netjes. De meeste routers hebben dat niet ingebouwd. Gebruik je DD-WRT, OpenWRT of Tomato om dit te bereiken? Wil zelf DD-WRT gaan installen, speciaal voor dit DNS-rebinding probleem.

Het zal me niet verbazen als er om een gegeven moment datahandelaren (of misschien wel Facebook) DNS-rebinding gaat toepassen om nog meer informatie over mensen te verzamelen.

[henk717]

Ik gebruik zelf DD-Wrt in mijn build zitten alle genoemde functies ingebouwd inclusief het forceren van de DNS op PC's welke deze op een alternatieve DNS hebben staan.

[djwice]

Je kunt in chrome zien hoe lang domeinen worden gecached:
chrome://net-internals/#dns

Voor mijn eigen domein heb ik de TTL op 60000ms staan, ik zie dat netjes terug in de lijst.
2018-07-21 19:50:51.005 [Expired]

Maar een nieuwe pagina bezoeken leverd niet een nieuw DNS verzoek.
Dus ondanks de TTL van 1 minuut, lijkt Chrome te kiezen voor 10 minuten caching van het resultaat.

Volgens mij moet dat voor de meeste aanvallen voldoende zijn om niet succesvol te zijn met 1 domein (een bezoek van meer dan 20 minuten is dan nodig). Hmm.. bedenk me net hoe je de aanval zelfs zonder DNS-rebinding kan uitvoeren... re-binding is ouderwets.

[Reactie gewijzigd door djwice op 22 juli 2024 17:03]

[djwice]

Mijn beveiligingsadvies tegen deze attacks:

Als bedrijf koop een publiek domein.
Gebruik dat domein alleen (!) voor interne routing en alleen in niet publieke DNS.
En gebruik dat domein en zijn sub-domeinen voor al het interne traffic, bijvoorbeeld intern IP4nummer.domein.tld

Vanaf dan laat je firewall / DNS alleen nog voor dat ene domein (met sub-domeinen) interne IP-adress ranges toe.
Voor alle andere worden de responses met interne IP adressen geblokkeerd en de betrokken domeinnamen op een blacklist geplaatst. En voor dat domein accepteer je geen publieke IPs.

Ook alle interne pakketjes die een ander domein bevatten en een intern IP filter je uit je netwerk, dit kan vanwege SNI.

[Reactie gewijzigd door djwice op 22 juli 2024 17:03]

[Verwijderd]

Hoe zou een IoT device zich hiertegen moeten beschermen? Hij kan toch niet weten dat het request indirect van buiten af komt?

[woekele]

Het probleem zit wat mij betreft niet in het IoT-device, maar in de browser en in DNS-servers.

Maar... het IoT-device kan zichzelf wel beter beveiligen. Het zal kunnen kijken naar de host-header die de browser meestuurt in het verzoek richting het device. Als dit een extern domein is, en niet de hostname of ip-adres van het IoT-device, zou hij communicatie kunnen weigeren.

Of.. https gebruiken. Dan gaat de communicatie sowieso niet tot stand komen.

Of.. authenticatie afdwingen zonder mogelijkheid tot simpele standaard wachtwoorden en zonder automatisch ingelogd blijven.

[Reactie gewijzigd door woekele op 22 juli 2024 17:03]

[Robbaman]

Andere mogelijke beveiliging: laat je DNS-server lokale IP-adressen weigeren als antwoord op DNS-verzoeken voor externe domeinen. Op die manier krijgen je clients de malicious DNS-antwoorden überhaupt nooit binnen.

Dat kan wel een super handige hack tijdens het developen van een web applicatie. Gebruik het niet vaak, maar af en toe kan het nuttig zijn

[Bedenker]

Andere mogelijke beveiliging: laat je DNS-server lokale IP-adressen weigeren als antwoord op DNS-verzoeken voor externe domeinen. Op die manier krijgen je clients de malicious DNS-antwoorden überhaupt nooit binnen.

Ik dacht dat dit al de standaard was? (met uitzondering van localhost)
Of geld het alleen voor doorsturen van data?

[woekele]

Geen idee. Blijkbaar niet. OpenDNS schijnt het standaard te doen. Maar anderen... ?

Doorsturen van data snap ik niet helemaal in deze context.

[Jerie]

Wat er gebeurt: je surft vanaf je laptop naar nu.nl. Op nu.nl staat een malicious advertentie.

Welke op DNS niveau wordt geblokkeerd, en dus ook op de IoT apparaten. Ga verder.

Verder is het stupide dat zo'n korte TTL geaccepteerd wordt. Het is stupide dat een client er niet over klaagt of waarschuwing geeft. Het is stupide dat het geaccepteerd wordt dan een publiek domein naar een intern IP adres verwijst. Het is stupide dat het geaccepteerd wordt dat het eerst naar een extern en vervolgens naar een intern IP adres verwijst. Het is stupide dat een website op het internet kan bepalen dat er een connectie wordt gemaakt met een intern IP adres. Het is stupide dat er geen standaard gebruik gemaakt wordt van iig DNS over TLS (waardoor er ook sprake kan zijn van DNS rebind attack door bepaalde partijen). Ik kan nog wel even doorgaan.

Maar als je Qubes gebruikt, is er niets aan de hand...

[woekele]

hoe blokkeer je een site op DNS-niveau als nog niet bekend is dat het een malafide site is? Of blokkeer je gewoon alles wat je niet kent? (whitelisting)

[Jerie]

Jij had het over malafide ads. Ik blokkeer ads standaard. Nee, malafide sites kan ik niet allemaal blokkeren (er zijn wel blacklists die aardig wat tegenhouden, zelfs Google gebruikt dat in Chrome).

[woekele]

Maar ook ad-blocking op DNS-niveau werkt alleen als het domein dat de advertentie host al bekend staat. Het helpt vast een heleboel, maar je kan niet zeker zijn dat de advertentie geblokkeerd wordt.

[Jerie]

Klopt, maar dat maakt de aanval die jij noemt wel een stuk moeilijker.

[djwice]

Verder is het stupide dat zo'n korte TTL geaccepteerd wordt. Het is stupide dat een client er niet over klaagt of waarschuwing geeft.

Mijn website draait op een infrastructuur die elke 5 minuten alle servers ontmanteld en nieuwe servers inzet, de lage TTL zorgt er voor dat klanten altijd een werkende site krijgen.

[Reactie gewijzigd door djwice op 22 juli 2024 17:03]

[deadinspace]

Verder is het stupide dat zo'n korte TTL geaccepteerd wordt.

Een korte TTL is onder andere nuttig voor DNS-based load-balancing, failover, en service migraties.

Los daarvan, wat is kort? Een minimale TTL afdwingen voorkomt deze aanval niet, het zorgt er alleen voor dat deze langer duurt (en dus minder praktisch wordt).

Het is stupide dat een client er niet over klaagt of waarschuwing geeft.

Dat zou veel onterechte waarschuwingen opleveren (zie boven). Bovendien helpen waarschuwingen bij de meeste gebruikers nauwelijks.

Het is stupide dat het geaccepteerd wordt dan een publiek domein naar een intern IP adres verwijst.

Dat is doodnormaal in grotere netwerken, bijvoorbeeld bij bedrijven. Dan wijst bijvoorbeeld agenda.bedrijf.nl naar een intern adres; nuttig voor services die alleen voor interne medewerkers toegankelijk hoeven te zijn.

Het is stupide dat het geaccepteerd wordt dat het eerst naar een extern en vervolgens naar een intern IP adres verwijst.

Waarom? IP adressen kunnen wijzigen, services verhuizen; DNS-resultaten kunnen daardoor veranderen. Als ik op mijn werk een externe server naar ons interne netwerk verhuis en de DNS aanpas, dan kan precies die situatie voorkomen.

Om verder maar niet te denken aan captive DNS portals van publieke WiFi hotspots, of (legitieme) proxies.

Het is stupide dat een website op het internet kan bepalen dat er een connectie wordt gemaakt met een intern IP adres.

Dat kan dus niet onder normale omstandigheden; dat is juist het hele punt van deze aanval, waarmee een manier bedacht is om dat toch te doen.

Overigens heeft dit (en al het bovenstaande) niks per se met interne adressen te maken; de hele aanval is ook bruikbaar tegen externe adressen (bijvoorbeeld je webmail).

Het is stupide dat er geen standaard gebruik gemaakt wordt van iig DNS over TLS (waardoor er ook sprake kan zijn van DNS rebind attack door bepaalde partijen)

Dat haalt niks uit. In de aanval zoals hij beschreven is gebruikt de aanvaller gewoon de DNS van de malafide site die onder zijn beheer staat. Er is dus niet ingebroken op DNS-verkeer, en het DNS-verkeer authenticeren zou niks hiervan voorkomen.

Ik kan nog wel even doorgaan.

Nou, liever niet, want alles wat je hierboven stupide hebt genoemd is onjuist, of een legitieme toepassing van DNS.

Maar ja, roepen vanaf de zijlijn is zo lekker makkelijk heh?

[Jerie]

Een korte TTL is onder andere nuttig voor DNS-based load-balancing, failover, en service migraties.

Allemaal zaken waar de gemiddelde gebruiker zelf niets mee te maken zou moeten hebben. Load balancing en failover hoeft ook niet via DNS te gebeuren, dat is een keuze. Service migratie idem. Om een paar alternatieven te noemen hoe je het anders kunt implementeren: CARP, VRRP, anycast/multicast, manual routing, automatische routing (div protocollen), port forwarding, cloud, geen DNS gebruiken maar een hardcoded IP, ...

Dat is doodnormaal in grotere netwerken, bijvoorbeeld bij bedrijven. Dan wijst bijvoorbeeld agenda.bedrijf.nl naar een intern adres; nuttig voor services die alleen voor interne medewerkers toegankelijk hoeven te zijn.

Weet ik. Hard rijden is ook doodnormaal. Het feit dat iets normaal is, betekent nog niet dat het OK is. Het hoeft namelijk niet. Je kunt ook massaal er voor kiezen split horizon DNS te gebruiken? is geen rocket science of wel soms?

Waarom? IP adressen kunnen wijzigen, services verhuizen; DNS-resultaten kunnen daardoor veranderen.

Dat gebeurt niet binnen een paar seconden (waar we het hier over hebben). Bovendien is het ook niet zo dat dat van intern naar extern gaat. Neem als voorbeeld de browser. Een browser zou dus dikke vette waarschuwing kunnen geven wanneer dat wel gebeurd (zo'n heel scherm rood bijvoorbeeld, wat Chrome heeft) en vervolgens alleen met uitdrukkelijke toestemming v/d gebruiker de verbinding opzetten. Een kort TTL is een factor waar de gebruiker op gewezen kan worden, of wat intern kan worden meegewogen in de risk factor.

Dat zou veel onterechte waarschuwingen opleveren (zie boven). Bovendien helpen waarschuwingen bij de meeste gebruikers nauwelijks.

Hangt ook van de manier van waarschuwen af.

Dat kan dus niet onder normale omstandigheden; dat is juist het hele punt van deze aanval, waarmee een manier bedacht is om dat toch te doen.

Omdat teveel autoriteit wordt gegeven aan iets waar je niet op kunt bouwen (DNS). Los daar van, zou je dit op kunnen lossen dmv whitelisting en het programma zou het verschil wel degelijk moeten kunnen checken. Heck, een layer-7 packet filter had dit nog tegen kunnen houden mits hij strikt genoeg is.

Dat haalt niks uit. In de aanval zoals hij beschreven is gebruikt de aanvaller gewoon de DNS van de malafide site die onder zijn beheer staat. Er is dus niet ingebroken op DNS-verkeer, en het DNS-verkeer authenticeren zou niks hiervan voorkomen.

In dit geval niet, nee, maar het helpt wel om de integriteit van de DNS requests te verhogen. Iets dat standaard niet al te best is, en eenvoudig is te combineren (MITM + DNS rebind). En daar helpt mijn oplossing WEL tegen. Maar ja, dat kon je zelf niet bedenken blijkbaar.

Maar ja, roepen vanaf de zijlijn is zo lekker makkelijk heh?

Diverse v/d oplossingen die ik aandroeg worden door professionals al gebruikt om DNS rebind aanvallen tegen te gaan verder gebruik je zelf drogredeneringen zoals "iedereen doet het" en "zo werkt het nou eenmaal".

[ro3lie]

Dit recent uitgezocht om te voorkomen, maar echte oplossingen zijn er zover ik weet nog niet.
Mogelijke optie is de apparatuur scheiden van de werkplekken, dit gaat echter voor sommige al ver.
Printers plaatsen in een apart VLAN en alleen vanaf de print server toestaan is bijvoorbeeld een optie.

[DigitalExorcist]

Maar dan krijg je weer gezever met AirPrint-users, of automatisch bestellen van toner, of uitlezen van tellerstanden en noem maar op.... management van de printer zelf, firmware updates, etc.

[MrDikke]

AirPrint weet ik niks over, dus daar kan ik niks over zeggen.

Maar voor bijvoorbeeld automatisch bestellen van de toner/managment/firmware updates kun je gewoon via de printserver doen.

[DigitalExorcist]

Als je daar centrale software voor hebt wel ja. Klopt. Maar dan heb je een multihomed printserver en of dát nou perse een goed idee is...

[Zer0]

Een multihomed printserver is niet nodig, met ACL's kun je inregelen dat vanaf het printer-vlan alleen met de printserver gecommuniceerd mag worden, en niet met andere bestemmingen.

[Cyb]

Is de oplossing niet gewoon het gebruik van een DNS server waarvan je weet dat deze het resolven naar lokale adressen blokkeert?

OpenDNS deed dit al in 2008. Dan zou het een kwestie zijn van je router instellen op OpenDNS en klaar.

[ro3lie]

En wat alsje clients verwijzen naar een andere DNS server?
Bijvoorbeeld intern.

[Cyb]

Dan wordt dat inderdaad omzeild. Maar het is wel de gemakkelijkste oplossing, mits elke client zijn standaard DHCP instellingen ongewijzigd laat.

Edit: ik kan mijn reactie even niet plaatsen. Heb misschien de vraag verkeerd geinterpreteerd of half op een ander bericht gereageerd. Maar zie maar de reactie van @Jerie hieronder.

[Reactie gewijzigd door Cyb op 22 juli 2024 17:03]

[Jerie]

Nope, dat wordt niet omzeild. Dat werkt prima, die interne server vraagt namelijk wanneer hij het niet weet aan OpenDNS. Dat mangle je die pakketten in je firewall door naar OpenDNS. Bij mij gaat geen enkele DNS request over plaintext. Alles wordt afgevangen en gaat over TLS.

[Jerie]

Ook die interne server haalt uiteindelijk z'n DNS info uit een externe. Die kun je afvangen en doorsturen naar OpenDNS (of wat dan ook).

[Transportman]

Hangt er vanaf hoe je interne adressen definieert. Zijn genoeg bedrijven die heel veel intern hebben draaien en dat moet natuurlijk wel bereikbaar blijven.

[Cyb]

Das een kwestie van whitelisten op de DNS server.
Waar het om gaat is dat externe hostnames niet naar lokale adressen resolved mogen worden. Lokaal is gedefinieerd als alles wat valt onder wat RFC onder prive verstaat.

[segil]

In een bedrijfsomgeving gaat dat sowieso niet werken, en voor lokaal blokkeer je daarmee alle andere clients. Dus ook geen mogelijkheid meer om te communiceren met je nas, wifi printer, etc.

[Cyb]

Dan kan prima werken. Het is een kwestie van whitelisten op je lokale DNS server.
Waar het om gaat is dat externe hostnames niet naar lokale adressen resolved mogen worden. Lokaal is gedefinieerd als alles wat valt onder wat RFC onder prive verstaat.

[ThomasG]

IoT-apparaten beginnen anzich een probleem te worden. Veel apparaten hangen, al dan niet indirect en vaak onbedoeld, aan het internet en veruit de meeste daarvan hebben inadequate beveiliging. Steker nog,. de meeste apparaten hebben geen beveiliging en de fabrikanten zijn daar vaak ook totaal niet mee bezig. Nu hebben de meeste consumenten nog een NAT router waardoor de kwetsbaarheid nog enigsinds beperkt wordt, maar met IPv6 wordt de kwetsbaarheid van veel apparaten groter als mensen hun netwerk niet goed configureren.

Het zou fijn zijn als er een soort keurmerk komt voor IoT-apparaten dat ze in ieder geval een aantal essentiele beveiligingsfunctionaliteiten hebben. Zodat je bijvoorbeeld een gebruikersnaam/wachtwoord nodig hebt om de apparaten te configureren, dat je geen XSS-aanval kunt uitvoeren op die apparaten (dat is wat deze dns-rebinding aanval namelijk doet), e.d.

[Dreamvoid]

Alle huidige IPv6 consumenten aansluitingen hebben standaard een firewall draaien dus dat is niet het probleem.

[jeanj]

Als ik het goed lees zit het issue niet in de iot apparaten, maar in de pc/browser die een toegang tot aparaten in het interne netwerk toestaat, dit kan een iot apparaat of een ander device, zoas een nas

De breuk wordt gemaakt op de pc, Een reden te meer voor een ad blocker , het iot apparaat en de zwake beveiliging wordt dan gebruikt om het netwerk te verkennen.

Persoonlijk vind het iot gehalte van de genoemde voorbeeld apparaten (routers, printers, camera's, tv's en telefoons) wel laag, maar dat is een definitie kwestie

Hoe kan je hier tegen verdedigen zolang het dns issue niet wordt opgelost, aparte vlan voor iot gaan dus al niet helpen....

[Cyb]

Iot apparaten kunnen zich beschermen door onbekende hostnames in de http host header te blokkeren, al hoewel dat niet de mooiste oplossing is.
Het is niet echt een DNS protocol probleem, maar meer een implementatie probleem. Ze moeten gewoon inbouwen/configureren dat externe hostnames niet naar lokale prive adressen geresolved mogen worden. Met "ze" bedoel internet providers, bedrijven met een eigen DNS server, en als deze het niet doen, dan moet de eindgebruiker een dergelijke DNS server zelf configureren. Firewalls zouden eventueel ook dergelijke DNS responses kunnen blokkeren.

[neeecht]

Met een HackRF transceiver kun je zelfs een complete 2g/3g/4g man-in-the-middle setup maken.
En dat werkt prima ook. iot zoals LoRa zijn ook heel makkelijk te spoofen.

De enige beveiliging is straks je verstoppen in de massa.
Maar er zullen altijd grapjassen tussen zitten die de boel gaan verstoren.

Mijn advies, wat ik altijd geef? Doe lekker mee in de digitale wereld.
Verzet je niet tegen innovatie, MAAR weet hoe je je moet redden als alles uitvalt.
Geen stroom, geen bitjes en bijna alles staat stil.

Water/voedsel/(warm)dak boven je hoofd, zolang je die basics op #1 blijft zetten, moet je je niet zo druk maken. En de rest? Komt vanzelf, de zon straalt genoeg energie uit.

[totaalgeenhard]

Okay dus je snift een IoT de device en ziet dat het een http verzoek doet naar updates.xxxx.com dan zul je eerst die moeten hacken om er een java script op te plaatsen.

Echter je hebt een even groter probleem zonder dns en javascript omdat je gewoon firmware kunt aanpassen en IoT laten doen wat jij wilt waaronder voorkomen dat ze updates van OEM server afhalen.


Als je ingewikkelde aanval vectoren gaat verzinnen is in theorie alles mogelijk.

[BernardV]

Dat is niet wat hier gezegd wordt.
Het is dus zo dat de browser van de gebruiker via DNS-rebinding het interne netwerk gaat scannen en zo worden IoT devices gevonden. Als deze gevonden zijn is, in het geval van slechte beveiliging, het apparaat anders in te stellen, zoals de "hacker" wil.

Maar wat de kop suggereert is dat IoT devices gevoelig zijn voor DNS-rebinding, dat is niet het geval. Ze kunnen gevonden worden in een intern netwerk met behulp van DNS-rebinding, waar ze normaal "veilig" achter een firewall zaten.

[--Andre--]

Wat er dus gebeurt is dat die IoT apparaten de host header negeren. Als hierop gelet werd, dan zouden verzoeken via deze methode als ongeldig gezien worden.

[BernardV]

Dat klopt en dat zou al een groot deel schelen in de identificatie van de apparaten, maar het is sowieso mogelijk om een intern netwerk te "gokken".

Stel je gebruikt zoiets in een pagina (heb even snel een poc geschreven):
http://jsfiddle.net/xpvt214o/459388/

Je kunt in JS gewoon een call doen naar een IP adres, deze zal ten alle tijden falen door de 'cross origin policy', maar het verschil met niet bestaande ip's is dat deze een status 'error' krijgt en niet status 'timeout'.

Nu heb je met redelijke zekerheid een ip in het netwerk te pakken en kun je vanuit daar ip's gaan scannen op dezelfde manier, en daarna heb je lijst met alle "up" webservers, immers is een ajax call naar een webserver.

Vanuit daar kun je payloads gaan posten naar die ip's, je krijgt geen response terug, maar een post komt zeker aan. Dus bij genoeg schieten is er altijd een mogelijkheid dat je in te prijzen valt.

//EDIT: Fiddle met basis scanning naar devices: http://jsfiddle.net/xpvt214o/459442/

[Reactie gewijzigd door BernardV op 22 juli 2024 17:03]

[R4gnax]

Het is dus zo dat de browser van de gebruiker via DNS-rebinding het interne netwerk gaat scannen en zo worden IoT devices gevonden.

Als je dat wilt doen heb je geen DNS rebinding aanval nodig. Enige wat je nodig hebt is een courante browser die websockets ondersteunt, waarmee deze een zelf-geschreven port-scanner in JS kan uitvoeren.

Sterker nog; als een geschikt apparaat gevonden wordt, kan het via deze weg zelfs direct aangevallen worden. Enige wat je nodig hebt? Tijd. Maar dan hebben we het over de orde van grootte van ~5min om al een eind te komen. En tja; hoe lang kijkt iemand gemiddeld naar een webpagina, waar een geinfecteerde advertentie op aanwezig zou kunnen zijn?

Dat is de keerzijde van het feit dat browsers tegenwoordig zo ongeveer een eigen mini-OS zijn geworden.


Overigens ook nog een leuke voor de discussie omtrent piraterij en het feit dat Brein achter torrent uploaders aan wil gaan:

Torrent clients kunnen mbv WebRTC covert in je browser draaien en jij kunt covert via een gecompromiteerde webpagina of advertentie gedwongen deel uit gaan maken van een swarm om pirated content te gaan helpen mee verspreiden.

Zie bijv. https://webtorrent.io/ voor een open source implementatie.

[Reactie gewijzigd door R4gnax op 22 juli 2024 17:03]

[BernardV]

Inderdaad, daar had ik niet aan gedacht! Dank je voor de info.

[XiniX88]

Leuk verhaal, alleen het punt dat de DNS moet zijn veranderd naar een kwaadaardige DNS... Als je dat voor elkaar krijgt op Android, Windows, Linux, iOS of macOS, had je die rechten ook kunnen gebruiken om via een script zelf alle lokale poorten langs te gaan en dingen triggeren...

Als ze er vanuit gaan dat een persoon zelf zijn DNS aanpast is het wellicht nog makkelijker ze een app te laten installeren die het netwerk afgaat...

Ik vind het een beetje ver gezocht. Er gaat 1 handeling aan vooraf die niet zomaar wordt gedaan, hetzelfde als die email met die bijlage die je niet had moeten openen, of die app die je niet had moeten installeren.

Iot devices moeten gewoon allen zijn voorzien van sterke wachtwoorden en dan lijkt mij dit een non issue... Geen wachtwoord is geen access.

[Reactie gewijzigd door XiniX88 op 22 juli 2024 17:03]

[BernardV]

Nee, je hoeft alleen maar een domein te registeren en zelf de DNS van dat domein in beheer te hebben. Vervolgens moet je een gebruiker naar dat domein lokken.

Dus je hoeft niets aan te passen op het gebruikte apparaat.

[o0Runaljod0o]

Dat Iot apparaten slechte tot zelfs geen beveiliging hebben wisten we al, van dit bericht sta ik ook niet echt van op te kijken.

Tijd dat we er wat aan gaan doen.

[DigitalExorcist]

Doe een voorstel zou ik zeggen....

[scsirob]

Een stapje terug doen en je afvragen of de wereld echt beter wordt van de huidige IoT prullaria?

[DigitalExorcist]

Oh dat wordt t zeker. Het probleem los je niet op door terug te gaan naar het stenen tijdperk, maar door je huidige spul te beveiligen.

[MadEgg]

Dat vind jij. Ik gooi alles IoT-achtig op een apart VLAN dat niet met buiten kan communiceren. Het risico is veel te groot, en zal altijd mis blijven gaan. Het is een veel te aantrekkelijk doelwit.

Dat daardoor wat gekunstelde use cases verloren gaan kan ik niet wakker van liggen. IoT wordt veel te veel gehyped zonder nuttige toepassingen.

[DigitalExorcist]

Ja ik weet niet. IoT toepassingen voor mn huis laat ik wel met het internet communiceren, omdat ze data vanaf het internet gebruiken (weerstation, zonnepanelen, etc).

Voor toegang tot mn huisnetwerk heb ik een VPN (en nee, geen PPTP.. ;-)) en kan ik alles monitoren. Voor pushberichten heb ik Pushbullet in Domoticz.

[totaalgeenhard]

Verplichte two factor authenticatie.

Overigens het is theorie.

Cache van OS en browser spelen een rol als ook dat ze je lokale range moeten weten.

Alleen in geval roundrobin (Loadbalancing binnen DNS protocol) zou met een zeer korte TTL accepteren.

[Mijzelf]

Verplichte two factor authenticatie.

Voor IoT apparaten? Weet jij een manier om dat praktisch te houden? Als ik voor ieder IoT apparaat een hardware token nodig heb, is de lol er snel vanaf. Nog afgezien dat dan mijn home automation systeem in de vuilnisbak kan.

[DigitalExorcist]

DNSSEC zou ik zeggen?

[Mijzelf]

Wat heeft dat met two factor authenticatie te maken?

Maar als je reageert op het oorspronkelijke artikel, helpt niet. Met DNSSEC kun je garanderen dat je de dns gegevens niet onderweg worden aangepast, en dat ze van de juiste server komen.
In dit geval gaat het om de juiste server, en is de data onderweg niet aangepast.

[DigitalExorcist]

Het was op de vorige reactie bedoeld eigenlijk, en meer als vraag ;-)

Maar sowieso wordt dnssec te weinig toegepast imho

[totaalgeenhard]

Preshared keys of client side certificate en gewoon wachtwoord.

Als je eenmalig bij installatie van IoT device dit moet regelen ben je klaar.

[Verwijderd]

Duh...... Zelfs het idee dat we alle apparaten die we in huis hebben up to date kunnen houden is lachwekkend. Ik daag iedereen uit om te zien welke IP adressen er in hun huishouden is en te garanderen dat die firmware up to date is. In mijn (okay uitgebreid) huishouden met veel automation zijn dat 113 apparaten. Dat gaat van de server, via de koelkast en robot stofzuiger naar de Tesla's.

Ik ken niemand die dit soort firmware wekelijks controleert en update. Voor zover ik kan zien heb ik niet eens opties om mijn wasmachine en koelkast te updaten.

De enige manier om dit soort dingen in de hand te houden is te verhinderen dat er ongewenste dingen via de router naar buiten gaan. Zelfs het idee dat we dat per apparaat kunnen doen doet experts lachen.

[Verwijderd]

Voor zover ik kan zien heb ik niet eens opties om mijn wasmachine en koelkast te updaten.

De meeste mensen hebben geen wasmachine met internet connectiviteit. Je koelkast kan ik mij nog wat bij voorstellen, automatisch bestellingen laten plaatsen als je melk cq. boter bijna op is... maar kom op zeg je probeert een behoorlijk randgeval te positioneren alsof het de gewoonste zaak van de wereld is.

De enige manier om dit soort dingen in de hand te houden is te verhinderen dat er ongewenste dingen via de router naar buiten gaan.

Met zoveel apparaten zou ik zeker iets als pfSense draaien, en daar je dns instellen dat het niet naar lokale apparaten kan resolven. Dat is dan weer het voordeel van een randgeval zoals jij, waarschijnlijk ben je technisch genoeg om dit hele probleem op een simpele manier teniet te doen.

[SeatRider]

Tesla's ook.

[MPAnnihilator]

Besmette advertenties , tjiens, dat hebben we de laatste jaren nu nog nooit gezien.
Gewoon advertenties blijven blokkeren met een pi-hole lokale dns server, niet ? Opgelost toch ?
Vraag me trouwens af of dat met een L7 firewall zowiezo al niet geblokkeerd wordt, kan me nu niet inbeelden dat die sources met malicious javascript al niet snel op de zwarte lijst komen bij de grote security vendoren ?

Voor de rest , interne devices niet naar Internet laten connecteren , enkel via de lokale proxy...