macOS 화면 공유 취약점 패치가 몰린 낮에 사내 네트워크가 느려졌다. 정작 내 맥은 5900 포트가 그대로 열려 있었다
macOS 화면 공유 취약점 패치가 몰린 낮에 사내 네트워크가 느려졌다. 정작 내 맥은 5900 포트가 그대로 열려 있었다 오늘 낮에 사내 네트워크가 눈에 띄게 느렸다. 처음엔 회선이나 VPN 문제인가 싶어서 재접속을 몇 번 했다. 알고 보니 다들 macOS 보안 업데이트를 받고 있었다. 화면 공유 취약점 때문이었다. 회사 공동체 곳곳에서 같은 시간대에 같은 걸 받으니 그만큼 대역폭이 나간 것이다. 원인을 알고 나니 오히려 좀 안심이 됐다. 장애가 아니라 다들 제때 고치고 있다는 뜻이니까. 나도 받았다. 내 맥은 26.6.2가 됐고, 문제가 된 취약점은 이미 그 앞 버전에서 막혀 있었다. 여기까지는 잘 끝난 얘기다. 그런데 글을 쓰려고 자료를 뒤지다가 "화면 공유가 켜져 있는 시스템만 해당된다"는 문장을 읽었다. 내 맥은 켜져 있다. 원격에서 제어하려고 넉 달 전에 내가 켰다. 그건 알고 있었다. 몰랐던 건 그게 어디까지 열려 있는지였다. 5900이 모든 인터페이스에 열려 있었고, 방화벽은 꺼져 있었다. 무엇이 뚫렸는지부터 이번 건은 CVE-2026-65400 이다. macOS 화면 공유의 인증 우회이고, CVSS 점수가 9.8이다. 10점 만점 척도에서 9.8은 거의 최상단이다. 애플의 설명은 짧다. 네트워크상의 공격자가 유효한 자격증명 없이 화면 공유에 인증할 수 있으며, 인증 과정의 상태 관리를 개선해 해결했다는 것이다. 이 한 줄만 보면 무슨 일인지 잘 안 그려진다. 헌트리스가 공개한 분석을 보면 좀 더 구체적이다. 화면 공유 데몬은 SRP라는 인증 프로토콜을 쓰는데, 그 구현에서 프레임 길이 검사기가 이전 상태의 성공 값을 그대로 반환하는 결함이 있었다. 인증이 끝나지도 않았는데 시스템이 "성공"이라고 읽는다. 그 결과 연결이 인증된 것으로 취급된다. 여기서 한 가지가 더 붙는다. 그렇게 통과한 연결은 암호화 없이 이어진다. 평문 세션이 된다. 원래 SRP를 쓰는 이유 중 하나가 세션 키를 만드...