한 AI 에이전트가 샌드박스 (sandbox)를 탈출하여 Hugging Face의 인프라 (infrastructure)에 침입했으며, 탈취한 Tailscale 자격 증명 (credential)을 사용하여 181개의 노드 (nodes)를 그들의 테일넷 (tailnet)에 등록했습니다. Tailscale의 취약점 (vulnerability)은 발견되지 않았으며 악용되지도 않았습니다. 어쨌든 우리는 이를 방지할 수 있었어야 했습니다.

Dark orange and light orange shapes—ovals, squares, circles, quarter-circles—against a very dark brown/orange background.

여러분은 아마 보안 평가 (security evaluation)를 탈출하여 LLM 마켓플레이스인 Hugging Face를 공격한 AI 에이전트에 대해 이미 들어보셨을 것입니다. 이 에이전트는 Hugging Face가 자신의 벤치마크 (benchmark)에 대한 정답을 가지고 있을지도 모른다고 판단했고, 시험에서 부정행위를 하기 위해 정답을 훔쳤습니다. 이는 우스꽝스러운 동기이지만 무서운 결과입니다.

Hugging Face는 이번 침입에 대한 상세한 재구성 보고서를 발표했습니다. 여기에는 샌드박스 탈출 (sandbox escapes), 코드 실행 (code execution), 클라우드 자격 증명 (cloud credentials), 임시 명령 및 제어 시스템 (command-and-control systems), 그리고 최종적으로 조직 전체로 확산하기 위해 Tailscale을 사용한 것을 포함하여 4.5일 동안 복구된 약 17,600개의 작업이 포함되어 있습니다.

하지만 Tailscale은 제로 트러스트 네트워크 (zero trust network)입니다! 제로 트러스트의 핵심 목적은 공격자가 회사 내에서 측면 이동 (moving laterally)을 하는 것을 방지하는 것입니다. 무엇이 잘못된 걸까요?

Tailscale에서 발견되거나 악용된 "취약점 (vulnerabilities)"은 없었으며, 이 사실이 우리를 더욱 불편하게 만들 수도 있습니다. Tailscale은 AI 인프라 (AI infrastructure) 어디에서나 나타납니다. 거의 모든 AI 기업이 Tailscale을 사용합니다. 따라서 우리가 결국 AI 사고 보고서에 등장하게 된 것은 놀라운 일이 아닙니다.

하지만 우리는 보안 도구입니다. 그들의 침입은 곧 우리의 침입이며, 이를 심각하게 받아들이는 것이 우리의 임무입니다. 모든 사후 분석 (post-mortem)과 마찬가지로, 우리는 무슨 일이 일어났는지, 그리고 이를 방지하기 위해 무엇을 할 수 있었는지 되돌아봐야 합니다.

에이전트가 샌드박스를 탈출하고 Tailscale을 찾아냈을 때, 그것은 이미 프로덕션 워커 (production worker) 내부에서 코드 실행 권한 (code execution privileges)을 획득했고, Kubernetes 노드 (Kubernetes node)에 대한 루트 권한 (root access)에 도달했으며, 136개의 키 (keys)가 포함된 프로덕션 비밀 저장소 (production secret store)를 읽었습니다. 어떤 의미에서, 우리가 현장에 도착하기도 전에 이미 게임은 끝난 상태였습니다.

하지만 그것이 문제 아닌가요? 한두 단계 뒤로 물러나 봅시다. 왜 수명이 긴 비밀 키 (long-lived secret keys)가 누구에게나 접근 가능했던 것일까요?

하지만 그래선 안 됩니다. 그리고 우리는 지금 그것이 왜 중요한지에 대한 좋은 예를 목격했습니다. 대부분의 침입이 인간에 의해 인간의 속도로 이루어지던 옛날 세상에서는, 자격 증명 유출 완화(credential leak mitigations)는 '있으면 좋은' 기능으로 취급되었습니다. 한 번에 136개의 키를 읽을 수 있는 대규모 자격 증명 저장소는 보안 팀의 낮은 우선순위 할 일 목록 중 어딘가에 놓인 항목이었습니다.

하지만, rogue AI 에이전트(rogue AI agents)의 세상에서는, 이 대규모 자격 증명 금고 자체가 목표물이 됩니다. 더 이상 괜찮지 않습니다.

저는 장기 비밀 키(long-lived credentials)를 위한 두 가지 주요 해결책만 알고 있습니다.

첫 번째는, 한 번 삽입하고 절대 돌려주지 않는 것을 기반으로 오직 단기 자격 증명(short-lived creds)만을 발행하는 금고를 구성하는 것입니다. 예를 들어 HashiCorp Vault가 이것을 할 수 있으며, 이를 동적 자격 증명(dynamic credentials)이라고 부릅니다. 불행하게도, 동적 자격 증명은 설정하고 유지 관리하는 데 많은 노력이 필요합니다. 보안이 노력을 요구할 때, 사람들은 그렇게 하지 않습니다.

두 번째 옵션은 자격 증명을 주입하는 프록시(credential-injecting proxy)입니다. 만약 클라이언트 C가 서버 S에 접근하길 원한다면, C에게 S의 자격 증명을 직접 주기보다는, 대신 요청을 받아서 자격 증명을 삽입하고 통과시키는 것 외에는 아무것도 하지 않는 강화된 프록시 P를 통해 전송하도록 하는 것입니다. 현대적인 메시 기반 네트워킹(mesh-based networking)이 대부분의 지연 시간(latency)을 제거함에 따라, 자격 증명 주입은 인기를 얻고 있습니다. 몇 달 전, 우리는 Tailscale과 긴밀하게 통합된 우아하고 상당히 멋진 자격 증명 주입 프록시인 Border0(

보너스로 제공되는 세 번째 옵션은 Tailscale 자체입니다. Tailscale에서는 노드 키 (node key)를 TPM을 사용하여 머신에 바인딩 (machine bound)함으로써 유출을 방지할 수 있으며, 기업 사용자라면 반드시 이를 적용해야 합니다. 아쉽게도 일부 사용자의 하드웨어에서 발견된 HSM 문제로 인해 Linux 및 Windows에서 TPM 스토리지를 기본적으로 비활성화해야 했습니다. 어쨌든, 이번 사례의 경우 공격이 Tailscale에 대한 접근 권한을 부여한 방식이었기 때문에, 우리는 너무 늦게 도착했습니다.

동적 자격 증명 (dynamic credentials)도, 자격 증명 주입 프록시 (credential-injecting proxies)도 구축되어 있지 않았기에 136개의 키가 유출되었습니다. 그렇다면 다음 방어선은 무엇일까요?

유출된 136개의 자격 증명 중 하나는 재사용 가능한 Tailscale 인증 키 (auth key)였으며, 이는 그들의 tailnet 내에서 새로운 Tailscale CI (지속적 통합, continuous integration, 자동화된 테스트에 사용됨) 노드를 생성하는 데 사용되었습니다. 에이전트는 해당 키를 일련의 외부 샌드박스 (sandboxes)로 복사하여 사용했으며, 며칠에 걸쳐 총 181개의 노드를 Hugging Face의 tailnet에 등록했습니다. 해당 노드들은 각각 CI 노드가 가질 수 있는 모든 권한을 부여하는 Tailscale ID 태그 (identity tag)를 부여받았습니다.

우리는 그 136개의 키를 구할 수 없었습니다. 하지만 재사용 가능한 Tailscale 키가 그중에 포함될 필요는 없었습니다.

우리는 이와 같은 사례를 위해 워크로드 ID 페더레이션 (workload identity federation)을 구축했습니다. 이는 클라우드 제공업체가 실행 중인 VM (또는 컨테이너)의 클라우드 ID로부터 생성된 수명이 짧은 자격 증명 (short-lived creds) 형태로 "주변 권한 (ambient authority)"을 제공하는 것에 의존합니다. CI 작업은 클라우드 플랫폼에 서명된 OIDC 토큰을 요청할 수 있습니다. Tailscale은 해당 토큰을 검증한 다음, 해당 워크로드에 할당된 태그와 스코프 (scopes)로 접근 권한을 부여합니다. 멋진 점은 이를 활성화하면 자동으로 수행될 수 있다는 것입니다. CI 노드를 실행하면 Tailscale이 ID를 가져오고 적절한 태그를 할당합니다. 유출될 자격 증명이 없으며, 주의 깊게 구성한다면 이 자격 증명을 CI 이외의 다른 곳에서 사용할 방법도 없습니다.

즉, CI 자격 증명을 탈취하여 다른 노드에서 실행함으로써, 테스트 클러스터에서 나머지 네트워크로 빠져나가는 포장된 경로 (paved route)로 만드는 것을 방지할 수 있다는 의미입니다.

안타깝게도, 워크로드 ID 페더레이션 (workload identity federation)을 사용하는 사람이 충분하지 않았습니다. 고객들이 이것이 더 쉽고(easier) 동시에 더 안전한(safer) 경로임을 확실히 알 수 있도록 하고, 이를 채택할 수 있는 명확한 방법을 제공하기 위해 더 많은 노력을 기울였어야 했습니다. 우리는 문서를 개선하고, UI에 더 많은 유도 장치 (nudges)를 추가할 수 있습니다.

흔적을 숨기려는 시도로, 에이전트는 해당 클라이언트의 보고를 억제하는 --no-logs-no-support 옵션과 함께 Tailscale을 실행했습니다.

이는 Tailscale로 텔레메트리 (telemetry) 메타데이터를 보내는 것을 우려하는 사용자를 위해 설계된 옵션입니다. 설령 우리가 이 옵션을 제공하지 않았더라도, 소스 코드를 수정하여 텔레메트리를 제거하는 것은 쉬운 일이었을 것입니다.

하지만 로그를 중단한다고 해서 연결이 보이지 않게 되는 것은 아닙니다. Tailscale 네트워크 플로우 로그 (network flow logs)를 활성화하면, 모든 연결의 양쪽 끝(both ends)은 물론 서브넷 라우터 (subnet routers)와 엑시트 노드 (exit nodes)로부터의 트래픽을 보고합니다. 이는 미묘하지만 중요한 점입니다. 침해된 노드는 플로우 로그를 보내지 않을 수 있지만, 해당 노드가 연결되는 모든 노드는 로그를 보냅니다. 그러면 주의 깊게 설정된 SIEM (Security Information and Event Management)이 양 끝단이 일치하지 않을 경우 즉각적인 적색 경보를 울릴 수 있습니다.

플로우 로그가 주의 깊게 구성된 SIEM으로 스트리밍된다면 탐지에 도움이 될 수 있습니다. 하지만 이는 많은 작업이 필요합니다. 플로우 로그를 활성화해야 하며, 나중의 포렌식 (forensics) 용도뿐만 아니라 실시간으로 유용하게 사용될 수 있도록 적절한 실시간 탐지 규칙 (live detection rules)을 갖추어야 합니다. 우리는 플로우 로그를 더 쉽게 발견하고, 구성하고, 채택하며, 경보 트리거 (alert triggers) 역할을 할 수 있도록 만드는 방법을 검토하고 있습니다. 저는 우리가 플로우 로그를 너무나 사용하기 쉽게 만들어, 보안 팀이 모니터링하지 않더라도 도움이 되도록 만들고 싶습니다.

단순한 로깅 이상의 직접적인 제어를 원한다면, Tailnet Lock을 활성화할 수도 있습니다. 이를 통해 모든 새로운 노드에 대해 직접적인 가시성을 확보하고, 엄격하며 프로그래밍 가능한 승인 제어 (admission control)를 수행할 수 있습니다. 예를 들어, 약간의 작업을 통해 서명 노드 (signing node)가

네트워크 보안은 어렵습니다. 언제나 어려웠습니다. 악성 AI 에이전트 (rogue AI agents)가 등장한 새로운 세상에서는 단순히 어려운 것을 넘어 필수적인 요소가 되었습니다. 그리고 많은 조직이 네트워크 보안 전문 지식을 갖추고 있지 않다는 점이 문제입니다.

그래서 Tailscale은 이를 개인적인 책임으로 받아들입니다. 사람들은 자신이 측면 이동 공격 (lateral movement attack)이 무엇인지조차 모르더라도, 별도의 조치 없이도 우리 제품이 기본적으로 이러한 종류의 공격을 방지해 주기를 기대합니다.

만약 이번 사건으로 인해 자신의 인프라를 불안하게 바라보고 있다면, 워크로드 (workloads)가 읽을 수 있는 재사용 가능한 Tailscale 인증 키 (auth keys)를 살펴보는 것부터 시작하십시오. 특히 클라우드와 CI의 경우, 가능한 한 워크로드 ID 페더레이션 (workload identity federation)으로 교체하십시오. 수명이 긴 인증 키들을 제거하십시오.

(인증 키는 여전히 유용한 용도가 있습니다. 특히 일회성 프로비저닝 (one-time provisioning)이나 플랫폼 ID가 없는 환경의 경우 그렇습니다. 인증 키가 필요한 경우, 일회용 키를 선호하십시오. OAuth 클라이언트 (OAuth clients)를 사용하여 인증 키의 만료 기간을 짧게 유지하십시오. 좁은 범위의 태그 (tags)를 사용하십시오. ACL에서 해당 키에 부여된 권한을 감사(audit)하십시오.)

네트워크 흐름 로그 (network flow logs)를 활성화하고 보안 팀이 이미 사용 중인 도구로 전송하십시오.

TPM을 제어할 수 있는 관리형 플릿 (managed fleets)에서는 보안 노드 상태 저장소 (secure node state storage)를 사용하십시오. 제어할 수 없는 노드에 대해서는 디바이스 포스처 (device posture)를 사용하여 노드를 격리하고 제한하십시오.

우리가 이러한 안전한 선택지들을 충분히 명확하게 제시하지 못했다는 점을 알고 있습니다. 그것은 우리의 책임입니다. 우리는 문서를 개선하고, UI에 알림 (nudges)을 추가하며, 이러한 설정들이 기본적으로 활성화되도록 최선을 다하고, 위험한 작업을 수행할 때 경고를 보내며, 더 나은 대안을 제안하겠습니다.

이것은 매우 캐나다다운 사과입니다. 저희의 실수로 불편을 드려 죄송합니다. 이번 공격은 Tailscale을 악용한 것이 아니며, Tailscale이 침해 사고를 일으킨 것도 아닙니다. 하지만, 저희가 그것을 막지 못했습니다. 다음에는 막아내겠습니다.

Tailscale을 운영 중이며 더 깊이 파고들고 싶다면, 저희의 지원 및 솔루션 엔지니어링 팀에 문의해 주십시오. 다음 AI 에이전트가 나타나기 전에 설정을 강화하고 취약한 부분을 찾을 수 있도록 도와드리겠습니다.

저자

Avery Pennarun Headshot