{"id":105307,"date":"2022-10-14T15:36:38","date_gmt":"2022-10-14T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah"},"modified":"2022-10-14T15:36:38","modified_gmt":"2022-10-14T13:36:38","slug":"ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/ataka-na-npm-pozvolyayushhaya-opredelit-nalichie-paketov-v-privatnyh-repozitoriyah","title":{"rendered":"Angriff auf NPM, der es erm\u00f6glicht, das Vorhandensein von Paketen in privaten Repositories zu bestimmen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In NPM wurde eine Schwachstelle entdeckt, die es erm\u00f6glicht, die Existenz von Paketen in geschlossenen Repositories festzustellen. Das Problem resultiert aus unterschiedlichen Reaktionszeiten bei der Abfrage eines existierenden und nicht existierenden Pakets durch einen externen Benutzer, der keinen Zugriff auf das Repository hat. Bei fehlendem Zugriff auf beliebige Pakete in privaten Repositories gibt der Server registry.npmjs.org einen Fehler mit dem Code \u201e404\u201c zur\u00fcck, w\u00e4hrend im Falle eines bestehenden Pakets mit dem angeforderten Namen der Fehler mit sp\u00fcrbarer Verz\u00f6gerung ausgegeben wird. Ein Angreifer kann diese Eigenschaft nutzen, um die Verf\u00fcgbarkeit eines Pakets durch das Ausprobieren von Paketnamen aus W\u00f6rterb\u00fcchern zu bestimmen. <\/p>\n
Die Bestimmung von Paketnamen in geschlossenen Repositories kann f\u00fcr einen Angriff durch das Mischen von Abh\u00e4ngigkeiten erforderlich sein, der das \u00dcberlappen von Abh\u00e4ngigkeiten in \u00f6ffentlichen und internen Repositories manipuliert. Wenn der Angreifer wei\u00df, welche internen NPM-Pakete in den Unternehmensrepositories vorhanden sind, kann er Pakete mit denselben Namen und neueren Versionsnummern in einem \u00f6ffentlichen NPM-Repository ver\u00f6ffentlichen. Wenn interne Bibliotheken bei der Erstellung nicht explizit auf ihr Repository festgelegt werden, wird der Paketmanager npm das \u00f6ffentliche Repository als priorit\u00e4r betrachten und das vom Angreifer vorbereitete Paket herunterladen. <\/p>\n
GitHub wurde im M\u00e4rz \u00fcber das Problem informiert, lehnte jedoch ab, einen Schutz gegen den Angriff hinzuzuf\u00fcgen, und verwies auf architektonische Einschr\u00e4nkungen. Unternehmen, die private Repositories verwenden, wird empfohlen, regelm\u00e4\u00dfig nach \u00fcberschneidenden Namen im \u00f6ffentlichen Repository zu suchen oder unter ihrem Namen Platzhalter mit Namen zu erstellen, die die Namen von Paketen in privaten Repositories wiederholen, damit Angreifer ihre Pakete mit \u00fcberschneidenden Namen nicht hochladen k\u00f6nnen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"