MikroTik SSH 취약점, 비밀번호 없어도 공유기가 넘어간다

9월 5일에 확정된 것과 아직 숫자로 안 나온 것

MikroTik SSH 취약점 이야기는 제조사 공지와 CERT 공개가 이틀 어긋납니다. MikroTik은 2026년 9월 3일 보안 게시판에서 “RouterOS에서 보안 취약점을 찾았고 모든 채널에 수정본을 냈다”고만 적었습니다. 당시에는 CVE 번호와 공격 방식을 공개하지 않았습니다. 이용자에게 시간을 주려는 조치라고 밝혔습니다. 같은 업데이트에서 MikroTik 앱을 설치한 휴대폰으로 푸시 알림을 보낸 것은 제조사 역사상 처음이라고 CERT가 적었습니다.

세부 내용은 9월 5일 CERT Polska 글에서 나왔습니다. 팀이 RouterOS에서 취약점 6건을 찾고 공개를 조율했으며, 그중 SSH 인증 우회(CVE-2026-67276)와 조작된 사용자 이름으로 권한을 올리는 결함(CVE-2026-86060)을 이어 쓰면 장비를 통째로 잡을 수 있다고 했습니다. 이 조합의 이름이 MikroTrick입니다. CERT는 “최근 며칠 인터넷에 열린 RouterOS를 향한 공격을 보고 있고, SSH가 공인망에 노출된 장비를 이 조합으로 완전 장악하는 것을 확인했다”고 썼습니다. 패치가 그 관찰된 공격을 막는다는 점도 같이 적었습니다.

여기서 빠진 것도 분명합니다. 피해자 수, 국가별 분포, 한국 경보, 공격 조직 이름은 CERT와 MikroTik 공식문에 없습니다. 일부 보안 기사가 Shodan 기준으로 약 30만 대를 거론하지만, 그 숫자는 공식 원출처가 아닙니다. “이미 전 세계가 뚫렸다”는 문장과 “가정용은 볼 필요 없다”는 문장 모두 근거가 부족합니다. 확인할 대상은 내 장비의 SSH가 인터넷에서 닿는지, 버전이 수정본 미만인지입니다.

기본 방화벽 가정용과, 포트를 열어 둔 장비는 위험이 다릅니다

MikroTik은 보안 공지에서 “일반 가정용 이용자에게 이 문제는 즉시 위험이 되지 않지만, 그래도 업데이트를 권한다”고 적었습니다. 기본 방화벽이 유지된 가정용 구성에서는 WAN 쪽 관리 포트가 막혀 있다는 설명도 포럼·공지에 반복됩니다. 즉 공장 설정에 가깝고, 외부에서 22번 포트로 접속할 수 없다면 MikroTrick의 전제 조건이 성립하지 않습니다.

위험이 커지는 구성은 따로 있습니다. 매장·사무실에서 외근 관리를 위해 SSH나 Winbox, 웹 설정을 공인 IP에 열어 둔 경우, 클라우드에 가까운 소호 라우터에 DST-NAT로 22번을 넘긴 경우, 기본 방화벽을 지우고 “일단 접속되게” 만든 경우입니다. 국내에서 자주 보는 형태는 원룸·상가에 둔 RB·hAP를 집에서도 만지려고 통신사 공인 IP에 포트를 열어 둔 구성, 작은 호스팅 앞단, 현장 카메라·출입 장비를 한 대의 RouterOS 뒤로 모은 구성입니다. CERT가 임시 완화로 적은 대상도 SSH, WWW/WWW-SSL, bandwidth-test입니다. 세 서비스가 신뢰할 수 없는 망에서 열려 있으면 업데이트 전까지라도 막으라고 했습니다.

밖에서 SSH가 보이는지 확인하는 가장 안전한 방법은 장비 설정 화면입니다. IP → Services에서 ssh의 포트와 Available From, IP → Firewall에서 input 체인의 22번 허용 규칙, IP → Firewall → NAT의 dst-nat가 WAN 인터페이스의 22번을 내부로 넘기는지를 봅니다. 공인 IP를 검색 엔진의 개방 포트 조회 사이트에 넣는 방식은, 그 조회 자체가 로그를 남기고 잘못된 사이트로 이어질 수 있어 이 글에서는 권하지 않습니다. 통신사 공유기를 앞에 두고 MikroTik이 사설 IP만 받는 이중 공유기라면, 앞단에서 포트포워드를 켰는지만 보면 됩니다.

누구에게 필요한가를 한 줄로 나누면 이렇습니다. 원격 관리를 위해 포트를 연 운영자, 호스팅·VPN 앞단에 RouterOS를 둔 사람, 예전에 방화벽을 직접 고친 사람은 오늘 버전과 로그를 봐야 합니다. 기본 설정의 가정용 hAP만 쓰고 외부 접속을 연 적이 없다면 긴급도는 낮습니다. 그래도 제조사가 업데이트를 권한 이유는, 나중에 포트를 열거나 방화벽 규칙을 실수로 지울 때를 대비하기 때문입니다.

MikroTik SSH 취약점이 비밀번호를 묻지 않는 이유

CERT가 자세히 적은 세 건은 아래와 같습니다. CVSS 값은 CERT 설명문 기준입니다.

같은 날 CERT CVE 목록에는 추가로 CVE-2026-67278(X.509 서명 검증), CVE-2026-67279(인증 전에 SSH 연결 프로토콜로 진입), CVE-2026-67281(WebFig 경로의 초기화되지 않은 포인터)이 올라 있습니다. 현재 실제 공격으로 확인된 조합은 앞의 두 SSH 결함입니다. 나머지 세 건을 “이미 현장에서 쓰인다”고 적으면 공식 범위를 넘습니다.

관찰된 공격의 흔적은 비교적 구체적입니다. CERT는 로그에 failure for user -2 from <ip> via ssh와 user <name> added by ssh:-2@<ip>가 남는다고 했습니다. 성공한 사례에서는 권한이 높은 계정 이름 ops가 생겼습니다. 성공 공격의 출발지로 적힌 주소는 82.192.72.4이고, 시도에 쓰인 주소로 103.102.31.18이 나옵니다. 시점은 적어도 2026년 9월 2일입니다. 공지(9월 5일)와 패치(9월 3일)보다 앞섭니다.

이 흔적이 없다고 끝나지 않습니다. CERT는 “위 흔적이 있으면 즉시 조사해야 하고, 없다고 해서 무단 행위를 배제하지 못한다”고 못 박았습니다. 로그가 순환됐거나, 공격자가 다른 계정 이름을 썼거나, 관리자가 예전에 로그를 지운 경우를 염두에 둔 문장입니다.

내 RouterOS가 해당 버전인지 먼저 가른다

CERT가 취약하다고 적은 범위는 이렇습니다.

버전은 Winbox나 WebFig의 System → Packages, 또는 터미널 /system resource print에서 확인합니다. 업데이트는 System → Packages → Check for Updates가 공식 경로입니다. 설치 파일은 MikroTik 다운로드 페이지에서 채널에 맞는 이미지만 받는 것이 안전합니다. 검색 광고나 mirror 사이트의 .npk는 이번 글의 주제와 별개로, 이전 가짜 설치 파일 캠페인과 겹치면 위험합니다.

장기 채널을 쓰는 사람은 한 가지를 더 보면 됩니다. The Hacker News는 9월 6일 정리에서, 7.23.4가 보안 수정본이지만 IPv6 DHCP 회귀가 있어 장기 채널은 7.23.5를 쓰라고 적었습니다. 보안 하한선은 여전히 7.23.4입니다. 이미 7.23.4를 올렸다면 추가 기능 버그를 제조사 포럼에서 확인한 뒤 최신 장기 빌드로 맞추면 됩니다. 6.x는 MikroTik이 “더 이상 적극 개발하지 않는다”고 포럼에 적어 두었습니다. 보안 수정만 받고 끝낼 장비인지, 7.x로 옮길 장비인지 이번 기회에 나누는 편이 낫습니다.

업데이트 전에 백업은 다른 저장소로 빼 두되, 침해가 의심되면 그 백업을 그대로 되돌리지 마십시오. CERT는 공장 초기화 후 검증된 설정으로 다시 짜라고 했습니다. 전원은 업데이트 중에 끊기지 않게 하고, 패키지 저장 공간이 부족한 구형 보드는 불필요한 패키지를 먼저 지웁니다.

올린 뒤에 볼 로그, Flagged, 계정 목록

수정본을 올린 RouterOS는 시작 때 설정에서 알려진 무단 변경 흔적을 훑습니다. 의심 항목을 비활성화하고, 로그에 critical 메시지를 남기며, Flagged 표시를 켭니다. 확인 명령은 CERT가 지정한 /system/device-mode/print입니다. 로그에 장비가 Flagged 됐다고 나오면 MikroTik의 Flagged 문서 순서를 따릅니다. 표시를 먼저 지우고 보면 증거가 사라집니다.

Flagged가 꺼져 있어도 아래는 손으로 봅니다.

• 사용자 목록에 ops나 기억에 없는 full 권한 계정이 있는지
• 로그에 ssh:-2@, user -2가 있는지
• 스케줄러, 스크립트, 프록시, 터널, DST-NAT, 방화벽 허용 규칙이 언제 생겼는지
• bandwidth-test 서버, WWW, SSH가 어느 인터페이스에서 listen 중인지

업데이트 전에 막을 임시 조치는 패치를 대체하지 않습니다. CERT는 노출된 서비스를 끄거나 관리망만 남기라고 했습니다. 고치지 않은 장비에서 내장 SSH 클라이언트(/system ssh, /system ssh-exec)로 다른 호스트에 붙거나, 신뢰할 수 없는 대상으로 TLS를 열지 말라고도 했습니다. X.509 쪽 결함이 같은 묶음에 들어 있기 때문입니다.

흔적이 있을 때와 없을 때, 다음 조치가 갈린다

Flagged가 켜졌거나 ops, ssh:-2@가 보이면 장비를 네트워크에서 분리하는 것이 먼저입니다. CERT는 초기화 전에 로그와 설정을 보존하라고 했고, 보존 절차는 CERT의 MikroTik 로그·설정 확보 안내를 가리킵니다. 그다음 공장 초기화, 신뢰할 수 있는 설정으로 재구성, 비밀번호·키·VPN preshared key·인증서 교체 순서입니다. 침해 가능성이 있는 전체 백업을 그대로 복원하면 공격자가 넣어 둔 계정과 스크립트가 같이 살아납니다.

관리자 권한을 빼앗긴 공유기에서 실제로 바뀌는 것은 PC 화면이 아닙니다. DNS가 이상한 주소로 바뀌거나, 새 PPTP·L2TP·WireGuard 피어가 생기거나, 스케줄러가 외부 스크립트를 주기적으로 받을 수 있습니다. CERT가 이번 공격의 최종 목적(랜섬웨어, 도청, 봇넷)을 특정하지는 않았습니다. 다만 라우터를 통째로 잡으면 그 아래 있는 PC·휴대폰·NAS의 트래픽을 다른 곳으로 돌릴 수 있다는 점은 구조적으로 같습니다. 그래서 침해가 의심되면 공유기만 고치고 끝내지 말고, 그 공유기 비밀번호와 무선 암호, VPN 키도 함께 바꿉니다.

흔적이 없어도 “패치했으니 끝”으로 두지 않는 편이 낫습니다. 공개 SSH를 닫고, 관리는 WireGuard 같은 VPN 뒤로 옮기며, 관리 포트를 공인 주소에 다시 열지 않는 구성이 MikroTik 공지의 권고와 맞습니다. 비밀번호만 길게 바꾸는 것으로는 CVE-2026-67276을 막지 못합니다. 그 결함은 비밀번호가 아니라 공개키 비교를 건너뛰는 쪽에 있습니다.

한국에서 신고할 공식 창구를 CERT Polska가 지정하지는 않았습니다. 국내 사업장 장비라면 한국인터넷진흥원 신고 체계를 이용하고, 호스팅·MSP 고객 망이면 고객에게 노출 여부와 패치 버전을 같이 알리는 것이 실무적으로 맞습니다. 공격 IP 82.192.72.4, 103.102.31.18을 방화벽에서 차단하는 것은 보조일 뿐입니다. 주소는 바뀔 수 있고, 이미 열린 SSH가 있으면 다른 출발지도 같은 사슬을 쓸 수 있습니다.

지금 할 일과 하지 말아야 할 일

할 일의 순서는 짧습니다. 버전 확인 → 해당하면 수정본 설치 → 로그·계정·Flagged 확인 → SSH·웹·bandwidth-test의 WAN 노출 제거 → 이상 징후가 있으면 분리 후 초기화입니다. 제조사 다운로드와 Check for Updates 외의 경로에서 .npk를 받지 마십시오.

하지 말아야 할 일도 분명합니다. Flagged를 분석 전에 지우기, 침해 의심 장비의 전체 백업을 그대로 복원하기, “가정용이니 무시”로 방화벽을 이미 열어 둔 장비를 건너뛰기, 패치 전에 그 장비에서 다른 장비를 관리하기입니다. 이번 문제는 신제품 출시 소식이 아닙니다. 열려 있는 관리 포트가 있는지만 보면 됩니다.

점검 순서를 한 줄로 고정하면 이렇습니다. ① 버전. ② SSH·웹·bandwidth-test가 WAN에 열려 있는지. ③ 수정본 설치. ④ Flagged와 로그의 -2. ⑤ 모르는 계정·스크립트. ⑥ 이상하면 분리 후 초기화. 이 여섯 칸만 채우면 뉴스 제목보다 장비 상태가 먼저 정리됩니다.

확인일 2026-09-07. 1차 자료: CERT Polska 권고 및 CVE 목록(2026-09-05), MikroTik September 2026 vulnerability 공지(2026-09-03). 보도 대조: The Hacker News 2026-09-06.