| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 1 Sep 2021 13:20:46 -0500
From: KoreLogic Disclosures via Fulldisclosure <fulldisclosure@...lists.org>
To: fulldisclosure@...lists.org
Subject: [FD] KL-001-2021-008: CyberArk Credential File Insufficient
Effective Key Space
KL-001-2021-008: CyberArk Credential File Insufficient Effective Key Space
Title: CyberArk Credential File Insufficient Effective Key Space
Advisory ID: KL-001-2021-008
Publication Date: 2021.09.01
Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2021-008.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-31796
2. 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.
3. 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
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists