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. Versions prior to 12.1 are affected.
584fe77e2ea6857a7616d3364bb329f1KL-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