10.0점 만점의 의미: 사용자 클릭 한 번 없이 열리는 Adobe Campaign Classic 서버

이미지 출처: The Hacker News

CVSS 점수표에서 10.0이 나오려면 조건이 꽤 까다로움. 네트워크로 접근 가능해야 하고(AV:N), 공격 난이도가 낮아야 하고(AC:L), 인증이 필요 없어야 하고(PR:N), 피해자가 아무것도 클릭하지 않아야 하며(UI:N), 마지막으로 영향 범위가 취약한 컴포넌트를 넘어 확장(S:C)돼야 함. Adobe Campaign Classic에서 보고된 이번 결함이 딱 그 조합에 들어감. 즉 메일 한 통 열게 만들 필요도, 계정 하나 훔칠 필요도 없이 서버에 도달하는 것만으로 코드가 돈다는 뜻임.

핵심 요약

• Adobe Campaign Classic의 최고 심각도 결함은 인증·사용자 상호작용 없이 원격 코드 실행으로 이어질 수 있음
• 이 제품은 고객 개인정보와 발송 인프라를 동시에 쥐고 있어, 한 대가 뚫리면 피해가 마케팅 영역에서 끝나지 않음
• 패치가 1순위지만 그 전에 "우리 것이 인터넷에 열려 있는지" 확인과 웹 요청·프로세스 생성 로그 점검이 먼저임

왜 하필 마케팅 서버인가

Adobe Campaign Classic은 대량 이메일·SMS 캠페인을 설계하고 뿌리는 온프레미스형 마케팅 자동화 플랫폼임. 보안팀 입장에서 이 제품의 성격을 정리하면 이렇게 됨.

• 고객 개인정보의 종착역 — 이름, 이메일, 휴대폰번호, 구매 이력, 세그먼트 태그가 통째로 들어 있음
• 신뢰받는 발송 인프라 — 회사 도메인으로 SPF·DKIM이 정렬된 상태에서 수백만 통을 보낼 수 있는 권한을 가짐
• DB 계정을 쥔 애플리케이션 서버 — 백엔드 데이터베이스에 상시 접속하는 자격증명을 로컬에 보관함
• 관리 사각지대 — 소유 부서가 IT가 아니라 마케팅인 경우가 많아 자산 목록과 패치 주기에서 자주 누락됨

공격자 관점에서 보면 한 대로 데이터 탈취와 대규모 피싱 발송을 동시에 해결할 수 있는 자리임. 랜섬웨어 협상 재료로도, 후속 사회공학의 발판으로도 값이 나가다 보니 노려질 이유가 충분함.

공격 흐름은 개념적으로만

구체적인 요청 형태나 페이로드를 적을 생각은 없고, 방어에 필요한 만큼만 정리함. 이런 부류의 결함은 대개 세 단계를 거침.

• 1단계 도달 — 인증 없이 응답하는 엔드포인트(관리 콘솔, SOAP·API 라우터, 서버사이드 스크립트 처리 경로)에 요청이 닿음
• 2단계 실행 전환 — 입력값이 역직렬화되거나 서버사이드 템플릿·스크립트 문맥에서 해석되면서 데이터가 코드로 바뀜
• 3단계 지속성 확보 — 서비스 계정 권한으로 웹셸을 심거나 설정 파일에서 DB·SMTP 자격증명을 회수함

여기서 방어자가 붙잡아야 할 포인트는 2단계가 아니라 1단계와 3단계임. 2단계는 벤더 패치의 영역이고, 나머지 둘은 우리가 오늘 당장 손댈 수 있는 영역이기 때문임.

먼저 할 일: 우리 것이 어디까지 열려 있나

패치 공지를 읽기 전에 이 확인부터 하는 걸 개인적으로 추천함. 취약점이 있어도 도달 경로가 없으면 급한 불은 아니고, 반대로 패치를 미룰 상황이라면 도달 경로를 끊는 게 유일한 방어선이 됨.

• 외부 인터넷에서 애플리케이션 서버와 관리 콘솔에 접근되는지 실제로 확인함. 내부망 전용이라고 믿고 있는 것과 실제 방화벽 정책이 다른 경우가 정말 많음
• 클라우드 보안그룹, 로드밸런서 리스너, 리버스 프록시 설정에서 이 서버로 향하는 규칙을 전부 뽑아 목록화함
• 운영·검증·개발 인스턴스를 같이 셈. 사고는 대개 "쓰지도 않는데 켜져 있던 스테이징"에서 시작함
• 버전 정보를 정확히 특정하고 Adobe 보안 공지에 적힌 대상 범위와 대조함. 빌드 번호까지 확인해야 함

탐지: 로그에서 무엇을 되짚을 것인가

이미 시도를 받았는지 확인하려면 아래 순서로 보는 게 효율적임.

• 웹 액세스 로그 — 인증 절차를 건너뛰고 곧장 API·스크립트 경로로 들어온 POST 요청, 비정상적으로 큰 본문 크기, 짧은 시간에 몰린 동일 경로 반복 호출
• 프로세스 생성 이벤트 — 가장 확실한 신호임. 애플리케이션 서비스 프로세스가 셸이나 스크립트 해석기, 다운로드 유틸리티를 자식으로 띄운 기록이 있으면 그 시점 전후 요청을 통째로 보존해야 함
• 파일 시스템 변경 — 웹 루트와 임시 디렉터리에 새로 생긴 스크립트 파일, 최근 수정 시각이 배포 이력과 어긋나는 파일
• 아웃바운드 트래픽 — 캠페인 발송용이 아닌 목적지로 나가는 연결, 특히 원격지에서 서버 쪽으로 열리는 세션 흔적
• DB·계정 활동 — 평소 조회 패턴을 벗어난 대량 SELECT, 새로 만들어진 운영자 계정, 야간 시간대의 대량 export

로그 보존 기간이 짧다면 이번 기회에 늘려두는 걸 권함. 며칠 지나서 공지가 나오는 취약점은 흔한데, 그때 볼 로그가 없으면 "침해가 없었다"가 아니라 "확인할 방법이 없었다"로 남게 됨.

완화: 패치가 1순위, 그리고 그 앞뒤

• 패치 적용 — 이 등급의 결함은 정기 배포 주기를 기다릴 사안이 아님. 긴급 변경 절차를 쓰는 게 맞음
• 노출면 축소 — 관리 인터페이스는 사내망·VPN·제로트러스트 게이트웨이 뒤로 넣고, 외부 공개가 꼭 필요한 경로만 허용 목록으로 남김
• 가상 패치 — 즉시 재기동이 어렵다면 WAF·리버스 프록시에서 해당 엔드포인트로 향하는 미인증 요청을 차단하고, 차단 로그를 반드시 수집함
• 권한 최소화 — 서비스 계정을 로컬 관리자·도메인 권한에서 떼어내고, DB 계정 권한도 필요한 테이블로 제한함. 실행이 되더라도 그 다음이 막히도록 설계하는 것이 핵심임
• 망 분리 — 이 서버에서 사내 파일서버나 도메인 컨트롤러로 나가는 통신을 기본 차단으로 두면 횡적 이동 비용이 크게 올라감

패치했다고 끝나는 게 아님

미인증 원격코드실행 계열에서 가장 자주 나오는 사후 실수가 "업데이트했으니 됐다"임. 공개 이전에 이미 접근이 있었다면 패치는 문을 잠근 것일 뿐, 안에 들어와 있던 손님을 내보내는 조치는 아님. 최소한 아래 세 가지는 같이 해야 함.

• 설정 파일에 들어 있던 DB·SMTP·API 자격증명 전부 교체
• 웹 루트 및 배포 경로에 대한 무결성 검증과 미확인 파일 탐색
• 공지 시점 기준으로 최소 수 주 전까지 거슬러 올라간 로그 재검토

정리하자면, 이번 사안의 교훈은 특정 제품 하나가 아니라 "보안팀 자산 목록에 없는 서버가 가장 위험하다"는 오래된 사실을 다시 확인시켜 준 것에 가까움. 마케팅 자동화, HR 포털, 전자결재처럼 IT 부서가 직접 관리하지 않는 시스템이 조직마다 꼭 몇 대씩 있는데, 이런 서버들이 보유한 데이터의 무게는 결코 가볍지 않습니다.

주말에 시간 조금 내서 우리 조직의 '주인 없는 서버' 목록부터 만들어 보면 어떨까요. 저도 이번 주에 자산 목록 다시 훑어보려고 하는데, 여러분 환경에서는 어떤 시스템이 사각지대에 있었는지 댓글로 공유해 주시면 같이 정리해 보아요!