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