CyberArk Credential File Insufficient Effective Key Space

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-31796

Vulnerability Description

CyberArk Credential Providers and possibly other Vault
components use credential files to store usernames and encrypted
passwords. Under certain conditions, the effective key space
used to encrypt the passwords 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. With partial access, the effective key space can
vary depending on the information available, and a number of
those variations are unlikely to withstand brute force attacks.

Technical Description

The password(s) stored in CyberArk version 2 credential (.cred)
files are protected against inadvertent disclosure through
the use of a proprietary key derivation scheme and Advanced
Encryption Standard (AES) encryption. More specifically, each
password along with some additional information is encrypted
using the AES cipher in Cipher Block Chaining (CBC) mode,
a 256-bit key, and a 128-bit Initialization Vector (IV).

Per online documentation, the encryption key is derived from a
random 160-bit salt and the following environmental information:
Client ID (10 characters), OS user, IP address, and Application
[1].

Based on analysis and observations, the following credential
file fields are involved in the key derivation process:

- ClientApp             (conditionally required)
- AppPath               (conditionally required)
- ClientIP              (conditionally required)
- OSUser                (conditionally required)
- AdditionalInformation (              required)
- ClientHostname        (conditionally required)

where

- ClientApp identifies the allowed application type
- AppPath is a path that points to an allowed system executable
- ClientIP identifies the allowed system IP address
- OSUser identifies the allowed system user
- AdditionalInformation is a 160-bit random salt
- ClientHostname identifies the allowed system hostname

Whether or not the conditionally required fields noted above are
required (i.e., used in the key derivation process) depends on
the value of the VerificationsFlag field, which is implemented
as a bit mask having the undocumented mappings shown in the
table below.

±----------------------±-----------±----+
| Field | Mask Value | Bit |
±----------------------±-----------±----+
| ClientApp | 0x0001 | 0 |
| AppPath | 0x0002 | 1 |
| ClientIP | 0x0004 | 2 |
| OSUser | 0x0008 | 3 |
| AdditionalInformation | 0x0010 | 4 |
| ClientHostname | 0x0020 | 5 |
±----------------------±-----------±----+

For a specific VerificationsFlag value, a given field is
required if its bit is set in the aggregate mask for that
value. For example, an aggregate mask of 17 (0x0011) indicates
that the AdditionalInformation (bit 4) and ClientApp (bit 0)
fields are required since those mask values (i.e., 0x0010 and
0x0001) yield an aggregate mask of 0x0011 when ORed together in
a bitwise operation. Similarly, an aggregate mask of 63 (0x003f)
indicates that all fields in the table above are required.

Below is a table derived from online documentation [1]. It
identifies all currently known application types. For the
purposes of key derivation, this list constitutes the set
of valid choices for the ClientApp field. If the bit for
this field is set in the aggregate mask, the corresponding
value undergoes several transformations prior to being folded
into the key derivation process. First, it 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 ClientAppXForm.

±--------------------------------------------±---------------+
| Application Type | ID |
±--------------------------------------------±---------------+
| Central Policy Manager | CPM |
| Password Vault Web Access | PVWA |
| Password Vault Web Access application user | PVWAApp |
| OPM and Credential Provider | AppPrv |
| Privileged Session Manager application user | PSMApp |
| CyberArk Replicator/Restore/Prebackup | CABACKUP |
| Disaster Recovery Vault | DR |
| Event Notification Engine | ENE |
| PrivateArk Client | WINCLIENT, GUI |
| CyberArk CLI | PACLI |
| CyberArk ActiveX API | XAPI |
| CyberArk .Net API | NAPI |
| Export Vault Data | EVD |
| CyberArk Encryption Utility | CACrypt |
±--------------------------------------------±---------------+

Embedded in the key derivation code are two undocumented,
hard-coded byte sequences (henceforth referred to as Suffix1
and Suffix2).

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 required field values in the following
  order: ClientAppXForm, AppPath, ClientIP, ClientHostname,
  OSUser, and AdditionalInformation
- 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 field values used. The table below
provides a qualified best case estimate for each field value
than can be used.

±----------------------±----------------±-------------------------------------------------------+
| Best Case Estimates |
±----------------------±----------------±-------------------------------------------------------+
| Field | Possible Values | Basis for Estimate |
±----------------------±----------------±-------------------------------------------------------+
| ClientAppXForm | =15 | actual number of documented application types |
| AppPath | <=1000000 | reasonable number of distinct files on a Linux system |
| ClientIP | <=2^24 | confined to a single class A network |
| ClientHostname | <=63^63 | confined to 63 characters drawn from [0-9A-Za-z-] |
| OSUser | <=1000 | reasonable number of distinct users on a Linux system |
| AdditionalInformation | =16^40 | actual size of value |
±----------------------±----------------±-------------------------------------------------------+

If all fields are used, the effective key space would be:

15 * 1000000 * 2^24 * 63^63 * 1000 * 16^40

or approximately 2^595. This is certainly better than 2^256,
but it’s not realistic because additional context will
be available in the typical attack scenario: a credential
file is found/accessed within the system/network for which
it was originally created/deployed. With this scenario, an
attacker will likely be able to significantly narrow the set
of possible values for the AppPath, ClientIP, ClientHostname,
and OSUser fields. The table below provides a more realistic
set of estimates.

±----------------------±----------------±-------------------------------------------------------+
| Realistic Estimates |
±----------------------±----------------±-------------------------------------------------------+
| Field | Possible Values | Basis for Estimate |
±----------------------±----------------±-------------------------------------------------------+
| ClientAppXForm | =15 | actual number of documented application types |
| AppPath | <=256 | limited to CyberArk components actually installed/used |
| ClientIP | <=256 | if no direct lookup, likely to be class C or less |
| ClientHostname | <=256 | if no direct lookup, follow site naming conventions |
| OSUser | <=256 | reasonable number of likely users on a Linux system |
| AdditionalInformation | =1 | value specified in credential file |
±----------------------±----------------±-------------------------------------------------------+

If all fields are used, the effective key space would be:

15 * 256 * 256 * 256 * 256 * 1

or approximately 2^36. Note that the work factor associated
with this key space is well within the reach of even modest
compute power.

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 example
credential file created using the CyberArk “createcredfile”
utility, shown below.

$ createcredfile example_0x003f.cred Password -Username ca_user -Password ca_pass -ExternalAuth no -AppType AppPrv -ExePath /opt/CARKaim/sdk/clipasswordsdk -IPAddress -Hostname -OSUsername os_user -DisplayRestrictions
--- example_0x003f.cred ---
CredFileType=Password
CredFileVersion=2
Username=ca_user
VerificationsFlag=63
Password=A9125EA93F77E5DEABB00FB822169AEAC0E5AC6EEA08FF4F90EC0361E43992B27077B73242916AE401081ACD6842D89A
ExternalAuthentication=no
AdditionalInformation=27653F765AE71F605833AF1A3EC96048477F133F
ClientApp=AppPrv
AppPath=/opt/CARKaim/sdk/clipasswordsdk
ClientIP=192.168.1.6
ClientHostname=krom
OSUser=os_user
--- example_0x003f.cred ---

When SUFFIX1 and SUFFIX2 are assigned the proper values, the
decryption utility provided in the Proof-of-Concept section
below will decrypt example_0x003f.cred as demonstrated here:

$ decrypt-cyberark-credfile.py ${SUFFIX1} ${SUFFIX2} example_0x003f.cred
--- output ---
SUPPLIED_VERIFICATION_FLAGS='0x003f' (63)
REQUIRED_VERIFICATION_FLAGS='0x003f' (63)
TARGET='Password'
  KEY='0E145BE620B42749F077294ED222C6799A2A31C88BB7528C2863AC90D5DE4A52'
  IV='A9125EA93F77E5DEABB00FB822169AEA'
  ACTUAL_PLAINTEXT_HASH='1D2BABAF7564A7291782DBC1258E5E62D8D7CBF8'
  TARGET_PLAINTEXT_HASH='1D2BABAF7564A7291782DBC1258E5E62D8D7CBF8'
  DECRYPTION_STATUS='pass'
  PASSWORD='ca_pass'
--- output ---

Note that it’s not uncommon to encounter credential files
with a VerificationsFlag value of 16 (i.e., 0x0010). This
means that the effective key space is automatically one. The
example below demonstrates that scenario.

$ createcredfile example_0x0010.cred Password -Username ca_user -Password ca_pass
--- example_0x0010.cred ---
CredFileType=Password
CredFileVersion=2
Username=ca_user
VerificationsFlag=16
Password=E948B686F881DE616B2E00672B0ED39982977250CF9AD473A5C445FE240268DBC27E686B40AA5B6D204B14D6CCD56801
ExternalAuthentication=No
AdditionalInformation=6CF3132ECA8BD1A9F550DB18F69176EFCF8823DD
--- example_0x0010.cred ---

$ decrypt-cyberark-credfile.py ${SUFFIX1} ${SUFFIX2} example_0x0010.cred
--- output ---
SUPPLIED_VERIFICATION_FLAGS='0x0010' (16)
REQUIRED_VERIFICATION_FLAGS='0x0010' (16)
TARGET='Password'
  KEY='6BE15C6BFFF6F234E74CE46F8D510F76490778658E9B903D693A92150D64A715'
  IV='E948B686F881DE616B2E00672B0ED399'
  ACTUAL_PLAINTEXT_HASH='1D2BABAF7564A7291782DBC1258E5E62D8D7CBF8'
  TARGET_PLAINTEXT_HASH='1D2BABAF7564A7291782DBC1258E5E62D8D7CBF8'
  DECRYPTION_STATUS='pass'
  PASSWORD='ca_pass'
--- output ---

In cases where security restrictions (i.e.,
‘-DisplayRestrictions’) have been enabled or certain fields
are not represented in a given credential file, the decryption
utility would need to be modified to brute force missing values,
but that is relatively easy to do.

[1] https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASIMP/CreateCredFile-Utility.htm

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 Notes/RN-WhatsNew12-1-CPs.htm?tocpath=Get Started|What’s New|Release Notes|_____4

Credit

This vulnerability was discovered by Klayton Monroe of
KoreLogic, Inc.

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.

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.