오늘 낮에 사내 네트워크가 눈에 띄게 느렸습니다. 처음엔 회선이나 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를 .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일에 43760 패치가 나왔고, 8월 6일에 65400 패치가 Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9로 나왔습니다. 8월 중순에 네덜란드 쪽에서 실제 악용 경고가 나오고 채굴기 얘기가 퍼졌고, 17일에 보안 항목이 스물몇 건 들어간 26.6.2가 나왔고, 그리고 오늘 사내에서 패치가 몰렸습니다.
8월 6일 업데이트는 취약점 하나만 고친 업데이트였습니다. 애플이 항목 하나짜리 릴리스를 낸다는 건 그만큼 급하다는 뜻인데, 그날 바로 몰리지는 않았습니다.
사람들이 실제로 받기 시작한 건 패치가 나와서가 아니라 실제로 공격당하고 있다는 뉴스가 나와서였던 것 같습니다. 이론적인 위험은 일정에 밀리고, 실제로 관측된 악용은 일정을 밀어냅니다. 어느 조직이든 대체로 그렇습니다. 패치 하나하나에 전사 대응을 걸면 일이 안 돌아가니까요. 애플만 해도 이번 달에 업데이트를 세 번 냈습니다. 그러니 순서를 정해야 하고, 실제로 악용되고 있느냐가 제일 강한 신호 중 하나가 됩니다. 미국 CISA가 악용이 확인된 취약점만 따로 목록으로 관리하는 것도 같은 이유일 겁니다.
그런데 그 신호가 언제 도착하느냐는 공격하는 쪽이 정합니다. 8월 6일부터 뉴스가 뜨기까지 열흘 남짓이 무방비였고, 그 기간을 정한 건 우리가 아니라 채굴기를 깔던 쪽이었습니다. 걔네가 조용히 했으면 그 기간은 더 길어졌을 겁니다.
탐지가 얼마나 늦는지 썼던 글이랑 같은 모양이 또 나옵니다. 얼마나 빨리 대응하느냐보다 언제 알아채느냐가 전체를 정하고, 알아채는 건 대개 남이 시켜줍니다.
17일에 나온 26.6.2는 보안 항목이 스물여덟 건인데, 웹킷이 스무 건이고 나머지는 커널, 이미지IO, 오디오, IOGPUFamily 같은 것들입니다. 화면 공유는 여기 없습니다. 화면 공유는 6일 26.6.1에서 끝난 얘기입니다.
그러면 오늘 사내에서 오간 트래픽 중 꽤 많은 부분이, 화면 공유 때문에 받는다고 생각하며 받은 26.6.2였을 수도 있습니다. 웹킷 스무 건도 받을 이유로는 충분합니다. 그래도 사람들이 무슨 이유로 받았는지와 실제로 뭘 받았는지가 어긋나 있으면, 다음에 비슷한 일이 왔을 때 판단이 흐려질 것 같습니다.
해커는 한 명도 안 왔는데 일이 멈췄습니다
오늘 실제로 손해가 난 건 이쪽이었습니다.
우리 회사에 누가 침입했다는 얘기는 없습니다. 채굴기가 심어졌다는 보고도 없습니다. 낮 시간에 일하던 사람들이 다 같이 느려졌을 뿐입니다. 파일이 늦게 열리고, 회의 도구가 끊기고, 빌드가 늘어졌습니다.
용량을 대충 세어보면 왜 그런지 나옵니다. 26.6.1이 애플 실리콘 기준 2GB 남짓이고, 26.6.2는 거기서 올라갈 때 애플 실리콘 기준 3GB 가까이 됩니다. 한 사람이 두 번 다 받았으면 5GB에 가깝습니다. 여기에 사람 수를 곱하면 되는데, 천 명이 평균 3GB씩만 받아도 3TB입니다. 그게 점심 전후 몇 시간에 몰리면 평균으로만 기가비트가 넘고, 피크는 그 몇 배로 뜁니다.
좀 허탈했던 건 이 문제의 해결책이 macOS 안에 이미 있다는 거였습니다.
콘텐츠 캐싱이라는 기능이 있습니다. 사내에 맥 한 대를 캐시로 정해두면 애플 소프트웨어 업데이트를 그 한 대가 받고, 나머지는 인터넷이 아니라 그 맥에서 받아갑니다. 설정에서 켜기만 하면 되고 같은 네트워크의 맥들이 알아서 찾아 씁니다. 수천 대가 각자 밖에 나가서 같은 3GB를 받는 걸 막으려고 있는 물건입니다. 이걸 알고 나니 오후 내내 느렸던 게 좀 억울해졌습니다.
생긴 건 어제 글에서 쓴 패키지 프록시 캐시랑 똑같습니다. 밖으로 나가는 통로를 하나로 모으고 나머지는 그 하나에서 가져갑니다. 아티팩토리가 거기 있었던 것도 그래서였습니다.
그러니 오늘 느려진 건 기술적으로 어쩔 수 없는 일은 아니었습니다. 캐시가 없었거나, 있는데 안 쓰였거나, 아무도 그 얘기를 안 꺼낸 겁니다. 급한 패치를 돌릴 때 대역폭 계획까지 같이 세우는 조직은 생각보다 드문 것 같습니다. 보안 공지랑 네트워크 운영이 다른 사람 손에 있고, 그 둘이 같은 회의에 안 들어가니까요.
이걸 뭐라고 불러야 할지가 좀 재밌었습니다. 보안 사고인가 하면 침입은 없었습니다. 장애인가 하면 고장 난 장비도 없었습니다. 그런데 서비스가 제대로 안 돌아간 시간은 분명히 있었습니다.
보안을 지키려는 행동이 가용성을 깎았습니다. 그리고 이건 어쩌다 한 번 있는 일이 아니라 꽤 규칙적으로 일어납니다. 긴급 패치, 인증서 일괄 교체, 백신 전체 검사, 강제 재부팅이 다 같은 모양입니다. 방어 조치는 늘 어딘가에서 자원을 쓰고, 그 자원은 대개 그 시간에 일하던 사람들 겁니다.
비용이 눈에 안 띄는 이유도 같습니다. 침해 사고는 보고서가 남고 숫자가 붙는데, 패치 때문에 오후 내내 느렸던 건 어디에도 안 남습니다. 각자 조금씩 손해 보고 아무도 청구서를 안 씁니다.
훨씬 큰 규모로 같은 성질의 일이 몇 년 전에 있었습니다. 판교 데이터센터 화재요. 그때도 해커는 없었습니다. 불이 났고 서버가 죽었고 전 국민이 며칠 불편했습니다. 그 화재가 태운 서버 중 하나가 나중에 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 이상이 됐는지 아는 사람이 있을까요. 외근 나간 사람, 저전력 모드로 미뤄둔 사람, 재부팅을 내일로 미룬 사람이 남습니다. 대상 목록이 없으면 완료 목록도 없습니다. 다들 받았겠지 하는 상태로 끝나고, 그 상태는 다음 취약점이 나올 때까지 아무도 확인하지 않습니다.
세는 쪽은 반대입니다. 화면 공유가 켜진 맥이 서른 대라고 나오면 그 서른 대가 다 처리됐는지 확인할 수 있습니다. 서른 대면 점심 먹기 전에 끝낼 수 있는 일입니다. 세는 비용을 내면 끝났는지 확인할 수 있게 되고, 안 세면 둘 다 없습니다.
세는 게 그렇게 어려운 일도 아닙니다. 자산 관리 도구가 있는 조직이면 화면 공유 서비스 상태는 조회할 수 있는 항목이고, 없어도 명령 한 줄이면 각자 확인할 수 있습니다.
그런데 이걸 아무도 안 물어봤습니다. 오늘 오간 메시지는 전부 업데이트하라는 거였고, 화면 공유 켜져 있는 사람 있냐는 말은 없었습니다. 그걸 먼저 물었으면 오늘 급하게 받아야 할 사람이 훨씬 적었을 거고, 나머지는 저녁에 받아도 됐을 겁니다.
패치 다음에
막는 쪽은 업데이트입니다. Tahoe는 26.6.1 이상, Sequoia는 15.7.9 이상, Sonoma는 14.8.9 이상이면 65400은 해결됩니다.
노출을 줄이는 건 그거랑 따로입니다. 화면 공유를 안 쓰면 끄면 됩니다. 설정의 일반 아래 공유에서 화면 공유를 끄면 되고, 터미널로 확인하려면 앞의 netstat 한 줄이면 됩니다. 끄고 나서 다시 조회했을 때 5900이 안 나오면 닫힌 겁니다.
어려운 건 저처럼 써야 하는 경우입니다. 대부분의 권고가 여기서 말이 없어집니다.
끄지 않고 할 수 있는 게 몇 가지 있긴 합니다. 방화벽은 켤 수 있습니다. 응용 프로그램 방화벽 상태는 socketfilterfw --getglobalstate로 보이는데, 저처럼 꺼져 있으면 켜는 게 거의 기본값이고, 켜면 어떤 연결을 받을지 물어보는 층이 하나 생깁니다. 어느 네트워크에서 받을지도 좁힐 수 있습니다. 집에서 붙는 용도면 회사 네트워크에 있을 때까지 열려 있을 이유가 없고, VPN을 거치게 하면 5900을 공용 구간에 안 내놓고도 같은 일을 할 수 있습니다. 안 쓰는 동안 꺼두는 것도 방법입니다. 원격 접속은 대개 특정 시간에만 필요하니까요. 그리고 제일 낮은 단계로는, 적어도 열려 있다는 걸 알고 있는 겁니다. 저는 오늘까지 그것도 못 하고 있었습니다.
탐지 쪽 얘기도 나와 있습니다. 헌트리스는 ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH 이벤트에서 인증 유형은 SRP인데 RSA-SRP 암호화가 없는 세션, 그리고 세션 사용자명이 root인 연결을 이상 신호로 보라고 했습니다. root 세션은 macOS에서 기본으로 꺼져 있으니 그 자체가 신호입니다. 프로세스 쪽으로는 SSFileCopySender가 UID/GID 0과 80으로 뜨는 게 초기 탐색의 흔적이라고 합니다.
이걸 다 보려면 엔드포인트 보안 이벤트를 모으고 있어야 합니다. 안 모으고 있으면 나중에 무슨 일이 있었는지 되짚을 방법이 없습니다. 제가 세워둔 감시 훅들이 넉 달 동안 한 번도 안 울렸던 걸 뒤늦게 안 적이 있는데, 그때 안 울리는 감시와 없는 감시가 화면에서는 똑같아 보인다는 걸 알았습니다. 여기도 그렇습니다. 오늘 이후 이 맥에 누가 붙었는지 저는 확인할 방법이 없습니다.
오늘 회사에서 일어난 일은 보안 사고가 아니었습니다. 아무도 털리지 않았습니다. 수천 대의 맥이 몇 GB짜리 파일을 동시에 받았고, 그동안 다른 일이 느려졌고, 그 대가로 9.8짜리 인증 우회가 닫혔습니다. 저는 이게 나쁜 거래는 아니었다고 봅니다. 채굴기가 깔리고 디스크가 통째로 읽히는 것보다 낮 몇 시간 느린 게 훨씬 낫습니다. 그래도 더 싸게 할 수는 있었습니다. 대상을 셌으면 됐고, 콘텐츠 캐싱을 켰으면 됐습니다. 둘 다 오늘 아침에 정할 수 있는 일이었지 새로 만들어야 하는 기술이 아니었습니다.
저한테 남은 건 좀 다른 겁니다. 오늘 패치 대열에 있었고, 끝냈고, 안전해졌다고 생각했습니다. 그 상태에서 명령 두 줄을 쳤더니 포트가 열려 있고 방화벽이 꺼져 있었습니다.
패치를 끝냈다는 느낌이랑 안전해졌다는 느낌이 붙어 있는 게 문제 같습니다. 앞의 건 오늘 확실히 일어났고, 뒤의 건 아무 근거 없이 따라왔습니다. 이 둘이 붙어 있으면 다음에도 똑같이 갈 겁니다. 뉴스가 뜨고, 급하게 받고, 네트워크가 느려지고, 끝났다고 생각하고, 그 상태로 몇 달이 갑니다.
제 경우 그 몇 달이 넉 달 반이었습니다. 켰다는 기억이 있으니 확인했다고 착각하기 쉬웠던 것 같습니다. 오늘에서야 명령을 쳐봤고, 결과가 생각했던 거랑 달라서 이 글을 쓰게 됐습니다. 화면 공유는 안 끌 겁니다. 방화벽은 켤 겁니다.
댓글
댓글 쓰기