개요
The Silverfort 연구팀은 Anthropic이 macOS에 Claude Code CLI 자격 증명을 저장하는 방식 때문에 사용자의 권한으로 실행되는 모든 프로세스가 사용자의 Anthropic 계정 자격 증명을 쉽게 탈취할 수 있으며, 더 나아가 연결된 MCP 서버 자격 증명까지 탈취할 수 있다는 사실을 발견했습니다. 공격자는 단 한 번의 무음 읽기만으로 전체 자격 증명 묶음을 가져올 수 있으며, 이를 다른 컴퓨터에서 실행하여 사용자 행세를 할 수 있습니다.
macOS 키체인은 사용자가 암호 또는 생체 인증을 다시 입력해야만 요청하는 프로세스에 비밀 정보를 제공하는 안전한 저장 메커니즘을 갖추고 있습니다. Claude Desktop은 이 기능을 올바르게 사용합니다. 다른 프로세스가 저장된 자격 증명에 접근하려고 하면 macOS는 사용자에게 재인증을 요청합니다. 하지만 Claude Code CLI는 그렇지 않습니다. 사용자 모드 프로세스라면 어떤 프로세스든 재인증 요청 없이 자격 증명을 가져올 수 있도록 구현되어 있으며, 이 부분에 대해서는 이 블로그 글에서 자세히 설명하겠습니다.
엄밀히 말하면 이는 취약점이 아니라 구현 설계 결함, 즉 보안 약점입니다. 재인증이 필요한 자격 증명에 대해 재인증이 필요하지 않습니다. 이를 악용하는 데는 일반적인 "사용자 권한으로 코드 실행" 이상의 정교한 기술이 필요하지 않으며, 권한 상승보다 훨씬 쉽습니다. 이 설계 결함은 Claude Code CLI를 실행하는 모든 macOS 사용자에게 영향을 미칩니다(데스크톱 및 Windows/Linux CLI 사용자는 제외됩니다. 이들은 파일 기반 저장소를 사용하므로 기존 AV/EDR 휴리스틱이 이미 변조를 감지하기 때문입니다).
결론적으로, 악성 코드가 사용자 계정으로 실행 중인 경우, 권한 상승이나 암호 입력 프롬프트, 경고 없이 Claude Code 자격 증명을 조용히 읽어 MCP 서버에 접근하는 등 네트워크 전반으로 이동할 수 있습니다. macOS에서는 파일 기반 저장소보다 키체인이 더 나은 방법이지만, Claude Code CLI가 재인증 단계를 건너뛰기 때문에 이러한 장점이 사라지고, 다른 플랫폼에서 파일 접근을 감지하는 휴리스틱처럼 이를 감시하는 기존 안티바이러스 휴리스틱도 없습니다. 엔드포인트가 탈취되면 공격자는 사용자의 Anthropic 계정과 연결된 모든 MCP 서버에 접근하여 해당 서버가 관리하는 모든 항목, GitHub의 회사 코드베이스, Atlassian의 기술 자료 또는 기타 중요한 MCP 커넥터에 영향을 미칠 수 있습니다.
Silverfort HackerOne은 책임 있는 정보 공개 절차에 따라 6월 25일 Anthropic에 이 사실을 보고했습니다. Anthropic은 즉시 답변했고, 팀과 논의한 결과 키체인 아이템의 접근 제어 강화 조치를 보안 강화의 일환으로 추적 중이며, 이는 "심층 방어 차원에서 가치 있는 변화"라고 생각한다고 확인했습니다. Anthropic은 이에 대해 이의를 제기하지 않았습니다. Silverfort 연구 결과를 발표하는 것.
수비수들을 위한 지침
이 문제가 해결될 때까지 macOS에서 Claude Code CLI를 실행하는 조직은 서로 다른 컴퓨터에서 동일한 토큰이 사용될 때마다 경고를 생성해야 합니다. 기존의 탐지 및 대응 방식을 넘어, 조직은 고정 또는 임시 자격 증명 사용을 제어하고, 동일한 토큰이 두 대의 서로 다른 컴퓨터에서 사용될 경우 이를 알려주는 ID 보안 플랫폼을 고려해야 합니다. 이는 자격 증명 도용의 강력한 지표입니다. 보안팀은 Claude Code CLI에서 사용하는 키체인 항목에 대한 비정상적이거나 예상치 못한 프로세스 접근을 모니터링해야 합니다. 이러한 자격 증명 저장소에 대한 비정상적인 접근 패턴은 잠재적 침해의 중요한 지표이므로 조사 대상으로 삼아야 합니다.
배경
이제 AI 코딩 에이전트는 실제 자격 증명을 보유합니다. 작업을 수행하기 위해 로그인하고 시스템에 토큰을 저장합니다. 클로드 코드 CLI Claude도 예외는 아닙니다. Claude를 실행하면 OAuth 번들로 로그인하는데, 여기에는 단기 액세스 토큰과 장기 갱신 토큰이 포함됩니다. 여기서 주의해야 할 부분은 갱신 토큰입니다. 갱신 토큰은 누군가가 취소할 때까지 새로운 액세스 토큰으로 교환될 수 있으므로 임시 세션이 아닙니다. 노트북에 영구적으로 저장된 계정 액세스 권한입니다.
OAuth 번들 파일이 저장되는 위치는 운영체제에 따라 다릅니다. 세 가지 플랫폼 중 두 가지(리눅스와 윈도우)에서는 디스크의 일반 파일에 저장됩니다. macOS에서는 OS 키체인에 저장되는데, 이는 직관적인 방식이지만 한 가지 문제가 있습니다. 기본적으로 해당 항목은 생성한 프로그램에 잠겨 있는데, 이는 보안상 어떤 프로세스든 실행할 수 있는 도구라는 점을 간과하는 것입니다. 따라서 잠금 표시가 있지만 실제로는 잠기지 않으며, 사용자 계정으로 실행되는 모든 프로세스는 사용자에게 암호를 입력하라는 추가 메시지 없이 토큰을 가져올 수 있습니다.
우리는 세 가지 플랫폼 모두에서 Claude Code CLI 자격 증명을 추적하고, macOS 결함을 자세히 살펴보고, 도난당한 번들을 재사용하는 간단한 방법을 다룬 다음, 모든 기업이 던질 질문인 "새로운 기능은 과연 제대로 작동하지 않을까요?"에 대한 답변으로 마무리할 것입니다. 클로드 앱 게이트웨이 이것을 무의미하게 만들 수 있을까요? 간단히 말하면, 아닙니다.
파일 속의 비밀은 듣기에는 끔찍하지만, 직접 확인할 수 있는 비밀이기도 합니다.
Linux와 Windows에서는 자격 증명이 운영체제 키 저장소를 거치지 않고 일반 텍스트 JSON 파일에 저장됩니다. 언뜻 보기에는 보안에 취약해 보이지만, 디스크에 자격 증명 파일을 저장하는 것은 보안 담당자들이 이미 대처 방법을 알고 있는 문제입니다. 이는 전형적인 공격 대상이며, 안티바이러스나 EDR과 같은 엔드포인트 보안 도구는 토큰이 저장된 파일에 접근하는 프로세스를 감시할 수 있습니다. 즉, 제어 장치를 설치할 위치와 경고를 발생시킬 구체적인 기준이 있는 것입니다. 하지만 macOS에서는 이러한 안전장치가 사라진다는 것을 곧 살펴보겠습니다.
Claude Code CLI 설명서에는 해당 파일의 위치가 나와 있습니다.
"리눅스에서 자격 증명은 다음 위치에 저장됩니다."
~/.claude/.credentials.json파일 모드 0600으로."Windows에서는 자격 증명이 다음 위치에 저장됩니다.
%USERPROFILE%\.claude\.credentials.json또한 사용자 프로필 디렉터리의 액세스 제어를 상속받으므로 기본적으로 해당 파일에 대한 액세스가 사용자 계정으로 제한됩니다.
한 가지 문제점: CLAUDE_CONFIG_DIR 이 파일은 다른 위치로 이동되므로, 실제 경로를 하드코딩하는 탐지 규칙은 해당 설치를 감지하지 못하게 됩니다.
해당 파일 안에는 중요한 모든 정보가 담겨 있습니다. OAuth 액세스 토큰(sk-ant-oat…), 장기 갱신 토큰(sk-ant-ort…), 만료 시간 타임스탬프, 그리고 토큰 스코프가 여기에 포함됩니다. 또한 연결된 MCP 서버 OAuth 토큰과 플러그인 비밀 키도 같은 저장소에 저장됩니다. 여기서 가장 중요한 것은 갱신 토큰입니다. 이 토큰을 한 번만 읽으면 영구적인 계정 접근 권한을 얻을 수 있기 때문입니다. Linux와 Windows 환경에서 주의해야 할 사항은 다음과 같습니다.
- 파일 무결성 모니터링. 처리
~/.claude/.credentials.json(그리고CLAUDE_CONFIG_DIR(변형)을 민감한 객체로 취급합니다. 원하는 알림은 claude 바이너리가 아닌 다른 프로세스에 의한 읽기 또는 열기 작업입니다. Linux에서는 auditd 감시를 사용하여 이를 수행할 수 있습니다.auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_creds) 또는 eBPF 개방형 원격 측정 기능을 사용하십시오. Windows에서는 SACL을 사용한 객체 액세스 감사(이벤트 ID 4663) 또는 EDR 파일 읽기 원격 측정 기능을 사용하십시오. - 권한 변동. Linux 파일은 다음 위치에 유지되어야 합니다.
0600만약 해당 내용이 그룹이나 전 세계에서 읽을 수 있는 형태로 바뀐다면, 그 자체로 경고 신호입니다. - 콘텐츠 서명. sk-ant-oat(액세스) 및 sk-ant-ort(새로 고지) 접두사를 DLP 및 AV의 자격 증명 표시자로 취급하십시오. 구성 디렉터리 외부의 파일, 아카이브, 클립보드 및 아웃바운드 트래픽에서 이러한 접두사를 표시하십시오. 새로 고침 토큰 접두사와의 일치는 가장 심각한 위협입니다.
- 신원 확인이 중요합니다. 가장 확실한 신호는 엔드포인트에서 나오는 것이 아닙니다. 한 호스트에서 처음 나타난 토큰이 다른 호스트에서 다시 나타나는 것은 전형적인 도용 징후입니다. 로컬에서 읽은 직후 동일한 OAuth 세션이 새로운 장치, 위치 또는 IP 주소에서 다시 나타나는지 주의 깊게 살펴보세요. 이러한 호스트 간 재사용을 감지하는 것이 바로 신원 위협 탐지 플랫폼의 목적입니다.
관련 파일을 보관하십시오. ~/.claude.json, 당신의 레이더망에도 포착될 겁니다. 비밀 저장소는 아니지만, 계정 정보를 보관하고 있습니다.oauthAccount,userID이는 워크숍의 나머지 절반을 차지합니다. 이에 대해서는 다음 섹션에서 자세히 설명하겠습니다.
잠기지 않는 자물쇠: macOS의 키체인은 좋은 아이디어이지만, 제대로 구현되어야 합니다.
macOS는 CLI가 자격 증명을 디렉터리가 아닌 키체인에 저장함으로써 이러한 패턴을 깨뜨립니다. .credentials.json 파일입니다. 문서에는 명확하게 설명되어 있습니다.
macOS에서는 자격 증명이 암호화된 macOS 키체인에 저장됩니다.
이는 올바른 직감입니다. 암호화되고 운영체제로 보호되는 저장소는 일반 파일보다 항상 안전합니다. 하지만 키체인 항목의 보안은 해당 항목에 연결된 접근 제어 목록(ACL)만큼만 강력한데, 바로 이 부분에서 이 특정 항목의 보안성이 무너집니다.
Claude Code CLI는 다음 명령을 실행하여 키체인 항목을 생성합니다. /usr/bin/security add-generic-password또한 접근 제어 인수를 전달하지 않습니다. 특정 애플리케이션을 신뢰하기 위한 -T도, 모든 애플리케이션을 허용하기 위한 -A도 없습니다. 따라서 이 항목은 키체인 기본 접근 제어 목록(ACL)을 상속합니다. macOS security(1) man 페이지에는 이 기본값이 무엇을 하는지 자세히 설명되어 있습니다.
기본적으로 항목을 생성하는 애플리케이션은 경고 없이 해당 데이터에 접근할 수 있도록 신뢰됩니다. 명시적으로 빈 애플리케이션 경로를 지정하여 이 기본 접근 권한을 제거할 수 있습니다. -T ""."
이 코드 경로에서 항목을 생성하는 애플리케이션은 다음과 같습니다. /usr/bin/security 그 자체입니다. 따라서 해당 항목에 기록된 신뢰할 수 있는 판독기는 다음과 같습니다. /usr/bin/security앉아 있는 apple-toolmacOS가 Apple 자체 서명 도구를 위해 예약해 둔 파티션입니다. 이 기본 설정이 바로 문제의 핵심입니다. /usr/bin/security 는 Apple에서 서명한 범용 명령줄 도구이며, 사용자 계정으로 실행되는 모든 프로세스는 특별한 권한 없이 이를 호출할 수 있습니다. 유일하게 신뢰할 수 있는 읽기 권한이 있는 프로세스만 있는 ACL은 다음과 같습니다. security 해당 도구는 실행되는 모든 프로세스에 의해 만족됩니다. security 도구, 즉 머신의 모든 프로세스를 의미합니다. ACL은 어떤 프로그램이 비밀 키를 읽을 수 있는지를 제어하기 위한 것이지만, 실제로는 아무런 제어도 하지 못합니다. 어떤 프로그램이든 표준 바이너리 프로세스에 읽기를 요청하면 비밀 키를 읽을 수 있기 때문입니다.
그 결과는 한 줄짜리, 소리 없는 읽기입니다:
security find-generic-password -s "Claude Code-credentials" -a "$USER" -w
Touch ID도 없고, 로그인/비밀번호 입력 프롬프트도 없고, 권한 상승도 없습니다. 액세스 토큰, 장기 갱신 토큰, 그리고 해당 항목을 공유하는 모든 MCP 또는 플러그인 비밀 키를 포함한 전체 자격 증명 JSON이 반환됩니다.
Anthropic은 이미 Claude Desktop에서 이 기능을 제대로 구현하고 있는데, Claude Code CLI에서는 왜 안 될까요?
이것이 macOS의 제한 사항이 아니라 구현상의 선택이라는 가장 명확한 증거는 Anthropic이 Claude Desktop에서 이미 이를 올바르게 처리하고 있다는 점입니다. Claude Desktop은 동일한 운영 체제에서 동일한 사용자 계정으로 실행되며 동일한 종류의 비밀 정보를 보호합니다. Claude Desktop은 Electron의 safeStorage를 사용하여 이를 구현하는데, 그 설계 방식은 CLI와는 다르므로 자세히 설명할 필요가 있습니다. safeStorage 암호화 키는 키체인에 보관하고 실제 토큰은 암호문 형태로 디스크의 파일에 저장합니다. Electron 문서에는 해당 키가 어떻게 보호되는지 설명되어 있습니다.
"암호화 키는 다른 애플리케이션이 사용자가 직접 수정하지 않는 한 로드할 수 없도록 키체인 접근에 저장됩니다."
해당 키를 저장하는 키체인 항목의 ACL에는 서명된 Claude 앱만 나열되어 있으며, 해당 파티션은 Anthropic의 개발자 팀에 고정되어 있으므로 보안상 어떤 곳에서든 읽기가 불가능합니다. 그렇지 않으면 로그인 비밀번호를 입력하라는 메시지가 표시됩니다.디스크에 저장된 암호문은 키 없이는 쓸모가 없으며, 키를 얻으려면 해당 프롬프트가 필요합니다.
두 디자인은 비슷해 보이지만 동작 방식은 매우 다릅니다. CLI는 토큰을 키체인에 저장하고, 모든 프로세스가 읽을 수 있도록 ACL을 적용합니다. 반면 Claude Desktop은 키체인에 키만 저장하고, 해당 키를 자체 서명에 연결하며, 암호화된 토큰은 그 자체로는 쓸모없는 파일에 저장합니다. 동일한 운영 체제, 동일한 사용자, 동일한 유형의 비밀 키를 사용하더라도, 하나는 모든 프로세스가 안전하게 읽을 수 있는 반면 다른 하나는 사용자 승인이 필요합니다. 차이점은 키체인 항목이 생성되는 방식과 보호하는 내용에 있습니다.
근본 원인 : CLI는 항목 생성을 담당합니다. /usr/bin/security 클로드 데스크톱에서 이미 제공하는 방식처럼, 네이티브 키체인 서비스 API를 사용하여 항목을 클로드 바이너리 자체의 코드 서명에 바인딩하는 대신 다른 방법을 사용합니다. 보안 도구는 항목을 호출한 프로그램에 바인딩할 수 없습니다. 네이티브 API만 가능합니다. 취약점 측면에서 보면 이는 CWE-732(중요 리소스에 대한 잘못된 권한 할당) 및 CWE-522(불충분하게 보호된 자격 증명)에 해당합니다.
설정 파일을 하나도 건드리지 않고 세션을 다시 구축합니다.
토큰을 읽는 것은 가장의 절반에 불과합니다. 피해자 역할을 하려면 Claude Code CLI는 누가 로그인했는지도 알아야 하는데, 이는 일반적으로 다음 위치에 있습니다. oauthAccount 블록 내부 ~/.claude.json가장 очевид한 행동은 해당 파일까지 훔치는 것이지만, 훨씬 흔적을 덜 남기는 깔끔한 방법이 있습니다. 이 방법을 살펴볼 가치가 있는 이유는, 이 방법이 효과가 있는 것처럼 보이는 이유가 틀렸기 때문입니다.
공격자의 컴퓨터에 저장된 레시피는 다음과 같습니다.
1. 탈취한 액세스 토큰을 내보내고 Claude를 한 번 실행합니다.
export ANTHROPIC_API_KEY=<access-token>
claude
2. 종료한 다음 unset ANTHROPIC_API_KEY.
3. 훔친 물건 묶음 전체를 당신의 열쇠고리에 넣어 두세요.
security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'
4. 실행 claude 다시 로그인했습니다. 이제 피해자 계정으로 로그인되었습니다.
여기서 예상치 못한 부분이 나옵니다. 환경 변수는 로그인에 사용되는 것이 아닙니다. 도난당한 sk-ant-oat… Claude Code CLI 인증 우선순위 문서에 따르면 ANTHROPIC_API_KEY에 입력된 값은 X-Api-Key 헤더로 전송됩니다. 이는 잘못된 헤더이며, 토큰 종류 또한 잘못되었습니다. OAuth 액세스 토큰은 콘솔 API 키가 아니기 때문입니다. 따라서 모델 호출을 인증하는 데 전혀 사용되지 않습니다.
그렇다면 내보내기는 무엇을 위한 것일까요? 핵심은 작업 순서입니다. 탈취한 액세스 토큰을 내보내는 첫 번째 실행 단계는 피해자의 계정 ID를 ~/.claude.json 파일에 기록하는 단계이므로 공격자는 해당 파일을 복사할 필요가 없습니다. 그런 다음 변수를 해제하고 새로 고침 토큰을 포함한 전체 패키지를 키체인에 심습니다. 문서에 설명되어 있습니다. unset ANTHROPIC_API_KEY 이는 "구독으로 되돌아가는" 방법으로, 최종 실행에서는 정확히 그렇게 작동합니다. 즉, 키체인 번들을 구독 자격 증명으로 사용하여 인증하고, 이 자격 증명의 수명이 긴 새로 고침 토큰은 지속적으로 새로운 액세스 토큰을 생성합니다. 이 자격 증명은 목록에서 우선순위가 가장 낮지만 가장 내구성이 뛰어납니다.
왜 방어자들이 이 방법을 주목해야 할까요? 이 방법의 핵심은 흔적을 최소화하는 것이기 때문입니다. 키체인에서 한 번 조용히 읽는 행위는 여러 파일을 한꺼번에 가져오는 것과 같은 효과를 내며, 소스 시스템에 복사되는 파일 수가 적을수록 유출 탐지에 도움이 되는 단서가 줄어듭니다. macOS에서는 파일 자체가 없기 때문에 파일 이벤트를 기다릴 필요조차 없습니다. 읽기 작업은 프로세스 내부에서 이루어지므로, 감시해야 할 대상은 바로 그 프로세스입니다.
전체 과정, 시작부터 끝까지
두 부분을 합치면 공격은 간단해집니다. 피해자 측에서는 모든 작업이 일반 사용자 권한으로 실행되며, 프롬프트나 권한 요청이 없습니다. 공격자 측에서는 단순히 실행 결과를 그대로 따라 하면 됩니다.
다음은 개념 증명 차원에서 처음부터 끝까지 실행되는 동일한 흐름입니다.
클로드 앱 게이트웨이가 이 문제를 해결해 주지 않을까요?
간단히 답하자면, 아니요. 저희는 게이트웨이를 설치하고 자체 클로드 코드(Claude Code)를 연결한 후, 똑같은 방식으로 데이터 유출 시도를 해봤습니다. 그런데도 여전히 작동했습니다.
게이트웨이가 무엇인지 정확히 정의하는 것이 중요합니다. 이름에서 암시하는 것보다 범위가 좁기 때문입니다. 게이트웨이는 일반적인 Claude 설정에 추가되는 보안 계층이 아닙니다. 오히려 조직에서 실행하거나 선택한 특정 모델 엔드포인트(Anthropic의 기본 경로가 아닌 온프레미스, Microsoft Foundry, Amazon Bedrock, Google Cloud 또는 자체 Anthropic 엔드포인트 등)로 Claude Code를 연결하는 라우팅 도구입니다. 게이트웨이를 사용하는 이유는 데이터 상주 및 규정 준수 규칙, 선호하는 클라우드 공급업체 또는 로컬 배포와 같은 익숙한 이유들입니다. 만약 여러분의 조직이 이러한 경우에 해당하지 않는다면, 게이트웨이는 설정의 일부가 아니며 키체인 항목은 이 글의 나머지 부분에서 설명하는 그대로 노출됩니다.
게이트웨이가 실제로 어떤 이점을 제공하는지 묻는 것은 당연합니다. 게이트웨이는 결코 무의미한 것이 아니기 때문입니다. 개발자는 회사 SSO로 로그인하고, 세션은 약 1시간 동안 지속되며, 계정 취소는 IdP(ID 공급자)를 통해 처리됩니다. 따라서 조직에서 사용자의 게이트웨이 접근을 차단하면 해당 세션 내에서 게이트웨이 접근이 종료됩니다. 업스트림 키, 즉 Claude API 키 또는 클라우드 자격 증명은 노트북에 저장되지 않습니다. 이것이 바로 이번 발표의 핵심 내용입니다.
"개발자 컴퓨터에는 오래도록 숨겨진 비밀이 없습니다."
해당 문구를 정확히 읽는 것이 중요합니다. 왜냐하면 이는 도용이 아니라 상위 키에 관한 것이기 때문입니다. 게이트웨이의 키체인에 남아 있는 것은 갱신 자격 증명입니다. 게이트웨이만 사용할 수 있도록 범위가 제한될 수 있지만, 바로 여기에 함정이 있습니다. 공격자가 이 자격 증명을 탈취하여 해당 사용자로 게이트웨이에 연결하면 계정이 활성화되어 있는 한 계속해서 새로운 세션을 생성할 수 있습니다. 1시간 세션 제한은 도둑의 접근을 막지 못합니다. 공격을 막을 수 있는 유일한 방법은 조직에서 이를 알아채고 사용자를 차단하는 것인데, 키체인에서 몰래 읽는 행위는 이러한 조치를 취할 수 없게 만듭니다. "장기간 유지되는 비밀 키 사용 금지"라는 문구는 해당 항목을 읽는 사람에게 장기간 접근 권한을 부여하는 결과를 초래합니다.
그래서 우리는 게이트웨이를 설정하고 클로드를 거기에 연결한 다음 이전 섹션에서 설명한 공격을 반복했습니다. 키체인 읽기 결과는 변하지 않았습니다. 동일한 한 줄짜리 파이썬 스크립트가 아무런 프롬프트 없이 자격 증명을 추출했고, 우리는 그것을 두 번째 컴퓨터로 복사했습니다.
이번에는 이전 섹션에서 했던 추가적인 부트스트래핑 과정도 필요 없었고, 피해자로부터 두 번째 파일도 필요하지 않았습니다. 게이트웨이 주소는 이미 우리가 탈취한 자격 증명 안에 들어있었기 때문입니다. 'Claude Code-credentials Keychain' 항목에 저장된 값에는 토큰뿐만 아니라 피해자가 로그인했던 게이트웨이 정보도 기록되어 있습니다. 따라서 한 번의 은밀한 읽기만으로 게이트웨이의 키와 주소를 모두 얻을 수 있습니다.
즉, 피해자의 디스크에서 추가로 빼낼 데이터가 없다는 뜻입니다. 공격자는 자신의 컴퓨터에서 다음 위치에 설정을 생성합니다.
/라이브러리/애플리케이션 지원/ClaudeCode/managed-settings.json
그리고 방금 탈취한 자격 증명에서 읽어낸 게이트웨이 URL을 가리키도록 설정합니다.
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
해당 파일을 작성하는 것은 아무런 장벽이 되지 않습니다. Anthropic 자체에서도 관리형 설정을 "보안 경계가 아닌 클라이언트 측 제어"라고 부르기 때문에 공격자는 자유롭게 자신만의 설정을 만들 수 있습니다. 그런 다음 탈취한 자격 증명을 로드하고 Claude Code를 시작합니다. 피해자의 신원을 다시 생성하는 별도의 단계는 없습니다. 자격 증명에는 토큰이 포함되어 있고, 토큰은 게이트웨이에 인증되며, 게이트웨이는 피해자의 접근 권한으로 피해자의 계정으로 세션을 실행합니다.
게이트웨이는 순수 원격 공격자가 넘을 수 없는 한 가지 장애물을 설치합니다. 클로드 코드(Claude Code)는 공용 IP 주소를 사용하는 게이트웨이와는 통신하지 않습니다.
"로그인 시, Claude Code는 게이트웨이의 호스트 이름 또는 IP 주소가 사설 주소(RFC 1918, 링크 로컬, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 또는 로컬 개발용 루프백)로만 확인되어야 합니다. 사용자가 직접 호스팅하는 게이트웨이의 경우, 공용 주소는 모두 거부됩니다."
따라서 탈취한 자격 증명은 사설 게이트웨이에 접근할 수 있는 곳에서만 작동합니다. 언뜻 보기에는 장벽처럼 보일 수 있지만, 위협 모델을 떠올리면 생각이 달라집니다. 공격자는 피해자 컴퓨터의 사용자 계정으로 실행 중이라고 가정하는데, 피해자 컴퓨터는 애초에 같은 네트워크 내부에 있습니다. 따라서 거기서 사설 주소에 접근하는 것은 쉬운 일입니다. 이는 장벽이 아니라 마찰일 뿐입니다.
솔직히 평가해 보겠습니다. 게이트웨이는 다른 이유로 가치가 있습니다. 상위 키가 노트북에 저장되지 않도록 보호하고, IdP를 통해 조직에 중앙 집중식 차단 기능을 제공합니다. 다만 이 기능은 누군가 도용 사실을 알아차린 후에만 작동합니다. 하지만 게이트웨이가 이 글에서 다루는 취약점을 해결해 주지는 않습니다. 자격 증명은 여전히 동일한 키체인 항목에 저장되고, 어떤 프로세스든 아무런 확인 절차 없이 해당 항목을 읽을 수 있으며, 도용된 갱신 자격 증명은 계정이 비활성화될 때까지 게이트웨이를 계속 공격할 수 있습니다.
네트워크 점검은 우회 경로일 뿐, 경유지가 아닙니다. 게이트웨이를 전혀 사용하지 않는 대다수 사용자에게는 이 과정에서 달라지는 것이 없습니다.
수비수는 즉시 무엇을 해야 할까요?
- macOS: 항목의 ACL이 Claude 서명에 바인딩될 때까지 탐지 지점은 파일이 아니라 프로세스입니다. 신호는 서비스 문자열이 Claude Code-credentials이고 -w 옵션을 사용하여 비밀 키를 출력하는 /usr/bin/security find-generic-password 호출입니다. 프로세스 실행 또는 엔드포인트 보안 원격 측정을 통해 경고를 설정하고 프로세스 계보를 사용하여 오탐을 줄이십시오. 정상적인 읽기는 Claude 바이너리로 추적되므로 이러한 항목을 먼저 기준선으로 설정하고, 의심스러운 읽기는 셸 한 줄 명령, 편집기 또는 확장 프로그램 호스트, 종속성 설치 스크립트에서 발생합니다. 동일한 서비스에 대한 add-generic-password도 감시하십시오. 도난당한 번들이 다른 시스템에 심어지는 경로이기 때문입니다. 이러한 경고는 보완 제어 수단으로 활용하십시오.
- Linux 및 Windows: .credentials.json 파일에 대한 파일 무결성 모니터링 및 DLP, 권한 변동 경고, sk-ant-oat 및 sk-ant-ort 접두사에 대한 콘텐츠 서명 기능.
- 모든 곳에서 자격 증명 저장소 읽기와 예상치 못한 아웃바운드 트래픽 간의 상관관계를 파악하고, 동일한 토큰이 호스트 간에 재사용되는지 ID 플레인을 감시하십시오. 의심스러운 경우 토큰을 교체하십시오. 한 번의 읽기로 장기간 유효한 갱신 토큰이 전달되므로, 신뢰할 수 있는 읽기 이벤트가 발생하면 엔드포인트 정리뿐만 아니라 로그아웃 후 재로그인 및 콘솔 키 교체가 필요합니다.
- 진정한 해결책은 Anthropic에 있으며, 위험 부담도 적습니다. Claude 바이너리 자체의 코드 서명에 바인딩된 네이티브 API를 통해 CLI의 키체인 항목을 생성하는 것입니다. 이는 Claude Desktop에서 이미 사용되고 있는 방식입니다.
다행인 점은 어려운 부분은 이미 Anthropic 자체 코드베이스 내에서 해결되었다는 것입니다. CLI는 새로운 보안 모델이 필요하지 않습니다. 이미 옆에서 실행 중인 보안 모델을 사용하면 됩니다.
정보 공개 일정
6월 25일 오후 3시 46분 (UTC). 연구원은 재현 단계, 영향, 그리고 세 장의 스크린샷을 포함한 보고서를 제출합니다.
6월 25일 오후 4시 05분 (UTC). Anthropic은 불과 19분 만에 해당 문제를 "Claude Code 자격 증명, 구성 및 로그의 로컬 저장" 항목에서 제외하며 정보 제공용으로만 평가하고, 동일 사용자 프로세스는 완전히 신뢰할 수 있으므로 프로세스별 키체인 ACL은 의미 있는 경계를 추가하지 않는다고 밝혔습니다.
7월 2일 오전 11시 12분 (UTC). 연구원은 사람의 재평가를 요청하며, 해당 클로징이 잘못된 제외 항목에 매핑되었다고 주장합니다(이는 로컬 저장소 문제가 아니라 키체인 ACL 구성 오류이며, 동일한 운영 체제에서 데스크톱 버전은 올바르게 처리합니다). 또한, 개념 증명(POC) 비디오를 첨부하고, 정보 공개 협조 제안과 함께 방어적인 보고서를 제출할 예정임을 알립니다.
7월 2일 오전 11시 14분 (UTC). 앤스로픽은 재평가 요청을 접수했으며 내부 검토를 진행할 것이라고 밝혔습니다. 또한 보고서가 이미 마감되었으므로 공개적인 논의는 괜찮다고 확인하면서, 보고서 초안을 미리 볼 수 있기를 요청했습니다.
7월 22. 연구원은 Anthropic의 요청에 따라 출판 전 검토를 위해 블로그 최종 초안을 공유했으며, 이 초안에는 Claude 앱 게이트웨이가 해당 결함을 완화하는지 여부에 대한 분석이 포함되어 있다고 밝혔습니다.
7월 24. Anthropic은 검토를 완료하고 사실 관계에 대한 우려 사항이나 수정 요청 사항이 없다고 보고하며 보고서 게시를 승인했습니다. 분류는 변경되지 않았으며, Keychain 항목의 접근 제어 강화는 심층 방어 강화 조치로서 가치가 있다고 판단하여 추적 중이라고 덧붙였습니다. 다만, Anthropic의 위협 모델에서는 이를 취약점으로 간주하지 않습니다.
