The release of the Restic 0.18 backup system has been announced, allowing for the storage of backups in encrypted form in a versioned repository with deduplication support. The system is initially designed for environments that are not trusted, ensuring that if a backup falls into the wrong hands, the system remains uncompromised. Flexible rules can be defined for including and excluding files and directories when creating a backup (the rules format resembles rsync or gitignore). It supports operation on Linux, macOS, Windows, and BSD systems. The project code is written in Go and is distributed under the BSD license.
Backups can be stored in local file systems, on external server with access via SFTP/SSH or HTTP REST, on cloud services like Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage, and Google Cloud Storage, as well as in any storage systems for which rclone backends are available. For storage, the developing project rest server can also be utilized, providing higher performance compared to other backends and capable of operating in a read-only mode that prevents deletion or modification of backups in the event of a compromise of the source server and access to the encryption keys.
The system supports snapshots that reflect the state of the directory hierarchy at different points in time (snapshots are automatically created for each backup). Snapshots can be copied between different repositories. To save bandwidth during the backup creation process, only changed data is copied. A snapshot with a backup can be mounted as a virtual partition (mounting is done using FUSE). Additionally, commands are provided for analyzing changes and selectively extracting files.
The backup storage in Restic manipulates not complete files but blocks of variable sizes, chosen using Rabin fingerprints. Information is stored in reference to content rather than file names (data-related names and objects are defined at the block metadata level). To save space in storage and avoid unnecessary data duplication, deduplication is performed.
On external servers, information is stored encrypted—SHA-256 hashes are used for checksums and deduplication, the AES-256-CTR algorithm for encryption, and Poly1305-AES authentication codes to ensure integrity. There is an option to verify backups through checksums and authentication codes to confirm that the files' integrity has not been compromised.
In the new version, the possibility of a (PDF) attack that determines the presence of certain files in the encrypted backup storage has been eliminated. This attack allows the identification of whether a specific file exists in the encrypted backup by gaining access to the storage or through network traffic analysis of the backups. For example, the attack could be carried out by a server administrator where backups are stored, an internet service provider, or intelligence agencies that have gained access to server or the traffic. The goal of the attack could be to investigate a data leak, in which case the agencies could assess the presence of documents of interest in the backup storage.
To exploit the vulnerability, the attacker must manage to include their data in the victim's backup or know that a file they are aware of is present in the backup. If the backup contains a file known to the attacker (for example, some standard system or multimedia content), then by accessing the encrypted storage, the attacker can determine if other files of interest are also present.
The method is based on the fact that due to the characteristics of content compression, the parameters of the blocks used when fragmenting the content can be identified. It is sufficient to identify three encrypted blocks containing data known to the attacker to determine such parameters.
The vulnerability is not specific to Restic and affects other backup systems that use data block separation through CDC (Content-Defined Chunking) techniques, such as BorgBackup, Tarsnap, Bupstash, and Duplicacy. In Tarsnap, the issue was resolved in update 1.0.41, while work on a fix for BorgBackup is underway and intended to be included in the borg 2 branch. The last update for Bupstash was 2 years ago, and for Duplicacy, it was 4 months ago.
It is also noted that in systems using deduplication, when there's an option to add your own files to the backup, one could take a simpler approach and determine the presence of interesting files indirectly. After adding the file being checked, one can evaluate the change in storage size — if the file already exists in storage, its re-addition due to deduplication will not lead to a significant increase in size.
In addition to addressing the vulnerability in Restic 0.18, several new features have also been introduced:
- Experimental support for "cold" backup storage has been added (data becomes available for extraction within minutes or hours after a request), supporting the S3 protocol, such as Amazon S3 Glacier.
- Support for output in JSON format has been added to the check and tag commands.
- When building images for GitHub Container Registry, recommendations from SLSA (Supply-chain Levels for Software Artifacts) have been taken into account.
- The ls command has added the option to choose the output sorting method. The find command now defaults to sorting by date (from newest to oldest).
- A feature has been provided to exclude files smaller than a specified size from the repacking operation.
- A setting has been added to enable/disable the restoration of extended file attributes.
- Support for DragonFlyBSD has been added.
- Support for extended file attributes on systems with NetBSD 10+ has been added.
- In the restic 0.19.0 branch, support for deprecated features activated through settings deprecate-legacy-index, deprecate-s3-legacy-layout, explicit-s3-anonymous-auth, and safe-forget-keep-tags is set to be removed.
- Support for older versions of Windows and macOS has been discontinued; at least Windows 10, Windows Server 2016, or macOS 11 is now required. Support for TLS versions prior to 1.2 has been discontinued.
Source: opennet.ru
