CVE-2020-5248 in GLPI
Summary
by MITRE
GLPI before before version 9.4.6 has a vulnerability involving a default encryption key. GLPIKEY is public and is used on every instance. This means anyone can decrypt sensitive data stored using this key. It is possible to change the key before installing GLPI. But on existing instances, data must be reencrypted with the new key. Problem is we can not know which columns or rows in the database are using that; espcially from plugins. Changing the key without updating data would lend in bad password sent from glpi; but storing them again from the UI will work.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2020
The vulnerability described in CVE-2020-5248 represents a critical cryptographic weakness in GLPI versions prior to 9.4.6, where a default encryption key known as GLPIKEY is publicly exposed and utilized across all instances. This flaw falls under the category of weak cryptographic key management as classified by CWE-326, specifically addressing inadequate key protection mechanisms. The default encryption key serves as a fundamental security control failure, creating a scenario where any attacker with access to the system can decrypt sensitive information stored within the GLPI database. This vulnerability directly impacts the confidentiality aspect of the CIA triad, as it allows unauthorized decryption of data that should remain protected.
The technical implementation of this vulnerability stems from the hardcoded nature of the encryption key, which is embedded within the application code and accessible to all users with sufficient privileges to examine the system configuration. The default key is used consistently across all GLPI installations, making it a universal target for attackers who can leverage this knowledge to gain access to encrypted data. The issue extends beyond core functionality to include plugin components, where the encryption key may be used in unknown columns or database tables, creating an additional layer of complexity for administrators trying to identify and remediate affected data. This situation creates a scenario where the encryption mechanism becomes ineffective, essentially providing no real security benefit to the encrypted data.
Operational impact of this vulnerability is significant, as it allows attackers to access sensitive user credentials, personal information, and other confidential data that should remain protected. The vulnerability particularly affects authentication data, where passwords and other credentials are stored in encrypted form but can be decrypted using the known default key. When administrators attempt to change the encryption key on existing installations, they face the challenge of identifying which database records have been encrypted using the old key, especially in plugin modules where encryption usage patterns are not well documented. This creates a risk of data corruption or loss of functionality if the key is changed without proper data migration, potentially leading to service disruption when GLPI attempts to access previously encrypted data that cannot be properly decrypted with the new key.
Mitigation strategies for this vulnerability require immediate attention from system administrators, including the implementation of proper encryption key rotation procedures before upgrading to GLPI 9.4.6 or later versions. Organizations should first identify and backup all encrypted data within their GLPI instances, then implement a process to re-encrypt existing data using the new encryption key before changing the key configuration. The recommended approach involves creating a systematic method to track which database columns and tables contain encrypted data, particularly focusing on plugin-specific encryption usage patterns. Additionally, security best practices dictate that encryption keys should never be hardcoded within applications and should instead be dynamically generated and securely stored using established key management protocols. This vulnerability highlights the importance of following ATT&CK framework principle T1552.004 for credential access and T1552 for data encryption, emphasizing the need for proper key management and the avoidance of default cryptographic parameters that can be easily discovered and exploited by attackers.