Die node-netmasker NPM-pakket, wat ongeveer 3 miljoen aflaaie per week het en as 'n afhanklikheid van meer as 270 duisend projekte op GitHub gebruik word, het 'n kwesbaarheid (CVE-2021-28918) wat dit toelaat om tjeks wat die netmasker gebruik te omseil om die voorkoms te bepaal om reekse aan te spreek of vir filtering. Die probleem is opgelos in die vrystelling van node-netmask 2.0.0.
Die kwesbaarheid maak dit moontlik om 'n eksterne IP-adres as 'n adres vanaf die interne netwerk te hanteer en omgekeerd, en met 'n sekere logika om die node-netmaskermodule in die toepassing te gebruik om SSRF (Server-side request forgery), RFI uit te voer (Afgeleë lêerinsluiting) en LFI (plaaslike lêerinsluiting) aanvalle ) om toegang tot hulpbronne op die interne netwerk te verkry en eksterne of plaaslike lêers in die uitvoeringsketting in te sluit. Die probleem is dat adresstringwaardes wat met 'n nul begin, volgens die spesifikasie as oktale getalle geïnterpreteer moet word, maar die nodus-netmaskermodule neem dit nie in ag nie en hanteer dit as desimale getalle.
Byvoorbeeld, 'n aanvaller kan 'n plaaslike hulpbron versoek deur die waarde "0177.0.0.1" te spesifiseer, wat ooreenstem met "127.0.0.1", maar die "node-netmasker"-module sal die nul weggooi en 0177.0.0.1″ behandel as " 177.0.0.1", wat in die toepassing wanneer toegangsreëls geëvalueer word, dit nie moontlik sal wees om identiteit met "127.0.0.1" te bepaal nie. Net so kan 'n aanvaller die adres "0127.0.0.1" spesifiseer, wat identies moet wees aan "87.0.0.1", maar sal as "127.0.0.1" in die "node-netmasker"-module behandel word. Net so kan jy die tjek vir toegang tot intranetadresse bedrieg deur waardes soos "012.0.0.1" te spesifiseer (gelykstaande aan "10.0.0.1", maar sal tydens kontrole as 12.0.0.1 verwerk word).
Die navorsers wat die probleem geïdentifiseer het, noem die probleem katastrofies en verskaf verskeie aanvalscenario's, maar die meeste van hulle lyk spekulatief. Byvoorbeeld, dit praat oor die moontlikheid om 'n Node.js-gebaseerde toepassing aan te val wat eksterne verbindings tot stand bring om 'n hulpbron te versoek gebaseer op die parameters of data van die insetversoek, maar die toepassing is nie spesifiek genoem of gedetailleerd nie. Selfs al vind jy toepassings wat hulpbronne laai op grond van die ingevoerde IP-adresse, is dit nie heeltemal duidelik hoe die kwesbaarheid in die praktyk uitgebuit kan word sonder om aan 'n plaaslike netwerk te koppel of sonder om beheer oor "spieël" IP-adresse te verkry nie.
Die navorsers neem net aan dat eienaars van 87.0.0.1 (Telecom Italia) en 0177.0.0.1 (Brasil Telecom) die toegangsbeperking na 127.0.0.1 kan omseil. 'n Meer realistiese scenario is om die kwesbaarheid te ontgin om verskeie toepassingskant-bloklyste te omseil. Die probleem kan ook toegepas word om die definisie van intranetreekse in die NPM-module "privaat-ip" te deel.
Bron: opennet.ru