회의실 서버는 왜 인터넷 쪽을 보고 있었나 — TrueConf Server 코드 인젝션 이야기

이미지 출처: CISA KEV

사내에 자체 구축형 화상회의 서버를 두는 조직이 꽤 있음. 클라우드 회의 서비스를 못 믿거나, 망분리 정책 때문이거나, 회의 녹화본을 외부에 두면 안 되는 규정 때문. TrueConf Server도 그런 목적으로 선택되는 온프레미스 제품 중 하나임. 그런데 이런 서버가 조용히 위험해지는 지점이 하나 있음. 회의 자체는 내부에서만 쓰는데, 관리 웹 인터페이스는 외부에서 접근 가능한 상태로 방치되는 경우가 많다는 것.

핵심 요약

• CVE-2026-72530은 TrueConf Server에서 보고된 코드 인젝션(Code Injection) 계열 취약점으로, 입력값이 서버 측 실행 흐름에 섞여 들어가는 유형임
• 온프레미스 회의 서버는 관리 인터페이스가 인터넷에 노출된 채로 오래 방치되기 쉬워, 실제 위험도가 CVE 점수보다 높아지는 경우가 많음
• 방어자는 패치 적용과 함께 관리 포트 접근 제한·웹 요청 로그 이상 탐지·서버 프로세스가 낳는 자식 프로세스 감시를 같이 걸어야 함

코드 인젝션이란 게 정확히 뭘 말하는가

용어가 비슷비슷해서 헷갈리기 쉬운데, 정리하면 이럼.

• 커맨드 인젝션: 사용자 입력이 OS 셸 명령에 붙어서 실행되는 것. 세미콜론이나 파이프 같은 셸 메타문자가 걸러지지 않을 때 발생
• 코드 인젝션: 사용자 입력이 애플리케이션이 쓰는 언어의 코드로 해석되는 것. 서버가 PHP·Python·JS 같은 걸로 동작 로직을 만드는데 그 재료에 외부 입력이 섞이는 경우
• 템플릿 인젝션: 위 둘의 사촌 격. 템플릿 엔진이 입력을 표현식으로 평가해버리는 것

CVE-2026-72530이 붙은 유형은 두 번째. 즉 셸을 직접 부르지 않아도, 서버 애플리케이션의 실행 문맥 안에서 공격자 의도가 코드처럼 해석될 수 있다는 뜻임. 이게 왜 무서우냐면, 셸 메타문자만 필터링하는 방어책이 통하지 않기 때문. 세미콜론도 백틱도 안 쓰고 그냥 그 언어의 정상 문법으로 목적을 달성할 수 있음.

화상회의 서버라서 더 문제인 이유

회의 서버는 성격상 권한이 넓음. 정리해보면 이런 자산을 한꺼번에 들고 있음.

• 사내 사용자 계정 디렉터리(LDAP·AD 연동인 경우 더 심각)
• 회의 녹화 파일과 채팅 로그 — 경영 회의, 인사 면담, 계약 협상이 그대로 담김
• 회의 초대 링크 발급 권한 — 탈취당하면 정상적인 회의에 침입자가 들어와 앉아 있을 수 있음
• 내부망 깊숙한 위치 — DMZ가 아니라 내부 세그먼트에 놓인 경우가 많아 측면 이동 발판이 좋음

공격자 입장에서는 파일서버 하나 터는 것보다 회의 서버 하나 잡는 게 정보 밀도가 훨씬 높음. 녹화본은 요약본이 아니라 원본 대화라서 그럼.

내가 방어자라면 이 순서로 봄

패치는 당연한 얘기니 그 앞뒤로 뭘 해야 하는지 위주로 적어봄.

1단계 — 우리 조직에 이게 몇 대나 있는지부터

의외로 여기서 막힘. 화상회의 서버는 IT팀이 아니라 총무팀이나 특정 사업부가 도입한 경우가 있어서 자산 목록에 안 잡혀 있는 일이 흔함. 확인 방법.

• 내부 대역 스캔에서 회의 서버가 쓰는 웹 관리 포트와 시그널링 포트 응답 확인
• DNS 레코드에서 conf, meeting, vcs, video 같은 호스트명 패턴 훑기
• 방화벽 정책 테이블에서 외부 인바운드가 허용된 내부 IP 목록 재검토 — 여기 걸려 있는 미확인 호스트가 대개 범인
• 외부 공격면 조회 서비스로 우리 도메인·IP 대역에 노출된 서비스 배너 확인

2단계 — 관리 인터페이스를 인터넷에서 떼어냄

이번 건뿐 아니라 온프레미스 협업 제품 취약점이 나올 때마다 반복되는 결론임. 회의 참가는 외부에서 되어야 하지만 관리 콘솔까지 외부에서 될 이유는 없음. 분리 방법은 이런 게 있음.

• 관리 경로는 VPN 또는 사내 대역에서만 접근하도록 소스 IP 제한
• 리버스 프록시를 앞에 두고 관리 URL 경로 자체를 외부에서 차단
• 관리자 계정에 MFA 강제, 기본 계정명 변경, 초기 비밀번호 잔존 여부 점검
• 회의 트래픽용 포트와 관리용 포트를 서로 다른 인터페이스에 바인딩

3단계 — 탐지 규칙을 미리 깔아둠

패치를 못 하는 기간이 반드시 생김. 검증 일정, 회의 일정, 업무 시간 문제로. 그 기간을 버티는 건 탐지임.

웹 요청 계층에서 볼 것

• 관리 인터페이스 경로에 대한 인증 실패 후 즉시 성공하는 패턴
• 평소 안 쓰이는 파라미터에 비정상적으로 긴 값, 인코딩이 중첩된 값이 들어오는 요청
• 설정 저장·업로드 계열 엔드포인트에 대한 비업무시간 POST
• User-Agent가 브라우저가 아닌 자동화 도구 문자열인데 관리 경로에 접근하는 세션

호스트 계층에서 볼 것 — 개인적으로는 이쪽이 훨씬 신뢰도가 높다고 봄. 웹 페이로드는 변형이 무한하지만 결과로 생기는 행위는 종류가 한정되어 있어서 그럼.

• 회의 서버 프로세스가 셸(cmd, powershell, sh, bash)을 자식 프로세스로 낳는 순간 — 정상 운영에서는 거의 없는 일임
• 서비스 계정이 갑자기 네트워크 진단 도구, 압축 도구, 다운로드 유틸을 실행
• 웹 디렉터리나 업로드 폴더에 새 스크립트 파일이 생성됨
• 회의 서버에서 외부로 나가는 아웃바운드 연결 — 원래 이 서버가 먼저 말을 거는 외부 대상은 라이선스 서버, 업데이트 서버 정도로 좁음. 화이트리스트를 만들기 아주 쉬운 서버라는 뜻
• 녹화 파일 저장소에 대한 대량 읽기 접근 — 유출 단계의 신호

4단계 — 침해 여부 사후 확인

패치했다고 끝이 아님. 공개 전에 이미 당했을 가능성을 접어두면 안 됨. 최소한 이 정도는 봐야 함.

• 관리자 계정 목록 전수 대조 — 모르는 계정, 최근 생성된 계정 여부
• 웹 접근 로그를 패치 시점보다 훨씬 이전까지 되짚어 관리 경로 접근 이력 확인
• 서버 내 예약 작업(스케줄러·서비스 등록) 신규 항목 점검
• 설정 파일 변경 시각과 실제 관리 작업 기록의 대조 — 아무도 안 만졌는데 바뀐 시각이 있으면 그게 단서
• 회의 녹화·채팅 데이터 접근 로그 — 유출 판단의 핵심 근거임

배포 방식이 만든 사각지대

이런 제품군의 공통된 문제는 도입 시점과 운영 주체가 어긋난다는 것임. 도입은 프로젝트로 하고, 그 프로젝트가 끝나면 담당자가 바뀌거나 없어짐. 그 뒤로는 아무도 버전을 안 봄. 웹 서버나 DB는 정기 점검 대상에 들어가지만 회의 서버, 사내 위키, 파일공유 어플라이언스 같은 건 목록에서 잘 빠짐. 그러다 몇 년 지나 CVE가 하나 뜨면, 그제야 "우리 그거 아직 쓰고 있었네" 소리가 나옴.

그래서 이번 건을 계기로 하면 좋은 게, 취약점 하나 막고 끝내는 게 아니라 협업·회의·문서 계열 온프레미스 제품 전체를 한 번 목록화해두는 것임. 화상회의, 사내 메신저, 위키, 문서관리, NAS 웹UI. 이 다섯 개만 훑어도 방치된 관리 콘솔이 최소 하나는 나옴. 경험상 거의 항상 나옴.

정리

코드 인젝션은 원리가 오래된 취약점이지만 여전히 잘 없어지지 않음. 입력을 데이터로만 다루면 되는데, 편의를 위해 실행 가능한 문맥에 넣는 설계가 계속 만들어지기 때문. 그리고 그런 설계는 제품 내부 깊숙이 들어가 있어서 사용자가 손쓸 수 없음. 사용자가 할 수 있는 건 패치를 빨리 붙이고, 그 전까지 노출면을 줄이고, 터졌을 때 알아챌 눈을 미리 심어두는 것 세 가지뿐임.

혹시 사내에 온프레미스 회의 서버 운영하고 계신 분들, 오늘 한 번만 관리 콘솔이 외부에서 열리는지 확인해보시면 좋겠음. 5분이면 되는 일인데 결과는 꽤 큼. 확인해보고 놀라셨다면 댓글로 남겨주세요. 같이 이야기해봐요!