KL-001-2021-010:CyberArk Credential Provider Local Cache Can Be Decrypted Title: CyberArk Credential Provider Local Cache Can Be Decrypted Advisory ID: KL-001-2021-010 Publication Date: 2021.09.01 Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2021-010.txt 1. Vulnerability Details Affected Vendor: CyberArk Affected Product: Application Access Manager/Credential Provider Affected Version: Prior to 12.1 Platform: Linux/Windows/zOS CWE Classification: CWE-326: Inadequate Encryption Strength CVE ID: CVE-2021-31798 2. Vulnerability Description CyberArk Credential Providers can be configured to retain passwords, password metadata, and other application properties in a local, encrypted cache file. Under certain conditions, the effective key space used to encrypt the cache is significantly reduced. For an attacker who understands the key derivation scheme and encryption mechanics, full access to the information used to derive the encryption key is sufficient to reduce effective key space to one. Even in cases where the information is not known, the encrypted cache files will likely be unable to withstand a brute force attack. However, the severity of this issue is partially mitigated by the privilege level required (root) for access. 3. Technical Description According to available online documentation [1], CyberArk cache files store three types of information: passwords and associated properties, application properties and authentication details, and relationships between applications and passwords. To maintain a high degree of availability, cached information is supplied even when the Vault cannot be accessed (e.g., due to a network outage). When the Vault is accessible, cached information is maintained periodically through a background refresh process, which is controlled by various configuration parameters. For a host system [NAME REDACTED], the following parameters were set in main_appprovider.conf.linux.9.95 under the Cache section: --- main_appprovider.conf.linux.9.95 --- CacheLevel=persistent CacheFile=/var/opt/CARKaim/cache/appprovider_cache.dat CacheRefreshInterval=180 VaultAccessInterval=31536000 --- main_appprovider.conf.linux.9.95 --- Cache files from the host system [NAME REDACTED] (appprovider_cache.dat and configuration_cache.dat) were collected, analyzed, and found to be encrypted on a line-by-line basis using AES in CBC mode with a 256-bit key. On the file system, these files were found to have sufficiently restrictive permissions. More specifically, their user/group ownerships were root/root, and their file permissions only allowed the root user read/write access. This implies that an attacker seeking to read or alter these files must first acquire root-level access. Note, however, that depending on the environment in which a given Credential Provider system operates, there may be other viable attack vectors (e.g., abuse of setuid/setgid executables, accessing the target file system while booted in or mounted from an alternate OS, unprotected backups, etc.). Based on analysis and observations, it was determined that the key material used to derive cache encryption keys are as follows: - application type (AppProvider, AIMAccount, or OPMProvider) - application user (Credential Provider username) - two undocumented, hard-coded byte sequences The application type (dubbed AppType) is transformed prior to being folded into the key derivation process. First, its ID (e.g., AppPrv for AppProvider) is converted to a lowercase string. Next, the lowercase string is hashed using SHA1. Finally, the resultant hash (in binary form) is encoded as a Base64 string. In the sections that follow, this transformed value will be referred to as AppTypeXForm. The application user (dubbed AppUser) is believed to be taken directly from the Username field of the Credential Provider's credential file (appprovideruser.cred). According to available online documentation [2], the username is established during Credential Provider installation, and the default value is "Prov_<servername>". According to RFC 1035 Section 2.3.1 [3]: [The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.] The two undocumented, hard-coded byte sequences noted above (henceforth referred to as Suffix1 and Suffix2) were found embedded in the key derivation code. Given the above, the key derivation process can be summarized as follows: - start a pair of SHA1 hashes (Hash1 and Hash2) - update each hash with AppTypeXForm - update each hash with AppUser - update Hash1 with Suffix1 - update Hash2 with Suffix2 - finalize hashes - construct encryption key using Hash1[0:20] and Hash2[0:12] Unfortunately, the effective key space can be substantially less than the total key space, which is 2^256. This is due to a lack of entropy in the values used. The table below provides a qualified best case estimate for each value that can be used. +-----------------------+-----------------+----------------------------------------------------------------+ | Best Case Estimates | +-----------------------+-----------------+----------------------------------------------------------------+ | Item | Possible Values | Basis for Estimate | +-----------------------+-----------------+----------------------------------------------------------------+ | AppTypeXForm | =3 | actual number of known application types | | AppUser | <=63^63 | "Prov_" plus up to 63 characters drawn from [0-9A-Za-z-] | +-----------------------+-----------------+----------------------------------------------------------------+ This yields an effective key space of: 3 * 63^63 or approximately 2^379. This is certainly better than 2^256, but it's not realistic because additional context will be available in the typical attack scenario: a cache file is found/accessed within the system/network where it was originally populated. With this scenario, an attacker will likely be able to significantly narrow the set of possible values for the AppUser. Note that if the appprovideruser.cred file or any of the application audit/console log files are accessible, this value is easily obtained/confirmed. The table below provides a more realistic set of estimates. +-----------------------+-----------------+----------------------------------------------------------------+ | Realistic Estimates | +-----------------------+-----------------+----------------------------------------------------------------+ | Item | Possible Values | Basis for Estimate | +-----------------------+-----------------+----------------------------------------------------------------+ | AppTypeXForm | =3 | actual number of known application types | | AppUser | <=256 | "Prov_" plus direct lookup or site naming conventions | +-----------------------+-----------------+----------------------------------------------------------------+ This yields an effective key space of: 3 * 256 or approximately 2^10. Note that the work factor associated with this key space is trivial. In the case where an attacker has access to all the information used to derive the encryption key, the effective key space is reduced to one. To illustrate this point, consider the actual cache file shown below. Note that this file was originally decrypted using 'Prov_[REDACTED]' and subsequently re-encrypted using 'Prov_acme' as the value for AppUser. --- configuration_cache.dat --- C8A216AC499542BE21F7CD503CD45B8606A20264847FC2D2601DBB446DCC6022DD0C92D888481B016178C44BA816BF7D 36CE96B752F2524E3E2E85D0EDE2C02DDAABAB7204BF1FE0783B9D6508D768B816647948DD96C030B598C2C8CE64C0D15F599796FD2E7DBE705CB13AD0FA30DAC44EE7D96329FD90826E834E66836EE5CD543B0523E3FD7AF9EAD811BC271AC6A78A11591B4870143814BBA05DCF5B01 01CDBDF5470A03A213CA182CAAA071363F7E4A0463BDFA034651E1713FC546E599E5641A7C83B8C56B327DA3B5885C9E9E224A001BE5E0EA00F6CF436F205195D5D64E3FFBA8001829F61AB61D7FCE10 --- configuration_cache.dat --- When SUFFIX1 and SUFFIX2 are assigned the proper values, the decryption utility provided in the Proof-of-Concept section below will decrypt configuration_cache.dat as demonstrated here: $ decrypt-cyberark-cache.py appprv Prov_acme ${SUFFIX1} ${SUFFIX2} configuration_cache.dat --- output --- KEY='0066B3EEC3A5BBF53FC22F92F566A26AB7777E2AA25DA169B7A5148D9985803F'; LINE='1'; STATUS='pass'; ACTUAL_HASH='DD081E18FC027B73E6513959A6457DD8E6226848'; TARGET_HASH='DD081E18FC027B73E6513959A6457DD8E6226848'; LINE='1'; RECORD='1'; ITEM='1'; VALUE='1'; LINE='1'; RECORD='2'; ITEM='1'; VALUE='8'; LINE='2'; STATUS='pass'; ACTUAL_HASH='E13994FC37A8528B8C55B65CD36F56DD4A9FE212'; TARGET_HASH='E13994FC37A8528B8C55B65CD36F56DD4A9FE212'; LINE='2'; RECORD='1'; ITEM='1'; VALUE='0'; LINE='2'; RECORD='2'; ITEM='1'; VALUE='12'; LINE='2'; RECORD='3'; ITEM='1'; VALUE='LastUpdate=0'; LINE='2'; RECORD='3'; ITEM='2'; VALUE='vars=InstalledProvidersOnVault=366|ProviderUserType=33|'; LINE='2'; RECORD='4'; ITEM='1'; VALUE=''; LINE='3'; STATUS='pass'; ACTUAL_HASH='1114122803D02CC642788B048ED91ED0352CCA8B'; TARGET_HASH='1114122803D02CC642788B048ED91ED0352CCA8B'; LINE='3'; RECORD='1'; ITEM='1'; VALUE='F1E723C8285DD3EADC3004A668062BD2EA03CD4A'; FILE_HASH='F1E723C8285DD3EADC3004A668062BD2EA03CD4A'; --- output --- It should be noted that the decryption utility is equally effective on appprovider_cache.dat, which is where the majority of sensitive information (i.e., passwords, password metadata, and other application properties) is stored. In practice, attackers will likely target that file exclusively. [1] https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-CP/Latest/en/Content/CP%20and%20ASCP/configuring-caching.htm [2] https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-CP/Latest/en/Content/CP%20and%20ASCP/installing-the-Credential-Provider.htm [3] https://tools.ietf.org/html/rfc1035 4. Mitigation and Remediation Recommendation The vendor has released an updated version (v12.1) which remediates the described vulnerability. Release notes are available at: https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/Release%20Notes/RN-WhatsNew12-1-CPs.htm?tocpath=Get%20Started%7CWhat%E2%80%99s%20New%7CRelease%20Notes%7C_____4 5. Credit This vulnerability was discovered by Klayton Monroe of KoreLogic, Inc. 6. Disclosure Timeline 2020.11.04 - KoreLogic submits vulnerability details to CyberArk. 2020.11.05 - CyberArk acknowledges receipt and the intention to investigate. 2020.11.16 - KoreLogic and CyberArk meet to discuss the details of this and other reported vulnerabilities. Both parties agree that the remediation timeline will extend significantly longer than the standard 45 business days specified in the KoreLogic Public Disclosure Policy. 2021.01.14 - 45 business days have elapsed since the vulnerability was reported to CyberArk. 2021.01.21 - KoreLogic and CyberArk meet to discuss proposed remediation efforts for this and other reported vulnerabilities. 2021.03.24 - 90 business days have elapsed since the vulnerability was reported to CyberArk. 2021.04.22 - CyberArk notifies KoreLogic that the reported vulnerability will be mitigated in a version scheduled for release in late May, 2021. 2021.05.10 - 120 business days have elapsed since the vulnerability was reported to CyberArk. 2021.05.10 - CyberArk provides KoreLogic with the CVE for this vulnerability. Vendor requests KoreLogic delay public disclosure until the end of June, 2021. 2021.06.08 - KoreLogic and CyberArk meet to discuss the details of the product release and revisit timeline for public disclosure. CyberArk informs KoreLogic that the Linux/Windows version of the Credential Provider will be released at the end of June, 2021. A Credential Provider for the zOS platform will be released at the end of July, 2021. KoreLogic agrees to delay public disclosure of this and other reported vulnerabilities until 2021.08.15. 2021.06.23 - CyberArk releases Credential Provider v12.1 for Linux/Windows platforms. 2021.08.05 - 180 business days have elapsed since the vulnerability was reported to CyberArk. 2021.08.10 - CyberArk informs KoreLogic that the zOS Credential Provider update has been released to their customers. Requests that KoreLogic forgo publication of the Proof of Concept code as an unforseen issue prevents some customers from updating in the near term. 2021.08.27 - KoreLogic suggests delaying the release of the Proof of Concept until a to-be-determined future date. 2021.08.30 - CyberArk tenders 2022.01.01 release date for the Proof of Concept. 2021.09.01 - KoreLogic public disclosure. 7. Proof of Concept At the vendor's request, KoreLogic has agreed to delay publication of the Proof of Concept while customers continue to deploy the updated versions of the product. The contents of this advisory are copyright(c) 2021 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v2.3.txt