Sårbarhet kan leda till DNS-förgiftning i mängder av hårdvara

Vill dom titta på min wireguard trafik så go for it..

Exakt vilka produkter påverkas? Är t.ex. övervakningskameror i farozonen? Axis är ju väldigt känd aktör i den marknaden och många företag har Axis kameror.

Hur skyddad är man mot sådana attacker om man kör en egen rekursiv DNS (Pihole med Unbound)?

Påverkar det här vanliga switchar inom hemnätverket? Låter som att det är routrar och annat som kopplas upp mot nätet?

Hur kommer det sig att de inte hittat denna förrän nu?
Liknande buggar var ju på tapeten för ett bra tag sen nu, så man tycker att folk borde ha gått igenom alla vanliga DNS-bibliotek nu.

Relaterad attack från 2008: https://www.wired.com/2008/11/ff-kaminsky/
Relaterad attack från 2020: https://www.cs.ucr.edu/~zhiyunq/pub/ccs20_dns_poisoning.pdf

Immun gissar jag, eftersom ett sådant system antagligen använder glibc.

Jag är verkligen ingen expert på DNS, men förutsättningen för att få till poisoning är ju att routern/Pi-Hole ställer en DNS-fråga till en upstream-server. Hela grejen med att ha en lokal DNS är väl att den ska cacha DNS-förfrågningar, så förfrågningarna kommer knappast att utföras särskilt ofta, för sådana hosts som är intressanta att attackera ("banken.se")?

Om man kan avlyssna trafiken vet man redan vem som frågat och exakt hur, eftersom DNS mot port 53 är okrypterat. Då bör det vara enkelt att fejka ett svar till exakt rätt ställe, i frånvaro av andra säkerhetsmekanismer i svaret (och svaret står ju den som attackerar för...). Trafiken går ju normalt till ISP:n som har upstream-DNS:en (men det är möjligt att folk skickar sina okrypterade DNS-förfrågningar över halva internet, till typ 1.1.1.1).

Artikeln är rätt oklar över hur en attack skulle gå till om man inte kan avlyssna trafiken. TransaktionsId:t verkar vara 16 bitar (65535 alternativ) och porten som används på klientsidan har ca 30 000 alternativ (Linux) och jag gissar att porten slumpas ganska bra eftersom det är kärnan som står för att välja den. Ska man spamma frågeställaren med 30000*n DNS-svar kontinuerligt oavsett om en fråga ställts eller ej? Hur hjälper det att transkations-Id:t är sekventiellt i så fall, minskar n på något vis från 2^16?

Och varför i hela helvetet skulle någon få för sig att göra det?

Sedan förutsätter det hela att den som utför attacken kan låtsas att den är den korrekta mottagaren av nyttotrafiken. Om man surfar till "banken.se" så används ju ett TLS-cert och att presentera ett sådant utan att faktiskt vara "banken.se" är inte trivialt. Funkar alldeles säkert för statliga aktörer, men inte nödvändigtvis för en normal cyberkriminell. Okrypterad trafik över protokoll där servern inte autentiseras ligger förstås risigt till, typ gammal hederlig SMTP (skicka e-post).

Unbound har inte* det oönskade beteendet som detta handlar om, så om alla dina enheter använder en lokal Unbound-server så är även en eventuell klient som använder uclibc (någon iot/embedded-pryttel typ, är väl där detta bibliotek förekommer i första hand?) så måste attacken i så fall ske i ditt lokala nät, så ytterst begränsad möjlighet för någon att utnyttja sårbarheten.

Sedan är ju felet som detta handlar om välkänt sedan gammalt, varianter på detta var mycket vanligt förr, nyheten är att de nu upptäckt att uclibc inte åtgärdat felet typ 20 år senare. Och sedan då något alarmerande för de som nyttjar uclibc att de "inte har möjlighet" att åtgärda felet och hoppas att någon hjälper till efter att detta uppmärksammas publikt.
Vi får väl hoppas att det funkar någorlunda snabbt, kanske att något av de välkända bolagen som använder biblioteket i sina produkter skjuter till lite resurser för att lösa problemet.

* Definitivt inte vad gäller transaktionsid, och vad gäller slumpad källport så är iaf default-inställningarna bra, men på den punkten kan man nog sabotera genom konfigurationsfilen om man så vill. Om man begränsar vilka portar Unbound får använda (mha outgoing-port-permit/outgoing-port-avoid) till ett litet antal portar så hjälper det ju inte att den sedan slumpar vilken port den ska ta, så det bästa är ju att bara låta Unbound göra sin grej om man inte har någon väldigt god anledning att begränsa vilka portar den får använda.

Relaterat från 2002: https://cr.yp.to/djbdns/forgery.html

Har sedan länge stängt av DNS-relayen i routern och kör dnsmasq på min Raspberry Pi istället så förhoppningsvis är man inte påverkad eller så kommer en fix snart i så fall.

Swec-artikeln länkar detta om själva fyndet i uclibc: https://www.nozominetworks.com/blog/nozomi-networks-discovers...

Där framgår det att transaktionsid i uclibc väljs på ett förutsägbart sätt (inte slumpat) och att biblioteket inte gör någon ansats att själv välja en slumpad källport.

Där gör ju dock de flesta operativsystem viss nytta med sitt standardbeteende, som de konstaterar använder Linux t.ex. en slumpad port 32768–60999 om man inte väljer något själv.
Sedan är ju 32768–60999 knappt 15 bitars entropi istället för "nästan 16" som de flesta väl satsar på när de själva slumpar en port, men det är ju klart bättre än inget.

Uclibc hamnar ju dock långt ifrån de "nästan 32" (16 + "nästan 16") som väl numera mer eller mindre är det förväntade, där är ju själva bristen.
Och problemet blir väl just att en attackerare i blindo kan skicka t.ex. 2^15 gissningar tillräckligt snabbt för att ha en realistisk möjlighet att ändå vara först. Dvs ren brute force.
Detta exempel då utifrån förutsättningen för uclibc på Linux där ingen mixtrat med inställningarna, om man kör något ännu mer embedded-fokuserat så kan man ju inte utesluta att förutsättningarna kan vara värre, kanske även förutsägbara portar? Då blir det ju öppet mål istället för bara rejält svagt skydd.

Okunskap i vissa fall, förekommer än idag folk som får för sig att de ska sätta sourceporten till 53, t.ex, vad gäller DNS-mjukvara, men det är väl mindre sannolikt om man ser till inställningar på OS-nivå (som verkar vara vad uclibc fallet tillbaka på).
Så konkret vad gäller detta så är det nog det jag nämnde tidigare, uclibc på något OS som inte som standard slumpar sourceporten på något sätt som iaf delvis räddar situationen. Något embedded-kör med mer primitiv IP-stack, typ.

Ja, det kan absolut vara en räddning. Rent allmänt känns ju "banken.se" som något som förmodligen är ett mer eller mindre irrelevant exempel eftersom vi iaf just nu inte observerat att detta bibliotek används på någon enhet som en användare surfar på eller liknande. Det känns mer som att scenariot skulle vara något som en IoT-grej ansluter till på egen hand, och då handlar det ju om dels om den använder TLS öht, och om den gör det att det inte är alltför trasigt implementerat.

En Vpn har en egen DNS uppslagning som sker genom tunneln.
Skulle dom ändra så jag inte kan nå min tunnel så bryts anslutningen till internet helt.

Jag kanske missar nåt, men vad har det förutsägbara transaktions-id:t med saken att göra?
Om de sniffar trafiken kan de väl kopiera transaktions-id från anropet (även om det är randomiserat) och svara tillbaka snabbare än dns-servern.

Poängen är just att attackeraren inte behöver se trafiken.
OM attackeraren är i en position att se trafiken så spelar inget av detta någon roll, men det ställer ju högre krav på vem som kan utföra attacken.

En VPN kan ha en egen DNS via tunneln. Oavsett så kan de inte lyssna på din trafik, det är ju inte det sårbarheten gäller.
Är du sårbar kan man dock antagligen göra en del kreativa saker. T.ex. om din router (som antagligen inte kör Wireguard) kör någon remoteuppdatering och blir lurad att ladda hem ett kapat paket..

My bad, fixat, hoppas jag.