Forskare vid IoT-säkerhetsföretaget Nozomi Networks varnar för att ett populärt bibliotek för programmeringsspråket C för IoT-produkter är sårbart för DNS-cache-förgiftningsattacker. Felet är 10 år gammalt och kunde för närvarande inte åtgärdas av dess underhållare.
Nozomi säkerhetsforskare Andrea Palanca upptäckte att implementeringen av Domain Name System (DNS) av uClibc- och uClibc-ng C-bibliotek som används i flera populära IoT-produkter genererar förutsägbara, inkrementella transaktionsidentifierare (ID) i DNS-svar och nätverkskommunikation för begäranden.
uClibc slutade underhållas 2012 efter releasen av versionen uClibc-0.9.33.2, medan uClibc-ng-gaffeln är designad för användning inom OpenWRT, ett vanligt operativsystem för routrar “möjligen utplacerade i olika kritiska infrastruktursektorer”, enligt Palanca.
SER: Emotet-botnätet är tillbaka, och det har några nya knep för att sprida skadlig programvara
uClibc är också känt för att användas av Linksys, Netgear och Axis, och Linux-distributioner, såsom Embedded Gentoo, noterar Palanca.
Nozomi har valt att inte avslöja de specifika IoT-enheter som den testade eftersom buggen inte är patchad. Palanca noterar dock att de testade enheterna var “en rad välkända IoT-enheter som körde de senaste firmwareversionerna med en stor chans att de kommer att distribueras i all kritisk infrastruktur.”
UClibc-ng-gaffeln är ett litet C-bibliotek för att utveckla inbäddade Linux-system med fördelen att vara mycket mindre än GNU C-biblioteket (glibc).
Palanca säger att han rapporterade problemet till ICS-CERT i september för att genomföra ett VINCE-ärende (Vulnerability Information and Coordination Environment) med CERT/CC. I april godkände CERT/CC hans begäran om att fortsätta med avslöjande av sårbarhet den 2 maj. Problemet spåras som ICS-VU-638779, VU#473698.
CERT/CC bjöd in uClibc-ngs underhållare till VINCE-fallet i mitten av mars men utvecklaren sa att han inte kunde implementera korrigeringen själv och föreslog att dela sårbarhetsrapporten på e-postlistan med en “ganska liten community” som kanske skulle kunna hjälpa till att implementera en fix.
Sex månader efter den ursprungliga felrapporten till ICS-CERT förblir buggen oparpad och fungerar som en påminnelse om utmaningarna inom öppen källkodssäkerhet och mer allmänt mjukvarans leveranskedja på grund av brist på utvecklarresurser och finansiering.
Den största risken för DNS-förgiftningsattacker är att de kan tvinga fram ett autentiseringssvar. DNS, ofta beskrivet som “internets telefonbok”, ansvarar för att översätta IP-adresser till domännamn.
En DNS-förgiftningsattack innebär att en angripare förgiftar DNS-poster för att lura en DNS-klient att acceptera ett förfalskat svar, och från att göra ett program omdirigering av nätverkskommunikation till en slutpunkt som de kontrollerar snarare än den korrekta.
När Palanca testade en icke namngiven IoT-enhet, märkte Palanca att transaktions-ID:n – en av två hemliga bitar i fråge-svar-kommunikationen – var inkrementella. Dessa ID:n genererades av uClibc 0.9.33.2, som dess ursprungliga underhållare släppte i maj 2012.
“För att ha ett DNS-svar accepterat för en viss DNS-begäran måste ovannämnda 5-tuple, frågan och transaktions-ID vara korrekt inställda”, förklarar Palanca i ett blogginlägg.
SER: Google: Flera hackningsgrupper använder kriget i Ukraina som ett lockbete i nätfiskeförsök
Han säger att – eftersom protokollet är DNS inkluderar allmänt känd information den destinationsporten, frågan är målet som en angripare vill kompromissa, käll-IP-adressen är målmaskinen och att destinations-IP-adressen är adressen till DNS-server som används i ett visst nätverk – de enda okända kvarstår källporten och transaktions-ID.
“Det är viktigt att dessa två parametrar är så oförutsägbara som möjligt, för om de inte är det kan en förgiftningsattack vara möjlig”, konstaterar Palanca.
“Med tanke på att transaktions-ID:t nu är förutsägbart, för att utnyttja sårbarheten skulle en angripare behöva skapa ett DNS-svar som innehåller rätt källport, samt vinna tävlingen mot det legitima DNS-svaret som kommer in från DNS-servern.
“Exploatbarheten av problemet beror exakt på dessa faktorer. Eftersom funktionen inte tillämpar någon explicit källportsrandomisering är det troligt att problemet lätt kan utnyttjas på ett tillförlitligt sätt om operativsystemet är konfigurerat att använda en fast eller förutsägbar källa hamn.”
Palanca noterar att moderna Linux-kärnor möjliggör randomisering av källportar på OS-nivå, vilket gör det svårare att utnyttja för DNS-förgiftningsattacker. Men om en angripare har tillräckligt med bandbredd, kan de kanske “brute-force 16-bitars källportvärde genom att skicka flera DNS-svar, samtidigt som de vinner kapplöpningen mot det legitima DNS-svaret.”
