지키는 장비와 뚫리는 장비는 한 끗 차이 — PAN-OS CVE-2026-0322 코드 인젝션 대응 메모

Tue, 20 Oct 2026 19:01:14 +0900

이미지 출처: CISA KEV

2024년 봄, GlobalProtect 취약점(CVE-2024-3400) 때문에 전 세계 보안 담당자들이 주말에 방화벽 앞에 붙어 있었던 일을 기억하는 분들이 꽤 있을 것 같다. 나도 그때 로그를 밤새 뒤졌다. 그런데 Palo Alto Networks PAN-OS에서 코드 인젝션(Code Injection) 취약점이 또 하나 공개됐다. 이번 번호는 CVE-2026-0322. 방화벽은 네트워크 맨 앞에서 모든 트래픽을 보는 장비라서, 이 장비가 공격자 뜻대로 코드를 실행한다면 사실상 성문을 열어주는 것과 같음. 그래서 이번 글은 "무엇이 위험한가"보다는 "우리 장비는 지금 괜찮은가, 어떻게 확인하고 막을까"에 초점을 맞춰 정리해봤다.

핵심 요약

CVE-2026-0322는 PAN-OS에서 외부 입력이 제대로 걸러지지 않아 의도하지 않은 코드가 실행될 수 있는 코드 인젝션 취약점임.
영향받는 버전과 심각도는 Palo Alto 보안 권고문에서 정확히 확인하고, 해당되면 수정 버전으로 올리는 것이 1순위임.
패치 전까지는 관리 인터페이스·포털 노출을 줄이고, 비정상 프로세스·설정 변경·외부 통신 로그를 중점적으로 봐야 함.

1. 코드 인젝션이 방화벽에서 특히 무서운 이유

코드 인젝션은 개념만 보면 단순함. 프로그램이 사용자 입력을 "데이터"로만 다뤄야 하는데, 검증이 허술하면 그 입력이 "코드"로 해석되어 실행돼 버리는 구조. 웹 애플리케이션에서 자주 보던 유형인데, 이게 방화벽 OS에서 터지면 이야기가 달라짐.

권한이 높음 — 방화벽 프로세스는 대부분 높은 권한으로 돌기 때문에, 한 번 실행되면 장비 전체 장악으로 이어질 수 있음.
보는 눈이 적음 — 서버에는 EDR을 깔지만 방화벽 내부에는 그런 에이전트가 없음. 탐지가 늦어지기 쉬움.
내부망의 관문 — VPN 세션, 정책, 인증 정보가 다 모여 있는 곳이라 침투 이후 횡적 이동의 발판이 됨.

공격 흐름을 굳이 개념으로만 그려보면, 공격자가 취약한 입력 지점에 조작된 값을 보내고 → 장비가 그 값을 처리하는 과정에서 코드로 해석하고 → 이후 지속성 확보나 설정 탈취로 넘어가는 식임. 구체적인 페이로드는 여기서 다루지 않고, 방어자는 각 단계마다 어떤 흔적이 남는지만 알면 충분하다고 생각함.

2. 지금 바로 확인할 것

버전 확인 — 운영 중인 PAN-OS 버전(Panorama, Prisma Access 포함)을 정리하고, Palo Alto 보안 권고문(security.paloaltonetworks.com)의 영향 범위와 대조하기.
노출 면 확인 — 관리 인터페이스(웹 UI, SSH)가 인터넷이나 넓은 내부 대역에 열려 있는지. GlobalProtect 포털·게이트웨이를 쓰고 있는지도 같이 체크.
KEV 등재 여부 — CISA KEV 목록에 올라와 있다면 이미 실제 공격이 관측됐다는 뜻이니 우선순위를 최상단으로 올리기.

3. 로그에서 볼 것

개인적으로는 패치보다 이 단계를 먼저 하는 걸 추천하는 편이다. 이미 당했는데 패치만 하면 흔적이 덮여버리기 때문임.

시스템·관리 로그 — 평소 없던 시간대의 관리자 로그인, 알 수 없는 출발지 IP의 웹 UI 접근, 실패 후 갑자기 성공하는 패턴.
설정 변경 이력(Config Log) — 누가 했는지 모르는 정책 추가, 관리자 계정 생성, 로깅 설정 비활성화.
장비발 외부 통신 — 방화벽 자신이 출발지인 낯선 외부 연결. 방화벽이 먼저 바깥으로 말을 거는 건 업데이트 서버 정도 말고는 드묾.
장애·재부팅 이력 — 이유 없는 프로세스 크래시나 재시작은 공격 시도의 부산물일 수 있음.
Tech Support File 분석 — 의심스러우면 TSF를 떠서 벤더나 침해대응 팀에 분석 의뢰하는 것도 방법.

4. 완화 조치, 우선순위대로

1순위: 수정 버전으로 업그레이드 — 권고문의 fixed 버전으로 올리기. 핫픽스가 단계적으로 나오는 경우가 많으니 본인 트레인에 맞는 버전을 꼭 확인.
2순위: 관리 평면 격리 — 관리 인터페이스는 전용 관리망이나 점프 서버에서만 접근되게 Permitted IP를 좁히기. 인터넷 노출은 절대 금지.
3순위: Threat Prevention 시그니처 — 구독 중이라면 해당 CVE용 위협 ID가 배포됐는지 확인하고 차단 액션으로 적용.
4순위: 침해 의심 시 재구축 관점 — 흔적이 나왔다면 패치로 끝내지 말고 관리자 계정·API 키·VPN 인증서 교체, 필요하면 공장 초기화 후 재구성까지 고려.

5. 해보면서 느낀 점

방화벽 취약점이 나올 때마다 드는 생각인데, 결국 사고를 키우는 건 취약점 자체보다 "관리 화면이 바깥에 열려 있었다"는 기본 설정 문제인 경우가 많은 것 같다. 패치는 벤더가 주지만, 노출 면을 줄이는 건 운영자가 평소에 해둬야 하는 일이다 보니 이번 기회에 관리 접근 정책을 한 번 싹 정리해두면 다음 CVE 때 훨씬 마음이 편할 거다.

혹시 운영 중인 환경에서 비슷한 로그 패턴을 보셨거나, 패치 적용하면서 겪은 이슈가 있다면 댓글로 공유해 주세요. 같이 정리하면서 더 단단하게 막아보아요!

AhsayCBS 관리 콘솔을 바깥에 열어둔 운영자라면 — CVE-2026-105133 부적절한 인증, 로그에서 볼 것과 오늘 바꿀 설정

Tue, 20 Oct 2026 13:01:14 +0900

이미지 출처: CISA KEV

새벽 세 시, 백업 서버 관리 화면에 처음 보는 IP가 관리자 세션으로 들어와 있었다고 생각해보자. 비밀번호를 바꾼 적도 없고 OTP도 걸어놨는데 말이다. CVE-2026-105133은 딱 이런 그림이 나올 수 있는 유형의 취약점임. Ahsay의 백업 서버 제품인 AhsayCBS에서 인증 처리가 제대로 되지 않는, 이른바 Improper Authentication(부적절한 인증) 문제로 분류되어 있음.

같은 제품에서 명령 주입 건을 정리한 적이 있다 보니 이번에는 조금 다른 각도로 보고 싶었다. 명령 주입이 "들어온 다음 무엇을 하느냐"의 문제라면, 이번 건은 "애초에 누구를 들여보내느냐"의 문제임. 백업 서버에서는 후자가 훨씬 무서운 것 같다.

핵심 요약

AhsayCBS에서 인증 절차를 제대로 거치지 않고도 보호된 기능에 접근할 수 있는 부적절한 인증 취약점(CVE-2026-105133)이 공개됨
백업 서버는 전사 데이터 사본과 복구 수단을 쥐고 있어, 인증이 뚫리면 데이터 유출과 백업 삭제가 한 번에 가능해짐
벤더 패치 적용이 최우선이고, 그 전까지는 관리 콘솔 외부 노출 차단과 비정상 세션·설정 변경 로그 점검이 핵심임

1. 부적절한 인증이 정확히 무슨 뜻인가

"인증 우회"라고 하면 흔히 비밀번호를 맞히는 걸 떠올리는데, 이 유형은 결이 좀 다름. 서버가 요청을 받았을 때 "이 요청이 정말 인증된 사용자로부터 왔는가"를 확인하는 단계 자체가 빠지거나 허술한 것이 핵심임.

특정 API 경로나 기능이 세션 검증 없이 동작하는 경우
클라이언트가 보낸 값(헤더, 파라미터, 토큰 형식 등)을 서버가 지나치게 신뢰하는 경우
인증 결과를 확인하는 로직에 예외 처리가 잘못 들어가 실패를 성공처럼 처리하는 경우

이번 CVE의 세부 트리거 조건이나 영향받는 정확한 버전 범위, 심각도 점수는 벤더 공지와 NVD 항목을 기준으로 확인하는 게 맞음. 다만 유형 자체가 "로그인 없이 안쪽 기능에 닿을 수 있다"는 뜻이라, 외부에 노출된 인스턴스라면 점수와 상관없이 급하게 다뤄야 할 부류라고 개인적으로는 보고 있음.

2. 왜 하필 백업 서버라서 더 위험한가

AhsayCBS는 MSP나 기업이 여러 고객·지점의 백업을 한곳에서 관리하는 용도로 많이 쓰임. 즉 한 대가 뚫리면 여러 조직의 데이터 사본이 한꺼번에 노출될 수 있는 구조임.

데이터 유출: 원본 서버를 건드리지 않고도 백업본에서 통째로 가져갈 수 있음
복구 수단 제거: 백업 세트 삭제, 보존 정책 단축, 스케줄 비활성화 같은 조작이 관리 기능으로 가능함
발판 확보: 백업 클라이언트와 통신하는 서버라 내부망으로 이어지는 연결 고리가 될 수 있음

랜섬웨어 조직이 본격적으로 암호화를 걸기 전에 백업부터 정리하는 건 이제 거의 공식처럼 되어버렸다. 인증 단계가 허술한 백업 서버는 이 작업을 너무 쉽게 만들어줌.

3. 지금 당장 할 일: 완화 순서

제가 운영자라면 아래 순서로 움직일 것 같다.

패치 확인 및 적용: Ahsay 공식 공지에서 수정 버전을 확인하고 최우선으로 올림. 다중 노드 구성이라면 모든 노드의 버전을 따로 확인해야 함
관리 콘솔 노출 차단: 웹 관리 인터페이스가 인터넷에 직접 열려 있다면 방화벽에서 관리자 IP나 VPN 대역만 허용하도록 좁힘. 백업 클라이언트 통신용 포트와 관리용 접근 경로를 분리할 수 있으면 분리함
관리자 계정 정리: 안 쓰는 관리자·서브 관리자 계정 비활성화, 비밀번호와 API 키 재발급. 패치 전에 이미 누가 들어왔을 수 있다는 전제로 진행함
백업 사본 분리: 최소 한 벌은 AhsayCBS 관리 권한으로 지울 수 없는 위치(오프라인, 불변 스토리지 등)에 두는 게 좋음

4. 로그에서 찾아볼 흔적

패치를 올렸다고 끝이 아님. 공개 이전부터 악용됐을 가능성은 늘 열어둬야 하니까 과거 로그도 한 번 훑어보는 걸 추천함.

정상 로그인 이벤트 없이 바로 관리 기능 호출이 찍힌 세션
평소 관리자가 접속하지 않는 국가·IP 대역에서의 관리 API 요청
짧은 시간 안에 몰린 백업 세트 삭제, 보존 기간 변경, 사용자 생성 이벤트
새로 추가된 관리자 계정이나 권한이 갑자기 올라간 계정
업무 시간 외 대용량 복원(restore) 또는 다운로드 작업

웹 서버 접근 로그와 애플리케이션 감사 로그를 시간 순으로 맞춰보면, "인증 기록은 없는데 관리 작업은 있는" 구간이 의외로 잘 보임. SIEM을 쓰고 있다면 이 패턴을 탐지 룰로 걸어두면 이번 건 말고 다음에 비슷한 인증 취약점이 나와도 그대로 써먹을 수 있음.

5. 마무리하며

백업은 "최후의 보루"라고들 하지만, 정작 그 보루의 문 단속은 소홀한 경우가 많은 것 같다. 백업 서버는 한번 세팅하고 나면 잘 돌아가는 한 아무도 안 들여다보게 되다 보니 더 그렇다. 이번 CVE-2026-105133을 계기로 우리 백업 서버 관리 화면이 바깥에서 보이는지, 마지막으로 관리자 계정 목록을 본 게 언제인지 한 번씩 확인해보면 좋겠다.

AhsayCBS 운영하시면서 패치 과정이나 로그 점검하다가 이상한 점 발견하신 분은 댓글로 공유해주세요. 같이 정리해보아요!

가족이 함께 쓰는 PC에서 계정과 파일 분리하는 방법: 윈도우 사용자 계정 만들기부터 폴더 권한 점검까지 체크리스트

Tue, 20 Oct 2026 12:31:35 +0900

이미지 출처: general

얼마 전 본가에 갔을 때 거실에 있는 컴퓨터를 켜 봤어요. 그런데 바탕화면에 아버지 거래 내역 엑셀, 동생 과제 파일, 어머니가 받으신 택배 문자 캡처가 한데 섞여 있더라고요. 브라우저를 여니 누군가의 쇼핑몰 계정이 로그인된 채였고, 저장된 비밀번호 목록을 열어 보니 가족 전원의 비밀번호가 다 들어 있었답니다. 이 컴퓨터를 쓰는 누구든 다른 가족의 계정에 들어갈 수 있는 상태였던 거죠.

가족끼리 뭘 그렇게까지 하느냐고 생각하실 수 있어요. 그런데 문제는 가족이 서로를 믿지 못해서가 아니라 사고가 한 사람에게서 모두에게 번진다는 데 있어요. 아이가 게임 핵 프로그램을 받다가 악성코드에 감염되면, 같은 계정에 저장된 부모님의 인터넷뱅킹 인증서와 브라우저 비밀번호까지 함께 위험해지거든요. 그래서 오늘은 공용 PC에서 계정과 파일을 사람별로 나누는 방법을 따라 하기 쉬운 순서로 정리해 볼게요. 윈도우 11 기준으로 설명하지만 윈도우 10도 메뉴 이름만 조금 다르고 거의 같답니다.

핵심 요약

가족 한 사람마다 윈도우 계정을 따로 만들고, 관리자 권한은 한 명만 가져요.
개인 파일은 각자의 사용자 폴더에 두고, 함께 쓸 파일만 공용 폴더에 모아요.
잠금 습관, 브라우저 비밀번호 정리, 로그인 기록 확인으로 분리가 잘 유지되는지 점검해요.

1. 왜 계정을 나누면 안전해질까요?

윈도우는 계정마다 따로 공간을 만들어 줘요. 바탕화면, 문서, 다운로드 폴더, 브라우저 기록, 저장된 비밀번호가 모두 계정별로 분리되는 거죠. 그리고 계정은 크게 두 종류로 나뉘어요.

관리자 계정: 프로그램 설치, 시스템 설정 변경, 다른 사람의 폴더 열람까지 할 수 있는 계정이에요.
표준 사용자 계정: 자기 파일과 일상적인 작업만 할 수 있어요. 프로그램을 설치하거나 중요한 설정을 바꾸려 하면 관리자 비밀번호를 물어보고요.

보안 쪽에서 이걸 최소 권한 원칙이라고 불러요. 필요한 만큼만 권한을 주면 실수나 악성코드가 끼치는 피해도 그 범위 안에서 멈춘다는 뜻이에요. 표준 계정에서 수상한 파일을 실행해도 관리자 비밀번호 창이 한 번 더 뜨니까 "어, 이게 왜 설치 권한을 달라고 하지?" 하고 멈출 기회가 생기는 거죠.

2. 가족 구성원별 계정 만들기

먼저 컴퓨터를 주로 관리하는 한 사람이 관리자 계정으로 로그인한 뒤 아래 순서로 진행해요.

설정 열기: 시작 버튼 → 설정 → 계정 → 기타 사용자(윈도우 10은 "가족 및 다른 사용자")로 들어가요.
계정 추가: "계정 추가"를 누르고, 그 사람이 쓰는 마이크로소프트 계정 이메일을 입력해요. 이메일 없이 만들고 싶다면 "이 사람의 로그인 정보가 없습니다" → "Microsoft 계정 없이 사용자 추가"를 선택하면 로컬 계정이 만들어져요.
자녀 계정: 설정 → 계정 → 가족 메뉴에서 자녀를 추가하면 Microsoft Family Safety와 연결돼서 사용 시간, 앱 설치 승인, 웹 필터링까지 관리할 수 있어요.
계정 유형 확인: 새로 만든 계정을 눌러 "계정 유형 변경"이 표준 사용자로 되어 있는지 확인해요. 기본값은 표준이지만 혹시 모르니 한 번 더 보시는 걸 추천해요.

개인적으로는 관리자 계정을 한 명만 두는 걸 추천해요. 그리고 그 관리자도 평소에는 별도의 표준 계정으로 쓰고, 설치나 설정 변경이 필요할 때만 관리자 비밀번호를 입력하는 방식이 제일 깔끔하더라고요. 처음엔 좀 번거로운데 쓰다 보니 금방 익숙해졌어요.

3. 로그인 잠금 제대로 걸기

계정을 나눠도 비밀번호가 없으면 아무나 다른 사람 계정을 클릭해서 들어갈 수 있어요. 그래서 계정마다 잠금 장치가 꼭 필요해요.

PIN 또는 비밀번호 설정: 설정 → 계정 → 로그인 옵션에서 PIN을 만들어요. PIN은 그 컴퓨터에서만 쓰이니 온라인 비밀번호와 다르게 정하는 게 좋아요.
Windows Hello: 지문 인식기나 얼굴 인식 카메라가 있다면 함께 등록해 두면 편해요.
자리 비울 때 잠그기: 키보드에서 윈도우 키 + L을 누르면 바로 잠금 화면으로 넘어가요. 가족 모두에게 이 단축키 하나만은 꼭 알려 주세요.
자동 잠금: 설정 → 계정 → 로그인 옵션에서 "자리를 비울 때 다시 로그인 요구"를 켜 두고, 화면 보호기 대기 시간도 5~10분 정도로 짧게 맞춰요.
Guest 계정 확인: 예전 윈도우에서 업그레이드한 PC라면 게스트 계정이 남아 있을 수 있어요. 쓰지 않는 계정은 지워 두는 게 안전해요.

4. 파일은 어디에 두어야 할까요?

계정을 만들면 각자 C:\Users\사용자이름 폴더가 생겨요. 표준 사용자는 다른 사람의 이 폴더를 열 수 없게 기본으로 막혀 있어요. 그러니 개인 파일은 꼭 자기 계정의 문서·바탕화면·다운로드 폴더에 두는 습관을 들이면 돼요.

함께 볼 파일: 가족사진처럼 모두가 봐야 하는 건 C:\Users\Public(공용) 폴더에 모아요. 이 폴더는 모든 계정이 읽고 쓸 수 있어요.
D 드라이브 주의: 하드디스크를 두 개 쓰는 PC라면 D 드라이브에 만든 폴더는 기본적으로 모두가 볼 수 있는 경우가 많아요. 개인 폴더를 D에 만들었다면 폴더 우클릭 → 속성 → 보안 탭에서 "Users" 그룹을 빼고 본인 계정만 남겨 두세요.
기존 파일 정리: 원래 하나의 계정을 다 같이 쓰던 PC라면, 새 계정을 만든 뒤 각자의 파일을 자기 계정 폴더로 옮기고 원래 계정에 남은 개인 파일은 지워 주세요.
디스크 암호화: 설정 → 개인 정보 및 보안 → 장치 암호화(Pro 버전은 BitLocker)를 켜 두면 노트북을 잃어버리거나 하드디스크를 빼 가도 파일을 읽기 어려워요. 복구 키는 마이크로소프트 계정에 저장되었는지 꼭 확인해 두세요.

한 가지 솔직히 말씀드리면, 관리자 계정은 다른 사람의 폴더도 열 수 있어요. 계정 분리는 실수와 악성코드 확산을 막는 장치이지, 관리자에게서까지 숨기는 장치는 아니에요. 정말 민감한 자료라면 암호를 건 압축 파일이나 개인 클라우드 보관함(예: OneDrive 개인 중요 보관소)을 함께 쓰는 걸 추천해요.

5. 브라우저와 인증서도 분리했나요?

의외로 많이 놓치는 부분이 브라우저예요. 계정을 나눴는데 예전 계정의 크롬이나 엣지에 가족 전원의 비밀번호가 저장되어 있으면 분리한 의미가 반쯤 사라지거든요.

예전 공용 계정의 브라우저에서 설정 → 비밀번호(암호) 목록을 열어 다른 가족의 저장 비밀번호를 지워요.
각자 자기 윈도우 계정에서 브라우저를 열고 본인 계정으로만 동기화해요.
인터넷뱅킹 공동인증서도 각자 계정에서 다시 저장하고, 공용 계정에 남은 인증서는 삭제해요.
"로그인 상태 유지"는 가족 공용 계정에서는 체크하지 않아요.

6. 분리가 잘 유지되는지 점검하는 방법

설정만 해 두고 끝내면 차차 다시 흐트러지기 마련이에요. 한 달에 한 번 정도 아래 항목을 확인해 보면 좋아요.

계정 목록 확인: 설정 → 계정 → 기타 사용자에서 모르는 계정이 생기지 않았는지 봐요. 명령 프롬프트에서 net user를 입력해도 전체 계정 목록이 나와요.
관리자 수 확인: 명령 프롬프트에 net localgroup administrators를 입력하면 관리자 권한을 가진 계정이 보여요. 정해 둔 한 명 외에 다른 이름이 있다면 표준으로 바꿔 주세요.
로그인 기록 보기: 시작 메뉴에서 "이벤트 뷰어"를 검색 → Windows 로그 → 보안으로 가서 이벤트 ID 4624(로그인 성공)와 4625(로그인 실패)를 필터링해 보세요. 아무도 쓰지 않은 새벽 시간에 로그인 실패가 반복된다면 비밀번호를 바꿔 주는 게 좋아요.
설치된 프로그램 확인: 설정 → 앱 → 설치된 앱에서 아무도 설치한 기억이 없는 프로그램이 있는지 살펴봐요.
윈도우 보안 상태: 윈도우 보안 앱에서 바이러스 및 위협 방지, 업데이트가 모두 초록색 체크인지 확인해요.

정리하며

본가 컴퓨터는 그날 저녁에 가족 넷의 계정을 하나씩 만들고, 바탕화면에 흩어진 파일을 각자 폴더로 옮기는 데 한 시간 정도 걸렸던 것 같아요. 처음엔 다들 "로그인하기 귀찮다"고 하셨는데, 몇 주 지나니 오히려 자기 바탕화면이 생겨서 편하다는 반응이더라고요. 보안은 거창한 프로그램보다 이런 작은 분리에서 시작된다고 생각해요.

오늘 내용 중에 딱 세 가지만 기억해 주세요. 사람마다 계정 하나, 관리자는 한 명, 자리 비울 때 윈도우 키 + L. 이번 주말에 가족과 함께 한번 해보아요! 따라 하다가 막히는 부분이 있거나 맥이나 크롬북 같은 다른 환경이 궁금하시면 댓글 주세요.

스팸을 걸러내던 관문이 디렉터리 바깥까지 보여줄 때: Cisco Secure Email Gateway CVE-2026-76519, 로그에서 찾을 것과 먼저 막을 것

Tue, 20 Oct 2026 08:01:23 +0900

이미지 출처: CISA KEV

회사 메일함에 스팸이 생각보다 적게 들어오는 건 대개 메일 서버 앞에 이메일 게이트웨이가 하나 서 있기 때문임. 들어오는 메일을 전부 열어 보고, 첨부파일을 검사하고, 수상한 링크는 바꿔 쓰고, 격리함에 가둬 두기도 함. 그러다 보니 이 장비는 조직 안에서 가장 많은 외부 데이터를 가장 먼저 만지는 시스템이 되는 셈인데, 이번에 Cisco Secure Email Gateway에서 상대 경로 탐색(Relative Path Traversal) 취약점 CVE-2026-76519가 공개됐음. 지켜야 할 장비가 오히려 자기 안의 파일을 밖으로 내줄 수 있는 문제라 그냥 넘기기는 좀 찝찝했고, 그래서 방어하는 쪽에서 무엇을 먼저 보면 좋을지 정리해 봤음.

핵심 요약

CVE-2026-76519는 Cisco Secure Email Gateway에서 경로 입력값을 제대로 정규화하지 않아 의도한 디렉터리 바깥의 파일에 접근될 수 있는 상대 경로 탐색 취약점임.
메일 게이트웨이는 설정 파일, 인증 정보, 격리 메일까지 쥐고 있어서 파일 하나만 새어 나가도 다음 공격의 발판이 되기 쉬움.
Cisco 권고문 기준으로 패치 적용, 관리 인터페이스 노출 축소, 웹 로그의 경로 조작 흔적 점검을 같이 진행하는 게 현실적인 순서임.

상대 경로 탐색이 뭐길래

개념 자체는 단순함. 애플리케이션은 보통 "이 폴더 안에 있는 파일만 보여준다"는 전제로 동작하는데, 사용자가 넘긴 파일 이름이나 경로 값을 그대로 이어 붙이면 문제가 생김. 상위 디렉터리를 가리키는 표현이 섞여 들어오면 기준 폴더를 벗어나 시스템의 다른 위치를 읽거나, 경우에 따라 쓸 수도 있음.

원인: 입력값을 실제 경로로 바꾼 뒤(canonicalize) 허용된 기준 디렉터리 안에 있는지 확인하는 과정이 빠져 있거나 불완전함
변형: URL 인코딩, 이중 인코딩, 운영체제별 구분자 차이처럼 필터를 우회하려는 표현이 자주 섞여 들어옴
결과: 읽기만 가능해도 설정·키·로그가 새어 나가고, 쓰기까지 가능하면 설정 변조나 추가 코드 실행으로 이어질 여지가 생김

NVD 설명에 따르면 이번 건도 이런 계열에 속하는 것으로 보임. 정확히 어떤 기능과 어떤 버전대가 영향을 받는지, 인증이 필요한지는 Cisco 보안 권고문에 정리된 내용을 기준으로 보는 게 맞고, 장비마다 쓰는 기능이 달라서 자기 환경에 맞는지부터 대조해 보는 게 먼저인 것 같음.

왜 하필 메일 게이트웨이라서 더 신경 쓰이는가

일반 웹 서버였다면 "파일 몇 개 새는 것"으로 끝날 수도 있는데, 메일 게이트웨이는 사정이 좀 다름. 개인적으로 이 장비를 점검할 때 늘 긴장되는 부분이 바로 여기임.

설정 파일: LDAP 연동 정보, 스마트 호스트, 릴레이 정책 등 내부 메일 구조가 거의 그대로 담겨 있음
자격 증명: 디렉터리 서버나 외부 연동용 계정 정보가 장비 안에 저장되는 경우가 많음
격리 메일·로그: 차단된 피싱 메일, 첨부파일, 송수신 기록 자체가 민감 정보임
위치: 외부와 내부 사이 경계에 놓여 있어서 한 번 발판이 되면 내부로 들어가는 길이 짧아짐

그러니까 "경로 하나 잘못 열린 것"이 실제로는 조직 메일 인프라의 지도를 넘겨주는 일이 될 수도 있다는 거임.

먼저 할 일: 패치와 노출 범위 줄이기

권고문 대조: Cisco 보안 권고문에서 영향 받는 AsyncOS 릴리스와 수정 릴리스를 확인하고, 운영 중인 장비 버전과 맞춰 봄. 클러스터 구성이면 모든 노드를 같이 봐야 함
업그레이드 일정 확보: 메일 흐름이 끊기면 안 되니 이중화 장비가 있다면 한 대씩 순차 적용하는 방식이 무난했음
관리 인터페이스 격리: 웹 관리 화면(HTTP/HTTPS)이 인터넷 쪽 인터페이스에 열려 있다면 바로 닫는 게 좋음. 관리망 전용 인터페이스나 허용 IP 목록으로만 접근되게 묶어 두면, 패치 전이라도 공격 표면이 크게 줄어듦
불필요한 서비스 정리: 스팸 격리함 최종 사용자 접근 등 외부에 열어 둔 기능이 꼭 필요한지 다시 따져 봄

탐지: 로그에서 어떤 모양을 찾을까

공격 문자열을 그대로 외우기보다는 패턴의 특징을 잡아 두는 편이 오래 써먹기 좋았음.

요청 경로나 파라미터에 상위 디렉터리 이동 표현이 들어간 기록, 특히 인코딩된 형태로 반복되는 경우
평소에는 요청되지 않는 시스템 파일 이름, 설정 파일 확장자가 파라미터 값으로 등장하는 경우
짧은 시간에 같은 출발지에서 경로만 조금씩 바꿔 가며 들어오는 요청 묶음(자동화 스캐너 흔적)
관리 화면 접근 로그에서 처음 보는 국가·IP 대역, 업무 시간 밖의 접근
설정 변경 이력, 계정 추가, 새 API 키 생성처럼 사후 행위로 이어진 흔적

장비 앞단에 WAF나 리버스 프록시가 있다면 경로 정규화 후 상위 디렉터리 탐색 시도를 차단하는 룰을 걸어 두는 것도 임시 완화책으로 괜찮음. 다만 이건 어디까지나 시간 벌기용이고, 근본 해결은 결국 벤더 패치임.

이미 노출됐을지 모른다면

관리 인터페이스가 외부에 열려 있었고 위 패턴이 로그에서 보인다면, 패치만 하고 끝내기보다 한 발 더 나가는 게 맞다고 생각함.

장비에 저장된 LDAP·SMTP 인증 등 연동 계정 비밀번호 교체
관리자 계정 전체 비밀번호 재설정과 불필요 계정 삭제
설정 백업을 알려진 정상 시점과 비교해 변경된 정책이 있는지 확인
장비 로그를 SIEM으로 보내고 있었다면 과거 기간까지 거슬러 올라가 같은 패턴을 다시 검색

정리하며

보안 장비라서 안전할 거라는 생각이 사실 제일 위험한 것 같음. 메일 게이트웨이는 한 번 세팅해 두면 몇 년씩 손을 안 대는 경우가 많은데, 이번 CVE-2026-76519를 계기로 버전 확인, 관리 화면 노출 여부, 로그 수집 상태 세 가지만이라도 같이 한 번씩 훑어보아요. 각자 환경에서 패치하면서 겪은 이슈나 탐지 룰 팁이 있다면 댓글로 공유해 주세요, 같이 보면서 다듬어 보면 좋겠음.

랜섬웨어가 백업부터 노리는 이유, AhsayCBS CVE-2026-105134 명령 주입으로 다시 보기

Mon, 19 Oct 2026 21:31:15 +0900

이미지 출처: CISA KEV

랜섬웨어 조직들이 암호화를 시작하기 전에 백업 서버부터 찾아서 지운다는 건 몇 년 전부터 거의 공식처럼 알려진 얘기임. 복구할 길을 먼저 끊어놔야 몸값 협상이 쉬워지기 때문인데, 이번에 공개된 Ahsay AhsayCBS 명령어 주입 취약점(CVE-2026-105134)은 그 백업 서버 자체가 공격자의 발판이 될 수 있다는 점에서 그냥 넘기기 어려운 건이라고 생각함. 백업 솔루션은 한번 깔아두면 잘 안 들여다보게 되다 보니 패치가 늦어지는 경우가 많은데, 그래서 이번 기회에 방어자 입장에서 뭘 봐야 하는지 정리해봄.

핵심 요약

AhsayCBS(Ahsay Cloud Backup Suite) 서버에서 외부 입력이 운영체제 명령으로 넘어가는 명령어 주입 취약점이 보고됨
백업 서버는 권한이 높고 내부망 깊숙이 연결돼 있어서, 뚫리면 데이터 유출과 백업 파괴로 바로 이어질 수 있음
벤더 패치 적용, 관리 콘솔 외부 노출 차단, 서버 프로세스가 띄우는 자식 프로세스 모니터링이 우선 대응임

1. AhsayCBS가 어떤 물건인지부터

AhsayCBS는 백업 서비스 사업자(MSP)나 기업이 자체 백업 서버를 운영할 때 많이 쓰는 솔루션임. 클라이언트 에이전트들이 데이터를 이 서버로 올리고, 관리자는 웹 기반 관리 콘솔에서 사용자·정책·저장소를 관리하는 구조임. 문제는 이런 서버 특성상 다음과 같은 조건이 겹친다는 점임.

고객사나 원격지 에이전트가 붙어야 하니 인터넷에 직접 노출된 경우가 흔함
백업 데이터 전체에 접근 가능한 높은 권한으로 서비스가 돌아감
여러 고객사 데이터가 한 서버에 모이는 경우가 많아서, 한 곳이 뚫리면 피해가 연쇄적으로 번짐

개인적으로는 백업 서버를 "가장 중요한 서버 중 하나"로 분류해두고도 실제 관리 우선순위는 한참 뒤로 밀어두는 곳을 꽤 많이 봤던 것 같음.

2. 명령어 주입, 개념만 짚고 가기

명령어 주입(Command Injection)은 애플리케이션이 사용자에게 받은 값을 검증 없이 운영체제 셸 명령의 일부로 이어 붙여 실행할 때 생기는 취약점임. 예를 들어 서버가 내부적으로 "어떤 경로를 점검하라"는 명령을 만들 때 사용자가 넣은 경로 문자열을 그대로 끼워 넣는다면, 그 문자열 안에 셸이 특별하게 해석하는 문자(명령 구분자, 치환 문법 등)가 섞였을 때 원래 의도하지 않은 명령까지 같이 실행되는 식임.

이번 건의 정확한 취약 지점이나 영향받는 버전 범위, 인증이 필요한지 여부는 벤더 권고문과 NVD 항목에서 확인하는 게 맞고, 여기서는 단정하지 않겠음. 다만 명령어 주입은 성공하면 서비스 계정 권한으로 임의 명령 실행이라는 결과로 이어지는 게 보통이라, 심각도가 낮게 매겨지는 일은 드묾.

3. 탐지는 어디서부터 볼까

패치를 바로 하더라도 이미 누가 들어왔다 나갔는지는 따로 확인해야 함. 내가 우선순위를 둔다면 이 순서로 보겠음.

프로세스 계보 확인: AhsayCBS 서비스 프로세스(자바 기반으로 도는 경우가 많음)가 셸, PowerShell, cmd, curl, wget 같은 걸 자식 프로세스로 띄운 기록이 있는지 EDR이나 Sysmon(Event ID 1), Linux auditd로 확인함. 평소엔 거의 안 생기는 패턴이라 신호 대 잡음비가 좋음
웹 접근 로그 확인: 관리 콘솔 및 API 요청 중 파라미터에 셸 메타문자나 URL 인코딩된 특수문자가 비정상적으로 많이 들어간 요청, 처음 보는 IP에서 들어온 관리 기능 호출을 추려봄
파일 변화 확인: 웹 루트나 설치 디렉터리에 최근 생성된 스크립트·JSP 파일, 예약 작업(cron, 작업 스케줄러)에 새로 생긴 항목이 있는지 봄
아웃바운드 통신 확인: 백업 서버가 평소 통신하지 않던 외부 주소로 연결을 시도한 흔적이 있는지 방화벽·프록시 로그에서 확인함
백업 데이터 무결성 확인: 백업 세트 삭제, 보존 정책 변경, 관리자 계정 추가 같은 설정 변경 이력을 감사 로그로 점검함

4. 완화 조치, 현실적인 순서

벤더 보안 업데이트 적용: Ahsay 쪽 권고문에서 수정 버전을 확인하고 최대한 빨리 올리는 게 1순위임
관리 콘솔 노출 줄이기: 에이전트 백업 포트와 관리 콘솔 접근 경로를 분리할 수 있다면 분리하고, 관리 콘솔은 VPN이나 허용 IP에서만 접근하게 묶어둠
서비스 권한 최소화: 서비스 계정이 OS 관리자 권한으로 돌고 있다면 필요한 범위로 줄일 수 있는지 검토함
WAF·IPS 임시 룰: 패치 전까지 관리 경로 요청에서 셸 메타문자 패턴을 차단하는 룰을 걸어두면 시간을 벌 수 있음. 물론 우회 가능성이 있으니 어디까지나 임시방편임
백업의 백업: 백업 서버 하나에 모든 걸 맡기지 말고, 오프라인 또는 변경 불가(immutable) 저장소에 별도 사본을 두는 3-2-1 원칙을 다시 점검함

5. 정리하면서

백업 서버 취약점은 늘 "데이터가 털린다"보다 "복구할 수단이 사라진다"는 쪽이 더 무서운 것 같음. 평소엔 조용히 돌아가는 서버라 관심 밖에 있다가, 막상 사고 터지고 나서야 그 서버가 제일 먼저 당했다는 걸 알게 되는 경우가 많다 보니 이번 CVE-2026-105134를 계기로 우리 백업 서버가 어디까지 노출돼 있는지, 마지막 패치가 언제였는지 한번 확인해보시길 바람. 개인적으로는 패치보다 관리 콘솔 외부 노출 여부부터 먼저 보는 걸 추천함, 그게 생각보다 자주 열려 있음.

AhsayCBS 운영하면서 탐지 룰이나 노출 줄이는 방법을 따로 써보신 분들 계시면 댓글로 경험 공유해주세요. 같이 정리해서 다음 글에 보태보겠음!

Jira·Confluence 서버의 파일, 바깥에서 얼마나 보이고 있을까? Atlassian CVE-2026-21589 점검 기록

Mon, 19 Oct 2026 19:01:17 +0900

이미지 출처: CISA KEV

접근 로그를 넘기다 보면 가끔 눈에 걸리는 줄이 있음. 응답 코드는 200이고 응답 크기는 수십 KB인데, 요청 경로를 보면 정적 리소스도 아니고 평소에 보던 REST API도 아닌 그런 줄. 그냥 넘겼다가 나중에 보니 서버 안쪽 파일이 그대로 밖으로 나간 흔적이었던 경우가 생각보다 많은 것 같다. 이번 Atlassian CVE-2026-21589이 바로 이런 종류라서, 탐지와 완화 위주로 정리해 봄.

핵심 요약

CVE-2026-21589는 여러 Atlassian 제품에서 외부에 노출되면 안 되는 파일이나 디렉터리에 바깥에서 접근할 수 있게 되는 취약점(CWE-552 계열)임
설정 파일, 내부 경로, 자격증명 단서가 새어 나가면 다음 단계 공격의 발판이 되기 때문에 '정보 노출일 뿐'이라고 넘기면 안 됨
벤더 패치 적용이 1순위이고, 그 전까지는 외부 노출 차단, 리버스 프록시 경로 제한, 접근 로그 소급 점검을 병행해야 함

1. 어떤 취약점인지 한 줄로

이름 그대로 "외부 당사자가 접근할 수 있는 파일 또는 디렉터리" 문제임. 애플리케이션이 내부용으로 쓰는 파일을, 인증이나 경로 검증을 충분히 거치지 않은 채 웹 요청으로 내어주는 구조적 결함이라고 보면 됨.

영향 대상은 Atlassian의 여러 제품군으로 묶여 있음. 사내에서 많이 쓰는 Jira, Confluence 같은 셀프 호스팅(Data Center/Server) 환경이 주로 관심 대상임
정확한 영향 버전과 수정 버전은 Atlassian 보안 권고문 기준으로 확인해야 함. 제품마다 수정 버전 라인이 다르게 나오는 경우가 많아서 "우리 Jira는 괜찮았으니 Confluence도 괜찮겠지"라고 생각하면 안 됨
CISA KEV 형식의 이름이 붙은 건 실제 악용 정황이 확인됐다는 뜻이라서, 일반 패치 주기보다 앞당겨 처리할 항목임

2. 파일 몇 개 보이는 게 왜 위험한가

처음엔 나도 "코드 실행도 아니고 파일 읽기 정도면…" 하고 우선순위를 낮게 잡았던 적이 있음. 근데 실제 침해 사례를 따라가 보면 정보 노출이 첫 단추인 경우가 정말 많았음.

설정 파일: DB 연결 정보, 외부 연동 토큰, 내부 호스트명이 들어 있을 수 있음
내부 경로·버전 정보: 공격자가 다음에 쓸 취약점을 고르는 지도가 됨
첨부파일·내보내기 산출물: Jira 이슈나 Confluence 페이지에 붙은 문서 자체가 민감 정보인 경우가 많음
세션·캐시 관련 파일: 경우에 따라서는 계정 탈취 쪽으로 이어질 여지도 있음

그러니까 이 취약점은 단독으로 끝나는 게 아니라 연쇄 공격의 정찰 단계를 공짜로 열어주는 것이라고 이해하는 게 맞는 것 같음.

3. 우리 서버가 당했는지 확인하는 방법

공격 재현을 해볼 필요까지는 없고, 방어자 입장에서는 로그를 보는 게 훨씬 현실적임.

리버스 프록시·WAF 로그 소급: 취약점 공개 시점 전후로, 평소 쓰지 않는 경로에 대한 200 응답을 뽑아봄. 특히 인증 쿠키 없는 요청인데 응답 크기가 큰 건 우선 확인 대상임
요청 패턴 이상치: 짧은 시간에 같은 IP가 경로만 바꿔가며 연속 요청한 흔적은 자동화 스캐너일 확률이 높음
애플리케이션 로그: Atlassian 제품의 access log, 그리고 Tomcat 로그를 같이 봐야 프록시에서 빠진 부분이 보임
노출됐을 수 있는 비밀값 목록화: 설정 파일이 나갔을 가능성이 조금이라도 있으면, 그 안에 있던 DB 비밀번호, API 토큰, 연동 계정은 교체 대상으로 바로 분류함

4. 완화 순서

개인적으로는 아래 순서로 처리하는 걸 추천함. 패치가 제일 확실하지만 운영 환경은 바로 재기동이 어려운 경우가 많아서 그 사이를 메워줄 조치가 꼭 필요했음.

1단계 – 노출면 줄이기: 인터넷에 직접 열려 있는 인스턴스라면 VPN이나 SSO 게이트웨이 뒤로 숨기는 것부터 함
2단계 – 프록시 경로 제한: 리버스 프록시에서 업무상 필요한 경로만 허용하고, 나머지 내부 리소스 경로는 차단하는 허용 목록 방식으로 바꿈
3단계 – 벤더 패치: 권고문에 나온 수정 버전으로 업그레이드함. 제품별로 따로 확인하는 거 잊지 말기
4단계 – 비밀값 교체: 노출 가능성이 있었던 자격증명은 패치 후에 반드시 바꿈. 패치는 문을 닫는 거지 이미 나간 정보를 회수해주지는 않기 때문임
5단계 – 탐지 규칙 남기기: 이번에 찾은 이상 패턴을 SIEM 규칙으로 남겨두면 비슷한 유형이 또 나왔을 때 훨씬 빨리 대응할 수 있음

5. 정리하며

Atlassian 제품은 회사의 업무 기록이 전부 모이는 곳이다 보니, 파일 하나가 새어 나가는 것만으로도 생각보다 많은 게 드러나는 것 같다. "읽기만 되는 취약점"이라는 말에 마음 놓지 말고, 패치하고, 로그 다시 보고, 비밀값 바꾸는 것까지 한 세트로 묶어서 처리해 보셨으면 함. 혹시 운영하면서 이 건 때문에 이상한 로그를 발견했거나 프록시 차단 규칙을 어떻게 잡았는지 공유해 줄 수 있는 분이 있다면 댓글로 남겨주세요. 같이 보면서 더 단단하게 막아보아요!

패스키를 새 휴대폰으로 옮기기 전 체크리스트: 동기화, 백업 코드, 복구 연락처 확인하는 방법

Mon, 19 Oct 2026 12:31:21 +0900

이미지 출처: general

새 휴대폰 상자를 뜯고 데이터 옮기기 버튼을 누르기 직전, 이런 생각 해보신 적 있으세요? "사진이랑 카톡은 옮겨지는데, 비밀번호 대신 쓰던 패스키는 어떻게 되는 거지?" 저도 얼마 전 폰을 바꾸면서 딱 그 지점에서 멈칫했어요. 옛날 폰을 초기화하려다가, 혹시 이걸 지우면 은행 앱이나 메일 계정에 못 들어가는 건 아닌가 싶어서 손이 멈추더라고요. 그래서 오늘은 패스키를 새 폰으로 옮길 때 무엇을 먼저 확인해야 계정을 안 잃어버리는지 하나씩 정리해 보려고 해요.

핵심 요약

패스키는 보통 비밀번호 관리자(아이클라우드 키체인, 구글 비밀번호 관리자 등)에 저장돼 같은 계정으로 로그인하면 따라오지만, 기기 종류가 바뀌거나 한 기기에만 묶인 경우에는 안 따라올 수 있어요.
옛날 폰을 초기화하기 전에 백업 코드, 복구 이메일·전화번호, 두 번째 패스키 같은 복구 수단이 살아있는지 먼저 확인해야 해요.
"패스키를 옮겨드린다"며 인증번호를 달라는 문자나 전화는 사기예요. 진짜 서비스는 인증번호를 물어보지 않는답니다.

먼저, 패스키가 뭐였죠?

패스키는 비밀번호를 외우는 대신 휴대폰의 지문, 얼굴 인식, 화면 잠금으로 로그인하는 방식이에요. 휴대폰 안에 나만 가진 열쇠(비밀 키)가 들어 있고, 웹사이트는 그 열쇠에 맞는 자물쇠(공개 키)만 갖고 있는 구조라고 생각하시면 돼요. 그래서 가짜 사이트에 비밀번호를 털리는 피싱에 아주 강하답니다.

문제는 이 열쇠가 어디에 보관돼 있느냐예요. 그 보관 장소에 따라 새 폰으로 자연스럽게 따라오기도 하고, 아예 안 따라오기도 하거든요.

1단계: 내 패스키가 어디에 저장돼 있는지 확인하기

대부분은 아래 셋 중 하나에 들어 있어요.

아이폰: 아이클라우드 키체인. 설정에서 내 이름을 누른 다음 아이클라우드, 비밀번호 및 키체인 항목이 켜져 있는지 보세요. 켜져 있으면 같은 애플 계정으로 로그인한 새 아이폰에 동기화돼요.
안드로이드: 구글 비밀번호 관리자. 새 폰에서 같은 구글 계정으로 로그인하면 동기화되는데, 이때 예전 폰의 화면 잠금(PIN, 패턴)이나 구글 비밀번호 관리자 PIN을 물어볼 수 있어요. 이건 꼭 기억해 두셔야 해요.
외부 비밀번호 관리자 앱: 1Password나 Bitwarden 같은 앱에 저장했다면 그 앱 계정으로 로그인만 하면 돼요. 운영체제가 달라도 따라온다는 게 장점이에요.

확인하는 방법은 간단해요. 휴대폰의 비밀번호 관리 화면에서 "패스키"라고 표시된 항목이 몇 개인지 세어보고, 메모장에 서비스 이름만 적어두세요. 나중에 새 폰과 비교할 체크리스트가 된답니다.

2단계: 아이폰에서 안드로이드로(또는 반대로) 갈 때는 더 조심하기

이 부분이 제일 많이 막히는 지점이에요. 아이클라우드 키체인과 구글 비밀번호 관리자는 원래 서로 직접 동기화되지 않거든요. 최근에는 비밀번호 관리자끼리 패스키를 안전하게 내보내고 가져오는 표준(자격 증명 교환 방식)이 생겨서 일부 기기와 앱에서 옮기기 기능을 지원하기 시작했지만, 내 폰과 내가 쓰는 앱이 그걸 지원하는지는 직접 확인해 보셔야 해요.

개인적으로는 운영체제를 바꿀 때는 옮기기에 기대기보다, 새 폰에서 각 서비스에 다시 로그인해서 패스키를 새로 등록하는 걸 추천해요. 조금 번거롭지만 가장 확실한 방법이거든요.

3단계: 옛날 폰 초기화 전 복구 수단 체크리스트

여기가 오늘 글의 핵심이에요. 아래 항목을 중요한 계정(메일, 은행·결제, 메신저, 클라우드)부터 하나씩 확인해 보세요.

백업 코드(복구 코드): 2단계 인증을 켤 때 받은 일회용 코드 묶음이에요. 어디 있는지 모르겠다면 계정 보안 설정에서 새로 발급받고, 종이에 적거나 오프라인으로 안전한 곳에 보관하세요.
복구 이메일과 전화번호: 예전 번호나 지금은 안 쓰는 메일로 되어 있지 않은지 확인하세요. 번호이동으로 번호가 바뀌었다면 특히 중요해요.
두 번째 로그인 수단: 태블릿, 노트북, 보안 키(USB 형태의 실물 열쇠) 같은 다른 기기에도 패스키가 등록돼 있으면 폰 하나가 사라져도 들어갈 수 있어요. 보안 키는 그 기기 안에만 열쇠가 있어서 새 폰으로 옮겨지지 않는다는 점도 기억해 두세요.
애플·구글 계정 자체의 복구 수단: 아이폰이라면 복구 연락처나 복구 키, 안드로이드라면 구글 계정의 복구 정보를 확인하세요. 패스키 보관함 자체를 잃으면 모든 게 막히니까, 이게 가장 바깥쪽 안전망이에요.
휴대폰 화면 잠금 비밀번호: 새 폰에서 동기화할 때 예전 잠금 비밀번호를 물어보는 경우가 있어요. 생체 인식만 쓰다 보니 PIN을 잊어버린 분들이 생각보다 많더라고요.

4단계: 새 폰에서 실제로 로그인되는지 테스트하기

동기화가 끝났다고 바로 안심하지 마시고, 1단계에서 적어둔 목록을 보면서 실제로 하나씩 로그인해 보세요. 로그인이 된 서비스에는 체크 표시를 하고, 안 되는 곳은 비밀번호나 백업 코드로 들어간 다음 패스키를 새로 등록하면 돼요.

모든 항목에 체크가 끝난 다음에 옛날 폰을 초기화하세요. 저는 개인적으로 일주일 정도는 옛날 폰을 그대로 두고 지냈는데, 자주 안 쓰는 서비스가 뒤늦게 떠올라서 이 기간이 꽤 쓸모 있었어요.

5단계: 정리와 이상 징후 확인

각 계정 보안 설정의 등록된 기기, 패스키 목록에서 이제 안 쓰는 옛날 폰 항목을 삭제하세요. 폰을 중고로 팔거나 잃어버렸을 때 위험을 줄여줘요.
최근 로그인 기록에서 모르는 지역이나 기기가 있는지 한번 훑어보세요. 기기 변경 시기는 사람들이 보안 알림을 대충 넘기기 쉬운 때라서 더 꼼꼼히 보는 게 좋아요.
"기기 변경으로 패스키 재인증이 필요합니다" 같은 문자의 링크는 누르지 마세요. 확인이 필요하면 앱을 직접 열거나 주소를 직접 입력해서 들어가세요. 진짜 서비스는 문자나 전화로 인증번호, 백업 코드를 알려달라고 하지 않아요.

마무리하며

패스키는 정말 편하고 안전한 방식인데, 그 열쇠를 어디에 두었는지 모르면 폰을 바꿀 때 오히려 발목을 잡을 수 있더라고요. 결국 핵심은 옛날 폰을 지우기 전에 복구 수단을 먼저 확인하는 것, 이거 하나예요. 이번 주말에 폰 바꿀 계획이 없더라도 백업 코드가 어디 있는지 한번 찾아보시는 건 어떨까요? 기기 변경하다가 막혔던 경험이나 궁금한 점이 있다면 댓글로 편하게 남겨주세요. 같이 해결해 보아요!

BeyondTrust Remote Support CVE-2026-102764: 원격지원 서버가 내세운 이름만 믿고 들여보낸 상대

Mon, 19 Oct 2026 08:01:26 +0900

이미지 출처: CISA KEV

헬프데스크 담당자가 전화를 받고, 사용자에게 세션 키를 불러주고, 몇 초 뒤 사용자 PC 화면이 상담원 모니터에 뜨는 장면을 떠올려보면 원격지원 솔루션이 얼마나 깊은 곳까지 들어가는 도구인지 실감이 남. 그 한가운데 서는 어플라이언스가 "이 요청을 보낸 쪽이 정말 그 사람이 맞는지"를 제대로 확인하지 않는다면 어떻게 될까? 이번에 NVD에 올라온 CVE-2026-102764가 바로 그런 이야기임. BeyondTrust Remote Support에서 스푸핑(Spoofing)을 통한 인증 우회가 가능하다는 내용이고, 개인적으로는 패치 공지만 보고 지나치기엔 이 제품이 쥐고 있는 권한이 너무 크다 보니 방어자 입장에서 한 번 길게 정리해두는 게 맞는 것 같았음.

핵심 요약

BeyondTrust Remote Support에서 요청 출처나 신원 정보를 위조해 정상 인증 절차를 건너뛸 수 있는 취약점(CVE-2026-102764)이 공개됨.
원격지원 어플라이언스는 엔드포인트 전체에 대한 접근 통로라서, 인증이 뚫리면 내부 확산의 출발점이 될 수 있음.
벤더 패치 적용이 1순위이고, 관리 인터페이스 노출 축소와 세션·인증 로그 소급 점검을 함께 해야 함.

1. 이 취약점이 건드리는 자리

스푸핑에 의한 인증 우회는 분류상 흔히 CWE-290 계열로 묶이는 유형임. 공격자가 비밀번호를 맞히거나 토큰을 훔치는 게 아니라, 서버가 신뢰의 근거로 삼는 어떤 값을 그럴듯하게 꾸며서 내미는 방식임. 그 값이 무엇이냐는 제품마다 다른데, 일반적으로는 다음 같은 것들이 후보가 됨.

요청이 어디서 왔는지 알려주는 헤더나 출발지 정보
클라이언트가 스스로 신고하는 식별자(장치 ID, 사용자 이름, 역할 값 등)
내부 구성요소끼리만 주고받는다고 가정한 신호나 플래그

핵심은 "클라이언트가 말한 것"을 "서버가 검증한 것"처럼 취급했다는 데 있음. 개념적으로 보면, 원래는 인증을 마친 쪽만 보낼 수 있어야 하는 정보를 외부에서도 그대로 흉내 낼 수 있었다는 뜻이고, 서버는 그걸 의심 없이 받아준 셈임. 구체적인 필드나 요청 형태는 공개 자료 범위를 넘어서 다루지 않겠음. 방어하는 입장에서는 그 디테일보다 내 환경에서 그 문이 바깥을 향해 열려 있는가가 훨씬 중요하기 때문임.

2. 왜 원격지원 제품에서 특히 위험한가

BeyondTrust Remote Support는 이전에도 공격자들이 노린 이력이 있는 제품군임. 이유는 단순함. 이 장비 하나가 수많은 사내 PC와 서버에 화면 제어, 파일 전송, 명령 실행을 할 수 있는 통로이다 보니, 공격자 눈에는 엔드포인트 수백 대로 들어가는 마스터키처럼 보이는 것임.

인증이 우회되면 상담원 권한으로 세션을 열거나 설정을 바꾸는 시나리오가 가능해질 수 있음
정상 원격지원 트래픽과 섞이기 때문에 EDR이나 네트워크 장비에서 이상 행위로 튀지 않을 가능성이 큼
외부 고객 지원 때문에 인터넷에 노출된 채 운영되는 경우가 많아서 스캐닝 대상이 되기 쉬움

3. 탐지 — 지금 로그에서 볼 것

패치를 하기 전이든 후든, 이미 누가 다녀갔는지 보는 작업은 따로 해야 함. 개인적으로는 아래 순서로 보는 걸 추천함.

인증 로그와 세션 로그의 불일치: 로그인 성공 기록 없이 시작된 상담원 세션, 혹은 평소 쓰지 않는 계정으로 열린 세션이 있는지 확인
출발지 IP 패턴: 상담원들이 실제로 접속하는 사내·VPN 대역 밖에서 관리 기능에 접근한 흔적이 있는지 확인
설정 변경 이력: 신규 계정 생성, 권한 상승, API 계정·키 발급, 점프 클라이언트 배포 같은 변경이 공지 시점 전후로 있었는지 확인
비정상 시간대: 지원 업무가 없는 새벽·주말에 시작된 세션이나 파일 전송
엔드포인트 측 흔적: 원격지원 클라이언트 프로세스가 자식 프로세스로 셸이나 스크립트 엔진을 띄운 기록

로그를 SIEM으로 보내고 있지 않았다면 어플라이언스 내부 보존 기간이 짧을 수 있으니, 지금 바로 원본 로그부터 백업해두는 게 좋음.

4. 완화 — 패치와 그 주변

벤더 권고 패치 적용: BeyondTrust 클라우드 호스팅 고객은 자동으로 반영되는 경우가 있지만, 온프레미스 어플라이언스는 직접 업데이트해야 하는 경우가 많으니 반드시 버전을 확인할 것
관리 인터페이스 노출 축소: 고객용 포털과 상담원·관리자용 인터페이스를 분리하고, 관리 쪽은 VPN이나 허용 IP로만 접근하게 묶기
프록시·로드밸런서 설정 재검토: 앞단 장비가 클라이언트 헤더를 그대로 전달하고 있다면, 외부에서 들어온 신원·출처 관련 헤더는 덮어쓰거나 제거하도록 정리
자격 증명 교체: 침해 흔적이 조금이라도 의심되면 관리자 계정, API 키, 연동 계정 비밀번호를 일괄 교체
MFA와 세션 승인 정책 강화: 우회 자체를 막지는 못하더라도, 이후 단계의 권한 행사를 한 번 더 걸러주는 효과가 있음

5. 이번 건에서 챙겨갈 교훈

스푸핑 기반 인증 우회는 코드 한 줄의 실수라기보다는 신뢰 경계를 어디에 그었느냐의 문제인 경우가 많음. "이 값은 내부에서만 오니까 괜찮다", "앞단 프록시가 걸러주겠지" 같은 가정이 겹겹이 쌓이다 보면 결국 아무도 검증하지 않는 값이 생기는 것 같음. 우리 쪽에서 직접 만드는 서비스도 마찬가지라서, 이번 기회에 클라이언트가 보낸 값을 그대로 신원 판단에 쓰는 곳이 없는지 같이 돌아보면 좋겠음.

원격지원 솔루션을 운영 중이라면 오늘 안에 버전 확인부터 해보아요! 탐지 쿼리를 짜다가 막히는 부분이나 환경별로 다르게 본 지점이 있다면 댓글로 공유해주세요. 차차 모아서 정리해보겠음.

패치 달력보다 KEV가 먼저다 · Artifactory, ScreenConnect, RouterOS 다섯 건 동시 등재를 방어자 눈으로 정리

Sun, 18 Oct 2026 21:34:08 +0900

이미지 출처: The Hacker News

CISA가 KEV(Known Exploited Vulnerabilities) 카탈로그를 처음 공개한 건 2021년 11월임. 그때만 해도 "또 하나의 취약점 목록"쯤으로 보는 사람이 많았는데, 몇 년 지나고 보니 이 목록은 "실제로 공격에 쓰이는 게 확인된 것"만 골라 담는 곳이라는 점에서 성격이 꽤 다름. CVSS 점수가 높다고 들어가는 게 아니라 실제 악용 증거가 있어야 올라감. 그래서 개인적으로는 패치 우선순위를 정할 때 벤더 권고문보다 KEV 업데이트를 먼저 보는 편임.

이번에 그 목록에 한 번에 다섯 건이 추가됐는데, 대상이 JFrog Artifactory, ConnectWise ScreenConnect, MikroTik RouterOS 세 제품군임. 하나는 개발 파이프라인의 창고, 하나는 원격 관리 도구, 하나는 네트워크 경계 장비. 공격자 입장에서 보면 "한 번 들어가면 멀리 갈 수 있는 자리"만 골라 놓은 조합이라 그냥 넘기기 어려웠음.

핵심 요약

CISA가 Artifactory, ScreenConnect, RouterOS 관련 취약점 5건을 실제 악용 확인을 근거로 KEV에 추가함
세 제품 모두 인증·인가 경계가 무너지는 계열이라, 한 번 뚫리면 공급망·원격관리·네트워크 전체로 피해가 번질 수 있음
패치가 1순위지만, 외부 노출 차단과 접근 로그 점검을 같이 해야 "이미 들어온 흔적"까지 잡을 수 있음

1. 왜 이 세 제품이 같이 묶였을까

제품은 서로 다르지만 공통점이 분명함. 이전에 이 블로그에서 개별 글로 다뤘던 Artifactory 인증·인가 문제, ScreenConnect 인가 누락, RouterOS 인증 누락과 인자 처리 문제처럼, 이번 다섯 건도 대체로 "누가 요청했는지 확인하는 단계"가 약한 부분에 모여 있음.

Artifactory: 빌드 서버와 개발자 PC가 의심 없이 받아 가는 패키지 저장소임. 여기에 쓰기 권한이 생기면 악성 아티팩트를 끼워 넣는 공급망 공격으로 바로 이어질 수 있음
ScreenConnect: 원격 지원 도구라서 원래부터 "남의 PC를 조작하는 권한"을 가지고 있음. 권한 검사가 빠지면 공격자가 그 권한을 그대로 빌려 쓰는 셈임
RouterOS: 경계 장비라서 트래픽 경로 변경, 프록시 설정, 봇넷 편입 같은 용도로 오래 악용돼 왔음. 한 번 장악되면 내부망을 넘어가는 발판이 됨

정리하면 세 개 다 "신뢰받는 자리에 있는 시스템"이라 피해가 해당 장비 하나로 끝나지 않는다는 점이 제일 무서운 부분인 것 같음.

2. KEV 등재가 실무에서 의미하는 것

미국 연방기관은 BOD 22-01에 따라 KEV에 오른 취약점을 정해진 기한 안에 조치해야 함. 보통 등재일로부터 몇 주 정도 기한이 주어짐. 우리나라 기업이야 이 지침을 따를 의무는 없지만, 실제로 공격이 돌고 있다는 신호라는 점은 똑같음.

KEV 등재는 "이론상 위험"이 아니라 "지금 누군가 쓰고 있음"이라는 뜻임
등재 시점에는 이미 스캐닝이 돌고 있는 경우가 많아서, 패치 전 기간 동안의 로그를 같이 봐야 함
사내 패치 일정이 월 1회 정기 패치라면, KEV 항목은 그 주기와 별도로 긴급 처리 대상으로 빼는 게 맞다고 생각함

3. 제품별로 먼저 볼 곳

Artifactory

벤더 권고에 나온 수정 버전으로 올리는 게 가장 먼저임
관리 콘솔과 REST API가 인터넷에 직접 노출돼 있는지 확인하고, 가능하면 VPN이나 사내망 안으로 넣음
최근 생성된 액세스 토큰, 새로 생긴 관리자 계정, 권한이 바뀐 그룹이 있는지 감사 로그로 확인함
패키지 저장소에 예상하지 못한 업로드나 덮어쓰기가 있었는지 보고, 중요 아티팩트는 체크섬을 다시 확인함

ScreenConnect

온프레미스로 운영 중이면 패치 버전 적용 여부를 바로 확인함. 클라우드 버전은 벤더 쪽에서 조치하는 경우가 많지만 공지는 꼭 확인함
평소에 없던 세션, 업무 시간 외 접속, 낯선 IP에서 들어온 관리자 로그인을 우선 확인함
원격 도구를 통해 실행된 명령이나 파일 전송 기록이 남아 있다면 같이 검토함. 랜섬웨어 조직이 초기 침투 도구로 자주 쓰는 패턴이라 이 부분은 꼭 봐야 함

RouterOS

RouterOS 펌웨어를 최신 안정 버전으로 올림
WinBox, 웹 관리, API, SSH 같은 관리 서비스는 WAN 쪽에서 막고, 허용할 관리 IP를 명시적으로 지정함
사용자 목록, 예약된 스크립트(scheduler), 프록시·SOCKS 설정, 방화벽·NAT 규칙에 모르는 항목이 생겼는지 확인함
이미 장악된 정황이 있으면 설정만 지우지 말고 초기화 후 새로 구성하는 걸 개인적으로는 추천함. 지속성 장치가 어디 숨어 있을지 모르기 때문임

4. 탐지 관점에서 챙길 것

패치만 하고 끝내면 "패치 전에 들어온 사람"은 그대로 남아 있을 수 있음. 그래서 아래 정도는 같이 보는 게 좋다고 생각함.

인증 없이 성공한 요청: 로그인 기록 없이 관리 기능 API가 호출된 흔적이 있는지
권한 변화: 새 계정, 새 토큰, 그룹 변경처럼 사람이 직접 한 기억이 없는 변경
장비에서 바깥으로 나가는 연결: 라우터나 저장소 서버가 평소 통신하지 않던 외부 주소로 연결하는지
설정 변경 시각: 변경 관리 기록과 실제 설정 변경 시간이 맞지 않는 경우

SIEM을 쓰고 있다면 이 세 제품 로그가 제대로 수집되고 있는지부터 확인해 보길 추천함. 막상 사고가 났을 때 보면 경계 장비나 원격 관리 도구 로그는 수집 대상에서 빠져 있는 경우가 생각보다 많았음.

5. 마무리

다섯 건이 한꺼번에 올라오면 솔직히 어디서부터 손대야 할지 막막한 게 당연한 것 같음. 개인적으로는 외부에 노출된 것부터, 그리고 권한이 큰 것부터 순서를 정하는 게 제일 현실적이었음. 그 기준으로 보면 이번 세 제품은 대부분 환경에서 우선순위 상단에 들어갈 거라고 생각함.

운영 중인 환경에 이 중 하나라도 있다면 이번 주 안에 버전 확인이랑 노출 여부 점검만이라도 먼저 해보아요. 점검하다가 이상한 흔적을 찾았거나 우선순위를 다르게 잡은 분이 있다면 댓글로 공유해 주세요. 같이 정리해 보면 다음 등재 때는 훨씬 빨리 대응할 수 있을 것 같음.

파일 이름에 점 두 개가 들어가는 순간 — GitLab CVE-2026-85706 경로 조작 취약점, 방어자가 먼저 볼 곳

Sun, 13 Sep 2026 13:02:35 +0900

이미지 출처: CISA KEV

회사에서 소스코드 저장소로 GitLab을 쓰는 곳이라면, 그 서버 한 대에 회사의 거의 모든 것이 들어 있다고 봐도 과언이 아님. 코드, CI/CD 파이프라인, 배포 키, 이슈에 적힌 내부 사정까지 전부 그 안에 있음. 그래서 GitLab에 경로 조작(Path Traversal) 취약점이 등록됐다는 소식은 단순히 "파일 하나 읽힐 수 있음" 정도로 넘길 문제가 아니라고 생각함. 이번에 NVD에 올라온 CVE-2026-85706은 GitLab Community Edition과 Enterprise Edition 양쪽에 모두 해당하는 건이라, 무료판 쓴다고 안심할 수도 없는 상황임.

핵심 요약

GitLab CE/EE에서 파일 경로를 처리하는 과정에 경로 조작(Path Traversal) 취약점이 확인됨. 의도한 디렉터리 바깥의 파일에 접근할 가능성이 있음.
방어의 핵심은 패치 버전으로 빠르게 올리는 것이고, 당장 어렵다면 외부 노출 차단·WAF 규칙·로그 모니터링으로 시간을 버는 것임.
탐지는 요청 로그에서 ../ 계열 패턴과 인코딩 변형을 찾는 것부터 시작하면 됨.

1. 경로 조작 취약점이 뭔지, 왜 GitLab에서는 더 무서운지

경로 조작은 이름 그대로임. 프로그램이 "이 폴더 안의 파일만 열어줄게"라고 설계돼 있는데, 사용자가 파일 이름에 ../ 같은 상위 디렉터리 이동 문자를 섞어 넣으면 프로그램이 그걸 걸러내지 못하고 폴더 바깥으로 나가버리는 것임. 개념 자체는 웹 해킹 입문서 첫 장에 나올 정도로 오래됐지만, 지금도 계속 새 CVE가 나오는 이유는 파일 경로를 다루는 지점이 애플리케이션마다 너무 많기 때문임. 업로드, 아티팩트 다운로드, 저장소 내보내기/가져오기, 위키 첨부파일 등 GitLab만 해도 경로를 조립하는 코드가 셀 수 없이 많음.

GitLab에서 경로 조작이 특히 위험한 이유는 서버 안에 놓인 파일들의 성격 때문임. 예를 들어 다음과 같은 것들이 같은 호스트에 존재함.

애플리케이션 설정 파일(데이터베이스 접속 정보, 시크릿 키 등)
CI/CD 러너 토큰과 파이프라인 변수
다른 프로젝트의 저장소 데이터와 아티팩트
백업 파일과 내보내기(export) 파일

즉, 경로 하나가 새는 순간 "파일 읽기"가 "권한 상승"과 "다른 프로젝트 정보 유출"로 곧바로 이어질 수 있는 구조임. 취약점의 세부 경로나 구체적인 트리거 조건은 벤더 권고문에 따라 확인해야 하지만, 방어자 입장에서는 "경로를 조립하는 기능이 외부 입력을 받는 곳"이 공격 표면이라고 이해하면 충분함.

2. 지금 당장 확인할 것: 우리 GitLab이 해당되는가

개인적으로는 CVE 소식을 들었을 때 가장 먼저 하는 일이 "우리 버전이 뭐지?"를 확인하는 것임. 생각보다 많은 조직이 GitLab을 한 번 설치해 두고 버전을 몇 년째 안 올리는 경우가 많음. 확인 방법은 간단함.

관리자 계정으로 로그인해서 Admin Area > Overview에서 버전 확인
Omnibus 설치라면 서버에서 gitlab-rake gitlab:env:info 실행
API로는 /api/v4/version 엔드포인트 호출(인증 필요)

GitLab은 보통 보안 릴리스를 여러 마이너 버전 라인에 동시에 내놓기 때문에, 자기 버전이 어느 라인에 있는지 파악한 뒤 공식 보안 릴리스 공지에서 해당 라인의 패치 버전을 찾아 올리는 것이 정석임. 정확한 영향 범위와 수정 버전 번호는 GitLab 보안 릴리스 블로그와 NVD 항목을 함께 보고 판단해야 하고, 이 부분은 여기서 단정하지 않겠음.

3. 탐지: 로그에서 무엇을 찾아야 하는가

패치를 적용했더라도 "이미 당했는가"를 확인하는 작업이 남음. 경로 조작 공격은 다행히 로그에 흔적이 비교적 잘 남는 편임. 요청 경로나 파라미터에 이상한 문자열이 들어가야만 성립하는 공격이기 때문임.

Nginx/워크호스 접근 로그에서 ../, ..\ 패턴을 검색. URL 인코딩된 형태인 %2e%2e%2f, 이중 인코딩 %252e%252e도 같이 찾아야 함.
production_json.log에서 파일 관련 컨트롤러(업로드, 아티팩트, 리포지토리 파일 조회)에 대한 요청 중 파라미터에 상위 경로 이동 문자가 포함된 것 필터링.
평소 접근하지 않던 계정이 짧은 시간에 파일 관련 엔드포인트를 반복 호출한 기록. 자동화 스캐너는 대개 수십~수백 개 변형을 한꺼번에 던지기 때문에 요청 빈도 자체가 신호가 됨.
응답 코드 분포. 정상적인 사용자는 200과 404가 섞이지만, 경로 탐색 시도는 403/404가 연속으로 쌓이다가 갑자기 200이 하나 튀는 패턴이 나타남. 그 200 하나가 성공한 요청일 가능성이 높음.

SIEM을 운용 중이라면 위 패턴을 룰로 만들어 두는 것을 추천함. 이번 건뿐 아니라 앞으로 나올 비슷한 유형의 취약점에도 그대로 재사용할 수 있어서, 한 번 만들어 두면 두고두고 도움이 됨.

4. 완화: 패치가 당장 어려울 때 시간 버는 법

현실적으로 GitLab 업그레이드는 "지금 바로"가 안 되는 경우가 많음. 대규모 저장소, 커스텀 러너 구성, 마이그레이션 시간 등 걸리는 게 많다보니 며칠 정도 여유가 필요할 때가 있음. 그 기간 동안 할 수 있는 것들을 정리해 봄.

외부 노출 최소화: GitLab이 인터넷에 직접 열려 있다면 VPN 뒤로 옮기거나 최소한 IP 허용 목록을 적용. 내부 개발자만 쓰는 서버가 공인 IP에 그대로 열려 있는 경우가 의외로 많음.
WAF/리버스 프록시 규칙: 요청 경로와 쿼리스트링에 상위 디렉터리 이동 패턴(원본 및 인코딩 변형)이 포함되면 차단. 오탐 가능성이 있으니 처음에는 로깅 모드로 며칠 돌려보고 차단으로 전환하는 것이 안전함.
권한 최소화: GitLab 프로세스가 실행되는 OS 계정이 필요 이상의 파일에 읽기 권한을 갖고 있지 않은지 확인. 경로 조작이 성공하더라도 OS 레벨 권한이 막아주면 피해가 줄어듦.
시크릿 순환 준비: 침해 흔적이 발견되면 즉시 러너 토큰, 개인 액세스 토큰, 배포 키를 교체할 수 있도록 목록과 절차를 미리 만들어 두기.

이 완화책들은 어디까지나 임시방편이고, 근본 해결은 패치 버전으로 올리는 것이라는 점은 잊으면 안 됨. WAF 규칙은 우회 변형이 계속 나오기 때문에 영구적인 방어선이 될 수 없음.

5. 개발자 관점에서 배울 점

이 취약점을 "GitLab 문제"로만 보고 끝내면 아까움. 우리가 만드는 서비스에도 파일 경로를 조립하는 코드는 반드시 있고, 같은 실수를 하고 있을 가능성이 높음. 개인적으로 코드 리뷰할 때 꼭 보는 포인트는 이런 것들임.

사용자 입력이 경로에 들어간다면 정규화(normalize) 후 기준 디렉터리 안에 있는지 검증하는 코드가 있는가. 단순히 .. 문자열을 치환하는 방식은 인코딩 변형에 쉽게 뚫림.
파일 이름을 사용자 입력 그대로 쓰지 말고, 서버가 생성한 식별자(UUID 등)로 저장하고 원래 이름은 메타데이터로만 보관하는가.
아카이브(zip, tar) 해제 시 내부 항목 이름에 상위 경로가 포함된 경우를 거르는가. 이른바 zip slip 문제는 경로 조작의 사촌 격임.

결국 경로 조작은 "입력을 믿지 말라"는 오래된 원칙이 코드 한 줄에서 무너지면서 생기는 문제임. 오래된 원칙일수록 잊기 쉽다는 게 함정인 것 같음.

마무리

GitLab 서버는 회사의 두뇌 같은 존재라서, 여기서 파일 하나가 새는 것은 다른 서비스에서 파일 하나 새는 것과 무게가 다름. CVE-2026-85706 소식을 계기로 우리 GitLab 버전이 어디쯤 와 있는지, 인터넷에 직접 열려 있지는 않은지, 로그는 제대로 남고 있는지 한 번씩 점검해 보면 좋겠음. 패치 적용 과정에서 겪은 경험이나 탐지 룰 아이디어가 있다면 댓글로 공유해 주시면 저도 배우고 싶음. 같이 지켜 나가요!

토큰 없이도 문이 열렸다는 보고 — Artifactory CVE-2026-42018, 인증 자체가 흔들린 경우의 대응 순서

Sat, 12 Sep 2026 21:32:08 +0900

이미지 출처: CISA KEV

바이너리 저장소를 운영해 본 사람이라면 아는 감각이 하나 있음. 개발자들은 저장소를 "그냥 파일이 있는 곳"으로 생각하지만, 실제로는 회사 전체 빌드가 매일 수백 번씩 신뢰를 걸고 들어가는 관문이라는 것. 그 관문에서 이번에는 '권한을 잘못 줬다'가 아니라 '누구인지 확인하는 단계 자체가 제대로 작동하지 않았다'는 보고가 나옴. NVD에 등록된 CVE-2026-42018, JFrog Artifactory의 Improper Authentication(부적절한 인증) 취약점임.

핵심 요약

CVE-2026-42018은 Artifactory에서 인증 검증이 불완전하게 이뤄져, 정상적인 자격 증명 없이도 보호된 기능에 닿을 수 있는 유형의 결함임(CWE-287 계열).
인가(무엇을 할 수 있나) 문제였던 CVE-2026-42016과 달리 이번엔 인증(누구인가) 단계의 결함이라, 영향 범위가 더 넓게 잡힐 수 있음.
대응 순서는 벤더 패치 적용 → 외부 노출 차단 → 접근 로그에서 '주체 없는 요청' 추적 → 토큰·자격 증명 재발급 순으로 잡는 것을 권함.

1. 인가 취약점과 인증 취약점, 무엇이 다른가

같은 제품에서 비슷한 시기에 번호가 붙은 취약점이 두 개 있다 보니 혼동하기 쉬움. 짧게 정리하면 이렇게 됨.

인증(Authentication): "너 누구야?"를 확인하는 단계. 아이디/비밀번호, 액세스 토큰, API 키, SSO 세션이 여기에 해당함.
인가(Authorization): 확인된 사용자가 "그걸 해도 되는가"를 판단하는 단계. 저장소별 읽기/쓰기 권한, 관리자 기능 접근 여부 등.

인가 결함은 '이미 로그인한 누군가'가 전제이므로, 최소한 내부 계정 하나는 있어야 함. 반면 인증 결함은 그 전제조차 무너뜨림. 계정이 없거나, 만료된 토큰이거나, 아예 빈 자격 증명으로도 특정 경로에서 인증된 것처럼 처리될 수 있다는 뜻임. 그래서 같은 "Improper"라는 단어가 붙어 있어도 방어자가 잡아야 할 우선순위는 인증 쪽이 한 단계 위라고 개인적으로는 봄.

2. 이 결함이 왜 아티팩트 저장소에서 유독 아픈가

Artifactory는 단순 파일 서버가 아님. Maven, npm, PyPI, Docker, Helm 등 수십 종의 패키지 프로토콜을 하나의 게이트웨이로 흡수하는 구조임. 문제는 각 프로토콜이 자격 증명을 전달하는 방식이 제각각이라는 점.

어떤 클라이언트는 Basic 인증 헤더로, 어떤 클라이언트는 Bearer 토큰으로, 어떤 클라이언트는 프로토콜 고유의 핸드셰이크로 신원을 넘김.
이 다양한 경로를 하나의 인증 계층이 받아내다 보니, 특정 경로에서만 검증이 느슨해지는 틈이 생기기 쉬움. 예를 들어 익명 접근이 허용된 저장소와 그렇지 않은 저장소를 구분하는 로직, 토큰의 서명·만료·발급자를 검증하는 로직 중 한 군데만 빠져도 결과는 "인증 없이 통과"가 됨.
저장소가 뚫리면 다음 단계는 뻔함. 빌드 서버가 그 저장소에서 받아 가는 의존성에 손을 대거나, 캐시된 원격 아티팩트를 바꿔치기하거나, 프라이빗 소스가 담긴 패키지를 그대로 내려받는 것. 공급망 공격의 출발점으로 이보다 좋은 자리가 없음.

정확한 영향 버전과 점수는 벤더 공지와 NVD 페이지를 기준으로 확인해야 하고, 여기서는 '어떤 유형의 위험이며 무엇부터 봐야 하는가'에 집중함.

3. 방어자가 밟아야 할 순서

순서가 중요함. 로그부터 뒤지다가 패치를 미루면 조사하는 동안에도 문은 열려 있는 셈이라, 아래 순서를 추천함.

① 패치 적용 여부부터 확정

JFrog 보안 권고에서 CVE-2026-42018이 수정된 버전을 확인하고, 운영 중인 인스턴스 버전과 대조함. 셀프호스팅이라면 업그레이드 창을 잡고, SaaS라면 벤더 측 적용 완료 공지를 확인함.
HA 구성이면 노드 전체가 같은 버전인지 반드시 확인. 한 노드만 구버전이면 로드밸런서가 그쪽으로 보내는 순간 의미가 없어짐.

② 즉시 패치가 어렵다면 노출면 줄이기

Artifactory가 인터넷에 직접 열려 있는지 확인. 개발 편의 때문에 공인 IP로 열어 둔 경우가 생각보다 많음. VPN이나 사내망으로 제한하고, 리버스 프록시에서 허용 경로를 화이트리스트로 좁힘.
익명 접근(Anonymous Access)이 켜져 있다면 이번 기회에 끄는 것을 검토. 익명 허용 자체가 취약점은 아니지만, 인증 결함과 결합하면 판단 로직을 더 헷갈리게 만드는 요인이 됨.

③ 로그에서 '주체가 비어 있는 요청' 찾기

access.log, request.log, 그리고 access 서비스의 감사 로그를 함께 봄. 주목할 패턴은 사용자명이 비어 있거나 anonymous로 찍혔는데 보호된 저장소에 성공(2xx) 응답이 남은 기록임.
특정 IP나 User-Agent가 짧은 시간에 여러 저장소를 훑고 지나간 흔적, 평소 쓰지 않는 프로토콜 엔드포인트로 들어온 요청, 업무 시간 밖의 대량 다운로드도 같이 확인.
SIEM으로 로그를 보내고 있다면 위 조건을 탐지 룰로 굳혀 두는 것을 권함. 이번 CVE가 끝나도 인증 계층의 이상 징후를 잡는 룰은 계속 쓸모가 있음.

④ 자격 증명과 아티팩트 무결성 점검

인증 우회 가능성이 있었던 기간에 발급·사용된 액세스 토큰과 API 키는 전부 회전(rotation)하는 것이 안전함. 특히 CI/CD 파이프라인에 박혀 있는 서비스 계정 토큰을 빼먹기 쉬움.
중요 저장소의 아티팩트 체크섬을 빌드 시점 기록과 대조. 바꿔치기 흔적이 없는지 확인하는 것이 공급망 관점에서 가장 중요한 마무리임.

4. 개념 수준에서 본 공격자의 움직임

실행 가능한 절차는 다루지 않지만, 방어자가 시나리오를 그려 보는 건 필요함. 공격자는 먼저 인터넷에 노출된 Artifactory 인스턴스를 찾고, 인증이 느슨하게 처리되는 특정 엔드포인트나 프로토콜 경로를 골라 접근을 시도함. 성공하면 조용히 목록을 훑어 내부 패키지명, 버전 체계, 의존성 구조를 먼저 파악하고, 그 다음에야 값어치 있는 아티팩트를 내려받거나 변조를 시도함. 그러니 탐지 룰도 '대량 다운로드'만이 아니라 '탐색 단계의 목록 조회'까지 잡을 수 있게 설계하는 편이 좋음.

마무리

CVE-2026-42016을 다뤘던 글에서 "저장소가 누구를 믿었는가"를 이야기했다면, 이번 글은 그보다 앞선 질문임. 믿기 전에 누구인지 제대로 물어봤는가. 인증 결함은 화려하지 않지만 뚫리면 뒤에 있는 모든 방어가 의미를 잃는 자리라, 패치 우선순위를 높게 잡는 걸 개인적으로는 강하게 추천함. 여러분 조직의 Artifactory는 어디에 열려 있고, 익명 접근은 켜져 있는지 오늘 한 번만 확인해 보길 바람. 점검하다가 막히는 부분이나 다른 탐지 아이디어가 있으면 댓글로 나눠 주세요. 같이 정리해 보아요!

빌드 서버가 믿는 창고, 그 창고는 누구를 믿었나 — JFrog Artifactory 인가 오류(CVE-2026-42016) 방어 노트

Sat, 12 Sep 2026 19:02:08 +0900

이미지 출처: CISA KEV

개발팀이 아침에 커밋을 올리면 CI가 돌고, 빌드 결과물은 Artifactory에 차곡차곡 쌓임. 배포 서버는 그 창고에서 파일을 꺼내 쓰고, 개발자들은 npm이나 Maven, Docker 이미지를 거기서 받아옴. 이 창고 하나가 조직 전체의 코드 흐름을 떠받치고 있는데, 정작 그 창고가 "이 사람이 이 저장소를 만져도 되는가"를 잘못 판단한다면 어떻게 될까. CVE-2026-42016은 바로 그 지점, JFrog Artifactory의 인가(Authorization) 판단이 어긋난 문제를 다루는 취약점임.

핵심 요약

JFrog Artifactory에서 권한 검사가 잘못 적용되어(Incorrect Authorization) 사용자가 본래 허용된 범위를 넘어 리소스에 접근·조작할 수 있는 취약점임
아티팩트 저장소는 공급망의 중심이라, 인가 오류 하나가 빌드 산출물 오염과 내부 정보 유출로 번질 수 있음
대응은 패치 적용, 권한 모델 재점검, 접근 로그 기반 이상 탐지 세 가지를 같이 가져가는 것이 핵심임

1. 어떤 종류의 문제인가

이번 건은 이름부터 힌트가 있음. "인증(Authentication) 우회"가 아니라 "인가(Authorization) 오류"임. 인증은 "너 누구냐"를 확인하는 단계고, 인가는 "그래서 너 이거 해도 되냐"를 판단하는 단계임. 즉 공격자가 로그인 자체를 뚫는 게 아니라, 정상적으로 로그인한 계정이 자기 권한 밖의 것을 할 수 있게 되는 구조임. 이런 유형은 흔히 CWE-863(Incorrect Authorization) 계열로 분류되는데, 코드 어딘가에서 권한 검사를 빠뜨렸거나, 검사는 하는데 엉뚱한 기준으로 했거나, 특정 경로만 검사가 느슨하게 걸려 있는 식으로 나타남.

Artifactory 맥락에서 생각해보면 위험한 시나리오는 대충 이런 것들임.

읽기 권한만 받은 외주 개발자 계정이 특정 저장소에 쓰기·삭제를 할 수 있게 됨
프로젝트 A에만 접근이 허용된 계정이 프로젝트 B의 내부 아티팩트나 메타데이터를 열람함
권한 관리 API나 특정 엔드포인트를 통해 원래 관리자만 할 수 있는 설정 조회·변경이 가능해짐

개인적으로 인가 오류 취약점을 볼 때마다 느끼는 건, 이게 RCE처럼 화려하지 않아서 우선순위에서 밀리기 쉬운데 공급망 도구에서는 오히려 더 무섭다는 점임. 빌드 산출물 하나를 바꿔치기하면 그걸 받아가는 모든 서버와 개발자 PC가 영향을 받으니까 말임.

2. 왜 아티팩트 저장소에서 유독 위험한가

보통 웹 서비스의 인가 오류는 "남의 데이터를 봤다" 수준에서 끝나는 경우가 많음. 그런데 Artifactory는 다름. 여기 저장된 건 단순 데이터가 아니라 실행될 코드임. 라이브러리, 컨테이너 이미지, 설치 패키지 같은 것들이 CI/CD 파이프라인을 타고 그대로 운영 환경까지 흘러감. 그래서 권한을 넘어선 쓰기가 가능해지면 다음 같은 연쇄가 이론적으로 가능함.

내부 라이브러리 버전에 변조된 파일을 덮어씀 → 다음 빌드부터 모든 서비스에 포함됨
도커 베이스 이미지 태그를 오염시킴 → 신규 배포되는 컨테이너 전체에 영향
저장소 설정이나 원격 프록시 설정을 바꿈 → 외부에서 가져오는 패키지 출처 자체가 바뀜

읽기 방향도 가볍지 않음. 내부 전용 패키지에는 회사 도메인 구조, 내부 API 주소, 가끔은 하드코딩된 설정값까지 들어 있는 경우가 많아서, 정찰 단계에서 이만한 정보원이 없음. 그러다보니 인가 오류 하나가 "정보 유출 → 표적 선정 → 산출물 변조"로 이어지는 출발점이 될 수 있다는 걸 염두에 두는 게 좋을 것 같음.

3. 방어자가 먼저 할 일: 패치와 노출면 정리

순서를 정리하면 이렇게 가는 걸 추천함.

버전 확인과 업데이트: JFrog 보안 공지에서 이번 CVE가 수정된 버전을 확인하고 그 이상으로 올림. Self-hosted 환경이라면 관리자 UI 또는 시스템 정보 API로 현재 버전을 먼저 파악함. SaaS 환경은 벤더가 처리하지만, 자체 설치형은 직접 챙겨야 함
외부 노출 여부 점검: Artifactory가 인터넷에 직접 열려 있는지 확인함. 인가 오류는 "로그인한 사용자"가 전제라 해도, 셀프 가입이 켜져 있거나 익명 접근이 허용돼 있으면 사실상 아무나 조건을 만족하게 됨. 익명 접근(Anonymous Access)이 정말 필요한지 이 기회에 다시 물어볼 것
임시 완화: 즉시 패치가 어렵다면 리버스 프록시나 WAF 단에서 관리 API 경로에 대한 접근을 내부망·특정 IP로 제한하고, 권한이 낮은 계정의 쓰기 작업을 잠시 막는 것도 방법임

4. 권한 모델 자체를 다시 보기

패치는 이번 구멍을 메우는 것이고, 권한 모델 점검은 다음 구멍이 생겨도 피해를 줄이는 것임. Artifactory에는 사용자, 그룹, 퍼미션 타겟(Permission Target), 프로젝트 단위 역할 같은 계층이 있는데 운영하다보면 이게 차차 꼬여감. 아래 항목을 한 번씩 훑어보는 걸 권함.

퍼미션 타겟에 "모든 저장소(Any Repository)"로 걸린 권한이 있는지 — 있다면 정말 필요한지 확인
CI 서비스 계정이 배포 권한(Deploy)과 삭제 권한(Delete)을 함께 갖고 있는지 — 삭제·덮어쓰기는 별도 계정으로 분리하는 편이 안전함
오래된 액세스 토큰과 API 키 — 만료 없이 발급된 토큰은 인가 오류와 결합하면 위력이 커짐. 주기적으로 회전시킬 것
관리자 계정 수 — 편의상 admin을 나눠 쓰고 있다면 개인 계정 + 최소 권한으로 정리
릴리즈 저장소의 덮어쓰기 금지(immutable) 설정 — 같은 버전에 재업로드가 안 되게 막아두면 변조 시나리오 상당수가 차단됨

5. 탐지: 어떤 로그를 보면 되는가

인가 오류는 익스플로잇 흔적이 화려하지 않음. 정상 로그인, 정상 요청처럼 보이는데 "이 계정이 이걸 했다는 게 이상하다"는 맥락으로만 잡힘. 그래서 로그를 계정·권한 관점으로 봐야 함.

access.log / request.log: 읽기 전용이어야 할 계정에서 PUT·DELETE 요청이 나갔는지, 특정 계정이 평소 접근하지 않던 저장소 경로를 건드렸는지 확인
권한 변경 이벤트: 퍼미션 타겟 생성·수정, 그룹 멤버 추가, 토큰 발급 이벤트를 SIEM으로 보내고 관리자 외 계정에서 발생하면 알림
아티팩트 무결성: 릴리즈 산출물의 체크섬을 빌드 시점에 별도 저장해 두고, 저장소 내 체크섬과 주기적으로 비교. 서명(예: 컨테이너 이미지 서명)을 도입했다면 검증 실패 이벤트를 놓치지 말 것
비정상 시간대·출처: 서비스 계정이 평소와 다른 IP나 시간대에서 활동하는 패턴

이미 노출된 기간이 있었다면, 패치 이전 로그를 위 기준으로 한 번 되돌아보는 게 좋음. 특히 릴리즈 저장소에 덮어쓰기가 있었는지, 권한 관련 설정 변경이 있었는지 두 가지는 꼭 확인해 볼 것.

6. 정리하며

이번 취약점의 교훈은 사실 Artifactory에만 해당하는 게 아님. 빌드 서버가 창고를 믿고, 창고는 계정을 믿고, 계정은 권한 시스템을 믿는 구조에서 한 고리의 판단이 틀리면 신뢰가 통째로 옮겨간다는 점임. 패치는 당연히 하되, 이참에 "우리 저장소에서 누가 무엇을 쓸 수 있는가"를 표로 한 번 그려보는 걸 개인적으로 추천함. 막상 그려보면 생각보다 넓게 열려 있어서 놀라는 경우가 많더라고요. 여러분 환경에서는 어떤 식으로 아티팩트 권한을 관리하고 계신지, 좋은 방법이 있으면 댓글로 나눠 주세요. 같이 정리해 보아요.

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

Sat, 12 Sep 2026 13:02:56 +0900

이미지 출처: 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처럼 파급이 큰 도구일수록 '패치했다'로 끝내지 말고, 노출면 축소·최소권한·로그 상관분석까지 한 세트로 돌려보길 권함. 각자 환경에서 콘솔 버전부터 한 번 열어 확인해보고, 애매한 로그가 있으면 댓글로 같이 뜯어봐요.

관리 콘솔의 옆문 — Cisco FMC가 인증을 우회당하는 '대체 경로' 구조와 방어 점검

Fri, 11 Sep 2026 21:32:45 +0900

이미지 출처: CISA KEV

방화벽을 한 대만 굴려본 사람은 안다. 정작 공격 표면으로 가장 무서운 건 방화벽 그 자체가 아니라, 수십 대의 방화벽을 한 화면에서 주무르는 관리 서버라는 것을. Cisco의 Firewall Management Center(FMC, 과거 FireSIGHT·FMC)는 바로 그 자리에 앉아 있음. 정책 배포, 룰셋 갱신, 이벤트 집계가 전부 여기를 거침. 그런데 이 관리 평면에서 정규 로그인 절차를 밟지 않고도 인증된 것처럼 행세할 수 있는 틈(CVE-2026-20079)이 보고됨. 분류상으로는 CWE-288, 즉 "대체 경로 또는 채널을 이용한 인증 우회"에 해당함.

핵심 요약

Cisco FMC의 관리 인터페이스에서 정상 인증 절차를 건너뛰는 대체 경로로 권한을 획득할 수 있는 결함(CVE-2026-20079, CWE-288)
관리 평면이 뚫리면 연결된 방어 장비 전체의 정책·룰이 영향권 — 단일 취약점이지만 폭발 반경이 큼
방어는 패치 적용이 1순위, 이어 관리망 분리·인증 로그 이상징후 모니터링·관리 계정 감사가 핵심

"대체 경로를 이용한 인증 우회"가 대체 무슨 말일까

CWE-288은 개념만 잡으면 어렵지 않음. 정문(정상 로그인 핸들러)은 아이디·비밀번호, 세션 토큰, 권한 검사를 차례로 요구함. 그런데 같은 기능에 도달하는 다른 입구가 있고, 그 입구는 같은 검사를 요구하지 않는다면? 공격자는 굳이 정문을 부술 필요가 없음. 옆문으로 돌아 들어가면 됨.

현실의 소프트웨어에서 이런 옆문은 대개 의도해서 만든 게 아님. 내부 API 엔드포인트, 디버그·헬스체크용 경로, 예전 버전과의 호환을 위해 남겨둔 레거시 핸들러, 혹은 특정 요청 형식일 때만 우회되는 미들웨어 같은 것들이 "우리끼리만 쓰니까 검사 생략해도 되겠지" 하고 방치되다가 외부에서 닿는 순간 문이 됨. FMC처럼 웹 UI와 REST API, 내부 통신 채널이 한 몸에 얽혀 있는 제품일수록 이런 경로가 많아지는 건 구조적으로 자연스러운 일임.

왜 하필 관리 서버가 문제인가 — 폭발 반경의 문제

취약점 하나의 심각도를 볼 때 개인적으로 가장 먼저 따지는 건 CVSS 숫자보다 "뚫리면 뭐가 딸려 나오는가"임. FMC는 개별 방어 장비가 아니라 그것들을 지휘하는 지휘소임. 여기서 인증을 우회한 누군가가 할 수 있는 일을 상상해보면:

전체 방화벽 정책을 조회해 내부망 구조와 허용 규칙을 파악함 — 즉, 침투 지도를 공짜로 얻음
특정 구간의 차단 룰을 느슨하게 바꾸거나 예외를 추가해, 이후의 실제 트래픽 공격을 위한 길을 미리 터둠
로깅·이벤트 전송 설정을 건드려 자신의 흔적을 관제에서 지움

방어 장비를 끄는 게 아니라 방어 장비를 내 편으로 돌려세우는 셈이라 무서운 것임. 그래서 이런 종류의 관리 평면 인증 우회는 단일 CVE치고 우선순위를 높게 두는 게 맞다고 봄.

방어자가 지금 당장 확인할 순서

순서가 중요함. 급할수록 하나씩 짚어야 빠짐이 없음.

1. 패치 적용 여부 확인. 가장 확실한 해결은 벤더가 내놓은 고정 버전으로 올리는 것임. 운영 중인 FMC의 정확한 빌드를 확인하고 보안 권고에 명시된 대상 버전인지 대조함. 관리 서버는 "나중에 창 띄워서" 식으로 미루기 쉬운데, 폭발 반경을 생각하면 유지보수 창을 앞당겨 잡을 가치가 있음.
2. 관리 인터페이스 노출 범위 축소. FMC 웹·API가 인터넷이나 일반 사무망에서 직접 닿는 상태라면 그 자체가 근본 위험임. 전용 관리 VLAN, 점프 호스트, 접근 소스 IP 제한으로 물리적·논리적으로 입구 수를 줄이는 것만으로도 대체 경로의 실질 도달성을 크게 낮춤.
3. 인증·접근 로그 역추적. 이미 당했는지를 보려면 로그부터 봄. 비정상적인 API 호출 경로, 로그인 이벤트 없이 발생한 권한 동작, 평소 쓰지 않던 엔드포인트로의 요청, 낯선 소스에서의 관리 세션 같은 걸 기간을 넉넉히 잡고 훑음.
4. 관리 계정·세션 감사. 추가된 계정, 변경된 권한, 살아 있는 비정상 세션 토큰을 점검하고, 의심스러우면 관리 크리덴셜과 API 토큰을 일괄 회전함.
5. 정책 무결성 대조. 최근 정책·룰셋 변경 이력을 마지막으로 신뢰할 수 있는 백업과 비교해, 손대지 않은 변경이 끼어들지 않았는지 확인함.

탐지 관점에서 한 가지 더

이런 인증 우회는 공격 자체가 조용한 편이라 "알림이 안 울렸으니 안전하다"가 통하지 않음. 오히려 평소 기준선(baseline)을 알아두는 쪽이 실전에 강함. FMC API를 정상적으로 호출하는 주체가 누구인지, 어떤 경로로, 어느 시간대에 움직이는지를 평상시에 파악해두면, 기준선에서 벗어난 단 한 번의 요청이 훨씬 선명하게 떠오름. 관리 평면 앞단에 리버스 프록시나 WAF를 두어 접근을 한 번 더 걸러주는 구성도 대체 경로의 노출을 줄이는 데 도움이 됨.

정리하면, 이 이슈의 본질은 "비밀번호가 약했다"가 아니라 "검사를 안 거치는 다른 문이 있었다"임. 그래서 비밀번호 강화 같은 대책으로는 메워지지 않고, 결국 패치로 문 자체를 막고, 관리망을 좁히고, 로그로 이미 열렸는지를 확인하는 세 박자가 같이 가야 함. 운영 중인 FMC가 있다면 오늘 버전 확인부터 같이 해보아요. 자기 환경에서 관리 인터페이스가 어디까지 노출돼 있는지 점검해본 경험이 있다면 댓글로 방법 공유해 주면 서로에게 큰 도움이 될 거라고 봄.

라우터가 "누구세요"를 묻지 않았다면 — MikroTik RouterOS CVE-2026-67277 인증 누락, 방어자용 점검 순서

Fri, 11 Sep 2026 19:02:20 +0900

이미지 출처: CISA KEV

2018년 여름을 기억하는 분이라면 MikroTik이라는 이름이 그리 낯설지 않을 것 같다. 그때 Winbox 쪽 취약점 하나로 전 세계 수십만 대의 라우터가 순식간에 코인 채굴 스크립트 배포 장치로 바뀌었고, 국내 소규모 사업장 장비도 꽤 많이 휩쓸렸던 기억이 있음. 그로부터 몇 년이 지나 다시 RouterOS에서 인증 자체가 빠진 관리 기능이 보고됐는데, 이번 번호가 CVE-2026-67277임. 이름부터가 "Missing Authentication for Critical Function", 즉 중요한 기능인데 로그인 절차를 거치지 않아도 닿을 수 있다는 뜻이라 개인적으로는 2018년의 그 장면이 먼저 떠올랐음.

핵심 요약

MikroTik RouterOS의 특정 관리 기능이 인증 검사 없이 호출될 수 있는 취약점(CWE-306 유형)이 CVE-2026-67277로 등록됨
라우터는 네트워크의 관문이라, 인증 없는 설정 변경 하나가 DNS 변조·트래픽 우회·내부망 진입으로 바로 이어질 수 있음
대응 순서는 벤더 수정 버전 적용, 관리 서비스 노출 차단, 그리고 이미 바뀐 설정이 없는지 역추적하는 세 단계임

1. 이번 취약점은 어떤 유형인가

취약점 분류로 보면 버퍼 오버플로우나 인젝션처럼 "코드가 잘못 짜여서" 생긴 문제라기보다, 있어야 할 확인 절차가 통째로 빠진 문제임. RouterOS 내부의 어떤 기능이 원래는 로그인한 관리자만 부를 수 있어야 하는데, 그 앞단에서 세션이나 자격증명을 검사하는 단계가 누락되어 있었던 것으로 정리됨. 정확히 어느 서비스의 어떤 기능인지, 영향받는 버전 범위와 수정 버전이 몇인지는 NVD와 MikroTik 공지에 적힌 내용을 기준으로 봐야 하고, 여기서는 "인증 없이 닿을 수 있는 중요 기능"이라는 구조 자체에 집중해서 설명함.

공격 재현을 개념 수준에서만 말하자면, 공격자는 장비의 관리 서비스 포트에 접근 가능한 위치에서 해당 기능을 직접 호출하기만 하면 됨. 비밀번호를 맞출 필요도, 세션을 훔칠 필요도 없음. 그래서 이 유형은 노출 범위가 곧 피해 범위가 되는 편임. 관리 포트가 인터넷에 열려 있다면 전 세계가 사정권이고, 내부망에서만 닿는다면 내부 침해 이후의 횡적 이동 도구가 됨.

2. 왜 라우터에서 이 유형이 유독 아픈가

서버 한 대의 인증 우회는 그 서버가 피해 범위임. 그런데 라우터는 그 뒤에 있는 모든 장비의 트래픽이 지나가는 자리라서, 인증 없이 설정을 만질 수 있다는 건 다음과 같은 일이 한꺼번에 가능해진다는 뜻임.

DNS 변조 — 내부 사용자 전체를 피싱 페이지로 보내거나 업데이트 서버를 가로챌 수 있음
트래픽 우회·도청 — 미러링이나 터널 설정으로 트래픽 사본을 외부로 흘릴 수 있음
SOCKS·프록시 개설 — 장비를 다른 공격의 중계지로 쓰는 건 2018년에 실제로 대량 발생했던 패턴임
스케줄러·스크립트 심기 — 재부팅 뒤에도 살아남는 지속성 확보 수단이 됨
방화벽 규칙 완화 — 내부망으로 들어오는 문을 조용히 넓혀둘 수 있음

그러다보니 이 취약점은 "패치하면 끝"이 아니라, 패치 전에 이미 누가 다녀갔는지를 확인하는 게 같이 붙어야 함. 인증 로그가 남지 않는 경로로 들어온 것이라 로그인 실패 기록만 보고 안심하면 안 됨.

3. 탐지 — 무엇을 어디서 볼 것인가

인증을 거치지 않았으니 "누가 로그인했다"는 기록은 기대하기 어려움. 대신 결과물을 봐야 함. 개인적으로는 아래 순서로 훑는 걸 추천함.

설정 변경 흔적 — /system history와 로그에서 본인이 기억하지 못하는 변경 시점이 있는지 확인함. 특히 /ip dns, /ip socks, /system scheduler, /system script, /ip firewall 항목의 변경 여부를 우선 봄
백업 비교 — 마지막으로 정상이라고 확신하는 export 파일과 현재 /export 결과를 diff로 비교함. 이 방법이 가장 단순하고 확실함
관리 포트 접근 기록 — 방화벽 input 체인에 로깅 규칙을 붙여 두었다면 외부 IP에서 관리 서비스 포트로 들어온 연결 시도를 뽑아봄. 없었다면 지금이라도 붙여두는 게 좋음
이상 트래픽 — 장비 자체에서 외부로 나가는 낯선 연결(특히 비표준 포트나 알 수 없는 IP로의 지속 세션)이 있는지 /ip firewall connection과 Torch로 살펴봄
사용자 계정 — /user에 모르는 계정이 추가되었거나 기존 계정 그룹이 바뀌었는지 확인함

외부에서 보는 관점도 필요함. 자기 회선의 공인 IP로 관리 포트(Winbox, www, api, ssh 등)가 열려 있는지 외부 스캔 도구나 공개 검색엔진으로 한 번 조회해 보면, 생각보다 "나는 닫았다고 믿었는데 열려 있는" 경우가 꽤 있음.

4. 완화 — 순서가 중요함

이런 유형은 우회할 방법을 찾을 필요 없이 그냥 열려 있는 것이라, 완화도 단순하게 가는 게 맞음. 다만 순서를 지키는 게 중요함.

첫째, 노출부터 줄임 — 업데이트를 검토하는 동안에도 공격은 진행되니, /ip service에서 쓰지 않는 서비스(telnet, ftp, www, api 등)를 끄고, 남기는 서비스는 address 항목으로 관리용 대역만 허용함. 방화벽 input 체인에서도 관리 포트는 신뢰 대역 외 drop을 기본으로 둠
둘째, 벤더가 안내한 수정 버전으로 올림 — 안정(stable)과 장기(long-term) 채널 중 자기 장비가 타는 채널의 수정 버전을 확인하고 적용함. 업그레이드 전 export 백업은 필수임
셋째, 관리 경로를 분리함 — 가능하면 관리 접속은 VPN을 통해서만, 혹은 별도 관리 VLAN에서만 가능하도록 구성함. 인터넷에서 바로 Winbox가 열리는 구성은 편하긴 한데, 이번 같은 취약점 앞에서는 그 편함이 그대로 비용이 됨
넷째, 3번에서 찾은 흔적을 정리함 — 이상 설정이 있었다면 단순 삭제보다는 깨끗한 백업으로 복원하고, 모든 관리 계정 비밀번호를 교체함
다섯째, 다음을 대비함 — export 파일을 주기적으로 저장하고 버전 관리에 넣어두면, 다음에 비슷한 일이 생겨도 "언제부터 뭐가 바뀌었나"를 몇 분 안에 답할 수 있음

5. 학습자 관점에서 남는 것

이 취약점을 보면서 개인적으로 다시 느낀 건, 네트워크 장비 보안은 결국 "관리 인터페이스가 누구에게 보이는가"라는 아주 오래된 질문으로 돌아온다는 점임. 코드 결함은 벤더가 고쳐주지만, 관리 포트를 인터넷에 열어둔 구성은 벤더가 대신 닫아주지 않음. 2018년에도 그랬고, 이번에도 피해 규모를 가르는 건 취약점의 심각도보다 노출된 장비의 수였던 것 같다.

집이나 사무실에 MikroTik 장비가 한 대라도 있다면 오늘 저녁에 딱 세 가지만 해보아요. 외부에서 관리 포트가 보이는지 확인하고, 마지막 export와 지금 설정을 비교해 보고, 수정 버전으로 올리는 것. 시간이 오래 걸리지 않고, 하고 나면 마음이 꽤 편해질 것임. 점검하다가 낯선 설정을 발견했거나 헷갈리는 부분이 있으면 댓글로 남겨 주세요. 같이 들여다보면서 차차 정리해 보아요.

스크립트 한 줄에 공백 하나 더 — MikroTik RouterOS가 인자 경계를 잘못 읽은 자리(CVE-2026-86060)

Fri, 11 Sep 2026 13:02:20 +0900

이미지 출처: CISA KEV

작은 사무실이나 원룸 건물 배전반을 열어 보면 열 중 서넛은 하얀 MikroTik 장비가 들어앉아 있음. 가격이 착하고 RouterOS 기능이 웬만한 엔터프라이즈 장비 못지않다 보니 국내 소규모 ISP, 학원, 카페, 그리고 홈랩 유저들까지 폭넓게 쓰는 물건임. 그런데 이 장비의 운영체제인 RouterOS에서 명령어 인자 구분자를 제대로 무력화하지 못하는 취약점이 CVE-2026-86060으로 등록됐음. 분류는 CWE-88, 풀어 쓰면 "명령 안의 인자 구분자를 부적절하게 중화함"임. 이름만 보면 지루한 문자열 처리 문제 같지만, 라우터라는 위치를 생각하면 절대 가볍게 넘길 수 없는 유형이라 정리해 둠.

핵심 요약

RouterOS가 사용자 입력을 내부 명령의 인자로 넘길 때 공백·따옴표·옵션 접두어 같은 구분자를 걸러내지 못해, 입력 하나가 여러 개의 인자나 옵션으로 쪼개져 해석될 수 있는 문제임(CWE-88).
일반적인 명령 인젝션(CWE-78)과 달리 새 명령을 끼워 넣는 게 아니라 기존 명령의 동작을 옵션 추가로 비틀어 버리는 방식이라 필터 우회가 쉽고 눈에 잘 안 띔.
대응의 핵심은 관리 인터페이스 노출 차단, 벤더 패치 적용, 스크립트·API 입력 검증, 그리고 로그에서 비정상 인자 패턴을 찾는 탐지 룰임.

1. 인자 구분자 인젝션이 뭔지부터 잡고 가기

많은 분들이 "명령 인젝션"이라고 하면 세미콜론이나 파이프로 뒤에 새 명령을 붙이는 그림을 떠올리실 텐데, CWE-88은 그것과 결이 조금 다름. 프로그램이 내부적으로 어떤 명령을 실행하면서 사용자 입력을 인자 하나로 넘긴다고 가정해 보면, 개발자는 입력이 "값 하나"라고 믿지만 실제로는 공백이나 따옴표, 혹은 -나 = 같은 옵션 표시가 들어가면 명령 파서가 그것을 "값 하나"가 아니라 "값 + 추가 옵션"으로 읽어 버림. 예를 들어 파일 이름을 받아 어딘가로 복사하는 기능이 있다고 치면, 파일 이름 자리에 옵션처럼 생긴 문자열이 들어가는 순간 복사 명령의 동작 자체가 바뀌는 식임.

이 유형이 방어자 입장에서 특히 골치 아픈 이유는 세 가지임.

새 명령이 등장하지 않음. 세미콜론·백틱·파이프 같은 흔한 인젝션 문자를 막아 놓은 필터를 그대로 통과하는 경우가 많음.
로그에 남는 흔적이 정상 요청과 비슷함. 실행된 명령 이름은 그대로고 인자만 조금 이상할 뿐이라, 명령 이름 기반의 탐지 룰로는 잡기 어려움.
영향 범위가 명령마다 다름. 어떤 명령에 붙느냐에 따라 파일 쓰기, 설정 변경, 권한 상승까지 결과가 달라져서 "이 정도면 괜찮겠지"라고 단정하기 어려움.

2. RouterOS에서 왜 문제가 되는가

RouterOS는 CLI 터미널, WebFig, WinBox, REST API, 그리고 내장 스크립트 엔진까지 사용자 입력이 들어오는 통로가 여러 개임. 그리고 그 입력 상당수가 결국 내부의 명령 처리기로 넘어감. 스케줄러에 등록한 스크립트, 넷워치(Netwatch)가 호스트 상태 변화 때 실행하는 명령, DHCP 리스 스크립트, 핫스팟 로그인 처리 같은 기능은 하나같이 외부에서 들어온 값(호스트명, 인터페이스 이름, 사용자명, 코멘트 등)을 명령 인자에 끼워 넣는 구조임. 이런 곳에서 구분자를 걸러내지 않으면, 공격자가 자기 통제 아래 있는 값(예를 들어 DHCP로 보내는 클라이언트 호스트명이나 핫스팟 사용자명)에 인자처럼 생긴 문자열을 넣어 두는 것만으로 관리자가 짜 둔 스크립트가 엉뚱한 옵션을 달고 돌아가게 만들 수 있음.

이 글에서는 어떤 문자열을 넣으면 어떻게 되는지 구체적인 페이로드는 다루지 않음. 개념만 짚자면, "내가 넣은 값이 값으로만 남지 않고 명령 옵션으로 승격되는 순간"이 이 취약점의 본질이고, RouterOS에서 그 승격이 가능한 지점이 있었다는 게 이번 CVE의 내용임. 정확히 어떤 버전대가 영향을 받는지, 점수가 몇 점인지는 벤더 공지와 NVD 페이지를 기준으로 확인하시는 게 맞고, 여기서는 "네 장비가 RouterOS면 일단 해당한다고 가정하고 점검하라"는 쪽으로 이야기하겠음.

3. 우리 장비가 위험한지 판단하는 순서

개인적으로는 아래 순서로 보시는 걸 추천함. 패치가 나왔다고 무작정 올리기 전에 노출면부터 줄이는 게 먼저인 경우가 많기 때문임.

관리 인터페이스가 어디에 열려 있는지 확인. /ip service print로 www, www-ssl, api, api-ssl, winbox, ssh, telnet 중 무엇이 살아 있고 어느 주소 대역에 허용돼 있는지 봄. WAN 쪽에서 WebFig나 API가 보이면 그 자체가 이미 문제임.
스크립트·스케줄러·넷워치 목록 점검. /system script print, /system scheduler print, /tool netwatch print에서 외부 입력을 변수로 받아 명령에 넣는 스크립트가 있는지 찾음. 특히 $hostname, $user, 코멘트 값 같은 걸 그대로 문자열 결합하는 패턴이 있으면 표시해 둠.
핫스팟·DHCP·PPP 스크립트. on-login, on-lease, on-up 같은 이벤트 훅에 걸린 스크립트는 공격자가 값을 마음대로 주입할 수 있는 대표적인 입구라 따로 봄.
버전과 채널 확인. /system package update print로 현재 버전과 채널(long-term, stable)을 확인하고 벤더 체인지로그에 이 CVE 대응이 들어간 빌드인지 대조함.

4. 완화 조치 — 패치 전과 후

패치를 바로 올릴 수 있으면 올리는 게 답이지만, 현장 장비는 재부팅 창을 잡기 어려운 경우가 많아서 패치 전에도 할 수 있는 것과 패치 후에도 유지해야 하는 것을 나눠 적음.

관리 포트 접근 제한. /ip service set www-ssl address=관리대역 같은 식으로 관리 서비스마다 허용 주소를 못 박고, 쓰지 않는 서비스(telnet, ftp, 평문 www, api)는 disable함. 방화벽 input 체인에도 같은 정책을 이중으로 걸어 두면 서비스 설정을 실수로 풀어도 한 겹이 남음.
스크립트 입력을 값으로 고정. 외부 값을 명령에 넣을 때는 문자열 결합 대신 RouterOS 스크립트의 변수 전달 방식을 쓰고, 값에 공백·따옴표·= 등이 들어오면 그냥 버리거나 치환하는 검증 단계를 넣음. 특히 hostname과 comment는 길이와 허용 문자를 화이트리스트로 제한하는 게 좋음.
권한 분리. 자동화용 API 계정은 full 그룹이 아니라 필요한 정책만 가진 별도 그룹으로 만들고, 스크립트 실행 권한(policy)도 필요한 것만 남김. 인자 하나가 비틀려도 그 계정이 할 수 있는 일이 작으면 피해가 작음.
패치 적용. 벤더가 수정 빌드를 내놓은 채널로 올리고, 업그레이드 뒤에는 RouterBOOT(펌웨어)도 함께 올려 둠. 올리기 전 /export로 설정 백업을 받아 두는 건 기본임.
패치 후에도 유지. 위 접근 제한과 입력 검증은 패치와 무관하게 계속 두는 게 맞음. 같은 유형의 취약점은 다른 명령, 다른 경로에서 또 나올 수 있기 때문임.

5. 탐지 — 로그에서 무엇을 봐야 하나

이 유형은 명령 이름으로는 못 잡는다고 했으니, 인자의 모양을 보는 룰이 필요함. RouterOS 로그를 syslog로 원격 수집하고 계신다면 아래 관점으로 룰을 짜 보시는 걸 권함.

이벤트 훅 실행 로그의 변수 값에 구분자가 섞인 경우. DHCP 리스, 핫스팟 로그인, PPP 세션 로그에서 hostname·username 필드에 공백, 따옴표, =, 선행 -가 들어간 항목은 그 자체로 이상 징후임. 정상 클라이언트가 그런 이름을 쓰는 일은 거의 없음.
스크립트 실행 실패·경고 급증. 인자가 깨지면 명령이 문법 오류로 죽는 경우가 많아서, script 토픽의 error 로그가 갑자기 늘면 누가 찔러보고 있을 가능성이 있음.
설정 변경 이벤트와 로그인 이벤트의 불일치. 관리자 로그인 없이 system 토픽에 설정 변경(changed by ...)이 찍히면 스크립트 경로로 무언가 바뀐 것이므로 즉시 확인 대상임.
관리 포트 접근 시도. 방화벽 input 체인에서 관리 포트로 들어온 외부 IP를 별도 로그 접두어로 남겨 두면, 취약점 공개 이후 스캔이 늘어나는 흐름을 눈으로 볼 수 있음.

로그를 아직 안 모으고 계시다면 이번 기회에 /system logging action에 원격 syslog 하나 추가하는 것부터 해 보셨으면 함. 장비 안에서만 도는 로그는 재부팅 한 번에 사라지고, 침해 후 조사할 때 가장 아쉬운 게 그 부분임.

6. 정리하며

MikroTik은 예전에도 관리 인터페이스 쪽 취약점이 나올 때마다 국내외에서 대규모로 털린 전례가 있음. 이유는 취약점 자체보다 인터넷에 관리 포트를 열어 둔 장비가 너무 많아서였음. 이번 CVE-2026-86060도 인자 처리라는 다소 기술적인 결함이지만, 결국 공격자가 값을 밀어 넣을 수 있는 통로가 열려 있어야 성립함. 그러니 패치 여부와 별개로 오늘 당장 관리 포트 노출부터 닫고, 스크립트에서 외부 값을 그대로 명령에 끼워 넣는 부분이 있는지 한 번씩만 훑어보셨으면 함. 저도 홈랩 장비 넷워치 스크립트를 이 글 쓰면서 다시 열어 봤는데, 코멘트 값을 검증 없이 쓰는 부분이 있어서 고쳤음. 여러분 장비에서도 비슷한 게 나오면 댓글로 공유해 주세요. 같이 하나씩 닫아 나가 보아요.

자바스크립트 배열 한 칸 바깥, V8이 넘어선 경계선 이야기

Thu, 10 Sep 2026 21:31:59 +0900

이미지 출처: CISA KEV

브라우저는 우리가 하루 중 가장 오래 켜 두는 프로그램임. 메일도 보고, 사내 그룹웨어도 열고, 심지어 방화벽 관리 콘솔까지 브라우저로 들어감. 그런데 그 브라우저 안에서 남의 자바스크립트를 초당 수천 줄씩 실행하고 있다는 사실은 자주 잊게 됨. CVE-2026-87491은 바로 그 지점, Chromium의 자바스크립트 엔진인 V8에서 발생한 Out of Bounds Write(경계 밖 쓰기) 취약점임.

핵심 요약

Chromium V8 엔진의 경계 밖 쓰기 결함으로, 악성 페이지 방문만으로 렌더러 메모리가 조작될 수 있음
브라우저 단독 취약점이라기보다 샌드박스 탈출·권한 상승과 엮이는 연쇄 공격의 1단계로 보는 편이 맞음
방어의 핵심은 자동 업데이트 강제, 브라우저 버전 인벤토리 확보, 그리고 재시작하지 않는 사용자를 찾아내는 일

1. Out of Bounds Write가 V8에서 갖는 의미

경계 밖 쓰기는 이름 그대로 할당된 메모리 범위를 넘어선 위치에 값을 기록하는 결함임. 길이가 10인 배열에 11번째 칸을 쓰는 상황을 떠올리면 개념은 단순함. 문제는 그 단순한 개념이 V8 안에서는 훨씬 무겁게 작동한다는 점임.

V8은 자바스크립트를 그대로 해석하지 않고 JIT 컴파일로 기계어를 만들어 냄. 이 과정에서 "이 배열 길이는 항상 10이다" 같은 최적화 가정을 세우고, 그 가정을 믿고 경계 검사(bounds check)를 통째로 생략함.
공격자가 그 가정을 깨뜨리는 코드 패턴을 만들면, 컴파일러가 지워 버린 검사 자리에 그대로 구멍이 생김.
렌더러 프로세스 힙에는 함수 포인터, 객체 메타데이터, 다른 탭에서 넘어온 데이터 구조가 같이 놓여 있음. 한 칸을 잘못 쓰는 순간 임의 읽기·쓰기로 확장되는 경로가 열림.

그래서 V8 계열 메모리 결함은 "브라우저가 죽는다" 수준에서 끝나지 않고, 대부분 렌더러 코드 실행까지 목표로 삼음. 공격 재현 코드는 여기서 다루지 않지만, 구조만 알아도 왜 이 계열 패치가 항상 급한지는 충분히 이해됨.

2. 실제 공격 흐름은 어떻게 생겼나

이런 결함이 실전에서 쓰일 때의 모양은 거의 정형화되어 있음. 순서대로 정리하면 이럼.

1단계 — 유입: 피싱 링크, 악성 광고(멀버타이징), 혹은 정상 사이트에 삽입된 스크립트. 사용자는 클릭 한 번밖에 하지 않음.
2단계 — 렌더러 장악: V8 결함으로 렌더러 프로세스 안에서 코드 실행. 이 시점까지는 아직 샌드박스 안임.
3단계 — 샌드박스 탈출: 별도의 커널 드라이버나 브라우저 브로커 프로세스 취약점을 엮어서 샌드박스 밖으로 나감.
4단계 — 지속성 확보: 여기서부터는 평범한 엔드포인트 침해와 똑같음. 스케줄러 등록, 자격 증명 탈취, 내부망 정찰.

방어자 입장에서 반가운 소식이 하나 있다면, 2단계에서 3단계로 넘어가는 벽이 꽤 두껍다는 점임. 사이트 격리(Site Isolation)와 샌드박스가 제대로 켜져 있으면 렌더러 하나를 잃어도 즉시 전면 침해로 이어지지는 않음. 그래서 이 구간의 설정을 건드리지 않는 것이 생각보다 중요한 방어임.

3. 탐지 관점 — 무엇을 볼 것인가

솔직히 말하면 렌더러 안에서 벌어지는 익스플로잇 자체를 EDR이 직접 보기는 어려움. 그래서 탐지는 대부분 "결과의 흔적"을 잡는 쪽으로 설계함.

브라우저의 비정상 자식 프로세스: chrome.exe나 msedge.exe가 powershell.exe, cmd.exe, rundll32.exe, mshta.exe를 띄우는 순간은 거의 언제나 조사 대상임. 렌더러 익스플로잇 이후 단계에서 가장 먼저 드러나는 신호임.
반복되는 렌더러 크래시: 익스플로잇은 한 번에 성공하지 않음. 힙 정렬(heap grooming)이 어긋나면 탭이 죽음. 특정 단말에서 짧은 시간 안에 브라우저 크래시가 몰린다면 정황 증거로 볼 만함. Windows 이벤트 로그의 애플리케이션 오류(1000번대)를 브라우저 프로세스로 필터링해 두면 유용함.
렌더러 프로세스의 네트워크 시도: 정상적으로는 네트워크 서비스 프로세스가 통신을 담당함. 렌더러가 직접 외부로 나가려는 흔적은 이상 신호임.
브라우저 프로필 디렉터리의 이상 변화: 확장 프로그램이 조용히 추가되거나 Preferences 파일이 예상 밖 시점에 바뀌는 것도 후속 단계에서 자주 보임.
프록시·DNS 로그: 짧은 수명의 도메인, 신규 등록 도메인으로의 첫 접속. 익스플로잇 킷은 여전히 이 패턴을 벗어나지 못함.

4. 완화 — 우선순위대로

이 계열 취약점의 대응은 화려한 기술보다 지루한 운영이 승부를 가름. 순서대로 하면 이럼.

업데이트를 강제하고, 재시작까지 확인함. Chromium 계열은 패치를 받아도 브라우저를 재시작해야 적용됨. 몇 주째 탭 300개를 켜 둔 채 재시작을 미루는 단말이 조직마다 반드시 있음. 그룹 정책의 RelaunchNotification과 RelaunchNotificationPeriod로 강제 재시작 기한을 두는 편을 개인적으로 추천함.
버전 인벤토리를 실제로 수집함. "자동 업데이트 켜 뒀으니 되겠지"는 검증이 아님. 자산 관리 도구나 EDR 질의로 브라우저 버전 분포를 뽑아 보면, 뒤처진 단말 비율에 놀라는 경우가 많음. Chrome, Edge, Whale, 그리고 Electron 기반 사내 앱까지 같이 봐야 함. Electron 앱은 V8을 품고 있으면서도 자동 업데이트가 없는 경우가 흔함.
사이트 격리와 샌드박스를 끄지 않음. 성능 튜닝이나 특정 업무 시스템 호환 때문에 관련 플래그를 해제해 둔 조직이 의외로 있음. 한번 점검해 볼 가치가 충분함.
고위험 사용자에게는 추가 층을 둠. 임원, 개발자, 관리자 계정 사용자에게는 강화된 보안 모드나 원격 브라우저 격리를 검토할 만함. 전사 적용은 부담스러워도 대상을 좁히면 현실적임.
확장 프로그램을 허용 목록으로 관리함. 브라우저 공격면은 엔진만이 아님. 오히려 확장 쪽이 더 조용하고 오래감.

5. 학습자에게 남기고 싶은 것

브라우저 취약점을 공부하다 보면 처음엔 익스플로잇 기법 이름들에 압도되기 쉬움. 근데 계속 보다 보니 결국 반복되는 건 몇 가지 축이더라. 메모리 안전성, 최적화가 만드는 가정, 그리고 그 가정이 깨지는 지점. V8이든 다른 엔진이든 이 구조는 크게 다르지 않음.

실습으로 이어 가고 싶다면 순서를 이렇게 잡는 걸 개인적으로 추천함. 먼저 자바스크립트 배열의 내부 표현과 elements kind 개념을 읽어 보고, 그 다음 JIT가 어떤 조건에서 경계 검사를 제거하는지 컴파일러 관점 자료를 보고, 마지막으로 공개된 패치 커밋 diff를 읽어 보는 것. 패치 diff는 정말 좋은 교재임. "여기에 검사 한 줄이 추가되었다"는 사실 자체가 취약점의 본질을 한 줄로 요약해 주니까.

정리하면 이럼. 이번 건은 특별히 새로운 종류의 위협이라기보다, 브라우저 패치 주기를 조직이 제대로 굴리고 있는지 확인하는 시험지에 가까움. 오늘 자기 조직의 브라우저 버전 분포를 한 번만 뽑아 보자. 생각보다 할 일이 명확해질 것임. 다들 각자 환경에서 확인해 보고, 재시작 강제 정책 어떻게 운영하고 계신지 댓글로 공유해 주면 같이 배워 보아요!

방화벽이 스스로 무너질 때 — Fortinet 힙 오버플로우(CVE-2025-25249) 대응 노트

Thu, 10 Sep 2026 19:01:58 +0900

이미지 출처: CISA KEV

경계 장비는 다른 자산을 지켜주는 존재라서, 정작 그 장비 자신이 무너지는 시나리오는 잘 상상하지 않게 됨. 그런데 방화벽·VPN 게이트웨이 계열에서 반복적으로 나오는 결함 유형을 들여다보면, 공격 표면이 가장 넓은 자산이 곧 가장 방어가 얇은 자산이라는 역설이 그대로 드러남. CVE-2025-25249는 Fortinet 여러 제품에 걸친 힙 기반 버퍼 오버플로우로 분류된 항목이고, 이런 유형은 한 번 성립하면 인증 이전 단계에서 장비 제어권 근처까지 밀고 들어갈 수 있어 방어자 입장에서 가장 신경이 쓰이는 계열임.

핵심 요약

Fortinet 다수 제품에 영향을 주는 힙 기반 버퍼 오버플로우 결함으로, 메모리 손상을 통해 장비 동작을 흔들 수 있는 유형임
경계 장비 특성상 노출면이 넓고 패치 창을 잡기 어려워, 관리 인터페이스 노출 차단과 임시 완화가 실질적인 1차 방어선이 됨
탐지는 페이로드 시그니처보다 비정상 종료·재시작·크래시 로그·세션 붕괴 패턴을 보는 쪽이 현실적임

1. 힙 오버플로우가 왜 경계 장비에서 유독 무서운가

스택 오버플로우는 카나리·ASLR·NX 같은 방어책이 비교적 촘촘하게 깔려 있어서 요즘은 단순 리턴 주소 덮어쓰기로 끝나는 경우가 드묾. 반면 힙은 사정이 좀 다름. 힙 청크 옆에 무엇이 놓이는지는 프로그램이 메모리를 어떤 순서로 쓰고 반납했는지에 따라 달라지고, 공격자가 요청 크기와 순서를 조절해 그 배치를 어느 정도 유도할 수 있음. 그래서 힙 오버플로우는 "한 바이트 넘쳤다"에서 끝나지 않고, 옆에 있던 함수 포인터·구조체 메타데이터·길이 필드를 건드리는 방향으로 확장되는 경우가 있음.

경계 장비는 여기에 조건이 하나 더 붙음. 인증을 처리하기 전에 이미 요청을 파싱하고 있어야 한다는 점임. 프로토콜 헤더를 읽고, 길이 필드를 해석하고, 버퍼에 복사하는 그 지점은 정의상 누구나 도달할 수 있는 코드임. 길이 검증이 한 군데만 어긋나도 인증 없는 원격 상대에게 메모리 조작 기회를 넘겨주는 셈이 되는 거고, 이게 방화벽·VPN 계열 CVE가 늘 높은 등급을 받는 이유임.

2. 이 결함을 방어자 시선으로 읽는 법

세부 익스플로잇 경로를 쫓는 건 공격 연구자의 몫이고, 운영하는 입장에서 실제로 필요한 판단은 훨씬 단순함. 다음 세 가지만 정리되면 대응 우선순위가 나옴.

도달 가능성 — 문제가 되는 서비스 포트가 인터넷에서 직접 보이는가, 아니면 특정 대역에서만 열려 있는가
인증 요구 여부 — 인증 전 단계에서 파싱되는 경로인가. 인증 전이면 사실상 전 세계가 잠재 공격자임
영향 범위 — 성공 시 서비스 중단에 그치는가, 코드 실행까지 이어질 여지가 있는가

메모리 손상 계열은 이 셋 중 앞의 둘이 나쁘게 나오면 나머지 판단을 기다릴 이유가 없음. 벤더가 상세를 공개하기 전이라도 노출면부터 줄여놓고 패치를 기다리는 순서가 맞다고 개인적으로는 봄. 취약점 상세가 공개되는 시점과 실제 스캐닝이 시작되는 시점의 간격은 요즘 며칠 단위가 아니라 시간 단위로 좁혀졌음.

3. 지금 당장 손댈 수 있는 완화 조치

패치 적용이 최종 답이지만, 이중화되지 않은 경계 장비는 재부팅 창 하나 잡는 데도 며칠이 걸리는 게 현실임. 그 사이를 버티는 조치들임.

관리 인터페이스를 공인 IP에서 걷어내기 — HTTPS 관리 화면, SSH, 그리고 벤더 전용 관리 프로토콜 포트가 외부에 열려 있는지 외부 스캐너 관점에서 직접 확인해볼 것. 내부에서 방화벽 정책만 읽으면 놓치는 예외 규칙이 꼭 하나씩 있음
trusted host 지정 — Fortinet 계열은 관리자 계정별로 접속 허용 대역을 제한할 수 있음. 이건 취약점 유무와 무관하게 상시로 켜둬야 하는 설정임
불필요한 서비스 비활성화 — 쓰지 않는 VPN 게이트웨이, 쓰지 않는 웹 포털은 켜져 있다는 사실 자체가 위험임. "언젠가 쓸 것 같아서" 열어둔 포트가 가장 오래 방치됨
지원 종료 모델 식별 — 패치가 나와도 받을 수 없는 구형 장비가 조직 어딘가에 반드시 있음. 이 목록을 미리 갖고 있으면 사고 때 판단이 빨라짐

4. 탐지는 페이로드가 아니라 '흔들림'을 봐야 함

메모리 손상 취약점의 탐지에서 흔한 착각이 하나 있음. 특정 바이트 패턴을 IPS 룰로 잡으면 된다는 생각인데, 힙 오버플로우 익스플로잇은 대상 펌웨어 버전과 메모리 배치에 맞춰 페이로드가 매번 달라짐. 그래서 시그니처는 이미 알려진 PoC 한두 개만 걸러내고 나머지는 통과시키기 쉬움.

대신 이런 신호들이 훨씬 정직함.

데몬 크래시와 자동 재시작 기록 — 익스플로잇 개발은 성공보다 실패가 압도적으로 많음. 그 실패가 로그에 크래시로 남음. 원인 없는 프로세스 재시작이 짧은 시간에 반복된다면 그것부터 봐야 함
세션 테이블·VPN 터널의 갑작스러운 붕괴 — 사용자 민원보다 먼저 모니터링에 잡히도록 임계값을 잡아둘 것
관리 계정 로그인 성공 이력의 이상 — 낯선 원본 IP, 업무 시간 외 접속, 평소 쓰지 않던 인증 경로
설정 변경 이력 — 관리자 추가, VPN 정책 수정, 로그 전송 설정 해제. 특히 마지막 항목은 침해 후 흔적을 지우려는 전형적인 동작임

여기서 전제가 하나 필요함. 장비 로그를 외부 수집기로 보내고 있어야 한다는 것. 장비 자체가 손상된 상황에서 그 장비 안의 로그를 믿을 수는 없음. syslog 전송이 안 걸려 있는 경계 장비가 있다면, 이번 CVE와 별개로 그게 더 큰 구멍임.

5. 침해가 의심될 때의 순서

메모리 손상으로 장비가 장악됐다고 의심되는 상황이라면, 재부팅부터 하고 싶은 충동이 생김. 그런데 그러면 메모리에만 남아 있던 증거가 통째로 날아감. 순서를 바꿔야 함.

먼저 외부 수집기에 쌓인 로그를 별도로 보존. 장비를 만지기 전에 함
관리자 계정 목록, VPN 사용자 목록, 라우팅·정책 설정을 현재 상태 그대로 덤프
인증 정보는 전부 오염된 것으로 가정. 로컬 관리자 비밀번호뿐 아니라 그 장비가 들고 있던 인증서·사전 공유 키·연동 계정까지 포함
펌웨어 업데이트만으로 백도어가 사라진다고 단정하지 말 것. 설정 파일에 심긴 항목은 업그레이드 후에도 살아남음

6. 마무리

경계 장비 취약점 소식이 나올 때마다 느끼는 건, 결국 승부가 갈리는 지점이 취약점 자체보다 자산 목록이 최신인가에 있다는 점임. 어떤 모델이 몇 대 있고, 펌웨어가 몇 버전이고, 관리 화면이 어디까지 열려 있는지를 30분 안에 답할 수 있는 조직은 이런 공지가 떠도 침착하게 움직임. 반대로 그 표가 없으면 공지 내용을 아무리 정독해도 첫 액션이 안 나옴.

그러니 이번 건을 계기로, 우리 조직의 경계 장비 목록을 한 번 열어보는 걸 개인적으로 추천함. 패치 적용은 며칠 걸리더라도 관리 인터페이스 노출 점검과 syslog 전송 확인은 오늘 안에 끝낼 수 있는 일임. 다들 무사히 넘기시길 바라고, 각자 현장에서 쓰고 있는 완화 팁 있으면 댓글로 공유해 주세요. 같이 정리해두면 다음 공지 때 훨씬 덜 당황할 수 있음.

정문은 잠갔는데 배달구가 열려 있었다 — NetScaler 인증 우회(CVE-2026-19490)를 방어자 시선으로

Thu, 10 Sep 2026 13:01:51 +0900

이미지 출처: CISA KEV

건물 출입을 통제할 때 가장 흔한 실수는 정문만 신경 쓰는 것임. 경비 데스크, 출입증 리더, CCTV까지 정문에는 전부 붙여두지만 뒤편 배달구나 지하 주차장 계단은 "거긴 원래 직원만 쓰니까"라는 이유로 방치됨. CVE-2026-19490으로 정리된 Citrix NetScaler의 인증 우회 문제도 결국 같은 구조임. 로그인 폼이라는 정문은 멀쩡한데, 같은 목적지로 이어지는 다른 통로가 인증 검사를 건너뛴 채 열려 있었던 것.

핵심 요약

NetScaler ADC/Gateway에서 인증을 거치지 않는 대체 경로(Alternate Path or Channel)로 보호된 기능에 접근할 수 있는 인증 우회 결함임
익스플로잇이 성공해도 로그인 실패 기록이 남지 않기 때문에, 실패 카운트가 아니라 "인증 이벤트 없이 발생한 세션·설정 접근"을 탐지 기준으로 삼아야 함
패치 적용이 1순위이고, 그 전까지는 관리 인터페이스 분리·NSIP 접근 통제·세션 전수 만료가 현실적인 완화책임

대체 경로 취약점이란 무엇인가

CWE 분류로는 288번, "Authentication Bypass Using an Alternate Path or Channel"에 해당함. 이름이 길지만 개념은 단순함. 하나의 기능에 도달하는 경로가 두 개 이상 존재하는데, 개발자가 주요 경로에만 인증 검사를 붙여둔 상황임.

실무에서 이런 구조가 생기는 이유는 대부분 기능이 누적되면서임. 처음 설계할 때는 경로가 하나였는데, 나중에 모바일 클라이언트용 엔드포인트가 추가되고, 내부 헬스체크용 URL이 붙고, 레거시 호환을 위한 예외 규칙이 들어감. 그때마다 "이건 내부에서만 부르니까", "이건 그냥 상태 확인용이니까" 하는 판단이 들어가면서 인증 필터의 예외 목록이 길어지다 보니, 어느 순간 그 예외 하나가 보호된 기능까지 이어져 버리는 것.

NetScaler처럼 인증 게이트웨이 역할 자체를 담당하는 장비에서 이 문제가 발생하면 파급력이 다름. 이 장비는 뒤에 있는 내부 서비스들의 신원 검증을 대신 처리해주는 존재임. 문지기가 뚫리면 문지기 하나만 뚫린 게 아니라, 그 문지기를 믿고 자기 검증을 생략한 뒤쪽 서비스 전부가 노출됨.

왜 이 장비가 매년 표적이 되는가

NetScaler ADC와 Gateway가 공격자에게 인기 있는 이유는 세 가지로 정리됨.

인터넷에 노출될 수밖에 없는 위치: 원격 접속과 VPN을 담당하는 장비라 방화벽 뒤에 숨길 수가 없음. 정의상 외부에서 접근 가능해야 동작함.
인증 정보와 세션의 집결지: 사용자 인증 토큰, LDAP 바인딩 계정, 백엔드 서버 목록이 한곳에 모여 있음. 한 번 침투하면 얻을 수 있는 정보의 밀도가 매우 높음.
패치 주기가 느림: 서비스 중단을 각오해야 하는 핵심 인프라라 "다음 정기 점검 때"로 미뤄지는 경우가 많음. 공격자는 이 시차를 노림.

과거 NetScaler 계열에서 반복적으로 터진 사례들을 보면 패턴이 비슷함. 공개 후 며칠 안에 스캔 트래픽이 급증하고, 패치가 늦은 조직부터 순서대로 웹셸이 심어짐. 그래서 이 장비의 취약점은 "우리한테 올 확률"이 아니라 "언제 오는가"의 문제로 다루는 게 맞다고 봄.

탐지: 무엇을 봐야 하는가

인증 우회 공격의 가장 성가신 특성은 실패 흔적을 남기지 않는다는 점임. 브루트포스나 크리덴셜 스터핑은 실패 로그가 산더미처럼 쌓이니까 임계값 기반 룰로 잡히지만, 인증 우회는 애초에 인증 절차를 거치지 않으니 실패할 것도 없음. 로그인 실패율 대시보드만 보고 있으면 아무 일도 없는 것처럼 보임.

그래서 탐지 관점을 뒤집어야 함. 핵심 질문은 "실패가 몇 번 있었나"가 아니라 "성공에 앞선 인증 이벤트가 실제로 존재하는가"임. 실무에서 확인할 지점들을 정리하면 이렇게 됨.

인증 이벤트 없는 세션 생성: 세션이 만들어졌는데 그 직전에 대응하는 로그인 성공 기록이 없는 경우. 이게 가장 직접적인 신호임.
관리 기능 접근 경로의 이상: 평소 관리자가 접근하던 경로·출발지 IP 대역이 아닌 곳에서 설정 조회나 변경이 일어난 경우.
비정상적인 요청 형태: 정상 클라이언트라면 거치지 않을 순서로 엔드포인트를 호출하거나, 헤더 구성이 브라우저·정품 클라이언트와 다른 요청. User-Agent가 도구 기본값 그대로인 경우도 여기 포함됨.
파일시스템 변화: 웹 루트 하위에 새로 생긴 스크립트 파일, 예정에 없던 시각에 갱신된 설정 파일. 침투 이후 지속성 확보 단계의 흔적임.
아웃바운드 연결: 어플라이언스가 스스로 외부로 나가는 트래픽. 게이트웨이 장비가 낯선 목적지로 먼저 연결을 시도한다면 그 자체로 조사 대상임.

개인적으로는 마지막 항목을 제일 추천함. 침해 여부를 판단할 때 인바운드 로그는 노이즈가 너무 많아 가려내기 어렵지만, 아웃바운드는 정상 상태에서의 목적지 목록이 짧아서 이상치가 훨씬 선명하게 드러남.

완화: 순서대로

대응은 우선순위대로 진행하는 게 좋음. 한꺼번에 다 하려다 아무것도 못 끝내는 경우를 여러 번 봤음.

1. 패치: 벤더가 배포한 수정 버전 적용이 유일한 근본 해결책임. 대체 경로 문제는 WAF 룰로 완벽히 막기 어려움. 경로가 하나가 아니라는 게 문제의 본질이라, 알려진 패턴 하나를 차단해도 다른 표현이 남아 있을 수 있음.
2. 세션 전수 만료: 패치를 적용해도 이미 발급된 세션은 그대로 살아 있음. 침해 시점이 패치 이전일 가능성을 고려해 기존 세션과 토큰을 모두 무효화해야 함. 이걸 빠뜨려서 패치 후에도 공격자가 계속 붙어 있던 사례가 실제로 있었음.
3. 관리 인터페이스 격리: NSIP와 관리용 접근은 인터넷에서 아예 보이지 않아야 함. 전용 관리망이나 점프 호스트를 거치도록 강제하고, 접근 가능한 출발지 IP를 화이트리스트로 좁혀두는 게 기본임.
4. 자격증명 회전: 장비에 저장돼 있던 LDAP 바인딩 계정, 백엔드 인증 정보, API 키를 교체함. 침해가 확인되지 않았더라도 노출 가능성이 있었다면 회전하는 쪽이 안전함.
5. 사후 점검: 설정 파일을 알려진 정상본과 비교하고, 계정 목록에 추가된 항목이 없는지 확인함. 어플라이언스는 일반 서버보다 포렌식이 까다로워서, 평상시에 설정 스냅샷을 주기적으로 떠두면 이럴 때 비교 기준이 생김.

구조적으로 남는 교훈

이번 건에서 가져갈 것은 특정 버전 번호가 아니라 설계 원칙 쪽이라고 봄. 인증 검사는 진입 경로마다 붙이는 게 아니라 자원 앞에 붙여야 한다는 것. 경로 A, 경로 B, 경로 C에 각각 검사를 다는 방식은 경로 D가 추가되는 순간 무너짐. 반대로 "이 기능을 실행하려면 유효한 신원이 필요하다"를 기능 자체의 조건으로 못 박아두면, 어떤 경로로 들어와도 같은 검사를 통과해야 함.

그리고 게이트웨이를 믿고 뒤쪽 서비스의 검증을 생략하는 관행도 다시 볼 때가 됐음. 내부망이니까 안전하다는 전제는 문지기가 온전할 때만 성립하는데, 지금까지의 사례들은 문지기가 생각보다 자주 뚫린다는 걸 보여줬음. 내부 서비스도 자기 앞에 온 요청의 신원을 한 번 더 확인하도록 만들어두면, 게이트웨이가 무너져도 피해 범위가 한 단계에서 끊김.

여러분 조직의 원격 접속 장비는 마지막으로 언제 패치했는지 기억나시는지. 이 글 읽고 나서 바로 확인해보시길 권함. 확인하다가 애매한 부분 나오면 댓글로 남겨주세요, 같이 찾아보아요!

RMM 콘솔에 심긴 한 줄이 관리 대상 전체로 번지는 구조 — N-central 코드 인젝션 정리

Wed, 9 Sep 2026 21:31:45 +0900

이미지 출처: CISA KEV

관리형 서비스 제공사(MSP)의 야간 당직 화면을 상상해 보면 이해가 빠름. 한 화면에 고객사 수십 곳, 엔드포인트 수천 대가 트리 구조로 늘어서 있고, 오른쪽 클릭 한 번이면 스크립트가 원격지 서버에서 실행됨. N-able N-central은 정확히 그런 도구임. 그래서 이 제품에서 정적 코드 인젝션(static code injection) 계열 취약점이 보고되면, 그 영향 범위는 콘솔 한 대가 아니라 그 콘솔이 관리하는 자산 전부로 계산해야 함. CVE-2026-86218이 신경 쓰이는 이유가 바로 그 지점임.

핵심 요약

N-able N-central에서 코드 인젝션 계열 결함이 보고됨 — 관리 서버 하나의 문제가 아니라 관리 대상 전체로 번질 수 있는 구조라는 점이 본질임
정적 코드 인젝션은 입력이 저장·기록 단계에서 실행 경로로 흘러드는 유형이라, 요청 한 건만 보는 탐지로는 잘 잡히지 않음
방어는 벤더 패치 적용을 최우선으로 하되, 관리 콘솔 노출면 축소·스크립트 실행 로그 감사·계정 권한 분리를 함께 묶어야 실효가 있음

정적 코드 인젝션이 다른 인젝션과 다른 점

인젝션이라고 하면 보통 SQL 인젝션이나 명령 주입을 먼저 떠올림. 그런데 정적 코드 인젝션은 결이 조금 다름. 공격자가 넣은 문자열이 그 자리에서 바로 실행되는 게 아니라, 애플리케이션이 나중에 읽어 들이는 코드나 설정, 템플릿 형태로 저장된 다음 그 파일이 해석되는 시점에 실행됨.

주입 시점과 실행 시점이 분리됨 — 로그를 시간순으로 훑어도 두 사건이 이어져 보이지 않음
저장된 코드가 정상 코드와 같은 신뢰 수준으로 실행됨 — 애플리케이션 계정 권한을 그대로 물려받음
패치를 적용해도 이미 심어진 잔재는 남을 수 있음 — 취약점을 막는 것과 침해 흔적을 지우는 건 별개의 작업임

마지막 항목이 특히 중요함. 취약점 대응을 "패치했으니 끝"으로 마무리하다 보면, 정작 남아 있는 지속성 아티팩트를 놓치게 됨. 정적 코드 인젝션 계열을 다룰 때는 패치와 무결성 점검을 항상 한 세트로 묶어서 생각하는 게 안전함.

RMM이라는 위치가 만드는 증폭

N-central 같은 RMM(원격 모니터링·관리) 플랫폼은 설계상 모든 관리 대상에 대한 실행 권한을 가지고 있음. 이건 결함이 아니라 그 제품의 존재 이유임. 문제는 그 구조가 침해 시나리오에서 그대로 증폭 장치가 된다는 것임.

에이전트는 관리 서버를 신뢰하도록 설정돼 있음 — 서버가 내리는 명령을 검증할 이유가 없음
MSP 환경이면 고객사 경계를 넘어 확산될 수 있음 — 침해 하나가 계약 전체의 사고가 됨
정상 관리 트래픽과 악성 명령이 같은 채널·같은 포맷을 씀 — 네트워크 계층에서 구분하기 어려움

이런 특성 때문에 랜섬웨어 조직들이 몇 년째 RMM 제품을 우선 표적으로 삼아 왔음. 침투 후 횡적 이동을 직접 할 필요 없이, 이미 깔려 있는 배포 채널을 쓰면 되니까 말임. 개인적으로는 RMM·백업 콘솔·EDR 관리 서버 이 세 가지를 같은 등급의 크라운 주얼로 놓고 관리 정책을 세우는 걸 추천함.

탐지는 어디를 봐야 할까

주입 자체를 실시간으로 잡는 건 어려움. 대신 주입 이후에 반드시 남는 흔적을 기준으로 잡는 게 현실적임.

파일 무결성 모니터링: N-central 설치 경로와 설정·템플릿 디렉터리를 FIM 대상에 넣고, 패치·업그레이드 창 바깥의 변경은 전부 조사 대상으로 처리
프로세스 계보 이상: 웹 애플리케이션 프로세스나 서비스 계정에서 셸·스크립트 인터프리터가 파생되는 패턴은 정상 운영에서 거의 나오지 않음
스크립트 배포 감사: 콘솔에서 실행된 작업·스크립트 이력을 주기적으로 뽑아, 담당자별 승인 기록과 대조 — 근무 시간 밖 대량 배포는 특히 우선순위 높게
계정 행위: 관리자 계정 신규 생성, 권한 상승, 익숙하지 않은 대역에서의 로그인. 인젝션이 성공했다면 그 다음 단계는 대개 지속성 확보임
아웃바운드 연결: 관리 서버가 평소 통신하지 않던 외부 목적지로 나가는 트래픽. 관리 서버는 통신 상대가 비교적 정형화돼 있어서 기준선을 잡기 쉬운 편임

완화는 순서가 중요함

급한 순서대로 정리하면 이렇게 됨.

1) 벤더 공지 확인 후 패치: 자사에서 돌리는 빌드 번호를 먼저 확인하고, 벤더가 안내한 대상 버전인지 대조. 클라우드 호스팅형과 자체 설치형은 조치 방법이 다르니 구분해서 진행
2) 관리 인터페이스 노출 축소: 콘솔을 인터넷에 열어 둔 상태라면 이게 사실상 1순위와 동급임. VPN 뒤로 넣거나 IP 허용 목록을 걸어 접근 자체를 제한
3) 관리자 계정 MFA 전면 적용: 인젝션 이후 단계는 결국 계정 장악으로 이어지는 경우가 많음. 서비스 계정은 대화형 로그인 자체를 차단
4) 소급 점검: 패치 이전 기간의 로그를 되짚어 위 탐지 항목들을 검색. 취약점 공개일이 아니라 취약 코드가 배포된 시점 기준으로 범위를 잡아야 함
5) 복구 경로 분리: 백업 시스템 자격 증명을 RMM 콘솔과 완전히 분리. 관리 채널이 뚫렸을 때 복구 수단까지 같이 넘어가면 선택지가 사라짐

학습자 입장에서 남는 것

이런 사례를 볼 때마다 느끼는 건데, 취약점 하나의 기술적 세부보다 그 소프트웨어가 인프라에서 차지하는 위치가 실제 피해 규모를 훨씬 잘 설명해 주는 것 같음. 같은 등급의 결함이라도 사내 위키에 있으면 사고 하나로 끝나지만, RMM 콘솔에 있으면 관리 대상 전부가 사정권에 들어가니까 말임. 그래서 자산 목록을 만들 때 취약점 점수만 나열하지 말고 "이 시스템이 뚫리면 몇 대까지 번지는가"라는 열을 하나 더 두는 걸 개인적으로 추천함. 이 열 하나가 패치 우선순위를 정할 때 생각보다 많은 걸 정리해 줌.

혹시 RMM이나 유사한 중앙 관리 도구를 운영 중이라면, 이번 기회에 콘솔 노출 여부부터 한번 확인해 보시길. 확인해 보고 의외의 결과가 나왔다면 댓글로 공유해 주세요. 같이 정리해 보아요!

심볼릭 링크는 왜 아직도 Windows 권한 상승의 단골 통로일까 (CVE-2026-81963)

Wed, 9 Sep 2026 19:02:03 +0900

이미지 출처: CISA KEV

서비스 하나가 C:\Windows\Temp 밑에 로그 파일을 만든다. 만들고, 쓰고, 지운다. 그 폴더는 사용자 누구나 파일을 만들 수 있는 곳이고, 서비스는 SYSTEM 권한으로 돈다. 이 두 문장이 한 문단 안에 같이 있으면, 그때부터는 취약점 이야기가 됨. CVE-2026-81963으로 정리된 Microsoft Windows의 링크 팔로잉(Link Following) 문제도 이 계열에 속함.

핵심 요약

높은 권한 프로세스가 사용자가 통제 가능한 경로를 검증 없이 따라가면서 생기는 권한 상승 유형임
공격은 파일을 깨는 게 아니라 경로를 바꿔치기하는 것이며, 경쟁 조건 특성상 흔적이 짧게 스쳐 지나감
방어는 패치가 1순위, 그다음이 재분석 지점(reparse point) 생성 탐지와 임시 디렉터리 권한 정리임

링크 팔로잉이 정확히 무슨 뜻인가

파일 시스템에는 "이 경로는 사실 저기를 가리킨다"고 알려주는 장치가 여럿 있음. NTFS의 정션(junction), 심볼릭 링크, 하드 링크, 그리고 객체 관리자 수준의 심볼릭 링크까지. 편의 기능이고 Windows가 오래전부터 쓰던 정상 기능임.

문제는 권한이 높은 코드가 이 링크를 아무 의심 없이 따라갈 때 생김. SYSTEM으로 도는 프로세스가 "C:\Windows\Temp\svc.log를 열고 쓰겠다"고 요청했는데, 그 이름이 사실은 C:\Windows\System32 아래 어딘가를 가리키도록 미리 바꿔져 있었다면? 커널은 요청자의 권한으로 최종 목적지를 열어줌. 권한 검사는 통과함. 애초에 SYSTEM이 요청했으니까. 결과적으로 일반 사용자가 직접은 못 건드릴 파일을 대신 쓰게 만드는 그림이 됨.

여기서 자주 오해하는 부분 하나. 심볼릭 링크를 만들려면 특권이 필요하지 않느냐는 것. 맞는 말이지만 절반만 맞음. 파일 심볼릭 링크는 그렇고, 디렉터리 정션이나 객체 관리자 심볼릭 링크는 일반 권한으로도 만들 수 있는 경로가 존재함. 그래서 이 유형이 십 년 넘게 반복되는 것.

CVE-2026-81963을 어떻게 읽을 것인가

개별 취약점의 세부 동작은 벤더 공지에 담긴 범위 안에서만 이야기하는 게 맞다고 봄. 다만 링크 팔로잉으로 분류된 이슈는 대체로 아래 조건을 공유함.

로컬 접근이 전제됨. 원격에서 바로 터지는 종류가 아니라, 이미 들어온 공격자가 권한을 끌어올리는 데 쓰임
사용자 상호작용이 거의 필요 없음. 링크를 심어두고 대상 프로세스가 동작하기를 기다리면 됨
경쟁 조건(TOCTOU)이 자주 끼어듦. 경로를 검사한 시점과 실제로 여는 시점 사이의 틈을 노림
단독으로는 초기 침투가 안 되지만, 랜섬웨어·자격증명 탈취 단계의 디딤돌로 가치가 큼

그래서 CVSS 숫자만 보고 "로컬이니까 나중에"라고 미루면 곤란함. 침해 사고 타임라인에서 이런 취약점은 항상 중간 지점에 박혀 있음.

탐지: 무엇을 봐야 하는가

공격 자체는 조용함. 익스플로잇 바이너리가 화려하게 뜨지 않고, 링크 하나 만들었다가 지우는 게 전부일 때도 있음. 그래도 볼 수 있는 지점은 있음.

재분석 지점 생성 이벤트. Sysmon 이벤트 ID 2(파일 생성 시각 변경)와 11(파일 생성)을 공용 임시 경로 기준으로 걸어두면 노이즈 대비 효율이 괜찮음. 특히 C:\Windows\Temp, C:\ProgramData 하위, 사용자 Temp에서 디렉터리가 만들어졌다 짧게 사라지는 패턴이 신호임
객체 접근 감사(4656, 4663). 보호 대상 디렉터리에 SACL을 걸고, 예상 밖의 프로세스가 SYSTEM 권한으로 쓰기를 시도하는 순간을 잡음. 전체에 걸면 로그가 폭발하니 대상은 좁게
서비스·설치 프로그램의 임시 경로 사용 이력. 어떤 제품이 공용 경로에 SYSTEM으로 파일을 쓰는지 목록을 미리 만들어두는 것이 사실상 절반임. 정상 목록이 없으면 이상 탐지도 없음
권한 상승 직후의 행동. 링크 트릭 자체보다, 그 뒤에 따라오는 새 서비스 등록·스케줄 작업 생성·LSASS 접근이 더 잘 보임. 탐지 룰의 무게중심을 이쪽에 두는 것도 방법

완화: 순서대로 하면 됨

패치. 뻔하지만 이 유형은 벤더 수정이 유일하게 확실한 답임. 대상 코드가 경로를 열 때 재분석 지점을 거부하거나 최종 경로를 재확인하도록 고쳐지는 것이라 우회 설정으로 대체하기 어려움
리다이렉션 신뢰 정책 활용. Windows에는 특권 프로세스가 비특권 사용자가 만든 링크를 따라가지 못하게 막는 완화 기능이 들어와 있음. 자체 개발한 서비스가 있다면 이 정책을 적용하고, 파일을 열 때 재분석 지점을 따라가지 않는 플래그를 쓰도록 코드를 손보는 게 정석임
공용 임시 디렉터리 정리. 서비스가 굳이 C:\Windows\Temp를 쓸 이유가 없다면 서비스 전용 경로로 옮기고 ACL을 좁힘. "누구나 쓰기 가능 + SYSTEM이 접근"이라는 조합을 하나씩 줄여나가는 작업임
최소 권한. 일반 사용자에게 관리자 권한이 있으면 이런 취약점은 애초에 필요가 없어짐. 반대로 말하면 로컬 관리자 권한 회수가 이 유형 전체에 대한 광역 방어임
자산 목록. 오래된 설치 프로그램, 업데이터, 백신 보조 서비스가 의외로 이런 패턴을 많이 갖고 있음. 벤더 패치가 끊긴 소프트웨어를 찾아내는 게 실질적인 이득이 큼

정리하면서

개인적으로는 이 계열 취약점을 볼 때마다 "신뢰 경계가 어디에 그어져 있나"를 다시 그려보게 됨. 파일 이름은 데이터인데, 높은 권한 프로세스에게는 사실상 명령처럼 작동함. 이름을 통제할 수 있는 사람이 결국 대상을 통제하게 되는 구조인 것.

당장 할 수 있는 건 어렵지 않다고 봄. 이번 달 패치 적용 상태 한 번 확인하고, 공용 임시 폴더에 SYSTEM으로 파일 쓰는 서비스가 뭐가 있는지 목록을 만들어보는 것. 그 두 가지만 해도 다음에 비슷한 CVE가 나왔을 때 대응 속도가 확 달라짐. 각자 환경에서 확인해본 결과가 있으면 댓글로 공유해 주시면 좋겠음. 같이 정리해 나가 보아요!

상품 설명란에 넣은 중괄호 하나 — Adobe Commerce 템플릿 엔진이 그것을 명령으로 읽을 때

Wed, 9 Sep 2026 13:01:48 +0900

이미지 출처: CISA KEV

쇼핑몰 관리자 페이지에서 상품 설명을 편집하다 보면, 굵게·기울임 말고도 이상한 문법이 하나 눈에 띔. {{store url=""}} 같은 중괄호 두 개짜리 지시문. Magento 계열을 만져본 사람이면 다들 한 번쯤 써봤을 그 문법인데, 이게 바로 이번 이야기의 출발점임.

핵심 요약

Adobe Commerce·Magento의 템플릿 엔진이 특수 문자를 제대로 무력화하지 않아, 콘텐츠에 삽입된 지시문이 서버에서 그대로 해석될 수 있는 문제임
공격 표면은 관리자 콘텐츠 필드·이메일 템플릿·CMS 블록처럼 "사용자가 문자열을 넣고 서버가 렌더링하는" 모든 지점임
방어는 패치 적용이 1순위, 그다음이 관리자 권한 최소화·템플릿 필터 화이트리스트 점검·렌더링 로그 기반 탐지임

템플릿 엔진이 왜 취약점의 무대가 되는가

Magento의 템플릿 문법은 원래 편의를 위해 만들어진 것임. 이메일 하단에 매번 스토어 주소를 손으로 적을 순 없으니 {{store}} 같은 지시문을 두고, 렌더링 시점에 실제 값으로 바꿔주는 구조. 문제는 이 "바꿔주는" 동작이 문자열을 데이터가 아니라 코드로 취급한다는 점임.

여기서 특수 요소의 중화(neutralization)가 제대로 안 되면 어떻게 되는지가 CVE-2026-75650의 핵심임. 공격자가 넣은 문자열이 단순 텍스트로 출력되는 게 아니라, 템플릿 파서를 거치면서 지시문 경계를 새로 만들어냄. 파서 입장에서는 "관리자가 정당하게 넣은 지시문"과 "외부에서 흘러들어온 문자열"을 구분할 방법이 없음. 둘 다 똑같은 중괄호로 보이니까.

이런 종류를 서버 사이드 템플릿 인젝션(SSTI)이라고 부름. SQL 인젝션이 쿼리 문법 경계를 넘는 거라면, SSTI는 템플릿 문법 경계를 넘는 것. 그리고 템플릿 엔진은 대개 객체 접근이나 메서드 호출 같은 기능을 품고 있어서, 경계를 한 번 넘으면 도달 범위가 생각보다 훨씬 넓어짐. 개념적으로만 말하면 "출력용 문법이 실행용 문법으로 승격되는 순간"이 위험 지점임.

어디를 봐야 하는가 — 공격 표면 지도

패치를 바로 못 올리는 상황이라면, 최소한 내 쇼핑몰에서 어디가 위험한지는 알고 있어야 함. 템플릿 인젝션이 성립하려면 두 조건이 동시에 필요함: 공격자가 문자열을 심을 수 있는 입력점과 그 문자열을 서버가 템플릿으로 렌더링하는 출력점.

CMS 페이지·블록 — 마케팅팀이 자유롭게 편집하는 영역이라 지시문 사용이 일상적임. 그래서 이상한 지시문이 섞여도 눈에 잘 안 띔
이메일·트랜잭션 템플릿 — 주문 확인, 배송 안내 메일. 렌더링이 백그라운드 큐에서 도는 경우가 많아 흔적이 더 흐림
상품 속성·설명 필드 — 특히 외부 PIM이나 공급사 피드로 자동 동기화되는 환경이면, 내가 직접 입력하지 않은 문자열이 그대로 들어옴
위젯·레이아웃 업데이트 XML — 관리자 UI로 노출된 영역 중 가장 강력한 축에 속함
테마·확장 모듈 — 서드파티 익스텐션이 자체적으로 템플릿 필터를 호출하면서 코어의 안전장치를 우회하는 경우가 실제로 꽤 있음

정리하면 "관리자만 만질 수 있으니 괜찮다"는 전제가 흔들리는 게 문제임. 커머스 운영 조직은 보통 계정이 많음. 마케터, MD, 외주 개발사, 고객센터. 그중 한 계정만 털려도 조건이 성립함.

탐지: 로그에서 무엇을 골라낼 것인가

이 유형은 익스플로잇 순간이 조용해서, 사후 탐지를 미리 설계해두는 게 훨씬 이득임. 개인적으로는 다음 세 겹으로 보는 걸 추천함.

첫째, 콘텐츠 저장 시점의 문자열 검사. DB에서 CMS 블록·페이지·상품 설명 컬럼을 대상으로 중괄호 지시문 패턴을 주기적으로 스캔함. 정상 운영에서 쓰는 지시문 목록(store, media, block, widget 정도)을 화이트리스트로 잡아두고, 그 밖의 이름이 등장하면 알림. 정상 목록이 짧다는 게 오히려 유리한 지점임.

둘째, 렌더링 시점의 이상 징후. 템플릿 필터가 처리하는 과정에서 예외가 나거나, 평소보다 렌더링 시간이 튀거나, PHP 프로세스가 갑자기 외부로 커넥션을 여는 패턴. 특히 웹 서버 계정에서 나가는 아웃바운드 트래픽은 커머스 환경에서 원래 종류가 뻔하기 때문에, 화이트리스트 기반 이그레스 통제가 잘 먹힘.

셋째, 파일 시스템 무결성. 템플릿 인젝션의 최종 목적지는 대개 웹셸 설치나 결제 정보 스키밍 스크립트 삽입임. pub/, var/, generated/ 아래 신규 PHP 파일 생성과 체크아웃 페이지 JS 변경을 감시 대상에 넣어두면, 침해 이후 단계에서라도 잡을 여지가 생김. 커머스는 카드 정보가 흐르는 곳이라 스키머가 붙는 순간 피해가 바로 금전으로 이어짐.

완화: 지금 당장 할 수 있는 순서

보안 패치 적용 — 어도비 보안 공지에 맞춰 해당 버전 라인의 업데이트를 올리는 게 유일한 근본 해결임. 나머지는 전부 시간 벌기임
관리자 URL 은닉과 IP 제한 — 관리 경로를 랜덤화하고, 가능하면 사무실·VPN 대역으로만 접근을 제한함. 이것만으로도 대량 스캐닝의 대부분이 걸러짐
관리자 계정 권한 분리 — 마케팅 계정에 레이아웃 XML 편집 권한까지 주고 있진 않은지 역할(Role) 설정을 다시 봄. 2FA는 예외 없이 전 계정 적용
웹 서버 아웃바운드 차단 — PHP-FPM 계정이 임의 외부 호스트로 나가지 못하게 막음. 템플릿 인젝션이 성공해도 2차 페이로드 다운로드 단계에서 끊김
디스크 쓰기 권한 최소화 — 웹 루트 대부분을 읽기 전용으로 두고 쓰기가 필요한 디렉터리만 예외 처리함. 여기서 PHP 실행을 막아두면 웹셸 시나리오가 상당히 무력해짐
서드파티 모듈 재점검 — 코어를 패치해도 확장 모듈이 자체 필터를 돌리면 구멍이 남을 수 있음. 템플릿 필터를 직접 호출하는 코드가 있는지 확인해볼 것

마무리하며

커머스 취약점을 볼 때마다 느끼는 건데, 이쪽은 다른 분야보다 패치까지 걸리는 시간이 유독 길다는 점이 진짜 문제인 것 같음. 쇼핑몰은 멈추면 매출이 바로 꺾이니까 "다음 정기 점검 때"로 미루기 쉽고, 그 사이 공격자는 자동화 스캐너로 이미 전 세계를 훑고 있음. 실제로 커머스 플랫폼 취약점은 공개 후 며칠 안에 대량 스캐닝이 시작되는 게 거의 공식처럼 굳어져 있음.

그래서 개인적으로 추천하는 건, 패치 창구를 미리 만들어두는 습관임. "긴급 보안 패치는 트래픽 최저 시간대에 30분 안에 적용한다"는 절차를 평소에 합의해두면, 막상 공지가 떴을 때 회의부터 하느라 하루를 날리는 일이 없어짐. 기술적 방어보다 조직적 준비가 결국 더 크게 작동하는 영역인 것 같기도 하고.

혹시 Magento나 Adobe Commerce를 운영 중이시라면, 오늘 관리자 계정 목록 한 번만 열어보시길. 퇴사한 외주 개발사 계정이 아직 살아있는 경우가 생각보다 많음. 저도 이번에 정리하면서 몇 개 발견했음. 여러분 환경에서는 어떤 항목이 제일 먼저 걸렸는지 댓글로 공유해주시면 같이 배워보아요!

SonicWall SMA1000, 신뢰받는 장비가 대신 요청을 보낸다 (CVE-2026-83548)

Tue, 8 Sep 2026 21:31:59 +0900

이미지 출처: CISA KEV

방화벽 로그를 뒤지다 보면 가끔 이상한 줄을 만남. 내부 관리 대역으로 향하는 HTTP 요청이 찍혀 있는데, 출발지가 외부 공격자 IP가 아니라 우리 쪽 원격접속 장비인 경우임. 공격자가 내부로 들어온 게 아니라, 장비에게 "대신 좀 다녀와 줘"라고 시킨 결과인 것 같다는 생각이 드는 순간이 바로 SSRF를 의심해야 할 지점임. SonicWall SMA1000 계열에서 보고된 CVE-2026-83548이 딱 그 유형에 해당함.

핵심 요약

SonicWall SMA1000 어플라이언스에서 서버 측 요청 위조(SSRF) 취약점(CVE-2026-83548)이 공개됨. 원격 사용자가 장비를 경유해 내부 자원으로 요청을 유도할 수 있는 구조임.
SMA1000은 DMZ·경계에 놓이고 내부망 접근 권한을 가진 장비라, SSRF 한 건이 곧 내부 정찰·메타데이터 탈취로 이어질 수 있음.
방어는 벤더 펌웨어 적용이 1순위, 그 다음이 관리 인터페이스 노출 차단 + 장비 발신(outbound) 트래픽 화이트리스트 + 프록시 로그 기반 탐지임.

1. SMA1000이라는 자리의 특수성

SMA1000(Secure Mobile Access)은 원격 근무자·협력사를 사내로 들여보내는 관문 장비임. 그래서 태생적으로 두 가지 성질을 동시에 가짐.

외부(인터넷)에서 접근 가능해야 함 — 안 그러면 원격접속이 성립 안 됨.
내부(사내망·인증서버·디렉터리)로 말을 걸 수 있어야 함 — 인증 연동, 리소스 프록시가 그 역할임.

일반 웹 서버에서 발생한 SSRF와 경계 장비에서 발생한 SSRF의 체감 위험도가 다른 이유가 여기 있음. 보통의 SSRF는 "서버가 접근 가능한 범위"가 제한적이지만, VPN 게이트웨이는 애초에 내부를 향해 열려 있는 신뢰 구간에 앉아 있음. 즉 취약점의 파급 범위 = 그 장비가 평소에 닿을 수 있는 모든 곳이 되어버림.

2. SSRF는 개념적으로 어떻게 성립하는가

실행 가능한 페이로드를 적을 이유는 없고, 원리만 정리하면 충분함. SSRF는 대체로 이런 흐름을 탐.

애플리케이션이 사용자 입력값으로 URL이나 호스트명을 받아 서버 쪽에서 요청을 수행하는 기능이 있음(리소스 프록시, 헬스체크, 원격 리소스 가져오기, 리디렉트 처리 등).
입력값 검증이 "형식이 URL 맞나" 수준에 그치고, 목적지가 어디인지는 제대로 제한하지 않음.
공격자는 목적지를 내부 대역(사설 IP, 루프백, 클라우드 메타데이터 주소)으로 바꿔서 장비가 대신 요청을 보내게 만듦.
응답이 그대로 돌아오면 정보 유출, 응답이 안 보여도 지연·상태코드 차이로 내부 포트 스캔이 가능해짐(블라인드 SSRF).

여기서 방어자가 놓치기 쉬운 게 우회 기법의 다양성임. 단순히 "127.0.0.1이나 10.0.0.0/8 문자열이면 차단"으로 막았다고 안심하다 보면, DNS가 사설 IP로 응답하게 만드는 방식이나 리디렉트를 한 번 태우는 방식, 검증 시점과 실제 요청 시점 사이의 시간차를 노리는 방식에서 그대로 뚫림. 차단은 문자열이 아니라 실제 연결 시점의 목적지를 기준으로 해야 함.

3. 방어자가 먼저 손대야 할 순서

개인적으로는 이런 순서를 추천함. 완벽한 설계보다 "오늘 안에 줄일 수 있는 노출"이 먼저인 것 같다는 생각임.

벤더 공지 기준 펌웨어 적용. 경계 장비는 자체 패치 외에 근본 해결책이 없음. 유지보수 창구가 끊긴 구형 라이선스라면 그 사실 자체를 위험으로 등재해야 함.
관리 인터페이스를 인터넷에서 분리. 서비스 포털과 관리 포털이 같은 주소에서 열려 있는지 확인. 관리 접근은 점검용 대역이나 별도 VPN 뒤로 옮기는 게 원칙임.
장비의 아웃바운드를 허용목록으로 전환. SMA1000이 정상 동작에 필요한 목적지는 생각보다 적음(LDAP/RADIUS, 내부 애플리케이션 몇 개, 업데이트 서버). 그 외 내부 대역으로 나가는 연결은 기본 차단이 맞음. SSRF의 피해는 결국 "그 장비가 어디까지 갈 수 있느냐"로 결정됨.
메타데이터·내부 API 접근 차단. 클라우드나 가상화 환경에 올린 어플라이언스라면 인스턴스 메타데이터 엔드포인트 접근을 명시적으로 막아둘 것.

4. 탐지 포인트: 무엇을 보면 걸리는가

패치를 못 붙이는 기간이 있다면 최소한 눈은 뜨고 있어야 함. 실전에서 신호가 잘 잡히는 지점들임.

어플라이언스 발신 트래픽의 방향성. 평소 통신하지 않던 내부 서브넷·포트로 향하는 연결이 갑자기 생기는지. 특히 짧은 시간에 여러 포트를 두드리는 패턴은 내부 스캔 시도로 보아야 함.
루프백·링크로컬 목적지. 장비가 자기 자신이나 169.254 대역으로 HTTP 요청을 보내는 흔적은 정상 운영에서 나오기 어려운 신호임.
인증 전 요청의 비율. 로그인하지 않은 세션에서 특정 엔드포인트만 반복 호출되는지. SSRF는 인증 우회와 엮일 때 가장 위험해짐.
응답 시간 분포. 같은 엔드포인트인데 응답 지연이 이상하게 갈리면 블라인드 방식의 내부 탐색일 수 있음. 평균만 보지 말고 꼬리를 봐야 함.
User-Agent와 발신 IP의 조합. 내부 서버 접근 로그에서 출처가 VPN 장비 IP인데 요청 내용이 업무 트래픽과 안 맞으면 바로 조사 대상임.

5. 학습용으로 해볼 만한 것

실제 장비에 무언가를 시도하는 건 당연히 안 되고, 개념은 홈랩에서 충분히 익힐 수 있음. URL을 입력받아 서버가 대신 가져오는 간단한 애플리케이션을 직접 만들어 보고, 목적지 검증을 문자열 필터로만 짰을 때 어떻게 무력해지는지 확인해 보는 과정이 이해에 큰 도움이 됨. 그다음 DNS 해석 결과와 리디렉트 최종 목적지까지 검사하도록 고쳐 보면, 왜 "요청 직전에 확인해야 한다"는 원칙이 반복해서 나오는지 몸으로 알게 됨.

정리하면 이번 건의 교훈은 새로운 게 아님. 경계에 놓인 장비일수록 자기가 보낼 수 있는 요청의 범위를 스스로 좁혀야 한다는 것. 패치를 붙이는 건 오늘의 대응이고, 아웃바운드를 통제하고 로그를 남기는 건 다음 CVE를 위한 대응임. 둘 다 해두면 다음 공지가 떴을 때 훨씬 덜 급해짐.

사내에 SMA 계열이 있다면 이번 주 안에 관리 인터페이스 노출 여부부터 한 번 확인해 보아요. 확인하다가 애매한 구간 나오면 댓글로 상황 남겨주시면 같이 고민해 봅시다.

사내 전화기 뒤에 있던 데이터베이스 — Switchvox 관리 화면이 삼킨 한 줄

Tue, 8 Sep 2026 19:01:44 +0900

이미지 출처: CISA KEV

회사에 있는 IP 전화기를 떠올려 보자. 책상 위에 놓인 그 플라스틱 덩어리는 대부분의 사람에게 "그냥 전화기"다. 그런데 그 전화기들을 묶어 관리하는 서버, 즉 Sangoma Switchvox 같은 통합 커뮤니케이션(UC) 장비 안에는 생각보다 많은 것이 들어 있다. 내선 번호와 부서 구조, 음성 사서함, 통화 기록, 그리고 관리자 계정 정보까지. CVE-2026-9586은 바로 그 서버의 웹 인터페이스에서 SQL 구문 조작이 가능하다는 내용으로 정리된 건이다.

핵심 요약

Sangoma Switchvox의 웹 인터페이스에서 입력값이 SQL 질의에 그대로 섞이는 문제로, 데이터베이스 내용 노출·조작 위험이 있음
UC 장비 특성상 통화기록·내선정보·계정 데이터가 한곳에 모여 있어 한 번의 유출로 조직 전체 구조가 드러남
패치 적용이 최우선, 그전까지는 관리 인터페이스의 인터넷 노출 차단과 웹 로그 기반 탐지로 버티는 것이 현실적

SQL Injection이 왜 아직도 나오는가

SQL Injection은 1998년쯤부터 공개적으로 논의된, 웹 취약점 중에서도 가장 오래된 축에 속함. 그런데도 2026년에 또 CVE 번호가 붙는 이유는 단순함 — 웹 애플리케이션이 아니라 어플라이언스이기 때문임.

UC·PBX 장비의 관리 UI는 십수 년 동안 기능을 얹어온 레거시 코드가 많음
내부망에만 두는 장비라는 전제 때문에 입력 검증 우선순위가 낮게 잡힘
ORM이 아니라 문자열로 질의를 조립하는 옛 방식이 그대로 남아 있는 경우가 흔함

즉 취약점 자체가 정교해서가 아니라, 아무도 오래 들여다보지 않은 코드였기 때문에 지금 나온 것에 가깝다고 봄.

개념적으로 무슨 일이 벌어지는가

원리만 짚자면 이렇다. 웹 화면의 어떤 파라미터 — 검색어든 ID값이든 — 가 서버 내부에서 SQL 질의문을 만들 때 문자열로 이어붙여짐. 정상 값이면 아무 문제 없지만, 값 안에 질의문의 구조를 바꾸는 문자가 섞이면 원래 의도와 다른 질의가 실행되는 것임. 여기서 중요한 건 "어떤 문자열을 넣느냐"가 아니라 데이터와 명령이 구분되지 않는 구조 그 자체가 결함이라는 점.

이 상태가 되면 공격자는 원래 접근 권한이 없는 테이블을 읽거나, 조건절을 항상 참으로 만들어 인증 로직을 우회하거나, 데이터베이스 계정 권한에 따라 내용을 수정하는 것까지 시도할 수 있음. UC 장비에서 이게 특히 뼈아픈 이유는, 그 데이터베이스가 곧 조직도 그 자체이기 때문임. 누가 누구에게 자주 전화하는지, 임원 내선이 몇 번인지가 다 들어있다면 그건 이후 보이스피싱이나 표적 사회공학의 훌륭한 재료가 되어버림.

방어자가 지금 확인할 것들

순서대로 정리해봄.

1. 자산 파악: 우리 조직에 Switchvox가 있는지부터. 의외로 IT팀이 아니라 총무팀이 도입해둔 경우가 있어서, 네트워크 스캔으로 관리 포트(HTTP/HTTPS)가 열린 장비를 훑는 게 빠름
2. 노출면 축소: 관리 인터페이스가 인터넷에서 바로 보이면 안 됨. VPN 뒤로 넣거나, 최소한 접근 소스 IP를 화이트리스트로 제한. 원격근무 때문에 열어둔 임시 규칙이 몇 년째 살아있는 경우가 정말 많음
3. 패치: 벤더가 배포한 최신 펌웨어·패치를 적용하는 것이 유일한 근본 해결책. 어플라이언스는 자동 업데이트가 꺼져 있는 일이 잦으니 수동으로 확인
4. 계정 정리: 기본 관리자 계정, 퇴사자 계정, 설치 업체가 만들어둔 유지보수 계정을 점검. SQLi로 해시가 유출됐을 때를 대비해 비밀번호도 교체

탐지 관점 — 로그에서 무엇을 보는가

패치까지 시간이 걸리는 조직이라면, 탐지라도 걸어두는 게 낫다고 봄. 실제로 볼 만한 신호는 이런 것들임.

웹 액세스 로그에서 동일 파라미터에 비정상적으로 긴 값이나 인코딩이 중첩된 값이 반복 요청되는 패턴
같은 엔드포인트에 대해 응답 크기나 응답 시간이 요청마다 들쭉날쭉한 흐름 — 블라인드 방식 탐색의 전형적 흔적임
인증 실패 없이 관리 페이지 응답이 200으로 계속 돌아오는데 세션 생성 기록은 없는 경우
데이터베이스 오류 메시지가 HTTP 응답에 그대로 실려 나가는 상황 — 이건 이미 정보 노출이니 그 자체로 조치 대상

WAF를 앞단에 둘 수 있다면 SQLi 시그니처를 켜두는 것도 임시 완충으로 쓸 만함. 다만 WAF는 우회 기법이 많아서 시간을 버는 수단이지 해결책은 아니라는 점은 분명히 해두고 싶음. "WAF 켰으니 패치는 다음 분기에" 가 되는 순간 그게 제일 위험한 상태가 됨.

조금 더 넓게 보면

이번 건을 계기로 한 번쯤 생각해볼 만한 게, 우리가 "보안 점검 대상"이라고 부르는 목록에 전화 시스템이 들어가 있느냐는 질문이다. 웹서버, 메일서버, VPN 게이트웨이는 다들 챙기는데 PBX·UC·회의실 장비·프린터 서버 같은 것들은 자산 목록 맨 아래에 이름만 올라가 있거나 아예 빠져 있는 경우가 많은 것 같다. 공격자 입장에서는 오히려 그런 곳이 조용하고 편한 진입로인데 말입니다.

개인적으로는 분기에 한 번 정도, 팀 안에서 "우리가 관리 안 하고 있는 IP 있나?" 하고 훑는 시간을 잡아두는 걸 추천함. 거창한 도구 없이 네트워크 대역 스캔 한 번만 돌려도 몰랐던 장비가 튀어나오는 일이 꽤 있음. 이번 Switchvox 건도, 결국 패치보다 먼저 필요한 건 그 장비가 우리 것이라는 인식이었다고 생각한다.

여러분 조직의 전화 서버는 지금 어디까지 열려 있는지, 이번 주에 한 번 확인해보면 어떨까요. 확인해보고 재밌는 게 나왔다면 댓글로 공유해주세요. 같이 점검해보아요!

빌드 산출물이 쌓인 창고의 옆문 — Artifactory 인증 처리에 생긴 틈

Tue, 8 Sep 2026 13:01:43 +0900

이미지 출처: CISA KEV

사내에서 아티팩트 저장소는 보통 "그냥 있는 것"으로 취급됨. CI가 빌드한 jar와 컨테이너 이미지가 흘러들어가고, 배포 파이프라인이 그걸 다시 꺼내 쓰는 통로일 뿐이라 여겨지기 때문임. 그런데 그 창고의 문을 여는 절차 자체가 헐거우면, 창고 안 물건은 물론이고 그 물건을 받아 쓰는 모든 시스템이 함께 흔들림. CVE-2026-82329로 등록된 JFrog Artifactory의 부적절한 인증(Improper Authentication) 이슈가 딱 그 지점을 건드림.

핵심 요약

Artifactory의 인증 처리 과정에서 신원 검증이 제대로 이뤄지지 않아, 정상 자격증명 없이 접근이 성립할 수 있는 문제임
아티팩트 저장소는 공급망의 상류이므로, 한 번의 인증 우회가 다운스트림 배포 전체의 신뢰를 깨뜨림
방어는 벤더 패치 적용이 1순위이고, 그 전까지는 노출면 축소·인증 로그 이상탐지·아티팩트 무결성 검증으로 버티는 게 현실적임

왜 '인증 우회'가 저장소에서 특히 아픈가

부적절한 인증은 개념 자체는 단순함. 시스템이 "너 누구야"를 묻긴 하는데, 그 대답을 검증하는 로직이 어딘가에서 헐겁게 끊어지는 것임. 토큰 서명을 확인하지 않거나, 특정 경로나 헤더 조합에서 인증 필터가 우회되거나, 익명 접근 경로가 의도보다 넓게 열리는 식의 문제들이 전부 이 범주에 들어감.

다만 같은 결함이라도 어디에 있느냐에 따라 체감 위험이 완전히 달라짐. 사내 위키에 인증 우회가 있으면 문서가 새는 사고지만, 아티팩트 저장소에 있으면 이야기가 달라짐. 이유는 이럼.

상류 위치: 저장소의 산출물은 수십 개 서비스로 퍼져나감. 여기 하나를 건드리면 다운스트림 전체가 오염될 수 있음
신뢰 전제: 배포 파이프라인은 보통 "우리 저장소에서 받은 건 안전하다"는 가정 위에서 동작함. 그 가정이 검증 없이 굴러가는 조직이 많음
자격증명 저수지: 저장소 설정에는 외부 레지스트리 자격증명, 원격 리포지터리 토큰, 서명키 참조 같은 것들이 함께 들어 있는 경우가 흔함

공격 시나리오는 개념 수준으로만

구체적인 요청 형태나 페이로드를 늘어놓을 생각은 없음. 방어자 입장에서 필요한 건 "어떤 모양으로 벌어지는가"에 대한 감각이지 재현 절차가 아니기 때문임. 흐름은 대략 이럼: 인증이 성립하지 않아야 할 요청이 인증된 것처럼 처리됨 → 배포 권한이 있는 컨텍스트로 리포지터리에 쓰기가 가능해짐 → 정상 버전과 구분되지 않는 산출물이 저장소에 자리 잡음 → CI/CD가 평소처럼 그걸 당겨 배포함.

여기서 무서운 건 마지막 단계가 완전히 정상적인 동작이라는 점임. 파이프라인은 아무 잘못도 하지 않고, 로그도 깨끗하고, 알림도 울리지 않음. 그래서 이런 유형은 사고 인지가 늦음.

탐지 — 무엇을 보면 보이는가

패치 전후 모두 챙겨야 하는 관측 포인트를 정리하면 이럼.

인증 이벤트의 결측: 접근 로그에는 리포지터리 read/write가 찍혔는데, 대응하는 로그인·토큰 발급 이벤트가 앞에 없는 경우. 인증 우회 계열은 이 '앞뒤 안 맞음'으로 드러나는 일이 많음
주체 프로파일 이탈: 평소 pull만 하던 서비스 계정이 갑자기 push를 하거나, 특정 리포지터리만 만지던 주체가 광범위한 경로를 훑는 패턴
비정상 시간대·출처: CI 러너 대역이 아닌 IP에서 들어온 배포성 요청. 저장소는 접근 출처가 비교적 정형적이라 이 탐지가 잘 먹힘
산출물 메타데이터 불일치: 체크섬은 새로 갱신됐는데 대응하는 빌드 잡 기록이 없는 아티팩트. CI 빌드 ID와 저장소 업로드 기록을 조인해두면 이런 고아 아티팩트가 튀어나옴
덮어쓰기 시도: 이미 배포된 릴리스 버전에 대한 재업로드. 정책상 금지돼 있더라도 시도 자체를 알림으로 올려두면 좋음

완화 — 순서대로 하면 되는 것들

패치가 1순위: 인증 로직 결함은 설정으로 우회해 막기 어려운 부류임. 벤더가 배포한 고정 버전으로 올리는 게 유일하게 확실한 조치임. 자체 호스팅 인스턴스는 특히 미뤄지기 쉬우니 담당자를 명시해두는 게 좋음
노출면 축소: Artifactory 관리·API 엔드포인트를 인터넷에 그대로 열어둘 이유는 거의 없음. VPN이나 사내망, 최소한 IP 허용목록 뒤로 넣는 것만으로도 실질 위험이 크게 줄어듦
익명 접근 재점검: 오래 굴린 인스턴스일수록 "잠깐 열어두고 잊은" 익명 read 설정이 남아 있음. 리포지터리별로 한 번씩 훑어볼 만함
권한 최소화: CI용 토큰에 관리자 권한이 붙어 있는 경우가 생각보다 많음. 읽기용과 배포용을 분리하고, 배포용은 대상 리포지터리를 좁히는 게 기본임
무결성 검증을 배포 단계에도: 저장소를 무조건 믿지 말고, 배포 직전에 서명 검증이나 체크섬 대조를 한 겹 더 두는 것. 인증 우회가 나더라도 여기서 걸릴 수 있음
불변 태그 정책: 릴리스 아티팩트는 덮어쓰기 불가로 잠가두기. 조용한 교체를 막는 가장 값싼 방법임

사고가 났다고 가정하면

이런 유형은 "우리는 안 당했다"를 증명하기가 은근히 까다로움. 그래서 점검할 때는 순서를 정해두는 게 편함. 먼저 취약 버전으로 운영된 기간을 특정하고, 그 구간의 리포지터리 쓰기 이력을 전부 뽑음. 그다음 각 업로드를 CI 빌드 기록과 대조해서 출처 없는 항목을 걸러냄. 마지막으로 그 기간에 발급되거나 사용된 토큰을 전부 회전시킴. 토큰 회전은 귀찮지만, 인증 계열 취약점 대응에서 생략하면 나중에 후회하는 단계임.

마무리

개인적으로는 이런 공급망 상류 취약점을 볼 때마다 "우리 조직은 저장소를 얼마나 믿고 있나"를 다시 재보게 됨. 대부분은 생각보다 훨씬 많이 믿고 있고, 그 믿음에 대한 검증 장치는 생각보다 훨씬 적음. 패치는 당연히 해야 하는 일이고, 그와 별개로 "저장소가 뚫려도 배포는 안 뚫리게" 만드는 이중 방어선을 하나쯤 깔아두면 다음번에 비슷한 CVE가 떠도 훨씬 덜 급해짐.

여러분 조직의 아티팩트 저장소는 지금 어디까지 열려 있나요? 익명 접근 설정 한 줄, CI 토큰 권한 한 칸부터 같이 점검해보아요. 비슷한 사례 겪어보셨다면 댓글로 공유해주시면 저도 배우겠습니다!

워크플로우 한 줄이 셸이 되는 순간 — Kestra OSS 명령 주입(CVE-2026-49869) 방어 노트

Mon, 7 Sep 2026 21:32:09 +0900

이미지 출처: CISA KEV

데이터 파이프라인을 굴리는 팀에서 Kestra는 꽤 익숙한 이름임. YAML로 플로우를 정의하고, 스케줄 돌리고, 실패하면 재시도까지 알아서 해주는 오케스트레이터라 한 번 붙여놓으면 손이 잘 안 감. 그런데 바로 그 "손이 안 가는" 성질이 문제임. 이번에 공개된 CVE-2026-49869는 Kestra 오픈소스 배포판에서 OS 명령이 주입될 수 있는 결함으로, 워크플로우 엔진이라는 물건이 본질적으로 "남이 준 문자열을 시스템에 실행시키는 기계"라는 사실을 다시 확인시켜 줌.

핵심 요약

Kestra OSS에서 사용자 입력이 OS 명령 실행 경로로 흘러들어가는 명령 주입 취약점(CVE-2026-49869)이 보고됨
워크플로우 엔진 특성상 실행 권한 자체가 넓어, 성공 시 오케스트레이터 호스트 전체가 공격자의 실행 환경이 됨
방어는 패치 적용 + 플로우 편집 권한 최소화 + 워커 프로세스의 자식 프로세스 로그를 탐지 대상으로 올리는 3단 구성

1. 왜 오케스트레이터에서 명령 주입이 특히 아픈가

일반 웹앱에서 명령 주입이 터지면 "웹 서버 계정 권한"까지가 보통의 손해임. 그런데 Kestra 같은 워크플로우 엔진은 성격이 다름. 이 물건은 설계상 이미 셸을 부르고, 스크립트를 실행하고, 컨테이너를 띄우고, 외부 시스템에 붙기 위한 자격증명을 잔뜩 들고 있음. 즉 취약점이 주는 것은 "새로운 권한"이 아니라 "기존의 강한 권한에 대한 접근"임.

워커 노드에는 DB 접속 정보, 클라우드 키, 사내 API 토큰이 시크릿 스토어를 통해 주입되어 있음
오케스트레이터는 대개 내부망 깊숙한 곳에 있어, 여기서 한 발짝만 옮기면 측면 이동 거리가 매우 짧음
정상 동작 자체가 "명령 실행"이라 악성 실행과 정상 실행의 구분선이 흐릿함

세 번째가 특히 고약한 부분인것같음. 탐지 관점에서 보면 워커가 자식 프로세스를 만드는 건 매일 수천 번 일어나는 정상 이벤트라, 단순히 "프로세스 생성"을 알림으로 걸면 그날로 알림 피로에 묻혀버림.

2. 결함의 구조 — 개념 수준으로만

명령 주입의 골격은 어디서나 같음. 애플리케이션이 문자열을 조립해 시스템 셸에 넘기는데, 그 문자열 안에 사용자가 통제 가능한 조각이 섞여 있고, 셸이 해석하는 메타문자(구분자·치환 기호 등)가 걸러지지 않은 상태로 통과하는 것. Kestra처럼 플로우 정의·태스크 파라미터·표현식 치환 같은 층이 여러 겹 쌓인 시스템에서는 "어디까지가 검증된 값인지"의 경계가 층 사이에서 흐려지기 쉬움.

실무에서 이런 결함이 살아남는 전형적인 이유가 몇 가지 있음.

입력 검증을 진입 지점(API·UI)에서만 하고, 내부 표현식 평가 이후의 값은 이미 안전하다고 가정함
템플릿 치환이 검증보다 나중에 일어나서, 검증 시점의 문자열과 실행 시점의 문자열이 달라짐
"이건 관리자만 쓰는 기능"이라는 전제로 방어를 생략했는데, 실제 배포에서는 그 관리자 경계가 생각보다 헐거움

재현 가능한 페이로드를 적을 생각은 없고, 방어자 입장에서 필요한 건 그게 아님. 필요한 건 "우리 환경에서 저 경로가 살아 있는가"를 확인하는 방법이지, 남의 서버에서 명령을 실행하는 방법이 아니니까.

3. 지금 당장 해야 할 것 — 우선순위 순

순서를 지키는 게 중요함. 아래를 위에서부터 차례로 밟는 걸 개인적으로는 추천함.

패치 적용: Kestra 릴리스 노트에서 해당 CVE가 정리된 버전을 확인하고 올리는 게 1순위. 오케스트레이터는 "다운타임이 무서워서" 업데이트가 제일 밀리는 컴포넌트라 지금 버전이 몇 개월 묵어 있을 확률이 높음
노출면 축소: Kestra UI와 API가 인터넷에서 직접 닿는지 먼저 봄. 이런 내부 도구는 VPN이나 리버스 프록시 뒤 인증 게이트 안쪽에 있어야 정상이고, 공개 노출되어 있다면 패치보다 이쪽이 더 급함
권한 재정비: 플로우를 생성·수정할 수 있는 계정이 몇 개인지 세어봄. 이 취약점 계열에서 "플로우 편집 권한"은 사실상 "임의 명령 실행 권한"과 동의어라, 조회 권한과 편집 권한이 같은 롤에 묶여 있으면 지금 분리해야 함
실행 격리: 워커를 별도 컨테이너·별도 서비스 계정으로 돌리고, 시크릿은 필요한 태스크에만 스코프를 좁혀 주입함. 컨테이너 안에서 root로 도는 워커라면 그것부터 손보는 게 순서임
이그레스 통제: 워커에서 나가는 아웃바운드를 화이트리스트로 묶음. 명령 주입 이후 단계는 거의 항상 외부로 나가는 통신이라, 여기서 한 번 더 끊을 기회가 생김

4. 탐지 규칙은 이렇게 짜면 덜 시끄러움

앞에서 말했듯 "프로세스 생성"만 보면 노이즈에 파묻힘. 그래서 정상 워크플로우가 절대 하지 않을 행동을 기준선으로 잡는 게 핵심임.

워커 프로세스(JVM)의 자식으로 대화형 셸이나 네트워크 유틸리티가 뜨는 경우 — 정상 태스크는 대개 정해진 스크립트 인터프리터만 부름
플로우 실행 컨텍스트에서 시크릿 파일이나 환경변수 전체를 한꺼번에 읽어가는 접근 패턴
워커가 평소 붙지 않던 목적지로 나가는 아웃바운드 세션, 특히 짧은 주기의 반복 연결
Kestra 감사 로그에서 비업무 시간대의 플로우 생성·수정, 그리고 만들자마자 즉시 실행되고 곧 삭제되는 플로우
실행 이력에는 남았는데 대응하는 플로우 정의가 저장소에 없는 경우 — 흔적 지우기의 전형적인 잔상임

마지막 두 개는 취약점 종류와 무관하게 오케스트레이터 침해를 잡아내는 데 두루 잘 먹히는 신호라, 이번 건이 아니더라도 규칙으로 만들어두면 두고두고 값을 함.

5. 그리고 조금 더 근본적인 이야기

요 몇 년 사이 CI/CD 러너, 워크플로우 엔진, MLOps 파이프라인, 에이전트 실행 환경까지 "설정을 받아 명령을 실행하는 시스템"이 사내 인프라의 중심으로 들어왔음. 그런데 이 계열은 자산 목록에서 자주 누락됨. 개발팀이 필요해서 올렸고, 보안팀은 존재를 늦게 알고, 인터넷 노출 여부는 아무도 정기적으로 확인하지 않는 상태로 몇 년을 굴러가다 보니 이런 CVE 하나에 조직 전체가 흔들리는 구조가 만들어지는 것임.

그래서 이번 기회에 패치만 올리고 끝내지 말고, 한 번쯤 목록을 만들어보는 걸 권함. 우리 회사에서 YAML이나 JSON을 읽어 명령을 실행하는 시스템이 몇 개나 돌고 있는지, 각각 누가 관리하고 어디까지 노출되어 있는지. 저도 예전에 이 작업을 한 번 해보고 나서 목록 절반이 제가 모르던 것이라 꽤 당황했던 기억이 있음. 아마 다들 비슷할 거라고 봄.

정리

CVE-2026-49869는 기술적으로 특별히 정교한 취약점은 아님. 오히려 명령 주입이라는 아주 고전적인 결함이, 하필 권한이 가장 넓은 컴포넌트에서 발견됐다는 점이 핵심임. 패치 → 노출면 축소 → 권한 분리 → 탐지 규칙 순서로 밟아나가면 이번 건도 정리되고, 다음에 비슷한 게 나와도 대응 시간이 훨씬 짧아짐.

혹시 이미 Kestra를 운영 중이시라면 오늘 안에 버전 확인이랑 외부 노출 여부, 이 두 가지만이라도 먼저 봐두시길. 그리고 워크플로우 엔진 쪽 탐지 규칙 잘 쓰고 계신 게 있으면 댓글로 공유해 주세요. 이런 건 서로 알려주면서 차차 다듬어가는 게 제일 빠르더라고요. 같이 해보아요!

프록시와 Starlette가 같은 요청을 다르게 읽을 때 — 경계면에서 갈라지는 한 건의 HTTP

Mon, 7 Sep 2026 19:01:42 +0900

이미지 출처: CISA KEV

사내 API 게이트웨이 로그를 보다가 이상한 걸 발견하는 순간이 있음. 프록시 액세스 로그에는 요청이 한 건인데, 뒤에 있는 애플리케이션 로그에는 두 건이 찍혀 있는 경우 말입니다. 이게 바로 HTTP 요청 스머글링이 남기는 가장 전형적인 흔적이고, 이번에 Starlette에 붙은 CVE-2026-48710도 정확히 이 계열의 문제임.

핵심 요약

Kludex/Starlette에서 HTTP 요청·응답 스머글링(Request/Response Smuggling) 취약점이 보고됨 — 프록시와 앱이 같은 바이트 스트림을 다르게 해석하는 경계면 불일치 문제.
실질 위험은 인증·WAF·라우팅 우회, 캐시 오염, 다른 사용자 응답 탈취까지 이어질 수 있다는 점.
대응은 세 겹 — Starlette·ASGI 서버 최신화, 프록시 단에서 모호한 요청 차단, 그리고 "프록시 로그 대 앱 로그" 건수 대조 탐지.

1. Starlette가 어디에 서 있는 물건인지부터

Starlette는 파이썬 ASGI 기반의 경량 웹 프레임워크임. 그 자체로 쓰이기도 하지만, 진짜 무서운 건 FastAPI가 Starlette 위에 얹혀 있다는 사실임. 요즘 사내에 돌아다니는 AI 추론 API, 내부 백오피스, 마이크로서비스 게이트웨이 상당수가 FastAPI로 짜여 있다보니, Starlette 하나에 구멍이 나면 조직도상 전혀 다른 팀들이 동시에 영향권에 들어감. 자산 목록에 "Starlette"라고 적혀 있는 서버가 없더라도 안심할 수 없는 이유가 이것.

2. 요청 스머글링, 개념만 짚고 넘어감

HTTP는 "요청이 어디서 끝나는가"를 두 가지 방식으로 알림. 하나는 Content-Length, 다른 하나는 Transfer-Encoding: chunked임. 문제는 이 둘이 동시에 들어오거나, 헤더 값이 애매하게 쓰였을 때 발생함. 앞단 프록시는 A 기준으로 요청 경계를 자르고, 뒷단 애플리케이션은 B 기준으로 자름. 그러면 프록시가 "요청 하나"라고 믿고 넘긴 바이트 뭉치의 뒷부분이, 앱 입장에서는 다음 요청의 앞머리가 되어버림.

그렇게 밀어넣은 조각은 프록시를 통과한 적이 없으니 WAF·인증 필터를 건너뜀.
연결이 재사용되는 구간이라면, 그 조각이 다른 사용자의 요청 앞에 붙어 응답이 뒤섞임.
응답 쪽 경계가 어긋나는 경우(응답 스머글링)에는 A 사용자에게 갈 응답이 B 사용자 브라우저에 도착하는 상황도 성립함.

구체적인 페이로드 문법은 여기서 다루지 않음. 방어자 입장에서 필요한 건 "어떤 문자를 어디에 넣느냐"가 아니라, 내 구간에 해석이 갈라지는 지점이 존재하는가이기 때문임.

3. 왜 프레임워크 레벨 파싱이 중요한가

많은 팀이 "우리는 nginx 뒤에 있으니 괜찮다"고 생각함. 과연 그럴까? 스머글링은 단독 소프트웨어의 버그가 아니라 두 파서 사이의 의견 차이임. 즉 프록시가 아무리 엄격해도, 뒷단 프레임워크가 관대하면 그 관대함이 곧 틈이 됨. 반대로 프레임워크가 엄격해도 앞단이 헐거우면 마찬가지고. 그래서 Starlette 같은 프레임워크·ASGI 서버(uvicorn, hypercorn 등)의 헤더 파싱 규약이 얼마나 RFC에 붙어 있느냐가 실제 보안 경계를 결정함.

4. 지금 당장 해볼 점검 순서

자산 식별: requirements.txt·poetry.lock·pip freeze를 전수 조사해 starlette, fastapi, uvicorn 버전을 뽑음. 컨테이너 이미지 안쪽까지 봐야 함. 자산 인벤토리에서 빠지는 건 대개 "누가 급하게 띄운 내부용" 서비스임.
버전 최신화: Starlette 및 함께 쓰는 ASGI 서버를 패치 반영된 최신 버전으로 올림. FastAPI를 쓴다면 FastAPI만 올리는 게 아니라 하위 의존성인 Starlette가 실제로 올라갔는지 확인해야 함.
경계면 축소: 프록시에서 Content-Length와 Transfer-Encoding이 동시에 존재하는 요청, 중복 헤더, 비정상 chunked 인코딩을 정규화하지 말고 그냥 거절하도록 설정. "고쳐서 전달"이 스머글링의 최고 조력자임.
연결 정책 조정: 프록시와 백엔드 사이 구간을 HTTP/2로 정리하거나, 리스크가 큰 구간은 keep-alive 재사용을 제한. 백엔드 연결이 공유되지 않으면 피해가 요청 하나에서 멈춤.

5. 탐지 — 로그 두 벌을 나란히 놓는 것부터

개인적으로는 패턴 시그니처보다 건수 대조를 먼저 추천함. 방법은 단순함.

같은 시간대에 프록시 액세스 로그의 요청 수와 애플리케이션 로그의 처리 요청 수를 비교. 앱 쪽이 꾸준히 더 많으면 그건 경계가 갈라지고 있다는 신호임.
앱 로그에는 있는데 프록시 로그에는 대응 항목이 없는 경로가 있는지 확인. 특히 /admin, /internal 같은 관리 경로가 프록시 기록 없이 등장하면 즉시 조사 대상임.
요청 ID를 프록시 단에서 발급해 헤더로 심고, 앱 로그에 그대로 남기도록 함. ID 없는 요청 = 프록시를 거치지 않은 요청.
동일 소스에서 400/408 같은 파싱 오류가 짧은 간격으로 반복되는 패턴도 좋은 조기 지표임. 스머글링은 성공 전에 항상 탐색 단계를 거침.

WAF 룰 하나 추가하는 것보다 이 요청 ID 파이프라인 하나 깔아두는 게 장기적으로 훨씬 값어치가 있는 것 같음. 이번 CVE뿐 아니라 앞으로 나올 같은 계열 이슈 전부를 같은 방식으로 볼 수 있게 되니까.

6. 마무리하며

스머글링 계열 취약점을 볼 때마다 드는 생각은, 결국 보안 사고 상당수가 소프트웨어 안이 아니라 소프트웨어와 소프트웨어 사이에서 터진다는 것임. 각각은 다 정상 동작인데, 이어붙이는 순간 해석이 갈라짐. 그래서 이런 건 패치만으로 끝내지 말고, 내 구간의 경계면 지도를 한 번 그려두는 게 좋다고 봄. 클라이언트 → CDN → 로드밸런서 → 프록시 → ASGI 서버 → 앱, 이 사슬에서 HTTP를 다시 파싱하는 지점이 몇 개인지 세어보는 것만으로도 감이 확 옴.

이번 주말에 각자 서비스 의존성 목록부터 한번 훑어보는 건 어떨까요. 혹시 사내에서 요청 ID 대조 탐지를 다르게 구현해서 재미를 본 사례가 있다면 댓글로 공유해 주세요. 차차 정리해서 다음 글에 반영해 보겠음. 같이 해보아요!

LiteLLM 1.84.0 이전 버전, MCP 엔드포인트가 아무 토큰이나 받아준 이유

Mon, 7 Sep 2026 13:03:02 +0900

이미지 출처: CISA KEV

CISA가 9월 2일에 알려진 악용 취약점(KEV) 목록에 일곱 건을 한꺼번에 올렸는데, 그 명단 안에 LiteLLM이 들어 있었다. LLM 프록시가 KEV에 오르는 장면은 아직 낯설지만, 사내 AI 게이트웨이가 실제 공격 표면으로 취급되기 시작했다는 신호로 읽는 게 맞다고 봄.

핵심 요약

LiteLLM 1.84.0 미만의 MCP Streamable HTTP 엔드포인트에서, 위조한 Authorization 헤더만으로 인증을 통과할 수 있었음(CVSS 8.8)
키 검증이 실패했을 때 예외를 던지는 대신 빈 인증 객체로 갈아끼우는 OAuth2 passthrough 폴백 경로가 원인
1.84.0 이상으로 올리고, MCP 경로의 외부 노출 차단과 업스트림 MCP 서버의 자체 인증을 2차 방어선으로 세워야 함

LiteLLM이 무엇을 대신 들고 있었나

LiteLLM은 BerriAI가 만든 LLM 프록시 겸 게이트웨이임. OpenAI·Anthropic·자체 호스팅 모델을 하나의 API 규격으로 묶어주고, 팀별 가상 키·예산·레이트리밋을 붙여주는 물건이라 도입 속도가 빨랐음. 문제는 여기에 MCP(Model Context Protocol) 중계 기능이 얹히면서 성격이 달라졌다는 점.

MCP를 붙이는 순간 이 프록시는 단순한 토큰 중계기가 아니라 사내 도구들의 관문이 됨. 티켓 시스템, 파일 저장소, 내부 검색, 사내 DB 조회 같은 것들이 MCP 서버로 등록되고, LiteLLM이 그 앞에서 "누가 어떤 툴을 부를 수 있는가"를 판정함. 즉 인증 판정이 무너지면 잃는 게 모델 호출 비용이 아니라 그 뒤에 붙은 도구 전부라는 뜻.

취약점의 구조: 실패를 예외가 아니라 기본값으로 처리함

이번 건은 개념만 놓고 보면 아주 단순함. MCP 인증 핸들러는 업스트림 MCP 서버로 사용자 토큰을 그대로 넘겨주는 OAuth2 passthrough를 지원하고 있었음. 그런데 그 경로에서 LiteLLM 자체 키 검증이 실패했을 때, 요청을 끊는 대신 비어 있는 UserAPIKeyAuth() 객체로 대체하고 흐름을 이어가는 폴백이 존재했음.

결과적으로 형식만 갖춘 Authorization 헤더를 붙여 보내면, 유효한 LiteLLM 키가 하나도 없어도 요청이 MCP 툴 계층까지 도달함. 등록된 툴 목록을 조회하고, 그 툴들을 호출하는 것까지 가능했다는 것. 실행 가능한 형태로 풀어 쓸 이유는 없고, 방어자가 기억할 건 한 줄이면 충분함 — 인증 실패를 "권한 없음"이 아니라 "권한이 비어 있는 사용자"로 번역하면 그 순간 fail-open이 됨.

이런 패턴이 유독 AI 인프라에서 자주 나오는 이유도 짚어둘 만함. 여러 인증 방식(마스터 키, 가상 키, JWT, OAuth 패스스루)을 동시에 지원하려다 보니 분기가 늘어나고, "이 경로에서는 이 검증을 건너뛰어도 된다"는 예외가 쌓임. 그러다 보면 어느 분기 하나가 조용히 열려 있게 되는 것 같음.

지금 확인할 것

배포된 LiteLLM 버전 확인. 1.84.0 미만이면 대상임. 컨테이너 이미지 태그만 믿지 말고 실제 실행 중인 패키지 버전을 확인할 것
MCP 엔드포인트가 인터넷에서 직접 닿는지 점검. 프록시 앞단 로드밸런서·인그레스 규칙에서 MCP 경로가 공개돼 있는 경우가 생각보다 많음
MCP 서버로 등록된 도구 목록과 각 도구의 권한 범위 재확인. 읽기 전용으로 충분한데 쓰기 권한이 붙어 있는 항목이 있는지
KEV 등재 건이므로 공공·금융 쪽은 내부 기한 관리 대상에 올려야 함

로그에서 무엇을 찾을 것인가

패치보다 먼저 해야 할 일은 "이미 당했는지" 확인하는 것임. 볼 지점은 이렇게 잡으면 됨.

키 식별자가 비어 있는 성공 요청. 정상 트래픽이면 요청 로그에 가상 키 해시나 팀/사용자 식별자가 남음. 이 필드가 비었는데 응답이 200인 MCP 요청은 그 자체로 이상 신호
인증 실패 없이 곧바로 도구 목록을 조회한 세션. 정상 사용자는 대개 모델 호출과 섞여서 들어오는데, 툴 목록 조회로 시작해 호출로 바로 넘어가는 흐름은 정찰 패턴에 가까움
단일 IP·단일 User-Agent에서 반복되는 MCP 세션 초기화. 자동화 도구 특유의 리듬이 남음
업스트림 쪽 로그와 대조. LiteLLM 로그가 지워지거나 부실해도, 실제 도구를 제공한 내부 서비스(파일 서버, 티켓 API 등)에는 호출 흔적이 남음. 게이트웨이 로그와 업스트림 로그의 건수가 맞지 않으면 그 차이를 파고들 것

패치 이후에도 남겨둘 방어선

버전을 올리는 건 최소 조건이고, 같은 유형이 또 나왔을 때 버텨줄 구조를 만드는 게 진짜 대응이라고 생각함.

MCP 경로는 네트워크 경계로 한 번 더 막기. 사내망·VPN·mTLS 뒤로 넣어서, 애플리케이션 인증이 뚫려도 도달 자체가 안 되게 만드는 게 가장 확실함
업스트림 MCP 서버에 자체 인증 걸기. "게이트웨이가 걸러줄 것"이라는 전제를 지우면 이번 같은 폴백 버그의 피해가 한 단계에서 끊김
도구 권한 최소화와 분리. 조회용 도구와 변경용 도구를 다른 자격증명으로 나누고, 변경 계열은 승인 절차를 붙일 것
키 회전과 예산 상한. 노출 가능성이 있었던 기간의 키는 전부 갈아치우고, 팀별 예산 상한을 실질적인 피해 억제선으로 써야 함
인증 코드에 대한 회귀 테스트. "잘못된 토큰이면 반드시 거부된다"는 케이스를 테스트로 박아두는 것. 폴백 분기는 사람 눈으로 리뷰할 때 가장 잘 놓치는 자리임

마무리

AI 인프라는 아직 "편의 기능"과 "보안 경계"의 구분이 흐린 편임. MCP처럼 도구를 붙여주는 기능은 특히 그런데, 붙이는 순간 그 프록시는 사내 시스템으로 들어가는 문이 되어버림. 개인적으로는 AI 게이트웨이를 도입한 조직이라면 이번 기회에 자산 목록에 정식으로 올리고, 웹 서버나 VPN 장비와 같은 등급으로 패치 주기를 관리하시길 추천드림.

혹시 사내에서 LiteLLM이나 비슷한 프록시를 쓰고 계시다면, 오늘 버전 한 번만 확인해보시면 좋겠음. 확인하시다가 이상한 로그를 발견하셨거나, 반대로 "우리는 이렇게 막고 있다" 하는 구성이 있으시면 댓글로 공유해주세요. 같이 정리해보아요!

V8 엔진의 타입 하나가 어긋났을 때 — 브라우저 방어선을 다시 그리는 법

Mon, 7 Sep 2026 08:02:17 +0900

이미지 출처: CISA KEV

브라우저 탭 하나를 여는 동안 V8은 수천 개의 자바스크립트 객체를 만들고, 그 객체들이 "어떤 모양인지"를 기억한 채로 기계어를 뽑아냄. 이 기억이 실제 메모리 배치와 딱 한 칸이라도 어긋나는 순간이 바로 타입 컨피전(Type Confusion)이고, CVE-2026-85046은 그 어긋남이 Chromium의 V8에서 발생한 사례임.

핵심 요약

V8이 객체 타입을 잘못 판단해 생기는 타입 컨피전 결함으로, 조작된 웹페이지만으로 렌더러 프로세스에서 힙 손상까지 이어질 수 있음
공격 진입점이 "사용자가 링크를 클릭한다" 수준이라 사용자 교육만으로는 막기 어렵고, 버전 강제 업데이트가 사실상 유일한 근본 대응임
탐지는 렌더러 비정상 종료 로그·브라우저 버전 인벤토리·자식 프로세스 생성 이상 조합으로 접근하는 게 현실적임

1. 타입 컨피전이 왜 그렇게 위험한가

V8은 속도를 위해 "이 변수는 정수 배열일 것이다" 같은 가정을 세우고 그 가정에 최적화된 코드를 만듦. 그런데 실행 도중 그 객체가 다른 모양으로 바뀌었는데도 최적화 코드가 예전 가정을 그대로 들고 있으면, 정수라고 믿고 읽은 값이 사실은 포인터인 상황이 생김. 이게 타입 컨피전의 본질임.

객체 A의 필드 오프셋으로 객체 B를 해석 → 인접 힙 메모리를 읽고 쓸 수 있게 됨
읽기/쓰기 원시 능력(primitive)이 확보되면 그 다음은 임의 주소 접근으로 확장되는 흐름이 전형적임
최종적으로 렌더러 프로세스 안에서 코드 실행 — 여기까지가 1단계임

다만 여기서 오해가 자주 생기는데, 렌더러에서 코드가 돌았다고 곧바로 PC가 넘어가는 건 아님. Chromium은 렌더러를 샌드박스에 가둬두기 때문에, 실제 시스템 장악까지 가려면 샌드박스 탈출용 두 번째 취약점이 붙어야 함. 그래서 실전 공격은 거의 항상 체인 형태로 관측됨. 방어자 입장에서 중요한 건, 이 1단계가 뚫리는 순간 공격자에게 "체인의 첫 칸"이 공짜로 주어진다는 점이라 생각함.

2. 이 취약점의 공격 표면은 생각보다 넓다

V8은 크롬에만 있는 게 아님. Edge, Whale, Brave, Opera 같은 Chromium 계열 브라우저는 물론이고, 우리가 매일 켜두는 Electron 기반 데스크톱 앱들도 같은 엔진을 품고 있음. 사내에 배포된 협업 툴, 채팅 클라이언트, 사내 대시보드 뷰어가 오래된 Electron 런타임 위에 올라가 있다면, 크롬을 아무리 최신으로 유지해도 그 앱은 여전히 옛날 V8을 들고 있는 거죠.

브라우저 본체 — 자동 업데이트가 있어서 그나마 상황이 나음
Electron 앱 — 앱 벤더가 런타임을 올려주기 전까지 방치되는 경우가 많음
WebView / 임베디드 브라우저 — 키오스크, 사내 단말, POS 등에서 몇 년째 그대로인 사례가 흔함
서버 사이드 렌더링·헤드리스 브라우저 — 외부에서 받은 URL을 자동으로 열어주는 파이프라인이라면 진입점이 사람 손도 안 거침

3. 완화: 무엇부터 손대야 하나

순서를 정해두는 게 좋음. 개인적으로는 아래 순서를 추천함.

버전 강제 — 정책으로 브라우저 자동 업데이트를 잠그고, 재시작 유예 기간을 짧게 설정. 크롬 계열은 관리 정책으로 "업데이트 후 N일 내 재시작 강제"를 걸 수 있음. 업데이트가 설치돼도 재시작을 안 하면 옛 V8이 그대로 돌아간다는 점이 자주 간과됨
사이트 격리 확인 — Site Isolation이 꺼져 있거나 저사양 단말에서 비활성화된 상태면 렌더러 침해의 파급이 커짐. 정책으로 강제 활성화 상태를 점검
공격 대상 축소 — 고위험 계정이나 격리망 단말에는 JIT 비활성화 정책을 검토할 만함. 타입 컨피전 상당수가 JIT 최적화 단계의 가정 오류에서 나오기 때문에, 성능을 일부 포기하는 대신 공격 표면이 눈에 띄게 줄어듦
Electron·WebView 인벤토리 — 사내에 깔린 앱들의 Chromium 빌드 번호를 실제로 뽑아보는 작업. 해보면 생각보다 오래된 것들이 나옴
웹 프록시·DNS 필터링 — 익스플로잇 킷이 얹히는 경유 도메인을 차단하는 건 근본 대책은 아니지만, 패치 적용까지의 시간을 벌어주는 층임

4. 탐지: 흔적은 어디에 남는가

타입 컨피전 익스플로잇은 조용히 성공하기보다, 시도 과정에서 렌더러를 여러 번 죽이는 경우가 많음. 힙 그루밍이 실패하면 곧장 크래시로 이어지기 때문임. 그래서 탐지 아이디어는 대체로 이 근처에 모임.

동일 단말에서 짧은 시간에 반복되는 브라우저 렌더러 비정상 종료 — 단발 크래시는 노이즈지만, 특정 도메인 방문 직후 반복되면 신호가 됨
브라우저 프로세스가 낳는 예상 밖 자식 프로세스 — 스크립트 호스트, 셸, 인증서 관리 도구 등이 브라우저 하위에서 뜨는 패턴
렌더러 프로세스의 이례적 네트워크 행위나 사용자 프로필 디렉터리 밖 파일 쓰기
EDR 텔레메트리에서 브라우저 프로세스의 실행 가능 메모리 영역 변화
자산 인벤토리 기반 탐지 — "취약 버전대를 아직 쓰는 단말 목록"을 매일 뽑아 대시보드에 올려두는 것. 화려하진 않지만 실효는 제일 큼

여기서 한 가지 짚고 갈 부분은, 익스플로잇 자체를 시그니처로 잡겠다는 접근은 잘 안 먹힌다는 점임. 자바스크립트는 난독화가 너무 쉽고, 공격 코드는 매번 형태가 바뀜. 그래서 "페이로드를 탐지"하기보다 "침해 이후의 행위를 탐지"하는 쪽으로 무게중심을 옮기는 게 맞다고 봄.

5. 대응 시나리오를 미리 써두기

취약점 공지가 뜬 다음에 대응 절차를 만들면 이미 늦음. 브라우저 계열 긴급 패치는 앞으로도 계속 나올 거라, 아예 템플릿을 만들어두는 걸 권함.

공지 확인 후 1시간 내 — 사내 전체 브라우저 버전 분포 조회 쿼리 실행
24시간 내 — 정책 배포로 강제 업데이트 + 재시작 알림 발송
72시간 내 — 미적용 단말 개별 추적, 격리망·키오스크 등 자동 업데이트 예외 자산 수동 처리
동시에 — 최근 7일치 렌더러 크래시 로그와 브라우저 자식 프로세스 로그를 소급 조회해 이미 당한 흔적이 있는지 확인

마지막 항목이 특히 중요함. 패치는 앞으로를 막는 거지, 이미 열렸던 문을 되돌려주진 않기 때문임.

마무리

타입 컨피전은 이름만 들으면 난해해 보이지만, 결국 "컴퓨터가 이 데이터를 무엇이라고 믿는가"의 문제임. 그 믿음이 어긋나면 메모리 안전성이 무너지고, 브라우저처럼 매일 낯선 코드를 실행하는 프로그램에서는 그 대가가 특히 큼. 그러다 보니 V8 관련 CVE는 앞으로도 꾸준히 나올 거라 보는 게 현실적이고, 우리가 할 일은 매번 놀라는 게 아니라 버전 인벤토리와 크래시 로그라는 두 개의 눈을 상시로 켜두는 것 아닐까 싶음.

오늘 당장 해볼 수 있는 건 하나임. 지금 쓰는 브라우저 주소창에 chrome://version 을 찍어보고, 그 숫자가 최신인지 확인해보기. 그리고 회사 자산이라면 나 말고 다른 사람들 것도 어떤지 한 번 물어봐 주기. 이 작은 습관이 생각보다 멀리까지 갑니다. 다들 각자 환경에서 한 번씩 점검해보고, 재미있는 탐지 아이디어 있으면 댓글로 나눠주세요. 같이 정리해봐요!

PLC 두 모델 사이의 거리를 AI가 좁혔을 때 — 방어자가 다시 계산해야 할 것들

Wed, 2 Sep 2026 21:31:56 +0900

이미지 출처: The Hacker News

보안 컨퍼런스 발표 자료 중에 이런 문장이 있었음. "동일 벤더의 다른 모델로 익스플로잇을 옮기는 데 보통 몇 주가 걸린다." 연구자들이 대형 언어모델을 붙여 그 작업을 시도했더니, 사전 인증(pre-auth) 원격코드실행 익스플로잇이 다른 PLC 모델에서 동작하기까지 걸린 시간이 며칠 단위로 줄었다는 결과가 나옴. 여기서 방어자가 붙잡아야 할 건 "AI가 해킹한다"는 자극적인 헤드라인이 아니라, 익스플로잇 재사용 비용이 내려가면 우리 자산 목록의 우선순위가 통째로 바뀐다는 사실임.

핵심 요약

연구자들이 LLM을 활용해 한 PLC 모델의 pre-auth RCE 익스플로잇을 같은 계열 다른 모델로 이식하는 데 성공했고, 기존에 수 주 걸리던 포팅 시간이 크게 단축됨
핵심 위협은 새로운 취약점이 아니라 "패치 안 된 소수 모델"이라 안심하던 자산이 더 이상 안전지대가 아니게 된 것
OT 환경은 즉시 패치가 어려우므로 네트워크 분리·프로토콜 화이트리스트·PLC 상태 변화 모니터링 같은 보상통제로 방어선을 세워야 함

1. 무슨 일이 있었나 — 사건의 뼈대

정리하면 이럼.

연구자들이 이미 알려진 PLC 취약점 하나를 골랐음. 인증 없이 네트워크만 닿으면 코드 실행이 가능한 부류, 즉 pre-auth RCE.
이 익스플로잇은 특정 모델·특정 펌웨어에서만 동작하도록 만들어져 있었음. 메모리 배치, 함수 오프셋, 프로토콜 처리 루틴이 모델마다 미묘하게 다르기 때문임.
연구자들은 대상 모델의 펌웨어를 뜯어 얻은 정보를 LLM에게 주고, 원본 익스플로잇을 다른 모델용으로 다시 쓰게 하는 반복 작업을 돌렸음.
결과는 동작하는 익스플로잇. 사람이 붙어서 검증하고 손봐야 하는 구간은 여전히 남았지만, 가장 지루하고 시간을 잡아먹던 "차이 찾아 맞추기" 작업이 대폭 압축됐음.

여기서 오해하지 말아야 할 게 있는데, AI가 스스로 0-day를 발굴해 세상에 없던 공격을 만든 게 아님. 이미 존재하는 공격을 다른 문에 맞는 열쇠로 갈아 끼우는 작업의 인건비가 내려간 것임. 방어 입장에서는 이 구분이 꽤 중요함.

2. 왜 하필 PLC인가

PLC(Programmable Logic Controller)는 공장 라인, 정수장 펌프, 빌딩 공조, 발전 설비 같은 물리 세계를 직접 제어하는 장비임. IT 서버가 털리면 데이터가 새지만, PLC가 털리면 밸브가 열리고 모터가 멈춤. 그런데 이 장비들의 보안 특성이 좀 고약함.

패치가 곧 정지: 펌웨어 업데이트는 라인 정지를 의미함. 분기 단위, 심하면 연 단위 정비 기간까지 미뤄짐.
수명이 김: 10년, 15년 넘게 도는 장비가 흔함. 벤더가 지원을 끝낸 모델도 현장에서 여전히 돌아감.
인증 개념이 얕음: 설계 당시엔 폐쇄망 전제였음. 프로토콜 자체에 인증이 없거나 형식적인 경우가 많음.
모델 파편화: 같은 시리즈여도 리비전마다 펌웨어가 다름. 역설적으로 이게 지금까지 일종의 방어막이었음.

마지막 항목이 이번 연구가 건드린 지점임. "우리 장비는 마이너 모델이라 공개된 PoC가 없다"는 말이 그동안 은근한 위안이었는데, 포팅 비용이 내려가면 그 위안은 유통기한이 짧아짐.

3. 방어자 관점에서 바뀌는 계산

위험도 산정을 다시 해야 함. 기존에는 "공개 PoC 존재 여부"가 실질 위험을 가르는 큰 변수였음. 앞으로는 이렇게 봐야 함.

같은 코드베이스를 공유하는 형제 모델은 한 묶음으로 취급. A 모델에 PoC가 나왔으면 B·C 모델도 노출 상태로 간주하고 대응 우선순위를 매기는 게 안전함.
"어렵다"는 시간 지연에 기대지 않기. 포팅 난이도는 공격자 입장에서 비용이었지 방어책이 아니었음. 비용이 줄면 방어 효과도 같이 줄어듦.
노출면이 유일한 상수. 인터넷이나 사무망에서 PLC 관리 포트에 닿을 수 있느냐, 이게 여전히 가장 확실한 통제 지점임.

4. 지금 당장 할 수 있는 탐지·완화

펌웨어를 못 올린다고 손 놓을 필요는 없음. 개인적으로는 아래 순서를 추천함.

노출 자산 실사부터: Shodan이나 Censys 같은 검색엔진에 자사 IP 대역을 넣어 산업용 프로토콜 포트가 외부로 열려 있는지 확인. 놀랍게도 "설치 업체가 원격 유지보수용으로 뚫어둔 포트"가 이 단계에서 자주 나옴.
망 분리와 단방향 통로: 제어망과 업무망 사이에 방화벽·DMZ를 두고, 가능하면 데이터는 나가는 방향만 허용. 엔지니어링 워크스테이션은 제어망 안쪽에 두고 별도 계정으로 관리.
프로토콜 화이트리스트: Modbus, S7comm, EtherNet/IP 같은 제어 프로토콜은 통신 상대와 기능 코드가 사실상 고정임. "허용된 HMI IP에서 온 읽기 요청만" 같은 규칙을 세우면 정체불명의 쓰기·다운로드 명령이 곧바로 걸림.
PLC 상태 변화를 이벤트로 다루기: 프로그램 다운로드, RUN/STOP 모드 전환, 펌웨어 업데이트 시도는 정상 운영 중엔 거의 안 일어나는 행위임. 이런 이벤트를 SIEM으로 보내고 정비 일정과 대조하면 탐지 정확도가 꽤 높음.
펌웨어 해시·설정 기준선 관리: 정상 상태의 펌웨어 버전과 로직 프로그램을 기록해두고 주기적으로 비교. 변조 여부를 판단할 기준선이 없으면 사고 후 포렌식이 거의 불가능해짐.
정비 창에 맞춘 패치 계획: 벤더 권고를 모아두고 다음 정비 기간에 한 번에 반영할 목록을 미리 만들어두는 게 현실적임. 급할 때 만들면 항상 빠뜨리게 됨.

5. 조금 더 넓게 보면

이번 연구가 던지는 메시지는 OT에만 국한되지 않음. 익스플로잇을 다른 아키텍처·다른 버전·다른 제품으로 옮기는 작업 전반이 저렴해지고 있다는 신호로 읽는 게 맞다고 봄. 그동안 우리는 "취약점은 있지만 실제로 공격하려면 실력과 시간이 필요하니까"라는 암묵적 완충재 위에서 위험을 계산해왔는데, 그 완충재가 얇아지는 중임.

그렇다고 비관할 일만은 아닌 것 같음. 같은 도구는 방어 쪽에서도 씀. 펌웨어 차이 분석, 로그 상관관계 찾기, 자산 목록 정리, 탐지 규칙 초안 작성 같은 작업도 똑같이 빨라짐. 결국 남는 건 누가 먼저 자기 환경을 정확히 파악하고 있느냐의 문제인 것 같음. 공격자는 우리 네트워크 구조를 모르지만, 우리는 알 수 있음. 그게 유일하게 우리 쪽이 앞선 카드임.

마무리

오늘 당장 할 일 하나만 고르라면, 제어망 장비 목록을 열어서 "이 모델이랑 같은 계열인 형제 모델에 공개된 취약점이 있나"를 확인해보는 것부터 권하고 싶음. 목록이 없으면 목록 만드는 게 첫 과제고. 지루한 작업이지만 이런 게 쌓여야 나중에 뉴스가 터졌을 때 몇 분 안에 "우리는 해당 없음" 또는 "여기 세 대 위험함"이라고 답할 수 있음.

혹시 현장에서 제어망 자산 관리하시는 분들, 어떤 방식으로 기준선 잡고 계신지 궁금함. 댓글로 공유해주시면 같이 배워보아요!

지도 서비스 백엔드에 뚫린 세 칸짜리 사다리 — GeoNetwork 메타데이터 엔진 이야기

Wed, 2 Sep 2026 19:01:43 +0900

이미지 출처: The Hacker News

공공 공간정보 포털을 들여다보면 앞단은 대개 조용함. 지도 타일이 뜨고, 검색창이 있고, 좌표를 넣으면 항공사진이 나오는 정도. 그런데 그 뒤에서 메타데이터를 관리하는 카탈로그 엔진 — GeoNetwork 같은 소프트웨어 — 은 생각보다 훨씬 많은 걸 하고 있음. XML을 파싱하고, 외부 카탈로그와 하베스팅으로 동기화하고, 스타일시트로 문서를 변환하고, 파일을 디스크에 씀. 이번에 정리된 취약점 묶음은 정확히 그 '많은 일' 쪽에서 나왔고, 인증 없이도 연결이 되는 형태라 성격이 꽤 나쁨.

핵심 요약

GeoNetwork 메타데이터 카탈로그에서 인증 없이 접근 가능한 엔드포인트를 시작점으로, XML 처리·변환·파일 쓰기 단계를 엮어 원격 코드 실행까지 이어지는 체인이 수정됨
단일 CVE가 아니라 '작은 결함 여러 개의 연결'이라는 점이 핵심 — 개별 항목만 보면 위험도가 낮아 보여 패치 우선순위에서 밀리기 쉬움
방어는 패치가 1순위, 그 다음이 익명 접근 범위 축소·아웃바운드 차단·XML 파서 하드닝·서블릿 컨테이너 프로세스 감시

왜 '체인'이라는 말이 중요한가

취약점 하나로 셸이 떨어지는 경우는 요즘 드묾. 대신 이런 조합이 흔함.

진입: 인증 없이 호출되는 API나 검색·하베스팅 관련 엔드포인트. 원래 공개 카탈로그라는 성격 때문에 익명 접근이 기본으로 열려 있는 경우가 많음
확장: XML 문서를 처리하는 과정에서 외부 엔티티나 외부 리소스를 참조하게 만드는 부분. 여기서 서버가 공격자 쪽으로 먼저 나가주면 내부망 정찰·파일 읽기로 번짐
착지: 변환·업로드·임시파일 저장처럼 서버가 디스크에 뭔가를 쓰는 지점. 쓰이는 위치를 통제할 수 있으면 웹 애플리케이션이 실행하는 경로로 코드가 들어감

세 칸이 다 있어야 사다리가 완성되는데, 문제는 방어자 입장에서 각 칸을 따로 보면 다 "심각도 중간" 정도로 보인다는 것. 그래서 이런 건 개별 CVE 점수보다 연결 가능성을 기준으로 판단하는 게 맞다고 봄.

내 자산에 이게 있는지부터

공간정보 계열 소프트웨어는 도입 경로가 특이해서 자산 목록에서 자주 누락됨. 보안팀이 아니라 GIS 담당 부서가 직접 올린 서버, 연구과제로 세워놓고 그대로 남은 인스턴스, 컨설팅 업체가 납품하고 인수인계가 흐지부지된 포털 같은 것들.

내부 스캔에서 톰캣·제티 계열 서블릿 컨테이너가 뜨는 호스트 중 /geonetwork, /catalog, /srv/ 같은 경로가 응답하는지 확인
HTTP 응답 헤더와 로그인 페이지 푸터에 남는 제품·버전 문자열 수집. 오픈소스 카탈로그는 버전 표기가 화면에 그대로 남아 있는 경우가 많음
GeoServer·GeoNetwork·PostGIS가 같은 망에 세트로 묶여 있는지도 같이 봐야 함. 한 칸이 뚫리면 옆 칸의 DB 자격증명이 설정파일에 평문으로 있는 구성이 흔함

탐지 관점 — 무엇을 로그에서 찾을까

공격 재현 자체는 여기서 다루지 않고, 남는 흔적만 정리함.

아웃바운드가 제일 정직함: 지도 서버가 갑자기 외부 HTTP나 DNS로 나가는 순간이 있으면 그게 신호. 정상 운영에서도 외부 카탈로그 하베스팅 트래픽은 있으니, 허용된 하베스팅 대상 목록을 화이트리스트로 만들어두고 그 밖으로 나가는 것만 알람을 거는 게 실용적임
웹 접근 로그: 익명 세션에서 관리·설정·하베스터 관련 경로로 POST가 들어오는 패턴, 그리고 짧은 시간에 같은 IP가 여러 엔드포인트를 순차로 두드리는 흐름
파일시스템: 웹 애플리케이션 배포 디렉터리와 데이터 디렉터리에 새 파일이 생기는지. 특히 정적 리소스 폴더에 스크립트 확장자가 새로 생기면 그 시점 전후 30분 로그를 통째로 봐야 함
프로세스 트리: 자바 프로세스가 셸이나 스크립트 인터프리터를 자식으로 띄우는 건 이런 서비스에서 정상 동작이 거의 아님. EDR에 이 규칙 하나만 넣어도 착지 단계는 상당히 잡힘

완화 — 순서대로

패치가 1순위. 다른 얘기 다 필요 없고 벤더가 낸 수정 버전으로 올리는 게 가장 확실함. 다만 공간정보 포털은 데이터 마이그레이션 부담 때문에 업그레이드를 미루는 곳이 많은데, 그럴수록 아래 항목이 임시 방벽이 됨
익명으로 열린 범위 축소: 공개 검색은 열어두더라도 편집·하베스팅·관리 계열 엔드포인트는 리버스 프록시 단에서 내부망 IP로 제한. 실제로 이런 서비스는 '조회는 전세계, 쓰기는 사내'로 나누는 게 자연스러움
XML 파서 하드닝: 외부 엔티티·DTD 처리를 끄는 설정을 애플리케이션과 컨테이너 양쪽에서 확인. 라이브러리 기본값에 기대지 말고 실제 설정값을 눈으로 볼 것
아웃바운드 차단: 서버가 인터넷으로 임의 접속하지 못하게 막고, 하베스팅이 필요하면 프록시 경유로 목적지를 명시. 이거 하나로 정찰 단계에서 체인이 끊기는 경우가 많음
실행 권한 분리: 애플리케이션 계정이 자기 배포 디렉터리에 쓰기 권한을 갖고 있지 않은지 점검. 업로드 경로는 실행 불가 마운트로

남는 생각

이런 사건을 볼 때마다 드는 생각인데, 공공 포털의 진짜 약점은 코드가 아니라 담당자가 애매한 시스템인 것 같음. 지도는 잘 뜨니까 아무도 안 건드리고, 건드리는 사람은 GIS는 알지만 패치 주기는 안 보고, 보안팀은 그 서버가 있는 줄도 모름. 그러다 보니 몇 년 지난 버전이 그대로 인터넷에 붙어 있는 상황이 만들어짐.

그래서 개인적으로는 이번 건을 계기로 '우리 조직에서 지도·공간정보를 다루는 서버가 몇 대이고 누가 주인인가'를 한 줄로 답할 수 있게 정리해두는 걸 추천함. 취약점은 계속 나올 거고, 그때마다 급한 건 패치 자체가 아니라 '어디에 깔려 있는지 찾는 시간'이라서 그럼. 자산 목록만 준비돼 있으면 다음 공지가 떴을 때 반나절이면 끝날 일임.

혹시 운영 중인 카탈로그 서버 있으시면 버전 확인부터 같이 해보아요. 점검하면서 걸린 부분이나 우회 설정으로 막은 사례 있으면 댓글로 공유해주시면 저도 배우겠음.

Langflow 1.3.0과 Rails 5.2.2.1 — 오래된 패치선 두 개가 지금 다시 두들겨 맞는 중

Tue, 1 Sep 2026 21:32:30 +0900

이미지 출처: The Hacker News

테스트용으로 띄워둔 웹 서버 액세스 로그를 훑다 보면, 사람이 아니라 기계가 남긴 흔적이 확연히 눈에 띄는 구간이 있다. 몇 초 간격으로 같은 경로를 두드리는데, 그 목록에 /api/v1/validate/code 같은 요청이 섞여 있고, 또 어떤 요청은 URL은 평범한데 Accept 헤더가 이상하게 길다. 하나는 AI 워크플로 도구인 Langflow를 노린 것이고, 다른 하나는 Ruby on Rails의 파일 노출 결함을 노린 것이다. 둘 다 패치가 나온 지 꽤 됐는데도, 공격자들의 스캔 목록에서는 아직 지워지지 않았다.

핵심 요약

Langflow의 코드 검증 엔드포인트 결함(CVE-2025-3248)과 Rails Action View의 파일 내용 노출 결함(CVE-2019-5418)이 하나의 자동화 스캔 세트로 묶여 관측되고 있음
목적은 단순 정찰이 아니라 설정 파일·자격증명 수집과 C2 연결 확보이며, 특히 Rails의 secret_key_base 유출은 세션 위조를 거쳐 코드 실행까지 이어질 수 있음
방어는 버전 상향이 1순위지만, 그와 함께 인증 경계·아웃바운드 통제·자격증명 재발급까지 묶어서 처리해야 실제로 끝남

1. 왜 이 둘이 한 세트로 들어오는가

겉보기에 접점이 없어 보이는 두 제품이 같은 캠페인에서 관측되는 이유는 단순하다. 공격자 입장에서 이 둘은 성격이 같은 매물임.

둘 다 인증 없이 단일 HTTP 요청으로 결과를 확인할 수 있어 대량 스캔에 적합함
둘 다 성공 여부가 응답만 봐도 바로 구분되어, 자동화 도구가 표적 목록을 추리기 쉬움
둘 다 개발·내부용으로 띄워두고 잊힌 인스턴스가 많아, 패치 적용률이 낮음

즉 이건 정교한 표적 공격이라기보다, 인터넷 전체를 훑는 그물망에 가까움. 문제는 그 그물에 한 번 걸리면 그다음 단계는 자동으로 진행된다는 점.

2. Langflow 쪽에서 벌어지는 일

Langflow는 LLM 파이프라인을 시각적으로 조립하는 도구라, 사용자가 작성한 파이썬 코드 조각을 다루는 기능이 구조적으로 들어가 있음. 문제가 된 지점은 이 코드 검증 기능이었음.

사용자 코드를 문법 검사한다는 명목으로 서버에서 파싱한 뒤, 일부 구문 요소가 평가(evaluate)되는 경로가 존재했음
검사 자체는 안전해 보여도, 함수 정의의 기본값이나 데코레이터처럼 "정의만 해도 값이 계산되는" 위치가 있으면 그 순간이 실행 시점이 됨
해당 엔드포인트가 인증을 요구하지 않았기 때문에, 외부에서 그대로 호출 가능했음

공격 코드를 굳이 옮겨 적을 필요는 없고, 핵심 교훈만 기억하면 됨. "검증"과 "실행"은 생각보다 가까운 이웃이라는 것. 사용자 입력을 언어 파서에 넘기는 기능이 있다면, 그 파서가 어디까지 계산을 수행하는지 반드시 확인해야 함. 수정은 1.3.0 계열에서 이루어졌고, 이 결함은 실제 악용이 확인되어 봇넷이 감염 장비를 끌어모으는 통로로 쓰인 전력이 있음. 감염 이후 흐름은 대체로 스크립트 내려받기 → 상주 → 외부 C2 접속 순서로 정형화되어 있음.

3. Rails 쪽 — 헤더 한 줄로 설정 파일을 읽어가는 방식

Rails 결함은 성격이 다름. 코드 실행이 아니라 파일 내용 노출임. Action View가 요청의 Accept 헤더에 담긴 값을 템플릿 경로 결정에 활용하던 시절, 그 값에 상위 디렉터리 참조가 섞이면 의도치 않은 파일이 렌더링 대상이 될 수 있었음.

공격자가 실제로 노리는 파일은 뻔함 — config/database.yml, config/secrets.yml, .env, 그리고 credentials 관련 파일
여기서 DB 접속 정보가 나오면 곧장 측면 이동 재료가 되고, 클라우드 키가 나오면 계정 자체가 흔들림
가장 위험한 건 secret_key_base 유출. 이 값은 세션 쿠키 서명에 쓰이므로, 유출되면 공격자가 임의의 세션을 만들어낼 수 있고 역직렬화 경로와 결합될 경우 원격 코드 실행으로 승격될 여지가 생김

수정 버전은 5.2.2.1, 5.1.6.2, 4.2.11.1, 그리고 6.0 계열 초기 버전에서 배포됐음. 문제는 이 취약점이 실패해도 조용하고 성공해도 조용하다는 점. 서버는 200을 돌려주고, 애플리케이션 에러 로그에는 아무것도 남지 않을 수 있음.

4. 탐지 포인트 — 어디를 보면 보이는가

두 사안 모두 네트워크 경계 로그에서 잡아내는 편이 현실적임. 개인적으로는 아래 순서로 확인하는 걸 추천함.

Accept 헤더 길이·형태 이상: 정상 브라우저의 Accept 값은 패턴이 정해져 있음. 여기에 경로 구분자나 상위 디렉터리 표기가 들어간 요청은 그 자체로 유의미한 신호
인증 없이 도달한 API 경로: 관리·검증·디버그 성격의 엔드포인트에 인증 헤더 없는 200 응답이 남았는지 확인
동일 IP의 다품종 스캔: 한 소스가 Langflow 경로와 Rails 경로를 연달아 두드렸다면 캠페인성 스캔으로 봐도 무방
아웃바운드가 진짜 증거: 애플리케이션 서버가 갑자기 낯선 IP로 HTTP 요청을 보내거나, curl·wget·셸 프로세스를 새로 띄웠다면 그건 이미 다음 단계임
응답 크기의 급변: 평소 수 KB짜리 응답을 내던 경로가 갑자기 다른 크기를 돌려줬다면 파일 노출을 의심

5. 완화 — 버전만 올리고 끝내면 안 되는 이유

패치는 당연히 1순위지만, 이미 스캔에 걸렸을 가능성을 전제로 움직여야 함.

Langflow는 고정 버전 이상으로 올리고, 애초에 인터넷에 직접 노출하지 않는 것이 정답에 가까움. 필요하다면 VPN이나 리버스 프록시 인증 뒤에 둘 것
Rails는 지원 버전으로 올리되, 노출 정황이 조금이라도 있으면 secret_key_base와 DB 자격증명을 재발급. 값이 이미 새어나간 뒤라면 패치는 문을 닫을 뿐 열쇠를 회수해주지는 않음
애플리케이션 컨테이너의 아웃바운드를 기본 차단하고 필요한 목적지만 허용. C2 단계에서 끊어내는 가장 값싼 방법
설정 파일을 소스 트리에 두지 말고 환경변수나 시크릿 매니저로 분리. 파일이 읽혀도 건질 게 없게 만드는 접근
내부에서만 쓰는 도구라도 자산 목록에 올려둘 것. 이번 사례에서 털리는 건 대부분 "누가 언제 띄웠는지 모르는" 인스턴스임

6. 사후 점검 체크리스트

해당 서버의 crontab, systemd 유닛, 시작 스크립트에 낯선 항목이 추가됐는지
임시 디렉터리에 실행 권한이 붙은 파일이 생겼는지
웹 서비스 계정으로 실행된 셸 프로세스 이력이 있는지
노출됐을 수 있는 자격증명이 다른 시스템에서 재사용되고 있지는 않은지

이번 건을 보면서 다시 확인한 건, 새 취약점보다 이미 알려진 취약점의 잔존율이 훨씬 무섭다는 사실이다. Rails 쪽 결함은 나온 지 한참인데도 여전히 스캔 목록 상단에 남아 있고, Langflow처럼 최근에 급하게 퍼진 도구는 아예 "설치했다는 사실 자체를 잊은" 사례가 많다. 공격자는 새로운 걸 찾는 게 아니라, 고쳐지지 않은 걸 찾는다.

오늘은 다른 것 말고 딱 두 가지만 해봐도 좋겠습니다. 우리 조직에서 인터넷에 노출된 웹 서비스 목록을 한 번 뽑아보는 것, 그리고 그중 버전을 마지막으로 확인한 게 언제인지 적어보는 것. 막상 적어보면 생각보다 오래된 항목이 나오거든요. 여러분 환경에서는 어떤 잊힌 서비스가 나왔는지 댓글로 공유해주시면 저도 같이 정리해보겠습니다. 같이 해보아요!

인쇄 대기열 뒤의 관리 콘솔: PaperCut CVE-2026-81578 방어 노트

Tue, 1 Sep 2026 13:02:09 +0900

이미지 출처: CISA KEV

사무실 복합기 옆 랙에 조용히 꽂혀 있는 서버 한 대. 자산 대장에는 그냥 "프린터 관리" 다섯 글자로 적혀 있고, 담당 부서는 총무팀으로 되어 있고, 보안팀 점검 리스트에서는 매년 마지막 순번으로 밀리는 그 장비 말입니다. PaperCut NG/MF에서 Missing Authentication for Critical Function 계열 취약점(CVE-2026-81578)이 공개될 때마다 저는 이 장면부터 떠올리게 되는 것 같습니다.

핵심 요약

CVE-2026-81578은 PaperCut NG/MF의 중요 기능이 인증 검사 없이 호출될 수 있는 문제로, CWE-306(중요 기능에 대한 인증 누락) 계열에 속함
프린트 서버는 AD 연동·서비스 계정·전 부서 접근이라는 조건을 동시에 갖고 있어, 권한 한 칸이 뚫리면 피해가 인쇄 영역에서 끝나지 않음
패치가 최우선이고, 그 전까지는 관리 포트 노출 차단·Device IP 제한·관리 이벤트 로그 감시로 시간을 벌어야 함

인증이 "없다"는 말의 정확한 의미

인증 우회(bypass)와 인증 누락(missing)은 비슷해 보여도 결이 다름. 우회는 잠긴 문의 자물쇠를 따는 일이고, 누락은 애초에 그 문에 자물쇠가 달리지 않은 상태임.

개발 단계에서 "이 엔드포인트는 내부 컴포넌트끼리만 부르니까"라는 전제가 코드에 그대로 남는 경우가 대부분임
정상 UI 흐름에서는 로그인한 관리자만 도달하니 QA에서도 잡히지 않음. 화면을 거치지 않고 HTTP 요청을 직접 만들면 전제가 무너짐
PaperCut처럼 관리 콘솔·장치 연동·릴리스 스테이션 등 여러 인터페이스가 한 프로세스 안에 공존하는 제품일수록 이런 틈이 생기기 쉬움
익스플로잇 난이도가 낮다는 점이 핵심임. 특별한 메모리 조작도, 정교한 레이스 컨디션도 필요 없이 요청 한 번으로 성립하는 구조라 공개 직후 스캐닝이 급증함

왜 하필 프린트 서버인가

공격자 입장에서 프린트 관리 서버는 가성비가 아주 좋은 표적임.

디렉터리 연동: 사용자 인증·부서 과금을 위해 AD/LDAP에 붙어 있는 경우가 많고, 연동 계정의 권한이 필요 이상으로 넓게 잡혀 있는 사례가 흔함
높은 실행 권한: 서비스 계정이 SYSTEM 또는 로컬 관리자 수준으로 돌아가므로, 애플리케이션 레벨 권한 획득이 곧 호스트 장악으로 이어짐
전사 연결성: 모든 부서에서 접근하는 서버라 내부 방화벽 정책이 관대함. 측면 이동(lateral movement)의 출발점으로 삼기 좋음
낮은 관심도: 패치 주기가 길고, 다운타임 협의가 어렵고, "인쇄 안 되면 민원"이라는 이유로 변경이 미뤄짐

공격 재현은 개념 수준으로만 말하면, 인증 검사가 붙지 않은 관리 기능에 요청을 보내 설정 값을 바꾸거나, 관리 계정을 새로 만들거나, 서버가 제공하는 스크립트·연동 기능을 통해 명령 실행 경로를 여는 흐름임. 여기서 중요한 건 순서가 아니라, "설정 변경이 곧 코드 실행"인 제품 구조 자체가 위험을 키운다는 점이라고 봄.

탐지: 무엇을 봐야 하는가

패치를 적용했더라도 이미 건드려졌는지 확인해야 함. 프린트 서버는 로그가 의외로 풍부한 편임.

관리 이벤트 로그: 관리 콘솔의 감사 로그에서 관리자 계정 생성·권한 변경·설정 항목 수정 이력을 시간순으로 확인. 근무 시간 외 변경은 무조건 의심 대상
웹 접근 로그: UI 이동 경로 없이 관리 기능 URL이 단독으로 호출된 흔적. Referer가 비어 있고 User-Agent가 스크립트 기본값인 요청 묶음
프로세스 계보: PaperCut 서비스 프로세스가 자식으로 cmd, powershell, wscript 등을 띄운 기록. 정상 운영에서는 거의 나오지 않는 조합이라 탐지 규칙으로 쓰기 좋음
아웃바운드 트래픽: 인쇄 서버가 외부로 HTTP(S) 세션을 여는 패턴. 프린트 서버는 원래 밖으로 말을 걸 일이 거의 없음
파일 시스템: 애플리케이션 디렉터리와 임시 경로에 최근 생성된 스크립트·아카이브 파일

완화: 오늘 안에 할 수 있는 것

패치 적용이 1순위. 벤더가 배포한 최신 유지보수 버전으로 올리는 것 외에 근본 해결책은 없음
노출 차단. 관리 콘솔 포트가 인터넷에서 열려 있는지 외부에서 직접 확인. 프린트 서버가 공인 IP를 갖고 있어야 할 이유는 거의 없음
접근 제어 강화. 제품이 제공하는 장치 IP 허용 목록과 관리 인터페이스 접근 IP 제한을 걸어 두면, 동일한 취약점이 또 나와도 사정권이 좁아짐
계정 권한 축소. 디렉터리 연동 계정을 읽기 전용 수준으로 낮추고, 서비스 실행 계정도 최소 권한으로 재검토
망 분리. 프린트 VLAN에서 도메인 컨트롤러나 파일 서버로 향하는 트래픽을 명시적으로 제한. 침해가 발생해도 한 칸에서 멈추게 만드는 작업임

정리하며

혹시 사내에서 이런 장비 목록을 정리해 본 경험이 있으시다면, 어떤 기준으로 우선순위를 매기셨는지 댓글로 공유해 주세요. 저도 아직 기준을 다듬는 중이라, 같이 채워 나가 보아요!

PaperCut NG/MF 관리 기능에 숨은 unsafe reflection, CVE-2026-82078 대응 정리

Tue, 1 Sep 2026 08:02:11 +0900

이미지 출처: CISA KEV

사무실 구석에 놓인 인쇄 서버는 자산 목록에서도 늘 맨 아래쪽에 있음. 담당은 총무팀이고, 패치 주기는 "복합기 잘 나오면 됐지"에서 멈춰 있는 경우가 대부분임. 그런데 그 장비가 도메인 계정으로 인증을 받고, 부서별 출력 로그를 쌓고, 관리 콘솔을 웹으로 열어두고 있다면 이야기가 달라짐. CVE-2026-82078은 바로 그 PaperCut NG/MF에서 안전하지 않은 리플렉션(unsafe reflection) 처리가 문제로 지목된 사례임.

핵심 요약

PaperCut NG/MF가 외부에서 들어온 값을 클래스·메서드 이름으로 그대로 써서 호출하는 구조(CWE-470)가 문제의 핵심임
공격이 성사되면 인쇄 서버 프로세스 권한으로 임의 코드가 실행될 수 있고, 이 서버는 보통 내부망 깊숙한 곳에 있음
패치가 1순위, 그다음이 관리 포트(9191/9192) 노출 차단과 pc-app-server의 자식 프로세스 감시임

1. unsafe reflection이 왜 위험한가

리플렉션은 자바에서 "이름만 가지고 클래스를 찾아 실행"하는 기능임. 개발 편의를 위해 플러그인 구조나 동적 핸들러 매핑에 흔히 씀. 문제는 그 이름을 사용자가 보낸 파라미터에서 가져올 때 발생함.

정상 흐름: 요청 값 → 허용 목록 대조 → 정해진 핸들러 호출
취약 흐름: 요청 값 → 그대로 클래스 로딩 → 인자까지 요청에서 받아 메서드 실행

후자면 개발자가 의도한 적 없는 내부 클래스까지 호출 대상이 됨. 여기서 실행 흐름을 바꿀 수 있는 클래스가 하나만 걸려도 원격 코드 실행으로 이어짐. 개념은 딱 여기까지고, 어떤 클래스를 어떻게 엮는지는 다루지 않음.

2. 인쇄 서버가 표적이 되는 진짜 이유

PaperCut은 2023년에도 인증 우회와 결합된 취약점이 랜섬웨어 그룹의 초기 침투 경로로 실제 악용된 전력이 있음. 공격자 입장에서 매력적인 조건이 겹쳐 있기 때문임.

웹 관리 콘솔이 상시 떠 있고, 편의상 인터넷 노출된 사례가 꾸준히 발견됨
서비스 계정 권한이 과하게 높은 경우가 많고, 윈도우에서는 SYSTEM에 가까운 권한으로 도는 구성이 흔함
AD 연동으로 사용자 목록·부서 구조를 이미 들고 있어 내부 정찰 자료로 바로 쓰임
EDR 정책 예외로 빠져 있는 경우가 잦음. 출력 지연 민원 때문에 예외를 넣어놓고 잊는 패턴임

3. 탐지 포인트

패치 전이든 후든, 이 계열 취약점은 프로세스 계보에서 가장 선명하게 드러남. 인쇄 서버가 갑자기 셸을 띄울 이유는 없음.

자식 프로세스 감시: pc-app-server.exe나 javaw.exe가 부모인 cmd.exe, powershell.exe, certutil, bitsadmin 실행. Sysmon Event ID 1로 부모-자식 관계를 걸어두면 오탐이 거의 없는 규칙이 나옴
애플리케이션 로그: 설치 경로의 server/logs/server.log와 관리자 감사 로그. 클래스 로딩 실패, ClassNotFoundException, NoSuchMethodException이 짧은 시간에 반복되면 이름을 바꿔가며 더듬은 흔적일 가능성이 큼
웹 접근 로그: 관리 경로에 대한 비정상 파라미터, 점(.)으로 구분된 패키지 형태 문자열이 값으로 들어오는 요청
파일 생성: 서버 디렉터리 하위나 임시 폴더에 새로 생긴 스크립트·JSP·실행 파일
아웃바운드 트래픽: 인쇄 서버가 외부로 HTTPS 세션을 새로 여는 행위. 이 장비는 원래 밖으로 나갈 일이 거의 없어서 베이스라인 잡기가 쉬움

4. 완화 순서

업그레이드가 최우선. 벤더가 공지한 수정 빌드로 올리는 것 외에 근본 해결책은 없음. 리플렉션 입력 검증은 애플리케이션 코드 안에서만 고칠 수 있음
관리 콘솔 노출 제거. 9191/9192 포트를 인터넷에 열어둘 이유가 없음. 외부 접근이 꼭 필요하면 VPN이나 리버스 프록시 뒤로 넣고 IP 허용 목록을 붙이기
권한 낮추기. 서비스 실행 계정을 전용 계정으로 분리하고, 도메인 관리자 권한과 절대 엮지 않기
EDR 예외 재점검. 예외를 걸어야 한다면 스풀 디렉터리처럼 좁은 경로만 지정하고, 서버 실행 파일 자체는 절대 예외에서 빼지 않기

5. 이미 뚫렸는지 확인하려면

패치만 하고 끝내면 남아 있는 발판을 놓침. 최소한 이 정도는 훑어야 함.

관리자 계정 목록과 최근 로그인 이력, 낯선 계정 추가 여부
서비스 등록·예약 작업·자동 실행 항목 중 취약 기간에 생성된 것
웹 애플리케이션 디렉터리의 파일 변경 시각 비교
해당 서버 계정으로 다른 시스템에 시도된 인증 로그

개인적으로는 이런 "업무 보조 서버" 목록을 따로 만들어 관리하는 걸 추천함. 인쇄, 회의실 예약, 사내 위키, 파일 변환 서버처럼 다들 쓰지만 아무도 주인이 아닌 장비들 말임. 취약점은 늘 화려한 시스템이 아니라 이 목록에서 터짐. 이번 주에 딱 30분만 내서 내부망 스캔 한 번 돌려보고, PaperCut 버전부터 확인해보면 어떨까 함. 확인해보니 의외의 장비가 인터넷에 열려 있더라 하는 경험, 댓글로 나눠주시면 반갑겠음.

백신 예외 폴더가 ValleyRAT의 안전가옥이 됐다

Mon, 31 Aug 2026 21:32:15 +0900

이미지 출처: The Hacker News

사용자가 백신 설정 창을 열고, 예외 경로에 폴더 하나를 손수 추가한다. 설치가 자꾸 막히니까, 화면에 뜨는 안내대로. 그 클릭 한 번으로 그 폴더 안의 모든 파일은 검사 대상에서 영구히 빠지고, ValleyRAT은 바로 그 자리에 자기 집을 짓는다. 이번 사례가 불편한 이유는 익스플로잇이 정교해서가 아니라, 보안 제품을 무력화한 게 공격자가 아니라 피해자 본인이라서다.

핵심 요약

유효한 코드서명이 붙은 애드웨어·유틸리티가 미끼로 쓰이며, 사용자가 직접 백신 예외 경로를 등록하도록 유도함
예외 폴더 안에서 정상 서명 실행파일이 악성 DLL을 사이드로딩해 ValleyRAT 백도어를 메모리에 올림
방어의 초점은 시그니처가 아니라 예외 목록 자체를 자산으로 관리하고 감사하는 것에 있음

서명이 붙었다는 건 안전하다는 뜻이 아님

많은 조직이 아직도 "디지털 서명 있으면 일단 통과"라는 암묵적 규칙으로 움직이는데, 이 캠페인은 정확히 그 지점을 노림.

코드서명 인증서는 신원 확인이지 의도 검증이 아님. 발급기관은 "이 회사가 존재한다"까지만 보증함
애드웨어·번들 설치기 배포사는 합법 법인으로 등록돼 있어 정상적으로 인증서를 받을 수 있고, 그 인증서가 그대로 악성 로더에 재사용됨
서명이 유효하니 스마트스크린 경고 강도가 낮아지고, 게시자 기반 화이트리스트에 자동으로 들어감

즉 서명 검증에서 봐야 할 건 "유효/무효"가 아니라 발급 시점, 발급 대상 법인, 카운터서명 타임스탬프, 그리고 그 게시자가 조직 내에 존재할 이유가 있는가임.

감염 흐름을 개념 수준으로 정리하면

1단계 — 유입: 검색광고, 커뮤니티 링크, 사칭 다운로드 페이지를 통해 무료 유틸리티·최적화 도구·메신저 사칭 설치기를 내려받게 함
2단계 — 예외 유도: 설치 과정에서 "오탐이 있으니 설치 폴더를 백신 예외에 추가하라"는 안내를 띄움. 사용자는 스스로 관리자 권한으로 예외를 등록함
3단계 — 사이드로딩: 예외 폴더 안에 정상 서명된 실행파일과 이름만 같은 악성 DLL이 함께 놓이고, 실행파일이 그 DLL을 로드하며 로더가 기동됨
4단계 — 메모리 상주: 로더가 암호화된 페이로드를 복호화해 정상 프로세스 안에 주입함. 디스크에는 완성된 백도어 형태가 남지 않음
5단계 — 지속성: 실행 레지스트리 키, 예약 작업, COM 하이재킹 같은 흔한 수법을 조합해 재부팅을 넘김
6단계 — 통신: 비표준 고포트로 커스텀 프로토콜 비콘을 올리고, 원격 제어·자격증명 수집·추가 모듈 투입으로 이어짐

구조 자체는 새롭지 않음. 새로운 건 탐지 회피를 코드가 아니라 사용자 동의로 해결했다는 점임.

예외 목록이 왜 최악의 사각지대인가

예외는 한 번 등록되면 아무도 다시 안 봄. 티켓도 안 남고, 만료도 없고, 담당자가 퇴사해도 그대로 남아 있음. 그런데 예외 폴더는 실시간 검사, 행위 기반 차단, 때로는 클라우드 조회까지 통째로 비껴가는 사실상의 무결성 공백지대가 됨.

개인적으로는 예외 목록을 "설정"이 아니라 자산 목록으로 취급하길 권하는 편임. 서버 한 대, 계정 하나를 관리대장에 올리듯 예외 경로도 소유자·사유·만료일이 붙어 있어야 함.

방어자가 지금 확인할 것

예외 인벤토리 수집: Windows Defender 환경이면 Get-MpPreference의 ExclusionPath·ExclusionProcess·ExclusionExtension을 전 엔드포인트에서 긁어 중앙에 모으고, 사용자 프로필 하위나 임시 폴더를 가리키는 항목부터 즉시 회수
변경 자체를 이벤트로: Defender 구성 변경 이벤트(5007)와 예외 관련 레지스트리 값 생성을 알람으로 승격. 예외 추가는 정상 업무에서도 드문 행위라 오탐 부담이 적음
로컬 병합 차단: 정책으로 로컬 관리자의 예외 병합을 막아, 단말 사용자가 임의로 예외를 추가하지 못하게 함
사이드로딩 패턴: 서명된 실행파일이 다운로드·임시·사용자 폴더에서 실행되며 같은 디렉터리의 DLL을 로드하는 조합을 탐지 규칙으로. 이미지 로드 이벤트에서 서명 없는 DLL을 서명된 프로세스가 올리는 경우가 핵심 신호
EDR과 AV를 분리: AV 예외가 EDR 텔레메트리 수집까지 끄지 않도록 구성. 검사 예외와 관측 예외는 다른 개념이어야 함
게시자 화이트리스트 재점검: WDAC·AppLocker에서 게시자 규칙만 쓰지 말고 경로·해시와 결합. 광고·번들 소프트웨어 계열 게시자는 애초에 차단 목록에 두는 게 깔끔함
네트워크 관점: 일정 주기로 반복되는 비표준 포트 아웃바운드, TLS가 아닌 커스텀 바이너리 프로토콜, 새로 등장한 목적지 IP에 대한 장시간 세션 유지

사용자 교육은 문구를 바꿔야 함

"의심스러운 파일 열지 마세요"로는 이 공격을 못 막음. 이미 사용자는 자기가 원해서 그 프로그램을 설치하는 중이고, 화면의 안내가 그럴듯하기 때문임. 그래서 교육 문구는 이렇게 구체적이어야 한다고 봄. "어떤 정상 소프트웨어도 백신 예외 추가를 설치 조건으로 요구하지 않는다", 그리고 "예외 추가 요청은 그 자체가 침해 시도로 신고 대상"이라는 두 문장. 추상적인 주의보다 이런 단정적인 규칙 한 줄이 훨씬 잘 먹힘.

오늘 하루만 시간 내서 우리 조직 단말들의 예외 목록을 한 번 뽑아 보면 좋겠음. 아마 아무도 기억 못 하는 경로가 몇 개는 나올 텐데, 그게 지금 가장 싸게 막을 수 있는 구멍임. 뽑아 보고 이상한 항목 나왔다면 어떤 형태였는지 댓글로 공유해 주세요. 서로 사례를 모아두면 다음 캠페인 때 훨씬 빨리 알아볼 수 있을 겁니다. 같이 점검해 보아요!

"인증하려면 Win+R을 누르세요": TerminalFix가 노린 건 브라우저가 아니라 사람이었다

Sun, 30 Aug 2026 21:32:17 +0900

이미지 출처: The Hacker News

페이지 하나가 뜹니다. 익숙한 주황색 로고, 익숙한 "사람인지 확인하는 중" 문구. 그런데 이번엔 체크박스가 없어요. 대신 "확인을 완료하려면 Win+R을 누르고 Ctrl+V, Enter를 눌러주세요"라는 안내가 뜹니다. 여기서 손이 먼저 움직인 사람과, 잠깐 멈춘 사람. TerminalFix라는 이름이 붙은 이번 캠페인은 정확히 그 0.5초의 차이를 노렸습니다.

핵심 요약

가짜 Cloudflare 인증 화면으로 사용자가 직접 악성 명령을 복사·실행하게 만드는 ClickFix 계열 초기침투 기법임
최종 목적은 정상 터널링 서비스를 악용한 리버스 터널 백도어로, 아웃바운드 연결만 쓰기 때문에 방화벽 인바운드 정책을 그대로 우회함
방어 지점은 페이로드가 아니라 실행 경로에 있음 — RunMRU 레지스트리, explorer.exe의 자식 프로세스, 터널 도메인 아웃바운드가 핵심 탐지 포인트임

왜 하필 CAPTCHA 화면일까요

이 수법이 무서운 건 기술적으로 정교해서가 아닙니다. 오히려 반대예요. 익스플로잇도, 취약점도 필요 없습니다. 사용자가 스스로 관리자 없이도 실행 가능한 명령을 자기 손으로 붙여넣기 때문이죠. 첨부파일 실행이나 매크로 허용은 요즘 사람들이 꽤 경계하는데, "인증 절차"라는 포장은 아직 의심의 문턱이 낮습니다. 게다가 진짜 Cloudflare 인증 화면을 하루에도 몇 번씩 보는 게 요즘 웹이잖아요. 학습된 습관을 그대로 무기로 쓴 겁니다.

흐름 자체는 이렇게 요약됩니다.

침해된 정상 사이트나 광고·검색 결과를 통해 가짜 인증 페이지로 유도함
페이지의 스크립트가 사용자 몰래 클립보드에 명령 문자열을 심어둠. 화면에 보이는 안내문과 실제 클립보드 내용은 다를 수 있음
사용자가 실행창에 붙여넣으면 스크립트 호스트나 셸이 외부에서 후속 단계를 내려받아 실행함
최종 단계에서 원격 접근 채널이 열리고, 서비스·예약 작업 등으로 지속성을 확보함

여기서 페이로드 자체를 파고드는 건 방어에 큰 도움이 안 됩니다. 문자열은 캠페인마다 바뀌지만, "사람의 손을 빌린다"는 구조는 안 바뀌거든요.

리버스 터널이 골치 아픈 이유

백도어라고 하면 보통 "공격자가 우리 쪽으로 들어온다"는 그림을 떠올리는데, 리버스 터널은 방향이 반대입니다. 감염된 단말이 밖으로 443 포트 연결을 하나 열고, 그 연결 위에 원격 셸이나 RDP 세션을 얹어요. 경계 방화벽 입장에서는 그냥 사용자가 HTTPS 사이트에 접속한 것과 구분이 잘 안 갑니다. NAT 뒤에 있든 인바운드가 전부 막혀 있든 상관이 없죠.

더 얄미운 건 이런 터널이 대체로 정상 서비스나 오픈소스 도구를 그대로 가져다 쓴다는 점입니다. 개발자들이 로컬 서버를 외부에 잠깐 노출할 때 쓰는 그 도구들이요. 서명도 멀쩡하고, 평판 기반 탐지에도 안 걸리고, 심지어 사내 개발팀이 정말로 쓰고 있을 수도 있습니다. 그러니까 "이 바이너리가 있으면 악성"이라는 판단이 안 통해요. 봐야 하는 건 누가, 어떤 부모 프로세스 아래에서, 어떤 인자로 띄웠는가입니다.

탐지: 어디를 봐야 할까요

개인적으로는 이 계열을 잡을 때 페이로드보다 실행 흔적부터 훑는 걸 추천해요. 순서대로 정리하면 이렇습니다.

RunMRU 레지스트리: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU에 실행창 입력 이력이 남음. 여기에 셸·스크립트 호스트 문자열이 박혀 있으면 사실상 확정적인 증거임
부모-자식 관계: explorer.exe가 부모인 powershell.exe, mshta.exe, cmd.exe, curl.exe 생성 이벤트. 정상 업무에서 이 조합이 나올 일은 많지 않음
인코딩된 명령줄: base64·문자열 결합·비정상적으로 긴 인자. PowerShell ScriptBlock 로깅(4104)이 켜져 있어야 보임
아웃바운드 터널 도메인: 프록시·DNS 로그에서 임시 터널 도메인, 무료 터널 서비스 서브도메인으로 향하는 장시간 유지되는 세션. 세션 지속 시간과 업/다운 비대칭이 좋은 지표임
지속성 흔적: 최근 생성된 서비스, 예약 작업, Run 키, 시작 폴더 항목

완화: 실행 경로를 먼저 끊읍시다

탐지도 중요하지만, 이 기법은 특이하게도 사전 차단이 꽤 잘 먹히는 편입니다. 사용자 손을 반드시 거쳐야 하는 구조라서 그 손을 막으면 체인이 끊기거든요.

일반 사용자 그룹에 한해 그룹 정책으로 실행창(Win+R) 사용을 제한하는 방안 검토
mshta.exe, wscript.exe 등 잘 안 쓰는 스크립트 호스트를 애플리케이션 제어(WDAC·AppLocker)로 차단
PowerShell 제한된 언어 모드 적용 + 스크립트 블록 로깅 상시 활성화
EDR의 공격 표면 축소 규칙 중 "Office/스크립트가 생성한 자식 프로세스 차단" 계열 활성화
업무상 필요 없는 터널링 서비스 도메인은 프록시에서 카테고리 단위로 차단
사용자 교육 한 줄: 정상적인 CAPTCHA는 절대 명령어를 복사해 붙여넣으라고 하지 않음

마지막 항목을 제일 강조하고 싶어요. 기술적 통제는 예외 처리하다 보면 구멍이 생기는데, "인증하는데 왜 터미널을 켜?"라는 감각은 한 번 심어두면 꽤 오래갑니다. 실제로 이런 화면을 캡처해서 사내 공지에 그대로 붙여두는 게 장문의 보안 수칙보다 효과가 좋았던 경우가 많았습니다.

이미 눌러버렸다면

만약 누군가 이미 실행했다고 신고해 왔다면, 순서는 이렇습니다. 먼저 네트워크에서 격리하고, 그다음에 종료하세요. 급한 마음에 전원부터 내리면 메모리에만 있던 흔적이 날아갑니다. 이후 RunMRU와 프로세스 생성 로그로 실행 시각을 특정하고, 그 시각 이후의 아웃바운드 세션을 역추적하면 터널 목적지가 나올 가능성이 높습니다. 그리고 해당 단말에 저장돼 있던 자격증명은 전부 유출된 것으로 간주하고 재발급하는 게 안전합니다. 리버스 터널이 열려 있던 시간이 짧아도, 브라우저 저장 비밀번호와 토큰을 긁어가는 데는 몇 분이면 충분하니까요.

가짜 CAPTCHA는 앞으로도 계속 모습을 바꿔가며 나올 것 같습니다. 인증 화면이라는 포장지가 워낙 효율이 좋으니까요. 그래도 우리가 볼 지점은 크게 안 변합니다. 실행창 흔적, 이상한 부모-자식 관계, 그리고 밖으로 나가는 조용한 터널. 이 세 가지만 대시보드에 올려두어도 절반은 막을 수 있다고 봅니다. 여러분 조직에서는 어떤 지표로 잡고 계신지, 댓글로 공유해 주시면 저도 배우겠습니다. 같이 다듬어 보아요!

워드프레스를 무너뜨린 건 코어가 아니라 플러그인 다섯 개였다

Sun, 30 Aug 2026 13:02:05 +0900

이미지 출처: The Hacker News

워드프레스 코어는 생각보다 단단하다. 보안팀도 있고, 자동 업데이트도 기본으로 돌고, 심각한 결함이 나오면 며칠 안에 패치가 배포된다. 그런데도 매달 "사이트가 통째로 넘어갔다"는 사고가 끊이지 않는 이유는 단순하다. 실제로 뚫리는 건 코어가 아니라 그 위에 얹은 플러그인과 테마이기 때문. 이번에도 플러그인·테마 다섯 곳에서 사이트 탈취나 원격 코드 실행으로 이어지는 결함이 한꺼번에 공개됐고, 하나같이 "인증 없이" 또는 "구독자 권한만으로" 시작할 수 있는 유형이었음.

핵심 요약

워드프레스 사고의 대부분은 코어가 아니라 서드파티 플러그인·테마의 권한 검사 누락에서 출발함
파일 업로드 검증 부재, 임의 옵션 변경, 파일 포함(LFI) 세 갈래가 결국 웹셸과 관리자 계정 생성으로 수렴함
방어는 패치가 1순위, 그다음이 uploads 디렉터리 PHP 실행 차단과 옵션·계정 변경 탐지

다섯 개의 결함이 공유하는 한 가지 패턴

제품 이름과 CVE 번호는 다르지만, 이런 류의 취약점은 놀랄 만큼 비슷한 자리에서 반복됨. 신뢰 경계를 잘못 그은 것.

권한 검사 누락 — 개발자가 nonce만 확인하고 끝내는 경우가 정말 많음. nonce는 CSRF 방어 수단이지 권한 검사가 아님. current_user_can()이 빠진 AJAX 핸들러 하나가 로그인만 하면 누구나 쓸 수 있는 관리 기능이 되어버림.
업로드 확장자 검증 부재 — 이미지 업로더인데 MIME 타입만 보거나, 아예 확장자 화이트리스트가 없는 경우. 웹셸 한 장이면 끝남.
임의 옵션 업데이트 — 얼핏 사소해 보이지만 가장 무서운 축. 공격자가 users_can_register를 켜고 default_role을 administrator로 바꾼 뒤, 회원가입 폼으로 관리자를 하나 만들어 들어옴. 파일 업로드 없이도 사이트가 넘어감.
파일 포함(LFI) — 템플릿 경로나 뷰 이름을 사용자 입력으로 받는 구조. 업로드 가능한 지점과 결합되면 곧바로 RCE가 됨.
인증 우회 — 사용자 ID나 이메일만 받아서 wp_set_auth_cookie()를 호출하는 소셜 로그인·원클릭 로그인 계열의 고전적 실수. 비밀번호를 몰라도 1번 계정으로 로그인됨.

왜 '사이트 탈취'와 'RCE'가 사실상 같은 말인가

워드프레스에서는 관리자 권한 획득과 코드 실행 사이의 거리가 굉장히 짧음. 관리자는 기본적으로 플러그인·테마 편집기를 쓸 수 있고, 플러그인 zip을 업로드해 설치할 수 있음. 즉 관리자 계정 하나 = 서버에서 PHP 임의 실행이라고 봐야 함. 그래서 "권한 상승 취약점"이라는 표현을 보고 방심하면 안 됨. 실제 결과는 웹셸이고, 그다음은 데이터베이스 덤프, 악성 리다이렉트 삽입, 스팸 페이지 대량 생성, 심하면 같은 호스팅 계정의 다른 사이트까지 번짐.

탐지: 로그에서 무엇을 보아야 하나

패치 전에 이미 당했는지를 확인하려면 로그를 봐야 하는데, 볼 곳이 의외로 정해져 있음.

비인증 요청이 몰리는 엔드포인트 — /wp-admin/admin-ajax.php와 /wp-json/ 하위로 들어오는 POST 중 로그인 쿠키가 없는 요청. 특정 action= 값이 짧은 시간에 반복되면 거의 자동화 스캔임.
readme.txt 대량 조회 — 공격자는 먼저 /wp-content/plugins/*/readme.txt를 훑어 버전을 수집함. 404가 우수수 찍히는 패턴이 보이면 며칠 안에 실제 시도가 옴.
uploads 아래의 .php 파일 — 정상 운영 중이라면 wp-content/uploads에 PHP 파일이 생길 이유가 없음. 파일 무결성 모니터링을 걸고 이 한 가지만 감시해도 체감 효과가 큼.
wp_options 변경 — users_can_register, default_role, siteurl, home 네 값은 바뀌면 알림이 오게 해두는 걸 개인적으로 추천함.
신규 관리자 계정과 capabilities 변조 — 계정 목록만 보지 말고 wp_usermeta의 capabilities 값도 같이 봐야 함. 기존 구독자 계정의 권한만 슬쩍 올려두고 잠수하는 경우가 있음.

완화: 순서대로 하면 됨

패치가 1순위. 취약한 버전을 그대로 두고 나머지를 아무리 해도 시간벌기일 뿐. 사용 중인 플러그인 목록과 버전을 먼저 뽑고, 자동 업데이트를 켤 수 있는 것부터 켜기.
uploads 디렉터리 PHP 실행 차단. 웹서버 설정에서 해당 경로의 .php 처리를 막아두면, 업로드 취약점이 터져도 웹셸이 실행되지 않음. 가성비가 가장 좋은 조치.
wp-config.php에 DISALLOW_FILE_EDIT, 가능하면 DISALLOW_FILE_MODS. 관리자 계정을 뺏겨도 코드 실행까지 가는 길을 한 칸 늘려줌.
안 쓰는 플러그인·테마는 비활성화가 아니라 삭제. 비활성 상태여도 파일이 남아 있으면 직접 호출로 취약 코드가 실행되는 경우가 있음. 기본 테마 하나만 남기고 정리하기.
WAF·가상 패치는 보조 수단. 패치까지 며칠이 걸릴 때 버티는 용도로는 충분히 값어치를 하지만, 그걸 최종 대책으로 삼으면 안 됨.
관리자 2FA와 최소 권한. 편집만 하는 사람에게 administrator를 주지 않기. 사고 대부분이 여기서 규모가 커짐.

이미 당한 것 같다면

플러그인만 업데이트하고 넘어가는 건 가장 흔한 실수. 이미 웹셸이 올라갔다면 패치는 문을 잠그는 것일 뿐, 안에 들어와 있는 사람을 내보내지는 못함. 낯선 관리자 계정 제거, 전 계정 비밀번호와 인증 키(SALT) 재발급, uploads와 테마 디렉터리 전수 점검, 그리고 감염 이전 시점 백업과의 파일 비교까지 해야 정리가 끝남. 복구보다 어디로 들어왔는지를 먼저 특정해야 같은 일이 반복되지 않음.

워드프레스를 쓰다 보면 플러그인이 스무 개, 서른 개까지 늘어나는 게 순식간이고, 그중 몇 개는 이미 개발이 멈춘 물건인 경우가 많다. 이번 주말에 딱 10분만 내서 플러그인 목록을 열어보고, 마지막 업데이트가 1년 넘게 없는 것부터 지워보는 걸 권함. 그것만으로도 공격 표면이 눈에 띄게 줄어드니까요. 다들 사이트 한 번씩 점검해보아요!

사내 Git 서버 하나가 조직 전체의 실행 권한을 쥐고 있다면 — Gitea CVE-2026-60004

Sun, 30 Aug 2026 08:02:24 +0900

이미지 출처: CISA KEV

회사에서 GitHub 대신 Gitea를 쓰는 팀이 생각보다 많음. 가볍고, 바이너리 하나로 뜨고, 라이선스 부담도 없어서 스타트업이나 사내망 개발팀이 자체 호스팅으로 올려두는 경우가 흔함. 그런데 그 "가볍게 올려둔" 서버가 조직의 모든 소스코드와 CI 파이프라인의 출발점이라는 걸 잊기 쉬움. CVE-2026-60004는 그 지점을 정확히 찌르는 코드 인젝션 계열 취약점임.

핵심 요약

Gitea에서 보고된 코드 인젝션 취약점으로, 신뢰되지 않은 입력이 서버 측에서 실행 가능한 문맥으로 흘러 들어가는 구조가 문제의 핵심임
Git 서버는 소스코드·CI 러너·배포 자격증명이 한곳에 모이는 지점이라, 단일 취약점이 곧바로 공급망 침해로 번질 수 있음
대응은 최신 버전 업그레이드가 1순위이고, 그 전까지는 익명 가입 차단·러너 격리·프로세스 실행 로그 감시로 시간을 벌어야 함

1. 코드 인젝션이 Git 서버에서 유독 위험한 이유

코드 인젝션이라는 말 자체는 넓음. 사용자가 넣은 문자열이 어딘가에서 코드나 명령으로 해석되면 전부 여기에 들어감. 웹 애플리케이션이라면 대개 "그 웹 프로세스 권한까지" 로 피해가 끝나지만, Git 서버는 사정이 다름.

Git 서버 프로세스는 저장소 파일 시스템에 대한 광범위한 접근 권한을 가짐
웹훅·CI 러너 등록 토큰·배포 키·패키지 레지스트리 자격증명이 같은 인스턴스 안에 저장돼 있음
서버가 실행하는 훅 스크립트, 미러링, 아카이브 생성 같은 기능은 원래부터 외부 프로세스를 호출하는 구조임

즉 인젝션 한 방으로 "코드 한 줄 실행"에서 끝나지 않고, 저장소 내용 변조 → CI 러너가 그 코드를 받아 빌드 → 산출물이 운영 환경으로 배포되는 흐름이 자연스럽게 이어짐. 공급망 공격 시나리오에서 Git 서버가 늘 1순위 표적으로 꼽히는 이유가 이것임.

2. 이 취약점을 개념적으로 어떻게 이해할 것인가

구체적인 페이로드는 다루지 않지만, 구조는 이해해 둘 필요가 있음. Gitea 같은 서버에서 인젝션이 생기는 자리는 대체로 정해져 있음.

템플릿 렌더링 경로 — 저장소 설명, 이슈 본문, 릴리스 노트처럼 사용자가 자유롭게 넣는 문자열이 템플릿 엔진을 거칠 때
외부 명령 조립 구간 — 브랜치명·태그명·파일 경로가 그대로 셸이나 git 하위 명령의 인자로 이어붙여질 때
웹훅·마이그레이션 설정 — 사용자가 지정한 URL이나 인증 정보가 서버 내부에서 요청 문자열로 재조립될 때

공통점은 하나임. "사용자가 통제하는 문자열"과 "서버가 해석하는 구문"이 같은 버퍼 안에서 섞이는 순간 취약점이 생김. 방어 코드는 언제나 이 둘을 분리하는 방향으로 짜여야 함 — 이스케이프가 아니라 애초에 인자 배열로 넘기고, 템플릿에는 데이터만 넣고, 화이트리스트로 형식을 강제하는 식임.

3. 우리 조직이 노출돼 있는지 먼저 확인

패치 이야기를 하기 전에, 자산 파악이 먼저임. 의외로 "우리가 Gitea를 쓰고 있었나?" 하는 조직이 많음. 옛날에 누군가 테스트용으로 띄워놓고 그대로 방치된 인스턴스가 사고의 진원지가 되는 경우를 여러 번 봤음.

내부망 대역에서 3000번 포트 및 HTTP 응답의 Gitea 문자열, /api/v1/version 엔드포인트로 인스턴스와 버전을 식별
리버스 프록시 뒤에 숨어 있는 경우가 많으므로 nginx·Traefik 설정 파일에서 업스트림 목록을 함께 훑기
컨테이너 환경이라면 이미지 태그 기준으로 조회 — 다만 latest 태그로 몇 년째 고정돼 있는 인스턴스가 진짜 위험한 쪽임
인터넷에 노출된 인스턴스가 있는지, 외부 스캔 관점에서도 한 번 확인

4. 완화 조치 — 패치 전후로 나눠서

가장 확실한 답은 벤더가 공지한 수정 버전으로 올리는 것임. Gitea는 릴리스 주기가 빠른 편이고 보안 수정이 마이너 버전에 함께 실려 나오는 경우가 많으니, 릴리스 노트의 보안 항목을 확인하고 계획을 잡는 게 좋음. 다만 사내 Git 서버는 "지금 당장 재시작하면 개발팀 전체가 멈춘다"는 이유로 미뤄지기 쉬움. 그 사이를 메울 조치들이 있음.

익명 가입 차단 — DISABLE_REGISTRATION을 켜서 임의 계정 생성을 막음. 인증 후 공격이 필요한 취약점이라면 이것만으로도 공격면이 크게 줄어듦
인터넷 직접 노출 제거 — VPN이나 SSO 프록시 뒤로 넣기. Git 서버가 공개 IP에 그대로 떠 있을 이유는 거의 없음
CI 러너 분리 — 러너를 Git 서버와 같은 호스트에 두지 말 것. 러너 등록 토큰의 유효 범위도 저장소 단위로 좁히기
실행 권한 최소화 — Gitea 프로세스를 전용 계정으로 돌리고, 컨테이너라면 불필요한 셸·컴파일러를 뺀 이미지를 쓰기
웹훅 아웃바운드 제한 — 허용 호스트 목록을 설정해 내부망 임의 주소로의 요청을 막기(SSRF 연계 차단 효과도 있음)

5. 탐지 — 무엇을 로그로 볼 것인가

패치는 언젠가 되지만, "이미 당했는지"를 보는 건 별개 작업임. 코드 인젝션의 최종 목적은 결국 서버에서 뭔가를 실행하는 것이니, 탐지 포인트도 실행 흔적에 맞춰야 함.

프로세스 계보 감시 — Gitea 프로세스가 git 외의 자식 프로세스(sh, bash, curl, wget, 스크립트 인터프리터)를 띄우는 이벤트를 우선순위 높은 경보로 잡기. 정상 운영에서는 거의 발생하지 않는 패턴임
아웃바운드 연결 — Git 서버가 외부로 새로 여는 연결. 미러링·웹훅 대상 외의 목적지는 전부 조사 대상
저장소 훅 디렉터리 변경 — hooks/ 아래 파일의 생성·수정 시각을 파일 무결성 모니터링으로 감시. 지속성 확보에 자주 쓰이는 자리임
관리자 권한·토큰 발급 이벤트 — 새 액세스 토큰, 새 배포 키, 새 러너 등록. 특히 업무 시간 외 발생 건
비정상 요청 패턴 — 저장소 이름·브랜치명·설명 필드에 유난히 긴 문자열이나 구문 기호가 몰려 있는 요청. 리버스 프록시 액세스 로그에서 걸러내기 좋음

6. 사고가 의심될 때의 순서

실행 흔적이 잡혔다면 판단을 미루지 않는 게 좋음. Git 서버 침해는 시간이 지날수록 "어느 커밋부터 믿을 수 있는가"를 되짚기가 어려워짐.

서버를 즉시 폐기하지 말고 메모리와 디스크 이미지를 먼저 확보 — 인젝션 흔적은 로그보다 프로세스 메모리에 남는 경우가 많음
모든 액세스 토큰·배포 키·러너 등록 토큰·웹훅 시크릿을 일괄 폐기하고 재발급
의심 시점 이후의 커밋 서명과 해시를 별도 보관본과 대조. 서명 커밋 정책을 안 쓰고 있었다면 이번 기회에 도입 검토
해당 서버가 배포한 아티팩트 목록을 뽑아 재빌드 범위를 정하기

마무리

Git 서버 취약점 소식을 보면 "우리는 내부망이라 괜찮다"는 반응이 제일 먼저 나오는데, 개인적으로는 그 말이 가장 위험한 신호라고 생각함. 내부망에 있다는 건 곧 일단 뚫리면 아무도 안 보고 있다는 뜻이기도 하니 말임. 오히려 조용한 곳일수록 프로세스 계보 로그 하나 걸어두는 게 값어치가 큼.

오늘 할 일은 단순함. 우리 조직에 Gitea 인스턴스가 몇 개 떠 있는지 목록부터 뽑아보기. 그리고 그중 마지막으로 업데이트한 날짜를 확인해보기. 그 숫자가 예상보다 오래됐다면, 이 글의 4번과 5번을 순서대로 적용하면 됨. 각자 환경에서 걸어둔 탐지 룰이 있다면 댓글로 공유해 주세요. 같이 다듬어보아요!

CVE-2019-1068: SQL Server 내부 함수 처리가 무너지면 서비스 계정까지 간다

Sat, 29 Aug 2026 21:32:29 +0900

이미지 출처: CISA KEV

2019년 7월 패치 화요일은 실제로 악용되고 있던 윈도우 제로데이 두 건 때문에 시끄러웠다. 그 소란 속에서 조용히 목록 한 줄을 차지하고 지나간 것이 CVE-2019-1068, Microsoft SQL Server의 원격 코드 실행 취약점임. 제로데이가 아니었고 공개 익스플로잇도 돌지 않았으니 대부분의 조직이 "다음 정기 점검 때"로 미뤘고, 그렇게 미뤄진 DB 서버가 몇 년 뒤 내부 침투 단계에서 발목을 잡는 경우를 심심찮게 보게 됨.

핵심 요약

SQL Server가 내부 함수 처리를 잘못하는 지점에서 발생하는 원격 코드 실행 결함으로, 조작된 쿼리 하나가 SQL Server 데이터베이스 엔진 서비스 계정 권한의 코드 실행으로 이어짐
"인증된 사용자만 가능"이라는 조건은 안심의 근거가 못 됨. 웹 애플리케이션의 SQL 인젝션이 그 인증을 대신 제공해 주기 때문임
방어의 핵심은 패치 + 서비스 계정 최소권한 + sqlservr.exe의 자식 프로세스 감시. 이 셋이 갖춰지면 미패치 상태에서도 피해 반경이 크게 줄어듦

결함의 성격: 데이터가 아니라 코드가 넘어간다

공개된 설명은 짧음. SQL Server가 내부 함수(internal function) 처리 과정을 올바르게 다루지 못할 때 발생하며, 공격자가 영향받는 인스턴스에 특수하게 조작된 쿼리를 제출하면 코드 실행이 가능하다는 것. 짧은 문장이지만 방어자 입장에서 뜯어볼 지점이 세 개 있음.

진입점이 '쿼리'임 — 별도 프로토콜 취약점이나 파일 업로드가 필요 없음. DB가 평소에 정상적으로 받아들이는 입력 경로 그대로 들어옴. 즉 네트워크 계층의 시그니처 탐지로 걸러내기가 대단히 어려움.
실행 컨텍스트가 서비스 계정임 — SQL 로그인 권한이 아니라 sqlservr.exe를 구동하는 OS 계정 권한으로 코드가 돌아감. 여기서 조직 간 피해 격차가 극단적으로 벌어짐.
인증이 선행 조건임 — 익명 공격은 불가. 다만 이 조건이 실무에서 얼마나 헐거운지는 아래에서 따로 다룸.

영향 범위는 2014부터 2017까지의 지원 버전대에 걸쳐 있었고, 서비스 팩과 누적 업데이트 라인별로 각각 수정본이 배포됨. 자기 인스턴스가 해당하는지는 SELECT @@VERSION으로 빌드 번호를 뽑아 해당 라인의 수정 빌드와 비교하는 게 가장 확실함.

"인증된 계정이 있어야 하잖아요"라는 말의 함정

이 CVE를 보고받으면 열에 아홉은 이렇게 반응함. 내부망이고, 로그인 계정도 앱 서비스 계정 하나뿐이고, 그 계정 비밀번호는 안전하다는 논리. 과연 그럴까?

SQL 인젝션이 곧 인증 우회임. 취약한 웹 애플리케이션은 이미 인증된 세션으로 임의 쿼리를 실어 보내주는 대리인 역할을 함. 공격자는 DB 자격증명을 몰라도 됨. 이 구조에서 CVE-2019-1068은 "SQLi로 데이터 유출"을 "SQLi로 서버 장악"으로 승격시킴.
저권한 계정이면 충분함. public 수준의 읽기 전용 로그인도 쿼리는 던질 수 있음. 권한 분리를 잘해 놨다는 사실이 이 결함 앞에서는 방어가 되지 않음.
내부망 전제도 위험함. 초기 침투에 성공한 공격자가 횡적 이동 중에 만나는 DB 서버는 대개 도메인 자산의 중심임. 서비스 계정이 도메인 계정이면 여기서 권한 상승 사슬이 시작됨.

탐지: 로그를 어디서 봐야 하는가

페이로드 자체를 잡는 건 현실적이지 않음. 대신 익스플로잇이 남기는 부수 효과를 노리는 게 훨씬 성공률이 높음. 개인적으로는 아래 순서대로 깔아두길 추천함.

프로세스 계보 감시(가장 가성비 좋음). Sysmon 이벤트 ID 1에서 부모 프로세스가 sqlservr.exe인 cmd.exe, powershell.exe, wmic.exe, rundll32.exe를 탐지 규칙으로 걸어둘 것. 정상 운영 환경에서 이 조합은 거의 발생하지 않으므로 오탐이 적고 신호가 선명함.
SQL Server ERRORLOG의 예외 흔적. 메모리 손상형 결함은 성공보다 실패가 많음. 액세스 위반(0xC0000005), 스택 덤프 생성, SqlDumpExceptionHandler 기록, 예기치 않은 엔진 재시작이 짧은 간격으로 반복된다면 누군가 오프셋을 맞추고 있는 중일 가능성을 의심해야 함.
구성 변경 감사. sp_configure를 통한 xp_cmdshell, CLR, Ole Automation Procedures 활성화는 공격자가 발판을 굳히는 전형적인 다음 수순임. SQL Server Audit이나 확장 이벤트(Extended Events)로 반드시 남길 것.
세션 메타데이터의 이질감. sys.dm_exec_sessions의 program_name, host_name, 접속 IP를 평소 값과 대조해 보면 sqlcmd나 관리 도구 문자열이 애플리케이션 서버가 아닌 곳에서 튀어나오는 순간이 보임.
아웃바운드 트래픽. DB 서버는 원래 밖으로 나갈 일이 거의 없는 장비임. DB에서 인터넷으로 향하는 신규 연결은 그 자체로 조사 대상이 되어야 함.

완화: 패치 이전에 피해 반경부터 줄이기

패치가 1순위인 건 당연하지만, 24시간 무중단 DB는 재기동 일정을 잡는 데만 몇 주가 걸리기도 함. 그 기간을 버티는 방법이 필요함.

서비스 계정을 LocalSystem에서 내릴 것. 이 하나가 사고의 등급을 바꿈. 전용 저권한 도메인 계정이나 gMSA로 전환하고, 필요한 로컬 정책 권한만 최소로 부여함. 서비스 계정이 로컬 관리자가 아니면 RCE가 성공해도 공격자는 DB 프로세스 권한이라는 좁은 상자 안에 남게 됨.
애플리케이션 DB 계정에서 sysadmin·db_owner를 회수할 것. 취약점 자체를 막지는 못해도 이후 확장 저장 프로시저 활성화 같은 후속 동작을 차단함.
SQL 인젝션 점검을 병행할 것. 앞서 말했듯 이 CVE의 선행 조건을 실질적으로 공급하는 통로임. 파라미터 바인딩과 저장 프로시저 사용 여부를 코드 레벨에서 다시 확인하는 게 결국 가장 근본적인 대응임.
노출면 정리. 1433/TCP와 1434/UDP가 인터넷이나 사용자 대역에서 직접 닿는 구조라면 방화벽과 세그먼트부터 손봐야 함. DB는 애플리케이션 서버에서만 접근 가능해야 함.
지원 종료 버전 정리. 수정본이 나오지 않는 구버전이 남아 있다면 그건 완화가 아니라 이전 계획의 영역임.

마무리하며

CVE-2019-1068을 지금 다시 꺼내 보는 이유는 이 결함이 특별히 화려해서가 아님. 오히려 평범한 CVE 하나가 조직의 구조적 약점을 그대로 증폭시키는 방식을 보여주기 때문임. 서비스 계정을 편하다고 LocalSystem으로 둔 선택, 앱 계정에 넉넉하게 준 권한, 미뤄둔 SQLi 점검 — 이런 것들이 평소엔 아무 일도 일으키지 않다가 취약점 하나를 만나면 한꺼번에 청구서로 돌아옴.

오늘 당장 하실 수 있는 건 두 가지예요. 하나는 SELECT @@VERSION으로 빌드 확인하기, 다른 하나는 SQL Server 서비스가 어떤 계정으로 돌고 있는지 서비스 속성 창 열어보기. 둘 다 5분이면 끝나는데, 결과에 따라 다음에 할 일이 완전히 달라질 겁니다. 확인해 보시고 예상 밖의 계정이 나왔다면 댓글로 공유해 주세요. 비슷한 상황 정리해 본 경험이 있으니 같이 방법 찾아보아요!

NetScaler 앞단에 놓인 장비 한 대, 왜 매번 표적이 되는가

Sat, 29 Aug 2026 13:01:54 +0900

이미지 출처: CISA KEV

사내 네트워크 다이어그램을 펼쳐보면 인터넷과 내부망 사이 딱 한 칸에 놓여 있는 상자가 있음. VPN 게이트웨이이자 로드밸런서이자 인증 관문 역할을 겸하는 Citrix NetScaler ADC/Gateway가 대표적인데, 이 위치에 있다는 것 자체가 공격자에게는 최고의 가성비 표적이 된다는 뜻임. CVE-2026-8452는 바로 그 장비에서 메모리 버퍼 경계를 벗어난 연산이 가능하다는 내용으로 등록된 건임.

핵심 요약

CVE-2026-8452는 Citrix NetScaler ADC/Gateway의 메모리 버퍼 경계 처리 결함(CWE-119 계열)으로, 인터넷에 직접 노출되는 엣지 장비라는 점에서 위험도가 큼
이런 유형은 크래시·재부팅·세션 이상 같은 흔적을 남기므로, 로그와 코어덤프 수집 체계를 먼저 갖춰두는 것이 탐지의 출발점임
패치가 최우선이며, 패치 이후에도 세션·토큰 무효화와 침해 흔적 점검을 함께 해야 실질적 대응이 됨

1. '메모리 버퍼 경계 내 연산의 부적절한 제한'이 뭘 말하는가

취약점 분류명이 길어서 어렵게 들리지만 뜯어보면 단순함. 프로그램이 데이터를 담을 상자(버퍼)를 만들어두고, 그 상자 크기를 넘어서는 읽기나 쓰기를 막아야 하는데 그 검사가 부족하거나 아예 빠져 있는 상태를 말함. CWE-119로 묶이는 이 계열은 아래 형태들을 모두 포함함.

상자보다 큰 데이터를 밀어 넣는 오버플로우
상자 앞쪽 영역을 건드리는 언더플로우
정해진 범위 밖을 읽어 메모리 내용을 흘려보내는 Out-of-Bounds Read

네트워크 장비에서 이게 왜 특히 위험하냐면, 경계를 넘어선 그 몇 바이트가 인접 메모리에 있던 세션 토큰이나 인증 정보를 덮어쓰거나 밖으로 흘려보낼 수 있기 때문임. 과거 NetScaler 계열에서 보고된 사례들을 보면, 단순히 장비가 죽는 데서 끝나지 않고 유효한 세션을 가로채 인증을 통째로 우회하는 경로로 이어진 경우가 여러 번 있었음. 즉 '메모리 오류'라는 표현이 주는 인상보다 실제 파급은 훨씬 큼.

2. 엣지 장비라는 위치가 만드는 특수성

일반 서버 취약점과 엣지 장비 취약점의 결정적 차이는 공격자가 사전 인증 없이 도달할 수 있느냐임. NetScaler Gateway의 로그인 페이지나 VPN 접속 엔드포인트는 정의상 외부에서 접근 가능해야 하는 표면임. 방화벽으로 가릴 수도 없고, 접근을 막으면 서비스 자체가 안 됨.

여기에 더해 이런 장비는 관리자가 내부를 들여다보기 어렵다는 문제가 겹침. EDR 에이전트를 설치할 수 없는 어플라이언스가 대부분이고, 셸 접근도 제한적이며, 로그 포맷도 일반 서버와 다름. 공격자 입장에서는 가장 잘 보이면서 가장 감시가 느슨한 지점인 셈임. 랜섬웨어 그룹들이 몇 년째 엣지 장비 취약점을 초기 침투 경로 1순위로 삼는 이유가 여기 있음.

3. 방어자가 먼저 할 일 — 자산 파악

대응 문서를 보면 대개 "즉시 패치하세요"로 시작하는데, 현장에서 진짜 발목을 잡는 건 우리가 그 장비를 몇 대나 쓰는지 모른다는 사실임. 인수한 계열사가 따로 운영하던 장비, 테스트용으로 올려두고 잊은 인스턴스, 클라우드 마켓플레이스에서 띄운 이미지까지 포함하면 목록이 생각보다 늘어남.

외부 노출 IP 대역에서 관리 포트와 게이트웨이 포트가 열린 호스트를 전수 조사함
HTTP 응답 헤더나 로그인 페이지 특성으로 NetScaler 계열 여부와 대략적 빌드를 식별함
관리 인터페이스(NSIP)가 인터넷에서 보이는 장비가 있다면 그것부터 즉시 차단 대상으로 분류함

개인적으로는 이 자산 목록을 취약점이 터진 다음에 만들지 말고, 평시에 분기 단위로 갱신해두는 걸 추천함. 급할 때 만든 목록은 항상 몇 대씩 빠져 있음.

4. 탐지 — 메모리 손상은 조용하지 않음

메모리 경계 침범 시도는 성공보다 실패가 훨씬 많음. 익스플로잇이 안정화되기 전 단계에서는 프로세스가 죽거나 장비가 재시작되는데, 이게 방어자에게 주어지는 신호임.

비정상 재시작·코어덤프 발생: 평소 없던 프로세스 크래시가 반복되면 단순 장애로 넘기지 말고 시각과 직전 요청을 대조함
비정상 길이의 요청: 특정 파라미터나 헤더가 유별나게 긴 요청, 혹은 인코딩이 뒤섞인 요청이 짧은 시간에 몰리는 패턴
인증 없는 세션의 등장: 로그인 기록 없이 유효한 세션이 활동하거나, 지리적으로 말이 안 되는 위치에서 기존 세션이 재사용되는 경우
설정 변경 이력: 관리자 계정 추가, 새 SSH 키 등록, 스크립트성 파일 생성 시각이 근무 시간과 어긋나는지 확인함

중요한 건 이 로그들이 장비 밖에 남아 있어야 한다는 점임. 침해가 확인된 어플라이언스는 초기화하거나 교체하게 되는데, 그 순간 장비 내부 로그는 같이 사라짐. syslog를 외부 수집기로 상시 전송해두지 않았다면 사고 후 조사할 재료 자체가 없음.

5. 완화 — 패치 전후로 나눠 생각하기

패치 적용이 1순위인 건 변함없지만, 엣지 장비는 재부팅이 곧 서비스 중단이라 즉시 적용이 어려운 경우가 많음. 그래서 시간대를 잡는 동안 버틸 조치가 필요함.

관리 인터페이스는 외부 노출을 끊고 관리 전용 대역이나 점프 호스트에서만 접근하도록 제한함
불필요하게 켜둔 가상 서버나 기능은 비활성화해 공격 표면 자체를 줄임
앞단 WAF나 리버스 프록시가 있다면 비정상적으로 긴 헤더·파라미터를 차단하는 규칙을 임시로 적용함
관리자 계정에 다중 인증을 걸고, 장비 자체 계정 목록에 낯선 항목이 없는지 대조함

그리고 놓치기 쉬운 부분인데, 패치했다고 끝이 아님. 취약점이 세션 데이터에 닿을 수 있는 유형이라면 패치 이전에 이미 탈취된 세션은 패치 후에도 그대로 살아 있음. 실제로 과거 사례에서 이 단계를 건너뛴 조직들이 "분명 패치했는데 다시 뚫렸다"는 상황을 겪었음. 그래서 패치 직후에는 아래를 같이 해야 함.

기존 ICA·PCoIP·웹 세션을 전부 강제 종료함
장비에 저장된 인증서와 관리자 자격증명을 교체함
패치 이전 기간 로그를 되짚어 계정 추가·파일 생성·비정상 접속 흔적을 확인함

6. 정리하며

엣지 장비 취약점을 볼 때마다 드는 생각인데, 결국 문제는 기술보다 운영 습관에 가까운 것 같음. 자산 목록이 최신인지, 로그가 장비 밖에 쌓이고 있는지, 패치 창을 잡는 절차가 미리 합의돼 있는지 — 이 세 가지가 준비된 조직은 새 CVE가 나와도 하루 이틀이면 정리가 되고, 안 된 조직은 한 달이 지나도 몇 대가 남아 있음.

CVE-2026-8452 같은 건이 나왔을 때 가장 먼저 열어봐야 할 건 익스플로잇 분석 글이 아니라 우리 자산 목록이라고 생각함. 혹시 NetScaler를 운영 중이라면 오늘 퇴근 전에 관리 인터페이스가 외부에서 보이는지만이라도 한 번 확인해보는 걸 추천함. 여러분 환경에서는 엣지 장비 로그를 어떻게 모으고 계신지, 괜찮은 방법 있으면 댓글로 공유해 주세요!

저장소 경로 한 칸을 벗어나면 — Artifactory가 걸러내지 못한 파일명

Fri, 28 Aug 2026 21:31:45 +0900

이미지 출처: CISA KEV

사내 빌드 파이프라인에서 아티팩트 저장소는 늘 조용한 존재입니다. 젠킨스가 돌고, 이미지가 올라가고, 개발자들은 npm install 한 줄로 그걸 내려받죠. 아무도 저장소 자체를 의심하지 않습니다. 그런데 그 저장소가 "파일을 어디에 저장할지"를 사용자가 준 문자열로 결정하고 있다면 어떨까요. CVE-2026-66384는 바로 그 지점, JFrog Artifactory가 경로 문자열을 지정된 디렉터리 안으로 제대로 가두지 못한 문제로 등록되어 있습니다.

핵심 요약

JFrog Artifactory에서 파일 경로가 지정된 저장소 디렉터리 밖으로 벗어날 수 있는 결함(경로 제한 미흡, CWE-22 계열)이 보고됨
아티팩트 저장소는 CI/CD의 상류에 있어, 임의 위치 쓰기·읽기가 성립하면 곧바로 공급망 오염으로 번짐
방어는 버전 업데이트가 우선이고, 그 전까지는 업로드 경로에 대한 로깅·역프록시 필터·저장소 권한 최소화로 시간을 벌 수 있음

이 취약점이 말하는 것

이름이 길어서 어렵게 보이지만 뜯어보면 단순함. "Improper Limitation of a Pathname to a Restricted Directory"는 흔히 경로 탐색(Path Traversal)이라 부르는 그 문제임. 프로그램이 기준 디렉터리를 정해두고 그 아래에만 파일을 두려 했는데, 입력으로 들어온 이름에 상위 디렉터리를 가리키는 조각이 섞여 있어 결과적으로 기준 밖으로 빠져나가는 상황.

Artifactory 맥락에서 특히 아픈 이유는 이 제품이 하는 일 자체가 "임의의 이름을 가진 파일을 받아서 디스크에 얹는 것"이기 때문임. 패키지 이름, 버전 문자열, 아카이브 내부 엔트리 이름까지 전부 외부에서 들어오는 데이터. 그중 어느 하나라도 정규화 전에 경로 조립에 쓰이면 저장 위치가 흔들림.

왜 아티팩트 저장소가 특히 위험한가

일반 웹 애플리케이션에서 경로 탐색이 터지면 설정 파일이 새는 정도로 끝나는 경우가 많습니다. 하지만 저장소는 위치가 다릅니다. 수백 대의 빌드 서버와 배포 대상이 이 한 곳을 신뢰하고 물건을 받아가는 구조거든요.

저장소가 관리하는 영역 밖에 파일이 놓이면, 애플리케이션 설정이나 기동 스크립트가 조용히 바뀔 수 있음
반대로 읽기 방향이면 저장소 내부 자격증명·라이선스·토큰 파일이 노출될 여지
무엇보다 다른 저장소(repo) 영역으로 넘어가는 경로가 성립하면, A 팀 권한으로 B 팀 아티팩트를 덮어쓰는 그림이 나옴

마지막 항목이 개인적으로는 제일 무섭다고 봅니다. 외부 인터넷에 노출되지 않았으니 괜찮다고들 하시는데, 이런 결함은 내부 사용자 한 명의 업로드 권한만으로도 경계를 넘게 만들거든요.

공격은 개념적으로 이렇게 성립함

재현 코드를 늘어놓을 이유는 없고, 원리만 정리하면 이렇게 됨.

공격자는 정상적으로 인증된 업로드 경로를 사용함. 여기까지는 감사 로그상 평범한 배포로 보임
파일명 또는 저장 대상 경로에 해당하는 필드에, 기준 디렉터리를 벗어나는 상대 경로 조각을 끼워넣음
서버가 그 문자열을 정규화(canonicalize)하지 않고 그대로 이어붙이면, 최종 저장 위치가 의도한 저장소 밖이 됨
변형으로는 URL 인코딩된 구분자, 이중 인코딩, 압축 파일 내부 엔트리 이름을 이용하는 방식이 알려져 있음

핵심은 "인증을 뚫는 문제가 아니다"라는 점. 이미 들어온 사용자가 자기 몫보다 넓은 범위를 만지게 되는 권한 경계의 문제임. 그래서 로그를 봐도 인증 실패가 안 찍힘.

어떻게 탐지할 것인가

이런 유형은 실패한 로그인처럼 눈에 띄는 신호를 남기지 않기 때문에, 볼 곳을 미리 정해두는 게 중요함.

요청 URI와 업로드 파일명에서 상위 경로 패턴을 찾음. 문자 그대로의 형태뿐 아니라 퍼센트 인코딩·이중 인코딩 변형까지 정규화한 뒤 매칭해야 함
Artifactory 접근 로그에서 PUT 계열 요청의 대상 경로가 저장소 이름 규칙을 벗어나는 케이스를 뽑아 봄. 정상 배포는 경로 형태가 대체로 일정하기 때문에 이탈이 드러남
파일시스템 쪽에서는 데이터 디렉터리 바깥에 Artifactory 프로세스 소유로 새 파일이 생기는지 감시. 무결성 모니터링(FIM) 규칙 한 줄이면 됨
배포되지 않은 시간대의 쓰기, 그리고 같은 계정이 평소 쓰지 않던 저장소 영역을 건드리는 패턴도 좋은 신호

완화는 이 순서로

순서를 뒤집지 않는 게 좋습니다. 우회 규칙부터 만들다가 정작 패치가 밀리는 경우를 여러 번 봤거든요.

벤더가 공지한 수정 버전으로 올리는 것이 1순위. 경로 정규화 결함은 필터링으로 완전히 막기 어려운 종류라서, 우회 규칙은 어디까지나 시간 벌기임
앞단 역프록시에서 경로 정규화 후 상위 참조가 남는 요청을 차단. 정규화 이전에 매칭하면 인코딩 변형에 그대로 뚫림
업로드 권한을 저장소 단위로 최소화. "배포용 계정 하나로 전부 올린다"는 구조는 이런 결함이 나올 때마다 피해 범위를 최대로 만듦
Artifactory 프로세스를 전용 계정으로 돌리고, 데이터 디렉터리 밖 쓰기 권한을 OS 차원에서 제거. 애플리케이션 버그가 파일시스템 경계까지 뚫지는 못하게 막는 이중 방어
관리 콘솔과 업로드 엔드포인트를 사내망·VPN 뒤로 두기. 노출 면적을 줄이는 건 언제 해도 손해가 아님

점검할 때 같이 보면 좋은 것들

익명 사용자(anonymous)의 읽기·쓰기 권한이 살아 있는지
더 이상 쓰지 않는 원격 저장소·프록시 설정이 남아 있는지
백업 파일과 시스템 export 산출물이 웹 경로에서 접근 가능한 위치에 있지는 않은지
배포 계정 토큰의 만료 정책과 회전 주기

정리하며

경로 탐색은 90년대부터 있던 문제인데도 여전히 매년 새 CVE로 올라옵니다. 문자열을 이어붙이는 코드가 계속 새로 쓰이는 한 사라지지 않을 것 같기도 하고요. 다만 이번처럼 공급망의 상류에 있는 제품에서 나오면 무게가 달라집니다. 내 서버 한 대의 문제가 아니라, 그 저장소에서 물건을 받아가는 모든 시스템의 문제가 되니까요.

오늘 저녁에 사내 Artifactory 버전 한 번 확인해 보시고, 접근 로그에서 업로드 경로 패턴만이라도 훑어보시는 걸 추천드립니다. 저도 이번 주에 저희 쪽 저장소 권한 정리를 다시 해볼 생각입니다. 같이 점검해보아요. 각자 환경에서 발견한 것들 있으면 댓글로 공유해주시면 좋겠습니다.

설명란이 비어 있는 커널 CVE를 만났을 때 방어자가 할 일

Fri, 28 Aug 2026 19:01:46 +0900

이미지 출처: CISA KEV

보안 담당자로 일하다 보면 참 애매한 순간이 있음. 취약점 관리 대시보드에 새 CVE가 뜨는데, 눌러 들어가 보면 요약란에 "Unspecified vulnerability"라고만 적혀 있고 그 아래가 텅 비어 있는 경우임. CVE-2026-53362 같은 리눅스 커널 항목이 딱 그런 부류인데, 제품이 커널이라는 것 말고는 손에 잡히는 게 거의 없다 보니 "그래서 이걸 어쩌라는 거지?" 싶어짐.

핵심 요약

정보가 비어 있는 커널 CVE는 "위험이 없다"가 아니라 "공개 정보가 아직 정리되지 않았다"는 뜻으로 읽어야 함
세부 내용을 기다리는 대신 커널 버전 인벤토리·패치 적용 경로·재부팅 창(window)을 먼저 정리하는 게 실질적 대응임
탐지는 익스플로잇 시그니처가 아니라 커널 크래시·권한 상승 흔적 같은 결과 기반 지표로 잡는 편이 현실적임

"Unspecified"가 실제로 뜻하는 것

CVE 항목에 설명이 비어 있는 데는 몇 가지 이유가 있음.

예약 후 대기 상태: CVE 번호는 먼저 할당되고, 상세 설명·영향 범위·CVSS 점수는 나중에 붙는 경우가 흔함. 특히 리눅스 커널은 자체 CNA가 되면서 커밋 단위로 CVE를 대량 발급하는데, 이 과정에서 사람이 읽을 만한 요약이 한참 뒤에 채워지거나 아예 짧게 끝나는 항목이 생김.
업스트림 커밋만 있고 서술이 없는 경우: 커널 쪽은 "이 커밋이 버그를 고쳤다"는 사실만 남고, 그 버그가 어떤 조건에서 어디까지 악용되는지는 아무도 공식적으로 정리해주지 않는 일이 많음.
분석 유보: 재분석 중이거나 참조 링크가 아직 반영되지 않아 비어 보이는 상태.

중요한 건 셋 중 어느 쪽이든 "영향이 없다"는 뜻은 아니라는 점임. 오히려 커널 취약점은 설명이 한 줄이어도 실제로는 로컬 권한 상승이나 커널 메모리 노출로 이어지는 경우가 적지 않음. 정보가 없다는 이유로 우선순위를 맨 뒤로 미루면, 나중에 상세 설명이 채워지는 날 갑자기 심각도만 올라간 채로 밀린 숙제가 되어 돌아옴.

커널 취약점이 실제로 굴러가는 방식 (개념 수준)

구체적인 코드 없이 흐름만 짚어보면, 커널 버그가 공격에 쓰이는 경로는 대체로 비슷함.

일반 사용자 권한으로 실행되는 프로세스가 시스템 콜이나 ioctl, 네트워크 프로토콜 파서 같은 커널 진입점을 두드림.
그 진입점에서 경계 검사 누락, 해제 후 사용(use-after-free), 경쟁 조건(race condition) 같은 결함이 건드려짐.
결과적으로 커널 메모리 구조가 공격자가 의도한 모양으로 바뀌고, 최종적으로는 권한 상승이나 정보 유출로 이어짐.

여기서 방어자에게 실용적인 통찰은, 커널 익스플로잇은 대부분 "이미 시스템 안에 발판이 있는 상태"에서 쓰인다는 것임. 웹 셸이든 탈취된 SSH 계정이든 컨테이너 내부든, 낮은 권한을 얻은 다음 root로 올라가는 마지막 계단 역할을 함. 그래서 커널 패치가 늦어질 때는 초기 침투 단계를 더 촘촘하게 막는 게 임시 방어선이 되어줌.

설명이 없어도 지금 할 수 있는 대응

개인적으로는 이런 CVE를 만나면 상세 정보를 기다리기보다 아래 순서로 움직이는 걸 추천함.

1. 커널 버전 인벤토리부터: 조직 안에 어떤 커널이 몇 대나 돌고 있는지 정확히 모르는 경우가 의외로 많음. uname -r 수집을 자산 관리에 붙여두면, 나중에 어떤 커널 CVE가 떠도 "우리 몇 대가 해당되는지"를 몇 분 만에 답할 수 있음. 이게 없으면 모든 커널 CVE가 매번 조사 프로젝트가 됨.
2. 배포판 보안 권고를 기준점으로: NVD 설명이 비어 있어도 우분투·데비안·레드햇·수세 같은 배포판 보안 트래커에는 해당 CVE의 패치 상태와 백포트 여부가 훨씬 빨리 정리되는 편임. 커널은 특히 "업스트림 버전 번호"보다 "내 배포판 패키지 버전"이 실질적인 판단 기준임.
3. 재부팅 창을 미리 확보: 커널 패치의 진짜 병목은 다운로드가 아니라 재부팅임. 라이브 패치(kpatch, kernel live patching 등)를 쓰더라도 모든 결함을 라이브로 덮을 수 있는 건 아니므로, 정기 재부팅 주기를 운영 절차에 넣어두는 게 결국 가장 확실함.
4. 완화 설정 점검: 커널 강화 옵션들은 익스플로잇 난이도를 눈에 띄게 올려줌. 비특권 사용자 네임스페이스 사용 제한, kernel.dmesg_restrict·kernel.kptr_restrict로 커널 주소 노출 줄이기, seccomp 프로파일로 컨테이너의 시스템 콜 표면 줄이기 같은 것들임. 이런 설정은 특정 CVE를 겨냥한 게 아니라 아직 이름 붙지 않은 커널 버그 전체에 대한 보험에 가까움.

탐지는 무엇을 봐야 하나

상세 정보가 없는 취약점은 익스플로잇 시그니처를 만들 수가 없음. 그래서 공격 자체가 아니라 공격이 남기는 결과를 보는 쪽으로 방향을 트는 게 맞음.

커널 로그의 이상 신호: dmesg나 journald에 갑자기 늘어난 커널 oops, general protection fault, BUG 메시지. 익스플로잇은 성공하기 전에 몇 번씩 시스템을 넘어뜨리는 일이 흔함.
권한 상승의 흔적: 일반 사용자 컨텍스트에서 시작된 프로세스가 갑자기 uid 0으로 동작하거나, 예상치 못한 부모-자식 프로세스 관계(예: 웹 서비스 계정에서 파생된 셸)가 생기는 경우.
컨테이너 경계 이탈 신호: 컨테이너 안에서 호스트 네임스페이스나 /proc, /sys의 민감한 경로에 접근하려는 시도. 커널은 컨테이너들이 공유하는 자원이라, 커널 취약점은 곧 컨테이너 격리의 약점이 됨.
커널 모듈 로딩 감시: 계획에 없던 모듈 적재는 그 자체로 조사 대상임. modules_disabled를 활용해 부팅 이후 모듈 적재를 잠그는 방식도 환경에 따라 고려할 만함.

정리하며

설명 없는 CVE는 사실 우리 실력을 시험하는 문제 같기도 함. 상세 분석이 친절하게 나와 있을 때는 누구나 대응할 수 있지만, 정보가 비어 있을 때 인벤토리·패치 경로·완화 설정·행위 기반 탐지라는 기본기로 버틸 수 있느냐가 진짜 차이를 만드는 것 같음. CVE-2026-53362처럼 손에 잡히는 게 없는 항목일수록, 특정 취약점을 쫓는 대신 커널 패치 파이프라인 자체를 점검하는 계기로 삼는 게 이득임.

혹시 여러분 조직에서는 커널 재부팅 주기를 어떻게 운영하고 계신지 궁금함. 라이브 패치를 쓰시는지, 아니면 정기 점검일을 잡아두시는지 댓글로 공유해주시면 저도 배우고 싶음. 같이 다듬어봐요!

서명은 맞는데 사용자는 아무나 — ownCloud WebDAV 서명 검증이 놓친 조건

Fri, 28 Aug 2026 13:02:13 +0900

이미지 출처: CISA KEV

2023년 11월 말, 파일 공유 서버를 운영하던 관리자들이 한 주 사이에 ownCloud 권고문 세 건을 연달아 받아야 했음. 그중 하나가 오늘 볼 CVE-2023-49105인데, 같은 시기 훨씬 유명해진 graphapi 정보노출(CVE-2023-49103)에 가려 상대적으로 조용히 지나간 감이 있음. 그런데 방어자 입장에서 보면 이쪽이 더 고약함. 설정 파일 하나 읽히는 게 아니라, 남의 계정 파일을 읽고 쓰고 지울 수 있는 문제였기 때문임.

핵심 요약

ownCloud core의 WebDAV 접근 경로에서, 서명된 URL 검증 로직이 "누가 요청했는가"를 충분히 묶어두지 못해 인증 없이 타인 파일에 접근 가능했던 문제임.
공격에 특별한 도구가 필요 없음 — 평범한 WebDAV 요청 형태라 IDS 시그니처보다 웹 접근 로그의 패턴으로 잡는 게 현실적임.
대응은 core 업데이트가 정답이고, 그 전까지는 서명 URL 기능 차단과 로그 소급 점검을 병행해야 함.

1. 무슨 일이 있었나

ownCloud는 설치형 파일 동기화·공유 플랫폼임. 웹 UI 뒤에서 실제 파일 입출력을 담당하는 건 대부분 WebDAV 엔드포인트고, 데스크톱 클라이언트나 모바일 앱도 결국 이 경로로 붙음. 문제는 이 WebDAV 경로에 붙어 있던 pre-signed URL 처리 로직이었음.

pre-signed URL은 원래 좋은 아이디어임. "이 사용자가, 이 파일을, 이 시각까지, 이 메서드로" 접근해도 된다는 걸 서버가 서명해두면, 매번 세션을 확인하지 않고도 접근 허용 여부를 판정할 수 있음. 클라우드 스토리지가 흔히 쓰는 방식이기도 함. 그런데 서명 검증이라는 게 "서명이 유효한가"와 "이 서명이 지금 이 요청에 해당하는가"는 완전히 다른 질문이고, 후자를 빠뜨리면 서명은 통행증이 아니라 만능키가 되어버림.

2. 취약점의 성격 — 개념 수준으로만

이 사안의 핵심은 요청에 담긴 사용자 식별자와, 서명을 만들 때 사용된 비밀값·대상 정보가 서로 단단히 결합돼 있지 않았다는 점임. 그래서 다음 조건이 겹치면 인증되지 않은 요청이 통과할 여지가 생김.

서명 검증에 쓰이는 비밀값이 예측 가능하거나, 사용자별로 분리되지 않은 상태일 것
URL에 들어간 사용자 지정 부분을 서버가 그대로 신뢰할 것
서명 대상 문자열에 요청 주체·유효기간 같은 결정적 요소가 빠져 있을 것

세 가지가 맞아떨어지면 공격자는 자신에게 정당하게 발급된 형태의 접근 정보를 기준 삼아, 대상만 바꿔치기한 요청을 만들어 볼 수 있음. 여기서 더 구체적인 요청 구성이나 서명 생성 절차를 적을 생각은 없음. 방어자가 알아야 할 건 "무엇을 만들면 뚫리는가"가 아니라 "뚫렸다면 로그에 무엇이 남는가"이기 때문임.

영향 범위도 짚고 갈 필요가 있음. 이 문제는 서명 URL 기능을 실제로 활성화해 쓰는 환경에서 의미가 있음. 즉 "우리도 ownCloud 쓰는데?" 하고 무작정 패닉할 일은 아니고, 설정을 먼저 확인하는 게 순서임. 다만 확인 전까지는 노출됐다고 가정하고 움직이는 편이 안전함.

3. 탐지 — 무엇을 어디서 볼 것인가

이 유형은 익스플로잇 트래픽이 정상 트래픽과 겉모습이 거의 같음. 그래서 페이로드 시그니처보다 맥락 이상을 봐야 함. 실무에서 먼저 열어볼 것들임.

웹서버 액세스 로그: /remote.php/dav/ 계열 경로에 대해, 세션 쿠키 없이 쿼리스트링에 서명 파라미터만 달고 들어온 요청. 정상 클라이언트는 대개 인증 헤더나 쿠키를 동반함.
User-Agent 이상: ownCloud 데스크톱/모바일 클라이언트 UA가 아닌 스크립트성 UA(curl, python-requests 등)가 DAV 경로에 반복 접근한 흔적.
계정-IP 조합: 특정 사용자 경로에 대한 접근이 그 사용자가 평소 쓰지 않던 IP·ASN·국가에서 발생했는지. 파일 공유 서버는 사용자별 접속 지점이 의외로 안정적이라 이 신호가 잘 먹힘.
메서드 분포: 짧은 시간에 PROPFIND가 몰린 뒤 GET이 이어지는 흐름. 목록을 훑고 원하는 파일을 골라 받아간 전형적 형태임.
ownCloud 자체 로그와 파일 활동 기록: 삭제·이동 이벤트가 해당 사용자의 웹 로그인 기록 없이 발생했다면 그 자체가 강한 신호임.

개인적으로는 리버스 프록시(nginx, Apache) 단의 로그를 SIEM으로 넘겨 "인증 흔적 없는 DAV 요청 중 200/207 응답을 받은 것"만 따로 뽑아보는 쿼리를 하나 만들어두길 추천함. 이 취약점뿐 아니라 이후에 나올 유사한 인증 우회에도 계속 재사용할 수 있는 자산이 됨.

4. 완화 — 순서대로

패치가 항상 첫 번째지만, 현실에서 파일 서버는 바로 못 내리는 경우가 많으니 단계로 정리함.

업데이트: ownCloud가 제공하는 core 보안 릴리스로 올림. 애드온이 아니라 core 쪽 수정이라 앱 비활성화만으로 끝나지 않음.
기능 차단: 즉시 패치가 어렵다면 서명 URL 관련 기능을 설정에서 끔. 기능을 실제로 쓰고 있는지부터 확인하고, 안 쓰고 있었다면 그대로 꺼둔 채 유지하는 게 낫음.
앞단 차단: 프록시나 WAF에서 인증 컨텍스트 없이 서명 파라미터만 달고 들어오는 DAV 요청을 임시로 거절. 정상 클라이언트 동작을 깨지 않는지 스테이징에서 먼저 확인해야 함.
노출면 축소: 관리 콘솔과 DAV 엔드포인트를 인터넷 전면에 열어둘 필요가 있는지 재검토. VPN 뒤로 넣거나 IP 허용목록을 거는 것만으로도 상당 부분이 정리됨.
사후 점검: 패치했다고 끝이 아님. 취약했던 기간의 로그를 소급해 위 탐지 항목으로 훑고, 이상 접근이 있었다면 해당 사용자 자격증명 초기화와 공유 링크 회수까지 이어가야 함.

5. 이 사건에서 남는 교훈

서명 기반 인가는 편하지만 조건이 까다로운 설계임. 서명 대상 문자열에 주체·대상·행위·만료가 전부 들어가야 하고, 비밀값은 충분히 예측 불가능해야 하며, 검증할 때 어느 하나라도 생략하면 그 즉시 무너짐. 이건 ownCloud만의 이야기가 아니고, 사내에서 직접 만든 다운로드 링크나 리포트 공유 기능에도 똑같이 적용되는 체크리스트임. 자체 개발한 서명 URL이 있다면 이번 기회에 한 번 열어보는 걸 권함.

그리고 하나 더. 같은 시기 ownCloud에서 나온 다른 취약점이 훨씬 크게 보도되면서, 관리자들이 그쪽만 처리하고 넘어간 사례가 적지 않았음. 권고문이 여러 건 나올 때는 뉴스에 많이 나온 것 하나가 아니라 목록 전체를 체크리스트로 만들어 하나씩 지워가는 습관이 필요함. 이런 게 쌓여서 나중에 큰 차이를 만드는 것 같다.

혹시 ownCloud를 운영 중이라면 오늘 로그 한 번 열어보시길. 위에 적은 쿼리 만드는 과정에서 막히는 부분 있으면 댓글로 남겨주세요, 같이 풀어보아요!

5.8에서 들어와 5.17에서 막힌 구멍: 리눅스 watch_queue OOB Write

Thu, 27 Aug 2026 21:32:55 +0900

이미지 출처: CISA KEV

리눅스 커널 5.8에 watch_queue라는 조용한 기능이 하나 들어왔음. 키링(keyring)이나 장치 상태가 바뀔 때 커널이 사용자 공간으로 알림을 밀어 넣어주는 통로인데, 일반 파이프를 특수한 플래그로 열어서 만드는 구조라 눈에 잘 띄지도 않았음. 그런데 이 통로에 붙는 필터 설정 코드가 같은 값을 두 번 검사하면서 기준을 서로 다르게 잡아버렸고, 그 어긋남이 2022년 3월 CVE-2022-0995로 정리됐음.

핵심 요약

리눅스 커널 watch_queue 알림 서브시스템의 필터 설정 경로에서 힙 경계 밖 쓰기(OOB Write)가 발생함. 로컬 일반 사용자가 root 권한 상승까지 노릴 수 있는 유형임.
원인은 "필터 개수를 세는 검사"와 "필터를 실제로 채우는 검사"가 서로 다른 상한을 쓴 것. 세는 쪽이 작게 세니 할당은 작게 되고, 쓰는 쪽은 그보다 많이 씀.
정답은 패치. 당장 못 올리면 CONFIG_WATCH_QUEUE 비활성화나 seccomp로 알림 파이프 생성 자체를 막고, pipe2 플래그와 'W' 계열 ioctl을 로깅해두면 탐지 신호가 꽤 선명함.

1. watch_queue가 하는 일

사용자 공간에서 pipe2()를 호출할 때 O_NOTIFICATION_PIPE 플래그를 주면 평범한 파이프가 아니라 알림 큐가 만들어짐. 그다음 이 fd에 ioctl을 걸어서 큐 크기를 정하고, 어떤 종류의 알림만 받을지 필터를 등록함. 특권이 필요 없음. 커널 옵션만 켜져 있으면 아무 일반 사용자나 이 경로를 그대로 탄다는 점이 이 취약점의 전제 조건이자 위험 요소였음.

2. 버그의 정체 — 같은 값, 다른 자

결과는 뻔함. 첫 루프에서 "이건 범위 밖이니 안 셀게"라고 건너뛴 항목을, 두 번째 루프는 "이 정도면 범위 안이네"라며 그대로 기록함. 할당된 배열은 작은데 쓰기 커서는 계속 전진하니 힙 경계 너머로 사용자가 고른 값이 새어나감. 덤으로 타입 비트맵을 세팅하는 비트 연산도 같이 범위를 벗어남. 개념적으로는 "세는 코드와 쓰는 코드가 서로 다른 자를 들고 있었다" 딱 그 한 줄임.

공격자 입장에서 좋은(=방어자 입장에서 나쁜) 점은, 넘어가는 값이 사용자가 상당 부분 제어 가능한 데이터라는 것. 커널 힙 할당자의 객체 배치를 다듬어 인접 슬랩에 의미 있는 구조체를 놓을 수만 있으면 단순 크래시에서 끝나지 않고 권한 상승 시나리오로 이어짐. 실제로 공개된 연구에서도 로컬 사용자가 root 셸을 얻는 데까지 도달했음. 자세한 익스플로잇 절차는 여기서 다루지 않겠음. 방어에 필요한 건 "이게 왜 터지는가"까지고, 그다음은 패치가 답이기 때문임.

3. 어디까지 영향이 가나

로컬 권한 상승이 핵심임. 원격 단독 공격은 아니지만, 웹셸이나 탈취된 서비스 계정 같은 발판이 이미 있는 상황에서 root로 올라서는 두 번째 단계로 딱 맞음.
컨테이너 안에서도 문제가 됨. 커널은 호스트와 공유하니, 컨테이너 내부 사용자가 커널 힙을 건드리면 격리 경계 자체가 흔들림.
단, CONFIG_WATCH_QUEUE가 켜진 커널에서만 성립함. 배포판마다 갈렸고, 이 옵션을 켜둔 데스크톱·서버 배포판이 주된 표적이 됐음.

4. 내 시스템은 해당되는가

커널 빌드 설정에서 grep WATCH_QUEUE /boot/config-$(uname -r)로 옵션이 y인지 확인. n이면 이 경로 자체가 없음.
배포판 커널이면 버전 숫자만 보고 판단하지 말 것. 백포트 패치가 들어가 있는 경우가 많아서, 배포사 보안 공지의 패키지 버전과 실제 설치본을 대조하는 게 정확함.
업스트림 기준으로는 5.17 계열에서 정리됐고, 그 이전 안정화 브랜치들로 수정이 내려갔음.

5. 탐지 — 무엇을 봐야 하나

이 취약점의 고마운 점은 정상 워크로드에서 거의 안 쓰이는 API를 지난다는 것임. 즉 신호 대비 잡음이 낮음.

알림 파이프 생성 감시: pipe2() 호출 중 O_NOTIFICATION_PIPE 플래그가 붙은 건을 audit이나 eBPF 기반 센서(Falco, Tetragon 등)로 잡음. 일반 애플리케이션에서 이 플래그가 뜨는 경우는 사실상 없다고 봐도 됨.
watch_queue 계열 ioctl: 큐 크기 설정과 필터 설정 ioctl은 'W' 매직 계열임. auditd의 syscall 인자 필터로 ioctl 명령 값을 좁혀 규칙을 걸어두면, 시도 자체가 로그에 남음.
실패의 흔적: 익스플로잇은 한 번에 성공하지 않음. 힙 그루밍이 어긋나면 dmesg에 slab 손상 경고, general protection fault, kernel oops가 남음. 커널 크래시 로그를 SIEM으로 안 보내고 있었다면 이번 기회에 파이프라인을 하나 붙여두길 개인적으로는 추천함.
사후 신호: setuid 바이너리 실행 없이 프로세스의 uid가 0으로 바뀌는 순간, 또는 컨테이너 프로세스가 호스트 네임스페이스 자원을 건드리는 순간. 커널 LPE 전반에 공통으로 쓰이는 탐지 축이라 이 CVE 하나 지나가도 계속 값어치를 함.

6. 완화 — 우선순위대로

패치가 1순위. 커널 업데이트 후 재부팅까지 해야 적용됨. livepatch를 쓴다면 해당 CVE가 패치 세트에 포함됐는지 확인이 필요함.
당장 재부팅 창을 못 잡는 서버라면 공격면 제거가 차선. 자체 빌드 커널을 쓴다면 CONFIG_WATCH_QUEUE를 끄는 게 가장 확실함. 이 기능을 실제로 쓰는 워크로드는 드묾.
seccomp 프로파일로 알림 파이프 생성 플래그와 해당 ioctl을 거부. 컨테이너 워크로드라면 기본 프로파일을 그대로 쓰지 말고 필요한 syscall만 남기는 방향으로 조여두는 게 이런 종류의 커널 버그 전체에 대한 보험이 됨.
커널 하드닝 옵션(슬랩 프리리스트 랜덤화·강화), kernel.dmesg_restrict=1, kernel.kptr_restrict=2 같은 설정은 익스플로잇 안정성을 떨어뜨리는 역할을 함. 근본 해결은 아니지만 공격자 비용을 올려줌.

마무리하며

이 사건에서 남는 교훈은 취약점 이름보다 패턴 쪽인 것 같음. "검증하는 루프"와 "사용하는 루프"가 분리돼 있으면 언젠가 두 기준이 어긋난다는 것. 커널이든 우리가 짜는 파서든 똑같이 적용되는 이야기라, 코드 리뷰할 때 "이 상한값, 아래쪽에서 또 계산하고 있지 않나?" 한 번만 되짚어보면 꽤 많은 걸 미리 잡을 수 있음.

오늘은 여기까지. 운영 중인 서버에 grep WATCH_QUEUE /boot/config-$(uname -r) 한 줄 돌려보는 것부터 시작해보시고, 커널 크래시 로그를 SIEM으로 보내고 계신 분들은 어떤 규칙으로 정리하셨는지 댓글로 공유해주시면 저도 배우겠음. 같이 조금씩 단단하게 만들어가요.

특권 헬퍼가 사용자 디렉터리를 믿을 때 생기는 일 (CVE-2015-5287, Red Hat ABRT)

Thu, 27 Aug 2026 19:02:36 +0900

이미지 출처: CISA KEV

2015년 가을, 레드햇 계열 서버를 돌리던 관리자들은 abrt 관련 보안 업데이트 공지를 한 번에 여러 건 받아야 했다. 그것도 원격 RCE가 아니라 전부 로컬 권한 상승이었다. "로컬이면 이미 들어온 거 아니냐"고 넘기기 쉬운데, 웹셸 하나로 www-data 권한만 잡은 공격자에게 로컬 루트 취약점은 사실상 게임의 후반부를 열어주는 열쇠라서 그렇게 가볍게 볼 물건이 아니었다. CVE-2015-5287은 그 묶음 중 하나다.

핵심 요약

ABRT(Automatic Bug Reporting Tool)는 크래시가 나면 자동으로 코어덤프와 진단 정보를 모아주는 도구인데, 그 수집 과정 일부가 높은 권한으로 동작함
CVE-2015-5287은 그 특권 동작이 일반 사용자가 손댈 수 있는 경로·파일을 충분히 의심하지 않아 로컬 사용자가 권한을 끌어올릴 수 있었던 사안임
방어는 패치가 1순위, 그다음이 심볼릭 링크 보호 커널 파라미터·코어덤프 정책 정리·abrt 관련 디렉터리 감사 규칙임

ABRT가 하는 일부터 짚고 가기

ABRT는 이름 그대로 "버그를 자동으로 신고해주는 도구"다. 프로세스가 죽으면 커널이 코어덤프를 넘겨주고, ABRT가 그걸 받아 크래시 정보를 정리해 스풀 디렉터리에 쌓아두고, 필요하면 디버그 심볼을 내려받거나 sosreport 같은 진단 자료까지 붙여 리포트를 만든다. RHEL·Fedora 계열에서는 기본으로 깔려 조용히 돌아가는 경우가 많다.

여기서 방어자가 눈여겨봐야 할 지점은 딱 하나임.

크래시를 일으키는 쪽은 아무 권한 없는 일반 사용자임
크래시를 처리하는 쪽은 root 혹은 그에 준하는 권한임
둘이 만나는 접점이 파일시스템 경로라는 것

권한이 낮은 쪽이 입력을 만들고 권한이 높은 쪽이 그걸 처리하는 구조는, 설계할 때 가장 조심해야 하는 형태인데도 "내부 도구니까 괜찮겠지" 하고 넘어가기 쉬운 곳이기도 하다.

문제의 구조 — 개념 수준으로만

CVE-2015-5287이 속한 abrt 계열 로컬 권한 상승들은 대체로 같은 뿌리를 공유함. 실행 가능한 재현 절차는 굳이 적지 않고, 어떤 조건이 겹치면 위험해지는지만 정리함.

예측 가능한 경로: 특권 프로세스가 /var/tmp나 스풀 하위처럼 일반 사용자도 이름을 미리 알 수 있는 위치에 파일·디렉터리를 만듦
검사와 사용 사이의 틈(TOCTOU): "이 경로가 안전한가" 확인한 시점과 실제로 열거나 쓰는 시점 사이에 아주 짧은 공백이 있고, 그 사이에 대상이 다른 것으로 바뀔 수 있음
심볼릭 링크·하드링크: 그 틈에 링크를 심어두면, 특권 프로세스가 원래 의도한 파일 대신 전혀 다른 시스템 파일을 향해 쓰기·소유권 변경을 수행하게 됨
소유권·권한의 애매한 인계: 사용자 소유로 만들어진 산출물을 나중에 root가 신뢰하고 다시 읽거나 실행 경로에 끼워 넣음

결과적으로 공격자는 자기 셸에서 프로그램 하나를 일부러 죽이는 정도의 평범한 행동으로 특권 처리 루틴을 발동시키고, 그 루틴의 손을 빌려 자기가 원하는 파일에 접근하게 만듦. 특별한 익스플로잇 코드보다 타이밍과 경로 조작이 본질인 유형임.

탐지 — 무엇을 로그로 남길 것인가

이 계열은 네트워크 IDS로는 거의 안 잡힘. 전부 호스트 안에서 벌어지는 일이라 파일시스템과 프로세스 관점의 관측이 필요함.

비정상적인 크래시 빈도: 이런 공격은 경쟁 조건을 이기려고 크래시를 수십, 수백 번 반복 유발하는 경우가 많음. 같은 사용자·같은 바이너리가 짧은 시간에 반복적으로 코어덤프를 남기면 그 자체가 신호임. abrt-cli list와 journald의 abrtd 로그를 함께 보면 패턴이 드러남
abrt 관련 디렉터리 감사: /var/spool/abrt, /var/tmp/abrt 하위의 생성·이름변경·삭제를 auditd 규칙으로 걸어두면 링크 심기 시도를 관측할 수 있음. 예: -w /var/spool/abrt -p wa -k abrt_watch
거부된 심볼릭 링크 추적: 커널의 링크 보호 기능이 켜져 있으면 차단 시 로그가 남음. 이 로그가 뜬다는 건 누군가 그 트릭을 쓰려 했다는 뜻이므로 단순 노이즈로 넘기지 말 것
이상한 위치의 root 소유 파일: 사용자 홈이나 임시 디렉터리에 root 소유 파일이 새로 생기는 것은 대표적인 사후 흔적임. 주기적으로 스캔해두면 좋음
SELinux denial: enforcing 상태라면 AVC 거부 로그가 공격 시도의 1차 증거가 되는 경우가 많음

완화 — 순서대로

패치가 1순위: 벤더 업데이트가 이미 나와 있는 사안임. abrt와 libreport 계열 패키지를 함께 올려야 함. 하나만 올리고 끝내면 다른 구성요소에 같은 구조가 남음
커널 링크 보호 활성화: fs.protected_symlinks=1, fs.protected_hardlinks=1을 sysctl에 박아둘 것. 이번 건뿐 아니라 같은 계열 취약점 상당수의 성공률을 크게 떨어뜨림
코어덤프 정책 정리: kernel.core_pattern이 어디로 파이프되고 있는지 확인하고, setuid 프로그램의 덤프를 허용할 이유가 없다면 fs.suid_dumpable=0을 유지할 것
필요 없으면 끄기: 다중 사용자 서버나 컨테이너 호스트에서 자동 버그 리포팅이 실제로 쓰이지 않는다면 abrt 서비스를 비활성화하거나 제거하는 편이 가장 확실함. 개인적으로는 사용자 계정이 여럿 붙는 서버라면 끄는 쪽을 추천함
마운트 옵션: /var/tmp, /tmp를 별도 파티션으로 두고 nosuid, nodev를 걸어두면 후속 단계의 선택지를 좁힐 수 있음

10년이 지나도 안 낡는 교훈

이 취약점이 지금도 읽을 가치가 있는 건, 똑같은 구조가 요즘 코드에도 계속 나오기 때문임. 백업 에이전트, 모니터링 데몬, 로그 수집기, 컨테이너 런타임 훅 — root로 돌면서 사용자 영역의 경로를 만지는 물건은 여전히 많음. 점검 질문은 세 개면 충분함.

이 특권 프로세스가 다루는 경로 중 낮은 권한 사용자가 만들거나 바꿀 수 있는 것이 있는가
경로를 검사한 뒤 실제로 여는 사이에 바뀔 수 있는 틈이 있는가 (디렉터리 핸들 기준의 *at 계열 호출을 쓰는가)
산출물의 소유권과 퍼미션을 누가 최종 결정하는가

사실 취약점 하나하나를 외우는 것보다 이 질문 세 개를 손에 익히는 게 훨씬 오래 갑니다. 오늘 여러분 서버에서 sysctl fs.protected_symlinks 한 줄만 쳐보시면 좋겠어요. 값이 0으로 나오면 그거 하나 바꾸는 데 1분도 안 걸리거든요. 혹시 운영 중인 환경에서 이런 특권 헬퍼 점검하다가 재미있는 걸 발견하셨다면 댓글로 공유해 주세요. 같이 보면서 배워보아요!

libuser가 /etc/passwd를 다시 쓰던 그 0.1초 (CVE-2015-3246)

Thu, 27 Aug 2026 13:02:14 +0900

이미지 출처: CISA KEV

2015년 여름에 공개된 리눅스 로컬 권한 상승 이슈 중 하나는 화려한 메모리 손상이 아니라 "파일을 어떻게 저장하느냐"에 관한 것이었음. 셸코드도, ROP 체인도 없이 그냥 사용자 계정 정보를 담은 텍스트 파일 하나가 쓰다 만 상태로 남는 것, 그게 전부였음. 그런데 그 파일이 하필 /etc/passwd였다는 게 문제였음.

핵심 요약

libuser는 /etc/passwd를 수정할 때 파일을 통째로 잘라내고 다시 쓰는 방식을 썼고, 그 중간에 프로세스가 죽으면 파일이 반 토막 난 채로 남았음
잘려나간 지점이 운 나쁘게(공격자 입장에선 운 좋게) 잡히면 루트 계정의 암호 필드가 비어버릴 수 있어 로컬 권한 상승으로 이어짐
방어는 패치가 1순위, 그 다음이 userhelper 같은 setuid 진입점 축소와 /etc/passwd 무결성 감시임

1. libuser는 무슨 물건인가

libuser는 레드햇 계열에서 사용자·그룹 계정을 다루는 공용 라이브러리임. 우리가 직접 부를 일은 거의 없지만, userhelper(consolehelper를 통해 일반 사용자가 chfn/chsh 같은 작업을 하도록 중개해 주는 setuid 프로그램)가 내부적으로 이 라이브러리를 씀. 즉 일반 계정이 "내 실명 정보 좀 바꿀게요" 하고 요청하면, 실제로 /etc/passwd를 손대는 주체는 루트 권한으로 돌아가는 libuser임.

여기서 신뢰 경계가 하나 생김. 입력은 일반 사용자, 쓰기 권한은 루트. 이런 구조는 언제나 조심스럽게 다뤄야 하는 자리임.

2. 문제의 본질 — 비원자적 쓰기

계정 파일을 안전하게 고치는 정석은 이런 흐름임.

임시 파일을 새로 만들고 거기에 전체 내용을 씀
제대로 다 써졌는지 확인하고 디스크에 반영함
마지막에 rename()으로 원본 자리에 갈아끼움

rename은 원자적이라, 중간에 뭐가 터져도 파일은 "예전 것" 아니면 "새 것" 둘 중 하나로만 존재함. 반쯤 쓰인 상태가 나올 수 없음.

그런데 libuser는 원본 파일을 열어서 truncate 후 처음부터 다시 쓰는 방식을 택했음. 이러면 쓰기가 진행되는 짧은 순간 동안 /etc/passwd는 물리적으로 불완전한 상태로 존재함. 평소엔 눈 깜짝할 사이라 아무도 신경 안 쓰지만, 공격자 입장에서 그 찰나는 노려볼 만한 창이 됨.

3. 창을 억지로 벌리는 방법 (개념 수준)

여기서 재밌는 건, 공격자가 굳이 정교한 타이밍 싸움을 할 필요가 없었다는 점임. 리소스 제한이라는 훨씬 얌전한 수단이 있었음.

자식 프로세스는 부모의 RLIMIT_FSIZE(파일 크기 상한)를 물려받음
이 상한을 아주 작게 걸어두고 userhelper를 실행하면, 루트 권한으로 /etc/passwd를 다시 쓰던 도중 상한에 걸려 프로세스가 그대로 종료됨
결과적으로 /etc/passwd는 지정한 크기에서 정확히 잘린 상태로 남음

즉 "언제 죽일까"가 아니라 "몇 바이트에서 자를까"의 문제로 바뀜. 경합 조건이지만 승률이 사실상 100%에 가까운 경합이었던 셈임. 여기에 같은 시기 공개된 짝꿍 이슈인 CVE-2015-3245(GECOS 필드에 개행 문자가 걸러지지 않던 문제)를 얹으면, 공격자는 자기 계정 정보 안에 원하는 형태의 줄을 미리 심어두고 절단 위치까지 조정할 수 있었음. 그렇게 해서 루트 항목의 암호 필드가 비어버리는 상태를 만들면, 그 다음은 설명이 필요 없음.

이 글에서는 여기까지만 개념적으로 정리함. 재현 스크립트는 다루지 않음. 중요한 건 절차가 아니라 "부분적으로 쓰인 설정 파일은 그 자체로 권한 상승 경로가 된다"는 사실임.

4. 방어자 관점 — 무엇을 봐야 하나

이미 오래전에 패치된 사안이지만, 탐지 관점은 지금도 그대로 재활용됨.

계정 파일 무결성 감시: AIDE나 유사 도구로 /etc/passwd, /etc/shadow, /etc/group의 해시 변화를 추적함. 정상적인 계정 생성과 달리, 공격 흔적은 보통 파일 크기가 갑자기 줄어드는 형태로 나타남
빈 암호 필드 점검: 두 번째 필드가 비어 있는 항목이 있는지 주기적으로 확인함. 특히 UID 0 계정은 무조건 봐야 함
auditd 규칙: /etc/passwd에 대한 write/truncate 이벤트를 감시하고, 어떤 실행 파일이 그 변경을 일으켰는지 함께 기록함. 정상 관리 작업(useradd, usermod)이 아닌 경로에서 변경이 발생하면 그게 신호임
setuid 프로그램 실행 로그: 일반 사용자가 userhelper 계열을 반복 호출하는 패턴은 흔한 일이 아님. 짧은 시간에 여러 번 실행되고 그때마다 계정 파일이 바뀌었다면 들여다볼 가치가 충분함
비정상 종료 흔적: 루트 권한 프로세스가 파일 크기 제한이나 시그널로 중도 종료된 기록은 그 자체로 이상 징후임

5. 완화 — 순서대로

패치가 먼저임. 배포판 벤더가 제공하는 libuser 및 관련 패키지 업데이트를 적용하면 근본 원인이 사라짐. 라이브러리 갱신이라 이미 떠 있는 프로세스 정리도 같이 챙겨야 함
불필요한 진입점을 줄임. 서버 용도의 시스템에서 일반 사용자가 chfn/chsh로 자기 정보를 바꿀 일이 거의 없다면, 해당 consolehelper 연동이나 setuid 비트를 정책에 맞게 정리하는 게 합리적임. 개인적으로는 데스크톱이 아닌 시스템에서 이런 setuid 중개 도구를 그대로 두는 걸 별로 좋아하지 않음
백업과 복구 경로를 준비함. /etc/passwd가 깨졌을 때 되돌릴 수 있는 스냅샷이 있으면 사고가 사건으로 번지지 않음. pwck 같은 검증 도구를 정기 점검에 넣어두는 것도 추천함
같은 패턴을 자체 코드에서도 찾아봄. 설정 파일을 직접 열어 truncate하고 다시 쓰는 코드가 사내 스크립트나 자체 데몬에 남아 있다면, 그건 libuser와 똑같은 실수임. 임시 파일 + rename 패턴으로 바꾸는 데 오래 걸리지 않음

6. 이 사건에서 챙길 것

취약점이라고 하면 보통 파싱 오류나 메모리 손상을 떠올리게 되는데, 이 건은 정상적인 코드가 중간에 멈췄을 때 남는 상태가 문제였음. 논리에 버그가 없어도, 실패 시나리오를 설계하지 않으면 그 자리가 공격면이 됨. 그리고 그 실패를 유발하는 수단이 꼭 대단할 필요도 없었음. 리눅스가 원래부터 제공하던 리소스 제한 기능 하나면 충분했음.

10년 전 이야기지만, "권한 있는 프로세스가 신뢰 경계 너머의 입력으로 중요한 파일을 다시 쓴다"는 구조는 지금도 사방에 있음. 내가 관리하는 시스템에도 그런 코드가 남아 있는지 한 번쯤 뒤져보면 좋겠음. 혹시 비슷한 패턴 발견한 적 있으면 댓글로 공유해 주세요. 같이 정리해 봐요.

JSON 한 조각에 타입 이름이 붙어 있을 때 — Ajax.NET Professional이 놓친 경계선

Thu, 27 Aug 2026 08:01:52 +0900

이미지 출처: CISA KEV

웹 애플리케이션에서 브라우저가 서버로 보내는 값은 기본적으로 "데이터"여야 함. 그런데 그 데이터 안에 "이걸 어떤 클래스로 만들어라"라는 지시가 섞여 들어갈 수 있다면, 그 순간부터 그건 데이터가 아니라 명령이 됨. CVE-2021-23758은 바로 그 경계선이 흐려졌을 때 무슨 일이 벌어지는지 보여주는 사례임.

핵심 요약

Ajax.NET Professional(AjaxPro)이 클라이언트가 보낸 JSON을 신뢰하지 않는 상태로 역직렬화하면서, 공격자가 지정한 타입까지 만들어지는 문제임.
핵심 위험은 원격 코드 실행으로, 인증이 필요 없는 AjaxPro 엔드포인트가 외부에 열려 있으면 위험도가 급격히 올라감.
방어는 세 가지 — 최신 버전 반영, AjaxPro 핸들러 경로 노출 통제, 그리고 요청 본문에 타입 지시자가 섞여 들어오는지 탐지하는 것.

AjaxPro가 하던 일

Ajax.NET Professional은 꽤 오래된 .NET 라이브러리임. AJAX라는 말이 유행하던 시절, 브라우저 자바스크립트에서 서버의 C# 메서드를 거의 직접 호출하는 것처럼 쓰게 해주는 게 목적이었음. 개발자는 메서드에 특성(attribute) 하나만 붙이면 되고, 나머지 배관 작업 — 요청을 받아서 파라미터를 파싱하고 실제 메서드에 넘겨주는 일 — 은 라이브러리가 알아서 해줬음.

편의성 자체는 훌륭했음. 문제는 그 "파라미터를 파싱하는" 단계에 있었음. C# 메서드의 인자는 문자열이나 숫자만 있는 게 아니라 임의의 객체일 수도 있음. 그래서 라이브러리는 들어온 JSON을 적당한 .NET 객체로 되살려내는 기능을 갖고 있어야 했고, 이때 어떤 타입으로 되살릴지를 요청 쪽 정보로 판단하는 구조가 만들어졌음. 여기서 신뢰 경계가 무너짐.

역직렬화가 위험해지는 지점

역직렬화 자체는 죄가 없음. 위험한 건 "바이트 뭉치를 객체로 되돌리는 과정에서 코드가 실행된다"는 특성임. .NET이든 자바든 파이썬이든, 객체를 복원할 때는 생성자·세터·콜백 같은 것들이 자동으로 돌아감. 공격자가 복원될 타입을 고를 수 있게 되면, 이야기는 이렇게 흘러감.

애플리케이션이 로드한 모든 어셈블리에서 "복원되는 순간 뭔가를 실행하는" 클래스를 뒤짐. 이런 걸 가젯(gadget)이라 부름.
그 가젯의 프로퍼티를 원하는 값으로 채운 JSON을 만들어 보냄.
서버가 그 JSON을 객체로 되살리는 순간, 개발자가 의도한 적 없는 코드 경로가 발동됨.

개념적으로만 짚자면 이게 전부임. 실제 가젯 체인은 프레임워크 버전과 로드된 어셈블리 구성에 따라 달라지므로 여기선 다루지 않음. 중요한 건 "공격자가 타입을 지정할 수 있는가"라는 질문 하나가 취약/안전을 가른다는 사실임.

내 환경에 이게 있는지부터

이 취약점이 까다로운 이유는 AjaxPro가 요즘 새로 도입되는 라이브러리가 아니라는 데 있음. 오래된 사내 시스템, 인수합병으로 넘어온 레거시 포털, 몇 년째 아무도 손대지 않는 관리자 화면 같은 곳에 조용히 박혀 있을 확률이 높음. 그래서 점검 순서는 이렇게 잡는 게 현실적임.

파일 흔적: 배포 디렉터리에서 AjaxPro 관련 DLL이 있는지 확인. bin 폴더를 뒤지는 게 가장 빠름.
설정 흔적: web.config의 httpHandlers 또는 handlers 섹션에 ajaxpro 경로가 등록되어 있는지 확인. 등록돼 있다면 그 경로가 곧 공격 표면임.
트래픽 흔적: 웹 서버 액세스 로그에서 /ajaxpro/ 형태의 경로가 찍히는지 검색. 개발자도 잊은 기능이 로그에는 남아 있는 경우가 많음.
참조 흔적: 소스가 있다면 프로젝트 파일과 패키지 목록에서 참조를 확인. 직접 넣은 게 아니라 다른 컴포넌트가 끌고 들어온 경우도 있음.

개인적으로는 세 번째 항목을 제일 먼저 해보는 걸 추천함. 자산 목록이 부정확한 조직일수록, 사람 기억보다 로그가 정직하기 때문임.

탐지 규칙을 어디에 걸 것인가

이 부류의 취약점은 "요청 본문 안에 타입 이름이 섞여 있다"는 아주 특징적인 신호를 남김. 정상적인 애플리케이션 데이터에는 .NET 타입의 정규화된 이름이나 어셈블리 정보가 들어갈 이유가 거의 없음. 그래서 탐지는 다음 축으로 세우면 됨.

본문 패턴: POST 본문에 __type, $type 같은 타입 지시 키나 System.으로 시작하는 정규화 타입 문자열, Assembly·Culture=·PublicKeyToken= 같은 어셈블리 식별 문자열이 섞여 들어오는 경우.
경로 결합: 위 패턴이 AjaxPro 핸들러 경로로 향하는 요청에서 발생하면 우선순위를 크게 올림. 경로와 본문을 함께 보는 게 오탐을 줄이는 핵심임.
후행 행위: w3wp.exe 같은 IIS 워커 프로세스가 cmd.exe나 powershell.exe를 자식으로 띄우는 순간. 역직렬화 공격의 성공 여부는 사실 이 지점에서 가장 확실하게 드러남.
나가는 연결: 웹 서버가 갑자기 외부로 아웃바운드 연결을 시도하는 패턴. 페이로드 다운로드나 리버스 셸의 전형적인 모습임.

앞의 두 축은 앞단(WAF·프록시)에서, 뒤의 두 축은 뒷단(EDR·프로세스 로그)에서 봐야 함. 한쪽만 걸어두면 우회 한 번에 그대로 뚫림.

실제로 막는 순서

순서를 정할 때는 "제일 빨리 위험을 떨어뜨리는 것"부터 가는 게 맞음.

1. 노출 차단: AjaxPro 핸들러 경로를 인터넷에서 접근 못 하게 막음. 내부 업무용 기능이라면 애초에 외부에 열려 있을 이유가 없음. 패치보다 이게 먼저 되는 경우가 많음.
2. 버전 정리: 이 문제를 해결한 릴리스로 올림. 라이브러리 교체가 곧바로 어렵다면 최소한 어떤 버전이 어디에 깔려 있는지 목록부터 만들어 둠.
3. 제거 검토: 솔직히 가장 확실한 해법임. AjaxPro가 담당하던 기능이 요즘 기준으로 보면 일반적인 REST 엔드포인트 몇 개로 대체 가능한 경우가 대부분이고, 그렇게 바꾸면 이 취약점 계열 전체가 사라짐.
4. 권한 축소: 애플리케이션 풀 계정 권한을 최소화. 코드 실행이 일어나더라도 그 다음 단계로 못 가게 막는 층임.
5. 로그 보존: 이미 당했는지 확인하려면 과거 로그가 필요함. 조치하기 전에 액세스 로그와 프로세스 로그 보존 기간부터 확인해두는 걸 권함.

이 사건이 남기는 것

역직렬화 취약점은 새로운 게 아님. 그런데도 계속 나오는 이유는, 개발할 때 "받은 데이터를 그대로 객체로 만들어주면 편하다"는 유혹이 워낙 강하기 때문인 것 같음. 편의 기능이 하나 늘어날 때마다 신뢰 경계가 한 칸씩 안쪽으로 밀려 들어오는데, 그게 밀려 들어온 자리에 코드 실행이 놓여 있으면 사고가 됨.

그래서 방어자 입장에서 기억할 원칙은 단순함. 입력이 타입을 고르게 하지 말 것. 서버가 기대하는 타입을 서버가 먼저 정해놓고, 들어온 데이터를 그 틀에 맞춰 검증하며 채우는 방향이어야 함. 요즘 라이브러리들이 타입 정보 포함 역직렬화를 기본으로 끄고, 켜려면 명시적으로 허용 목록을 요구하는 것도 같은 이유임.

혹시 사내에 AjaxPro가 남아 있는 걸 발견했다면, 그건 나쁜 소식이 아니라 좋은 소식이라고 생각함. 모르는 것보다 아는 게 언제나 나으니까. 오늘 bin 폴더 한 번, web.config 한 번만 열어보아요. 비슷한 레거시 라이브러리 정리하다 겪은 이야기 있으면 댓글로 나눠주면 좋겠습니다!

같은 메모리를 두 번 반납한 IKEEXT, CVE-2026-33824가 노린 지점

Wed, 26 Aug 2026 21:40:51 +0900

이미지 출처: CISA KEV

윈도우 서비스 목록을 아래로 훑다 보면 IKE and AuthIP IPsec Keying Modules라는 유난히 긴 이름이 지나간다. 이름은 거창한데 대부분의 관리자는 이 서비스를 켠 기억도, 쓴 기억도 없다. VPN도 안 쓰고 IPsec 정책도 없는 사무실 PC에서조차 이 녀석은 조용히 자동 시작 상태로 앉아 있음. 그 조용한 서비스에서 더블 프리(double free) 결함이 나왔다는 게 이번 CVE-2026-33824의 요지임.

핵심 요약

윈도우 IKE 서비스 확장(IKEEXT)에서 같은 힙 메모리를 두 번 해제하는 결함이 확인됨. 인증 이전 단계의 프로토콜 처리 경로가 문제 지점임.
IKE는 UDP 500·4500번에서 동작하며, 협상 초기 패킷은 신원 확인 전에 파싱되므로 노출 표면이 넓음.
방어의 핵심은 패치 적용, 두 포트의 인바운드 노출 차단, 그리고 IKEEXT 서비스 크래시·재시작 이벤트를 탐지 신호로 삼는 것임.

더블 프리가 왜 위험한 결함인가

메모리를 할당했다가 반납하는 건 지극히 평범한 동작임. 문제는 이미 반납한 블록을 한 번 더 반납할 때 생김. 힙 관리자는 해제된 블록들을 자유 목록(free list)으로 엮어 관리하는데, 같은 주소가 목록에 두 번 들어가면 자료구조의 일관성이 깨짐. 그다음 할당 요청이 들어오면 서로 다른 두 개의 코드 경로가 같은 메모리를 각자 자기 것인 줄 알고 쓰게 됨.

여기서부터가 공격자가 노리는 구간임. 한쪽이 문자열 버퍼로 쓰는 영역을 다른 쪽이 함수 포인터가 든 구조체로 해석하는 상황이 만들어지면, 값의 내용을 통제할 수 있는 쪽이 실행 흐름의 방향을 바꿀 여지가 생김. 개념적으로는 이 정도만 이해하면 충분하다고 봄. 실제로 이걸 안정적인 코드 실행까지 끌고 가려면 힙 배치를 원하는 모양으로 정렬하는 작업이 별도로 필요하고, 그건 이 글에서 다룰 영역이 아님.

하필 IKEEXT라서 신경 쓰이는 이유

취약점의 위험도는 결함 자체보다 그 코드에 누가 말을 걸 수 있느냐로 결정되는 경우가 많음. IKEEXT는 그 점에서 조건이 나쁨.

인증 이전에 파싱함 — IKE는 이름 그대로 키 교환 프로토콜임. 서로 신뢰할 근거를 만드는 게 목적이니, 협상 첫 패킷은 당연히 인증되지 않은 상대에게서 온 것임. 즉 결함이 있는 파서가 아무 자격 없는 발신자에게 열려 있음.
UDP 기반임 — TCP처럼 핸드셰이크를 완료할 필요가 없어 출발지 주소를 위조한 패킷 한 통으로 코드 경로를 건드릴 수 있음. 로그에 남은 IP를 그대로 믿기 어려운 이유도 여기 있음.
안 쓰는데 켜져 있음 — 앞서 말한 대로 IPsec을 전혀 쓰지 않는 시스템에서도 서비스가 살아 있는 경우가 흔함. 사용하지 않는 기능이 공격 표면으로 남아 있는 전형적인 사례임.
권한이 높음 — 이 서비스는 시스템 수준 컨텍스트에서 동작하므로, 성공적인 악용의 결과가 곧바로 상위 권한임.

우리 환경이 노출됐는지부터 확인하기

패치를 돌리기 전에 노출 범위를 아는 게 순서라고 봄. 순서대로 해보면 됨.

서비스 상태 확인 — Get-Service IKEEXT로 실행 여부를 봄. 자산 관리 도구가 있다면 조직 전체를 한 번에 뽑는 게 훨씬 빠름.
리스닝 포트 확인 — Get-NetUDPEndpoint -LocalPort 500,4500로 실제로 대기 중인지 봄. 서비스가 떠 있어도 정책이 없으면 소켓이 안 열리는 경우가 있어서 둘을 같이 봐야 함.
경계에서 확인 — 방화벽·클라우드 보안그룹 규칙에서 UDP 500과 4500이 외부로 열린 대상이 있는지 훑음. 예전에 VPN 테스트하다 열어두고 잊은 규칙이 이런 순간에 발목을 잡음.
정책 확인 — Get-NetIPsecRule이 비어 있다면 그 시스템은 IPsec을 사실상 안 쓰는 것임. 서비스를 유지할 이유가 없는 후보군임.

탐지: 무엇을 신호로 볼 것인가

메모리 손상 계열은 시그니처로 잡기 어렵지만, 실패의 흔적은 꽤 시끄럽게 남는 편임. 익스플로잇은 성공보다 실패가 압도적으로 많고, 실패는 곧 프로세스 종료로 나타남.

서비스 비정상 종료·자동 재시작 — 시스템 로그에서 서비스 제어 관리자가 남기는 종료/복구 이벤트(7031, 7034)를 IKEEXT 기준으로 걸어둠. 평소엔 거의 안 뜨는 이벤트라 오탐 부담이 적음.
WER 크래시 리포트 — 응용 프로그램 오류 및 Windows Error Reporting 항목에서 해당 서비스 호스트가 반복 등장하는지 봄. 힙 손상은 종종 STATUS_HEAP_CORRUPTION 계열 코드로 남음.
비정상 IKE 트래픽 패턴 — 짧은 시간에 다수의 협상 시작 패킷이 몰리거나, VPN 피어가 아닌 낯선 대역에서 500·4500번으로 유입되는 흐름. NetFlow만 있어도 잡히는 수준임.
사후 행위 탐지 — 서비스 호스트 프로세스가 갑자기 스크립트 해석기나 셸을 자식으로 띄우는 순간. 결국 공격자는 뭔가를 실행해야 하고, 그 지점이 EDR이 가장 자신 있어 하는 구간임.

완화: 순서를 정해서 처리하기

급한 순서대로 정리하면 이렇게 됨.

패치가 1순위임 — 더블 프리는 설정으로 우회할 수 있는 종류의 결함이 아님. 공급업체 수정이 정답이고 나머지는 시간을 버는 수단일 뿐임.
노출 축소 — 인터넷 경계에서 UDP 500·4500 인바운드를 차단하고, VPN 게이트웨이처럼 정말 필요한 장비만 예외로 남김. 내부에서도 IPsec을 쓰는 세그먼트로 출발지를 제한하면 표면이 크게 줄어듦.
안 쓰는 곳은 서비스 정지 — 개인적으로는 이 방법을 추천하는데, 조건이 붙음. IPsec 규칙이나 DirectAccess, L2TP 계열 VPN을 쓰는 환경에서 이걸 끄면 연결이 통째로 죽음. 반드시 소규모 그룹에 먼저 적용해보고 확대하는 게 안전함.
완화 기능 확인 — 익스플로잇 보호와 힙 무결성 관련 완화가 꺼져 있지 않은지 점검. 이런 완화들은 공격을 막아준다기보다 안정적인 악용을 어렵게 만들어 실패율을 올리고, 그 실패가 앞서 말한 탐지 신호가 됨.

정리하며

이번 건에서 개인적으로 가장 크게 남은 교훈은 결함의 종류가 아니라 "안 쓰는데 켜져 있는 것들" 쪽임. IKEEXT처럼 기본으로 살아 있는 서비스는 평소엔 존재감이 없다가, 이런 CVE가 나오는 날 한꺼번에 자산 전체가 대상이 됨. 취약점 하나 대응하는 것보다, 이참에 우리 시스템에서 아무도 쓰지 않는 서비스와 포트 목록을 한 번 정리해두는 게 훨씬 오래 가는 방어라고 봄.

오늘 당장은 세 줄만 해도 충분함. IKEEXT 실행 여부 확인, UDP 500·4500 외부 노출 점검, 그리고 서비스 크래시 이벤트에 알림 하나 걸어두기. 다들 자기 환경에서 한 번씩 돌려보고, 우리 쪽은 이렇게 나왔다는 결과 댓글로 공유해 주시면 저도 같이 배우겠음. 같이 해보아요!

"등록할 땐 공인 IP였는데요" — MLflow 웹훅이 남의 메타데이터를 대신 읽어준 사건

Tue, 25 Aug 2026 19:02:24 +0900

이미지 출처: CISA KEV

CVE 번호가 배정되고 몇 시간 만에 전 세계 허니팟 센서에 스캔이 잡혔다. 표적은 인터넷에 그대로 열려 있던 MLflow 트래킹 서버였고, 공격자들이 노린 건 모델도 실험 기록도 아니었음. 그 서버가 올라타 있는 클라우드 인스턴스의 임시 자격증명이었다.

핵심 요약

MLflow 웹훅 테스트 엔드포인트(POST /api/2.0/mlflow/webhooks/{id}/test)가 인증 없이 호출 가능하고, 등록 때 검증한 주소를 리다이렉트 이후 다시 확인하지 않아 전(全)내용 열람형 SSRF가 성립함. CVSS 9.3.
3.15.0 미만 전 버전이 영향권. 3.15.0은 검증된 주소를 연결 시점에 고정하는 방식으로 수정됨.
이미 실전 악용 중이며 KEV 목록에도 등재됨. 패치와 함께 아웃바운드 통제·IMDSv2 강제가 같이 가야 함.

1. 어디가 열렸나

MLflow에는 실험이나 모델 등록 같은 이벤트가 발생하면 외부 URL로 알림을 쏘는 웹훅 기능이 있음. 사용자가 URL을 등록하면 _validate_webhook_url이 그 주소를 검사해서 사설 대역이나 루프백으로 향하지 않는지 확인함. 여기까지는 교과서적인 SSRF 방어임.

문제는 그 다음. 웹훅이 실제로 발사될 때 HTTP 클라이언트가 리다이렉트를 그냥 따라감. 등록 시점엔 멀쩡한 공인 IP를 반환하던 서버가, 호출 시점에 302로 내부 주소를 가리키면 검증은 이미 지나간 뒤라 아무도 막지 않음. 전형적인 TOCTOU(검사 시점과 사용 시점의 불일치) 구조임. 같은 원리로 DNS 리바인딩 — 짧은 TTL로 같은 도메인의 응답을 공인 IP에서 사설 IP로 바꿔치기하는 방식 — 도 통함.

결정타는 접근 통제. 웹훅을 테스트하는 엔드포인트가 인증을 요구하지 않아서, 서버 주소만 알면 누구나 "이 웹훅 한번 쏴봐"를 시킬 수 있었음. 게다가 응답 본문이 호출자에게 되돌아오는 full-read SSRF라, 내부 서비스를 두드리는 데서 끝나지 않고 읽어낸 내용까지 회수됨.

2. 공격자가 실제로 가져간 것

구체적인 요청 형태는 굳이 적지 않겠음. 방어자 입장에서 중요한 건 도착지임. 클라우드 인스턴스는 대부분 링크로컬 주소의 메타데이터 서비스를 통해 자기 역할(role) 자격증명을 받아오는데, SSRF로 그 경로를 대신 읽게 만들면 AWS IAM 임시 토큰, GCP 서비스 계정 키, Azure 관리 ID 토큰이 통째로 노출됨.

이 자격증명이 왜 무서운가 하면, 그 뒤부터는 취약점이 필요 없어지기 때문임. 정상적인 API 호출로 스토리지 버킷을 훑고, 시크릿 매니저를 열고, 다른 인스턴스로 옆걸음질하는 단계로 넘어감. 실제로 초기 침투 브로커들이 자동화 스캐너로 노출 서버를 긁어 자격증명을 수집하고 있다는 관측이 여러 곳에서 나왔음.

3. 탐지 — 로그 어디를 볼 것인가

애플리케이션 로그: /api/2.0/mlflow/webhooks 경로에 대한 등록 요청과, 그 직후 이어지는 /test 호출. 사람이 쓰는 패턴이면 드문드문이지만 스캐너는 초 단위로 반복함.
아웃바운드 트래픽: MLflow 서버에서 169.254.169.254, metadata 관련 내부 호스트명, 127.0.0.1, RFC1918 사설 대역으로 나가는 HTTP 요청. 정상 운영에서는 웹훅이 내부를 향할 이유가 거의 없음.
리다이렉트 체인: 3xx 응답을 받은 직후 목적지가 공인 IP에서 사설 IP로 바뀌는 흐름. 프록시 로그가 있으면 여기가 제일 선명함.
DNS: 동일 도메인이 짧은 간격으로 공인 → 사설 IP로 응답을 바꾸는 리졸브. 리바인딩의 지문 같은 것임.
클라우드 감사 로그: 인스턴스 역할 자격증명이 해당 인스턴스가 아닌 IP에서 사용된 흔적. AWS라면 GuardDuty의 자격증명 외부 유출 계열 탐지가 여기에 걸림. 침해 확인용으로는 이게 가장 확실한 신호임.

4. 완화 — 순서대로

3.15.0 이상으로 올린다. 검증한 주소를 연결 시점에 고정하는 방식으로 바뀌었음. KEV 등재 항목이라 공공기관은 기한까지 붙어 있고, 민간도 그 기준을 그대로 따라가는 게 안전함.
트래킹 서버를 인터넷에서 내린다. MLflow는 원래 인증이 얇은 도구임. 리버스 프록시에 인증을 걸거나, VPN·사설망 뒤로 넣는 게 정석임.
egress 기본 차단. 웹훅이 나갈 곳이 정해져 있다면 allowlist로 묶어두면 됨. SSRF는 나가는 길이 막히면 상당 부분 무력화됨.
IMDSv2 강제 + hop limit 1. 토큰 기반 요청만 받게 하고 홉 수를 제한하면, 단순 GET형 SSRF로는 메타데이터에 닿지 못함. 개인적으로는 패치보다 이쪽을 먼저 확인해보길 추천함 — 다음번 SSRF까지 같이 막아주는 설정이라서.
권한 최소화와 회전. 인스턴스 역할에 붙은 정책이 넓으면 SSRF 하나가 계정 장악으로 번짐. 노출 정황이 있으면 자격증명 회전은 선택이 아니라 필수임.

5. 남는 이야기

이번 건을 보면서 계속 걸렸던 건, 방어 코드가 없어서 뚫린 게 아니라 있는 방어 코드가 한 박자 일찍 실행돼서 뚫렸다는 점이었다. 검증은 분명히 했는데, 검증한 값과 실제로 연결한 값이 달랐던 거죠. URL 필터링은 SSRF 방어의 절반밖에 안 되고, 나머지 절반은 "실제로 연결하는 그 순간"에 걸어야 한다는 게 이 CVE가 남긴 교훈인 것 같다.

MLOps 스택은 실험 편의를 위해 만들어진 도구가 어느새 프로덕션 경계에 서 있는 경우가 많다보니, 이런 구멍이 유난히 크게 번짐. 사내에 MLflow를 굴리고 계신다면 오늘은 버전 확인이랑 외부 노출 여부, 이 두 가지만이라도 같이 점검해보아요. 확인해보고 애매한 부분 있으면 댓글로 남겨주세요, 같이 찾아봅시다.

앞단은 막았는데 뒷단이 열렸다, WebLogic 프록시 플러그인 CVE-2026-21962

Tue, 25 Aug 2026 13:02:34 +0900

이미지 출처: CISA KEV

웹 서버를 앞에 세우고 애플리케이션 서버를 뒤에 숨기는 구성은 자바 진영에서 거의 20년 가까이 정석 취급을 받아 왔음. Oracle HTTP Server(OHS)가 요청을 받아 WebLogic Server로 넘겨주는 프록시 플러그인, 흔히 mod_wl_ohs 혹은 mod_weblogic이라 부르는 그 모듈이 그 정석의 한가운데에 있음. 그런데 이번에 공개된 CVE-2026-21962는 그 중간 다리 자체가 "누구를 어디로 보낼지"를 잘못 판단할 수 있다는 이야기라서, 구조를 믿고 설계했던 사람일수록 더 신경이 쓰이는 사안임.

핵심 요약

Oracle HTTP Server와 WebLogic Server 프록시 플러그인에서 접근 통제가 제대로 적용되지 않는 결함으로, 원격에서 HTTP만으로 건드릴 수 있는 성격의 문제임.
프록시 뒤를 "내부망이니까 안전하다"고 가정한 구성일수록 관리 경로·내부 전용 경로가 그대로 노출될 위험이 커짐.
정답은 Oracle 정기 패치 적용이고, 그 전까지는 경로 화이트리스트·WL-Proxy 계열 헤더 정리·백엔드 자체 인증으로 시간을 벌어야 함.

1. 이 플러그인이 실제로 하는 일

프록시 플러그인은 단순한 전달자가 아님. 요청 URI를 보고 WebLogic으로 보낼지 OHS가 직접 처리할지 고르고, 클러스터 멤버 목록을 관리하고, 원본 클라이언트 정보를 WL-Proxy-Client-IP, WL-Proxy-SSL 같은 헤더에 실어 뒤로 넘김. 즉 백엔드 입장에서 "이 요청이 누구한테서 왔는가"라는 판단의 상당 부분을 이 모듈에 위임하고 있는 셈임.

그러다 보니 이 모듈이 경로 매칭이나 접근 조건을 느슨하게 해석하는 순간, 앞단 웹 서버에 아무리 촘촘하게 규칙을 걸어 두었어도 그 규칙을 우회한 요청이 뒤로 흘러갈 수 있음. 이번 건의 성격이 딱 그 지점임. 공격 재현을 세세히 늘어놓을 필요는 없고, 개념만 잡으면 충분함. 앞단의 접근 통제와 뒷단의 라우팅 판단이 서로 다른 기준으로 같은 URI를 해석할 때 틈이 생긴다는 고전적인 구도.

2. 방어자가 진짜 걱정해야 할 부분

WebLogic을 운영해 본 사람은 알겠지만, 관리 콘솔이나 Enterprise Manager 경로는 보통 "외부에서는 프록시가 막아 주니까"라는 전제로 남겨 두는 경우가 많음. 인증이 아예 없는 게 아니라, 인증 앞에 놓인 방어선이 하나 더 있다고 믿는 상태인 것임. 그 방어선이 무력화되면 남는 건 계정 하나뿐이고, 기본 계정이나 오래된 계정이 살아 있다면 이야기가 급격히 나빠짐.

여기에 더해, 백엔드 애플리케이션이 원본 IP를 판단할 때 프록시가 붙여 준 헤더를 그대로 믿는 코드가 흔함. 외부에서 온 요청이 프록시 계층을 제대로 거치지 않고 들어올 수 있다면, 그 헤더는 더 이상 신뢰 근거가 아니라 공격자가 제어하는 입력값이 됨. 관리자 IP 화이트리스트가 이런 방식으로 무너지는 사례를 여러 번 봤음.

3. 탐지: 무엇을 어디서 볼 것인가

OHS 액세스 로그와 WebLogic 액세스 로그 상관분석 — 뒷단에는 기록이 있는데 앞단 로그에는 대응되는 항목이 없거나, 같은 요청인데 URI 문자열이 서로 다르게 남는 경우가 가장 굵은 신호임.
URI 정규화 흔적 — 중복 슬래시, 점 세그먼트, 세미콜론 파라미터, 이중 인코딩이 섞인 요청이 특정 시간대에 몰리는지 확인. 정상 브라우저 트래픽은 이런 모양을 거의 만들지 않음.
내부 전용 경로에 대한 외부 출처 요청 — 콘솔·관리·헬스체크·상태 조회 계열 경로가 대상. 인증 실패든 성공이든 시도 자체를 알림 대상으로 올려 두는 편이 나음.
WL-Proxy 계열 헤더가 클라이언트 요청에 실려 들어오는지 — 이 헤더는 원래 프록시가 붙이는 것이므로, 바깥에서 들어온 요청에 이미 들어 있다면 그 자체가 이상 징후임.
플러그인 디버그 로그 — 상시로 켜 두긴 부담스럽지만, 점검 기간 동안 한시적으로 켜서 라우팅 결정이 어떤 기준으로 내려졌는지 확인해 볼 가치가 있음.

4. 완화: 순서대로 밟기

첫째는 두말할 것 없이 Oracle 정기 보안 패치 적용임. 프록시 플러그인은 OHS 쪽과 WebLogic 쪽 버전이 함께 맞아야 하는 물건이라, 한쪽만 올리고 끝냈다가 낭패를 보는 일이 자주 생김. 적용 대상 목록을 만들 때 플러그인이 별도 웹 서버에 얹혀 있는 케이스를 빠뜨리지 않는 게 중요함.

둘째, 패치 창구가 열릴 때까지는 앞단에서 허용 경로 화이트리스트로 좁히는 방식을 권함. 막을 것을 나열하는 블랙리스트는 인코딩 변형 앞에서 늘 지는 싸움이었음. 셋째, 프록시 계층에서 들어오는 WL-Proxy 계열 헤더를 무조건 제거한 뒤 새로 붙이도록 정리할 것. 넷째, 백엔드가 프록시를 최종 방어선으로 삼지 않도록 관리 경로에 자체 인증과 접근 제한을 이중으로 걸어 두기. 다섯째, 관리 콘솔은 아예 별도 네트워크 세그먼트나 별도 포트로 분리해서 외부 경로에서 도달 자체가 불가능하게 만드는 게 가장 확실함.

5. 오늘 바로 해볼 점검 목록

우리 환경에 mod_wl_ohs 또는 mod_weblogic이 어디어디에 설치되어 있는지 전수 조사
OHS와 WebLogic의 패치 레벨이 서로 맞는지 대조
외부에서 관리 콘솔 경로에 도달 가능한지 실제로 확인
최근 한 달치 로그에서 앞단·뒷단 요청 수 불일치 구간 찾기
백엔드 코드가 프록시 헤더를 그대로 신뢰하는지 검토

개인적으로는 이런 종류의 취약점이 나올 때마다 "우리는 어디를 안전하다고 가정하고 있었나"를 다시 적어 보는 습관을 추천함. 패치는 이번 한 번으로 끝나지만, 잘못 잡힌 신뢰 경계는 다음 CVE에서 또 같은 자리를 내주게 되어 있음. 각자 환경에서 점검해 보시고, 로그에서 이상한 패턴 발견하신 분들은 어떤 모양이었는지 댓글로 공유해 주세요. 같이 정리하다 보면 훨씬 빨리 감이 잡힐 겁니다.