Fuite de données de China Software Developer Network en 2011

Les catégories de données attestées sont les adresses e-mail, les noms d’utilisateur et les mots de passe. La présence de mots de passe en clair est le point le plus critique. Le nom d’utilisateur révèle l’identité de la personne au sein de la communauté technique; l’adresse e-mail permet à l’attaquant de contacter sa cible. Ensemble, ces trois champs peuvent servir à des attaques visant à deviner les mots de passe, à des tentatives d’hameçonnage ciblé et au rapprochement de comptes de développeurs. Le risque augmente si les utilisateurs de CSDN ont créé leurs comptes techniques sur d’autres plateformes avec le même nom d’utilisateur. Les numéros de téléphone, les adresses, les informations de paiement et le contenu des dépôts de code ne figurant pas dans cette fiche, ils n’ont pas été inclus.

L’incident CSDN est considéré comme une fuite connue de longue date et vérifiée. Le nombre d’enregistrements dépasse 6,4 millions et les principales catégories de données sont publiques. Il ne faut toutefois pas en déduire que le compte professionnel actuel, le dépôt de code privé ou le compte financier de chaque utilisateur a été touché. Les champs exposés sont l’adresse e-mail, le nom d’utilisateur et le mot de passe en clair. L’ampleur du risque tient au fait que le mot de passe est lisible et à la probabilité que les développeurs aient conservé les mêmes habitudes de réutilisation des mots de passe sur d’autres services techniques.

Les développeurs qui possédaient un compte CSDN en 2011 et utilisaient la même adresse e-mail et le même mot de passe sur des forums techniques, des dépôts de code, des consoles cloud, des services de gestion de domaines ou des messageries professionnelles sont les plus exposés. Les anciens comptes de communautés techniques sont souvent oubliés; pourtant, leurs mots de passe peuvent rester utilisés sur d’autres systèmes pendant des années. Les adresses e-mail associées à une identité de développeur peuvent servir à envoyer des offres d’emploi ciblées, de fausses alertes de sécurité, des demandes d’accès à des dépôts ou des messages de facturation cloud. Les utilisateurs techniques peuvent être la cible d’attaques plus complexes et ciblées.

Les utilisateurs pour lesquels une correspondance avec CSDN est détectée devraient s’assurer que le mot de passe utilisé en 2011 ne l’est plus nulle part. Si ce même mot de passe, ou un mot de passe similaire, a été utilisé pour un dépôt de code, une console cloud, une messagerie, un domaine, un forum ou un compte professionnel, il devrait être changé immédiatement. Pour les comptes de développeurs, il convient de privilégier l’authentification à deux facteurs, les clés de sécurité ou l’authentification par application. D’anciens mots de passe peuvent aussi avoir servi à protéger des clés SSH, des archives ou des outils locaux; cette possibilité devrait également être examinée.

La réutilisation des mots de passe peut avoir des conséquences plus étendues sur les comptes de développeurs que sur ceux des autres utilisateurs. Des mots de passe uniques et une authentification multifacteur robuste devraient être utilisés pour les dépôts de code, l’infrastructure cloud et la gestion des domaines. Les anciens mots de passe de forums ne devraient plus être considérés comme sûrs. Les utilisateurs devraient séparer leurs adresses e-mail personnelles et professionnelles, et éviter d’utiliser exactement les mêmes noms d’utilisateur sur les communautés techniques et sur les systèmes critiques. Les notifications de sécurité devraient être consultées régulièrement, et les accès non autorisés aux dépôts ainsi que les autorisations des applications devraient faire l’objet d’un nettoyage périodique.

Si la vérification LeakData fait apparaître une correspondance avec China Software Developer Network, l’utilisateur devrait y voir un avertissement lié à un ancien mot de passe en clair présentant un risque élevé. Cette correspondance ne signifie pas que du code ou des données de paiement ont fuité; les comptes critiques devraient néanmoins être vérifiés en raison de cette exposition passée d’un mot de passe lisible. L’utilisateur devrait d’abord changer le mot de passe sur tous les systèmes où il l’avait réutilisé, puis renforcer l’authentification à deux facteurs de ses comptes de développeur. Les nouveaux mots de passe dérivés de la structure de l’ancien ne devraient pas non plus être considérés comme sûrs.