Zbtlink 라우터, 인증 없이 root 셸이 열린다면 어디부터 끊어야 할까

이미지 출처: The Hacker News

지방 공장 전기실 캐비닛을 열어보면 손바닥만 한 4G/5G 라우터가 케이블 타이에 묶인 채 몇 년째 돌아가고 있는 걸 흔히 본다. 설치한 사람은 이미 퇴사했고, 관리대장에도 "통신 장비" 한 줄로만 적혀 있고, 펌웨어는 출고 당시 그대로다. 이번에 Zbtlink 라우터에서 보고된 이야기는 딱 그런 장비들 이야기라서, 읽으면서 계속 그 캐비닛이 떠올랐다. 취약점이라기보다는 제조 단계에서 들어간 채 출고된 관리용 뒷문에 가깝고, 그 문을 두드리면 인증 절차 없이 root 권한 셸이 떨어진다는 게 요점이다.

핵심 요약

• Zbtlink 계열 라우터 펌웨어에 문서화되지 않은 서비스가 포함돼, 인증 없이 root 셸이 열리는 경로가 보고됨.
• 패치보다 먼저 할 일은 "우리 망에 이 장비가 몇 대 있는가"를 확인하는 자산 파악과 관리 포트 노출 차단임.
• WAN 노출 여부 점검, 관리망 분리, 아웃바운드 통제, 로그 원격 수집 세 가지만 해도 실질적 피해 범위는 크게 줄어듦.

1. 무엇이 문제인가 — 버그가 아니라 '설계된 통로'

• 일반적인 원격코드실행 취약점은 파서 버그·메모리 오류처럼 실수에서 출발함. 반면 이번 사안은 펌웨어 이미지 안에 처음부터 들어 있던 관리·디버깅용 통로가 제거되지 않은 채 양산품에 실려 나간 형태에 가까움.
• 이런 통로의 전형적인 모습은 세 가지임. ①비표준 포트에서 대기하는 정체불명 데몬 ②쉐도우 파일에 박혀 있는 하드코딩 계정 ③특정 문자열을 받으면 telnet/드롭베어를 켜주는 "매직 패킷" 처리 루틴.
• 공통점은 인증 단계 자체가 존재하지 않거나 우회된다는 것. 비밀번호를 아무리 복잡하게 바꿔도, 웹 관리자 계정을 잠가도 이 경로는 그대로 살아 있음.
• Zbtlink 같은 화이트라벨 제조사 제품은 국내외 여러 브랜드로 리브랜딩돼 팔리는 경우가 많음. 그래서 겉에 붙은 상표만 보고 "우리는 그 회사 제품 안 씀"이라고 결론 내리면 안 됨. 이게 이번 건에서 가장 놓치기 쉬운 부분이라고 봄.

2. 왜 라우터 백도어가 유독 아픈가

• 라우터는 경계선 그 자체임. 여기서 root를 잡히면 방화벽 규칙 수정, DNS 변조, 트래픽 미러링, 내부망으로의 터널 개설이 전부 한 번에 가능해짐.
• EDR이 안 깔림. 안 깔리는 정도가 아니라 깔 수가 없음. 결국 장비 자신이 남기는 로그와 옆에서 관찰하는 트래픽이 탐지 수단의 전부임.
• 재부팅·공장초기화로 지워지지 않음. 펌웨어에 포함된 통로라면 초기화는 오히려 "출고 상태 = 취약 상태"로 되돌리는 행위임.
• 산업용 셀룰러 라우터는 공인 IP를 직접 물고 있는 경우가 많아, 스캐너가 대역을 훑기만 해도 후보 목록이 만들어짐.

3. 탐지 순서 — 장비를 열기 전에 망에서 먼저 본다

순서를 잘못 잡으면 시간만 버린다. 개인적으로는 아래 순서를 추천함.

• 자산 식별 먼저. 관리대장이 아니라 실제 트래픽에서 찾아야 함. DHCP 로그·ARP 테이블·NetFlow에서 MAC OUI를 뽑아 제조사 대역과 대조하고, 웹 관리 페이지의 타이틀·favicon 해시로 동일 계열 장비를 묶는 방식이 빠름.
• 외부 노출면 확인. 회사가 보유한 공인 IP 대역을 대상으로 전체 포트 스캔을 돌려, 문서화되지 않은 열린 포트가 있는지 본다. 특히 웹 관리(80/443/8080) 외에 23, 22, 그리고 4자리·5자리 비표준 포트가 응답하면 그 자체로 조사 대상임.
• 장비 내부 확인. 콘솔 접근이 가능하다면 현재 리스닝 소켓 목록과 프로세스 목록을 떠서, 벤더 문서에 없는 프로세스가 포트를 물고 있는지 대조함. 계정 파일에 UID 0 계정이 root 외에 더 있는지도 같이 봄.
• 펌웨어 대조. 벤더가 배포하는 이미지 해시와 실제 장비 이미지 해시를 비교. 다르면 이미 손을 탄 것일 수도 있고, 그냥 구버전일 수도 있으니 버전 문자열까지 같이 기록해 둠.

공격을 그대로 재현해 보려는 시도는 굳이 권하지 않음. 인증이 없는 경로라는 성질상 "연결이 수립되고 프롬프트가 뜨는지" 여부만 확인해도 판정에는 충분하고, 그 이상은 운영 장비를 흔들 위험만 커짐.

4. 침해가 있었다면 어디에 흔적이 남는가

• 세션 기록의 공백. 웹 로그인 이력은 없는데 설정 변경 시각만 존재하는 패턴. 정상 관리자는 로그인 없이 설정을 못 바꾸므로, 이 불일치가 가장 강한 신호임.
• 방화벽·포트포워딩 규칙의 조용한 추가. 내부 서버로 향하는 낯선 DNAT 한 줄이 붙어 있는지 확인.
• DNS 설정 변조. 장비가 배포하는 DNS 서버가 통신사/사내 리졸버가 아닌 낯선 IP로 바뀌어 있는 경우.
• 비정상 아웃바운드. 라우터 자신이 외부로 지속 연결을 맺는 트래픽. 특히 새벽 시간대 규칙적인 비콘이나 장시간 유지되는 암호화 세션.
• cron·startup 스크립트 추가. 재부팅 후에도 통로를 되살리려는 지속성 확보 흔적이 여기 남음.

이런 것들은 장비 안에만 두면 지워지면 끝이라, syslog를 외부 수집기로 상시 전송해 두는 게 사실상 유일한 보험임. 사고 나고 나서 "로그가 없네요"라는 말을 몇 번 들어보면 이 설정 하나가 얼마나 큰지 체감하게 됨.

5. 오늘 안에 할 수 있는 완화

• WAN 쪽 관리 인터페이스 전면 차단. 원격 관리가 꼭 필요하면 VPN 뒤로 넣고, 장비 자체의 원격 관리 기능은 끔.
• 관리망 분리. 라우터 관리 인터페이스에 접근 가능한 출발지 IP를 관리 VLAN 소수 대역으로만 화이트리스트.
• 아웃바운드 통제. 라우터 자신이 임의 목적지로 나가지 못하도록 제한. 백도어가 열려도 밖으로 못 나가면 활용 폭이 크게 줄어듦.
• 펌웨어 갱신과 교체 판단. 벤더가 수정 이미지를 내면 적용하되, 통로가 설계상 남아 있는 제품이라면 갱신보다 교체 계획을 세우는 편이 현실적일 수 있음. 특히 중요 구간에 놓인 장비라면 더 그럼.
• 조달 기준에 한 줄 추가. 앞으로 도입하는 네트워크 장비에 대해 "출고 펌웨어에 문서화되지 않은 서비스·계정이 없음"을 계약 문서에 명시하고, 납품 시 포트 스캔 결과를 받아두는 것. 이번 같은 일을 반복하지 않으려면 결국 여기까지 가야 함.

마무리

솔직히 이런 뉴스를 볼 때마다 제일 먼저 드는 생각은 "그래서 우리 회사에 저게 몇 대나 있지?"인데, 대부분은 그 질문에 바로 답을 못 하는 것 같다. 취약점 대응의 절반 이상은 사실 자산 파악이고, 그건 하루아침에 되는 게 아니라 차차 쌓아야 하는 일이라고 본다. 이번 주말에 캐비닛 한 번 열어보고, MAC 주소 하나라도 대장에 적어두는 것부터 같이 시작해보아요. 혹시 현장에서 이런 화이트라벨 장비 정리해 본 경험 있으시면 어떤 방식으로 목록을 만드셨는지 댓글로 나눠주시면 저도 배우겠습니다.