지도 서비스 백엔드에 뚫린 세 칸짜리 사다리 — GeoNetwork 메타데이터 엔진 이야기

이미지 출처: The Hacker News

공공 공간정보 포털을 들여다보면 앞단은 대개 조용함. 지도 타일이 뜨고, 검색창이 있고, 좌표를 넣으면 항공사진이 나오는 정도. 그런데 그 뒤에서 메타데이터를 관리하는 카탈로그 엔진 — GeoNetwork 같은 소프트웨어 — 은 생각보다 훨씬 많은 걸 하고 있음. XML을 파싱하고, 외부 카탈로그와 하베스팅으로 동기화하고, 스타일시트로 문서를 변환하고, 파일을 디스크에 씀. 이번에 정리된 취약점 묶음은 정확히 그 '많은 일' 쪽에서 나왔고, 인증 없이도 연결이 되는 형태라 성격이 꽤 나쁨.

핵심 요약

• GeoNetwork 메타데이터 카탈로그에서 인증 없이 접근 가능한 엔드포인트를 시작점으로, XML 처리·변환·파일 쓰기 단계를 엮어 원격 코드 실행까지 이어지는 체인이 수정됨
• 단일 CVE가 아니라 '작은 결함 여러 개의 연결'이라는 점이 핵심 — 개별 항목만 보면 위험도가 낮아 보여 패치 우선순위에서 밀리기 쉬움
• 방어는 패치가 1순위, 그 다음이 익명 접근 범위 축소·아웃바운드 차단·XML 파서 하드닝·서블릿 컨테이너 프로세스 감시

왜 '체인'이라는 말이 중요한가

취약점 하나로 셸이 떨어지는 경우는 요즘 드묾. 대신 이런 조합이 흔함.

• 진입: 인증 없이 호출되는 API나 검색·하베스팅 관련 엔드포인트. 원래 공개 카탈로그라는 성격 때문에 익명 접근이 기본으로 열려 있는 경우가 많음
• 확장: XML 문서를 처리하는 과정에서 외부 엔티티나 외부 리소스를 참조하게 만드는 부분. 여기서 서버가 공격자 쪽으로 먼저 나가주면 내부망 정찰·파일 읽기로 번짐
• 착지: 변환·업로드·임시파일 저장처럼 서버가 디스크에 뭔가를 쓰는 지점. 쓰이는 위치를 통제할 수 있으면 웹 애플리케이션이 실행하는 경로로 코드가 들어감

세 칸이 다 있어야 사다리가 완성되는데, 문제는 방어자 입장에서 각 칸을 따로 보면 다 "심각도 중간" 정도로 보인다는 것. 그래서 이런 건 개별 CVE 점수보다 연결 가능성을 기준으로 판단하는 게 맞다고 봄.

내 자산에 이게 있는지부터

공간정보 계열 소프트웨어는 도입 경로가 특이해서 자산 목록에서 자주 누락됨. 보안팀이 아니라 GIS 담당 부서가 직접 올린 서버, 연구과제로 세워놓고 그대로 남은 인스턴스, 컨설팅 업체가 납품하고 인수인계가 흐지부지된 포털 같은 것들.

• 내부 스캔에서 톰캣·제티 계열 서블릿 컨테이너가 뜨는 호스트 중 /geonetwork, /catalog, /srv/ 같은 경로가 응답하는지 확인
• HTTP 응답 헤더와 로그인 페이지 푸터에 남는 제품·버전 문자열 수집. 오픈소스 카탈로그는 버전 표기가 화면에 그대로 남아 있는 경우가 많음
• GeoServer·GeoNetwork·PostGIS가 같은 망에 세트로 묶여 있는지도 같이 봐야 함. 한 칸이 뚫리면 옆 칸의 DB 자격증명이 설정파일에 평문으로 있는 구성이 흔함

탐지 관점 — 무엇을 로그에서 찾을까

공격 재현 자체는 여기서 다루지 않고, 남는 흔적만 정리함.

• 아웃바운드가 제일 정직함: 지도 서버가 갑자기 외부 HTTP나 DNS로 나가는 순간이 있으면 그게 신호. 정상 운영에서도 외부 카탈로그 하베스팅 트래픽은 있으니, 허용된 하베스팅 대상 목록을 화이트리스트로 만들어두고 그 밖으로 나가는 것만 알람을 거는 게 실용적임
• 웹 접근 로그: 익명 세션에서 관리·설정·하베스터 관련 경로로 POST가 들어오는 패턴, 그리고 짧은 시간에 같은 IP가 여러 엔드포인트를 순차로 두드리는 흐름
• 파일시스템: 웹 애플리케이션 배포 디렉터리와 데이터 디렉터리에 새 파일이 생기는지. 특히 정적 리소스 폴더에 스크립트 확장자가 새로 생기면 그 시점 전후 30분 로그를 통째로 봐야 함
• 프로세스 트리: 자바 프로세스가 셸이나 스크립트 인터프리터를 자식으로 띄우는 건 이런 서비스에서 정상 동작이 거의 아님. EDR에 이 규칙 하나만 넣어도 착지 단계는 상당히 잡힘

완화 — 순서대로

• 패치가 1순위. 다른 얘기 다 필요 없고 벤더가 낸 수정 버전으로 올리는 게 가장 확실함. 다만 공간정보 포털은 데이터 마이그레이션 부담 때문에 업그레이드를 미루는 곳이 많은데, 그럴수록 아래 항목이 임시 방벽이 됨
• 익명으로 열린 범위 축소: 공개 검색은 열어두더라도 편집·하베스팅·관리 계열 엔드포인트는 리버스 프록시 단에서 내부망 IP로 제한. 실제로 이런 서비스는 '조회는 전세계, 쓰기는 사내'로 나누는 게 자연스러움
• XML 파서 하드닝: 외부 엔티티·DTD 처리를 끄는 설정을 애플리케이션과 컨테이너 양쪽에서 확인. 라이브러리 기본값에 기대지 말고 실제 설정값을 눈으로 볼 것
• 아웃바운드 차단: 서버가 인터넷으로 임의 접속하지 못하게 막고, 하베스팅이 필요하면 프록시 경유로 목적지를 명시. 이거 하나로 정찰 단계에서 체인이 끊기는 경우가 많음
• 실행 권한 분리: 애플리케이션 계정이 자기 배포 디렉터리에 쓰기 권한을 갖고 있지 않은지 점검. 업로드 경로는 실행 불가 마운트로

남는 생각

이런 사건을 볼 때마다 드는 생각인데, 공공 포털의 진짜 약점은 코드가 아니라 담당자가 애매한 시스템인 것 같음. 지도는 잘 뜨니까 아무도 안 건드리고, 건드리는 사람은 GIS는 알지만 패치 주기는 안 보고, 보안팀은 그 서버가 있는 줄도 모름. 그러다 보니 몇 년 지난 버전이 그대로 인터넷에 붙어 있는 상황이 만들어짐.

그래서 개인적으로는 이번 건을 계기로 '우리 조직에서 지도·공간정보를 다루는 서버가 몇 대이고 누가 주인인가'를 한 줄로 답할 수 있게 정리해두는 걸 추천함. 취약점은 계속 나올 거고, 그때마다 급한 건 패치 자체가 아니라 '어디에 깔려 있는지 찾는 시간'이라서 그럼. 자산 목록만 준비돼 있으면 다음 공지가 떴을 때 반나절이면 끝날 일임.

혹시 운영 중인 카탈로그 서버 있으시면 버전 확인부터 같이 해보아요. 점검하면서 걸린 부분이나 우회 설정으로 막은 사례 있으면 댓글로 공유해주시면 저도 배우겠음.