요약
Tailscale SSH에서 권한 상승 취약점이 나와 테일스케일이 수정판과 임시 대응법을 내놓았습니다.
테일스케일이 자사 SSH 기능의 보안 조사 경과를 공개했습니다. 외부 보안 전문가와 함께 조사하고 있으며, 10월 27일 갱신에서 보안 공지 4건(TS-2026-014~017)을 냈다고 밝혔습니다.
왜 중요한가
- 이미 접속을 허락받은 사용자가 지정된 계정의 권한을 넘어설 수 있습니다. 계정별로 권한을 나눠 둔 조직이 영향을 받습니다.
- 테일스케일은 Tailscale SSH를 모두 끌 필요는 없다고 했습니다. 패치 전까지는 설정을 조여 위험을 줄이라고 권했습니다.
핵심 내용
- 문제 대부분은 권한 상승(허용된 범위보다 높은 권한을 얻는 것)입니다.
- 공격 가능성은 접속자에게 준 권한과 시스템 설정에 따라 달라지며, 영향받는 설정의 범위는 아직 확인 중입니다.
- 대부분은 이미 고쳤고, 10월 27일 패치된 클라이언트 배포를 목표로 테스트하고 있었습니다.
- 당장은 tailscaled 서비스 환경에
TS_SSH_DISABLE_FORWARDING=1을 넣어 SSH 포워딩을 끄라고 권했습니다. - 접근 정책을 점검해 필요한 사용자와 기기만 접속하게 하고, 민감한 시스템은 임시로 더 좁히라고 했습니다.
HN 반응
- 일부 이용자는 root나 sudo 없이 일반 계정 접속만 허용한 경우에만 문제라고 짚었고, 권한 상승도 가볍지 않다는 반론이 나왔습니다.
- 표준 OpenSSH를 고수해 다행이라는 댓글과, 감사 기록이 필요한 금융 조직에는 이런 제품이 오히려 관리를 덜어 준다는 반박이 맞섰습니다.
전직 테일스케일러이고, 지금은 한 조직에서 Tailscale을 관리하고 있습니다.
취약점과 GitHub에 올라오는 수정 내용을 직접 검토해 봤는데, 이번 건은 ACL로 노드에 대한 SSH 접속(opensshd가 아니라 Tailscale SSH)을 허용하면서 sudoers/root로 가는 경로는 주지 않은 경우에만 영향을 준다는 점이 분명합니다.
취약한 노드에 SSH 권한이나 연결 경로가 아예 없는 사용자라면, 이 취약점들로는 접근 권한을 얻을 수 없습니다.
하지만 취약한 tailscaled를 쓰면서 root가 아닌 계정이나 권한으로 SSH 접근을 줬다면, 특정 사용자 계정을 넘어서는 권한 상승이 이미 알려져 있으니 이 취약점들은 해당됩니다.
취약점을 깎아내리려는 건 아니고 중요한 문제가 맞습니다. 다만 일부에서 떠드는 것처럼 아무나 마음대로 할 수 있는 RCE는 아닙니다.
이걸 "tailworm"이라고 부르는 건 자기들이 찾은 걸 더 띄우려는 호들갑 같아요.
웜처럼 동작하려면 테일넷 안의 머신들이 딱 맞는 설정을 갖추고 있어야 하고, 그 머신들이 같은 설정을 가진 다른 테일넷에도 속해 있어야 하는데, 그러려면 또 그 테일넷의 누군가가 딱 맞는 설정의 또 다른 테일넷을 갖고 있어야 하죠...
억지스러워요.
그래도 Tailscale 사용자의 상당수는 소프트웨어 엔지니어링 전문가일 테고, 그래서 Tailscale을 SSH 용도로만 쓰는 경우도 많습니다. 저는 영향이 여전히 꽤 크다고 느낍니다. 특히 SSH는 곧바로 서버 장악으로 이어지니까요.
Tailscale SSH를 쓰는데 sudo가 없거나 root 로그인을 허용하지 않으시나요?
Tailscale SSH ACL이 전부 sudo가 되는 계정이나 root로 들어가게 해 준다면 영향이 없습니다. 한 달 전에도 할 수 없던 일을 이 취약점으로 새로 할 수 있게 되는 건 아니니까요. 제가 전하려는 뉘앙스가 바로 그겁니다(영어가 서툴러서 잘 전달됐는지 모르겠네요).
제가 Tailscale SSH 접근을 제공하는 노드는 대부분 root나 비밀번호 없는 sudo 사용자로 접속하게 되어 있습니다. 관리용 접근이거든요. 그런 노드에서는 말씀대로 별로 문제가 안 됩니다.
사용자를 각자 자기 계정으로 제한한 노드도 몇 대 있습니다. 하지만 개발 서버이고 개발자들도 우호적인 사람들이라, 그런 경우에도 그렇게 큰일은 아닙니다.
그래도 우리 정보보안팀은 모든 곳을 업그레이드하라고 요구할 게 분명하긴 합니다.
엔지니어는 SSH에는 그냥 일반 SSH를 씁니다. Tailscale SSH는 실행된 모든 명령의 감사 기록을 남기고 ACL을 강제하는 식의 엔터프라이즈 용도에 더 맞춰져 있어요.
저는 여러 직장에서 Tailscale을 써 봤지만 Tailscale SSH를 쓴 곳은 한 군데도 없었습니다. 구닥다리라고 하셔도 좋습니다. 지금 다니는 회사에서도 Ansible로 서버에 SSH 키를 배포하고, Tailscale SSH가 아니라 테일넷 위에서 그냥 평범한 SSH를 씁니다.
딴소리인데, 직원을 부르는 이름으로 정말 tailscalar를 쓰시나요? 아니면 tailscaler를 잘못 쓰신 건가요?
Tailscalar 맞아요!
또 하나 재미있는 사실이 있는데, tails.txt와 scales.txt라는 꼬리 달린 것들, 비늘 달린 것들의 목록이 있고(GitHub에서 찾아보세요), 이 목록으로 무작위 테일넷 이름을 만들었어요 :)
(적어도 예전에는 그랬어요. 벌써 몇 년 전 일이라서요.)
저는 리눅스에 기본으로 들어 있는 OpenSSH를 계속 써 와서 꽤 다행이라고 생각합니다. 이번 사건으로 그 선택이 옳았다는 게 확인됐어요.
수십 년 동안 원격 접속을 유지해 오면서 공유기 포트 포워딩도 썼습니다. 2008년에는 할머니가 입원해 계신 병원의 제한된 와이파이에서 접속하려고 SSH를 80번 포트에 올린 적도 있고요. openvpn도 써 봤고 Cloudflare 터널도 써 봤습니다. 하지만 결국 항상 키 인증만 허용하도록 단단하게 설정한 openssh로 접속합니다.
단일 사설 네트워크에서 OpenSSH를 쓰시는 것과, ACL로 관리되지 않는 SSH 클라이언트를 쓰고 배포하는 것은 어떤 의미로도 같지 않습니다.
전통적인 방식인 OpenSSH + 키 배포(설정 관리 도구나 ldap으로)에 복잡성만 더하는 것처럼 들리는데요.
게다가 이제 버그까지.
아니요, 그렇게 들리지 않습니다. Tailscale은 복잡성을 줄여 줍니다. 말 그대로 ACL이 붙은 키 배포 자체입니다.
저는 엔지니어가 수백 명, 기술 직군 사용자가 수천 명인 금융 조직에서 일합니다. 감사와 추적성, 어떤 형태로든 신원 관리 체계가 없으면 OpenSSH만으로는 금융 컴플라이언스 프레임워크를 절대 충족할 수 없습니다. 그걸 제공하는 게 바로 Tailscale(또는 대체 제품)입니다.
직접 구축하면 그 소프트웨어를 이제 전부 직접 책임져야 합니다. 말씀하신 댓글은 현실 시나리오의 복잡성을 이해하지 못하고 있습니다.
SSH CA를 구현하기만 하면 됩니다. 직접 만들어도 되고, Vault에는 엔터프라이즈용이 있고, 규모가 작은 조직이라면 StepCA가 적당합니다.
그냥 키에 서명하는 방식이라 핵심 SSH 프로토콜의 장점을 전부 누릴 수 있습니다. 솔직히 저평가된 방식이에요.
복잡성을 더한다는 건 둘 다 쓴다는 뜻일 텐데요. 이 경우에는 키 배포와 키 기반 접근 제어의 복잡성을 Tailscale SSH가 가져오는 복잡성과 맞바꾼다고 말하는 게 더 정확합니다.
맞아요, 첫날부터 뻔했죠.
제가 이해하기로 이 버그는 여러분이 SSH 접속을 명시적으로 허용한 사람이, 머신의 특정 계정에서 그 계정이 가진 범위 이상의 권한을 얻게 해 줍니다. 그러니 SSH를 본인만 쓰거나, sudo가 되는 사용자에게만 SSH 키를 주거나, 이 취약점을 악용하지 않을 거라고 믿는 사람에게만 주거나, 다른 취약점으로 로컬 셸 사용자가 어차피 권한을 올릴 수 있거나, Tailscale을 포트 포워딩 용도로만 쓴다면 영향이 없습니다. 어떻게 보면 공개된 openssh 인스턴스보다 노출이 오히려 적다고도 할 수 있는데, 저는 그렇게 공개해 두는 데 별 거부감은 없습니다.
이제 권한 상승은 걱정할 일이 아닌 건가요?
그 경계를 믿고 의존한다면 물론 걱정해야죠. Tailscale의 '일반 사용자' 용도는 그냥 리버스 프록시인데, 윗윗분이 그렇게 보고 계시다고 생각해서 한 말이에요. 저는 제 테일넷에 다른 사람이 아무도 없고, 예전에 있었을 때도 그 사람들에게는 SSH 키가 없었어요. 설령 있었다 해도 권한 상승 경로는 많았을 거라고 생각하고요. 어차피 sshd보다 공격 면이 더 넓으니까요. 그러니까 제가 말하려던 건, 이번 건이 인증받지 않은 사용자가 RCE를 하는 게 아니라 인증된 실행에서 특권 실행으로 올라가는 권한 상승으로 보인다는 거였어요.
root 계정에서는 권한 상승은 걱정할 일이 아니죠.
산업용 로봇 팔이 연결되어 있다면 물리적 접근까지 올라갈 수 있겠네요.
"root 계정"은 지금 그쪽 가정이잖아요, 아닌가요?
저도 같은 생각이에요. openssh의 공격 면(그리고 damien에 대한 제 신뢰)이 더 잘 맞는다고 봅니다.
저는 애초에 Tailscale이 서비스 인증까지 맡게 하는 게 좋은 생각이 아니라고 봅니다. Tailscale은 기존 인프라와 서비스를 둘러싼 추가 보안 계층이어야 하니까요.
Tailscale이 VPN과 SSH를 동시에 맡으면 결국 또 단일 장애점이 생기는 셈입니다. SSH를 인터넷에 직접 노출하는 것과 비슷합니다.
예전 직장에서 제가 내린 결정이 바로 이거였는데, 옳았다는 게 증명된 것 같네요.
그렇게 쓰는 게 맞다는 데는 동의합니다. 하지만 Tailscale이 인증을 대신해서 쓰라고 강력하게 권하고 있으니, 원래 그렇게 쓰도록 "되어 있는" 건 아니에요...
Tailscale(이나 Nebula 같은 다른 가상 네트워크 계층)에 올라타지 않아서 다행이라고 말하는 사람이 너무 많아요. 여러분, 이건 그저 하나의 계층일 뿐이라는 걸 기억하세요. 예를 들어 GitLab은 요즘 매주 새로운 치명적 CVE가 나오는 것 같은데, 저는 그 앞단에 계층으로 Tailscale(그리고 물리 방화벽)이 있어서 다행이라고 생각했습니다. Tailscale이 없었다면 스트레스가 전체적으로 더 컸을 거예요.
그리고 대안을 들고 나오시기 전에 말씀드리면, 저도 압니다. 하지만 대안들은 공격 면이 (이론상) 똑같거나(예: [관리형] Nebula), 수작업이 훨씬 많이 들어서(예: Wireguard) 설정 실수에 더 취약합니다.
결국 기본으로 돌아옵니다. 심층 방어, 최소 권한 원칙, 패치 똑바로 하기. 보안 문제는 거의 다 이 중 하나를 어겨서 생겨요.
그러게요, 매뉴얼을 읽어야 한다니 수작업이 훨씬 많이 드는 일이죠. 차라리 버그를 배포하는 게 낫겠네요.
기능도 너무 많고 코드 줄 수도 너무 많습니다(아마 OpenVPN보다 많을 거예요). 이 정도 공격 면과 기능 규모라면 온갖 제로데이가 있을 거라고 확신합니다.
저는 Tailscale을 아주 많이 쓰고, 코드를 검토해 준다면 기꺼이 돈을 더 낼 의향도 있어요.
위험한 기능을 꺼 두는 잠금 모드가 있으면 좋겠습니다.
저는 연결용 VPN만 필요합니다. taildrop, taildrive, SSH, funnel, services, DNS, 노드 공유 같은 건 필요 없어요... 관리 콘솔에서는 꺼 두었지만 코드는 제 기기에서 계속 돌아가고, 실수로 켜질 수도 있잖아요.
질문이 하나 있습니다. Taildrop은 인증 없는 입력을 받고 ACL도 따르지 않는다고 하는데요, 확실하지는 않습니다. 그렇다면 신뢰도가 낮은 기기에 있는 악성코드가 제 Synology NAS로 파일을 보내고, NAS가 그 파일을 자동으로 처리해서 썸네일 같은 걸 인덱싱하다가 코드 실행으로 이어질 수도 있지 않나요? 왜 ACL을 따르지 않는 건가요? 그리고 파일이 보내는 쪽 기기를 떠나기 전에 받는 쪽의 승인을 받도록 하지 않는 이유는 뭔가요? 저는 태그를 쓰지만, 제가 태그가 아니라 소유자입니다.