장바구니 뒤에 숨은 자바 서버, SAP Commerce Cloud의 무인증 코드 실행

이미지 출처: The Hacker News

세일 기간의 이커머스 서버는 하루에 수백만 건의 요청을 받아냄. 상품 조회, 장바구니 갱신, 결제 콜백, 재고 동기화가 쉴 새 없이 오가는데, 그 요청들을 실제로 처리하는 건 화면이 아니라 뒤편의 자바 애플리케이션 서버임. SAP Commerce Cloud(예전 hybris)에서 인증 없이도 임의 코드가 실행될 수 있는 결함이 보고됐다는 건, 바로 그 뒤편 서버가 로그인 절차를 건너뛴 채 명령을 받아들일 수 있다는 뜻임.

핵심 요약

• SAP Commerce Cloud에서 인증 없는 공격자가 서버에서 임의 코드를 실행할 수 있는 결함이 다뤄짐
• 스토어프론트·OCC API·백오피스가 한 JVM 위에 얹히는 구조라 한 지점이 뚫리면 주문·회원·결제 연동 데이터까지 사정권에 들어감
• 패치 적용이 1순위, 그 전까지는 관리 경로 노출 차단·아웃바운드 통제·JVM 자식 프로세스 탐지로 버텨야 함

이 제품이 어디에 놓여 있는지부터

SAP Commerce Cloud는 대형 유통·제조사가 B2C, B2B 쇼핑몰을 한꺼번에 굴릴 때 쓰는 자바 기반 커머스 플랫폼임. 특징을 정리하면 이렇게 됨.

• 스토어프론트(고객 화면), OCC REST API(앱·프론트엔드용), 백오피스(운영자 화면)가 같은 플랫폼 위에 확장(extension) 형태로 얹힘
• ERP, 결제 PG, 배송사, CRM과 연동돼 있어 주문·회원·정산 데이터가 한자리에 모임
• 커스터마이징이 많아 업그레이드가 늦어지기 쉽고, 그래서 구버전이 오래 살아남음

즉 이 서버는 인터넷에 그대로 노출된 채, 내부 기간계와도 연결돼 있는 자리에 앉아 있음. 방어자 입장에서 가장 신경 쓰이는 위치인 셈임.

무인증 코드 실행이 유독 무서운 이유

취약점 등급을 볼 때 개인적으로는 CVSS 숫자보다 두 가지를 먼저 봄. 인증이 필요한가, 그리고 사용자 상호작용이 필요한가. 이번 건은 둘 다 필요 없다는 쪽임. 계정을 훔칠 필요도, 운영자가 뭘 클릭하도록 유도할 필요도 없이 네트워크에서 요청 한 번으로 서버 권한을 얻는 형태라면, 공격 비용이 사실상 스캐너 돌리는 값 정도로 떨어짐.

이런 유형이 자바 커머스 플랫폼에서 반복적으로 나오는 경로는 대체로 정해져 있음. 개념 수준에서만 정리하면 이렇게 됨.

• 인증 필터가 걸리기 전 단계에서 처리되는 엔드포인트가 존재하는 경우
• 외부 입력이 객체 역직렬화나 표현식 평가 경로로 흘러드는 경우
• 업로드·미디어 처리 기능이 파일 경로나 확장자 검증을 느슨하게 하는 경우

구체적인 요청 형태는 굳이 옮길 필요가 없다고 봄. 방어 쪽에서 중요한 건 "어떤 문자열을 보내면 되는가"가 아니라 "우리 서버에서 그 경로가 열려 있는가, 열렸다면 흔적이 어디 남는가"이기 때문임.

먼저 할 일: 우리가 노출돼 있는지 확인

패치 공지를 읽자마자 자산 확인부터 하는 게 순서임. 확인 항목을 이렇게 잡아두면 편함.

• 운영 중인 SAP Commerce Cloud 인스턴스 목록과 정확한 버전·패치 레벨
• 외부에서 접근 가능한 경로 점검 — 백오피스, 관리 콘솔, 미디어 서빙 경로가 인터넷에 그대로 열려 있진 않은지
• 활성화된 확장 목록. 안 쓰는 확장이 켜져 있으면 공격 표면만 늘어남
• WAF·리버스 프록시가 앞단에 있는지, 있다면 관리 경로에 대해 실제로 차단 규칙이 걸려 있는지

운영팀이 "앞에 프록시 있으니 괜찮다"고 말할 때가 많은데, 실제로 규칙을 확인해 보면 스토어프론트만 보호하고 관리 경로는 통과시키는 설정이 꽤 흔함. 한 번은 직접 요청을 넣어보고 확인하는 걸 추천함.

탐지: 무엇을 어디서 보나

무인증 RCE는 성공하는 순간이 조용함. 로그인 실패 기록도 없고 계정 이상도 안 남음. 그래서 "인증 흔적"이 아니라 "실행 흔적"을 봐야 함.

• 웹 접근 로그 — 인증이 필요할 법한 경로에 인증 없이 들어온 POST가 200/302로 응답된 기록, 비정상적으로 큰 요청 본문, 짧은 시간에 여러 경로를 훑는 스캐닝 패턴
• 프로세스 계보 — 자바 프로세스(JVM)가 부모인 셸, cmd, curl, wget, whoami 같은 자식 프로세스. 정상 운영에서는 거의 나오지 않으므로 탐지 가치가 매우 높음
• 파일 시스템 — 미디어·임시·배포 디렉터리에 새로 생긴 스크립트나 아카이브, 웹에서 접근 가능한 경로의 파일 변경 시각
• 아웃바운드 트래픽 — 커머스 서버가 갑자기 낯선 IP나 도메인으로 나가는 연결. 이 서버는 원래 정해진 연동처하고만 통신하므로 화이트리스트를 세우기 좋은 대상임
• 애플리케이션 로그 — 역직렬화·클래스 로딩 관련 예외가 평소보다 늘어난 구간. 실패한 시도가 예외로 남는 경우가 많음

완화: 패치 전까지 버티는 방법

• 벤더가 제공한 보안 노트·패치를 최우선으로 적용. 커스터마이징 때문에 검증이 오래 걸린다면 적용 일정을 문서로 못 박아두는 것이 현실적임
• 백오피스와 관리 콘솔은 인터넷에서 내리고 VPN·사내망·IP 허용목록 뒤로 옮김
• 커머스 서버의 아웃바운드를 기본 차단으로 두고 필요한 연동처만 허용. 코드 실행이 성공해도 다음 단계 도구를 못 받아오면 피해가 크게 줄어듦
• 애플리케이션 계정을 최소 권한으로. JVM이 root나 관리자 권한으로 뜨고 있진 않은지 이번 기회에 확인
• DB 계정, 연동 API 키, 서비스 토큰은 침해가 의심되면 미련 없이 회전

이미 당했을 가능성을 검토할 때

패치를 적용했다고 끝이 아님. 무인증 결함은 공개 이전에 조용히 쓰였을 가능성을 항상 열어둬야 함. 최소한 이 정도는 되짚어 보길 권함. 웹 접근 로그를 패치 시점 기준 과거로 최대한 길게 확보하고, 미디어·배포 디렉터리의 파일 생성 시각을 배포 기록과 대조하고, 서버에서 나간 외부 연결을 기간별로 뽑아보는 것. 로그 보관 기간이 2주밖에 안 돼서 확인이 막히는 경우가 정말 많은데, 그럴 땐 이번 일을 근거로 보관 기간 연장을 요청하는 것도 방법임.

이커머스 서버는 장애가 곧 매출이라 패치가 늘 뒤로 밀리는 시스템임. 그 사정을 알기 때문에 더더욱, 패치 이전에 노출을 줄이고 실행 흔적을 볼 수 있게 만들어 두는 준비가 중요하다고 생각함. 오늘은 우리 쪽 관리 콘솔이 밖에서 열리는지 한 번만 확인해 보는 걸로 시작해 보아요. 혹시 자바 애플리케이션 서버 쪽 탐지 룰을 어떻게 잡고 계신지, 좋은 방법 있으면 댓글로 나눠주세요!