{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/backup-tampering/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["nginx-ui"],"_cs_severities":["critical"],"_cs_tags":["nginx-ui","backup-tampering","vulnerability"],"_cs_type":"advisory","_cs_vendors":["nginx-ui"],"content_html":"\u003cp\u003eThe \u003ccode\u003enginx-ui\u003c/code\u003e application, version v2.3.3 and earlier, contains a vulnerability in its backup and restore functionality. The backup format lacks a trusted integrity root, allowing attackers to manipulate encrypted backups. Specifically, the encryption key and initialization vector (IV) are provided to the client, and the integrity metadata (\u003ccode\u003ehash_info.txt\u003c/code\u003e) is encrypted using the same key. An attacker who obtains the backup security token can decrypt the archive, modify its contents, recalculate the integrity hashes, and re-encrypt the backup. The vulnerable code exists within \u003ccode\u003ebackup_crypto.go\u003c/code\u003e, \u003ccode\u003ebackup.go\u003c/code\u003e, \u003ccode\u003erestore.go\u003c/code\u003e, and \u003ccode\u003eSystemRestoreContent.vue\u003c/code\u003e. This vulnerability can be exploited in default Docker deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to the nginx-ui backup security token (Key and IV) through HTTP response headers or a \u003ccode\u003e.key\u003c/code\u003e file.\u003c/li\u003e\n\u003cli\u003eThe attacker decrypts the \u003ccode\u003enginx-ui.zip\u003c/code\u003e and \u003ccode\u003enginx.zip\u003c/code\u003e archives using the obtained token and AES-256-CBC.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the decrypted \u003ccode\u003eapp.ini\u003c/code\u003e file within the extracted archive to inject malicious configuration, such as setting \u003ccode\u003eStartCmd = bash\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker re-compresses the modified files into new \u003ccode\u003enginx-ui.zip\u003c/code\u003e and \u003ccode\u003enginx.zip\u003c/code\u003e archives.\u003c/li\u003e\n\u003cli\u003eThe attacker calculates the SHA-256 hashes of the re-encrypted archive files.\u003c/li\u003e\n\u003cli\u003eThe attacker updates the \u003ccode\u003ehash_info.txt\u003c/code\u003e file with the newly calculated SHA-256 hashes corresponding to the manipulated archives.\u003c/li\u003e\n\u003cli\u003eThe attacker re-encrypts the modified archive and the \u003ccode\u003ehash_info.txt\u003c/code\u003e using the original Key and IV.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads the tampered backup to the \u003ccode\u003enginx-ui\u003c/code\u003e restore interface, which accepts the malicious backup due to the lack of integrity verification. This results in the restoration of the attacker-controlled configuration and potential arbitrary command execution on the host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack allows an attacker to manipulate the \u003ccode\u003enginx-ui\u003c/code\u003e application's configuration and internal state during the restoration process. This could lead to persistent configuration tampering, backdoor insertion into the nginx configuration, execution of attacker-controlled commands depending on the configuration settings, and potentially complete compromise of the \u003ccode\u003enginx-ui\u003c/code\u003e instance. The severity is highly dependent on the restore permissions and the specific deployment configuration of \u003ccode\u003enginx-ui\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the patched version of nginx-ui (v2.3.4 or later) to remediate \u003cstrong\u003eCVE-2026-33026\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eImplement a trusted integrity root for backups. Integrity metadata must not be solely derived from data contained in the backup as described in the overview.\u003c/li\u003e\n\u003cli\u003eEnforce integrity verification in the restore operation to abort the process if hash verification fails, mitigating the tampering vulnerability detailed in the attack chain.\u003c/li\u003e\n\u003cli\u003eMonitor the \u003ccode\u003enginx-ui\u003c/code\u003e application logs for any suspicious activity related to backup and restore operations, particularly those involving warnings related to hash mismatches as described in the PoC.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-nginx-ui-backup-restore-tampering/","summary":"The nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration, potentially leading to arbitrary command execution.","title":"nginx-ui Backup Restore Allows Tampering with Encrypted Backups","url":"https://feed.craftedsignal.io/briefs/2024-01-nginx-ui-backup-restore-tampering/"}],"language":"en","title":"CraftedSignal Threat Feed - Backup-Tampering","version":"https://jsonfeed.org/version/1.1"}