CVE-2026-58240 (SAP NetWeaver Message Server 컴포넌트 등록 인증우회) 분석

2026-10-19 · ##웹·서버 ##인증우회

분류: CVE · 웹·서버 · 인증우회 · CVE-2026-58240 · [표준]

큰 시스템일수록 내부 구성원끼리는 서로를 믿습니다. SAP NetWeaver의 애플리케이션 서버들은 “메시지 서버(Message Server)“라는 중앙 교환대에 자신을 등록하며 하나의 클러스터로 묶입니다. 그런데 이 교환대가 “등록하려는 쪽이 정말 우리 편인가”를 충분히 확인하지 않았습니다. 그 결과 로그인하지 않은 외부 공격자가 자기를 정당한 내부 컴포넌트인 척 등록해, 클러스터의 신뢰를 통째로 빌려 쓸 수 있었습니다. 연구자들은 이 결함에 S4GET이라는 이름을 붙였습니다.

개요

SAP NetWeaver는 전 세계 대기업의 ERP·업무 시스템을 떠받치는 애플리케이션 플랫폼입니다. 그 중 메시지 서버는 여러 애플리케이션 서버(AS) 인스턴스를 하나의 클러스터로 조율하는 중앙 컴포넌트로, SAP 커널의 일부입니다. 이번 취약점은 새 컴포넌트가 이 메시지 서버에 등록(registration) 할 때, 등록하는 쪽의 진정성(authenticity)을 충분히 검증하지 않는 데서 나옵니다. 무인증(pre-auth) 원격 공격자가 인가되지 않은 컴포넌트를 정당한 내부 구성원인 것처럼 등록할 수 있습니다.

근본은 단일 요소 인증에 의존(CWE-308, Use of Single-factor Authentication)하는 설계 결함으로 분류됩니다. ⚠️미확인(팩트체크 대상) — CWE 매핑은 리서치 재료(OpenCVE) 기준이며 NVD·SAP 원본 대조 대상입니다. 자동 요약기들이 이 라벨을 제각각(예: “Insufficiently Random Values” 등)으로 표기하는 혼선이 있어, 공식명은 “Use of Single-factor Authentication”으로 고정합니다(⚠️미확인).

영향 범위: SAP 커널 9.16 · 9.18 · 9.19 · 9.20. ⚠️미확인 — 리서치 재료(NVD/OpenCVE/CERT-EU) 기준. 목록에 9.17이 빠져 있는데, 이것이 의도인지 누락인지는 확인되지 않았습니다(⚠️미확인).
수정 경로: SAP Security Note 3759472 (SAP 로그인 필요, me.sap.com/notes/3759472). 리서치 재료 기준 수정 패치레벨은 9.16 PL 100 / 9.18 PL 32 / 9.19 PL 17 / 9.20 PL 7로 보이나, ⚠️미확인 — 특히 재확인 필요. 이 PL 숫자는 인증 벽 뒤의 SAP Note 원문을 직접 열지 못하고 2차 매체(SecurityBridge) 인용에 의존했습니다.
CVSS: 3.1 기준 9.8 (Critical), 벡터 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. ⚠️미확인 — 다수 출처에서 확인됐으나 정확한 벡터 문자열은 NVD 본문과 대조가 필요합니다.
인증 요구: 없음(pre-auth), 원격. 자격증명·인증서·사전 오설정이 필요 없고, SAP GUI가 붙는 것과 같은 공개 포트로 도달합니다(⚠️미확인 — Onapsis/SecurityBridge 기준).
별칭·맥락: 연구자 명명 S4GET. 같은 SAP 9월 패치데이(2026-09-08)에 공개된 CVSS 10.0짜리 CVE-2026-44756 “OVERPASS”와는 별개의 취약점입니다(⚠️미확인 — 리서치 재료 기준).

한 줄 요약: “클러스터에 새로 합류하려는 컴포넌트의 신원을 한 겹으로만 확인하면, 아무나 그 한 겹을 통과해 내부 구성원 행세를 할 수 있다” — 등록 관문에서 상호 인증이 빠진 것이 핵심입니다.

기술 배경 — 메시지 서버와 컴포넌트 등록

SAP NetWeaver의 애플리케이션 서버는 혼자 동작하지 않습니다. 여러 인스턴스가 하나의 시스템(SID)으로 묶여 부하를 나누고 서로 통신하는데, 이 조율을 메시지 서버가 맡습니다. 새 인스턴스나 게이트웨이 같은 컴포넌트는 시작할 때 메시지 서버에 자신을 등록하고, 그러면 메시지 서버가 그 정보를 클러스터의 다른 구성원들에게 알립니다. 이렇게 등록을 마친 컴포넌트는 클러스터 내부에서 “믿을 수 있는 구성원”으로 취급됩니다.

이 구조가 안전하려면 등록 관문에서 두 가지를 물어야 합니다. 첫째, “너는 정말 우리 클러스터의 정당한 컴포넌트인가”(신원 확인). 둘째, 그 확인이 위조하기 어려운 근거(공유 비밀·인증서 등 상호 인증)에 기반해야 합니다. 만약 등록하는 쪽이 스스로 신고한 정보(호스트·포트·PID 같은 자기 진술)만으로 신원을 인정한다면, 그 진술은 누구나 흉내 낼 수 있으므로 관문이 사실상 열려 있는 셈입니다.

메시지 서버에는 남용을 막기 위한 접근 제어 목록(ms/acl_info)이 있습니다. 다만 이 방어는 IP 기반이라 알려진 특정 요청 유형을 걸러내는 데 초점이 있고, 이번 등록 경로를 게이트하지는 못한 것으로 알려져 있습니다(⚠️미확인 — SecurityBridge 기준).

CVE 분석 요약 — 어느 판단이 원인인가

⚠️중요 제약 — 대상이 폐쇄소스(SAP 커널)라 코드 라인 대조가 불가능합니다. SAP 커널은 비공개 상용 소프트웨어로, 공개 GitHub 저장소·패치 커밋 SHA·렌더 가능한 오픈소스 원본이 존재하지 않습니다. 따라서 이 글은 고정 커밋 SHA·파일·라인번호를 제시하지 않습니다(지어내지 않습니다). 아래에 등장하는 함수명·opcode는 전부 연구자(SecurityBridge 등)의 디컴파일/리버스엔지니어링 산물이며 확증된 소스 라인이 아닙니다 — 단일·소수 매체 기반의 ⚠️미확인 등급으로, 팩트로 단정하지 않습니다.

리서치 재료 기준, 등록 관문에서 신원 검증이 한 겹뿐이라 다음 흐름이 성립합니다(모두 ⚠️미확인 — 소스 대조 불가).

익명 클라이언트가 초기 핸드셰이크를 통과합니다. 메시지 서버와의 초기 로그인(연구자 표기 MS_LOGIN_2)을 마치면, 자격증명 없이도 후속 명령을 보낼 수 있는 상태가 됩니다.
자기 진술만으로 컴포넌트 등록을 요청합니다. 공격자가 특정 등록 명령(연구자 표기 opcode 0x52)을 보내면서 호스트·포트·IP·PID 같은 식별 정보를 자유롭게 위조합니다. 메시지 서버는 이 진술을 위조 불가능한 근거와 대조하지 않고 받아들입니다.
신뢰가 클러스터 전체로 전파됩니다. 메시지 서버가 등록된 컴포넌트를 “유효”로 표시하고, 그 신원 정보를 구독 중인 모든 애플리케이션 서버에 브로드캐스트합니다. 그 순간부터 공격자가 신고한 가짜 컴포넌트가 클러스터 안에서 정당한 구성원으로 취급됩니다.

여러 매체는 이 신뢰 전파를 발판으로 <sid>adm OS 사용자 권한의 원격 코드 실행(RCE)까지 이어질 수 있다고 봅니다. 다만 NVD 공식 설명은 “인가되지 않은 컴포넌트 등록/인가되지 않은 행위”까지만 명시하며, “RCE”는 연구자 해석입니다(⚠️미확인). 확정된 것은 CVSS의 기밀성·무결성·가용성이 모두 High(C:H/I:H/A:H)라는 등급입니다.

아래는 그 관문 판단을 개념적으로 재구성한 것입니다. 실제 SAP 커널 코드가 아니며, 폐쇄소스라 정확한 코드는 확인할 수 없습니다.

# 개념용 단순화, 실제 페이로드/원본 코드 아님 (폐쇄소스라 실 코드 미확인)

익명 클라이언트 ──(1) 초기 핸드셰이크(MS_LOGIN_2)──▶ 메시지 서버
                                                     └ 자격증명 없이 통과

익명 클라이언트 ──(2) 컴포넌트 등록 요청(opcode 0x52)─▶ 메시지 서버
   { host, port, ip, pid ... }  ← 전부 공격자가 신고한 "자기 진술"
                                                     └ 위조 불가능한 근거와
                                                       대조하지 않고 수락  ◀── 결함 지점

메시지 서버 ──(3) "유효한 컴포넌트" 브로드캐스트──▶ 클러스터의 모든 AS
                                                     └ 가짜 컴포넌트가
                                                       내부 신뢰를 획득

핵심은 등록 관문이 “자기 진술”만으로 신원을 인정한다는 점입니다. 등록하는 쪽과 받는 쪽이 공유 비밀이나 인증서로 서로를 확인했다면(상호 인증), 위조한 자기 진술만으로는 통과할 수 없습니다. 이 취약점은 그 두 번째 확인 겹이 없어서, 한 겹뿐인 신원 확인을 아무나 흉내 낼 수 있게 된 결과입니다.

패치(요지, ⚠️미확인): 수정은 SAP Security Note 3759472로 배포되며, 리서치 재료 기준 위 4개 커널의 특정 패치레벨에서 닫힙니다(PL 숫자는 ⚠️미확인·재확인 필요). SAP Note가 로그인 벽 뒤에 있어 diff를 확인할 수 없으나, 결함의 성격상 올바른 수정은 등록 요청자의 신원을 위조 불가능한 근거로 상호 검증하도록 관문을 강화하는 방향일 것입니다(우리 분석·추정, 팩트로 제시하지 않음).

공격 시나리오 · 영향도 + 대응방안

공격 시나리오 (단계 압축, 완성형 페이로드 없음):

공격자가 인터넷 또는 내부망에서 노출된 SAP 메시지 서버 포트에 도달합니다(SAP GUI가 붙는 것과 같은 공개 포트로 알려짐, ⚠️미확인).
자격증명 없이 초기 핸드셰이크를 마친 뒤, 컴포넌트 등록 명령을 보내며 신원 정보를 위조해 자신을 정당한 내부 컴포넌트로 등록시킵니다.
등록이 받아들여지면 메시지 서버가 이 가짜 컴포넌트를 클러스터에 전파하고, 공격자는 이후 내부 구성원으로서의 신뢰를 이용해 추가 행위(연구자 주장으로는 <sid>adm 권한 RCE까지)를 시도합니다.

영향도: 확정된 것은 무인증 원격 공격자가 인가되지 않은 컴포넌트를 등록할 수 있다는 점과, 그 결과 CVSS 기밀성·무결성·가용성이 모두 High로 평가됐다는 사실입니다. 여러 매체가 여기서 나아가 클러스터 신뢰 탈취를 통한 <sid>adm 권한 RCE를 경고하지만, 이는 NVD 공식 문구를 넘어선 연구자 해석입니다(⚠️미확인). 실제 노출은 메시지 서버가 신뢰 경계 밖(특히 인터넷)에 도달 가능하게 열려 있는지에 크게 좌우됩니다. 실제 악용 관측 여부는 이 글의 리서치 범위에서 확인되지 않았습니다(⚠️미확인).

대응방안:

근본: SAP Security Note 3759472를 적용해 커널을 수정 패치레벨 이상으로 올립니다(리서치 재료 기준 9.16 PL100 / 9.18 PL32 / 9.19 PL17 / 9.20 PL7 이상으로 보이나 ⚠️미확인·재확인 필요). 적용 전 SAP 지원포털에서 자신의 커널 릴리스에 해당하는 정확한 패치레벨을 확인하는 것이 안전합니다.
차선(즉시 패치 불가 시):
- 메시지 서버 포트를 신뢰된 내부 네트워크로만 제한하고, 인터넷·비신뢰 세그먼트에서의 도달을 방화벽으로 차단합니다. 특히 외부 노출은 최우선으로 닫습니다.
- 메시지 서버 접근 제어(ms/acl_info 등 관련 프로파일 파라미터)와 내부/외부 포트 분리 설정을 점검해, 신뢰 경계 밖에서 등록 경로에 닿지 못하게 합니다.
- (SAP 표준 하드닝 관점) 메시지 서버 내부 포트와 외부 포트를 분리 운영하는 권고 구성을 재확인합니다.
탐지 관점: 메시지 서버로 향하는 예상치 못한 출처의 컴포넌트 등록 시도와, 알려지지 않은 호스트/PID가 클러스터 구성원으로 새로 나타나는 이벤트를 감시합니다. 신뢰 경계 밖 IP에서 오는 메시지 서버 트래픽 자체가 조사 신호가 될 수 있습니다.

결론

클러스터의 문지기가 “네가 누구라고 했지?”만 묻고 “그걸 어떻게 증명하지?”는 묻지 않으면, 아무나 이름표만 바꿔 달고 안으로 들어옵니다.

이 부류의 사고가 반복되는 이유는 분명합니다. 분산 시스템의 내부 구성원끼리는 서로를 믿도록 설계되는데, 그 “합류하는 순간”의 신원 확인이 한 겹(자기 진술)뿐이면 신뢰의 전체 사슬이 그 한 겹만큼만 튼튼하기 때문입니다. 등록·조인·핸드셰이크처럼 “내부로 들어오는 관문”은 위조 불가능한 상호 인증을 요구해야 하고, 그렇지 않으면 이후의 모든 내부 신뢰가 공짜로 넘어갑니다. 이 결함은 우리가 다룬 다른 신뢰 경계에서의 인증 우회·단일 요소 인증(CWE-308) 계열, 그리고 “내부라서 안전하다고 가정한” 설계 계열과 같은 뿌리를 공유합니다. 정석은 관문에서 상호 인증을 강제하고, 내부 서비스라도 네트워크 노출을 최소화하며(제로 트러스트), 등록 이벤트를 관측·검증하는 다층 방어입니다. 이 한 관문의 틈은 패치로 닫히겠지만, “합류하는 쪽의 신원을 한 겹으로만 믿지 말라”는 교훈은 다음 클러스터, 다음 등록 프로토콜에서 또 시험대에 오릅니다. 그래서 우리는 도구가 아니라 방법을 남깁니다.

References / 참고자료

NVD, “CVE-2026-58240 Detail” — 이 글이 재구성한 1차 정본(취약점 설명·영향 커널·CVSS·CWE). 리서치 단계에서 근본 사실(무인증 컴포넌트 등록·영향 범위)의 기준으로 삼음. https://nvd.nist.gov/vuln/detail/CVE-2026-58240
OpenCVE, “CVE-2026-58240” — CWE(CWE-308) 및 CVSS 벡터 확인. https://app.opencve.io/cve/CVE-2026-58240
CERT-EU, Security Advisory 2026-011 (Critical SAP Kernel / Message Server) — 영향 범위·수정 경로(SAP Note)·심각도 교차 확인. https://cert.europa.eu/publications/security-advisories/2026-011
SAP Security Note 3759472 — 정본 수정 경로(패치·수정 패치레벨). 로그인 필요로 본문 미열람, 팩트체크 시 직접 대조 필요. https://me.sap.com/notes/3759472
Onapsis, “S4GET (CVE-2026-58240): SAP NetWeaver Message Server Threat Advisory” — 최초 발견·명명(S4GET), pre-auth 성격·영향 해석. 리서치 단계에서 직접 로드 실패(검색 스니펫 기준), 팩트체크 시 재확인 대상. https://onapsis.com/blog/s4get-cve-2026-58240-sap-message-server-threat-advisory/
SecurityBridge, “CVE-2026-58240: From Patch Day to PoC in 96 Hours” — 등록 경로·opcode·심볼 상세(디컴파일 산물, ⚠️미확인 등급의 근거). 리서치 단계에서 직접 로드 실패(검색 스니펫 기준), 팩트체크 시 재확인 대상. https://securitybridge.com/blog/cve-2026-58240-from-patch-day-to-poc-in-96-hours/

이 글은 위 원 자료를 우리 관점에서 다시 쓰고 논평을 더한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 재현 절차는 원문을 참고하세요. 대상이 SAP 커널(폐쇄소스)이라 공개 커밋 SHA·raw 소스가 없어, 함수명·opcode·코드 흐름은 연구자의 디컴파일/리버스엔지니어링에 근거한 개념 재구성이며 파일/라인 단정을 하지 않았습니다. ⚠️미확인 표시가 붙은 사실 주장(특히 영향 커널·수정 패치레벨·CWE·CVSS 벡터·근본원인·함수명/opcode·<sid>adm RCE 해석)은 발행 전 독립 팩트체크로 1차출처 대조가 끝나야 확정됩니다. 혼동 주의: 같은 SAP 2026-09 패치데이의 CVE-2026-44756(“OVERPASS”, CVSS 10.0)는 이름·시점이 가까운 별개 취약점입니다.