온프렘 오케스트레이터가 셸을 내주면 SD-WAN 전체가 따라간다 (Arista VeloCloud CVE-2026-16812)

이미지 출처: CISA KEV

지사 라우터 한 대가 멈추면 그 지사만 조용해진다. 그런데 그 라우터 수백 대에게 "너는 이 정책, 너는 저 경로"라고 매일 지시하는 서버가 어느 순간 남의 명령을 대신 실행하기 시작하면, 조용해지는 건 지사 하나가 아니게 됨. Arista VeloCloud Orchestrator On-Prem에서 보고된 OS 명령 주입 결함 CVE-2026-16812를 봐야 하는 이유가 딱 여기 있음.

핵심 요약

• VeloCloud Orchestrator(VCO)는 SD-WAN의 관제탑이라, 여기서 OS 명령이 실행되면 엣지 전체의 설정·인증정보까지 사정권에 들어감
• 명령 주입은 대개 진단·백업·인증서 같은 "시스템 도구를 호출하는 기능"에서 성립하므로, 탐지는 웹 서비스 계정이 셸이나 네트워크 유틸을 자식 프로세스로 띄우는 순간을 보는 게 가장 빠름
• 패치가 1순위지만, 관리 평면을 인터넷에서 떼어내고 아웃바운드를 막아두는 구조가 있으면 같은 결함이 또 나와도 피해 폭이 확 줄어듦

1. 온프렘 오케스트레이터라는 자리의 무게

VeloCloud는 SaaS로도 쓰지만, 규제나 내부 정책 때문에 자체 데이터센터에 올려 쓰는 On-Prem 구성이 꽤 많음. 문제는 이 On-Prem 오케스트레이터가 단순한 대시보드가 아니라는 점임.

• 엣지 장비의 설정 템플릿을 만들고 일괄 배포하는 주체임
• 사이트 간 터널을 맺기 위한 키·인증서·활성화 토큰을 다룸
• 운영자 계정, API 토큰, 외부 연동 자격증명이 한곳에 모여 있음
• 대부분의 엣지가 오케스트레이터를 신뢰하도록 설계돼 있음

즉 여기서 OS 명령이 실행된다는 건, 공격자가 "네트워크 장비 한 대를 얻었다"가 아니라 "네트워크를 설계하는 사람의 자리에 앉았다"에 가까움. CVSS 숫자보다 이 위치가 실질적인 심각도를 결정함.

2. 명령 주입은 왜 하필 이런 제품에서 반복될까

네트워크 관리 제품은 태생적으로 OS 도구를 많이 부름. 대상 IP로 ping을 쏘고, 인터페이스 상태를 뽑고, 설정을 tar로 묶어 백업하고, 인증서를 변환하고, 로그를 수집해 압축함. 이런 기능은 구현이 편하다는 이유로 종종 셸을 경유한 외부 명령 호출로 만들어짐.

여기서 사용자가 넣은 값(호스트명, 파일명, 인터페이스 이름, 진단 옵션 같은 것)이 명령 문자열에 그대로 이어붙으면, 셸이 그 값을 데이터가 아니라 명령 구분자로 해석하는 순간이 생김. 개념적으로는 그게 전부임. 별도의 메모리 익스플로잇도, 정교한 우회도 필요 없고, 그냥 문자열 하나가 문맥을 갈아타는 것뿐임. 그래서 이 계열 결함은 공개되고 나면 무기화가 빠른 편이라고 봐야 함.

이 글에서 실제로 동작하는 입력값을 적을 생각은 없음. 방어자에게 필요한 건 페이로드가 아니라 "그 문자열이 실행되면 호스트에 어떤 흔적이 남는가"이기 때문임.

3. 탐지: 결국 프로세스 계보를 본다

명령 주입은 흔적이 의외로 정직함. 웹 애플리케이션이 원래 하지 않던 일을 하기 때문임. 우선순위대로 정리하면 이렇게 됨.

• 웹/애플리케이션 서비스 계정의 자식 프로세스: 평소에 그 계정이 띄우던 프로세스 목록을 기준선으로 잡아두고, 거기서 벗어난 셸·스크립트 인터프리터·다운로드 도구가 등장하는지 봄. 이게 가장 신호 대 잡음비가 좋음
• 오케스트레이터에서 나가는 아웃바운드: 관제탑은 엣지와 통신하지, 낯선 외부 호스트로 먼저 연결을 여는 장비가 아님. 새 목적지·새 포트·주기적 비콘 패턴은 바로 조사 대상
• 진단·백업 계열 API 호출 로그: 접근 로그에서 해당 엔드포인트만 따로 뽑아 파라미터 길이 이상치, 비정상 문자 포함, 짧은 시간 내 반복 호출을 봄. 정상 운영자는 진단 기능을 그렇게 자주 두드리지 않음
• 지속성 흔적: 새로 생긴 서비스 유닛, 크론 항목, 인가키 파일 변경, 웹 디렉터리에 생긴 낯선 파일. 파일 무결성 모니터링을 이 경로들에 걸어두면 사후 확인이 훨씬 편해짐
• 인증·권한 이벤트: 관리자 계정 신규 생성, 기존 계정 권한 상향, API 토큰 발급 이력. 명령 실행에 성공한 쪽은 대개 정식 계정으로 갈아타려 함

개인적으로는 이런 관리 서버일수록 EDR을 "혹시 몰라서" 빼지 말고 반드시 넣어두는 쪽을 추천함. 네트워크 어플라이언스 성격이라며 에이전트를 제외해 둔 서버가, 정작 사고 났을 때 프로세스 계보가 없어 조사 자체가 막히는 경우를 꽤 봄.

4. 완화 우선순위

• 벤더 권고 버전으로 업데이트: 온프렘은 자동 갱신이 아니므로, 우리 조직의 VCO 버전을 실제로 확인하는 것부터가 시작임
• 관리 평면 노출 차단: 오케스트레이터 관리 UI/API가 인터넷에서 직접 닿는 구조라면 그것부터 정리함. 관리자는 VPN이나 점프호스트를 거치게 하고, 접근 출발지 IP를 좁힘
• 엣지 통신 포트와 관리 포트 분리: 엣지가 붙어야 하는 인터페이스와 사람이 붙는 인터페이스를 같은 노출면에 두지 않음
• 아웃바운드 화이트리스트: 오케스트레이터가 나가야 할 목적지는 생각보다 적음. 기본 차단으로 두면 명령 실행에 성공해도 다음 단계가 끊김
• 계정·토큰 최소화와 MFA: 안 쓰는 관리자 계정, 만료 없는 API 토큰을 정리함
• 침해 정황이 있다면 자격증명 회전: 오케스트레이터가 보유한 키와 토큰은 전부 오염된 것으로 간주하고 교체함. 호스트만 재설치하고 키를 그대로 쓰면 되돌아올 길을 남겨두는 셈임

5. 사고를 가정하고 한 번 더 볼 것

관제탑 결함의 진짜 무서운 부분은 랜섬웨어처럼 요란하지 않다는 점임. 공격자가 굳이 서버를 망가뜨릴 이유가 없음. 조용히 설정 템플릿 한 줄을 바꿔 특정 트래픽 경로를 자기 쪽으로 돌리거나, 방화벽 정책 예외를 하나 끼워 넣는 편이 훨씬 이득이기 때문임.

그래서 점검할 때는 "침입 흔적이 있나"만 보지 말고 설정 자체의 변경 이력을 같이 봐야 함. 최근 배포된 정책·템플릿 diff, 변경을 수행한 계정과 시각, 승인 절차를 거치지 않은 변경이 있는지. 가능하면 오케스트레이터 설정을 정기적으로 내려받아 형상관리에 넣어두는 걸 권함. 나중에 비교할 기준선이 있느냐 없느냐가 조사 시간을 며칠 단위로 갈라놓음.

마무리

이번 건을 "SD-WAN 제품 하나의 패치 이슈"로만 처리하면 다음에도 똑같이 당함. 우리 환경에서 다른 장비들에게 명령을 내리는 서버가 어떤 것들인지 목록을 만들어 보는 게 이 글의 실질적인 숙제라고 생각함. 오케스트레이터, 설정 관리 서버, 배포 서버, 백업 콘솔... 의외로 이 목록이 가장 방치돼 있는 경우가 많음.

여러분 환경에서는 관리 평면이 어디까지 열려 있나요? 목록 뽑아보시고, 막아둔 항목이나 탐지 룰 잘 먹힌 사례 있으면 댓글로 공유해 주세요. 저도 다음 글에서 관리 평면 분리 설계를 좀 더 정리해서 가져와 볼게요. 같이 해보아요!