bahirul/cve-2026-86060CVE-2026-86060에 대한 권고문으로, MikroTik RouterOS SSH의 치명적인 사전 인증 권한 상승 취약점에 대한 영향 분석, 탐지 지침, 강화 단계를 다룹니다.
| 필드 | 값 |
|---|---|
| CVE | CVE-2026-86060 |
| 제품 | MikroTik RouterOS (SSH 서비스) |
| 영향받는 버전 | RouterOS 6.x 및 7.0.0 – 7.23.3 (포함) |
| 수정된 버전 | RouterOS 7.23.4 및 이후 |
| 취약점 유형 | 인증 전 권한 상승 (인증 우회 / 접근 제어 결함) |
| 공격 벡터 | 원격, 비인증, SSH 서비스를 통한 공격 |
| 사전 조건 | 없음 — 자격 증명, 사용자 상호작용, 로컬 접근 불필요 |
| 영향 | 라우터의 완전한 관리자(policy) 제어 |
| CVSSv3.1 | 9.8 (치명적) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 확인 환경 | MikroTik CHR 6.49.20 및 7.21.5 (로컬 랩); 제한적인 인터넷 노출 검증도 수행됨 |
비인증 원격 공격자는 SSH 서비스와만 상호작용하여 취약한 MikroTik RouterOS 장치의 완전한 관리자 제어를 획득할 수 있습니다. 자격 증명, 사용자 상호작용, 로컬 접근이 모두 필요하지 않습니다.
완전한 policy를 획득한 후, 공격자는 full 그룹 RouterOS 관리자와 동일한
권한을 갖습니다: 전체 구성 읽기 및 수정, 권한 있는 계정 및 백도어 생성,
서비스 활성화/비활성화, 트래픽 리다이렉션 또는 가로채기, 그리고 장치를
내부 네트워크로 피벗하기 위한 발판으로 사용하는 것이 가능합니다.
6.x 및 7.0.0부터 7.23.3까지 (수정 전까지의 전체 6.x
및 7.x 브랜치).7.23.4 및 이후.이 문제는 로컬 QEMU 기반 랩(MikroTik Cloud Hosted Router)에서 실행되는 공식 CHR 6.49.20 및 CHR 7.21.5 릴리스에 대해 검증되었으며, 제한적인 검증 연구 중 접근한 소수의 인터넷 노출 설치 환경에서도 추가로 확인되었습니다 (세부 사항은 공개하지 않음; 제3자 호스트의 공개는 없음).
| 버전 범위 | 상태 |
|---|---|
| 6.x – 7.23.3 | 취약 |
| ≥ 7.23.4 | 패치됨 — 지금 업그레이드하십시오 |
이 취약점은 RouterOS SSH 서비스의 인증 전 권한 상승으로, 비인증 SSH 클라이언트가 완전한 관리자 policy 마스크를 가진 RouterOS 콘솔 세션에 도달할 수 있게 합니다.
구체적인 메커니즘, 영향을 받는 코드 경로 및 트리거 값은 재현을 방지하기 위해 의도적으로 공개하지 않습니다. 높은 수준의 효과만 설명합니다: 비인증 클라이언트가 유효한 자격 증명 없이 완전한 관리자 policy를 획득할 수 있습니다.
책임 있는 공개 참고: 이 문서는 의도적으로 익스플로잇 코드, 구체적인 트리거 값, 또는 단계별 재현 절차를 공개하지 않습니다. 개념 증명 스크린샷이 제공됩니다(아래 참조); 작동하는 페이로드나 소스 코드는 공개되지 않습니다.
성공적인 공격은 비인증 원격 공격자에게 라우터에 대한 완전한 full 그룹
관리자 권한을 부여합니다. 관찰된 그리고 현실적인 결과:
full 그룹 사용자 및 백도어 생성, 정당한 관리자
잠금.RouterOS 장치는 네트워크 엣지(게이트웨이, VPN 집중기, ISP CPE, 엔터프라이즈 라우터)에 위치하기 때문에, 영향 범위는 일반적으로 단일 침해 호스트보다 훨씬 큽니다.
이 권고를 공개 배포에 안전하게 유지하기 위해, 익스플로잇 코드, 트리거 값, 재현 스크립트는 여기에 공개되지 않습니다.
실험실 검증: 로컬 QEMU/Docker 랩에서 MikroTik CHR 6.49.20 및 7.21.5
에 대해 확인되었습니다. 증명은 읽기 전용/비인증 세션에서는 불가능한 쓰기
작업(full policy 사용자의 생성 및 이후 제거)을 보여주었습니다 — 완전한
관리자 policy가 인증 전에 획득되었습니다.
개념 증명 스크린샷:
이 문제는 RouterOS 7.23.4 및 이후에서 수정되었습니다.
먼저 구성을 백업하십시오:
/system backup save name=backup-before-upgrade
/export file=export-before-upgrade
일반 채널을 통해 업그레이드하십시오:
System → Packages → Check for updates (또는 라우터
아키텍처에 맞는 routeros-<version>.npk 업로드).업그레이드 후 실행 중인 버전을 확인하십시오:
/system resource print
그런 다음에만 외부 인터페이스에서 SSH를 다시 활성화하는 것을 고려하십시오 (아래 참조).
우회 방법보다 패치를 선호하십시오. 버전 업데이트만이 완전한 수정입니다. 아래 우회 방법은 노출을 줄이지만 근본적인 결함을 제거하지는 않습니다.
즉시 업그레이드할 수 없는 장치 — 그리고 패치된 장치에 대한 심층 방어로서:
방화벽에서 SSH 노출을 제한하십시오. SSH를 인터넷이나 신뢰할 수 없는 네트워크에 노출하지 마십시오. 신뢰할 수 있는 소스 주소만 허용하십시오:
/ip firewall filter
add chain=input protocol=tcp dst-port=22 src-address=192.168.1.0/24 \
action=accept place-before=1
add chain=input protocol=tcp dst-port=22 action=drop place-before=2
필요하지 않은 곳에서는 SSH를 완전히 비활성화하십시오. Winbox, WebFig 및 API는 관리에 종종 충분합니다; 원격 CLI 접근을 노출해야 하는지 고려하십시오:
/ip service disable ssh
강력한 인증을 요구하십시오. SSH를 활성화된 상태로 유지해야 하는 경우:
/user ssh-keys import user=<admin> public-key-file=<file>.admin 계정)를 절대 사용하지 마십시오.관리를 VPN / 분리된 관리 네트워크 뒤에 두십시오. 직접 노출 대신 신뢰할 수 있는 네트워크나 VPN을 통해 관리 접근을 라우팅하십시오; 이는 SSH, Winbox (8291), WebFig/HTTP (80/443), RouterOS API (8728/8729) 및 모든 사용자 지정 SSH 포트(3333, 2222, 8022 및 기타 일반적인 재지정 포트가 자주 사용됨)에 적용됩니다.
침해 지표를 모니터링하고(아래 탐지 참조) 인증 및 구성 이벤트의 로깅을 활성화하십시오.
펌웨어를 최신 상태로 유지하고 MikroTik 보안 권고를 구독하십시오: https://mikrotik.com/support/security.
이 취약점이 장치에서 시도되거나 악용되었을 수 있는 징후:
full 그룹), 접근을 여는
새로운 방화벽 규칙, 변경된 서비스, 예상치 못한 백도어 계정./system identity, DNS 설정, 또는
라우팅/방화벽 규칙.실행 중인 장치에서 유용한 점검:
# list users and look for accounts you did not create
/user print detail
# check the log for unusual SSH activity
/log print where topics~"ssh"
이 문서는 방어 및 교육 목적으로 공개됩니다 — MikroTik 장치 관리자가 노출을 평가하고, 패치 상태를 확인하고, 배포를 강화할 수 있도록 하기 위함입니다. 익스플로잇 세부 사항은 의도적으로 공개되지 않으며, 작동하는 익스플로잇은 공개되지 않습니다. 소유하거나 평가 권한이 있는 시스템만 테스트하십시오.