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

이미지 출처: 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가 추가되는 순간 무너짐. 반대로 "이 기능을 실행하려면 유효한 신원이 필요하다"를 기능 자체의 조건으로 못 박아두면, 어떤 경로로 들어와도 같은 검사를 통과해야 함.

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

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