관리자 페이지에 글자 몇 개 더 넣었을 뿐인데 — Lantronix EDS5000 코드 인젝션 들여다보기

이미지 출처: CISA KEV

공장 배전반 옆이나 발전 설비 캐비닛 안을 열어 보면, 손바닥만 한 회색 상자가 시리얼 케이블 한 줄과 랜선 한 줄을 양쪽에 물고 조용히 깜빡이고 있는 걸 종종 본다. Lantronix EDS5000 같은 디바이스 서버가 딱 그 자리를 지키는 물건이다. RS-232·RS-485로만 말하던 옛날 장비를 이더넷 세상에 끌어다 붙여 주는, 말하자면 통역사 같은 존재다. 그런데 이번에 공개된 CVE-2025-67038은, 그 통역사가 들은 말을 그대로 명령으로 실행해 버릴 수 있다는 이야기다.

핵심 요약

• Lantronix EDS5000 디바이스 서버의 관리 인터페이스 입력값이 시스템 명령으로 흘러드는 코드 인젝션 결함임.
• 이런 장치는 OT·산업망 깊숙이 박혀 있어 한 대만 뚫려도 내부망으로 가는 발판이 됨.
• 방어는 펌웨어 갱신·관리망 분리·접근통제가 기본이고, 평소 입력 패턴과 다른 요청을 잡아내는 모니터링이 핵심.

코드 인젝션, 이 장치에서 왜 더 무서운가

코드 인젝션을 한 줄로 풀면 "데이터로 들어가야 할 입력이 명령으로 둔갑하는 것"이다. 사용자가 장치 이름이나 네트워크 설정 같은 값을 입력하면, 펌웨어가 그 값을 내부적으로 셸이나 시스템 호출에 넘기는 경우가 있음. 이때 입력을 충분히 걸러 내지 못하면, 공격자가 정상 값처럼 보이는 문자열 안에 명령 구분 기호를 끼워 넣어 장치가 의도하지 않은 동작을 하게 만들 수 있음. 구체적인 페이로드는 여기서 다루지 않지만, 원리는 "신뢰할 수 없는 입력을 신뢰하는 실행 경로에 그대로 통과시킨다"는 고전적인 실수에서 출발함.

일반 웹 서버였다면 이것만으로도 충분히 심각한데, EDS5000 같은 장치는 사정이 더 안 좋다. 이런 디바이스 서버는 한 번 설치하면 몇 년씩 손대지 않고, 펌웨어 갱신 주기도 길며, 종종 "내부망이니 괜찮겠지"라는 믿음 아래 관리 화면이 사내망 어딘가에 노출돼 있음. 게다가 운영기술(OT) 환경의 길목에 있다 보니, 이 작은 상자 하나가 IT망과 OT망을 잇는 다리가 되기도 함. 공격자 입장에서는 화려한 서버보다 이렇게 잊힌 장치가 훨씬 매력적인 발판인 거죠.

공격자는 어떻게 접근하나 (개념 수준)

실행 가능한 공격 코드를 적는 대신, 방어를 설계하는 데 필요한 만큼만 흐름을 정리해 본다.

• 1단계 — 발견: 인터넷이나 내부망 스캔으로 특정 포트·배너·관리 페이지 특징을 보고 디바이스 서버를 식별함. Shodan류 검색이나 평범한 포트 스캔으로도 충분히 드러나는 경우가 많음.
• 2단계 — 진입: 기본 자격증명이 그대로거나 인증이 약한 관리 화면에 접근함. 많은 OT 장비가 출고 시 비밀번호를 끝까지 안 바꾼 채 운영됨.
• 3단계 — 주입: 설정 입력 필드에 명령 의미를 띤 문자열을 끼워 넣어, 장치가 그 값을 실행 경로로 넘기도록 유도함.
• 4단계 — 확장: 장치 권한으로 명령이 돌아가면 그걸 발판 삼아 같은 세그먼트의 다른 장비를 정찰하거나 트래픽을 가로챔.

중요한 건, 이 사슬의 어느 한 고리만 끊어도 전체가 무너진다는 점이다. 그래서 방어는 "완벽한 패치 하나"가 아니라 "여러 겹의 차단"으로 가는 게 현실적이다.

방어자 관점 — 무엇을 보고 무엇을 잠그나

탐지 쪽부터 보면, 디바이스 서버는 평소 행동이 굉장히 단조롭다는 게 오히려 무기가 된다. 시리얼 데이터를 한 방향으로 흘려보내는 게 일과의 거의 전부라, 정상 트래픽 패턴이 또렷함. 그래서 다음과 같은 신호가 평소 그림과 어긋나면 의심해 볼 만함.

• 관리 포트로 평소 없던 출처에서 들어오는 인증 시도나 설정 변경 요청.
• 장치가 갑자기 외부로 새로운 연결을 맺으려 하는 아웃바운드 트래픽 — 디바이스 서버가 먼저 바깥에 말을 걸 일은 거의 없음.
• 설정 필드 값에 들어 있을 이유가 없는 특수문자·명령 구분 기호가 섞인 요청.
• 짧은 시간에 반복되는 재부팅·설정 초기화 흔적.

이런 걸 잡으려면 결국 장치 앞단에서 트래픽을 보는 눈이 필요하다. OT망이라면 네트워크 IDS 룰에 디바이스 서버 관리 포트를 향한 비정상 요청을 추가하고, 가능하면 장치가 남기는 로그를 중앙 수집기로 끌어와 평소 베이스라인과 비교하는 걸 개인적으로 추천함.

지금 할 수 있는 완화책

• 펌웨어부터 확인: 제조사 보안 공지를 보고 해당 모델·버전에 대한 패치가 나왔는지 점검함. 정확한 영향 버전과 점수는 벤더·NVD 공지로 직접 대조하는 게 안전함.
• 관리망 분리: 장치의 웹·설정 인터페이스는 운영 트래픽과 다른 세그먼트에 두고, 관리는 점프 호스트나 VPN을 거치게 함. 인터넷 직접 노출은 무조건 끊는다.
• 기본 자격증명 제거: 출고 비밀번호 변경은 기본 중의 기본인데도 가장 자주 빠뜨리는 항목임. 계정·권한도 최소한으로 줄임.
• 불필요한 서비스 끄기: 안 쓰는 관리 프로토콜·포트는 닫아 공격 표면을 줄임.
• 접근통제: 관리 인터페이스에 접근할 수 있는 출발지 IP를 화이트리스트로 좁힘.

마무리

이번 건이 주는 교훈은 의외로 단순하다. 우리가 보안을 떠올릴 때 머릿속에 그리는 건 대개 번듯한 서버와 애플리케이션인데, 정작 사고의 발판은 이렇게 캐비닛 구석에서 몇 년째 깜빡이던 통역사 상자인 경우가 많다는 것. 자산 목록에 이름조차 안 올라간 장치가 있다면, 그게 바로 첫 점검 대상이다. 오늘 당장 우리 망 어딘가의 디바이스 서버 목록부터 한번 훑어보는 건 어떨까. 혹시 이미 EDS5000을 운영 중이거나 비슷한 OT 장비 점검 경험이 있다면, 어떤 식으로 관리망을 분리했는지 댓글로 같이 나눠 봐요.