스크립트 한 줄에 공백 하나 더 — MikroTik RouterOS가 인자 경계를 잘못 읽은 자리(CVE-2026-86060)

이미지 출처: CISA KEV

작은 사무실이나 원룸 건물 배전반을 열어 보면 열 중 서넛은 하얀 MikroTik 장비가 들어앉아 있음. 가격이 착하고 RouterOS 기능이 웬만한 엔터프라이즈 장비 못지않다 보니 국내 소규모 ISP, 학원, 카페, 그리고 홈랩 유저들까지 폭넓게 쓰는 물건임. 그런데 이 장비의 운영체제인 RouterOS에서 명령어 인자 구분자를 제대로 무력화하지 못하는 취약점이 CVE-2026-86060으로 등록됐음. 분류는 CWE-88, 풀어 쓰면 "명령 안의 인자 구분자를 부적절하게 중화함"임. 이름만 보면 지루한 문자열 처리 문제 같지만, 라우터라는 위치를 생각하면 절대 가볍게 넘길 수 없는 유형이라 정리해 둠.

핵심 요약

• RouterOS가 사용자 입력을 내부 명령의 인자로 넘길 때 공백·따옴표·옵션 접두어 같은 구분자를 걸러내지 못해, 입력 하나가 여러 개의 인자나 옵션으로 쪼개져 해석될 수 있는 문제임(CWE-88).
• 일반적인 명령 인젝션(CWE-78)과 달리 새 명령을 끼워 넣는 게 아니라 기존 명령의 동작을 옵션 추가로 비틀어 버리는 방식이라 필터 우회가 쉽고 눈에 잘 안 띔.
• 대응의 핵심은 관리 인터페이스 노출 차단, 벤더 패치 적용, 스크립트·API 입력 검증, 그리고 로그에서 비정상 인자 패턴을 찾는 탐지 룰임.

1. 인자 구분자 인젝션이 뭔지부터 잡고 가기

많은 분들이 "명령 인젝션"이라고 하면 세미콜론이나 파이프로 뒤에 새 명령을 붙이는 그림을 떠올리실 텐데, CWE-88은 그것과 결이 조금 다름. 프로그램이 내부적으로 어떤 명령을 실행하면서 사용자 입력을 인자 하나로 넘긴다고 가정해 보면, 개발자는 입력이 "값 하나"라고 믿지만 실제로는 공백이나 따옴표, 혹은 -나 = 같은 옵션 표시가 들어가면 명령 파서가 그것을 "값 하나"가 아니라 "값 + 추가 옵션"으로 읽어 버림. 예를 들어 파일 이름을 받아 어딘가로 복사하는 기능이 있다고 치면, 파일 이름 자리에 옵션처럼 생긴 문자열이 들어가는 순간 복사 명령의 동작 자체가 바뀌는 식임.

이 유형이 방어자 입장에서 특히 골치 아픈 이유는 세 가지임.

• 새 명령이 등장하지 않음. 세미콜론·백틱·파이프 같은 흔한 인젝션 문자를 막아 놓은 필터를 그대로 통과하는 경우가 많음.
• 로그에 남는 흔적이 정상 요청과 비슷함. 실행된 명령 이름은 그대로고 인자만 조금 이상할 뿐이라, 명령 이름 기반의 탐지 룰로는 잡기 어려움.
• 영향 범위가 명령마다 다름. 어떤 명령에 붙느냐에 따라 파일 쓰기, 설정 변경, 권한 상승까지 결과가 달라져서 "이 정도면 괜찮겠지"라고 단정하기 어려움.

2. RouterOS에서 왜 문제가 되는가

RouterOS는 CLI 터미널, WebFig, WinBox, REST API, 그리고 내장 스크립트 엔진까지 사용자 입력이 들어오는 통로가 여러 개임. 그리고 그 입력 상당수가 결국 내부의 명령 처리기로 넘어감. 스케줄러에 등록한 스크립트, 넷워치(Netwatch)가 호스트 상태 변화 때 실행하는 명령, DHCP 리스 스크립트, 핫스팟 로그인 처리 같은 기능은 하나같이 외부에서 들어온 값(호스트명, 인터페이스 이름, 사용자명, 코멘트 등)을 명령 인자에 끼워 넣는 구조임. 이런 곳에서 구분자를 걸러내지 않으면, 공격자가 자기 통제 아래 있는 값(예를 들어 DHCP로 보내는 클라이언트 호스트명이나 핫스팟 사용자명)에 인자처럼 생긴 문자열을 넣어 두는 것만으로 관리자가 짜 둔 스크립트가 엉뚱한 옵션을 달고 돌아가게 만들 수 있음.

이 글에서는 어떤 문자열을 넣으면 어떻게 되는지 구체적인 페이로드는 다루지 않음. 개념만 짚자면, "내가 넣은 값이 값으로만 남지 않고 명령 옵션으로 승격되는 순간"이 이 취약점의 본질이고, RouterOS에서 그 승격이 가능한 지점이 있었다는 게 이번 CVE의 내용임. 정확히 어떤 버전대가 영향을 받는지, 점수가 몇 점인지는 벤더 공지와 NVD 페이지를 기준으로 확인하시는 게 맞고, 여기서는 "네 장비가 RouterOS면 일단 해당한다고 가정하고 점검하라"는 쪽으로 이야기하겠음.

3. 우리 장비가 위험한지 판단하는 순서

개인적으로는 아래 순서로 보시는 걸 추천함. 패치가 나왔다고 무작정 올리기 전에 노출면부터 줄이는 게 먼저인 경우가 많기 때문임.

• 관리 인터페이스가 어디에 열려 있는지 확인. /ip service print로 www, www-ssl, api, api-ssl, winbox, ssh, telnet 중 무엇이 살아 있고 어느 주소 대역에 허용돼 있는지 봄. WAN 쪽에서 WebFig나 API가 보이면 그 자체가 이미 문제임.
• 스크립트·스케줄러·넷워치 목록 점검. /system script print, /system scheduler print, /tool netwatch print에서 외부 입력을 변수로 받아 명령에 넣는 스크립트가 있는지 찾음. 특히 $hostname, $user, 코멘트 값 같은 걸 그대로 문자열 결합하는 패턴이 있으면 표시해 둠.
• 핫스팟·DHCP·PPP 스크립트. on-login, on-lease, on-up 같은 이벤트 훅에 걸린 스크립트는 공격자가 값을 마음대로 주입할 수 있는 대표적인 입구라 따로 봄.
• 버전과 채널 확인. /system package update print로 현재 버전과 채널(long-term, stable)을 확인하고 벤더 체인지로그에 이 CVE 대응이 들어간 빌드인지 대조함.

4. 완화 조치 — 패치 전과 후

패치를 바로 올릴 수 있으면 올리는 게 답이지만, 현장 장비는 재부팅 창을 잡기 어려운 경우가 많아서 패치 전에도 할 수 있는 것과 패치 후에도 유지해야 하는 것을 나눠 적음.

• 관리 포트 접근 제한. /ip service set www-ssl address=관리대역 같은 식으로 관리 서비스마다 허용 주소를 못 박고, 쓰지 않는 서비스(telnet, ftp, 평문 www, api)는 disable함. 방화벽 input 체인에도 같은 정책을 이중으로 걸어 두면 서비스 설정을 실수로 풀어도 한 겹이 남음.
• 스크립트 입력을 값으로 고정. 외부 값을 명령에 넣을 때는 문자열 결합 대신 RouterOS 스크립트의 변수 전달 방식을 쓰고, 값에 공백·따옴표·= 등이 들어오면 그냥 버리거나 치환하는 검증 단계를 넣음. 특히 hostname과 comment는 길이와 허용 문자를 화이트리스트로 제한하는 게 좋음.
• 권한 분리. 자동화용 API 계정은 full 그룹이 아니라 필요한 정책만 가진 별도 그룹으로 만들고, 스크립트 실행 권한(policy)도 필요한 것만 남김. 인자 하나가 비틀려도 그 계정이 할 수 있는 일이 작으면 피해가 작음.
• 패치 적용. 벤더가 수정 빌드를 내놓은 채널로 올리고, 업그레이드 뒤에는 RouterBOOT(펌웨어)도 함께 올려 둠. 올리기 전 /export로 설정 백업을 받아 두는 건 기본임.
• 패치 후에도 유지. 위 접근 제한과 입력 검증은 패치와 무관하게 계속 두는 게 맞음. 같은 유형의 취약점은 다른 명령, 다른 경로에서 또 나올 수 있기 때문임.

5. 탐지 — 로그에서 무엇을 봐야 하나

이 유형은 명령 이름으로는 못 잡는다고 했으니, 인자의 모양을 보는 룰이 필요함. RouterOS 로그를 syslog로 원격 수집하고 계신다면 아래 관점으로 룰을 짜 보시는 걸 권함.

• 이벤트 훅 실행 로그의 변수 값에 구분자가 섞인 경우. DHCP 리스, 핫스팟 로그인, PPP 세션 로그에서 hostname·username 필드에 공백, 따옴표, =, 선행 -가 들어간 항목은 그 자체로 이상 징후임. 정상 클라이언트가 그런 이름을 쓰는 일은 거의 없음.
• 스크립트 실행 실패·경고 급증. 인자가 깨지면 명령이 문법 오류로 죽는 경우가 많아서, script 토픽의 error 로그가 갑자기 늘면 누가 찔러보고 있을 가능성이 있음.
• 설정 변경 이벤트와 로그인 이벤트의 불일치. 관리자 로그인 없이 system 토픽에 설정 변경(changed by ...)이 찍히면 스크립트 경로로 무언가 바뀐 것이므로 즉시 확인 대상임.
• 관리 포트 접근 시도. 방화벽 input 체인에서 관리 포트로 들어온 외부 IP를 별도 로그 접두어로 남겨 두면, 취약점 공개 이후 스캔이 늘어나는 흐름을 눈으로 볼 수 있음.

로그를 아직 안 모으고 계시다면 이번 기회에 /system logging action에 원격 syslog 하나 추가하는 것부터 해 보셨으면 함. 장비 안에서만 도는 로그는 재부팅 한 번에 사라지고, 침해 후 조사할 때 가장 아쉬운 게 그 부분임.

6. 정리하며

MikroTik은 예전에도 관리 인터페이스 쪽 취약점이 나올 때마다 국내외에서 대규모로 털린 전례가 있음. 이유는 취약점 자체보다 인터넷에 관리 포트를 열어 둔 장비가 너무 많아서였음. 이번 CVE-2026-86060도 인자 처리라는 다소 기술적인 결함이지만, 결국 공격자가 값을 밀어 넣을 수 있는 통로가 열려 있어야 성립함. 그러니 패치 여부와 별개로 오늘 당장 관리 포트 노출부터 닫고, 스크립트에서 외부 값을 그대로 명령에 끼워 넣는 부분이 있는지 한 번씩만 훑어보셨으면 함. 저도 홈랩 장비 넷워치 스크립트를 이 글 쓰면서 다시 열어 봤는데, 코멘트 값을 검증 없이 쓰는 부분이 있어서 고쳤음. 여러분 장비에서도 비슷한 게 나오면 댓글로 공유해 주세요. 같이 하나씩 닫아 나가 보아요.