Mantén seguras tus credenciales de código abierto

A principios de este mes, un investigador llamado ChALkeR compartió su investigación sobre credenciales filtradas en paquetes npm. Los hallazgos mostraron que las credenciales, como tokens y contraseñas de npm y GitHub, se incluyen con frecuencia en paquetes npm publicados o repositorios de GitHub. De hecho, 13 de los 15 paquetes npm más populares dependen de paquetes con credenciales filtradas, lo que expone a sus usuarios.

La publicación de ChALKeR es interesante y, hasta donde sé, es el primer análisis de credenciales filtradas centrado en npm, pero el problema no es nuevo. Hace casi tres años, la búsqueda de GitHub facilitó encontrar claves privadas (según se informó, se expusieron claves del equipo de Chrome), y Google puede exponer todo tipo de información privada. A medida que el código se vuelve más fácil de encontrar, también será más fácil detectar errores como este, lo que hace aún más importante que tomes medidas.

Para asegurarte de seguir las pautas de seguridad adecuadas, descarga la guía de Snyk con 10 prácticas recomendadas de seguridad para npm. Aprenderás a adoptar prácticas seguras para usar npm, útiles para desarrolladores de Node.js y JavaScript.

Por qué deberían preocuparte las credenciales filtradas

Filtrar credenciales significa exponer secretos que dan acceso a distintas cuentas.

Los tipos más comunes de credenciales filtradas son contraseñas, claves de API y claves privadas SSH. Estas claves pueden bastar para que una herramienta automatizada —tuya o de un atacante— realice una acción, como publicar una nueva versión de un paquete o eliminar código. Las acciones que permite cada clave varían según la clave y el sistema.

Si usas paquetes de código abierto, las credenciales que más deberían preocuparte son las que permiten publicar código nuevo, como un token de npm o una clave de implementación de GitHub. Un atacante con acceso a ellas puede publicar fácilmente una nueva versión de “corrección” con código malicioso, que muchas veces instalarás sin darte cuenta.

Si alojas tu proyecto de código abierto en algún lugar, también debes tener cuidado de no filtrar información sobre tus sistemas de ejecución. Esto va más allá de npm: podrías exponer tus claves de AWS, tus claves privadas SSH o contraseñas de distintos sistemas. Cualquiera de estas claves podría darles acceso a tu sistema a los atacantes, quienes podrían usarlo para robar tu propiedad intelectual y los datos de tus usuarios, o simplemente obtener capacidad de cómputo gratis (y dejarte con la factura).

Como desarrollador de código abierto, ¿qué debo hacer?

Además de ser consciente del riesgo, debes incorporar algunas prácticas recomendadas a tu flujo de trabajo y agregar varias capas de defensa que ayuden a evitar errores. Estas son algunas sugerencias específicas que puedes considerar:

Evita los comandos git add * indiscriminados

Usar comodines puede incluir fácilmente archivos locales que no tenías intención de compartir. Esto es especialmente importante al agregar subcarpetas completas (por ejemplo, git add dirname), ya que también se incluirán los archivos ocultos (dot).

En lugar de usar comodines, especifica cada archivo que confirmes o usa git add -p para revisar cada cambio que agregues.

Agrega los nombres de los archivos confidenciales a .gitignore y .npmignore

Tanto git como npm admiten un archivo local que enumera las exclusiones del empaquetado y las confirmaciones, y puedes usarlo como medida de seguridad para evitar incluir archivos confidenciales por accidente. Si no especificas exclusiones, npm seguirá ignorando ciertos archivos, pero git los incluirá todos. Más allá de las opciones predeterminadas, ninguna de las dos herramientas conoce tu aplicación tan bien como tú, así que lo mejor es que edites estos archivos tú mismo.

Algunos archivos con los que debes tener cuidado son:

• Archivos de configuración de CI (por ejemplo, .travis.yml, circle.yml)

• Dockerfile y docker-compose.yml

• Archivos de salida de compilación (por ejemplo, gypi)

• Scripts de implementación personalizados (por ejemplo, cualquier archivo dentro de /deploy/ o /scripts/).

ChALKeR menciona algunos otros ejemplos en su publicación, y puedes consultar los archivos .gitignore de ejemplo de GitHub para obtener más ideas.

Ten en cuenta que las exclusiones predeterminadas más amplias de npm se incorporaron recién en npm@2.14.1, así que asegúrate de actualizar a esa versión o a una posterior.

Cifra las claves o usa variables de entorno al publicar desde CI

Si publicas en npm a través de tu CI, esta necesitará acceder a tu token de npm, y es fácil incluirlo por error en los archivos de configuración de CI y exponerlo.

Siempre que sea posible, usa una variable de entorno para guardar el token. Así lo mantendrás fuera del control de versiones y oculto en la salida (al menos en Travis y Circle). Si por algún motivo tienes que incluir una clave en el control de versiones (por ejemplo, si quieres confirmar contenido en GitHub), asegúrate de cifrarla bien.

git-secrets: un hook de git evita confirmar credenciales

Michael Dowling, de AWS Labs, publicó recientemente una herramienta útil llamada git-secrets. La herramienta se conecta a git commit e interrumpe la confirmación si incluye patrones que parecen credenciales. Es una buena protección adicional centrada en el contenido, que complementa la protección basada en nombres de archivo sugerida anteriormente.

Es importante tener en cuenta que debes detectar estos datos antes de confirmar los cambios (o, mejor dicho, antes de hacer push), como lo hace esta herramienta. En los proyectos de código abierto, probar como parte del proceso de CI o del pull request es demasiado tarde: las credenciales ya se filtraron.

Invalida las credenciales filtradas

Por último, si te enteras de que ya filtraste una clave o contraseña, asegúrate de invalidar esos tokens rápidamente.

No bastará con eliminar el token de la versión o rama más reciente. Aunque borres las referencias históricas, las copias de tu clave seguirán circulando, incluso si ahora las eliminas de GitHub y npm: internet nunca olvida. También es buena idea revisar si alguien usó la clave mientras tanto para publicar código malicioso o acceder a tus sistemas.

Como consumidor de código abierto, ¿qué debo hacer?

Como consumidor de paquetes de código abierto, no hay mucho que puedas hacer. Al usar un paquete, confías explícitamente en él e implícitamente en las dependencias que incorpora. Los errores de seguridad de esas dependencias pueden poner en riesgo tus propios sistemas, ya sea por credenciales filtradas o vulnerabilidades (puedes usar Snyk para abordar estas últimas). Según ChALKeR, GitHub y npm ya invalidaron las credenciales que descubrió, respectivamente, y las credenciales invalidadas ya no representan un riesgo de seguridad (siempre que no se hayan aprovechado mientras tanto).

Dicho esto, si quieres tomar la iniciativa, puedes auditar tus propias dependencias y comprobar si comparten información que consideras que no deberían. Un poco de bash puede ayudarte a encontrar los archivos ocultos pertinentes en tus dependencias. Después, podrás decidir si contienen información privada.

Este comando de bash para Mac/Linux te ayudará a empezar. Encuentra algunos de estos archivos, elimina los duplicados y los muestra junto con el nombre del archivo:

find . \( -name '*.gypi' -o -name '.npmrc' -o -name '.travis.yml' \) | xargs md5 -r | sort | awk '{print $2" "$1}' | uniq -f1 | sort | awk '{print "echo "$1";cat "$1}'

Resumen

Desarrollar de forma abierta es excelente, pero no todo está destinado a compartirse. Filtrar credenciales pone en riesgo a quienes usan tus paquetes y, a su vez, a sus usuarios.

Mantén tus credenciales separadas del código y asegúrate de que todos conozcan este riesgo y estén atentos. Busca filtraciones durante las revisiones de código e incluye esta tarea en tus prácticas habituales. Además de establecer procesos, configura las protecciones descritas arriba para detectar errores humanos. Por último, si descubres que filtraste credenciales, gestiónalo bien: invalida los tokens, avisa a tus usuarios y revisa tu código para detectar rastros maliciosos.