Solucionado ataque de seguridad a Eslint en menos de 12 horas
Si un atacante consiguiese encontrar una debilidad en su software o consiguiera introducir un código malicioso, ¿cuánto tiempo cree que tardarían en detectar el problema y corregirlo? Puede que ya lo tengan y aún no lo sepan.
El 12 de Julio del 2018, un atacante consiguió hacerse con el email y password de uno de los usuarios que dan soporte a la librería Eslint (podéis encontrarla en npm, github), una librería que nos permite validar nuestro código javascript mediante unas reglas.
“ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript.”
Una vez dentro, introdujo un código malintencionado que enviaría nuestro contenido del archivo .npmrc a una web maliciosa. Este archivo es el encargado de configurar la dirección del registry de las dependencias de npm y donde a menudo, tendremos indicado nuestro usuario, password y puede que la configuración de nuestro proxy corporativo para la conexión.
Es decir, en el caso de que hayamos tenido dicha dependencia instalada, nuestro usuario, password y demás configuraciones en dicho archivo, ya estarán rondando por internet.
¿Cómo saber si me ha afectado? Esta librería puede que la tengamos instalada, si tenemos webpack o babel-eslint instalado. Si tenéis algún proyecto frontend con Reactjs, Angular, Vuejs, Polymer… lo más problable es que tengáis webpack instalado. Como solo afecta a una versión determinada, eslint-scope@3.7.2 y eslint-config-eslint@5.0.2, podéis buscar en vuestras dependencias por si las tenéis.
¿Qué hacer en el caso de que haya sido afectado? Avisar rápidamente en tu empresa, actualizar la versión de la librería para subsanar el problema de seguridad y actualizar el password.
¿Podíamos haber evitado este problema? Una forma fácil de evitar de tener datos sensibles en nuestro .npmrc, es hacer uso de un Nexus interno de nuestra empresa, donde apuntaremos con nuestro registry. De esta forma, dicho software se encargará de la seguridad, descarga de dependencias, cacheo, etc… de todos los usuarios.
Resumiendo, en el caso de que este problema de seguridad, hubiera ocurrido en una librería o software privado y no en uno Open Source, posiblemente no habría sido detectado con dicha velocidad.
No se puede comparar la creatividad, esfuerzo y motivación de miles de personas que colaboran gratuitamente con un pequeño equipo en una empresa.