로그인 전에 루트를 내주는 로드밸런서, Kemp LoadMaster 결함을 방어자 시선으로 뜯어보기

이미지 출처: The Hacker News

데이터센터 도면을 펼쳐 보면, 외부에서 들어오는 트래픽이 처음 만나는 장비 중 하나가 로드밸런서다. 서버 여러 대 앞에 서서 요청을 나눠 보내고, TLS를 끊어 주고, 때로는 방화벽 노릇까지 한다. 그만큼 네트워크의 길목에 앉아 있는데, 이번에 Progress의 Kemp LoadMaster에서 보고된 결함은 바로 그 길목 장비가 로그인을 거치기도 전에 운영체제 수준의 명령을, 그것도 루트 권한으로 받아들일 수 있다는 내용이다.

핵심 요약

• Kemp LoadMaster의 관리 인터페이스에서 인증 전(pre-auth) 단계에 입력값이 OS 명령으로 흘러들 수 있는 결함이 보고됨.
• 로드밸런서는 경계에 노출되는 일이 많아, 한 번 뚫리면 내부망으로 들어가는 발판이 되기 쉬움.
• 핵심 방어는 관리 인터페이스 인터넷 비노출·패치 적용·접속 로그 모니터링 세 가지로 정리됨.

무엇이 문제인가

Kemp LoadMaster는 애플리케이션 전달 컨트롤러(ADC) 계열 제품으로, 웹 기반 관리 화면과 API로 설정을 다룬다. 이번 결함의 핵심은 명령어 주입(command injection) 계열로 분류되는 문제로, 인증을 통과하지 못한 요청에 담긴 입력값이 충분히 걸러지지 않고 내부에서 실행되는 명령의 일부로 쓰일 수 있다는 점에 있음. LoadMaster의 관리 데몬이 보통 높은 권한으로 동작하기 때문에, 주입이 성공하면 결과적으로 루트 권한의 명령 실행으로 이어질 수 있음.

여기서 '사전 인증(pre-auth)'이라는 표현이 중요함. 비밀번호를 모르거나 계정이 없어도, 장비가 네트워크에서 닿기만 하면 공격이 성립한다는 뜻이기 때문. 과거 같은 제품군에서도 인증 우회·명령 주입 계열 결함이 반복적으로 나온 전례가 있어, 패턴 자체가 낯설지 않음.

왜 더 위험하게 보아야 하나

일반 웹 서버가 뚫린 것과 경계 장비가 뚫린 것은 무게가 다름. 로드밸런서는 보통 다음 같은 위치에 있음.

• 외부 트래픽이 가장 먼저 도달하는 네트워크 가장자리에 배치됨.
• 여러 백엔드 서버로 향하는 경로와 인증서, 세션 정보를 다룸.
• 관리 편의를 위해 관리 화면이 인터넷에 노출된 채 운영되는 사례가 흔함.

즉 이 장비를 장악하면 공격자는 단순히 서버 한 대를 얻는 게 아니라, 내부망으로 들어가는 다리와 트래픽을 들여다보는 자리를 동시에 얻는 셈. 그래서 CVSS 수치가 어떻든, 운영 환경에서는 '최우선 점검 대상'으로 다루는 편이 안전함.

어떻게 탐지할 것인가

공격을 재현하는 페이로드를 늘어놓을 필요는 없음. 방어자가 봐야 할 것은 '징후'임. 다음 항목을 중심으로 로그와 네트워크를 살피는 것을 권함.

• 관리 인터페이스 접근 로그: 인증에 성공하지 않은 출처에서 관리 포트로 향하는 비정상 요청, 평소와 다른 User-Agent나 비정상적으로 긴 파라미터가 반복되는지 확인.
• 장비 내부 프로세스: 로드밸런서 위에서 평소에 돌 일이 없는 셸·네트워크 도구(예: 외부로 향하는 역방향 연결 시도)가 새로 생겨났는지 점검.
• 아웃바운드 트래픽: 경계 장비가 갑자기 외부의 낯선 주소로 연결을 거는 것은 강한 침해 신호. 평소 통신 대상 목록(베이스라인)과 비교하는 게 핵심.
• 설정 변경 이력: 관리자 계정 추가, 규칙 변경, 인증서 교체 등 누가·언제 바꿨는지 추적 가능한지 확인.

탐지는 결국 '평소를 알고 있느냐'의 문제임. 경계 장비의 정상 동작을 기록해 두지 않으면, 이상이 생겨도 이상인지 모름.

어떻게 완화할 것인가

우선순위를 두자면 이렇게 정리할 수 있음.

• 패치 적용: 제조사가 내놓은 보안 업데이트를 가능한 빨리 반영. 경계 장비는 점검 창(maintenance window)을 잡기 어렵다는 핑계로 미뤄지기 쉬운데, 이번 같은 사전 인증 결함은 그 미룸이 곧 위험임.
• 관리 인터페이스 비노출: 관리 화면과 API는 인터넷에 직접 열어 두지 말고, 별도 관리망이나 VPN·점프호스트를 거쳐서만 닿도록 분리. '접근 자체를 막으면' 사전 인증 결함의 상당수는 실효를 잃음.
• 접근 통제와 분리: 관리 출처 IP를 화이트리스트로 좁히고, 로드밸런서가 위치한 망과 내부 핵심 자산 사이에 분할(세그멘테이션)을 둠.
• 침해 가정 점검: 노출 기간이 길었다면 이미 들어왔을 수 있다고 보고, 계정·인증서·설정을 점검하고 필요하면 교체.

마무리

경계 장비는 '잘 돌아가니까 건드리지 말자'는 심리 때문에 패치가 가장 늦어지는 영역인 것 같다. 그런데 역설적으로, 가장 바깥에서 가장 높은 권한으로 도는 장비라 한 번의 사고가 가장 아픈 곳이기도 함. 개인적으로는 이번 사건을 계기로, 우리 환경의 로드밸런서·VPN·방화벽 같은 관리 화면이 인터넷에서 보이는지부터 한 번 점검해 보길 추천한다. 노출 여부를 확인하고, 패치 일정을 잡고, 접근 로그를 베이스라인과 맞춰 보는 것까지가 한 세트다. 우리 장비는 지금 어떤지, 같이 점검해 보아요. 점검하다 막히는 부분이 있으면 댓글로 공유해 주세요.