Une plongée plus approfondie dans l'incident de sécurité de mai 2019: commentaires sur les articles de blog
Nous venons de publier une mise à jour de l'incident de sécurité survenu en mai 2019 avec des détails techniques sur ce qui s'est passé, comment cela s'est passé et les mesures correctives que nous avons appliquées pour empêcher qu'un incident comme celui-ci ne se reproduise. Voici quelques extraits de l'article - d'abord de l'introduction:
Le 12 mai 2019, vers 00h00 UTC, nous avons été alertés d'une élévation de privilèges inattendue pour un nouveau compte utilisateur par plusieurs membres de la communauté. Un utilisateur que personne n'a reconnu avait obtenu un accès de niveau modérateur et développeur sur tous les sites du réseau Stack Exchange. Notre réponse immédiate a été de révoquer les privilèges et de suspendre ce compte, puis de lancer un processus pour identifier et auditer les actions qui ont conduit à l'événement.
Après la découverte initiale, nous avons constaté que l'escalade de privilèges n'était que la pointe de l'iceberg et que l'attaque avait en fait entraîné l'exfiltration de notre code source et l'exposition par inadvertance des PII (e-mail, nom réel, adresses IP) de 184 utilisateurs. du réseau Stack Exchange (qui ont tous été notifiés). Heureusement, aucune des bases de données - ni publique (lire: contenu Stack Exchange) ni privée (Teams, Talent ou Enterprise) - n'a été exfiltrée. De plus, il n'y a eu aucune preuve d'accès direct à notre infrastructure de réseau interne et à aucun moment l'attaquant n'a jamais eu accès aux données des produits Teams, Talent ou Enterprise.
Et du dernier paragraphe:
Cet incident nous a rappelé certaines pratiques de sécurité fondamentales que tout le monde devrait suivre:
- Enregistrez tout votre trafic entrant. Nous conservons des journaux sur toutes les connexions entrantes. Cela a permis toutes nos enquêtes. Vous ne pouvez pas enquêter sur ce que vous ne consignez pas.
- Utilisez 2FA. Ce système restant qui utilise toujours l'authentification héritée peut être votre plus grande vulnérabilité.
- Gardez mieux les secrets. TeamCity a un moyen de protéger les secrets, mais nous avons constaté que nous ne l'utilisions pas systématiquement. Apprenez aux ingénieurs que «les secrets ne sont pas que des mots de passe». Protégez également les clés SSH et les chaînes de connexion à la base de données. En cas de doute, protégez-les. Si vous devez stocker des secrets dans un dépôt Git, protégez-les avec git-crypt ou Blackbox .
- Validez les demandes des clients. Plus une demande d'un client est inhabituelle, plus il est important de vérifier si la demande est légitime ou non.
- Prenez les rapports de sécurité au sérieux. Nous sommes reconnaissants que notre communauté ait signalé une activité suspecte aussi rapidement. Merci!
Il y en a beaucoup plus dans l'article du blog - n'hésitez pas à poser des questions ou des commentaires concernant l'article ci-dessous et nous ferons de notre mieux pour y répondre. Nous ne sommes pas en mesure de commenter d'autres détails liés à l'attaque au-delà de ce qui est inclus dans le billet de blog, en raison d'enquêtes en cours.
Réponses
Pouvez-vous faire des commentaires sur les intentions des attaquants?
Semble-t-il qu'ils recherchaient un certain objectif / certaines données (utilisateur)?
Ou était-ce peut-être plutôt un «adolescent curieux» qui piquait avec des bâtons pour voir jusqu'où ils pouvaient aller?
PS merci pour l'ouverture sur ce sujet, c'est vraiment apprécié!
Cette ligne:
Cet acte de recherche de choses (visites de questions) sur le réseau Stack Exchange devient fréquent et nous permet d' anticiper et de comprendre la méthodologie de l'attaquant au cours des prochains jours. (c'est moi qui souligne)
donne l'impression qu'en temps réel , alors que l'attaque se produisait, vous pouviez identifier ce que l'attaquant ferait en fonction de ce qu'il a visité sur Stack Overflow, au lieu de ce qu'il a fait en examinant de manière médico-légale ce qu'il a vu (après l'attaque). Lequel vouliez-vous dire?
Plusieurs questions concernaient principalement l'attaquant:
- Qu'est-il arrivé à l'attaquant?
- Avez-vous suspendu leur compte?
- Est-ce que SE a contacté l'attaquant à un moment donné?
- Pourquoi ne dévoilez-vous pas l'identité de l'attaquant?
- Quelqu'un d'autre a-t-il essayé d'utiliser cette même méthode d'attaque plus tard?
Y a-t-il eu un cycle de sommeil détectable à l'autre extrémité des événements?
Modifier pour clarifier:
Après avoir pris connaissance de l'attaquant, et comme vous avez suivi certaines de ses actions au fur et à mesure de leur déroulement, avez-vous remarqué quelque chose ressemblant à un cycle biologique, à la fois au jour le jour et rétrospectivement? Par exemple: manger (pauses de 1 à 2 heures), dormir (schéma d'inactivité de 8 heures), «siestes» (90 minutes), etc.
Cela ne fait pas vraiment partie de l'incident, mais une préoccupation plus générale concernant les mesures de sécurité autour des comptes des employés. Il y avait beaucoup d'étapes dans cet incident, mais la dernière était l'augmentation des privilèges d'un compte SE. Je peux imaginer des façons beaucoup plus simples de tenter cela que d'obtenir un accès administrateur au serveur CI via l'instance de développement pour exécuter SQL en production, et je suis intéressé par les mesures d'atténuation et de sécurité mises en œuvre par SE pour se défendre contre des tentatives plus simples de gagner. accès à un compte d'employé.
Vous ne pouvez évidemment pas mettre les principaux sites SE derrière le pare-feu, ils seront donc toujours exposés. Et la méthode de connexion interne SE ne fournit aucune méthode 2FA, ce que je trouve quelque peu inquiétant.
- les comptes des employés 2FA sont-ils protégés par d'autres moyens (ou d'autres fournisseurs de connexion)?
- Existe-t-il des mesures pour garantir qu'aucune adresse e-mail privée ou fournisseur de connexion ne soit attaché aux comptes des employés qui pourraient être moins sécurisés et être encore utilisés pour recevoir des e-mails de récupération afin d'accéder au compte?
- existe-t-il une surveillance des tentatives de connexion à partir de nouvelles sources pour les comptes des employés?
- Existe-t-il des protections supplémentaires pour les outils dangereux des employés au cas où quelqu'un accède à une session en cours d'un compte d'employé (par exemple, demander à nouveau un mot de passe et / ou un jeton 2FA lors de l'accès à des outils critiques pour la sécurité)
Quelque chose comme le spear phishing est probablement encore l'un des moyens les plus probables pour quelqu'un d'essayer d'accéder à un compte d'employé.
À peu près au même moment où cet incident de sécurité s'est produit, quelques jours plus tard, certains utilisateurs ont commencé à remarquer que le oneboxing Twitter dans le chat ne fonctionnait plus . Un employé a par la suite confirmé en février de l'année prochaine qu'il avait effectivement été désactivé intentionnellement en raison de la nécessité de «combler certaines lacunes» à la suite de cet incident de sécurité.
Pouvons-nous obtenir une explication complète de la raison pour laquelle la oneboxing Twitter dans le chat a dû être désactivée à la suite de cet incident de sécurité? Le billet de blog publié à l'époque indiquait que "d'autres vecteurs potentiels" avaient été fermés à ce moment-là, et le message du personnel de février 2020 que j'ai lié ci-dessus indiquait que la fonction oneboxing de Twitter "utilisait l'une des lacunes que nous avons comblées". Quelle était cette chose et quel risque de sécurité a-t-elle créé?
Enfin, est-il possible que cette fonctionnalité puisse être à nouveau implémentée, de manière sécurisée? En août 2020, quelques mois après le message du personnel ci-dessus, le rapport de bogue déposé à l'époque a été marqué statut par conception par un autre employé. Une demande de fonctionnalité pour modifier le design (de manière sécurisée) serait-elle envisagée, ou est-il impossible de le faire sans ouvrir un vecteur d'attaque?
Je signalerais que les types de paramètres "mot de passe" dans TeamCity ne sont pas considérés comme sécurisés:
La valeur du mot de passe est stockée dans les fichiers de configuration sous TeamCity Data Directory. En fonction des paramètres de chiffrement du serveur, la valeur est soit brouillée, soit chiffrée avec une clé personnalisée.
La valeur du journal de construction est masquée par un simple algorithme de recherche et de remplacement, donc si vous avez un mot de passe trivial de "123", toutes les occurrences de "123" seront remplacées, exposant potentiellement le mot de passe. La définition du paramètre sur le type de mot de passe ne garantit pas que la valeur brute ne peut pas être récupérée. Tout administrateur de projet peut le récupérer, et tout développeur qui peut modifier le script de génération peut potentiellement écrire du code malveillant pour obtenir le mot de passe.
Pourquoi le lien magique en dev visible par les CM (vraisemblablement juste en dev) était-il un véritable lien magique?
C'est vraiment un rapport d'incident génial! L'un des meilleurs que j'ai lus.
Merci à Stack de l'avoir rendu public et à Dean pour cette excellente rédaction!
Je suis juste curieux de savoir peu de choses:
- Quelle est la taille de l'équipe d'intervention en cas d'incident?
- Des protocoles spécifiques ont-ils été suivis pendant l'enquête?
- Quel facteur clé a été impliqué pour engager un fournisseur de sécurité externe? Quels ont été les points pris en compte lors du choix de ce fournisseur en particulier?
- Quelles leçons ont été tirées du fournisseur de sécurité externe? Leur processus d'audit était-il différent (efficace / inefficace) de celui déjà utilisé par l'équipe?
L'article donne un bon aperçu de toute l'architecture de Stack et des processus de développement. Une lecture plus détaillée serait ou un lien s'il y a déjà un article à ce sujet serait génial.
Sous "Conseils aux autres":
Enregistrez tout votre trafic entrant. Nous conservons des journaux sur toutes les connexions entrantes. Cela a permis toutes nos enquêtes. Vous ne pouvez pas enquêter sur ce que vous ne consignez pas.
Comment un réseau aussi occupé que Stack Exchange peut-il enregistrer l'intégralité du trafic entrant? S'agit-il d'entrées de serveur Web de journaux, de flux IP ou de sessions TCP complètes?
Je pourrais enregistrer la plupart des entrées et des tentatives de connexion sur mon petit réseau, mais je n'ai aucune idée de la façon dont un si grand réseau le fait.
Pouvez-vous expliquer plus clairement ce que signifie «propriétés accessibles au public» dans la citation ci-dessous?
nous avons une base de données contenant un journal de tout le trafic vers nos propriétés accessibles au public