2010년의 DLL 프리로딩이 2026년 지멘스 설치 관리자에서 다시 보인 이유, CVE-2026-110936 탐지·완화 정리

이미지 출처: CISA KEV

2010년 무렵 보안 업계에서는 DLL 프리로딩(Binary Planting)이 크게 화제였음. 수백 개의 윈도우 프로그램이 DLL을 엉뚱한 폴더에서 먼저 찾는다는 사실이 한꺼번에 알려졌고, 마이크로소프트가 별도 권고문까지 냈음. 그로부터 15년도 더 지났는데 같은 계열의 이슈가 산업용 소프트웨어 설치 관리자에서 또 나왔음. 이번 대상은 Siemens Software Center이고, 번호는 CVE-2026-110936, 분류는 Uncontrolled Search Path Element(CWE-427)임. 오래된 공격 기법인 만큼 막는 방법도 꽤 정리되어 있어서, 이번 글에서는 공격 원리를 개념 수준으로만 짚고 탐지와 완화 위주로 정리해봄.

핵심 요약

• Siemens Software Center가 DLL 같은 라이브러리를 불러올 때, 공격자가 쓰기 권한을 가질 수 있는 경로까지 검색하는 문제가 확인됨(CWE-427)
• 로컬 접근 권한이 있는 공격자가 악성 DLL을 미리 심어두면, 프로그램이 실행될 때 해당 프로세스 권한으로 코드가 실행될 수 있음
• 대응은 벤더 패치 적용이 최우선이고, 폴더 ACL 점검과 Sysmon 이미지 로드 이벤트 모니터링을 함께 하는 게 현실적임

1. Siemens Software Center가 뭐길래

Siemens Software Center는 지멘스의 엔지니어링·자동화 소프트웨어(TIA Portal 계열 등)를 설치하고 업데이트를 관리하는 일종의 허브 프로그램임. 설치 관리자 성격이라 관리자 권한으로 실행되는 경우가 많고, OT 엔지니어링 워크스테이션에 깔려 있는 경우가 대부분임. 그래서 단순한 PC 유틸리티 취약점보다 무게감이 좀 다르다고 보는 게 맞는 것 같음. 엔지니어링 PC는 PLC 같은 현장 장비로 가는 길목이기 때문임.

2. Uncontrolled Search Path Element, 개념만 짚기

윈도우 프로그램은 필요한 DLL을 이름으로 요청하면, 운영체제가 정해진 순서대로 여러 폴더를 뒤져서 처음 발견한 파일을 불러옴. 대략 아래 순서로 흘러감.

• 애플리케이션 실행 파일이 있는 폴더
• 시스템 디렉터리(System32 등)
• 윈도우 디렉터리
• 현재 작업 디렉터리(설정에 따라 순서가 달라짐)
• PATH 환경 변수에 등록된 폴더들

문제는 이 경로 중에 일반 사용자도 쓸 수 있는 폴더가 끼어 있을 때 생김. 정상 DLL보다 먼저 검색되는 위치에 같은 이름의 파일이 놓여 있으면, 프로그램은 그게 진짜인지 확인하지 않고 그대로 불러옴. CWE-427은 바로 이렇게 검색 경로를 통제하지 못하는 설계를 가리킴.

이번 CVE도 같은 구조로 이해하면 됨. 다만 공격자가 먼저 해당 시스템에 로컬 접근을 해서 특정 폴더에 파일을 쓸 수 있어야 한다는 전제가 붙음. 원격에서 바로 터지는 유형은 아니고, 이미 발판을 마련한 공격자가 권한을 올리거나 지속성을 확보하는 데 쓰기 좋은 유형이라고 보는 게 정확함. 세부 영향 버전과 점수는 지멘스 ProductCERT 권고문과 NVD 항목에 정리되어 있으니 자기 환경 버전과 직접 맞춰보는 게 제일 확실함.

3. 탐지: 어디를 보면 흔적이 남는가

DLL 하이재킹은 파일이 생기는 순간과 그 파일이 로드되는 순간, 이렇게 두 군데서 흔적이 남음. 개인적으로는 아래 순서로 보는 걸 추천함.

• Sysmon Event ID 7(Image Loaded): Software Center 관련 프로세스가 Program Files나 System32가 아닌 경로, 예를 들어 사용자 프로필 아래나 임시 폴더에서 DLL을 불러오면 의심해볼 만함. 특히 서명되지 않았거나(Signed=false) 서명자가 지멘스·마이크로소프트가 아닌 DLL이면 우선순위를 올림
• Sysmon Event ID 11(File Create): 설치 폴더나 PATH에 걸린 폴더에 새 .dll 파일이 생기는 이벤트를 따로 걸러봄. 정상 업데이트 시점이 아닌데 DLL이 생겼다면 바로 확인 대상임
• Process Monitor로 검색 경로 확인: 테스트 PC에서 Procmon 필터를 프로세스 이름과 결과값 NAME NOT FOUND로 걸어두면, 프로그램이 어떤 경로에서 DLL을 찾다가 실패하는지 보임. 그 경로가 사용자 쓰기 가능 폴더라면 그게 바로 공격 표면임
• EDR 규칙: 서명된 정상 프로세스가 비정상 경로의 DLL을 로드하는 패턴(사이드로딩)은 대부분의 EDR에 기본 탐지 로직이 있음. 해당 룰이 OT 구간 엔지니어링 PC에도 실제로 켜져 있는지 확인하는 게 의외로 놓치기 쉬운 부분임

4. 완화: 패치 전후로 할 수 있는 것

• 벤더 패치 적용: 가장 근본적인 해결책임. 지멘스는 보통 ProductCERT 권고문에 수정 버전을 명시하므로 그 버전 이상으로 올리는 게 우선임. OT 환경이라 바로 못 올린다면 아래 항목으로 버티는 계획이라도 세워둬야 함
• 폴더 권한(ACL) 점검: icacls로 설치 폴더와 PATH에 등록된 폴더를 확인해서 Users나 Authenticated Users에 쓰기·수정 권한이 있는지 봄. 있으면 회수함. 생각보다 오래된 도구들이 C 드라이브 루트에 폴더를 만들고 PATH에 추가해둔 경우가 많음
• PATH 환경 변수 정리: 시스템 PATH에 사용자 쓰기 가능 경로가 끼어 있으면 제거함. 이것만 해도 이 유형의 공격 대부분을 막을 수 있음
• SafeDllSearchMode 확인: 레지스트리에서 기본값대로 활성화되어 있는지 확인함. 현재 작업 디렉터리 검색 순서를 뒤로 미뤄주는 설정임
• WDAC / AppLocker DLL 규칙: 엔지니어링 워크스테이션처럼 용도가 정해진 PC라면 서명 기반 DLL 실행 제어를 거는 것도 충분히 현실적임. 처음엔 감사(Audit) 모드로 돌려서 오탐부터 걸러내는 걸 추천함
• 최소 권한 운영: 평소엔 일반 계정으로 쓰고 설치·업데이트할 때만 권한을 올리는 습관이 결국 피해 범위를 줄여줌

5. 정리하면서

DLL 검색 경로 문제는 원리 자체가 단순해서 오히려 계속 반복되는 것 같음. 개발 단계에서 전체 경로로 DLL을 불러오거나 SetDefaultDllDirectories 같은 API로 검색 범위를 좁히면 대부분 예방되는데, 설치 관리자처럼 여러 구성 요소를 다루는 프로그램에서는 어딘가 한 군데씩 빠지기 쉬운 듯함. 방어하는 입장에서는 "이 프로그램이 어디서 DLL을 찾는지, 그 폴더에 누가 쓸 수 있는지" 두 가지만 기억해두면 이번 CVE뿐 아니라 비슷한 이슈가 또 나와도 같은 방식으로 점검할 수 있음.

OT 환경 엔지니어링 PC는 패치 주기가 길어서 이런 로컬 취약점이 생각보다 오래 남아 있는 경우가 많음. 이번 기회에 Sysmon 이미지 로드 룰 하나라도 걸어두고 폴더 권한도 한 번 훑어보길 바람. 혹시 현장에서 ACL 정리하다가 막히는 부분 있으면 댓글로 남겨주세요. 같이 고민해보아요!