FlawOpen

flawopen.com/Teardowns/cve-2026-102255-sonicwall-sma1000-workplace-ssrf

● CVE-2026-102255 · CVSS 10.0[1] · 심각
보안 연구 · FlawOpen

CVE-2026-102255: SonicWall SMA1000 WorkPlace의 SSRF 취약점

CVE-2026-102255는 SonicWall SMA1000 WorkPlace의 CVSS 10.0 사전 인증 SSRF입니다. 10월 12일 MS-ISAC은 당시 권고문에 포함된 네 취약점이 실제 환경에서 악용됐다는 보고가 없다고 밝혔습니다. 또한 이 SSRF를 별도의 명령 주입 취약점인 CVE-2026-102256과 연계하면 원격 코드 실행으로 이어질 수 있다고 평가했습니다. CVE-2026-102256에는 인증된 관리자 권한이 필요합니다. 권고문은 연계 방식이나 인증 조건을 충족하는 방법을 설명하지 않으므로 이는 입증된 공격 체인이 아니라 조건부 위험 평가입니다. 10월 9일 이 CVE와 일치하는 허니팟 시도가 보고됐지만 침해 성공은 확인되지 않았습니다. 수정된 플랫폼 핫픽스를 적용하세요.[1], [2], [3], [4], [5], [6]

💡 알기 쉬운 설명 (ELI5)

장비를 방 사이로 메시지를 전달하는 안내 직원이라고 생각해 보세요. 이 결함은 낯선 사람이 안내 직원에게 신원 확인이 필요한 방으로 메시지를 전달하게 할 수 있습니다. SonicWall은 이 경로를 수정했지만 공개 공지에는 내부 경로나 소스 코드 패치가 나와 있지 않습니다.[1]

핵심 개념 및 용어

서버 측 요청 위조(SSRF)
신뢰할 수 없는 호출자가 고른 요청을 서버가 보내도록 유도하는 문제입니다. 이 사례에서 장비는 요청자를 대신해 내부 기능에 접근할 수 있습니다.[1], [3]

프레임워크 매핑

  • 이 가이드에서 설명하는 약점의 CWE 참조: CWE-918

근본 원인 분석 (Root Cause)

SonicWall은 SMA1000 Appliance WorkPlace 인터페이스에 의도하지 않은 대체 접근 경로가 있다고 설명합니다. 인증되지 않은 원격 공격자는 장비가 자신을 대신해 요청을 보내게 하고 내부 기능에 접근해 무단 작업을 수행할 수 있습니다. SonicWall 공지에는 펌웨어 소스 diff가 공개되지 않았습니다. BleepingComputer는 연구원 Ryan Dewhurst의 말을 인용해 허니팟이 WorkPlace Extraweb을 대상으로 한 OPTIONS 요청과 로컬 CouchDB 서비스를 겨냥한 시도를 탐지했다고 보도했습니다. 이 보도는 어떤 시도도 시스템 침해에 성공했음을 입증하지 않습니다. 이 글은 이를 확인된 악용이 아닌 출처가 명시된 시도 보고로 다룹니다. 보도된 payload와 자격 증명은 재현하지 않습니다. SonicWall은 CVSS 10.0 Critical을 부여하고 CVE 레코드는 CWE-918을 지정합니다. 10월 취약점은 다른 SonicWall 취약점과 무관하다고 밝혔습니다. 이전 SMA1000 공개 건과 하나의 공격 체인으로 묶지 마세요. SonicWall의 10월 6일 공지는 당시 실제 악용 증거가 없다고 밝혔습니다. 10월 9일 BleepingComputer는 연구원 Ryan Dewhurst의 말을 인용해 Previdian 허니팟이 이 CVE와 일치하는 시도를 탐지했다고 보도했습니다. 시스템 침해 성공 여부는 확인되지 않았습니다. 2026년 10월 12일 업데이트: MS-ISAC은 당시 권고문에 포함된 네 취약점이 실제 환경에서 악용됐다는 보고가 없다고 밝혔습니다. 이는 10월 9일 허니팟 시도 보고와 양립합니다. 시도는 악용 성공을 입증하지 않으며 MS-ISAC은 피해자를 특정하지 않았습니다. 같은 권고문은 사전 인증 SSRF CVE-2026-102255가 인증된 관리자 권한이 필요한 별도의 OS 명령 주입 취약점 CVE-2026-102256과 연계되면 원격 코드 실행과 전체 시스템 침해로 이어질 수 있다고 평가합니다. 인증 조건을 충족하는 방법이나 입증된 단계는 설명하지 않았고, 관찰된 활동에서 해당 체인이 사용됐다고 보고하지도 않았습니다. 이를 정부 출처의 조건부 위험 평가로 다루고 확인되거나 재현 가능한 공격 체인으로 표현하지 마세요. SonicWall은 수정 빌드 12.4.3-03670+ 및 12.5.0-03082+를 제시합니다. 체인이 입증됐는지와 관계없이 업데이트하세요.[1], [2], [3], [4], [6]

단계별 공격 실행 흐름

단계 1

인증되지 않은 요청이 WorkPlace에 도달

SonicWall은 인증 전 문제가 SMA1000 WorkPlace 인터페이스에 있다고 설명합니다. BleepingComputer는 허니팟이 WorkPlace Extraweb 대상 OPTIONS 시도를 탐지했다고 보도했으며, 이는 침해 성공을 입증하지 않습니다.[1], [4]

단계 2

장비가 요청자를 대신해 요청을 보냄

공급업체는 내부 기능 접근과 무단 작업이 가능하다고 설명합니다. BleepingComputer 보도에 따르면 시도는 로컬 CouchDB를 겨냥했지만 연구원은 침해 성공을 확인하지 않았습니다.[1], [4]

단계 3

운영자 대응: 패치하고 노출 여부 조사

SonicWall은 12.4.3-03670+ 및 12.5.0-03082+ 빌드를 수정 완료 버전으로 안내합니다. 패치가 지연되면 임시 격리 조치로 WorkPlace 노출을 제한하고 로그를 보존한 뒤 조사하세요. 보고된 시도만으로 침해 성공이 입증되지는 않습니다.[1], [4], [5]

소스 코드 비교: 취약한 구현 vs 보안 패치

펌웨어 소스 코드와 패치 diff는 공개되지 않았습니다. 이 일반 Python 예제는 호출자를 고정 서비스 ID로 제한하고 애플리케이션이 origin과 경로를 관리하며 리디렉션을 끕니다. SonicWall 코드나 CVE 재현 코드가 아니며 완전한 SSRF 방어도 아닙니다. 제품에는 SonicWall 플랫폼 핫픽스를 적용하세요.[1]

소스 코드 발췌: Generic SSRF defense illustration; not SonicWall source

취약한 구현
# 일반적인 예시이며 SonicWall 소스 코드나 취약점 재현이 아닙니다.
def fetch_health(user_supplied_url, session):
    return session.get(user_supplied_url, timeout=3)
보안 강화 패치
# 일반적인 SSRF 방어 패턴이며 SonicWall 소스 코드나 완전한 패치가 아닙니다.
from urllib.parse import urljoin

SERVICE_PATHS = {"status": "/health"}
BASE_URLS = {"status": "https://status.example.internal"}

def fetch_health(service_id, session):
    base = BASE_URLS.get(service_id)
    path = SERVICE_PATHS.get(service_id)
    if base is None or path is None:
        raise ValueError("unknown service")
    # 사용자 입력은 고정된 기능만 선택하며 URL이나 호스트는 선택하지 않습니다.
    return session.get(urljoin(base, path), timeout=(2, 3), allow_redirects=False)

엔지니어링 및 시스템 보안 강화 체크리스트

출처