요약
소형 라우터의 보안은 하드웨어를 사기 전에 이미 절반이 결정된다. 기본 설정, 노출된 관리 인터페이스, 물리 접근 벡터, 그리고 갱신되지 않은 펌웨어 — 이 넷이 SOHO(Small Office/Home Office) 라우터 사고의 대부분을 설명한다. 이 글은 MikroTik RB4011iGS+5HacQ2HnD를 예시로 삼아, 이미 공개된 하드웨어 사양과 벤더가 이미 패치를 배포한 CVE만을 놓고 방어자가 무엇을 점검해야 하는지 회고한다.
여기서 다루는 CVE-2023-32154는 Pwn2Own Toronto 2022에서 공개 시연되고 2023년 5월 MikroTik이 패치한 사안이다. 즉 새로운 발견이 아니라 이미 종결된 사건의 교훈이다. 익스플로잇 코드나 재현 절차는 이 글의 범위가 아니며, 방어자가 자산 인벤토리에서 무엇을 확인해야 하는지에 집중한다.
세 계층으로 나눠 본다. 하드웨어와 물리 접근, 네트워크·관리 인터페이스, 그리고 공개 CVE 타임라인이다.
1. 하드웨어와 물리 접근 표면
RB4011의 위치
RB4011은 MikroTik의 유선 중심 SOHO/엔터프라이지 엣지 라우터다. 상위 모델명 RB4011iGS+5HacQ2HnD-IN이 사양을 그대로 담고 있다. iGS+는 SFP+ 케이지를 포함한 기가비트 인터페이스군을, 5Hac는 5GHz 802.11ac 무선을, Q2HnD는 2.4GHz 무선 모듈을 뜻한다. 즉 이 모델은 유선 10포트에 듀얼밴드 무선을 얹은 통합 엣지 장비다.
방어자 관점에서 하드웨어 사양이 중요한 이유는 단순하다. 공격 표면은 물리적으로 존재하는 인터페이스의 총합이기 때문이다. 켜져 있는 포트, 노출된 콘솔, 활성화된 무선 라디오 하나하나가 잠재적 진입점이다. 사양서를 읽는 것은 인벤토리 작성의 첫 단계다.
무선 라디오 두 개
RB4011은 물리적으로 분리된 두 무선 모듈을 탑재한다.
| 밴드 | 모듈 | 체인 | 최대 대역폭 |
|---|---|---|---|
| 2.4 GHz | R11e-2HnD | 2T2R | 40 MHz (802.11n) |
| 5 GHz | QCA-9984 | 4T4R | 160 MHz (802.11ac Wave2) |
두 라디오는 각각 독립적인 공격 표면이다. 하나를 끄더라도 다른 하나가 켜져 있으면 무선 진입점은 여전히 열려 있다. 특히 5GHz의 QCA-9984는 4T4R·160MHz까지 지원하는 고성능 모듈이라 커버리지가 넓다 — 이는 성능상 장점이지만, 의도한 물리적 경계 너머까지 신호가 도달할 수 있다는 방어상 고려사항이기도 하다. AP를 벽 근처에 두면 주차장이나 옆 건물에서 SSID가 잡힐 수 있다.
기본 상태에서 이 장비는 AP 모드가 활성화되어 있고, 후술하듯 초기 무선 패스워드가 없다. 무선 라디오는 CPE·P2P·Repeater 모드도 지원하므로, 배치 시나리오에 따라 표면의 성격이 달라진다. 방어자는 "실제로 필요한 무선 모드가 무엇인가"를 먼저 정하고, 나머지는 비활성화하는 것이 원칙이다.
SFP+ 포트의 제약
RB4011의 SFP+ 케이지는 모든 광 모듈을 받지는 않는다. 공개 사양에 따르면 passive DAC 모듈, 1G copper SFP, SFP GPON 모듈이 미지원이다. 이 사실은 보안상 양면적이다. 한편으로는 임의 모듈을 꽂아 물리 채널을 활용하기 어렵다는 제약이고, 다른 한편으로는 운영자가 호환 모듈 목록을 사전에 확인해야 한다는 운영상 부담이다. 방어 관점에서 SFP+ 슬롯은 물리 접근이 가능한 확장 포트이므로, 사용하지 않는다면 비워두고 물리 접근 자체를 통제하는 편이 낫다.
시리얼 콘솔 — 물리 접근의 핵심
RB4011은 RJ45 형태의 시리얼 콘솔을 제공한다. 통신 파라미터는 표준적인 115200/8N1이다. RJ45-USB 시리얼 어댑터를 연결하면 RouterOS 셸에 접근할 수 있다(로그인은 필요하다).
방어자에게 시리얼 콘솔의 의미는 명확하다. 물리적으로 장비에 손이 닿는 사람은 관리 평면의 문 앞에 서 있는 것이다. 데이터센터 랙, 잠긴 통신실, 감시 카메라 아래에 두는 물리 보안이 사이버 통제만큼 중요한 이유다. 콘솔 접근에 강한 인증을 걸어도, 물리 접근이 통제되지 않으면 다음 절에서 설명할 리셋 시퀀스로 우회될 수 있다.
시리얼 콘솔이 특히 위험한 이유는 그것이 인증을 우회하는 채널이 아니라, 인증 이전의 계층에 존재하는 채널이기 때문이다. 부트 과정에서 콘솔은 부트로더 메시지, 커널 로드 과정, 초기화 시퀀스를 그대로 출력한다. 정상 상태에서는 로그인이 필요하지만, 부트 흐름을 관찰하는 것만으로도 펌웨어 버전, 하드웨어 리비전, 부트 순서 같은 정보가 드러난다. 방어자 관점에서 이것은 "물리 접근이 곧 정보 노출"이라는 원칙을 재확인시킨다. SOHO 라우터가 로비, 회의실, 창고처럼 통제되지 않은 공간에 방치되는 경우가 흔한데, 이런 배치는 그 자체로 하나의 취약점이다.
리셋 버튼 — 세 단계 시퀀스
MikroTik 라우터의 리셋 버튼은 홀드 시간에 따라 다른 동작을 한다. 공개된 사용자 매뉴얼 기준으로 정리하면 다음과 같다.
| 벡터 | 방법 | 결과 |
|---|---|---|
| 시리얼 콘솔 | RJ45→USB 어댑터, 115200/8N1 | RouterOS 셸 (로그인 필요) |
| Reset 5s | 부팅 중 홀드 → LED 깜빡이면 해제 | 설정 초기화 (완전 리셋) |
| Reset 10s | 계속 홀드 → LED 솔리드 → 해제 | CAP 모드 (CAPsMAN 서버 탐색) |
| Reset 15s | 계속 홀드 → LED 꺼짐 → 해제 | Netinstall 모드 (포트 1 TFTP) |
| RouterBOOT | 전원 인가 전 버튼 홀드 | 백업 부트로더 진입 |
이 시퀀스는 정상적인 복구 기능이지만, 동시에 물리 접근자가 설정을 통째로 날리고 초기 상태로 되돌릴 수 있는 경로이기도 하다. 5초 홀드로 설정이 완전 초기화되면, 초기 무인증 WebFig 상태로 돌아간다. 즉 물리 접근은 논리 통제를 초기화 버튼 하나로 무력화할 수 있다.
방어 원칙은 단순하다. 리셋과 콘솔이 있는 물리 장비는 물리적으로 통제된 공간에 둔다. 원격 관리로 아무리 견고하게 만들어도, 리셋 버튼에 손이 닿는 순간 그 견고함은 15초 안에 사라진다.
리셋 시퀀스의 각 단계는 서로 다른 위협 시나리오와 연결된다. 5초 홀드의 설정 초기화는 앞서 말한 무인증 상태로의 회귀를 뜻한다. 10초 홀드의 CAP 모드는 장비를 CAPsMAN 중앙 관리 서버를 찾는 상태로 전환하는데, 이는 신뢰되지 않은 네트워크에서 악의적 관리 서버에 장비가 붙을 여지를 열 수 있다. 15초 홀드의 Netinstall 모드는 포트 1을 통한 TFTP 재설치 상태로, 이 경로로 임의 펌웨어를 밀어 넣는 시나리오가 성립한다. 전원 인가 전 홀드로 진입하는 백업 RouterBOOT는 부트로더 계층의 복구 경로다. 이 네 단계는 모두 정당한 복구 기능이지만, 물리 접근자에게는 논리 통제를 우회하는 네 개의 서로 다른 문이기도 하다. 방어자는 이 문들이 존재한다는 사실 자체를 인지하고, 그에 상응하는 물리 통제를 설계해야 한다.
한 가지 덧붙이면, 물리 통제는 단순히 "장비를 잠근다"에 그치지 않는다. 자산 인벤토리에 각 장비의 물리적 위치, 접근 권한자, 콘솔·리셋 노출 여부를 기록하는 것까지가 물리 통제의 일부다. 어디에 무엇이 있는지 모르는 장비는 통제할 수 없다.
2. 네트워크와 관리 인터페이스 표면
기본 설정 상태 — 가장 넓은 창
RouterOS 장비의 초기 상태는 편의성을 위해 넓게 열려 있다. RB4011의 공개 매뉴얼 기준 기본값을 정리하면 다음과 같다.
| 항목 | 기본값 | 방어 우선순위 |
|---|---|---|
| 관리 IP | 192.168.88.1 | - |
| WebFig 패스워드 | 없음 (자동 로그인) | 최우선 |
| 무선 SSID | "MikroTik" | 중 |
| 무선 패스워드 | 없음 | 최우선 |
| 무선 AP | 활성화 | 중 |
| 인터넷 포트(1) | 외부에서 Winbox/SSH 차단 | 완화됨 |
| DHCP 서버 | 활성화 | - |
여기서 가장 중요한 사실은 초기 WebFig에 패스워드가 없고 자동 로그인된다는 점이다. 무선 AP도 활성화되어 있고 무선 패스워드도 없다. 두 조건이 겹치면, 장비를 처음 켠 직후에는 무선 범위 내 누구나 관리 인터페이스에 도달할 수 있다는 뜻이다.
다행히 MikroTik은 인터넷 포트(포트 1)에서는 기본적으로 Winbox와 SSH를 차단해, 갓 개봉한 장비를 WAN에 바로 물려도 외부에서 관리 평면이 즉시 노출되지는 않도록 완화 장치를 둔다. 그러나 이것은 한 겹의 방어일 뿐이다. 방어자가 해야 할 첫 조치는 명확하다 — 개봉 즉시, 인터넷에 연결하기 전에 관리자 패스워드를 설정하고 무선 보안을 구성한다.
관리 인터페이스 목록
RouterOS는 여러 관리 채널을 동시에 제공한다. 각각이 독립적인 인증·프로토콜을 갖는 별개의 문이다.
| 인터페이스 | 프로토콜/포트 | 기본 활성 | 방어 메모 |
|---|---|---|---|
| WebFig | HTTP (80) | 활성 | 초기 무인증. HTTPS로 전환·접근 제한 |
| Winbox | TCP 8291 (MAC 계층 포함) | 활성 | MAC 주소로 LAN에서 도달 가능 |
| SSH | TCP 22 | 활성 | 키 인증 권장, 소스 IP 제한 |
| Telnet | TCP 23 | 버전별 상이 | 평문 — 비활성화 |
| API | TCP 8728/8729 | 설정 가능 | 미사용 시 비활성화 |
| FTP | TCP 21 | 설정 가능 | 미사용 시 비활성화 |
Winbox는 특히 주의가 필요하다. TCP 8291 외에 MAC 계층 탐색을 지원하므로, IP를 잘못 설정해 L3 연결이 끊긴 상태에서도 같은 L2 세그먼트라면 관리 접근이 가능하다. 이는 운영자에게는 편리한 복구 경로지만, 방어 관점에서는 "IP 방화벽 규칙만으로는 Winbox 접근을 완전히 막지 못한다"는 뜻이다. 관리 트래픽은 별도 VLAN으로 격리하고, 물리적으로 신뢰된 세그먼트에서만 관리 인터페이스에 도달하도록 설계하는 것이 정석이다.
Telnet과 평문 프로토콜은 원칙적으로 비활성화한다. 사용하지 않는 API·FTP도 마찬가지다. 꺼진 서비스는 공격 표면이 아니다 — 가장 확실한 하드닝은 불필요한 것을 끄는 것이다.
방어 체크리스트로 정리
관리 인터페이스 하드닝의 핵심을 순서대로 정리하면 다음과 같다.
- 개봉 직후 관리자 패스워드 설정 — 무인증 WebFig 창을 즉시 닫는다.
- 불필요한 서비스 비활성화 — Telnet, FTP, 미사용 API, 미사용 무선 라디오.
- 관리 평면 격리 — 관리 트래픽을 별도 VLAN/인터페이스로 분리하고, WAN 측에서 모든 관리 인터페이스를 차단.
- 소스 IP 제한 — SSH·Winbox 접근을 신뢰된 관리 대역으로 제한.
- 암호화 전환 — WebFig는 HTTPS, 셸은 SSH 키 인증.
- 물리 접근 통제 — 콘솔·리셋 버튼이 있는 장비는 잠긴 공간에.
이 목록에 새로운 것은 없다. 그러나 SOHO 라우터 사고의 대부분은 이 기본기를 건너뛴 데서 발생한다.
무선 규제 정보가 방어에 주는 단서
RB4011의 공개 무선 인증 정보(FCC/IC/CE)는 언뜻 규제 서류처럼 보이지만, 방어자에게는 장비의 물리적 무선 표면을 정확히 이해하는 자료다. 공개 인증 문서에 따르면 이 장비의 5GHz 라디오는 U-NII-1부터 U-NII-3까지 여러 대역에서 동작하며, 그중 U-NII-2A(52605320 MHz)와 U-NII-2C(55005720 MHz) 대역은 DFS(Dynamic Frequency Selection) Master 기능과 TPC(Transmit Power Control)를 요구한다. DFS는 본래 레이더 간섭 회피를 위한 규제 요건이지만, 방어 관점에서 보면 장비가 어떤 주파수 대역에서 실제로 방출하는지를 알려주는 지도다.
무선 표면을 방어하려면 먼저 "우리 장비가 어느 대역에서, 얼마의 출력으로 방출하는가"를 알아야 한다. 공개 인증 정보는 이 질문에 답을 준다 — 예컨대 2.4GHz 모듈이 최대 1.0W, 5GHz 대역이 대역별로 수십에서 수백 mW 범위에서 동작한다는 사실은, 신호 커버리지의 대략적 반경을 가늠하게 한다. 커버리지가 넓다는 것은 곧 물리적으로 의도한 경계 너머까지 무선 진입점이 열려 있을 수 있다는 뜻이다. 또한 FCC/IC/EU가 공통으로 요구하는 안테나 이격 거리(최소 20cm)나 특정 5GHz 대역의 실내 전용 제약 같은 정보는, 장비를 물리적으로 어디에 어떻게 배치할지 결정하는 데 참고가 된다.
방어자가 규제 문서에서 취할 실천은 다음과 같다. 실제로 사용하지 않는 무선 대역과 라디오는 비활성화하고, AP의 물리적 위치와 출력을 필요한 커버리지에 맞춰 조정하며, 무선 경계가 조직의 물리적 경계와 일치하는지 점검한다. 규제 문서는 공격자가 아니라 방어자가 더 잘 활용할 수 있는 공개 자료다.
3. 공개 CVE 타임라인 — CVE-2023-32154 회고
이제 이미 공개되고 패치된 취약점 하나를 방어자 관점에서 회고한다. 이것은 벤더가 이미 수정 배포를 마친 사안이며, 여기서는 익스플로잇 방법이 아니라 왜 이 버그가 오래 살아남았고 방어자가 무엇을 배워야 하는가에 집중한다.
사건 개요
| 항목 | 내용 |
|---|---|
| 대회 | Pwn2Own Toronto 2022 |
| 카테고리 | SOHO Smashup |
| 연구팀 | DEVCORE (Angelboy, NiNi) |
| 시연 표적 | MikroTik RB2011UiAS-IN → Canon 프린터 |
| CVE | CVE-2023-32154 |
| CVSS | 7.5 (High) |
| 공개 패치일 | 2023-05-19 |
| 상금 | $100,000 |
주목할 점: 시연 표적은 RB2011이지 RB4011이 아니다. 그런데도 이 사례가 RB4011 리뷰의 참조점이 되는 이유는, 두 모델이 동일한 RouterOS 코드베이스를 공유하기 때문이다. 라우터의 취약점은 종종 특정 하드웨어가 아니라 공통 펌웨어 로직에 존재한다. 방어자에게 이것은 중요한 인벤토리 교훈이다 — "우리 모델이 시연 대상이 아니었으니 안전하다"는 가정은 위험하다. 같은 OS를 돌리는 형제 모델이 공유하는 결함일 수 있다.
취약점의 성격 (개념 수준)
이 CVE는 RouterOS의 IPv6 라우터 광고(Router Advertisement) 처리 경로에 있던 메모리 안전성 결함이다. 공개된 ZDI 어드바이저리(ZDI-23-710)와 DEVCORE의 공식 회고에 따르면, RDNSS(Recursive DNS Server) 옵션의 길이 필드를 충분히 검증하지 않은 채 처리한 것이 근본 원인이다. 입력 필드의 길이 값을 신뢰한 채 복사하는 전형적인 파서 결함 유형이다.
방어자가 여기서 얻을 교훈은 익스플로잇 기법이 아니라 도달 조건이다. 공개 자료에 따르면 이 결함이 문제가 되려면 IPv6 패키지가 활성화되어 있어야 하고, 공격자가 피해 장비와 IPv6 라우터 광고를 주고받을 수 있는 위치에 있어야 한다. 이것은 방어 설계에 직접 연결되는 정보다.
왜 9년이나 잠복했나
공개 회고에서 가장 교훈적인 부분은 이 결함이 약 9년(RouterOS v6 계열 이래)간 발견되지 않았다는 사실이다. 공개된 원인 분석을 방어자 언어로 정리하면 다음과 같다.
| 요인 | 방어자 관점 해석 |
|---|---|
| IPv6 기본 비활성 | 기본 꺼진 기능이라 실제 노출 사례가 드물어 관심 밖에 있었다 |
| 위협 모델 누락 | WAN 측 ICMPv6 RA 처리가 내부망 중심 위협 모델에서 빠져 있었다 |
| 코드 가시성 낮음 | 벤더 고유 구현이라 오픈소스 정적 분석 도구의 커버리지 밖이었다 |
| 스캐닝으로 안 잡힘 | 특정 활성화 조건과 L2 도달성이 필요해 광역 인터넷 스캔으로는 탐지 불가 |
이 네 가지는 "기본 비활성 기능은 안전하다"는 착각의 위험성을 정확히 보여준다. 기능이 꺼져 있어 관심을 덜 받는 코드일수록 검토가 부실해지고, 어쩌다 켜졌을 때 오래된 결함이 그대로 노출된다. 방어자는 자산에서 실제로 켜져 있는 기능이 무엇인지 정확히 알아야 하며, "쓰지도 않는데 켜져 있는" 기능이야말로 우선 점검 대상이다.
방어자를 위한 실천 항목
이미 패치된 사안이지만, 회고에서 도출되는 방어 원칙은 지금도 유효하다.
- 펌웨어를 최신으로 유지한다. RB4011은 공장 출하 시 RouterOS v6 계열이 설치되어 있을 수 있다. 개봉 후 최신 안정 버전으로 갱신하는 것이 첫 조치다. CVE-2023-32154 역시 갱신하면 해소된다.
- 쓰지 않는 프로토콜 스택을 끈다. IPv6를 실제로 사용하지 않는다면 해당 패키지를 비활성화한다. 도달 조건 자체를 없애는 것이 가장 강한 완화다.
- 관리·라우팅 프로토콜 트래픽을 경계에서 통제한다. 신뢰되지 않은 세그먼트에서 오는 라우터 광고·라우팅 프로토콜 메시지를 경계에서 필터링한다. 길이 신뢰형 파서 결함은 RDNSS 하나에만 국한된 유형이 아니므로, 이웃 프로토콜(DHCPv6, MLD, OSPFv3 등)에 대해서도 같은 경계 통제 원칙을 적용한다.
- 형제 모델까지 인벤토리에 포함한다. 같은 RouterOS를 돌리는 다른 MikroTik 장비가 조직에 있다면, 하나의 CVE 공지를 전체 자산에 매핑한다.
Pwn2Own이라는 공개 창구의 가치
방어자 관점에서 Pwn2Own 같은 공개 대회의 존재 자체가 하나의 자산이다. 연구자가 결함을 시연하면 벤더에게 조율된 공개(coordinated disclosure) 절차로 전달되고, 패치가 배포된 뒤 어드바이저리가 공개된다. CVE-2023-32154의 경우 2022년 12월 시연 → 2023년 5월 패치 → 어드바이저리 공개의 흐름을 거쳤다. 방어자는 이 공개 창구를 모니터링해 자신의 자산군에 해당하는 공지를 조기에 포착할 수 있다. 벤더 보안 공지, ZDI 어드바이저리, 대회 결과 발표는 자산 인벤토리와 연결해 두면 강력한 조기 경보 채널이 된다.
조율된 공개의 흐름을 방어자 관점에서 다시 보면, 그 안에는 방어자가 대응할 시간 창이 내장되어 있다. 시연 시점과 패치 배포 사이, 그리고 패치 배포와 조직이 실제로 적용하는 시점 사이에 각각 노출 구간이 존재한다. 벤더가 패치를 냈다고 해서 조직의 자산이 자동으로 안전해지는 것은 아니다 — 패치는 배포되는 것이 아니라 적용되는 것이다. 이 두 구간을 줄이는 것이 방어 운영의 핵심이다. 벤더 공지 채널을 구독하고, 자산 인벤토리와 CVE를 자동으로 대조하고, 패치 적용을 정례화된 절차로 운영하는 것 — 이 셋이 노출 창을 좁힌다.
또한 공개 대회의 회고 자료는 그 자체로 위협 인텔리전스다. CVE-2023-32154의 DEVCORE 회고는 단순히 "버그가 있었다"가 아니라 "왜 9년간 숨어 있었는가"를 분석했고, 그 분석에서 방어자는 자기 환경의 유사한 사각지대를 점검할 단서를 얻는다. 기본 비활성 기능, 벤더 고유 구현, 위협 모델에서 누락된 경로 — 이런 패턴은 MikroTik에만 있는 것이 아니다. 다른 벤더의 다른 장비에도 같은 종류의 사각지대가 존재할 수 있다. 한 사건의 회고를 자기 환경의 점검 항목으로 번역하는 것이 위협 인텔리전스를 소비하는 성숙한 방식이다.
맺음말
RB4011은 잘 만들어진 하드웨어지만, 여느 SOHO 라우터와 마찬가지로 보안은 사양이 아니라 운영에서 결정된다. 이 회고에서 반복된 원칙을 요약하면 다음과 같다.
- 넓은 기본 상태를 개봉 즉시 좁힌다 — 패스워드, 무선 보안, 불필요한 서비스.
- 관리 평면을 격리하고 경계에서 통제한다 — Winbox의 MAC 계층 도달성까지 고려해서.
- 물리 접근을 논리 통제만큼 중요하게 다룬다 — 콘솔과 리셋 버튼이 있다면.
- 펌웨어를 갱신하고 형제 모델까지 인벤토리에 넣는다 — CVE는 하드웨어가 아니라 공통 OS를 노린다.
- 쓰지 않는 기능을 끈다 — 9년 잠복 버그의 교훈은 "잠자는 기능이 가장 위험하다"였다.
이 글이 다룬 모든 내용은 공개된 사양서, 벤더 보안 공지, 그리고 이미 패치·공개된 CVE에서 나왔다. 방어의 대부분은 비밀이 아니라 이미 공개된 정보를 자기 자산에 성실히 매핑하는 규율에서 나온다.
참고 자료
- MikroTik 공식 보안 공지: CVE-2023-32154 — https://mikrotik.com/supportsec/cve-2023-32154/
- Zero Day Initiative 어드바이저리 ZDI-23-710 — https://www.zerodayinitiative.com/advisories/ZDI-23-710/
- DEVCORE 공식 회고: "A 9-year-old bug in MikroTik RouterOS" — https://devco.re/blog/2024/05/24/pwn2own-toronto-2022-a-9-year-old-bug-in-mikrotik-routeros-en/
- MikroTik RB4011 제품 사용자 매뉴얼 (공개 사양)
- FCC/IC/CE 무선 인증 공개 문서