Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
CACredDecoder — #CVE-2021-31796용 C-Ark 자격 증명 디코더 | Kitploit
도구/GitHubGitHub/unmanarc/cacreddecoder
Password CrackingEncryption/Decryption ToolsVulnerability AnalysisExploitationCryptographyPenetration Testing
GitHubunmanarc/cacreddecoder

CACredDecoder

#CVE-2021-31796용 C-Ark 자격 증명 디코더

저장소 보기
114년 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유

C-Ark Credential Decoder

Exploit tool for CVE-2021-31796
C-Ark 자격 증명 파일 디코딩 도구

제작: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
최초 릴리스: 2/Sep/2019
공개: 11/Oct/2021

참고 자료

  • https://packetstormsecurity.com/files/164023/CyberArk-Credential-File-Insufficient-Effective-Key-Space.html
  • https://vuldb.com/?id.181904

책임 있는 공개:

이 취약점은 2019년 9월부터 공개가 보류되어 있었습니다.

그리고... 타임라인은 다음과 같습니다:

  • 2019-08-1x 어떤 훈련 중에, 우리 팀은 사용된 일부 자격 증명 저장 방식에서 잠재적인 암호화 취약점을 발견하고 현지 공급업체 담당자에게 보고했습니다.
  • 2019-08-30 이 날짜까지 우리는 그들의 도구를 사용한 "ollydbg" 인메모리 개념 증명만 보유하고 있었습니다. 우리는 이것이 특정 상황에서 어떻게 공격 벡터가 될 수 있는지에 대한 요점을 전달하려 했지만, 전달하지 못했습니다. 그래서 우리는 더 명확한 논거를 위해 이 개념 증명 코딩을 시작하기로 결정했습니다.
  • 2019-09-02 우리는 자체 개념 증명에서 해싱과 암호화 알고리즘을 성공적으로 구현했습니다 (제품과 완전히 무관하게).
  • 2019-09-03 우리는 발견 사항과 이를 공개적으로 제공하려는 관심을 공급업체에 알렸습니다.
  • 2019-09-20 우리는 문제가 수정될 때까지 공개 릴리스를 연기해 달라는 공급업체의 요청을 받았습니다.
  • 2020-05 우리는 도구 릴리스 허가를 받기 위해 그들에게 다시 연락했고, 그들이 준비되지 않았다는 내용의 이메일 몇 통을 주고받았습니다.
  • 2021-09/2021-10 우리는 무관한 다른 연구자들도 최근에 동일한 취약점을 발견하여 공개적으로 공개했다는 것을 알게 되었고, 이러한 상황이 있어서... 우리는 마침내 (2년 만에!) 공급업체로부터 CreateCredFile 암호화 취약점을 악용하는 발견 사항과 개념 증명 도구를 여러분과 공유할 수 있는 허가를 받았습니다.

잠재적 사용:

침투 테스트 중에, 누군가가 영리하게 PSM에 도달하고 우연히 CredFile에 접근하게 된다면, 그 파일을 사용하여 Vault에 연결하고 전체 제어권을 얻을 수 있습니다...

대응책으로, 대부분의 자격 증명 파일은 암호가 다른 환경/컴퓨터(예: 해커 자신의 PSM)에서 사용되는 것을 방지하기 위해 몇 가지 "제한"을 둡니다.

하지만, 그러한 제한은 리버스 엔지니어링하여 원시 키 부분을 얻는다면 수정될 수 있습니다. 이 복호화된 키 부분은 다른 "보안" 매개변수(예: 다른 호스트, 다른 애플리케이션, 다른 OS 사용자)로 다른 파일을 다시 생성하는 데 사용될 수 있습니다.

동작 방식

AES-256(32바이트) 원시 복호화 키를 생성하기 위해, "AdditionalInformation" 자격 증명 필드에서 각 해시에 "0x00000000" 및 "0x00000001"을 추가하여 한 쌍의 SHA1SUM을 만듭니다. 첫 번째 해시는 키의 처음 20바이트를 제공하고, 두 번째 해시는 마지막 12바이트만 제공합니다.

환경 제한(IP/Host/exepath/... 등)이 있는 경우, 두 SHA1SUM을 계산하기 전에 각 평문 값을 AdditionalInformation 앞에 추가합니다.

중요한 점은 "ClientApp" 필드는 "AdditionalInformation" 앞에 추가되고 두 SHA1SUM이 생성되기 전에 BASE64(SHA1SUM(strlower(ClientApp)))로 변환된다는 것입니다.

복호화는 Password 또는 NewPassword 필드를 사용하여 AES-256-CBC OpenSSL 함수로 수행됩니다. (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

어떤 검증/제한이 적용되는지 파악하기 위해 (verificationflags-16)을 사용합니다:

root@kitploit:~
usingClientApp      = ((uVerificationsFlag&0x1) != 0);
usingAppPath        = ((uVerificationsFlag&0x2) != 0);
usingClientIP       = ((uVerificationsFlag&0x4) != 0);
usingOSUser         = ((uVerificationsFlag&0x8) != 0);
usingClientHostname = ((uVerificationsFlag&0x20) != 0);

그리고 일부 제한이 출력 자격 증명 파일에 표시되지 않는 경우, 항상 수동으로 추가할 수 있습니다. "앱 경로"나 "클라이언트 IP" 모두 진정한 임의 값이 아니라는 점에는 우리 모두 동의할 것이라고 생각합니다.

완화 방안:

HSM을 사용하세요 \o/, 복호화 키를 자격 증명 파일에 저장하지 마세요.

빌드 방법:

root@kitploit:~
qmake . 
make -j8
도구 다운로드