권한을 나눈 것과 지키는 것은 다른 일이다: ScreenConnect CVE-2026-84869 인가 누락 점검

이미지 출처: CISA KEV

원격 지원 콘솔은 관리자에게는 만능열쇠 같은 물건임. 한 화면에서 수십, 수백 대의 엔드포인트에 명령을 밀어넣고 세션을 열고 계정을 만들 수 있으니, 이런 도구는 편한 만큼 위험도 한곳에 몰려 있음. ConnectWise ScreenConnect는 국내외 MSP와 헬프데스크가 워낙 많이 쓰는 물건이라, 여기서 권한 처리가 어긋났다는 소식은 그냥 '또 하나의 CVE'로 넘기기 어렵다고 봄. 이번 CVE-2026-84869는 부적절한 권한 관리(Improper Privilege Management)와 인가 누락(Missing Authorization)이 겹쳐서 보고된 사안이라, 방어자 입장에서 짚어둘 지점이 꽤 있음.

핵심 요약

• ScreenConnect의 일부 기능이 호출자의 권한을 제대로 확인하지 않아, 낮은 권한 사용자가 관리자급 동작에 손댈 여지가 생김.
• RMM 콘솔 특성상 한 번의 인가 실패가 관리 대상 전체로 번질 수 있어 파급이 큼.
• 즉시 최신 버전 적용, 콘솔 외부 노출 차단, 감사 로그 기반 이상행위 탐지가 핵심 방어선임.

인가 누락이라는 게 정확히 뭘 말하는지

인증(authentication)과 인가(authorization)를 자주 한 덩어리로 묶어 생각하는데, 사실 별개의 일임. 인증은 "당신 누구세요"를 확인하는 절차고, 인가는 "그래서 당신이 이 기능을 써도 되는 사람이냐"를 확인하는 절차임. 로그인은 멀쩡히 통과했더라도, 특정 API나 관리 기능을 부를 때 서버가 "이 사람이 관리자 롤인가?"를 다시 검사하지 않으면 인가가 비어 있는 것임.

부적절한 권한 관리는 여기에 한 겹 더 얹힘. 사용자·세션에 붙는 역할과 범위가 느슨하게 설계돼 있으면, 원래 낮게 발급됐어야 할 권한이 필요 이상으로 넓게 작동하거나, 경계 검사가 없는 엔드포인트로 우회돼 관리자 전용 동작까지 닿게 됨. 두 결함이 겹치면 결과적으로 낮은 권한 계정 또는 인가되지 않은 요청이 관리자급 행위를 유발하는 그림이 나옴. 공격 재현은 개념 수준으로만 말하면, 정상 사용자가 접근 가능한 통로를 통해 원래 허용되지 않았어야 할 관리 기능(계정 생성, 세션·설정 변경, 엔드포인트 명령 전달 등)의 처리 경로에 도달하는 방식임.

왜 RMM에서 이게 유독 아픈가

일반 웹앱에서 인가가 하나 빠지면 그 앱 안에서 문제가 끝남. 그런데 ScreenConnect 같은 원격관리 도구는 콘솔 자체가 '관리 대상 전체로 가는 다리'임. 콘솔에서의 권한 상승은 곧 연결된 모든 단말로의 발판이 됨. 공격자가 RMM을 노리는 이유가 딱 이거라고 봄 — 한 지점만 뚫으면 수평 확산 없이도 다수 자산에 명령을 뿌릴 수 있으니 효율이 좋은 표적이라는 것임. 과거 ScreenConnect 관련 사고들이 랜섬웨어 배포의 초기 접점으로 악용됐던 흐름을 떠올리면, 인가 결함을 가볍게 두면 안 되는 이유가 분명함.

방어자가 지금 확인할 것들

• 버전 점검과 패치 우선순위: 자사가 온프레미스로 운영하는 ScreenConnect 인스턴스의 정확한 빌드를 확인하고, 벤더가 공지한 수정 버전으로 최우선 업데이트함. 클라우드형을 쓰더라도 관리 설정과 계정 권한을 재점검할 것.
• 콘솔 노출 최소화: 관리 콘솔을 공용 인터넷에 그대로 열어두지 말고 VPN·IP 허용목록·리버스 프록시 뒤로 넣음. 인가 결함은 애초에 요청이 서버에 닿지 못하면 시도조차 어려워짐.
• 최소 권한 원칙 재적용: 실제 필요한 사람에게만 관리자 롤을 부여하고, 불필요하게 넓게 잡힌 계정·역할을 정리함. 서비스 계정과 사람 계정을 분리하고 MFA를 강제함.

탐지 포인트: 로그에서 무엇을 보나

인가 누락 계열은 '정상 로그인 후 비정상 행위'로 나타나는 경우가 많아, 로그인 실패만 보고 있으면 놓치기 쉬움. 개인적으로는 다음을 함께 상관분석하길 추천함.

• 권한 변경·계정 생성 이벤트: 예정에 없던 관리자 계정 추가, 역할 상향, 세션 정책 변경이 짧은 시간에 발생하는지 봄.
• 비관리 세션의 관리 엔드포인트 호출: 웹서버 접근 로그에서 낮은 권한 세션이 관리자 전용 경로로 요청을 보낸 흔적, 비정상적인 파라미터·응답 코드 패턴을 검토함.
• 대량·비업무시간 명령 배포: 다수 엔드포인트로 한꺼번에 명령·설치가 나가거나, 평소 운영 패턴과 어긋나는 시간대의 세션 확장이 있는지 확인함.
• 감사 로그 무결성: ScreenConnect 자체 감사 로그와 OS·EDR 로그를 별도 저장소로 즉시 전송해 사후 삭제·조작에 대비함.

정리하며

이번 건의 교훈을 한 줄로 줄이면, 권한을 잘게 나누는 설계와 매 요청마다 그 권한을 실제로 검사하는 구현은 완전히 다른 일이라는 것임. 롤을 아무리 촘촘히 만들어도 서버가 호출 시점에 확인하지 않으면 종이 위의 권한일 뿐임. RMM처럼 파급이 큰 도구일수록 '패치했다'로 끝내지 말고, 노출면 축소·최소권한·로그 상관분석까지 한 세트로 돌려보길 권함. 각자 환경에서 콘솔 버전부터 한 번 열어 확인해보고, 애매한 로그가 있으면 댓글로 같이 뜯어봐요.