패치 권고에서 강제 기한으로: LoadMaster 명령 주입이 실제 공격에 쓰이기 시작함

이미지 출처: BleepingComputer

자산 목록에 로드밸런서 항목이 아예 없다는 사실은 보통 이런 순간에 드러남. 상부에서 "우리 LoadMaster 패치됐나요?"라는 한 줄 질문이 내려오고, 네트워크팀은 "그건 보안팀 자산 아니에요?"라고 답하고, 보안팀 스캐너 결과에는 그 장비의 관리 IP가 등록조차 안 되어 있는 상황. Progress LoadMaster의 치명적 결함이 실제 공격에 쓰이고 있다는 경고가 나온 지금, 이 공백이 그대로 노출면이 됨.

핵심 요약

• 앞서 정리했던 LoadMaster 관리 인터페이스 명령 주입 결함(CVE-2026-8037 계열)이 이제 이론이 아니라 관측된 공격 단계로 넘어감
• 로드밸런서는 TLS를 종료하고 인증서 개인키와 백엔드 구조를 다 들고 있는 장비라 한 번 뚫리면 피해 범위가 뒤쪽 서버 전체로 번짐
• 패치는 최소 조건이고, 관리평면 격리·설정 변경 감시·아웃바운드 통신 점검까지 묶어야 실제 방어가 됨

무엇이 어떻게 넘어가는가 (개념 수준)

핵심은 관리 인터페이스가 받아들이는 요청 파라미터가 내부적으로 시스템 명령 컨텍스트까지 흘러 들어간다는 점임. 인증 절차를 온전히 통과하지 않은 요청도 이 경로에 닿을 수 있다는 게 심각도를 최고 수준으로 밀어올린 이유임. 즉 자격증명 탈취나 사전 침투 같은 전제 조건 없이, HTTP 요청을 어떻게 구성하느냐만으로 장비 권한 실행에 도달할 수 있음. 재현 방법은 여기서 더 구체화하지 않음 — 방어 관점에서 필요한 정보는 "인증 없는 요청이 명령 실행으로 이어질 수 있다"는 사실 하나로 충분함.

더 중요한 건 대상 장비의 위치임. LoadMaster는 서비스 최전선에서 TLS 세션을 종료하고 뒤쪽으로 평문 트래픽을 뿌려주는 역할을 함. 그러니까 이 장비 안에는 다음이 함께 들어 있음.

• 서비스 도메인용 인증서와 개인키 — 유출되면 복호화·위장 모두 가능해짐
• 백엔드 실서버의 내부 IP·포트·헬스체크 경로 등 내부망 지도
• 인증 연동을 걸어둔 경우 디렉터리 서비스 계정 정보
• 세션 지속성 정보와, 경우에 따라 요청 본문까지 들여다볼 수 있는 중간 위치

정리하면 침해 시 시나리오가 "장비 하나 장악"에서 끝나지 않고, 조용한 트래픽 감청과 내부망 측면 이동의 출발점이 됨.

악용이 확인되면 계산이 달라짐

취약점 공개 직후와 실제 악용 관측 이후는 성격이 완전히 다름. 앞 단계에서는 "다음 정기 점검에 반영"이 그래도 통하는 선택이었지만, 뒤 단계에서는 인터넷에 노출된 관리 UI가 대량 스캐닝의 표적 목록에 이미 올라가 있다고 봐야 함. 공개된 관리 인터페이스는 검색엔진성 스캐너로 특정 응답 헤더나 로그인 페이지 특징만으로도 식별되기 때문에, 우리 조직이 작아서 눈에 안 띈다는 가정은 성립하지 않음.

그리고 KEV류 목록에 등재된다는 건 "권고"가 "기한"으로 바뀐다는 뜻임. 규제 대상 조직이 아니어도 이 기한은 실무적으로 유용한 기준이 됨 — 내부 설득 자료로 쓰기에 이만한 근거가 없음.

오늘 안에 끝낼 순서

• 노출 확인부터. 관리 포트가 외부에서 응답하는지 사내 대역이 아닌 회선에서 직접 확인함. 방화벽 정책 문서만 믿지 말고 실제 응답으로 검증할 것
• 패치 적용. 벤더가 배포한 수정 버전으로 올림. 이중화 구성이면 스탠바이 먼저 올리고 전환 테스트 후 액티브 순서로 진행
• 즉시 패치가 불가하면 접근 통제로 시간 벌기. 관리 인터페이스를 점프호스트·전용 관리 VLAN·VPN 뒤로만 도달 가능하게 제한함. 완화가 아니라 임시 조치라는 점을 티켓에 명시해둘 것
• 기본·유휴 계정 정리. 초기 관리자 계정, 퇴사자 계정, 자동화용 API 계정을 목록으로 뽑아 사용 여부를 확인함

탐지: 이미 손댔는지 어떻게 보는가

어플라이언스 계열의 가장 큰 약점은 EDR을 올릴 수 없다는 점임. 그래서 탐지는 장비가 남기는 로그와, 장비 밖 네트워크 텔레메트리 두 축으로 봐야 함.

• 웹 관리 접근 로그: 평소 접속하지 않는 출처 IP, 짧은 시간에 몰린 비정상 경로 요청, 자동화 도구 특유의 User-Agent 패턴
• 설정 변경 이력: 신규 관리자 계정 생성, 원격 접근 허용 범위 확대, SSH 공개키 추가, 신규 가상 서비스나 정체불명의 리다이렉트 규칙
• 설정 백업 파일의 반출 흔적: 인증서와 계정 정보가 함께 담기는 파일이라 공격자가 가장 먼저 노리는 대상임
• 아웃바운드 세션: 로드밸런서는 원래 밖으로 먼저 나갈 일이 거의 없는 장비임. 낯선 목적지로 향하는 지속 연결이나 규칙적인 비컨 패턴은 그 자체로 강한 신호임
• 재부팅·프로세스 이상·계정 잠금 같은 운영 이벤트를 침해 관점으로 다시 읽어보기

여기서 현실적인 문제 하나. 대부분의 조직이 이런 장비 로그를 원격으로 모아두지 않아서, 정작 필요할 때 "볼 로그가 없음" 상태가 됨. 이번 대응에 syslog 원격 전송 설정을 반드시 끼워 넣기를 개인적으로 강하게 추천함. 지금 5분 걸리는 설정이 다음 사고에서 며칠을 아껴줌.

침해가 의심될 때의 복구 원칙

명령 실행까지 갔을 가능성이 있으면 패치만으로 정리됐다고 보기 어려움. 순서는 이렇게 잡는 게 안전함.

• 해당 장비를 거친 모든 인증서 개인키 재발급·교체, 기존 인증서 폐기
• 관리자 자격증명, API 토큰, 디렉터리 연동 계정 일괄 회전
• 현재 설정을 침해 이전 백업과 줄 단위로 비교해 추가된 규칙·계정·키 확인
• 가능하면 깨끗한 이미지로 재설치한 뒤, 검증한 설정만 다시 올림. 침해된 장비의 설정 백업을 그대로 복원하면 심어둔 흔적까지 같이 살아남음
• 뒤쪽 백엔드 서버까지 조사 범위 확장 — 로드밸런서에서 내부로 향한 비정상 접근이 있었는지 확인

남는 교훈

앞단 장비는 관리 주체가 애매해서 취약점 관리 사각지대에 놓이기 쉬움. 이번 사안에서 진짜 얻어갈 건 특정 CVE 번호가 아니라, 관리평면은 절대 인터넷에 두지 않는다는 원칙과 에이전트를 못 올리는 장비는 네트워크 관점으로 감시한다는 보완 전략임. 이 두 가지만 자리 잡으면 다음에 비슷한 결함이 또 나와도 대응이 훨씬 담백해짐.

혹시 사내에 LoadMaster를 굴리고 있다면, 이 글 읽고 바로 관리 포트 노출 여부 한 번만 확인해 보시길 부탁드려요. 확인해 보고 예상과 달랐던 부분이 있으면 댓글로 공유해 주세요. 저도 어플라이언스 로그를 모으는 구성을 계속 손보고 있는 중이라, 각자 쓰는 방법을 나누면 서로 도움이 될 것 같아요. 같이 점검해 보아요!