라우터가 "누구세요"를 묻지 않았다면 — MikroTik RouterOS CVE-2026-67277 인증 누락, 방어자용 점검 순서

이미지 출처: CISA KEV

2018년 여름을 기억하는 분이라면 MikroTik이라는 이름이 그리 낯설지 않을 것 같다. 그때 Winbox 쪽 취약점 하나로 전 세계 수십만 대의 라우터가 순식간에 코인 채굴 스크립트 배포 장치로 바뀌었고, 국내 소규모 사업장 장비도 꽤 많이 휩쓸렸던 기억이 있음. 그로부터 몇 년이 지나 다시 RouterOS에서 인증 자체가 빠진 관리 기능이 보고됐는데, 이번 번호가 CVE-2026-67277임. 이름부터가 "Missing Authentication for Critical Function", 즉 중요한 기능인데 로그인 절차를 거치지 않아도 닿을 수 있다는 뜻이라 개인적으로는 2018년의 그 장면이 먼저 떠올랐음.

핵심 요약

• MikroTik RouterOS의 특정 관리 기능이 인증 검사 없이 호출될 수 있는 취약점(CWE-306 유형)이 CVE-2026-67277로 등록됨
• 라우터는 네트워크의 관문이라, 인증 없는 설정 변경 하나가 DNS 변조·트래픽 우회·내부망 진입으로 바로 이어질 수 있음
• 대응 순서는 벤더 수정 버전 적용, 관리 서비스 노출 차단, 그리고 이미 바뀐 설정이 없는지 역추적하는 세 단계임

1. 이번 취약점은 어떤 유형인가

취약점 분류로 보면 버퍼 오버플로우나 인젝션처럼 "코드가 잘못 짜여서" 생긴 문제라기보다, 있어야 할 확인 절차가 통째로 빠진 문제임. RouterOS 내부의 어떤 기능이 원래는 로그인한 관리자만 부를 수 있어야 하는데, 그 앞단에서 세션이나 자격증명을 검사하는 단계가 누락되어 있었던 것으로 정리됨. 정확히 어느 서비스의 어떤 기능인지, 영향받는 버전 범위와 수정 버전이 몇인지는 NVD와 MikroTik 공지에 적힌 내용을 기준으로 봐야 하고, 여기서는 "인증 없이 닿을 수 있는 중요 기능"이라는 구조 자체에 집중해서 설명함.

공격 재현을 개념 수준에서만 말하자면, 공격자는 장비의 관리 서비스 포트에 접근 가능한 위치에서 해당 기능을 직접 호출하기만 하면 됨. 비밀번호를 맞출 필요도, 세션을 훔칠 필요도 없음. 그래서 이 유형은 노출 범위가 곧 피해 범위가 되는 편임. 관리 포트가 인터넷에 열려 있다면 전 세계가 사정권이고, 내부망에서만 닿는다면 내부 침해 이후의 횡적 이동 도구가 됨.

2. 왜 라우터에서 이 유형이 유독 아픈가

서버 한 대의 인증 우회는 그 서버가 피해 범위임. 그런데 라우터는 그 뒤에 있는 모든 장비의 트래픽이 지나가는 자리라서, 인증 없이 설정을 만질 수 있다는 건 다음과 같은 일이 한꺼번에 가능해진다는 뜻임.

• DNS 변조 — 내부 사용자 전체를 피싱 페이지로 보내거나 업데이트 서버를 가로챌 수 있음
• 트래픽 우회·도청 — 미러링이나 터널 설정으로 트래픽 사본을 외부로 흘릴 수 있음
• SOCKS·프록시 개설 — 장비를 다른 공격의 중계지로 쓰는 건 2018년에 실제로 대량 발생했던 패턴임
• 스케줄러·스크립트 심기 — 재부팅 뒤에도 살아남는 지속성 확보 수단이 됨
• 방화벽 규칙 완화 — 내부망으로 들어오는 문을 조용히 넓혀둘 수 있음

그러다보니 이 취약점은 "패치하면 끝"이 아니라, 패치 전에 이미 누가 다녀갔는지를 확인하는 게 같이 붙어야 함. 인증 로그가 남지 않는 경로로 들어온 것이라 로그인 실패 기록만 보고 안심하면 안 됨.

3. 탐지 — 무엇을 어디서 볼 것인가

인증을 거치지 않았으니 "누가 로그인했다"는 기록은 기대하기 어려움. 대신 결과물을 봐야 함. 개인적으로는 아래 순서로 훑는 걸 추천함.

• 설정 변경 흔적 — /system history와 로그에서 본인이 기억하지 못하는 변경 시점이 있는지 확인함. 특히 /ip dns, /ip socks, /system scheduler, /system script, /ip firewall 항목의 변경 여부를 우선 봄
• 백업 비교 — 마지막으로 정상이라고 확신하는 export 파일과 현재 /export 결과를 diff로 비교함. 이 방법이 가장 단순하고 확실함
• 관리 포트 접근 기록 — 방화벽 input 체인에 로깅 규칙을 붙여 두었다면 외부 IP에서 관리 서비스 포트로 들어온 연결 시도를 뽑아봄. 없었다면 지금이라도 붙여두는 게 좋음
• 이상 트래픽 — 장비 자체에서 외부로 나가는 낯선 연결(특히 비표준 포트나 알 수 없는 IP로의 지속 세션)이 있는지 /ip firewall connection과 Torch로 살펴봄
• 사용자 계정 — /user에 모르는 계정이 추가되었거나 기존 계정 그룹이 바뀌었는지 확인함

외부에서 보는 관점도 필요함. 자기 회선의 공인 IP로 관리 포트(Winbox, www, api, ssh 등)가 열려 있는지 외부 스캔 도구나 공개 검색엔진으로 한 번 조회해 보면, 생각보다 "나는 닫았다고 믿었는데 열려 있는" 경우가 꽤 있음.

4. 완화 — 순서가 중요함

이런 유형은 우회할 방법을 찾을 필요 없이 그냥 열려 있는 것이라, 완화도 단순하게 가는 게 맞음. 다만 순서를 지키는 게 중요함.

• 첫째, 노출부터 줄임 — 업데이트를 검토하는 동안에도 공격은 진행되니, /ip service에서 쓰지 않는 서비스(telnet, ftp, www, api 등)를 끄고, 남기는 서비스는 address 항목으로 관리용 대역만 허용함. 방화벽 input 체인에서도 관리 포트는 신뢰 대역 외 drop을 기본으로 둠
• 둘째, 벤더가 안내한 수정 버전으로 올림 — 안정(stable)과 장기(long-term) 채널 중 자기 장비가 타는 채널의 수정 버전을 확인하고 적용함. 업그레이드 전 export 백업은 필수임
• 셋째, 관리 경로를 분리함 — 가능하면 관리 접속은 VPN을 통해서만, 혹은 별도 관리 VLAN에서만 가능하도록 구성함. 인터넷에서 바로 Winbox가 열리는 구성은 편하긴 한데, 이번 같은 취약점 앞에서는 그 편함이 그대로 비용이 됨
• 넷째, 3번에서 찾은 흔적을 정리함 — 이상 설정이 있었다면 단순 삭제보다는 깨끗한 백업으로 복원하고, 모든 관리 계정 비밀번호를 교체함
• 다섯째, 다음을 대비함 — export 파일을 주기적으로 저장하고 버전 관리에 넣어두면, 다음에 비슷한 일이 생겨도 "언제부터 뭐가 바뀌었나"를 몇 분 안에 답할 수 있음

5. 학습자 관점에서 남는 것

이 취약점을 보면서 개인적으로 다시 느낀 건, 네트워크 장비 보안은 결국 "관리 인터페이스가 누구에게 보이는가"라는 아주 오래된 질문으로 돌아온다는 점임. 코드 결함은 벤더가 고쳐주지만, 관리 포트를 인터넷에 열어둔 구성은 벤더가 대신 닫아주지 않음. 2018년에도 그랬고, 이번에도 피해 규모를 가르는 건 취약점의 심각도보다 노출된 장비의 수였던 것 같다.

집이나 사무실에 MikroTik 장비가 한 대라도 있다면 오늘 저녁에 딱 세 가지만 해보아요. 외부에서 관리 포트가 보이는지 확인하고, 마지막 export와 지금 설정을 비교해 보고, 수정 버전으로 올리는 것. 시간이 오래 걸리지 않고, 하고 나면 마음이 꽤 편해질 것임. 점검하다가 낯선 설정을 발견했거나 헷갈리는 부분이 있으면 댓글로 남겨 주세요. 같이 들여다보면서 차차 정리해 보아요.