Reddit

Tailscale warns of SSH flaws allowing root privilege escalation

Tailscale 취약점 11건 발견…SSH 결함은 root 권한 상승, 일부는 자격 증명 탈취 가능

보안 연구팀 Cyberdione Labs가 Tailscale과 자체 호스팅 제어 서버 headscale에서 취약점 11건을 발견했습니다. Tailscale SSH의 포트 포워딩 결함은 이미 접속 권한이 있는 사용자가 서버에서 root 권한을 얻도록 할 수 있으며, Tailscale은 패치를 준비하면서 SSH 정책 검토와 포워딩 비활성화를 권고했습니다.

에디터 노트

이번 취약점의 범위는 Tailscale 전체가 아니라 내장 Tailscale SSH와 여러 부가 구성요소입니다. root 권한 상승에는 이미 승인된 기기와 SSH 접근 정책이 필요하며, 일반 OpenSSH를 Tailscale 네트워크 안에서 쓰는 경우는 해당 SSH 결함의 대상이 아닙니다. 따라서 모든 사용자가 기능을 끄라는 권고 대신 정책 점검과 불필요한 포워딩 비활성화를 제시한 대응은 기사에 적힌 공격 조건과 맞습니다. Reddit에서는 인증된 접속이 필요한 문제를 root 권한 상승이라고 부르는 것이 과장인지 논쟁했지만, 낮은 권한으로 접속한 뒤 더 높은 권한을 얻는 상황은 권한 상승이라는 반박이 타당합니다. CVE 번호와 심각도 점수가 없다는 지적은 취약점 추적과 우선순위 판단에 필요한 정보가 부족하다는 문제를 짚습니다. 다만 제공된 내용만으로는 각 구성요소의 영향 버전과 패치 배포 여부를 확인할 수 없습니다.

AI 요약

Tailscale 보안팀은 자격 증명 탈취, 서버 충돌, root 권한 상승 등을 일으킬 수 있는 취약점 11건을 수정하고 있습니다. Cyberdione Labs는 Tailscale 1.104.2와 자체 호스팅 제어 서버 headscale v0.29.5를 대상으로 보안 감사를 진행해 이 결함들을 발견했습니다. 연구팀은 수정되지 않은 정식 배포 버전에서 취약점을 재현했다고 밝혔습니다. 전체 취약점은 Tailworm으로 불립니다.

Tailscale SSH에서 root 권한 상승

가장 심각한 문제는 root 권한으로 실행되는 Tailscale의 내장 SSH 서버에서 발견됐습니다. Unix 소켓 포워딩 과정에서 경로 확인과 파일 작업을 root 권한으로 수행하며, 권한을 낮추지 않거나 경쟁 상태가 생기는 결함이 있습니다. 공격자는 이 문제를 이용해 서버에서 root 권한으로 코드를 실행하거나 등록 키를 탈취하고, 임의의 root 파일을 삭제할 수 있습니다.

공격하려면 대상 tailnet에서 승인된 기기와 SSH 정책 규칙이 필요합니다. headscale에서는 포워딩이 자동으로 허용되고, Tailscale SaaS에서는 규칙별로 허용 여부를 설정합니다. Tailscale은 이미 Tailscale SSH 접속 권한이 있는 사용자가 설정된 로컬 계정보다 높은 권한으로 작업할 수 있다고 설명했습니다. 취약점 악용에는 사용자나 기기에 부여한 권한, 시스템 설정 등 조건이 따릅니다.

그 밖의 취약점

실험 기능인 app connectors(conn25)는 목적지 검증 없이 공격자가 지정한 곳으로 트래픽을 전달합니다. 실제 목적지에는 네트워크 ACL도 적용되지 않아 클라우드 메타데이터와 내부 LAN에 접근하거나 Kubernetes 클러스터의 모든 서비스에 닿을 수 있습니다. 공격자는 해당 커넥터 기능을 허가받은 기기를 필요로 합니다.

headscale에서는 인터넷에서 접근 가능한 제어 서버에 인증 없이 자원을 소모시키는 문제가 발견됐습니다. 메모리 사용량이 늘고 캐시가 밀려나면서 서버가 반복해서 중단될 수 있으며, 조직 전체에서 새 기기를 등록하지 못할 수 있습니다. DERP 클라이언트는 악성 릴레이 응답을 제한 없이 읽어 메모리가 고갈될 수 있습니다. tailscale serve에서는 Unix 소켓으로 TCP 포워딩할 때 HTTP 경로에 있는 보호 장치가 빠져 있고, 마운트 권한 확인 과정에도 경쟁 상태가 있습니다. 이 결함은 노드의 관리 API에 원격 접근하거나 일부 요청에서 앱 권한 검사를 우회하게 할 수 있습니다.

권고와 패치 계획

Tailscale은 모든 사용자에게 Tailscale SSH를 끄라고 권고하지는 않았습니다. 대신 SSH 접근 정책을 검토해 필요한 사용자와 기기로 제한하고, 불필요하다면 tailscaled 서비스 환경 변수에 TS_SSH_DISABLE_FORWARDING=1을 설정한 뒤 서비스를 재시작하라고 안내했습니다. 이 설정은 Tailscale SSH 자체를 끄지 않고 포워딩을 막아 여러 중대 취약점을 완화합니다. 민감한 시스템은 조사 중 접근 정책을 더 좁힐 것을 권했습니다.

Tailscale은 보도 당시 10월 27일 화요일까지 수정 버전을 배포하는 것을 목표로 삼았으며, 패치된 클라이언트가 나오면 업데이트하라고 당부했습니다.

Reddit 반응

  • @floralfrog — 이미 인증된 SSH 세션이 필요한 문제를 SSH root 권한 상승이라고 표현하면 지나치게 과장한 설명입니다. 결함이 있고 수정 중인 것은 맞지만 이번에도 침착하게 봅시다.
    • @sysop073 — 권한 상승에는 처음부터 권한이 필요합니다. 올린 글도 원하는 맥락을 담은 링크입니다.
    • @Perfect-Escape-3904 — 취약점은 심각하고 설명된 그대로 root 권한 상승입니다.
    • @two_bit_hack — 낮은 권한 사용자가 허용된 수준보다 높은 권한을 얻는 것이 권한 상승입니다. 인증된 세션이 필요해도 그 분류는 달라지지 않습니다.
  • @bankroll5441 — Tailscale SSH 기능을 명시적으로 켜야 영향을 받습니다. Tailscale을 거쳐 일반 OpenSSH를 쓰는 경우에는 영향이 없습니다.
  • @antitrack — Tailscale SSH는 기본적으로 꺼져 있고, 어떤 사용자와 기기가 어떤 기기에 SSH로 접속할지 접근 제어 정책도 만들어야 합니다. 그래서 대부분은 사용하지 않는 것 같습니다.
  • @doolittledoolate — Tailscale의 VPN 기능은 꽤 안전할 수 있지만, SSH를 대체하는 기능을 쓰는 것은 보안 면에서 후퇴라고 봅니다.
  • @zunjae — 키를 직접 관리하지 않아도 되고 접근 제어 규칙을 적용할 수 있다는 점은 큰 장점입니다. 기능은 선택 사항으로 보입니다.
  • @Zemei-Lochter — 신원 기반 SSH의 편리함은 있지만, 암호화된 통로 위에서 전통적인 키 관리를 하는 편이 공격 표면을 줄이는 데는 여전히 낫습니다.
  • @doolittledoolate — Tailscale 취약점에 CVE 번호가 없는 점이 마음에 들지 않습니다. 자체 TS 번호를 쓰면 취약점 이력을 추적하기 어렵고 검색 결과에도 Tailscale 취약점이 적게 나타납니다.

원문: BleepingComputer / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗