Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
패치되지 않은 Tailscale SSH 결함, 침해된 기기에서 다른 서버의 루트 권한까지 이어질 수 있어
연구자 Erica Windisch는 Tailscale SSH와 headscale의 실험실 테스트에서 포트 포워딩을 악용해 대상 서버의 루트 권한을 얻는 경로를 보고했습니다. Tailscale은 관련 문제를 조사하고 수정 중이라고 밝혔지만, 공개 시점에 패치나 보안 공지는 없었으며 실제 네트워크에서 재현된 공격도 없습니다.
- 주제
에디터 노트
접근 규칙이 넓을수록 한 기기의 침해가 다른 기기의 루트 권한으로 번질 수 있다는 보고서의 실험 결과가 이 사안의 중심입니다. 다만 Tailworm의 재현은 연구자 한 명의 실험실 테스트에 한정되고 Tailscale은 구체적인 기술 주장을 확인하지 않았습니다. 따라서 확산 가능성을 실제 공격 사례처럼 받아들이기보다 설정별 영향과 수정 상황을 구분해서 읽어야 합니다. Reddit 댓글은 Tailscale SSH를 오래전부터 꺼뒀다는 경험과 일반 SSH의 검증된 생태계를 선호한다는 의견을 보탭니다. 반면 한 댓글은 이 기능이 엔터프라이즈 PAM 제품의 일부라고 짚어 단순한 편의 기능으로만 볼 수 없음을 말합니다. Tailscale도 모두에게 비활성화를 권하지 않았고 영향받는 설정을 조사 중입니다. 현재 보고서가 제시한 직접적인 완화책은 포트 포워딩 제한과 기기별 쌍으로 좁힌 접근 규칙이며, SSH check mode는 권한 상승을 막지 않는다는 구분도 중요합니다.
AI 요약
Tailscale SSH는 접속 사용자의 비밀번호나 키 대신 기기 신원을 확인하고, 접근 규칙으로 세션 허용 여부를 정합니다. Erica Windisch는 2026년 10월 25일 공개한 Tailworm 보고서에서 이 구조와 포트 포워딩을 악용해 침해된 기기 한 대에서 접근 규칙이 허용한 다른 기기로 권한을 확장하는 방법을 설명했습니다. 공격자는 먼저 취약한 웹 앱, 악성 소프트웨어 패키지, 피싱, 탈취한 로그인 정보 등으로 네트워크 안의 기기를 장악해야 합니다. Tailscale이 초기 침투를 일으키는 것은 아닙니다.
실험실에서 확인한 공격 경로
Windisch는 Tailscale 1.104.2와 자체 호스팅 서버인 headscale 0.29.5를 사흘간 실험했습니다. 일반 사용자 권한으로 연 SSH 세션에서 표준 포트 포워딩을 사용하자 루트 권한으로 실행되는 Tailscale 프로세스가 루트 전용 시스템 소켓에 연결됐고, 테스트 환경에서 루트 권한과 시스템 암호 파일 접근을 얻었습니다. 다른 방법으로는 루트 소유 소켓을 공격자 소유 소켓으로 바꿔 특정 서비스에서 루트 명령을 실행했습니다.
보고서는 파일 경로 검사와 실제 사용 사이의 시차를 노리는 경쟁 상태 공격도 설명합니다. 이 경로에서는 기기 등록에 쓰이는 키를 가로채 공격자 기기를 신뢰된 서버로 네트워크에 등록했습니다. 다만 마지막 단계까지 성공한 것은 Tailnet Lock을 켜지 않은 환경뿐입니다. Tailnet Lock이 켜진 환경에서는 필요한 비밀 정보가 전송 중 포착됐지만 등록은 완료되지 않았습니다. 보고서는 접근 규칙이 허용한 기기들로 초당 1단계 미만의 속도로 확산할 수 있다고 주장하지만, 이는 실험실 측정이며 실제 네트워크에서 관찰한 결과는 아닙니다.
영향 범위와 완화책
Tailscale 호스팅 서비스에서는 규칙별로 포트 포워딩을 끌 수 있습니다. headscale 0.29.5에는 해당 설정이 없어 보고서는 모든 SSH 허용 규칙을 대상 기기의 루트 권한을 주는 것으로 취급하라고 권고합니다. 보고서에서 확산을 막은 통제는 출발 기기 하나와 대상 기기 하나를 지정하는 쌍별 접근 규칙이었습니다. TPM이나 Secure Enclave에 기기 키를 묶는 방식도 제약으로 꼽았습니다.
권고 사항은 SSH 접근 규칙을 기기별 쌍으로 제한하고 넓은 사용자·태그 기반 규칙을 제거하는 것입니다. 가능한 환경에서는 포트 포워딩을 끄고, 필요하지 않은 기기의 app connector 권한을 없애며, Unix 소켓을 향하는 tailscale serve 포워딩도 제거하라고 합니다. 노드 키 만료를 켜고 기기가 침해되면 제어 플레인에서 삭제해야 합니다. 기기를 재설치해도 공격자가 복사한 키는 폐기되지 않을 수 있기 때문입니다. Tailscale이 권하는 SSH check mode는 세션 전에 로그인 단계를 추가하지만 권한 상승 자체를 막지는 않습니다. 자동 업데이트도 권고했습니다.
공개 시점의 확인 상황
보고서가 공개됐을 때 Tailscale은 보안 공지와 CVE 번호, 수정 버전을 내놓지 않았습니다. 엔지니어링 부사장 Mike Shaver는 회사가 보고서를 받았으며 외부 보안 전문가와 같은 영역을 조사해 왔고 수정할 문제를 확인했다고 Reddit에 썼습니다. 어떤 설정이 영향을 받는지는 계속 확인 중이며 모두에게 Tailscale SSH를 끄라고 권하지는 않는다고 밝혔습니다. 구체적인 기술 주장은 Windisch의 보고서에만 근거하며 다른 연구자의 공개 재현이나 Tailscale의 확인은 없었습니다. Windisch는 보고서와 PoC를 공개 게시 전에 회사 보안 담당자에게 보냈다고 밝혔고, PoC 코드는 공개하지 않았습니다.
SSH 문제는 보고서의 11개 발견 사항 중 하나입니다. app connector의 실험 기능 conn25에서는 허용된 사용자가 보안팀이 승인하지 않은 목적지로 트래픽을 보내 클라우드 메타데이터 서비스에 접근할 가능성도 제기했습니다. Windisch는 일부 조직에서 이 문제가 더 큰 영향을 줄 수 있다고 말했습니다. 과거 Tailscale은 SSH와 서버 소켓 처리 결함을 수정했고, 2026년 초에는 권한 있는 소켓에 접근할 수 있던 Unix 소켓 포워딩 문제를 1.98.9에서 고쳤습니다.
Reddit 반응
- @hypnoticlife — 하하. 이건 첫날부터 예상할 수 있는 보안 문제였습니다. 수십 년의 역사와 실적, 더 큰 오픈소스 커뮤니티가 있는 SSH 대신 다시 만든 SSH 데몬을 왜 신뢰하겠습니까? 보안 제품이라고 생각한 게 문제입니다. 이건 일반 보안 절차를 우회하는 원격 루트 접근일 뿐입니다. 이런 편의성 백도어는 쓰지 말고 최소한 암호가 걸린 키를 쓰세요.
- @rb3po — 저도 늘 걱정했습니다. Tailscale 계정과 기기 설정에서 가장 먼저 끄는 기능입니다.
- @Gordahnculous — Tailscale의 답변, 특히 엔지니어링 부사장의 답변을 찾는 분들을 위한 댓글입니다.
- @InternalServerErr500 — Tailscale이 개발을 "여행 중 ProtonVPN에 연결한 상태로 Apple TV에서 집의 NAS에 접속하려면 어떻게 하지?!?!" 같은 사례에 집중하면 이렇게 됩니다. 특수한 경우에 매달리느라 기본적인 엔터프라이즈 연결도 제대로 처리하지 못합니다.
- @w1thh3ld — 이 기능은 실제로 베타 PAM 제품의 일부입니다. 적어도 예전 라이선스에서는 주로 엔터프라이즈용이었습니다. 에이전트를 쓰는 일부 PAM 제품에도 이런 접근 방식과 위험이 있을 것 같습니다.