https://blog.calif.io/p/no-country-for-old-passwords
2026.8.11
[No Country for Old Passwords; Two pre-auth macOS remote root exploits in four hours]
최근 애플이 배포한 긴급 보안 업데이트는 맥 화면 공유 기능에 존재하던 치명적인 원격 제어 취약점을 해결하기 위한 것이었으며, 보안 전문가들이 이를 분석하는 과정에서 인공지능의 발전이 소프트웨어 보안에 미치는 영향이 적나라하게 드러났습니다. 연구원들은 애플이 패치한 바이너리를 역설계하여 인증 절차를 완전히 우회하고 관리자 권한을 탈취할 수 있는 공격 도구를 단 몇 시간 만에 만들어냈으며, 이 과정에서 AI 도구가 취약점을 발견하고 악성 코드로 전환하는 속도를 가속화하고 있음이 입증되었습니다. 결과적으로 이 사건은 소프트웨어가 수정된 직후 곧바로 해킹 무기로 돌변하는 위험한 시대를 경고하며, 사용자들에게 신속한 업데이트와 함께 불필요한 원격 서비스의 차단을 강력히 권고하고 있습니다.

핵심 메시지: 이 글은 비밀번호의 강도가 아니라 인증을 수행하는 소프트웨어의 논리적 결함이 원격 시스템 전체의 보안을 무너뜨릴 수 있음을 보여줍니다. 동시에 AI를 활용한 패치 분석이 공격 재현 시간을 줄이면서, 방어자가 패치를 배포할 수 있는 시간적 여유도 줄어들고 있다는 문제를 제기합니다.
원문은 2026년 8월 10일 Calif가 공개한 보안 연구 사례입니다. 실제 구성은 도입부와 4개 본문 챕터이며, 아래에서는 그 순서를 그대로 따릅니다. 원문 내용과 분석적 해석을 구분하고, 주요 인증 취약점은 Apple 공식 보안 공지와 교차 확인했습니다.[1][2]
1. 도입부 — 비밀번호를 모르는데도 원격으로 접속할 수 있다
1.1 원문의 핵심 내용
Apple은 2026년 8월 6일 macOS의 Screen Sharing 기능에 대한 긴급 업데이트를 배포했습니다. Calif는 업데이트 전후의 차이를 역분석하여, 수정된 취약점을 이용하는 작동 가능한 공격을 만들었다고 설명합니다.[1]
Screen Sharing은 다른 컴퓨터에서 Mac의 화면을 보고 조작하는 정상적인 원격접속 기능입니다. 하지만 취약한 구현에서는 네트워크로 서비스에 접근할 수 있는 공격자가 유효한 비밀번호 없이 인증을 통과할 수 있었습니다.[1]
Apple 공식 공지도 CVE-2026-65400의 영향을 다음과 같이 명시합니다.
네트워크상의 공격자가 유효한 자격증명 없이 Screen Sharing에 인증할 수 있음.[2]
Calif는 여기에 더해, 해당 연결을 처리하는 screensharingd가 root 권한으로 실행되므로 영향이 특정 사용자의 화면 접근에 그치지 않고 시스템 전체 침해로 확장될 수 있다고 설명합니다.[1]
1.2 기술적으로 중요한 구분
| 개념 | 의미 | 이 사례에서의 중요성 |
| Pre-auth 취약점 | 정상적인 인증을 완료하기 전에 악용 가능 | 비밀번호를 확보하지 않아도 공격 경로에 진입 |
| 인증 우회 | 자격증명이 유효하지 않아도 인증된 상태로 전환 | 비밀번호 복잡도만으로는 방어할 수 없음 |
| 원격 root 영향 | 네트워크 공격이 최고 권한의 작업으로 이어질 수 있음 | 사용자 계정 차원을 넘어 시스템 전체가 위험 |
| 서비스 노출 | 공격자가 해당 서비스에 네트워크로 접근 가능 | Screen Sharing 활성화와 접근 경로가 핵심 조건 |
분석: 이 글의 제목을 “이제 비밀번호는 쓸모없다”로 읽으면 과도한 일반화입니다. 더 정확한 해석은 다음과 같습니다.
비밀번호가 강하더라도, 비밀번호 검증 절차 자체를 우회할 수 있으면 그 강도는 해당 공격을 막지 못한다.
따라서 이 사례의 핵심 방어 지점은 비밀번호 변경보다 취약한 인증 구현의 수정과 원격접속 경로의 제한입니다.
1.3 근거와 한계
원문은 한 연구자의 스캔에서 인터넷으로 접근 가능한 Screen Sharing 호스트가 약 4만 대 발견됐다고 인용합니다.[1]
그러나 이 수치를 곧바로 “4만 대가 취약하다” 또는 “4만 대가 침해됐다”로 바꿀 수는 없습니다.
- 스캔 시점과 상세 방법이 본문에 제시되지 않습니다.
- 각 호스트의 OS 버전과 패치 상태가 확인되지 않습니다.
- 서비스 노출은 실제 공격 성공이나 침해 발생과 다릅니다.
또한 Apple 공식 공지는 인증 우회를 확인하지만, Calif가 설명한 원격 root 공격의 전체 경로까지 상세히 기술하지는 않습니다. 공식 확인 범위와 연구팀의 실증 주장을 구분해야 합니다.[1][2]
2. 「How this came out」 — 취약점 발견·공개·패치의 경위
2.1 원문의 사건 흐름
이 챕터는 여러 연구자와 서로 다른 취약점이 얽힌 사건을 정리합니다.[1]
| 시점 | 원문에 제시된 사건 | 분석상 의미 |
| 시점 미상 | @osxreverser가 첫 번째 pre-auth 취약점을 발견했으나 Apple에 신고하지 않음 | 발견과 공식 신고는 별개 |
| 7월 27일 이전 | Bynario 등에서 Screen Sharing 취약점들을 신고 | 서로 다른 연구 경로가 병행 |
| 7월 27일 | macOS 26.6 배포, 신고된 취약점들과 함께 첫 번째 pre-auth 취약점도 수정됐다고 설명 | 패치의 실제 효과와 공지의 표현이 다를 수 있음 |
| 7월 29일 | Bynario가 CVE-2026-43760 분석을 공개하고, @osxreverser도 별도의 pre-auth 문제를 공개적으로 지적 | 인증 후 공격과 인증 전 공격의 차이가 부각 |
| 8월 초 | bl4sty가 AI를 활용한 분석을 공개 | 공개 자료의 재분석이 확산 |
| 8월 6일 | macOS 26.6.1에서 CVE-2026-65400 수정 | 두 번째 독립적 인증 우회 수정 |
| 8월 8일, APAC 기준 | Calif가 패치 차이를 분석해 공격 재현 | 패치 공개 후 공격 구현으로 연결 |
원문은 날짜가 기본적으로 미국 태평양 기준이고, Calif의 작업 시점은 APAC 기준이라고 별도로 설명합니다.[1]
2.2 핵심 주장: 공지 문구만으로 실제 공격 가능성을 충분히 이해할 수 있는가?
Calif는 7월 업데이트가 강력한 pre-auth 문제를 수정했는데도, 당시 보안 공지가 그 영향을 명확하게 설명하지 않았다는 점을 강조합니다.[1]
현재 확인한 Apple 26.6 공식 공지의 관련 항목에는 다음과 같은 영향 설명이 있습니다.[3]
- CVE-2026-43779: 다른 프로세스에 전달될 네트워크 연결 가로채기
- CVE-2026-43777: 원격 공격자의 서비스 거부 유발
- CVE-2026-43760: 사용자 민감정보 접근
반면 26.6.1 공지는 유효한 자격증명 없는 인증을 직접 명시합니다.[2]
분석: 운영자가 공지 제목이나 짧은 영향 문구만 보고 우선순위를 정하면, 실제로는 인증 경계에 영향을 주는 수정의 중요성을 충분히 인식하지 못할 수 있습니다. 취약점 관리에서는 다음 세 가지를 함께 봐야 합니다.
- 공식 공지: 제조사가 확인한 영향과 수정 버전
- 기술 분석: 실제 공격 조건과 가능한 영향
- 자산 맥락: 해당 기능이 켜져 있는지, 누가 접근할 수 있는지
2.3 주의할 부분: 발견 경위의 인과관계는 확정되지 않았다
원문은 @osxreverser의 공개 지적이 다른 연구자들을 같은 코드로 돌아가게 했을 것이라고 추정합니다. 이것은 확정된 발견 경위가 아닙니다.[1]
또한 “첫 번째 문제는 CVE가 없었다”는 설명은 기사 작성 당시 저자의 주장으로 다뤄야 합니다. 본문 아래 댓글에는 CVE-2026-43777과의 연관성을 제기하는 의견도 있지만, 댓글만으로 동일 취약점이라고 확정할 수는 없습니다.[1]
[확인 필요] 첫 번째 pre-auth 문제의 정확한 CVE 대응관계와 최초 신고 경위는, 이 기사와 공식 공지만으로 확정하기 어렵습니다.
3. 「Two pre-auth remote roots」 — 두 취약점의 공통점과 차이
이 챕터가 기술적 중심입니다.
3.1 첫 번째 취약점: 잘못된 반환값이 인증 성공으로 해석됨
원문은 첫 번째 문제를 단 하나의 잘못된 return으로 설명합니다.[1]
개념적인 흐름은 다음과 같습니다.
| 입력 길이 검증에서 문제 발견 ↓ 처리를 조기에 종료 ↓ 실패를 명확히 반환하지 않고 이전 읽기 작업의 성공값을 반환 ↓ 호출자가 인증 단계 성공으로 해석 ↓ 인증 상태가 부적절하게 다음 단계로 진행 |
분석: 여기서 문제는 검사가 아예 없었다는 것이 아닙니다. 검사에 실패했을 때의 처리 결과가 인증 실패로 연결되지 않았다는 점입니다.
이는 코드 검토에서 중요한 차이입니다.
“길이 검사가 존재한다”는 사실과 “잘못된 입력이 인증 경계를 넘지 못한다”는 보장은 서로 다릅니다.
검증 코드는 반환값, 호출자 해석, 상태 전이까지 연결해서 검토해야 합니다.
3.2 두 번째 취약점: 인증 상태 머신의 불일치
Calif는 두 번째 문제를 state machine desync, 즉 인증 상태 머신의 불일치로 설명합니다. 세부 공격 방식은 더 많은 사용자가 업데이트할 때까지 공개하지 않겠다고 밝힙니다.[1]
Apple 공식 공지도 이 문제를 상태 관리 개선으로 수정한 인증 문제라고 설명하므로, 결함의 큰 분류는 서로 부합합니다.[2]
원문에 따르면 두 번째 문제에는 계정 이름이 필요하지만, 첫 번째 문제에는 그것조차 필요하지 않습니다.[1]
| 구분 | 첫 번째 문제 | 두 번째 문제 |
| 원문이 설명한 결함 | 이전 성공값이 잘못 반환됨 | 인증 상태 머신 불일치 |
| 계정 이름 필요 | 필요 없다고 설명 | 필요하다고 설명 |
| 수정 시점 | macOS 26.6 | macOS 26.6.1 |
| 본문의 공개 수준 | 결함 개념 설명 및 외부 분석 링크 | 세부 방식 비공개 |
| CVE | 기사에서는 미부여라고 설명 | CVE-2026-65400 |
3.3 왜 메모리 보호가 있어도 막지 못하는가?
원문은 두 문제 모두 메모리 손상 공격이 아니라 논리적 결함이라고 강조합니다. 힙 조작, ASLR 우회, 경쟁 상태 승리와 같은 과정이 필요하지 않았다고 설명합니다.[1]
분석: 메모리 보호 기술은 중요하지만, “실패한 인증이 성공으로 처리되는가”라는 문제를 직접 해결하지는 않습니다. 이 사례는 보안 검증의 범위를 다음처럼 확장해야 함을 보여줍니다.
- 메모리 안전성
- 입력 검증
- 오류 처리의 일관성
- 인증 상태 전이
- 인증 전·후 기능 접근 통제
- 고권한 서비스의 권한 분리
3.4 신뢰성 주장의 한계
Calif는 공격이 처음부터 안정적으로 작동하고, Screen Sharing이 켜진 모든 미패치 시스템에서 작동한다고 강하게 표현합니다.[1]
다만 본문에는 전체 시험 대상 수, 설정별 결과, OS별 검증 행렬이 제시되지 않습니다. 따라서 분석에서는 다음 표현이 더 정확합니다.
Calif는 높은 재현성을 보고했지만, 모든 환경에 대한 독립적인 검증 자료가 본문에 제시된 것은 아니다.
4. 「Four hours」 — AI와 패치 분석이 공격 재현 시간을 단축한다
4.1 원문이 실제로 수행했다고 보고한 작업
Calif는 다음 두 비교를 수행했다고 설명합니다.[1]
- 26.6 ↔ 26.6.1: 두 번째 취약점의 패치 차이 분석과 공격 재현
- 26.5.2 ↔ 26.6: 첫 번째 취약점의 패치 차이 분석과 공격 재현
이렇게 두 개의 pre-auth 원격 root 공격을 약 4시간에 걸쳐, 주말의 다른 업무 사이에서 구현했다고 보고합니다.[1]
4.2 “4시간”을 어떻게 해석해야 하는가?
이 수치는 다음 의미로 제한해서 읽어야 합니다.
| 가능한 해석 | 판단 |
| Calif 연구팀이 두 공격을 재현하는 데 보고한 작업 시간 | 원문이 뒷받침 |
| 취약점을 아무 사전정보 없이 처음 발견한 시간 | 해당하지 않음 |
| 모델이 사람 없이 두 취약점을 발견하고 공격까지 완료한 시간 | 본문 근거 없음 |
| 모든 공격자가 동일하게 재현할 수 있는 시간 | 입증되지 않음 |
| AI가 기존 방식보다 얼마나 빨랐는지 보여주는 비교 실험 | 비교 기준 없음 |
분석: 패치가 작고, 공식 공지가 영향을 받는 하위 시스템을 알려주면 연구자의 탐색 범위가 크게 좁아집니다. 이 사례는 패치라는 단서가 주어진 상태에서의 공격 재구성이지, 아무 단서 없는 신규 취약점 탐색과 동일한 조건이 아닙니다.
4.3 AI의 역할: 발견과 재구성을 구분해야 한다
원문은 여러 참여자가 AI를 활용했다고 설명합니다. Bynario는 GPT-5.5 기반 자동화 워크플로로 별도의 취약점을 발견했고, 다른 연구자도 AI를 이용해 분석했다고 서술합니다.[1]
하지만 Bynario의 신규 발견 사례와 Calif의 패치 기반 재현 사례는 다른 작업입니다. 이를 합쳐 “AI가 두 개의 제로데이를 4시간 만에 발견했다”고 요약하면 잘못입니다.
또한 Calif 본문에는 자체 작업에 사용한 모델, 프롬프트, 인간 개입 정도, 비용이 구체적으로 제시되지 않습니다.[1]
4.4 핵심 시사점: 패치 공개가 공격자의 학습 자료가 된다
원문은 “패치됨”과 “공격에 활용 가능해짐” 사이의 간격이 줄어들고 있다고 주장합니다.[1]
분석: 이 사례가 보여주는 위험은 패치를 공개하지 말아야 한다는 것이 아닙니다. 오히려 다음 운영 문제를 강조합니다.
제조사의 패치 공개만으로 방어가 완료되는 것은 아니다. 실제 자산에 패치가 적용되거나 접근 경로가 차단될 때까지 노출은 남는다.
따라서 취약점 대응 속도는 단순히 “패치를 확보했는가”보다 영향 자산 식별 → 임시 차단 → 배포 → 적용 검증의 전체 흐름으로 평가해야 합니다.
5. 「Recommendations」 — 패치와 서비스 노출 축소
5.1 원문의 권고
Calif는 기사 작성 시점의 수정 버전으로 26.6.1, 15.7.9, 14.8.9를 제시합니다. 가능하면 Screen Sharing을 끄고, 필요한 경우 VPN이나 방화벽 규칙 뒤에서 운영하라고 권고합니다.[1]
또한 다수의 Mac을 관리하는 조직은 실제로 Screen Sharing이 활성화된 장비가 얼마나 되는지 확인하라고 강조합니다.[1]
Apple 공식 공지에서는 macOS Tahoe 26.6.1의 CVE-2026-65400 수정이 확인됩니다.[2]
주의: 위 버전들은 기사 당시의 수정 버전입니다. 현재 운영 권고를 해당 버전에 고정하기보다, 조직이 사용하는 OS 계열의 최신 지원 보안 업데이트를 기준으로 적용 여부를 판단해야 합니다.
5.2 실무 적용을 위한 우선순위
다음은 원문을 바탕으로 한 분석자 권고입니다.
| 우선순위 | 조치 | 확인할 증거 |
| 높음 | 인터넷에서 Screen Sharing에 직접 접근하는 경로 차단 | 외부 접근 시험, 방화벽·NAT 정책 |
| 높음 | 영향 자산의 보안 업데이트 적용 | 장비별 OS 버전·빌드, 적용 결과 |
| 높음 | 불필요한 Screen Sharing 비활성화 | 장비별 공유 설정, 관리 정책 |
| 중간 | 필요한 접근을 VPN·제한된 관리 구간으로 축소 | 허용 사용자·접속 원천·접근 정책 |
| 중간 | 원격접속 활성 자산과 예외 장비 목록 정비 | 자산대장, 담당자, 예외 승인 내역 |
| 중간 | 노출 기간의 의심 활동 조사 | 원격접속 기록, 보안 이벤트, 지속성 흔적 |
| 후순위 | 인증 상태 전이와 오류 처리 회귀시험 보강 | 부정 입력·순서 위반·오류 경로 시험 결과 |
여기서 VPN은 패치의 대체 수단이 아니라 접근 범위를 줄이는 보완 통제입니다. VPN 내부에서 공격자가 서비스에 접근할 수 있다면, 취약한 인증 구현은 여전히 문제가 됩니다.
또한 업데이트 적용은 취약점 수정의 증거이지, 이전 침해가 없었다는 증거는 아닙니다. 인터넷에 노출돼 있던 자산은 패치와 별도로 침해 가능성을 조사할 필요가 있습니다.
6. 종합 평가 — 무엇이 확인됐고, 무엇은 해석인가?
| 주요 주장 | 근거 수준 | 판단 |
| CVE-2026-65400으로 유효한 자격증명 없는 인증이 가능 | Apple 공식 확인 | 확인됨 |
| 수정은 인증 상태 관리 개선으로 이루어짐 | Apple 공식 확인 | 확인됨 |
| 두 개의 독립적 pre-auth 문제가 존재 | Calif 연구 보고 | 원문 주장으로 제시 가능 |
| 해당 공격이 원격 root 영향으로 이어짐 | Calif의 분석·재현 보고 | 공식 공지보다 넓은 영향 설명 |
| 두 공격을 약 4시간에 재현 | Calif 자체 보고 | 사례 수치이며 일반 벤치마크 아님 |
| 인터넷 노출 호스트 약 4만 대 | 원문이 인용한 연구자 스캔 | 취약·침해 호스트 수와 구분 필요 |
| AI가 패치 기반 공격 재구성을 가속 | 사례에 기반한 저자의 해석 | 방향성은 제시하지만 인과 효과는 정량 검증되지 않음 |
| 모든 미패치 환경에서 항상 성공 | 저자의 강한 표현 | 전체 시험 범위가 없어 일반화에 주의 |
최종 해석
이 글의 가장 중요한 교훈은 세 가지입니다.
- 비밀번호 강도와 인증 구현의 안전성은 별개의 문제입니다. 인증 우회는 비밀번호를 추측하는 공격이 아니므로, 비밀번호 정책만 강화해서 해결되지 않습니다.
- 검증 코드의 존재보다 실패 처리와 상태 전이가 중요합니다. 검사가 실패했는데도 성공값이 반환되거나 인증 상태가 진행되면, 방어 로직 자체가 우회 경로가 됩니다.
- AI 시대의 패치 관리는 배포 속도와 노출 관리까지 포함해야 합니다. 이 사례는 AI의 보편적 공격 성능을 입증하는 벤치마크는 아니지만, 공개 패치를 공격자가 신속하게 분석할 수 있다는 운영상 위험을 구체적으로 보여줍니다.
감리·보안 점검 관점에서는 “강한 비밀번호를 사용하는가?”에 더해, “원격 인증 서비스가 어디에 노출돼 있으며, 오류가 인증 성공으로 처리되지 않는지, 긴급 패치가 실제 자산에 적용됐는지”를 증거로 확인해야 합니다.
Sources
[1] https://blog.calif.io/p/no-country-for-old-passwords
[2] https://support.apple.com/en-us/148170
[3] https://support.apple.com/en-us/128067















'07.AI > 9. AI Safety' 카테고리의 다른 글
| AI 안전성 - LLM 기반 버그 탐색이 Linux 커널의 보안과 오픈소스 유지보수에 미치는 영향 (0) | 2026.10.04 |
|---|---|
| AI 안전성 - Hacktron, OpenAI 해킹 (0) | 2026.10.03 |
| AI 안전성 - Google Cloud, 에이전트 기반 AI를 활용한 인프라 코드 보안 강화 (0) | 2026.10.03 |
| AI 안전성 - Joshua Saxe, AI 사이버재난 : 펫테일(Fat-Tail) 리스크 (0) | 2026.10.03 |
| AI 안전성 - Anthropic, 인공지능 오용 탐지 및 대응: 2026년 9월 (0) | 2026.10.03 |


