⚠️ Le statut des services n’est pas détecté automatiquement.
Cette page est actualisée manuellement par l’équipe technique lorsqu’un incident est constaté ou qu’une opération de maintenance est programmée afin d’en informer le public.
Si un service vous semble en panne mais n’est pas indiqué comme tel ici, merci de ✉️ nous le signaler
Nous avons été récemment averti·es d'un problème de configuration logiciel pouvant permettre l'accès à des données de Framapiaf.
Ce communiqué vise à préciser dans quels ordres les informations nous sont parvenues, quelles ont été les actions entreprises, à quel moment, et l'analyse que nous en faisons.
Ceci est leur histoire. Ba-doum ! © Générique de série télé bien connu.
Pour le stockage des médias du service Framapiaf.org, l'instance du logiciel Mastodon gérée par Framasoft, nous utilisons depuis peu Minio, un logiciel libre de stockage de type ObjectStorage.
Une erreur de policy (politique de permission et d'accès) permettait à n’importe qui de demander à Minio de lui fournir la liste des fichiers du "bucket (conteneurs de base contenant des données).
Mastodon s’appuie sur les noms de fichiers aléatoires pour assurer la sécurité des fichiers privés tels les exports. Avoir la liste des fichiers permet à n’importe qui de télécharger des fichiers contenant des données privées, comme les archives d’export des données (cf Post-mortem de Mastodon.social ci-dessous pour plus d'informations).
L’erreur vient du fait que la policy d’accès anonyme aux fichiers fournie par Minio était trop permissive : il n’aurait pas fallu utiliser cette policy pré-configurée.
24 février 2023 : L'équipe qui gère l'instance Mastodon.social (la principale instance Mastodon, gérée par l'équipe de développement du logiciel) a été indirectement informée d'une mauvaise configuration de son domaine de stockage d'objets (files.mastodon.social) qui permettait à n'importe qui de voir la liste de tous les fichiers téléchargés vers files.mastodon.social ainsi que les archives générées par les utilisateur⋅ices. Cette erreur a été corrigée en moins de 30 minutes.
10 mars 2023 : la Fondation Mastodon envoie des messages pour prévenir les instances qui pourraient rencontrer le même problème le même problème de configuration.
17 mars 2023 : un post-mortem de l'incident est envoyé aux utilisateur⋅ices de Mastdon.social (voir par exemple https://mastodon.social/@gamingonlinux/110035344293178636 )
mardi 7 mars : Framasoft bascule son stockage de Ceph vers Minio, avec une configuration erronée. L’accès est autorisé aux alentours de 9h
vendredi 10 mars à 17h40 : nous recevons un message de la Fondation Mastodon nous avertissant du problème sur notre système de tickets. Le même message a été doublé par un message direct (DM) sur Mastodon et triplé par un message sur notre canal IRC. Notez que le vendredi, seule une partie très réduite de l'équipe salariée Framasoft est au travail (une majorité de salarié⋅es étant à temps partiels ou à 4j de travail par semaine), et qu'à 17H40, l'équipe technique est donc en week-end.
samedi 11 mars à 12h04 : un des salariés repère l'alerte et poste un message sur notre canal Framateam interne, avec un lien vers le ticket pointant notre souci de configuration.
samedi 11 mars à 12h15 : notre administrateur systèmes annonce avoir résolu le problème en modifiant la configuration du bucket. Les fichiers ne peuvent donc plus être listés.
lundi 20 mars : notre administrateur systèmes recherche des traces d’accès non autorisés dans les journaux ("logs") du serveur hébergeant le stockage de framapiaf.org. Aucun journal n'indique que la politique de configuration trop permissive aurait pu être utilisé.
mardi 21 mars : rédaction et publication de ce post-mortem.
Selon nos analyses, aucune donnée de Framapiaf.org n'a été accédée frauduleusement via la configuration trop permissive du bucket.
Nous remercions les équipes de la Fondation Mastodon de nous avoir prévenu, ainsi que notre équipe technique de sa réactivité.
Early morning Feb 24 we were indirectly made aware of a misconfiguration on our object storage domain (files.mastodon.social) that allowed anyone to see the list of all uploaded files.
Within 30 minutes this mistake was corrected.
However, we have reasons to believe that the issue has existed since Feb 2, when we began upgrading our infrastructure.
Normally Mastodon relies on long, randomly generated file names with high entropy to ensure that certain files are accessed only by those who know the link. However, that misconfiguration allowed that measure to be bypassed. Most files in our object storage are public in nature–profile pictures, custom emojis, images and videos attached to public posts.
But there is a type of file that should never be accessed by anyone but its owner, and it’s the user’s archive takeout. Unfortunately, your archive takeout was among those in the system when the incident occurred.
We have immediately deleted all archive takeouts to prevent anyone from downloading them, but we have reasons to believe that at least some of them were downloaded by unauthorized parties.
Archive takeouts contain the following information:
They DO NOT contain your e-mail address or any other Personal Identifiable Information from your account, excepting anything you’ve manually put in your public profile or shared in posts.
No action is required on your part.
We apologize sincerely for this mistake. We are changing the Mastodon software to not rely on high entropy links for access control to archive takeouts any longer, as well as adding an automated check into the admin dashboard to detect similar misconfigurations and notify other server operators about them. Security is important to us and we are continuously improving our processes as we scale our organization from one employee to multiple to ensure that mistakes like this do not happen in the future.