사내 전화기 뒤에 있던 데이터베이스 — Switchvox 관리 화면이 삼킨 한 줄

이미지 출처: CISA KEV

회사에 있는 IP 전화기를 떠올려 보자. 책상 위에 놓인 그 플라스틱 덩어리는 대부분의 사람에게 "그냥 전화기"다. 그런데 그 전화기들을 묶어 관리하는 서버, 즉 Sangoma Switchvox 같은 통합 커뮤니케이션(UC) 장비 안에는 생각보다 많은 것이 들어 있다. 내선 번호와 부서 구조, 음성 사서함, 통화 기록, 그리고 관리자 계정 정보까지. CVE-2026-9586은 바로 그 서버의 웹 인터페이스에서 SQL 구문 조작이 가능하다는 내용으로 정리된 건이다.

핵심 요약

• Sangoma Switchvox의 웹 인터페이스에서 입력값이 SQL 질의에 그대로 섞이는 문제로, 데이터베이스 내용 노출·조작 위험이 있음
• UC 장비 특성상 통화기록·내선정보·계정 데이터가 한곳에 모여 있어 한 번의 유출로 조직 전체 구조가 드러남
• 패치 적용이 최우선, 그전까지는 관리 인터페이스의 인터넷 노출 차단과 웹 로그 기반 탐지로 버티는 것이 현실적

SQL Injection이 왜 아직도 나오는가

SQL Injection은 1998년쯤부터 공개적으로 논의된, 웹 취약점 중에서도 가장 오래된 축에 속함. 그런데도 2026년에 또 CVE 번호가 붙는 이유는 단순함 — 웹 애플리케이션이 아니라 어플라이언스이기 때문임.

• UC·PBX 장비의 관리 UI는 십수 년 동안 기능을 얹어온 레거시 코드가 많음
• 내부망에만 두는 장비라는 전제 때문에 입력 검증 우선순위가 낮게 잡힘
• ORM이 아니라 문자열로 질의를 조립하는 옛 방식이 그대로 남아 있는 경우가 흔함

즉 취약점 자체가 정교해서가 아니라, 아무도 오래 들여다보지 않은 코드였기 때문에 지금 나온 것에 가깝다고 봄.

개념적으로 무슨 일이 벌어지는가

원리만 짚자면 이렇다. 웹 화면의 어떤 파라미터 — 검색어든 ID값이든 — 가 서버 내부에서 SQL 질의문을 만들 때 문자열로 이어붙여짐. 정상 값이면 아무 문제 없지만, 값 안에 질의문의 구조를 바꾸는 문자가 섞이면 원래 의도와 다른 질의가 실행되는 것임. 여기서 중요한 건 "어떤 문자열을 넣느냐"가 아니라 데이터와 명령이 구분되지 않는 구조 그 자체가 결함이라는 점.

이 상태가 되면 공격자는 원래 접근 권한이 없는 테이블을 읽거나, 조건절을 항상 참으로 만들어 인증 로직을 우회하거나, 데이터베이스 계정 권한에 따라 내용을 수정하는 것까지 시도할 수 있음. UC 장비에서 이게 특히 뼈아픈 이유는, 그 데이터베이스가 곧 조직도 그 자체이기 때문임. 누가 누구에게 자주 전화하는지, 임원 내선이 몇 번인지가 다 들어있다면 그건 이후 보이스피싱이나 표적 사회공학의 훌륭한 재료가 되어버림.

방어자가 지금 확인할 것들

순서대로 정리해봄.

• 1. 자산 파악: 우리 조직에 Switchvox가 있는지부터. 의외로 IT팀이 아니라 총무팀이 도입해둔 경우가 있어서, 네트워크 스캔으로 관리 포트(HTTP/HTTPS)가 열린 장비를 훑는 게 빠름
• 2. 노출면 축소: 관리 인터페이스가 인터넷에서 바로 보이면 안 됨. VPN 뒤로 넣거나, 최소한 접근 소스 IP를 화이트리스트로 제한. 원격근무 때문에 열어둔 임시 규칙이 몇 년째 살아있는 경우가 정말 많음
• 3. 패치: 벤더가 배포한 최신 펌웨어·패치를 적용하는 것이 유일한 근본 해결책. 어플라이언스는 자동 업데이트가 꺼져 있는 일이 잦으니 수동으로 확인
• 4. 계정 정리: 기본 관리자 계정, 퇴사자 계정, 설치 업체가 만들어둔 유지보수 계정을 점검. SQLi로 해시가 유출됐을 때를 대비해 비밀번호도 교체

탐지 관점 — 로그에서 무엇을 보는가

패치까지 시간이 걸리는 조직이라면, 탐지라도 걸어두는 게 낫다고 봄. 실제로 볼 만한 신호는 이런 것들임.

• 웹 액세스 로그에서 동일 파라미터에 비정상적으로 긴 값이나 인코딩이 중첩된 값이 반복 요청되는 패턴
• 같은 엔드포인트에 대해 응답 크기나 응답 시간이 요청마다 들쭉날쭉한 흐름 — 블라인드 방식 탐색의 전형적 흔적임
• 인증 실패 없이 관리 페이지 응답이 200으로 계속 돌아오는데 세션 생성 기록은 없는 경우
• 데이터베이스 오류 메시지가 HTTP 응답에 그대로 실려 나가는 상황 — 이건 이미 정보 노출이니 그 자체로 조치 대상

WAF를 앞단에 둘 수 있다면 SQLi 시그니처를 켜두는 것도 임시 완충으로 쓸 만함. 다만 WAF는 우회 기법이 많아서 시간을 버는 수단이지 해결책은 아니라는 점은 분명히 해두고 싶음. "WAF 켰으니 패치는 다음 분기에" 가 되는 순간 그게 제일 위험한 상태가 됨.

조금 더 넓게 보면

이번 건을 계기로 한 번쯤 생각해볼 만한 게, 우리가 "보안 점검 대상"이라고 부르는 목록에 전화 시스템이 들어가 있느냐는 질문이다. 웹서버, 메일서버, VPN 게이트웨이는 다들 챙기는데 PBX·UC·회의실 장비·프린터 서버 같은 것들은 자산 목록 맨 아래에 이름만 올라가 있거나 아예 빠져 있는 경우가 많은 것 같다. 공격자 입장에서는 오히려 그런 곳이 조용하고 편한 진입로인데 말입니다.

개인적으로는 분기에 한 번 정도, 팀 안에서 "우리가 관리 안 하고 있는 IP 있나?" 하고 훑는 시간을 잡아두는 걸 추천함. 거창한 도구 없이 네트워크 대역 스캔 한 번만 돌려도 몰랐던 장비가 튀어나오는 일이 꽤 있음. 이번 Switchvox 건도, 결국 패치보다 먼저 필요한 건 그 장비가 우리 것이라는 인식이었다고 생각한다.

여러분 조직의 전화 서버는 지금 어디까지 열려 있는지, 이번 주에 한 번 확인해보면 어떨까요. 확인해보고 재밌는 게 나왔다면 댓글로 공유해주세요. 같이 점검해보아요!