Die Version 0.18 des Backup-Systems Restic wurde veröffentlicht. Es ermöglicht die Speicherung von Backups in verschlüsselter Form in einem versionierten Repository mit Deduplizierungsunterstützung. Das System ist ursprünglich so konzipiert, dass Backups in unsicheren Umgebungen gespeichert werden, und der Zugriff auf ein Backup durch Dritte sollte das System nicht gefährden. Bei der Erstellung eines Backups können flexible Regeln für das Ein- und Ausschließen von Dateien und Verzeichnissen definiert werden (das Regelwerk ähnelt rsync oder gitignore). Die Anwendung unterstützt Linux-, macOS-, Windows- und BSD-Systeme. Der Code des Projekts ist in Go geschrieben und wird unter der BSD-Lizenz veröffentlicht.
Backups können auf einem lokalen Dateisystem, auf externen Server mit SFTP/SSH- oder HTTP REST-Zugriff auf Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage und Google Cloud Storage sowie in jedem Speicher, für den rclone-Backends verfügbar sind. Zudem kann der vom Projekt entwickelte Rest-Server verwendet werden, der eine höhere Leistung im Vergleich zu anderen Backends bietet und im Modus nur zur Ergänzung betrieben werden kann, sodass Löschungen oder Änderungen von Backups im Falle einer Kompromittierung des Ursprungsservers und des Zugriffs auf die Verschlüsselungsschlüssel nicht möglich sind.
Das System unterstützt Snapshots, die den Zustand der Verzeichnisstruktur zu verschiedenen Zeitpunkten widerspiegeln (Snapshots werden automatisch für jede Sicherung erstellt). Es ist möglich, Snapshots zwischen verschiedenen Repositories zu kopieren. Um den Datenverkehr zu reduzieren, werden beim Erstellen von Sicherungen nur die geänderten Daten kopiert. Ein Snapshot mit einem Backup kann als virtuelles Laufwerk bereitgestellt werden (die Bereitstellung erfolgt über FUSE). Außerdem stehen Befehle zur Analyse von Änderungen und für die selektive Wiederherstellung von Dateien zur Verfügung.
Das Backup-Speicher in Restic arbeitet nicht mit vollständigen Dateien, sondern mit variablen Größenblöcken, die mithilfe der Rabin-Signatur ausgewählt werden. Die Informationen werden in Bezug auf den Inhalt und nicht auf die Dateinamen gespeichert (datenbezogene Namen und Objekte werden auf der Metadatenebene des Blocks definiert). Um Speicherplatz zu sparen und unnötige Datenkopien zu vermeiden, wird eine Deduplizierung durchgeführt.
Auf externen Servern werden die Informationen verschlüsselt gespeichert – für Prüfziffern und Deduplizierung kommen SHA-256-Hashes zum Einsatz, für die Verschlüsselung der AES-256-CTR-Algorithmus, und zur Gewährleistung der Integrität werden Authentifizierungscodes auf Basis von Poly1305-AES verwendet. Es besteht die Möglichkeit, das Backup anhand von Prüfziffern und Authentifizierungscodes zu verifizieren, um sicherzustellen, dass die Integrität der Dateien nicht beeinträchtigt wurde.
In der neuen Version wurde die Möglichkeit beseitigt, einen Angriff (PDF) durchzuführen, um das Vorhandensein bestimmter Dateien im verschlüsselten Speicher der Backups zu überprüfen. Solch ein Angriff ermöglicht es, festzustellen, ob sich eine bestimmte Datei im verschlüsselten Backup befindet, indem man entweder auf den Backup-Speicher zugreift oder den Netzwerkverkehr der Backups analysiert. Beispielsweise kann ein Serveradministrator, der die Backups speichert, ein Internetanbieter oder eine Sicherheitsbehörde, die Zugang zu Server oder dem Datenverkehr hat, einen solchen Angriff durchführen. Ziel eines solchen Angriffs könnte die Untersuchung eines Datenlecks sein, bei dem die Sicherheitsbehörden den Bestand an relevanten Dokumenten im Backup-Speicher bewerten können.
Um die Schwachstelle auszunutzen, muss der Angreifer es schaffen, seine eigenen Daten in das Backup des Opfers einzufügen oder wissen, dass eine ihm bekannte Datei im Backup vorhanden ist. Wenn ein im Backup enthaltenes File bekannt ist (z. B. ein typischer System- oder Multimediainhalt), kann der Angreifer durch den Zugriff auf den verschlüsselten Speicher feststellen, ob sich darin andere für ihn interessante Dateien befinden.
Die Methode basiert darauf, dass man anhand der Besonderheiten der Inhaltskompression die Parameter der Blöcke bestimmen kann, die beim Zerlegen des Inhalts verwendet werden. Um solche Parameter zu bestimmen, reicht es aus, 3 verschlüsselte Blöcke zu identifizieren, die Daten enthalten, die dem Angreifer bekannt sind.
Die Schwachstelle ist nicht spezifisch für Restic und betrifft auch andere Backup-Systeme, die Daten mit der Technik CDC (Content-Defined Chunking) in Blöcke aufteilen, wie etwa BorgBackup, Tarsnap, Bupstash und Duplicacy. In Tarsnap wurde das Problem mit dem Update 1.0.41 behoben, während in BorgBackup an einer Lösung gearbeitet wird, die in den Branch borg 2 aufgenommen werden soll. Das letzte Update für Bupstash liegt 2 Jahre zurück, und für Duplicacy war es vor 4 Monaten.
Zusätzlich wird angemerkt, dass in Systemen, die Deduplizierung verwenden, bei der Möglichkeit, eigene Dateien in das Backup hinzuzufügen, einfacher vorgegangen werden kann, indem das Vorhandensein interessierender Dateien indirekt bestimmt wird. Nach der Hinzufügung der geprüften Datei kann die Änderung der Speichergröße bewertet werden – wenn die Datei bereits im Speicher vorhanden ist, führt ihre erneute Hinzufügung aufgrund von Deduplizierung nicht zu einer signifikanten Vergrößerung der Größe.
Neben der Behebung von Sicherheitsanfälligkeiten in Restic 0.18 wurden auch mehrere Neuerungen angekündigt:
- Experimentelle Unterstützung für 'kalte' Backup-Speicher wurde hinzugefügt (Daten sind Minuten oder Stunden nach der Anfrage verfügbar), die das S3-Protokoll unterstützen, wie z. B. Amazon S3 Glacier.
- Die Befehle check und tag unterstützen nun die Ausgabe im JSON-Format.
- Bei der Erstellung von Images für das GitHub Container Registry wurden die Empfehlungen von SLSA (Supply-chain Levels for Software Artifacts) berücksichtigt.
- Der Befehl ls bietet jetzt die Möglichkeit, die Sortiermethode der Ausgabe auszuwählen. Im Befehl find wird standardmäßig nach Datum (von neueren zu älteren) sortiert.
- Es wurde die Möglichkeit hinzugefügt, Dateien mit einer Größe unter einem bestimmten Wert von der Umverpackungsoperation auszuschließen.
- Es wurde eine Einstellung hinzugefügt, um die Wiederherstellung erweiterter Dateiattribute ein- oder auszuschalten.
- Unterstützung für das Betriebssystem DragonFlyBSD wurde hinzugefügt.
- Unterstützung für erweiterte Dateiattribute auf Systemen mit NetBSD 10+ wurde hinzugefügt.
- In der Version restic 0.19.0 ist die Entfernung der Unterstützung für veraltete Funktionen geplant, die über die Einstellungen deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth und safe-forget-keep-tags aktiviert wurden.
- Die Unterstützung älterer Versionen von Windows und macOS wurde eingestellt. Ab sofort ist mindestens Windows 10, Windows Server 2016 oder macOS 11 erforderlich. Die Unterstützung für TLS-Versionen unter 1.2 wurde ebenfalls eingestellt.
Quelle: opennet.ru
