Docusnap for Windows Vulnerability Let Attackers Access Sensitive Data
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
A critical information disclosure vulnerability in Docusnap, a widely used IT inventory management solution, allows attackers to decrypt sensitive system data collected from Windows hosts.
Designated as CVE-2025-26849, the flaw stems from the use of a static encryption key to protect inventory files, rendering the encryption effectively useless.
These files, intended to securely catalog installed software, firewall rules, local administrators, and other system details, are accessible to any domain user with read permissions due to insecure default configurations.
Docusnap’s client software for Windows generates encrypted XML inventory files during scheduled scans.
These files are stored on network shares with permissions typically granted to the “Authenticated Users” Active Directory group, which includes read access by default.
Critical Vulnerability in Docusnap
While the files are encrypted using AES-256 in CBC mode, the decryption key is hardcoded into the vendor’s .NET-based server application.
Attackers can extract this static key from the software’s binaries, enabling them to decrypt any inventory file and gain insights into system configurations that could facilitate lateral movement or privilege escalation.
The vulnerability affects Docusnap Client for Windows versions 13.0.1440.24261 and earlier, with evidence suggesting subsequent releases up to version 14 remain insufficiently patched.
Despite a vendor update in December 2024 that rotated the encryption key, the underlying issue—reliance on static keys—persists.
Security researchers at RedTeam Pentesting demonstrated that even obfuscated .NET assemblies in newer versions still expose decryption keys through reflection.
The encryption process for Windows inventory files uses a fixed AES key (K = “Pys6iB-jY{,&7+c/3uN,1a?~{2wC:L^x”) and initialization vector (IV = “N7IPe~R}w;1vuy5N”).
These values are embedded within the Docusnap.ServerAPI.Model.Tools.CryptoWinImport class.
Attackers can decompile the software or execute reflection-based code to extract the keys, as shown in the proof of concept below:
A Python script leveraging the extracted keys can decrypt inventory files in seconds:
Mitigations
While the decrypted data does not include passwords or cryptographic secrets, it provides attackers with reconnaissance goldmines:
RedTeam Pentesting classifies the risk as low due to the need for prior network access but emphasizes that compromised data accelerates attack chains.
The vendor recommends restricting read access to inventory file shares as a temporary workaround. A permanent fix would require transitioning to asymmetric encryption with per-installation key pairs—a measure not yet implemented.
Docusnap’s parent company, itelio GmbH, asserts that version 14 resolves the issue, but independent verification confirms the persistence of hardcoded keys.
Organizations using Docusnap are urged to audit share permissions and monitor for patches implementing ephemeral or client-specific encryption.
#Cyber_Security #Cyber_Security_News #Vulnerability #Windows #cyber_security #cyber_security_news
Оригинальная версия на сайте:
Docusnap for Windows Vulnerability Let Attackers Access Sensitive Data
Author: KaaviyaA critical information disclosure vulnerability in Docusnap, a widely used IT inventory management solution, allows attackers to decrypt sensitive system data collected from Windows hosts.
Designated as CVE-2025-26849, the flaw stems from the use of a static encryption key to protect inventory files, rendering the encryption effectively useless.
These files, intended to securely catalog installed software, firewall rules, local administrators, and other system details, are accessible to any domain user with read permissions due to insecure default configurations.
Docusnap’s client software for Windows generates encrypted XML inventory files during scheduled scans.
These files are stored on network shares with permissions typically granted to the “Authenticated Users” Active Directory group, which includes read access by default.
Critical Vulnerability in Docusnap
While the files are encrypted using AES-256 in CBC mode, the decryption key is hardcoded into the vendor’s .NET-based server application.
Attackers can extract this static key from the software’s binaries, enabling them to decrypt any inventory file and gain insights into system configurations that could facilitate lateral movement or privilege escalation.
The vulnerability affects Docusnap Client for Windows versions 13.0.1440.24261 and earlier, with evidence suggesting subsequent releases up to version 14 remain insufficiently patched.
Despite a vendor update in December 2024 that rotated the encryption key, the underlying issue—reliance on static keys—persists.
Security researchers at RedTeam Pentesting demonstrated that even obfuscated .NET assemblies in newer versions still expose decryption keys through reflection.
The encryption process for Windows inventory files uses a fixed AES key (K = “Pys6iB-jY{,&7+c/3uN,1a?~{2wC:L^x”) and initialization vector (IV = “N7IPe~R}w;1vuy5N”).
These values are embedded within the Docusnap.ServerAPI.Model.Tools.CryptoWinImport class.
Attackers can decompile the software or execute reflection-based code to extract the keys, as shown in the proof of concept below:
A Python script leveraging the extracted keys can decrypt inventory files in seconds:
Mitigations
While the decrypted data does not include passwords or cryptographic secrets, it provides attackers with reconnaissance goldmines:
- Lists of local administrators (potential privilege escalation targets)
- Installed software (to identify vulnerable applications)
- Firewall rules (to map network attack surfaces)
RedTeam Pentesting classifies the risk as low due to the need for prior network access but emphasizes that compromised data accelerates attack chains.
The vendor recommends restricting read access to inventory file shares as a temporary workaround. A permanent fix would require transitioning to asymmetric encryption with per-installation key pairs—a measure not yet implemented.
Docusnap’s parent company, itelio GmbH, asserts that version 14 resolves the issue, but independent verification confirms the persistence of hardcoded keys.
Organizations using Docusnap are urged to audit share permissions and monitor for patches implementing ephemeral or client-specific encryption.
#Cyber_Security #Cyber_Security_News #Vulnerability #Windows #cyber_security #cyber_security_news
Оригинальная версия на сайте:
