{"id":99604,"date":"2021-03-29T10:22:51","date_gmt":"2021-03-29T08:22:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-npm-pakete-node-netmask-primenyaemom-v-270-tysyachah-proektah"},"modified":"2021-03-29T10:22:51","modified_gmt":"2021-03-29T08:22:51","slug":"uyazvimost-v-npm-pakete-node-netmask-primenyaemom-v-270-tysyachah-proektah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/uyazvimost-v-npm-pakete-node-netmask-primenyaemom-v-270-tysyachah-proektah","title":{"rendered":"Vulnerabilidad en el paquete NPM node-netmask, utilizado en 270 mil proyectos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En el paquete NPM node-netmask, que cuenta con alrededor de 3 millones de descargas semanales y se utiliza como dependencia en m\u00e1s de 270 mil proyectos en GitHub, se ha detectado una vulnerabilidad (CVE-2021-28918) que permite eludir las verificaciones donde se utiliza la m\u00e1scara de red para determinar la inclusi\u00f3n en rangos de direcciones o para filtrado. El problema ha sido solucionado en la versi\u00f3n 2.0.0 de node-netmask. <\/p>\n
La vulnerabilidad permite tratar una direcci\u00f3n IP externa como si fuera una direcci\u00f3n de red interna y viceversa, y con una l\u00f3gica espec\u00edfica utilizando el m\u00f3dulo node-netmask en la aplicaci\u00f3n, realizar ataques SSRF (Server-side request forgery), RFI (Remote File Inclusion) y LFI (Local File Inclusion) para acceder a recursos en la red interna e incluir archivos externos o locales en la cadena de ejecuci\u00f3n. El problema radica en que, de acuerdo con la especificaci\u00f3n, los valores de direcci\u00f3n que comienzan con cero deben interpretarse como n\u00fameros octales, pero el m\u00f3dulo \u00abnode-netmask\u00bb no toma en cuenta esta particularidad y los maneja como n\u00fameros decimales. <\/p>\n
Por ejemplo, un atacante puede solicitar un recurso local al especificar el valor \u00ab0177.0.0.1\u00bb, que corresponde a \u00ab127.0.0.1\u00bb, pero el m\u00f3dulo \u00abnode-netmask\u00bb descartar\u00e1 el cero y tratar\u00e1 \u00ab0177.0.0.1\u00bb como \u00ab177.0.0.1\u00bb, lo que en la aplicaci\u00f3n, al evaluar las reglas de acceso, no permitir\u00e1 determinar la identidad con \u00ab127.0.0.1\u00bb. De manera similar, un atacante puede indicar la direcci\u00f3n \u00ab0127.0.0.1\u00bb, que deber\u00eda ser id\u00e9ntica a \u00ab87.0.0.1\u00bb, pero en el m\u00f3dulo \u00abnode-netmask\u00bb se tratar\u00e1 como \u00ab127.0.0.1\u00bb. De la misma manera, se puede enga\u00f1ar a la verificaci\u00f3n de acceso a direcciones intranet al especificar valores como \u00ab012.0.0.1\u00bb (equivalente a \u00ab10.0.0.1\u00bb, pero al comprobarlo se tratar\u00e1 como \u00ab12.0.0.1\u00bb). <\/p>\n