OpenJS y OpenSSF emiten una alerta sobre el riesgo de ataques de ingeniería social para tomar el control de proyectos de código abierto
- El intento de puerta trasera de XZ Utils (CVE-2024-3094) podría no ser un caso aislado.
- Al parecer, como la OpenJS Foundation bloqueó intentos similares de toma de control de confianza, esto podría no ser un incidente aislado.
- OpenSSF y la OpenJS Foundation instan a todos los mantenedores de código abierto a estar alerta ante intentos de toma de control por ingeniería social, reconocer los patrones iniciales de amenaza y tomar medidas para proteger los proyectos de código abierto.
Intentos de toma de control fallidos
- La OpenJS Foundation Cross Project Council recibió una serie de correos electrónicos sospechosos con mensajes similares.
- El remitente pidió a OpenJS que tomara medidas para actualizar uno de los proyectos populares de JavaScript para "resolver una vulnerabilidad crítica", pero no especificó detalles.
- El remitente pidió ser nombrado nuevo mantenedor del proyecto a pesar de haber participado muy poco en el código anteriormente.
- Este enfoque es muy similar al que Jia Tan usó para posicionarse en la puerta trasera de XZ/liblzma.
- No se les otorgó acceso a los proyectos alojados por OpenJS.
- El proyecto cuenta con una política de seguridad, incluyendo la explicación general del grupo operativo de seguridad de la fundación.
- El equipo de OpenJS detectó patrones sospechosos similares en dos proyectos populares de JavaScript que no están alojados por la fundación y comunicó de inmediato posibles problemas de seguridad a los líderes correspondientes de OpenJS y al CISA (Cybersecurity and Infrastructure Security Agency, Cybersicurezza e Infraestructura de Seguridad) de DHS (Department of Homeland Security, Departamento de Seguridad Nacional).
Patrones sospechosos de toma de control por ingeniería social
- Patrones
- Un miembro de la comunidad relativamente desconocido solicita de forma cordial, pero insistente y agresiva.
- Pide promover a una persona nueva o desconocida al rol de mantenedor.
- Recibe apoyo de otros miembros de la comunidad potencialmente con identidad falsa (conocidos como "sock puppets").
- PR con Blob como artefacto.
- Código fuente intencionalmente ofuscado o difícil de entender.
- Problemas de seguridad que se agravan gradualmente.
- Puede insertar una carga maliciosa externa en artefactos binarios Blob, Zip u otros al apartarse de las prácticas normales de compilación, compilado y publicación del proyecto.
- Esto ocurre especialmente cuando se presiona al administrador para que reduzca el nivel de revisión o eluda controles por la urgencia.
- Estos ataques de ingeniería social manipulan a los encargados explotando su sentido de misión hacia el proyecto y la comunidad.
- Esté atento a cómo se perciben las interacciones.
- Las interacciones que provocan dudas sobre uno mismo, sentirse inapropiado o sentir que no se contribuye lo suficiente al proyecto pueden formar parte de un ataque de ingeniería social.
- Un ataque de ingeniería social como el visto en XZ/liblzma fue evitado exitosamente por la comunidad de OpenJS.
- Este tipo de ataque es difícil de detectar o defender de forma programática porque aprovecha la manipulación de la confianza mediante ingeniería social.
- A corto plazo, compartir abiertamente e informar con transparencia sobre actividades sospechosas como las mencionadas ayudará a que otras comunidades se mantengan en alerta.
- Dar buen soporte a los mantenedores es una de las principales medidas para frenar estos ataques de ingeniería social.
Pasos para la seguridad de proyectos de código abierto
- Considerar seguir prácticas de seguridad estándar de la industria, como la Guía de OpenSSF
- Usar autenticación robusta: 2FA, administrador de contraseñas, almacenar códigos de recuperación en un lugar seguro, no reutilizar contraseñas/credenciales en servicios diferentes.
- Preparar una política de seguridad que incluya el proceso de "Coordinated disclosure"
- Aplicar buenas prácticas al fusionar código nuevo
- Habilitar protección de ramas y commits firmados.
- Si es posible, hacer que un segundo desarrollador revise el código antes de fusionar un PR, incluso si proviene de un mantenedor.
- Aplicar requisitos de legibilidad para que los nuevos PR no estén ofuscados y minimizar el uso de binarios opacos.
- Limitar quiénes tienen permiso para publicar en npm.
- Identificar committers y mantenedores y revisarlos periódicamente. Por ejemplo, ¿los has visto en una reunión de un grupo de trabajo o en algún evento?
- Si operas un repositorio de paquetes de código abierto, considerar adoptar los principios para Package Repository Security.
- Revisar "Evitar ataques de ingeniería social y phishing" de CISA y/o "Qué es la ingeniería social" de ENISA.
Acciones de industria y gobierno para la seguridad de la infraestructura crítica de código abierto
- Mantener proyectos de código abierto seguros y estables es una presión constante para los mantenedores.
- Se necesita gran volumen de recursos mediante colaboración internacional público-privada.
- Ya se está haciendo un trabajo excelente en muchas instituciones, como Open Source Foundations, el Sovereign Tech Fund y otras.
- Se requiere el esfuerzo de organizaciones similares a la familia de fundaciones Linux para brindar una red de seguridad a proyectos de código abierto.
- Es alentador que el gobierno de Alemania esté invirtiendo en infraestructura de código abierto crítica mediante la iniciativa Sovereign Tech Fund.
- Se respalda una mayor inversión pública global en iniciativas como la Sovereign Tech Fund de Alemania para escalar la inversión pública internacional.
Opinión de GN⁺
- Los atacantes están aprovechando astutamente la sensación de responsabilidad de los mantenedores para perturbar a los desarrolladores, por eso conviene prestar atención a los cambios emocionales que sienten los mantenedores respecto del proyecto.
- Se está de acuerdo en invertir más en seguridad, pero al final, en esencia, la cultura de desarrollo debería cambiar hacia una mayor prioridad a la seguridad. La seguridad debe impregnar naturalmente todo el proceso de desarrollo.
- Como los atacantes se aprovechan de la confianza de la comunidad, en los proyectos de código abierto también conviene hacer esfuerzos continuos para construir y fortalecer la confianza entre los miembros. La comunicación cara a cara podría ser el inicio de eso.
- Deberían crearse y apoyarse más proyectos como Alpha-Omega que inviertan en mejoras reales de vulnerabilidades. Solo así podrá mejorar de forma tangible la seguridad de los proyectos de código abierto.
1 comentarios
Opinión de Hacker News
Resumen: