서론

새벽 3시, 보안 관제 센터(SOC) 모니터를 지키던 담당자의 눈에 의심스러운 트래픽이 포착되었습니다. 내부망에서 오가는 평범해 보이는 IT 자산 관리 트래픽 사이로, 인증 과정 없이 시스템의 핵심 권한을 요청하는 짧은 패킷이 섞여 들어왔기 때문입니다. 이것은 단순한 오류가 아닙니다. SolarWinds Web Help Desk(WHD)의 취약점을 노린 실제 공격(Active Exploitation)의 신호였습니다.

Microsoft의 최신 분석에 따르면, 공격자들은 현재 SolarWinds Web Help Desk에 존재하는 심각한 인증 우회(Authentication Bypass) 및 SQL 인젝션 취약점을 적극적으로 악용하고 있습니다. SolarWinds 제품군은 과거 Sunburst 사태 이후로 보안 전문가들의 예의주시를 받아왔으나, 이번 공격은 그들의 ‘Web Help Desk’라는 구체적인 도구를 겨냥해 초기 진입(Initial Access) 경로로 삼고 있다는 점에서 더욱 위협적입니다.

왜 이 주제가 지금 중요할까요? 공격자가 단순히 웹사이트를 변조하는 수준을 넘어, IT 관리자가 믿고 사용하는 헬프데스크 시스템을 ‘트로이 목마’처럼 활용하여 내부망 깊숙이 침투하고 있기 때문입니다. 오늘 우리는 Microsoft가 밝� 공격의 기술적 메커니즘을 해부하고, 방어자 관점에서 어떻게 이 위협을 차단할지 집중적으로 살펴보겠습니다.

⚠️ 윤리적 경고: 본 문서에 포함된 모든 기술적 분석 및 코드 예시는 보안 연구 및 방어 목적(Defensive Purpose)로만 제공됩니다. 승인되지 않은 시스템에 대한 테스트는 불법이며 엄격히 금지됩니다.

본론

기술적 배경: Authentication Bypass & SQL Injection

Microsoft가 관찰한 공격은 주로 두 가지 핵심 취약점을 악용합니다. CVE-2024-28986(인증 우회)과 CVE-2024-28987(SQL 인젝션)가 그 주인공입니다.

1. 인증 우회 (CVE-2024-28986) 공격자는 정상적인 로그인 절차(JSON Web Token 검증 등)를 거치지 않고, 특정 엔드포인트에 조작된 요청을 보내 쿠키 또는 세션 토큰을 획득합니다. 이를 통해 마치 관리자 권한을 가진 것처럼 시스템에 인증됩니다.

2. SQL 인젝션 (CVE-2024-28987) 인증 우회 후 공격자는 데이터베이스 쿼리문을 조작하여 민감한 정보를 탈취하거나, 경우에 따라 원격 코드 실행(RCE)으로 이어질 수 있는 환경을 구축합니다. 특히 Web Help Desk는 Windows 서버 환경에서 구동되는 경우가 많아, 시스템 권한 탈취(Privilege Escalation) 위험이 극도로 높습니다.

공격 시나리오 분석

다음은 Microsoft의 보고서를 바탕으로 재구성한 공격자의 침투 흐름도입니다. 공격자는 외부에서 인증 없이 진입하여 내부 데이터를 유출하는 과정을 거칩니다.

  graph LR
    A[Attacker] --> B[Reconnaissance]
    B --> C[Auth Bypass Exploit]
    C --> D[SQL Injection Attack]
    D --> E[Privilege Escalation]
    E --> F[Data Exfiltration]
    C --> G[Webshell Upload]
    G --> E

이 흐름도에서 가장 중요한 점은 ‘인증 우회’가 방어망의 뚫린 구멍이라는 사실입니다. 일반적으로 인증은 첫 번째 관문이자 가장 강력한 방벽이어야 하지만, 이 취약점으로 인해 그 관문이 무력화되었습니다.

악성 트래픽 분석 및 탐지 로직

방어자 입장에서 공격을 식별하려면 정상적인 관리자 행위와 악성 공격 패턴을 구분해야 합니다. 아래는 일반적인 로그와 공격 시 나타나는 로그의 특징을 비교한 표입니다.

PoC 및 탐지 스크립트 (Python)

방어를 위해 실제 로그 데이터에서 이러한 패턴을 감지하는 자동화 스크립트가 필요합니다. 아래는 Python을 사용하여 웹 서버 접근 로그(Access Log)를 분석하고, SolarWinds WHD 취약점 공격 패턴을 탐지하는 예제 코드입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

import re

def analyze_solarwinds_log(log_file_path):
    """
    웹 서버 로그 파일을 분석하여 SolarWinds WHD 악용 징후를 탐지합니다.
    """
    # SQLi 및 Auth Bypass 패턴 정의
    sqli_pattern = re.compile(r"(\%27)|(\')|(\-\-)|(\%23)|(\;)|(\b(union|select|insert|delete|update|drop|alter)\b)", re.IGNORECASE)
    auth_bypass_path = re.compile(r"/helpdesk/WebObjects/Helpdesk.woa/wa/(Login|AssetSearch|TechAudit)", re.IGNORECASE)
    
    suspicious_entries = []

    try:
        with open(log_file_path, 'r') as file:
            for line in file:
                # 로그 파싱 (Apache Common Log Format 가정)
                parts = line.split()
                if len(parts) < 7:
                    continue
                
                ip_address = parts[0]
                timestamp = parts[3] + " " + parts[4]
                request_method = parts[5]
                request_uri = parts[6]
                
                # 분석 로직
                is_sqli = sqli_pattern.search(request_uri)
                is_target_endpoint = auth_bypass_path.search(request_uri)
                
                # 조건: SQLi 패턴이 존재하거나, 민감한 엔드포인트 호출 시 비정상적인 메소드 사용
                if is_sqli or (is_target_endpoint and request_method != 'GET'):
                    suspicious_entries.append({
                        "ip": ip_address,
                        "time": timestamp,
                        "attack_type": "SQL Injection" if is_sqli else "Auth Bypass Attempt",
                        "payload": request_uri
                    })
                    
        return suspicious_entries

    except FileNotFoundError:
        print("로그 파일을 찾을 수 없습니다.")
        return []

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 사용 예시 (학습 목적)
if __name__ == "__main__":
    # 실제 환경에서는 로그 파일 경로를 지정하세요.
    detected_logs = analyze_solarwinds_log("access.log")
    
    if detected_logs:
        print("[!] 경고: 의심스러운 활동이 탐지되었습니다.")
        for log in detected_logs:
            print(f"- IP: {log['ip']}, Type: {log['attack_type']}, Payload: {log['payload']}")
    else:
        print("[+] 현재 탐지된 위협이 없습니다.")

이 코드는 단순한 문자열 매칭을 넘어, 공격자가 자주 사용하는 SQL 인젝션 구문과 특정 엔드포인트에 대한 비정상적인 접근을 시각화하여 보안 관제자가 즉각 대응할 수 있도록 돕습니다.

완화 조치 및 대응 가이드

이론과 분석만으로는 공격을 막을 수 없습니다. 현장에서 즉시 적용해야 할 Step-by-step 가이드를 제시합니다.

Step 1: 즉시 패치 적용 (Immediate Patching) 가장 확실하고 우선순위가 높은 조치입니다. SolarWinds는 이미 이 문제를 해결하는 핫픽스를 배포했습니다.

• 대상 버전: Web Help Desk 12.8.3 이하

• 조치: Web Help Desk 12.8.3 HF2 (Hot Fix 2) 이상 버전으로 즉시 업그레드하십시오. 만약 업그레이드가 불가능하다면 외부 인터넷으로부터의 접근을 차단해야 합니다.

Step 2: 네트워크 격리 (Network Segmentation) WHD 서버는 관리 목적으로 넓은 범위의 네트워크 접근 권한을 필요로 하지만, 인터넷 노출은 최소화해야 합니다.

• 조치: WHD 서버를 DMZ 구간에 두거나, VPN을 통해서만 접근 가능하도록 제한하십시오. 공용 인터넷(0.0.0.0/0)에서의 80/443 포트 접근을 차단하세요.

Step 3: 침해 지표(IOC) 기반 탐지 (Detection) Microsoft Defender 등의 보안 솔루션에서 특정 패턴을 탐지하도록 규칙을 추가해야 합니다.

• 규칙 예시: Request contains "Helpdesk.woa" AND User-Agent does not contain "Mozilla"

• 조치: 위에서 작성한 Python 스크립트 또는 SIEM(Splunk, QRadar 등) 규칙을 배포하여 과거 로그에 대한 소급 검사(Retrospective analysis)를 수행하십시오.

Step 4: 인증 강화 (Hardening) 패치 후에도 추가적인 보안 계층을 둡니다.

• 조치: 관리자 계정의 강력한 비밀번호 정책 강제 및 MFA(다중 인증) 도입. WHD가 지원하는 SAML 통합을 통해 Active Directory와 연동하여 계정 관리를 중앙화하십시오.

결론

SolarWinds Web Help Desk에 대한 실제 공격은 우리에게 “잊혀진 구석(Shadow IT)에 존재하는 레거시 시스템"이 얼마나 치명적인 허점이 될 수 있는지를 다시금 상기시킵니다. Microsoft의 분석에서 드러나듯, 공격자는 이미 패치가 나온 취약점이라 할지라도 패치되지 않은 시스템을 찾아 자동화된 공격을 퍼부우고 있습니다.

핵심 요약은 다음과 같습니다. 첫째, 이번 공격은 인증 우회를 통한 신속한 내부 진입이 특징입니다. 둘째, 단순한 웹 방화벽만으로는 막기 어려운 로직 기반의 취약점입니다. 셋째, 대응은 **‘패치’와 ‘격리’**가 병행되어야 합니다.

전문가의 관점에서 인사이트를 덧붙이자면, 이번 사태는 소프트웨어 공급망(Supply Chain)의 보안뿐만 아니라, 조직 내에서 운영되는 모든 “관리 도구(Management Tools)“를 보안 관제의 핵심 대상으로 삼아야 함을 시사합니다. 개발툴이나 헬프데스크 소프트웨어는 방어자에게 편의를 제공하지만, 공격자에게는 “왕관의 보석"으로 향하는 가장 빠른 지름길이 될 수 있기 때문입니다.

지금 당장 서버 로그를 확인하고, 의심스러운 인증 기록이 없는지 확인하십시오. 그리고 SolarWinds Web Help Desk를 최신 버전으로 업데이트하는 것을 오늘의 최우선 과제로 삼으십시오.

참고자료 (References):

• Microsoft Security Blog - Analysis of active exploitation of SolarWinds Web Help Desk

• SolarWinds Security Advisories

• CVE-2024-28986 / CVE-2024-28987 Details