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

Permalänk
Melding Plague

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

Produkter från nätverksaktörer likt Axis, Linksys och Netgear är i farozonen på grund av en sårbarhet i biblioteket Uclibc.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk

Bara köpa nytt, vi behöver mer ewaste. De som säger att man ska ha svindyra utvecklare som sitter och underhåller gammal dritt. Så undrar jag om de sitter kvar på 14,4Kbps modem eller tagit steget till de nya 28,8Kbps modem än?

Vissa saker som routrar borde kunna underhållas, men för varje år vill folk ha mer skit som ska ha direktanslutning.

Permalänk
Medlem

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

Visa signatur

CPU: 5600x
GPU: 3080
RAM: 32GB

Sluta gömma din identitet, skaffa en till istället

Permalänk
Medlem

Usch, det här påminner mig om "busybox" som används på många produkter som routers etc. Problemet är inte linux eller andra IoT system utan det är tillverkarna som inte bryr sig om att uppdatera systemen när det upptäcks buggar, eller ens att uppdatera systemen till det att EOL har uppnåtts.

Det hittas ju hål, brister och annat hela tiden, jag upplever det som att man numera istället blivit ännu sämre på att uppdatera och bara vill kränga en ny produkt. Det är nästan så att en produkt bara har max ett år och sedan är det EOL på den. Absurt.

Permalänk
Medlem

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.

Visa signatur

Intel® Core i7-13700K @ 5.7/5.6GHz | ASRock Z690 Extreme | G.Skill Trident Z 32GB @ DDR4-3400 CL14 | Samsung EVO series M.2 + Sata SSDs 2TB | Intel Arc A750 | SuperFlower Titanium 1000W | Gigabyte M32Q 32"/1440p 165Hz | Arctic Freezer II 360 AIO | Phanteks P500A D-RGB | Windows 10 & 11 x64 Professional

Permalänk
Medlem
Skrivet av RPGWiZaRD:

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.

Just när det gäller Axis så är det relativt relativt bra på att uppdatera sin kamera FW och att agera på CVEer mm, kolla här: https://help.axis.com/axis-os#knowledge-base

Permalänk
Medlem
Skrivet av hakd:

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

Dock så handlar det ju inte om att de kan se din trafik, utan som det låter kan de ändra dina DNS-uppslag. Du frågar om banken.se men får ett svar som pekar dig till hackarnas server istället.

Permalänk
Medlem
Skrivet av Kamouflage:

Dock så handlar det ju inte om att de kan se din trafik, utan som det låter kan de ändra dina DNS-uppslag. Du frågar om banken.se men får ett svar som pekar dig till hackarnas server istället.

Satan, det e ju min bank!

Visa signatur

Diplomacy is the art of saying 'Nice doggie!'... till you can find a rock.

Permalänk
Medlem

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

Permalänk
Medlem

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?

Permalänk
Hedersmedlem

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

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Permalänk
Medlem
Skrivet av DasIch:

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

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?

Citat:

It is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port

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).

Permalänk
Medlem
Skrivet av DasIch:

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

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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Thomas:

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

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

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem

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.

Visa signatur

Ryzen 7 3800X, Asus Prime X370 Pro, 32 GB LPX 3600, Gainward RTX 3060 Ti Ghost, 7 TB SSD + 4 TB HDD

Permalänk
Medlem

"för att sedan injicera falska svar för att komma åt och ändra på vissa DNS-inställningar"
Det är väl inte så det står i artikeln grund artikeln.
Jag snabbläste bara men såg it som de kan ändra DNS inställningar men att de som då daton kollar första logiska svar den går kan man få den att gå till en felaktig adress. Men det ändrar ju inte några DNS inställningar.

Visa signatur

CPU: 5900x. Mem:64GB@3200 16-17-17-34-1T. (ImDIsk)
GPU: 1080 Ti@ca 6-7%OC. Sound: SB-Z -> toslink (DTS)-> old JVC. MB Realtek to Z-2300 for VOIP.

Permalänk
Hedersmedlem
Skrivet av evil penguin:

Jo, han var bra tidigt ute. Snubben är ju en ren legend; varenda människa som använt internet de senaste 20 åren lär ha (ffa indirekt) använt några av hans skapelser, om inte annat så via ChaCha20 och Poly1305 i TLS.

Bara att han mer eller mindre själv gjorde så att stark kryptografi kan exporteras från USA lär ju ha gjort stor skillnad för hur internet fungerar idag.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Permalänk
Medlem
Skrivet av KAD:

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?

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.

Skrivet av KAD:

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

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.

Skrivet av KAD:

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).

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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Kamouflage:

Dock så handlar det ju inte om att de kan se din trafik, utan som det låter kan de ändra dina DNS-uppslag. Du frågar om banken.se men får ett svar som pekar dig till hackarnas server istället.

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.

Visa signatur

CPU: 5600x
GPU: 3080
RAM: 32GB

Sluta gömma din identitet, skaffa en till istället

Permalänk
Medlem

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.

Permalänk
Medlem
Skrivet av prod01:

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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av hakd:

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.

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..

Permalänk
Skrivet av hACmAn:

"för att sedan injicera falska svar för att komma åt och ändra på vissa DNS-inställningar"
Det är väl inte så det står i artikeln grund artikeln.
Jag snabbläste bara men såg it som de kan ändra DNS inställningar men att de som då daton kollar första logiska svar den går kan man få den att gå till en felaktig adress. Men det ändrar ju inte några DNS inställningar.

Dåligt översatt eller skribenten som inte förstått "attacken" riktigt för det är ju som du säger, de kan inte komma åt inställningar eller ändra inställningar i ens dns mjukvara genom denna exploit.

Skrivet av hakd:

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.

En vpn anslutning kan använda sina egna inställningar för dns uppslagning men det är inget garanterat, så som i att en vpn har en egen dns uppslagning men det är väl rätt standard bland anonymitets vpn leverantörer att de har egna dns inställningar de kör med i sina program.

Permalänk
Medlem
Skrivet av Kamouflage:

Dock så handlar det ju inte om att de kan se din trafik, utan som det låter kan de ändra dina DNS-uppslag. Du frågar om banken.se men får ett svar som pekar dig till hackarnas server istället.

My bad, fixat, hoppas jag.

Permalänk
Medlem
Skrivet av ubkr:

Just när det gäller Axis så är det relativt relativt bra på att uppdatera sin kamera FW och att agera på CVEer mm, kolla här:

Axis har uppdaterat med uppgifter kring det här (https://www.axis.com/support/product-security):

Citat:

2022-05-05 Statement from Axis Communications on the uClibc DNS vulnerability discovered by Nozomi Networks (CVE-2021-43523). Axis has not incorporated the uClibc package since 2010 in Axis products, software and services. To date, no active selling or discontinued Axis product that is still under hardware or software support is therefore affected by this vulnerability except for the AXIS P7701 Video Decoder. We are currently awaiting the availability of an upstream patch to be available to judge if we can provide a service release that patches this vulnerability.

Skulle man dessutom gått in på länken till uClibc's så kallade produkt sida (länken fungerar inte längre men finns på WayBackMachine) som uppgiften om att "de flesta produkter från Axis" och andra använder uClibc kom från så skulle man sett att den liksom andra sidor på uClibc's site inte är uppdaterade sedan 2012. Det är alltså inte helt och hållet troligt att de andra som stod på den sidan fortfarande använder uClibc.

Till Sweclockers skribenter:
Skriv gärna och mycket om säkerhetsproblem i produkter och häng gärna ut bolag som inte sköter sig men lägg ribban lite högre och gör en egen värdering av saker innan ni skriver om det. Företag som Nozomi Networks gör mycket rätt men det är också väldigt mycket ute efter sensations rubrikerna så att de kan få med uppmärksamhet och fler jobb...