Difekto estis identigita en NPM, kiu permesas vin detekti la ekziston de pakaĵoj en fermitaj deponejoj. La problemo estas kaŭzita de malsamaj respondaj tempoj kiam oni petas ekzistantan kaj neekzistantan pakaĵon de tria partio, kiu ne havas aliron al la deponejo. Se ne ekzistas aliro por iuj pakaĵoj en privataj deponejoj, la servilo registry.npmjs.org resendas eraron kun la kodo "404", sed se ekzistas pako kun la petita nomo, la eraro estas elsendita kun rimarkinda prokrasto. Atakanto povas uzi ĉi tiun funkcion por determini la ĉeeston de pakaĵo serĉante pakaĵnomojn uzante vortarojn.
Determini pakaĵnomojn en privataj deponejoj povas esti necesa por elfari dependec-miksatakon kiu manipulas la intersekciĝon de dependecnomoj en publikaj kaj internaj deponejoj. Sciante kiuj internaj NPM-pakaĵoj ĉeestas en kompaniaj deponejoj, atakanto povas meti pakaĵojn kun la samaj nomoj kaj pli novaj versinumeroj en la publikan NPM-deponejon. Se dum asembleo la internaj bibliotekoj ne estas eksplicite ligitaj al sia deponejo en la agordoj, la pakaĵmanaĝero npm konsideros la publikan deponejon pli alta prioritato kaj elŝutos la pakaĵon preparitan de la atakanto.
GitHub estis sciigita pri la problemo en marto sed rifuzis aldoni protekton kontraŭ la atako, citante arkitekturajn limigojn. Firmaoj uzantaj privatajn deponejojn estas rekomenditaj periode kontroli la aspekton de imbrikitaj nomoj en la publika deponejo aŭ krei ĝermojn sur sia nomo kun nomoj kiuj ripetas la nomojn de pakaĵoj en privataj deponejoj, tiel ke atakantoj ne povas meti siajn pakaĵojn kun imbrikitaj nomoj.
fonto: opennet.ru