La version 0.18 du système de sauvegarde Restic a été présentée, permettant de stocker des sauvegardes de manière chiffrée dans un dépôt versionné avec support de la déduplication. Le système est conçu pour que les sauvegardes soient conservées dans des environnements non dignes de confiance, et le fait que la sauvegarde tombe entre de mauvaises mains ne doit pas compromettre le système. Lors de la création d'une sauvegarde, il est possible de définir des règles flexibles pour inclure et exclure des fichiers et des répertoires (le format des règles ressemble à rsync ou gitignore). La prise en charge comprend Linux, macOS, Windows et les systèmes BSD. Le code du projet est écrit en Go et est distribué sous la licence BSD.
Les sauvegardes peuvent être stockées sur le système de fichiers local, sur un externe le serveur avec un accès via SFTP/SSH ou HTTP REST, dans les clouds Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage et Google Cloud Storage, ainsi que dans tout stockage pour lequel des backends rclone sont disponibles. Pour le stockage, le projet développe également un serveur rest, offrant des performances supérieures par rapport aux autres backends et capable de fonctionner en mode uniquement complémentaire, empêchant la suppression ou la modification des sauvegardes en cas de compromission du serveur d'origine et d'accès aux clés de chiffrement.
Le système prend en charge les snapshots, reflétant l'état de l'arborescence des répertoires à différents moments (les snapshots sont créés automatiquement pour chaque sauvegarde). Il est possible de copier des snapshots entre différents dépôts. Pour économiser de la bande passante lors de la création de sauvegardes, seules les données modifiées sont copiées. Un snapshot avec une sauvegarde peut être monté sous forme de partition virtuelle (le montage se fait via FUSE). Des commandes sont également fournies pour analyser les modifications et extraire sélectivement des fichiers.
Le dépôt de sauvegarde dans Restic manipule non pas des fichiers entiers, mais des blocs de taille variable, sélectionnés à l'aide de la signature de Rabin. Les informations sont stockées en lien avec le contenu, et non les noms de fichiers (les noms et objets liés aux données sont définis au niveau des métadonnées du bloc). Pour économiser de l'espace de stockage et éviter une duplication inutile des données, la déduplication est effectuée.
Sur des serveurs externes, les informations sont sauvegardées sous forme chiffrée — pour les sommes de contrôle et la déduplication, des hachages SHA-256 sont utilisés, pour le chiffrement, l'algorithme AES-256-CTR, et pour garantir l'intégrité, des codes d'authentification basés sur Poly1305-AES. Il est possible de vérifier la sauvegarde par les sommes de contrôle et les codes d'authentification pour confirmer que l'intégrité des fichiers n'est pas compromise.
La nouvelle version a éliminé la possibilité de mener une attaque (PDF) permettant de déterminer la présence de fichiers spécifiques dans le stockage chiffré des sauvegardes. Cette attaque permet de savoir si un fichier particulier se trouve dans la sauvegarde chiffrée en accédant au stockage des sauvegardes ou en analysant le trafic réseau associé aux sauvegardes. Par exemple, un administrateur de serveur sur lequel les sauvegardes sont conservées, un fournisseur d'accès Internet ou des agences de renseignement ayant accès au serveur ou au trafic. L'objectif de l'attaque pourrait être d'enquêter sur une fuite d'informations, où les agences de renseignement pourraient évaluer la présence de documents d'intérêt dans le stockage des sauvegardes.
Pour exploiter la vulnérabilité, l'attaquant doit parvenir à ajouter ses propres données dans la sauvegarde de la victime ou savoir qu'un fichier connu se trouve dans la sauvegarde. Si la sauvegarde contient un fichier dont l'attaquant a connaissance (par exemple, un contenu multimédia ou un système standard), alors en accédant au stockage chiffré, l'attaquant peut déterminer s'il y a d'autres fichiers d'intérêt à l'intérieur.
La méthode repose sur le fait qu'en fonction des caractéristiques de compression du contenu, il est possible de déterminer les paramètres des blocs utilisés lors de la fragmentation des données. Pour déterminer de tels paramètres, il suffit d'identifier 3 blocs chiffrés contenant des données connues de l'attaquant.
La vulnérabilité n'est pas spécifique à Restic et affecte d'autres systèmes de sauvegarde qui utilisent la technique CDC (Content-Defined Chunking) pour diviser les données, tels que BorgBackup, Tarsnap, Bupstash et Duplicacy. Dans Tarsnap, le problème a été corrigé dans la mise à jour 1.0.41, dans BorgBackup, des travaux sont en cours pour un correctif qui devrait être inclus dans la branche borg 2. Dans Bupstash, la dernière modification date de 2 ans, et dans Duplicacy, cela fait 4 mois.
Il est également à noter que dans les systèmes utilisant la déduplication, lorsque la possibilité d'ajouter vos propres fichiers à la sauvegarde est disponible, il est possible d'agir plus simplement et de définir la présence des fichiers d'intérêt par des moyens indirects. Après l'ajout du fichier vérifié, il est possible d'évaluer la modification de la taille du stockage : si le fichier est déjà dans le stockage, son ajout à nouveau en raison de la déduplication ne conduira pas à une augmentation significative de la taille.
En plus de corriger la vulnérabilité dans Restic 0.18, plusieurs nouveautés ont également été proposées :
- Une prise en charge expérimentale des « cold storage » pour les sauvegardes (les données deviennent accessibles pour extraction quelques minutes ou heures après la demande), prenant en charge le protocole S3, telles que Amazon S3 Glacier, a été ajoutée.
- Les commandes check et tag ont ajouté le support de la sortie au format JSON.
- Lors de la création d'images pour GitHub Container Registry, les recommandations SLSA (Supply-chain Levels for Software Artifacts) ont été prises en compte.
- La commande ls a ajouté le choix du méthode de tri de la sortie. Par défaut, la commande find utilise le tri par date (des plus récents aux plus anciens).
- La possibilité d'exclure du processus de réemballage des fichiers de taille inférieure à celle spécifiée a été fournie.
- Un paramètre pour activer/désactiver la récupération des attributs étendus des fichiers a été ajouté.
- Un support pour le système d'exploitation DragonFlyBSD a été ajouté.
- Le support des attributs étendus des fichiers sur les systèmes NetBSD 10+ a été ajouté.
- Dans la branche restic 0.19.0, il est prévu de supprimer le support des fonctionnalités obsolètes, activées par les paramètres deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth et safe-forget-keep-tags.
- Le support des anciennes versions de Windows et macOS a été abandonné ; désormais, au minimum Windows 10, Windows Server 2016 ou macOS 11 est requis. Le support des versions de TLS inférieures à 1.2 a été arrêté.
Source : opennet.ru
