Filtración de datos de China Software Developer Network en 2011

Las categorías de datos documentadas en este registro son direcciones de correo electrónico, nombres de usuario y contraseñas. La presencia de contraseñas en texto plano es el aspecto más crítico. El nombre de usuario identifica a la persona dentro de la comunidad técnica; la dirección de correo electrónico permite al atacante contactar con su objetivo. Estos tres campos, en conjunto, pueden utilizarse para ataques de adivinación de contraseñas, phishing dirigido y vinculación de cuentas de desarrolladores. Si los usuarios de CSDN han creado cuentas técnicas con el mismo nombre de usuario en otras plataformas, el riesgo aumenta. Los números de teléfono, las direcciones, la información de pago y el contenido de los repositorios de código no figuran en este registro, por lo que no se han incluido.

El incidente de CSDN se considera una filtración verificada y conocida desde hace mucho tiempo. El número de registros supera los 6,4 millones y las principales categorías de datos son de conocimiento público. No obstante, no debe suponerse que se hayan visto afectados la cuenta de trabajo actual, el repositorio de código privado o la cuenta financiera de cada usuario. Los campos expuestos son el correo electrónico, el nombre de usuario y la contraseña en texto plano. La magnitud del riesgo se debe a que la contraseña es legible y a la probabilidad de que los desarrolladores hayan mantenido los mismos hábitos de uso de contraseñas en otros servicios técnicos.

El mayor riesgo lo corren los desarrolladores que tenían una cuenta de CSDN en 2011 y utilizaban el mismo correo electrónico y la misma contraseña en foros técnicos, repositorios de código, paneles de servicios en la nube, servicios de gestión de dominios o cuentas de correo de trabajo. Las cuentas antiguas de comunidades técnicas suelen quedar en el olvido; sin embargo, sus contraseñas pueden seguir utilizándose en otros sistemas durante años. Las direcciones de correo electrónico asociadas a la identidad de un desarrollador pueden utilizarse para enviar ofertas de empleo dirigidas, alertas de seguridad falsas, solicitudes de acceso a repositorios o mensajes sobre facturación de servicios en la nube. Los usuarios técnicos pueden ser el objetivo de ataques dirigidos más complejos.

Los usuarios para quienes se detecte una coincidencia con CSDN deben asegurarse de que la contraseña que utilizaban en 2011 ya no se use en ningún sitio. Si se ha utilizado la misma contraseña o una similar en un repositorio de código, un panel de servicios en la nube, una cuenta de correo electrónico, un dominio, un foro o una cuenta de trabajo, debe cambiarse de inmediato. En las cuentas de desarrolladores, conviene dar preferencia a la autenticación de dos factores, las llaves de seguridad o la autenticación mediante aplicaciones. También es posible que las contraseñas antiguas se hayan utilizado para proteger claves SSH, archivos comprimidos o herramientas locales; esta posibilidad también debe revisarse.

La reutilización de contraseñas puede tener un impacto más amplio en las cuentas de desarrolladores que en otras cuentas de usuario. Deben utilizarse contraseñas únicas y una autenticación multifactor robusta para los repositorios de código, la infraestructura en la nube y la gestión de dominios. Las contraseñas antiguas de foros ya no deben considerarse seguras. Los usuarios deben separar el correo personal del de trabajo y evitar utilizar en sistemas críticos exactamente los mismos nombres de usuario que en sus cuentas de comunidades técnicas. Deben revisar con regularidad las notificaciones de seguridad y retirar periódicamente los accesos no autorizados a repositorios y los permisos de aplicaciones.

Si aparece una coincidencia con China Software Developer Network en la comprobación de LeakData, el usuario debe interpretarla como una advertencia sobre una contraseña antigua en texto plano que puede tener un gran impacto en la seguridad. La coincidencia no significa que se haya filtrado código ni información de pago; sin embargo, deben revisarse las cuentas críticas, dado que la contraseña quedó expuesta de forma legible. El usuario debe cambiar primero las contraseñas en todos los sistemas en los que utilizó la misma y, después, reforzar la autenticación de dos factores en sus cuentas de desarrollador. Las contraseñas nuevas derivadas del patrón de la contraseña antigua tampoco deben considerarse seguras.