CVSS 9.8 패치가 몰린 날 내 맥의 5900 포트

-

밝은 사무실 네트워크 캐비닛 문이 열려 있고 포트 하나에만 케이블이 꽂혀 있는 장면

오늘 낮에 사내 네트워크가 눈에 띄게 느렸습니다. 처음엔 회선이나 VPN 문제인가 싶어서 재접속을 몇 번 했습니다.

알고 보니 다들 macOS 보안 업데이트를 받고 있었습니다. 화면 공유 취약점 때문이었습니다. 회사 곳곳에서 같은 시간대에 같은 걸 받으니 그만큼 대역폭이 나간 겁니다. 원인을 알고 나니 오히려 좀 안심이 됐습니다. 장애가 아니라 다들 제때 고치고 있다는 뜻이니까요.

저도 받았습니다. 제 맥은 26.6.2가 됐고, 문제가 된 취약점은 이미 그 앞 버전에서 막혀 있었습니다. 여기까지는 잘 끝난 얘기입니다.

글을 쓰려고 자료를 뒤지다가 "화면 공유가 켜져 있는 시스템만 해당된다"는 문장을 읽었습니다. 제 맥은 켜져 있습니다. 원격에서 제어하려고 넉 달 전에 제가 켰습니다. 그건 알고 있었습니다.

몰랐던 건 그게 어디까지 열려 있는지였습니다. 5900이 모든 인터페이스에 열려 있었고, 방화벽은 꺼져 있었습니다.

무엇이 뚫렸는지부터

이번 건은 CVE-2026-65400입니다. macOS 화면 공유의 인증 우회이고, CVSS 점수가 9.8입니다. 10점 만점 척도에서 9.8은 거의 최상단입니다.

애플의 설명은 짧습니다. 네트워크상의 공격자가 유효한 자격증명 없이 화면 공유에 인증할 수 있으며, 인증 과정의 상태 관리를 개선해 해결했다는 겁니다. 이 한 줄만 보면 무슨 일인지 잘 안 그려집니다.

헌트리스가 공개한 분석을 보면 좀 더 구체적입니다. 화면 공유 데몬은 SRP라는 인증 프로토콜을 쓰는데, 그 구현에서 프레임 길이 검사기가 이전 상태의 성공 값을 그대로 반환하는 결함이 있었습니다. 인증이 끝나지도 않았는데 시스템이 "성공"이라고 읽습니다. 그 결과 연결이 인증된 것으로 취급됩니다.

여기서 한 가지가 더 붙습니다. 그렇게 통과한 연결은 암호화 없이 이어집니다. 평문 세션이 됩니다. 원래 SRP를 쓰는 이유 중 하나가 세션 키를 만드는 건데, 인증 단계를 건너뛰니 키를 만들 재료도 없습니다.

그다음이 진짜 문제입니다. 이 연결로 SSFileCopySender라는 헬퍼 프로세스에 닿을 수 있습니다. 화면 공유 중에 파일을 주고받으라고 있는 물건인데, 이 프로세스가 물려받는 권한이 kTCCServiceSystemPolicyAllFiles입니다. 전체 디스크 접근 권한이고, TCC를 통째로 우회합니다.

TCC는 맥에서 "이 앱이 사진 폴더에 접근하려 합니다" 같은 창을 띄우는 그 층입니다. 사용자가 허락하고 거절하는 지점이 전부 거기 있습니다. 그 층 뒤로 들어가면 사용자는 아무것도 못 봅니다.

전체 디스크 접근이 실제로 무엇을 여는지 생각해보면 범위가 꽤 넓습니다. 메일 로컬 저장소, 메시지 데이터베이스, 사진 라이브러리, 브라우저 프로필, 그리고 개발자 맥이라면 SSH 키와 클라우드 자격증명 파일이 전부 홈 디렉터리 아래 있습니다. 예전에 시크릿 스캔 훅을 걸어놨는데 AWS 키가 그냥 통과했던 일을 정리한 적이 있는데, 그때 확인한 게 키라는 게 얼마나 여러 군데 흩어져 있는지였습니다. 그 흩어진 것들이 한 번에 읽히는 상태가 전체 디스크 접근입니다.

SRP 자체는 나쁜 프로토콜이 아닙니다. 비밀번호를 네트워크로 보내지 않고도 양쪽이 같은 비밀번호를 아는지 확인하는 방식이고, 그 과정에서 세션 암호화에 쓸 키가 부산물로 만들어집니다. 설계는 튼튼합니다. 무너진 건 설계가 아니라 그걸 구현한 코드의 한 지점이었습니다. 프레임 길이를 검사하는 함수가 이전 호출의 결과값을 그대로 물고 있었습니다.

이런 종류의 결함이 특히 성가신 이유가 있습니다. 암호가 깨진 게 아니라 암호를 쓸지 말지 판단하는 코드가 잘못 답한 것이라, 밖에서 보면 정상 연결과 구분이 잘 안 됩니다. 애플이 수정 방식을 "상태 관리 개선"이라고 적은 것도 그래서입니다. 알고리즘을 바꾼 게 아니라 상태를 잘못 읽던 자리를 고쳤다는 뜻입니다.

실제 공격에서는 여기까지 가서 root를 얻고 채굴기를 심었습니다. 마이크로소프트가 관측한 걸 보면 XMRig 6.26.0을 .config/sysmond라는 이름으로 숨기고, com.apple.airportd를 사칭하고, KeepAlive 옵션을 켠 런치데몬으로 재시작에도 살아남게 만들었습니다. 네덜란드 국가사이버보안센터는 인터넷에서 5900 포트에 닿을 수 있는 여러 시스템에서 실제 악용을 확인했다고 경고했습니다.

설정을 잠가도 안 되는 종류였습니다

이 취약점에서 제일 불편한 대목은 따로 있습니다.

헌트리스 분석에 이런 문장이 있습니다. 허용 사용자 계정을 지우거나 VNC 비밀번호 인증을 끄는 것 같은 개별 화면 공유 설정은 이 버그의 성공 여부에 영향을 주지 않는다는 겁니다.

이게 왜 서늘하냐면, 우리가 보안 설정을 잠글 때 실제로 하는 일의 대부분이 그 아래에 있기 때문입니다. 접근을 허용할 계정을 고르는 것도, 비밀번호를 어떻게 검증할지 정하는 것도, 전부 "인증을 통과한 다음"에 적용되는 규칙입니다. 인증 자체가 우회되면 그 규칙들은 실행되지 않습니다. 문 안쪽에 걸어둔 자물쇠는 문을 안 열고 들어온 사람에게 아무 의미가 없습니다.

제 맥에서 확인해봤습니다.

$ defaults read /Library/Preferences/com.apple.RemoteManagement
{
    AllowSRPForNetworkNodes = 0;
    DisableKerberos = 0;
}

AllowSRPForNetworkNodes = 0입니다. 네트워크 노드에 SRP를 허용하지 않는다는 뜻입니다. 이 값만 보면 SRP 경로가 닫혀 있는 것처럼 읽힙니다. 이번 버그는 정확히 그 설정 바깥에서 났습니다.

설정값을 보고 안심하는 습관이 여기서 깨집니다. 설정은 "이 기능을 어떻게 쓸지"를 정하는 것이고, 취약점은 "그 기능이 어떻게 잘못 동작하는지"의 문제입니다. 앞의 것으로 뒤의 것을 막을 수 없는 경우가 있고, 이번이 그런 경우였습니다.

이 구분이 실무에서 중요한 이유는 우리가 보안 점검을 할 때 보는 게 거의 다 앞쪽이기 때문입니다. 체크리스트를 돌리면 나오는 항목들이 대체로 그렇습니다. 비밀번호 정책이 걸려 있는가, 허용 계정이 최소인가, 암호화가 켜져 있는가. 전부 설정값이고, 전부 기능이 정상 동작한다는 전제 위에 있습니다.

그 전제가 깨지는 종류의 결함에 대해서는 설정 점검이 아무 신호도 주지 않습니다. 오히려 반대로 작동합니다. 항목이 전부 초록색이면 점검을 마쳤다고 기록되고, 그 기록이 다음 점검까지의 안심 근거가 됩니다.

그래서 설정을 잠그는 것과 노출을 줄이는 것은 다른 일입니다. 앞의 것은 기능을 어떻게 쓸지 정하고, 뒤의 것은 그 기능이 애초에 켜져 있어야 하는지를 묻습니다. 이번 건에서 실제로 효과가 있었던 건 뒤쪽뿐입니다. 화면 공유를 안 켠 맥은 설정을 어떻게 해뒀든 상관없이 무사했습니다.

7월 27일에 이미 한 번 고쳤습니다

이 건에는 앞 이야기가 있습니다.

CVE-2026-43760이 7월 27일 업데이트에 들어갔습니다. 레거시 VNC 인증 경로의 혼동된 대리자 문제였습니다. 이쪽은 인증이 필요했습니다. VNC 자격증명을 가진 사용자가 root 권한으로 파일을 읽고 만들 수 있게 되는 결함이었고, 대상 프로세스는 같은 SSFileCopySender와 SSFileCopyReceiver였습니다.

열흘 뒤에 65400이 나왔습니다. 목적지가 같습니다. 같은 헬퍼 프로세스, 같은 전체 디스크 접근입니다. 다른 건 가는 길입니다. 43760은 인증을 통과한 뒤에 쓰는 길이고, 65400은 인증이 아예 필요 없는 길입니다.

헌트리스는 이 둘이 순차적으로 이어지는 체인이 아니라 같은 특권 파일 작업으로 가는 두 개의 별도 경로라고 정리했습니다.

문이 두 개인 이유를 생각해보면 구조가 보입니다. 화면 공유는 오래된 기능이고, 그동안 인증 방식이 여러 번 바뀌었습니다. 옛날 VNC 방식이 있고, 애플이 나중에 만든 방식이 있습니다. 호환을 위해 옛것을 지우지 않고 남겨두면 인증 경로가 둘이 됩니다. 그 뒤에 있는 방은 하나입니다.

이런 모양은 아주 흔합니다. 레거시 인증을 남겨둔 API, 예전 토큰 형식을 계속 받아주는 게이트웨이, 구버전 클라이언트를 위해 살려둔 엔드포인트가 전부 같습니다. 뒷방을 튼튼하게 지켰는지가 아니라 그 방으로 들어오는 문이 몇 개인지가 실제 공격 표면이고, 문 개수를 정확히 아는 사람은 대개 없습니다.

이 모양을 어제 망분리 글에서도 봤고, 그 앞 아티팩토리 글에서도 봤습니다. 파일 쓰기를 막으니 폴더 이름으로 썼고, 랜선을 막으니 테더링이 남았습니다. 여기서는 인증 후 경로를 막으니 인증 전 경로가 나왔습니다.

경로를 하나씩 지우는 방식이 왜 항상 뒤처지는지가 이 세 사건에서 같은 모양으로 반복됩니다. 지워야 할 경로의 목록을 완전하게 쓸 수 있다는 가정 위에서만 그 방식이 성립하는데, 그 목록을 다 쓴 사람이 아무도 없습니다. 애플도 열흘 간격으로 두 번 썼습니다.

왜 하필 오늘이었나

여기서 좀 이상한 게 있습니다. 패치는 8월 6일에 나왔습니다. 오늘은 19일입니다. 열사흘 차이입니다.

날짜를 늘어놓으면 이렇게 됩니다.

날짜 무슨 일
7월 27일 CVE-2026-43760 패치 (Tahoe 26.6, Sequoia 15.7.8, Sonoma 14.8.8)
8월 6일 CVE-2026-65400 패치 (Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9)
8월 중순 네덜란드 NCSC가 실제 악용 경고. 채굴기 설치 관측
8월 17일 Tahoe 26.6.2. 보안 항목 28건
8월 19일 사내에서 패치가 몰림

8월 6일 업데이트는 취약점 하나만 고친 업데이트였습니다. 애플이 단일 항목으로 릴리스를 낸다는 건 그만큼 급하다는 신호인데, 그날 곧바로 몰리지는 않았습니다.

움직이게 만든 건 패치가 나왔다는 사실이 아니라 실제로 뚫리고 있다는 뉴스였습니다. 이론적 위험은 일정에 밀리고, 관측된 악용은 일정을 밀어냅니다. 어느 조직이든 대체로 그렇습니다.

이 비대칭은 사실 합리적인 구석이 있습니다. 패치 하나하나에 전사 대응을 걸면 업무가 안 돌아갑니다. 애플만 해도 이번 달에 세 번 업데이트를 냈습니다. 그러니 우선순위를 매겨야 하고, "실제로 악용되고 있는가"는 그 우선순위에서 가장 강한 신호 중 하나입니다. 미국 CISA가 아예 악용이 확인된 취약점만 따로 목록으로 관리하는 것도 같은 이유입니다.

문제는 그 신호가 도착하는 시점이 공격자의 일정에 달려 있다는 겁니다. 8월 6일부터 뉴스가 뜨기까지의 그 열흘 남짓이 무방비 구간이었고, 그 구간의 길이를 정한 건 우리가 아니라 채굴기를 깔던 쪽이었습니다. 조용히 했으면 그 구간은 더 길어졌을 겁니다.

여기서도 탐지가 얼마나 늦는지 얘기와 같은 구조가 나옵니다. 대응 속도가 아니라 인지 시점이 전체를 결정합니다. 그리고 인지는 대개 남이 시켜줍니다.

한 가지 짚어둘 게 있습니다. 8월 17일에 나온 26.6.2는 보안 항목이 스물여덟 건인데 그 구성이 웹킷 스무 건, 커널 세 건, 이미지IO 두 건, 오디오와 IOGPUFamily 각각 한 건 식입니다. 화면 공유는 여기 없습니다. 화면 공유는 8월 6일 26.6.1에서 이미 끝난 얘기입니다.

그러니까 오늘 사내에서 오간 트래픽 중 상당 부분은 "화면 공유 때문에" 받는다고 생각하며 받은 26.6.2일 가능성이 있습니다. 물론 웹킷 스무 건도 받아야 할 이유로 충분합니다. 다만 사람들이 어떤 이유로 움직였는지와 실제로 무엇을 받았는지가 어긋나 있었다면, 그건 다음번에 같은 상황이 왔을 때 판단을 흐립니다.

해커는 한 명도 안 왔는데 가용성이 깨졌습니다

오늘 실제로 손해가 난 지점을 보겠습니다.

우리 회사에 침입자가 들어왔다는 얘기는 없습니다. 채굴기가 심어졌다는 보고도 없습니다. 낮 시간에 일하던 사람들이 다 같이 느려졌습니다. 파일이 늦게 열리고, 회의 도구가 끊기고, 빌드가 늘어졌습니다.

용량을 대충 세어보면 왜 그런지 나옵니다. 26.6.1이 애플 실리콘 기준 2.1GB쯤이고, Sequoia 15.7.9는 4.2GB쯤입니다. 26.6.2는 26.6.1에서 올라갈 때 애플 실리콘 2.89GB, 인텔 1.27GB입니다. 한 사람이 두 번 다 받았으면 5GB에 가깝습니다.

여기에 사람 수를 곱하면 됩니다. 1,000명이 평균 3GB씩만 받아도 3TB입니다. 그게 점심 전후 네 시간에 몰리면 평균으로만 1.7Gbps고, 피크는 그 몇 배로 뜁니다. 실제 수치를 재본 건 아니니 어림이지만, 자릿수는 이 근처입니다.

여기서 좀 허탈한 대목이 있습니다. 이 문제는 이미 해결책이 macOS 안에 들어 있습니다.

콘텐츠 캐싱이라는 기능이 있습니다. 사내에 맥 한 대를 캐시로 지정해두면 애플 소프트웨어 업데이트를 그 한 대가 받고, 나머지는 인터넷이 아니라 그 맥에서 받아갑니다. 설정에서 켜기만 하면 되고, 같은 네트워크의 맥들이 알아서 찾아 씁니다. 수천 대가 각자 밖으로 나가서 같은 3GB를 받는 상황을 막으려고 있는 물건입니다.

구조를 보면 어제 글에서 다룬 패키지 프록시 캐시와 정확히 같은 모양입니다. 밖에 나가는 통로를 하나로 모으고 나머지는 그 하나에서 가져갑니다. 아티팩토리도 그래서 거기 있었습니다.

그러니 오늘 느려진 건 기술적으로 불가피한 일이 아니었습니다. 캐시가 없었거나, 있는데 안 쓰였거나, 아무도 그 얘기를 안 꺼낸 겁니다. 급한 패치를 돌릴 때 대역폭 계획까지 같이 세우는 조직은 생각보다 드뭅니다. 보안 공지와 네트워크 운영이 다른 사람 손에 있고, 둘이 같은 회의에 안 들어가기 때문입니다.

이 사건을 어떻게 분류할지가 좀 재밌습니다. 보안 사고인가요? 침입은 없었습니다. 장애인가요? 고장 난 장비는 없었습니다. 그런데 서비스가 정상적으로 안 돌아간 시간이 실재했습니다.

보안을 지키는 행동이 가용성을 깎았습니다. 그리고 이건 예외적인 일이 아니라 규칙적으로 일어나는 일입니다. 긴급 패치, 인증서 일괄 교체, 백신 전체 검사, 강제 재부팅이 전부 같은 모양입니다. 방어 조치는 항상 어딘가에서 자원을 쓰고, 그 자원은 대개 그 시간에 일하던 사람들의 것입니다.

비용이 눈에 안 띄는 이유도 같습니다. 침해 사고는 보고서가 남고 숫자가 붙는데, 패치 때문에 오후 내내 느렸던 건 아무 데도 기록되지 않습니다. 각자 조금씩 손해를 보고 아무도 청구서를 쓰지 않습니다.

4년 전에 훨씬 큰 규모로 같은 성질의 사건이 있었습니다. 2022년 10월 판교 데이터센터 화재입니다. 그때도 해커는 없었습니다. 불이 났고 서버가 죽었고 전 국민이 며칠 불편했습니다. 그 화재가 태운 서버 중 하나가 나중에 40개월 은폐로 드러난 그 침해 사건의 물건이기도 한데, 화재 자체는 순수한 가용성 사고였습니다.

보안을 침입 차단으로만 좁히면 이 두 사건이 다 밖으로 밀려납니다. 사용자 입장에서 "서비스를 못 썼다"는 결과는 완전히 같습니다.

제 맥을 실제로 열어봤습니다

여기까지는 남 얘기입니다. 제 것을 봤더니 다른 게 나왔습니다.

$ sw_vers
ProductVersion:     26.6.2
BuildVersion:       25G83

$ launchctl list | grep -i screensharing
-   0   com.apple.screensharing.agent
-   0   com.apple.screensharing.menuextra
-   0   com.apple.screensharing.MessagesAgent

$ netstat -an | grep 5900
tcp4       0      0  *.5900                 *.*                    LISTEN
tcp6       0      0  *.5900                 *.*                    LISTEN

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)

버전은 26.6.2입니다. 패치는 됐습니다. 65400은 26.6.1에서 막혔으니 이 맥은 그 취약점에 안 걸립니다.

그런데 5900 포트가 모든 인터페이스에 열려 있습니다. *.5900의 별표가 그 뜻입니다. 특정 주소에만 바인딩된 게 아니라 이 맥이 붙어 있는 모든 네트워크에서 닿습니다. 화면 공유 관련 프로세스도 세 개 돌고 있습니다. 그리고 응용 프로그램 방화벽은 꺼져 있습니다.

언제부터 이랬는지 찾아봤습니다.

$ ls -lT /Library/Preferences/com.apple.RemoteManagement.plist
-rw-r--r--@ 1 root  wheel  96 Apr  1 21:54:02 2026

4월 1일 밤 9시 54분입니다. 원격 관리 설정 파일이 마지막으로 쓰인 시각이고, 화면 공유를 켠 시점으로 보면 맞습니다. 오늘까지 넉 달 반입니다.

회사가 민 설정인지도 확인해봤습니다.

$ profiles status -type enrollment
Enrolled via DEP: No
MDM enrollment: No

$ profiles -L
There are no configuration profiles installed

아닙니다. MDM에 등록돼 있지 않고 구성 프로파일도 없습니다. 그 시각에 바뀐 파일도 com.apple.RemoteManagement.plist 하나뿐이라 다른 게 건드린 흔적이 없습니다. 제가 켠 겁니다.

기억도 납니다. 원격에서 이 맥을 제어하려고 켰습니다. 지금도 그 용도로 씁니다.

이 글이 여기서 흔한 실수담이 될 뻔했습니다. "켜놓고 잊었다"로 쓰면 교훈이 깔끔하게 떨어집니다. 끄면 되니까요.

사실이 아닙니다. 저는 이 기능이 필요하고, 끌 생각이 없습니다. 그러면 답이 "끄세요"인 조언은 저한테 아무 소용이 없고, 화면 공유를 실제로 쓰는 다른 사람들에게도 마찬가지입니다.

여기서 더 뼈아픈 게 하나 나왔습니다.

$ ls -l /Library/Preferences/com.apple.VNCSettings.txt
ls: No such file or directory

VNC 비밀번호 파일이 없습니다. 레거시 VNC 인증을 설정하지 않았다는 뜻입니다. 저는 화면 공유를 켜면서 비밀번호 방식은 안 쓴 것이고, 그건 보안적으로 더 나은 선택이었습니다. 실제로 7월 27일에 나온 43760은 VNC 자격증명이 있어야 성립하는 결함이라 제 맥은 애초에 해당이 없었습니다.

그 신중함이 8월 6일 건에는 하나도 도움이 안 됐습니다. 65400은 자격증명을 요구하지 않으니까요. 앞서 인용한 그 문장이 여기서 실물이 됩니다. 개별 화면 공유 설정은 이 버그의 성공 여부에 영향을 주지 않는다. 제가 잠근 자물쇠가 정확히 그 "개별 설정"이었습니다.

한 가지 더 눈에 걸린 게 있습니다.

$ ls -lTd /Library/Application\ Support/Apple/Remote\ Desktop
drwxr-xr-x  3 root  wheel  96 Aug 19 14:34:52 2026

오늘 오후 2시 34분입니다. 원격 데스크톱 관련 디렉터리가 오늘 낮에 건드려졌습니다. 네트워크가 느려졌다고 느낀 게 딱 그 시간대입니다. 남의 얘기인 줄 알았던 패치 물결 안에 제 맥도 있었습니다.

여기서 오늘 한 일이 무엇이었는지가 정확해집니다. 패치는 취약점을 막았지 노출을 줄이지 않았습니다. 65400은 닫혔습니다. 화면 공유 서비스는 여전히 켜져 있고, 포트는 여전히 열려 있고, 방화벽은 여전히 꺼져 있습니다. 다음 취약점이 나오면 저는 다시 같은 자리에 서 있습니다.

그리고 제가 진짜로 몰랐던 건 켜져 있다는 사실이 아니었습니다. 어디까지 열려 있는지였습니다.

제가 켠 건 "원격에서 내가 이 맥에 접속한다"였습니다. 실제로 켜진 건 "이 맥이 붙은 모든 네트워크에서 5900으로 누구나 말을 걸 수 있다"였습니다. 이 둘은 같은 스위치에 묶여 있습니다. 설정에서 체크박스 하나를 켜면 전 인터페이스에 바인딩됩니다. 어느 네트워크에서 받을지, 누구한테서 받을지는 그 스위치가 묻지 않습니다.

기능을 켜는 결정과 노출 범위를 정하는 결정은 원래 별개인데, 대부분의 운영체제 설정이 그 둘을 하나로 합쳐놨습니다. 그래서 쓰겠다고 결정한 사람은 노출 범위까지 자동으로 결정한 셈이 되고, 자기가 그런 결정을 했다는 자각이 없습니다. 저도 넉 달 반 동안 없었습니다.

인터넷에 직접 노출된 건 아닙니다. 회사 네트워크 안입니다. 어제 글에서 20년치로 정리한 게 정확히 "내부망이니까 괜찮다"는 문장이 어떻게 관리를 멈추게 하는지였습니다. 그 글을 쓴 다음 날 제 맥에서 그 문장의 실물이 나왔습니다. 4만 대 규모로 관측된다는 인터넷 노출 호스트들도 대부분 이 경로로 만들어졌을 겁니다. 누가 악의로 연 게 아니라, 쓰려고 켰고 범위는 안 물어봤을 뿐입니다.

목록이 없으면 전량 대응이 기본값이 됩니다

오늘 벌어진 일을 조금 떨어져서 보면 이런 구조입니다.

화면 공유는 macOS에서 기본으로 켜지는 기능이 아닙니다. 누군가 의도적으로 켠 맥만 해당됩니다. 그러면 실제 대상은 전체의 일부입니다. 이론적으로는 그 일부만 골라서 먼저 처리하면 됩니다.

어느 맥에서 화면 공유가 켜져 있는지 아는 사람이 없습니다. 저조차 제 것을 몰랐습니다. 그러니 답은 하나로 수렴합니다. 전부 패치합니다.

전량 대응은 안전한 선택입니다. 대상을 못 세도 되니까요. 그리고 비용은 대역폭으로 나갑니다.

이건 어제 망분리 글에서 본 것과 같은 저울입니다. 거기서는 개인정보를 다운로드할 수 있는 사람이 누군지 세는 것보다 전 직원 인터넷을 끊는 게 쌌습니다. 여기서는 화면 공유가 켜진 맥을 세는 것보다 전량을 받게 하는 게 쌉니다. 두 경우 다 목록을 안 쓴 자리에 광범위한 조치가 들어섰고, 그 조치는 목록보다 싸 보이지만 매번 값을 치릅니다.

차이가 있다면 이번 값은 하루치라 눈에 띄었다는 겁니다. 망분리 쪽 값은 20년에 걸쳐 나눠 냈기 때문에 아무도 청구서를 못 봤습니다.

여기서 짚을 게 하나 더 있습니다. 전량 대응이 안전해 보이는 건 대상을 못 세도 되기 때문인데, 그 대신 끝났는지도 알 수 없게 됩니다.

오늘 사내 맥이 몇 대나 실제로 26.6.1 이상이 됐는지 누가 아나요. 자리를 비운 사람, 저전력 모드로 미룬 사람, 재부팅을 내일로 미룬 사람이 남습니다. 대상 목록이 없으면 완료 목록도 없습니다. "다들 받았을 것"이라는 상태로 끝나고, 그 상태는 다음 취약점이 나올 때까지 검증되지 않습니다.

목록을 세는 쪽은 이게 반대입니다. 화면 공유가 켜진 맥이 서른 대라고 나오면, 그 서른 대가 다 처리됐는지 확인할 수 있습니다. 세는 비용을 내면 완료를 확인할 권리가 따라옵니다. 안 세면 둘 다 없습니다.

세는 게 그렇게 어려운 일도 아닙니다. 자산 관리 도구가 있는 조직이면 화면 공유 서비스 상태는 조회 가능한 항목입니다. 없어도 명령 한 줄이면 각자 확인합니다.

netstat -an | grep 5900

문제는 이걸 아무도 안 물어봤다는 겁니다. 오늘 오간 메시지는 전부 "업데이트하세요"였고, "화면 공유 켜져 있는 사람?"은 없었습니다. 후자를 먼저 물었으면 오늘 급하게 받아야 할 사람이 훨씬 적었을 것이고, 나머지는 저녁에 받아도 됐습니다.

패치 다음에 해야 하는 것

이번 건에서 조치는 두 갈래입니다. 그리고 대부분의 조직이 앞의 것만 합니다.

취약점을 막는 쪽은 업데이트입니다. Tahoe는 26.6.1 이상, Sequoia는 15.7.9 이상, Sonoma는 14.8.9 이상이면 65400은 해결됩니다. 취약한 건 26.5.2 이하, 15.7.7 이하, 14.8.7 이하입니다.

노출을 줄이는 쪽은 별개입니다. 화면 공유를 안 쓰면 끕니다. 설정의 일반 항목 아래 공유에서 화면 공유를 끄면 되고, 터미널로 확인하려면 앞의 netstat 한 줄이면 충분합니다. 끈 다음 다시 조회했을 때 5900이 안 나오면 닫힌 겁니다.

문제는 저처럼 써야 하는 경우입니다. 여기가 실제로 어려운 자리이고, 대부분의 권고가 여기서 말이 없어집니다.

끄지 않고 할 수 있는 게 몇 가지 있습니다.

  • 방화벽을 켭니다. 응용 프로그램 방화벽 상태는 socketfilterfw --getglobalstate로 보입니다. 제 경우처럼 꺼져 있으면 켜는 게 기본값에 가깝고, 켜면 어떤 연결을 받을지 물어보는 층이 하나 생깁니다
  • 어느 네트워크에서 받을지 좁힙니다. 집에서 붙는 용도면 회사 네트워크에 있을 때까지 열려 있을 이유가 없습니다. VPN을 경유하게 하면 5900을 공용 구간에 노출하지 않고도 같은 일을 합니다
  • 안 쓰는 동안 끕니다. 원격 접속은 대개 특정 시간대에만 필요합니다. 상시로 켜둘 이유가 있는지는 따로 판단할 문제입니다
  • 최소한 열려 있다는 걸 알고 있습니다. 이게 제일 낮은 단계인데, 저는 오늘까지 이것도 못 하고 있었습니다

인터넷에 열린 화면 공유 호스트가 4만 대 규모로 관측된다는 보고가 있습니다. 그중 상당수는 누가 일부러 공개한 게 아니라 쓰려고 켠 것이고, 범위를 정하는 화면이 따로 없어서 그렇게 된 것들일 가능성이 높습니다. 제 맥이 사내망에서 그랬던 것과 같은 이유입니다.

탐지 쪽도 항목이 나와 있습니다. 헌트리스는 ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH 이벤트에서 인증 유형이 SRP인데 RSA-SRP 암호화가 없는 세션, 그리고 세션 사용자명이 root인 연결을 이상 신호로 보라고 정리했습니다. root 세션은 macOS에서 기본적으로 비활성이라 그 자체가 신호입니다. 프로세스 쪽으로는 SSFileCopySender가 UID/GID 0과 80으로 뜨는 게 초기 탐색의 흔적입니다.

이걸 다 보려면 엔드포인트 보안 이벤트를 수집하고 있어야 합니다. 안 하고 있으면 나중에 무슨 일이 있었는지 되짚을 방법이 없습니다. 제가 세워둔 감시 훅들이 넉 달간 한 번도 발화하지 않았던 것을 뒤늦게 안 적이 있는데, 그때 배운 건 안 울리는 감시와 없는 감시가 화면상 같아 보인다는 것이었습니다. 여기도 같습니다. 오늘 이후 이 맥에 누가 붙었는지 저는 확인할 방법이 없습니다.

정확히 말하면 오늘 회사에서 일어난 일은 보안 사고가 아니었습니다. 아무도 안 뚫렸습니다.

일어난 일은 이렇습니다. 수천 대의 맥이 몇 GB짜리 파일을 동시에 받았고, 그동안 다른 일이 느려졌고, 그 대가로 CVSS 9.8짜리 인증 우회가 닫혔습니다. 이건 좋은 거래입니다. 채굴기가 깔리고 전체 디스크가 열리는 것보다 낮 몇 시간 느린 게 훨씬 낫습니다.

다만 그 거래를 더 싸게 할 수 있었습니다. 대상을 셌으면 됐고, 콘텐츠 캐싱을 켰으면 됐습니다. 둘 다 오늘 아침에 결정할 수 있는 일이었지 새로 만들어야 하는 기술이 아니었습니다.

저 개인에게 남은 건 다른 것입니다. 저는 오늘 패치 대열에 있었고, 끝냈고, 안전해졌다고 생각했습니다. 그 상태에서 명령 두 줄을 쳤더니 포트가 열려 있고 방화벽이 꺼져 있었습니다. 패치는 이번 구멍을 막은 것이지 제 맥의 노출 면적을 줄인 게 아니었습니다.

패치를 끝냈다는 감각과 안전해졌다는 감각이 붙어 있는 게 문제입니다. 앞의 것은 오늘 확실히 일어났고, 뒤의 것은 오늘 아무 근거 없이 따라왔습니다.

이 둘이 붙어 있으면 다음번에도 같은 순서로 갑니다. 뉴스가 뜨고, 급하게 받고, 네트워크가 느려지고, 끝났다고 생각하고, 그 상태로 몇 달이 지납니다.

제 경우 그 몇 달이 넉 달 반이었습니다. 그동안 몰랐던 건 화면 공유가 켜져 있다는 사실이 아닙니다. 그건 제가 켰고 알고 있었습니다. 몰랐던 건 그게 어느 범위까지 열려 있는지, 그리고 방화벽이 꺼진 채였다는 겁니다. 켰다는 기억이 있으면 확인했다고 착각하기 쉽습니다.

떼어놓는 방법은 하나뿐입니다. 열어보는 겁니다. 명령 한 줄이면 됩니다. 저는 오늘에서야 쳐봤고, 이 글은 그 결과가 예상과 달라서 쓰게 됐습니다. 화면 공유는 안 끕니다. 방화벽은 켤 겁니다.

참고 자료: 헌트리스 기술 분석 — CVE-2026-43760과 CVE-2026-65400 · The Hacker News 보도 · Malwarebytes 경고 · SecurityWeek 보도 · 애플 보안 업데이트 안내 (macOS Sequoia 15.7.9)

댓글

댓글 쓰기