마이크로소프트의 CrowdStrike 사건 기술 분석

• Microsoft는 Windows 커널 크래시 덤프에서 CrowdStrike 장애의 전역 패턴을 확인했고, CrowdStrike의 CSagent.sys 드라이버에서 발생한 read out-of-bounds 메모리 오류와 일치한다고 봄
• CSagent.sys는 파일 생성·수정과 named pipe 생성 같은 이벤트를 받는 파일 시스템 필터 드라이버였으며, 콘텐츠 업데이트가 관련 센서 로직을 바꾼 정황과 연결됨
• 장애 당시 시스템에는 CrowdStrike 드라이버 모듈 4개가 로드되어 있었고, 이 중 일부는 초기 부팅이나 동적 콘텐츠 업데이트와 맞물려 시스템 안정성에 직접 영향을 줄 수 있었음
• 보안 제품이 커널 드라이버를 쓰는 이유는 초기 부팅 위협 탐지, 시스템 전역 가시성, 차단, 성능, 변조 방지이지만, 커널 모드는 격리와 복구가 제한되어 가용성 리스크가 커짐
• Microsoft는 보안 제품이 커널 사용을 줄이고 사용자 모드 보호, ETW, AMSI, App Control for Business, Memory integrity, Device Health Attestation 같은 Windows 내장 기능으로 보안과 신뢰성을 함께 높여야 한다고 제안함

---

CrowdStrike 장애의 크래시 원인

• Microsoft는 Windows Error Reporting(WER) 커널 크래시 덤프를 분석해 CrowdStrike 장애와 관련된 전역 크래시 패턴을 확인함
• 분석에는 무료로 제공되는 WinDBG Kernel Debugger와 확장 도구가 사용됐으며, 크래시 덤프가 있는 고객은 같은 절차를 재현할 수 있음
• 크래시 덤프의 핵심 모듈은 csagent.sys였음
  • IMAGE_NAME: csagent.sys
  • MODULE_NAME: csagent
  • PROCESS_NAME: System
  • 잘못된 읽기 주소는 ffff840500000074로 표시됨
• 이 관찰은 CrowdStrike의 Preliminary Post Incident Review와 일치함
  • 원인은 CrowdStrike가 개발한 CSagent.sys 드라이버의 read out-of-bounds access violation
  • WER 데이터는 압축된 상태만 제공하므로, 크래시 이전의 더 넓은 명령어 범위를 역방향으로 디스어셈블하는 데 한계가 있음

CSagent.sys가 하던 일

• CSagent.sys 모듈은 안티멀웨어 에이전트에서 흔히 쓰는 파일 시스템 필터 드라이버로 등록되어 있었음
• 파일 시스템 필터 드라이버는 여러 파일 작업 알림을 받을 수 있음
  • 파일 생성
  • 파일 수정
  • 브라우저를 통해 다운로드된 새 파일의 디스크 저장
• 이런 필터는 시스템 동작을 감시하는 보안 솔루션의 신호 수집 지점으로 쓰일 수 있음
• CrowdStrike의 콘텐츠 업데이트 일부는 named pipe 생성 관련 데이터의 센서 로직을 바꿨고, 파일 시스템 필터 드라이버 API는 시스템에서 named pipe 생성 같은 활동이 발생할 때 호출될 수 있음
• 크래시 덤프에는 CrowdStrike 분석에서 언급된 control channel file version 291도 있었고, 해당 파일이 읽혔음을 보여줌
  • 파일 경로는 \Windows\System32\drivers\CrowdStrike\C-00000291-00000000-00000032.sys
  • 이 파일이 관찰된 access violation과 어떻게 연결되는지는 추가 드라이버 디버깅이 필요하며, Microsoft는 이를 분석 범위 밖으로 둠

장애 당시 CrowdStrike 드라이버 구성

• 크래시 당시 시스템에서 CrowdStrike가 제공한 다른 드라이버의 존재 여부도 덤프로 확인 가능했음
• Microsoft 분석에서 확인된 CrowdStrike 드라이버 모듈은 4개임
  • CSFirmwareAnalysis.sys
  • cspcm4.sys
  • CSBoot.sys
  • csagent.sys
• CSBoot.sys는 CrowdStrike Falcon Sensor Boot Driver로 등록되어 있었고, Early-Launch 그룹에 속함
• csagent.sys는 FSFilter Activity Monitor 그룹에 속하며 FltMgr에 의존함
• Microsoft는 고유한 스택과 크래시 속성을 사용해 이 CrowdStrike 프로그래밍 오류로 생성된 Windows 크래시 보고서를 식별할 수 있었음
  • 크래시 보고서를 생성한 장치 수는 Microsoft가 이전에 공유한 영향 장치 수의 부분집합임
  • Windows 크래시 보고서는 샘플링되며, Microsoft로 크래시 업로드를 선택한 고객에게서만 수집됨
  • 드라이버 소유자는 Hardware Dev Center analytics 대시보드에서 신뢰성 데이터를 평가할 수 있음

보안 제품이 커널 드라이버를 쓰는 이유

• CrowdStrike와 Microsoft를 포함한 여러 보안 벤더는 커널 드라이버 아키텍처를 사용함

• 가시성과 차단

  • 커널 드라이버는 시스템 전역 가시성을 제공함
  • 사용자 모드 애플리케이션보다 먼저 로드될 수 있는 boot kit과 root kit 같은 위협을 탐지하기 위해 초기 부팅 단계에서 로드될 수 있음
  • Windows는 프로세스·스레드 생성 콜백, 파일 생성·삭제·수정 이벤트를 감시하는 필터 드라이버 같은 기능을 제공함
  • 드라이버는 파일 생성이나 프로세스 생성 같은 활동을 차단할지 결정하는 콜백을 받을 수 있음
  • 많은 벤더가 NDIS driver class를 이용해 커널에서 네트워크 정보를 수집함

• 성능

  • 높은 처리량의 네트워크 활동 분석이나 데이터 수집은 커널 드라이버에서 성능상 이점을 얻을 수 있음
  • Microsoft는 커널 모드 밖에서도 데이터 수집과 분석을 최적화할 수 있는 시나리오가 많다고 봄

• 변조 방지

  • 보안 제품은 멀웨어, 표적 공격, 악의적 내부자가 관리자 권한을 가진 경우에도 소프트웨어가 비활성화되지 않기를 원함
  • Windows는 Early Launch Antimalware(ELAM)로 표시된 드라이버를 부팅 초기에 실행하는 메커니즘을 제공함
  • CrowdStrike의 CSBoot 드라이버는 ELAM으로 서명되어 부팅 시퀀스 초기에 로드될 수 있음

커널 모드의 신뢰성 트레이드오프

• 커널 드라이버는 가시성, 차단, 성능, 변조 방지 이점을 주지만 복원력 비용이 큼
• 가장 신뢰되는 수준에서 실행되는 커널 드라이버는 격리와 복구 능력이 본질적으로 제한됨
• 커널 수준 코드에는 광범위한 검증이 필요함
  • 일반 사용자 애플리케이션처럼 실패 후 재시작할 수 없음
  • 이 특성은 모든 운영체제에 공통적임
• Microsoft는 복잡한 Windows 핵심 서비스를 커널에서 사용자 모드로 옮기는 투자를 해왔음
  • 예시로 폰트 파일 파싱을 kernel to user mode로 이동함
• 보안 도구는 커널 모드에서 최소 센서만 실행해 데이터 수집과 차단을 맡기고, 업데이트 관리·콘텐츠 파싱 등 나머지 기능은 복구 가능한 사용자 모드에서 격리해 실행할 수 있음

Windows가 제공하는 대체 보호·확장 메커니즘

• Windows는 보안 제품이 필요한 커널 코드 양을 줄일 수 있는 사용자 모드 보호 방식을 제공함
• 변조 방지와 격리에 사용할 수 있는 기능
  • VBS Enclaves
  • Protected Processes
• 이벤트 가시성을 위한 사용자 모드 인터페이스와 이벤트
  • ETW events
  • Antimalware Scan Interface(AMSI)
• Microsoft는 Microsoft Virus Initiative(MVI)를 통해 서드파티 보안 벤더와 협력함
  • Windows 업데이트 호환성 확인
  • 성능 개선
  • 신뢰성 문제 대응
  • ELAM과 Protected Processes 같은 안티멀웨어 플랫폼 기능 접근
• Patch Guard는 안티멀웨어 같은 커널 드라이버 유형의 파괴적 동작을 막는 런타임 보호를 제공함

드라이버 검증과 배포 안전장치

• Microsoft Windows Hardware Quality Labs(WHQL)로 서명되는 모든 드라이버는 테스트와 품질 확인을 거쳐야 함
• 요구되는 확인에는 여러 기법이 포함됨
  • fuzzers
  • static code analysis
  • runtime driver verification
• 관련 도구는 모든 드라이버 개발자가 사용하는 Windows Driver Kit에 포함됨
• WHQL 서명 드라이버는 승인 전 Microsoft의 수집 검사와 멀웨어 검사를 통과해야 함
• 서드파티 벤더가 Windows Update를 통해 드라이버를 배포하면 Microsoft의 flighting과 점진적 롤아웃 절차도 거침
  • 목적은 품질을 관찰하고 광범위한 릴리스에 필요한 기준을 충족하는지 확인하는 것임

Windows를 더 높은 보안 모드로 배포하는 방법

• Windows는 개방적이고 범용적인 OS지만, 내장 도구를 사용해 더 잠긴 보안 구성으로 배포할 수 있음
• Windows 11에는 기본 활성화된 보안 기능이 다수 포함됨
  • TPM 2.0
  • Secure Boot
  • Virtualization-based security(VBS)
  • Memory integrity
  • Kernel DMA protection
  • BitLocker 또는 Device Encryption
  • Credential Guard
  • Microsoft Defender SmartScreen
  • Microsoft Vulnerable Driver Blocklist
• Windows의 기본 자기 보호 기능
  • Secure Boot: 초기 부팅 멀웨어와 rootkit 방지에 도움
  • Measured Boot: TPM 기반 부팅 속성 측정 제공
  • Memory integrity 또는 HVCI: 커널에서 동적 코드 런타임 생성을 방지하고 제어 흐름 무결성 보장에 도움
  • Vulnerable driver blocklist: 기본 활성화되고 OS에 통합되며 Microsoft가 관리함
  • Protected Local Security Authority: Windows 11에서 기본 활성화되어 자격 증명을 보호함
  • Microsoft Defender Antivirus: Windows에서 기본 활성화되어 OS 전반의 안티멀웨어 기능을 제공함

보안과 신뢰성을 위한 운영 권장사항

• Windows 내장 보안 기능은 MITRE ATT&CK 프레임워크에 나타나는 공격을 막는 데 도움이 되며, 비용과 복잡성을 줄일 수 있음
• App Control for Business는 신뢰된 앱이나 업무상 중요한 앱만 허용하는 보안 정책을 만들 수 있음
  • 거의 모든 멀웨어와 “living off the land” 유형 공격을 결정적으로 방지하도록 정책을 구성할 수 있음
  • 조직에서 허용한 커널 드라이버만 관리형 엔드포인트에 로드되도록 지정할 수 있음
• Memory integrity와 특정 허용 목록 정책을 함께 사용하면 VBS를 통해 Windows 커널을 추가로 보호할 수 있음
  • App Control for Business와 함께 쓰면 커널 멀웨어나 boot kit의 공격면을 줄일 수 있음
  • 신뢰성에 영향을 줄 수 있는 드라이버를 제한하는 데도 사용할 수 있음
• 표준 사용자로 실행하고 필요한 경우에만 권한을 상승하는 운영 방식은 여러 MITRE ATT&CK 기법을 완화함
• Device Health Attestation(DHA)은 하드웨어 기반 측정을 포함해 장치가 올바른 보안 정책을 갖췄는지 모니터링함

향후 Windows 보안 확장 방향

• Microsoft는 안티멀웨어 생태계가 Windows 내장 기능을 활용해 보안과 신뢰성을 함께 높이도록 협력할 계획임
• 지원 방향은 네 가지로 정리됨
  • 보안 제품 업데이트를 더 안전하게 수행하기 위한 안전한 롤아웃 가이드, 모범 사례, 기술 제공
  • 중요한 보안 데이터 접근에 필요한 커널 드라이버 의존도 축소
  • 최근 발표한 VBS enclaves 같은 격리·변조 방지 기능 강화
  • Windows 기본 보안 기능의 상태를 기반으로 머신 보안 상태를 판단하는 high integrity attestation 같은 제로 트러스트 접근 지원
• Windows는 Microsoft의 Secure Future Initiative 일부로 Rust 프로그래밍 언어에 대한 약속을 발표했고, 최근 Windows 커널의 Rust 지원도 확장함
• Microsoft는 CrowdStrike 사건 이후 Windows 보안 모범 사례와 새로운 보안 기능에 대한 지침을 계속 공유하겠다고 밝힘

[GN⁺]

Hacker News 의견들

• Microsoft가 최대한 외교적으로 쓰고 있지만, 사실상 CrowdStrike를 향한 강한 한 방으로 읽힘
  “배포를 제대로 못 하니 기본적인 QA 관행을 가르쳐 주겠다”에 가깝고, 이어서 커널 모드에서 덜 돌리도록 사용자 모드 기능들을 열거함
  Microsoft 내부에서 CS를 두고 어떤 잡담이 오갔을지 궁금함. 특히 “Windows가 망가져서 병원 환자들이 고통받는다”는 고객 대응을 해야 했던 팀들은 더 그랬을 듯

  • 이번이 처음도 아님. CrowdStrike는 지난 4개월 동안 매달 운영체제를 한 번씩 죽였음
    이쯤 되면 사실상 위협 행위자에 가깝고, 아직도 이 아마추어 같은 소프트웨어를 인프라에서 걷어내지 않았다면 경영진과 엔지니어링 쪽에서 공식적으로라도 검토했을 가능성이 큼
    https://en.wikipedia.org/wiki/CrowdStrike#Severe_outage_inci...
  • Microsoft 안에서도 꽤 불쾌해하는 분위기라고 들었음. 거기 다니는 친구가 이 얘기만 나오면 “우리 잘못이 아니다”라고 답답해하는데, 요즘 거의 모든 모임에서 계속 그 얘기가 나옴
  • “기본적인 QA 관행에 대한 지도가 필요하다”는 부분은 좀 웃김. Microsoft도 망가진 보안 업데이트의 긴 역사가 있어서, CrowdStrike에 많이 가르칠 수 있을지는 회의적임
  • 딱히 외교적으로 읽히지는 않았음. 특히 “보안 도구는 보안과 안정성을 균형 있게 가져갈 수 있고, 커널 모드에는 최소 센서만 두고 나머지 업데이트 관리·콘텐츠 파싱 등은 복구 가능한 사용자 모드에서 할 수 있다”는 문단은 이런 글에서 나올 수 있는 거의 최대치의 짜증처럼 보임
    요지는 “CrowdStrike가 그렇게 많은 코드를 실제 **커널 안에 넣을 이유가 전혀 없었다”는 것이고, 사후적으로 보면 꽤 강한 지적임
  • Microsoft는 Windows 애플리케이션과 드라이버를 위한 Project Zero 같은 조직을 둬야 함. PC의 1~5% 이상에 깔린 앱은 테스트하고 퍼징해야 하며, 공급사에게 수정을 압박해야 함
    기술적으로 Microsoft 책임이 아니더라도 이미 이미지 문제는 Microsoft 쪽으로 번졌고, 세상 절반은 이걸 Windows 블루스크린 문제로 부르고 있음

• 여기서는 더 권위 있는 분석을 기대했음. CrowdStrike가 말한 것처럼 범위 밖 읽기 시도가 있었다는 점은 확인하지만, 지금 시점에서는 새 정보가 아님
  결국 더 자세한 분석은 CrowdStrike 쪽에서 기다려야 할 듯함
  이 글은 보안 소프트웨어가 역사적으로 커널 모드에서 돌았던 이유를 설명하면서, 보안 업체들을 사용자 모드로 밀어내기 위한 Microsoft의 새 기술과 API를 홍보하는 느낌이 강함
  CrowdStrike는 Mac과 Linux에서는 이미 사용자 모드로 도는 것으로 보이고, Windows에서도 사용자 모드로 돌았다면 블루스크린 같은 치명적 장애 위험이 크게 줄었을 것임. 책임 대부분은 CrowdStrike에 있지만, Apple이 예전에 보안 업체들을 커널 모드에서 쫓아냈고 Windows도 비슷하게 했다면 이런 문제는 애초에 불가능했을 거라는 생각을 떨칠 수 없음. 외부 업체에 커널 모드 선택지를 제공하는 것 자체가 Microsoft에게 위험을 만드는 일이라고 봄

  • Microsoft는 이미 2006년 Windows Vista 출시 때 PatchGuard로 그런 방향을 시도했지만, Symantec과 McAfee 같은 업체들이 EU에 “제품 판매를 해친다”고 항의했고, 2009년에 EU가 Microsoft에게 그렇게 하지 말라고 했음
    Apple은 데스크톱 PC 시장 점유율이 작아 규제 당국의 관심을 덜 받고, 운영체제를 계속 갈아엎고 API를 폐기하고 CPU 아키텍처를 바꿔도 사용자층이 어느 정도 받아들이는 사치가 있음. Microsoft에는 그런 여유가 없음
    개인적으로는 Windows 기본 보안만 쓰고 서드파티 안티멀웨어를 안 쓰는 쪽이 예전 Symantec이나 McAfee를 설치하던 시절보다 훨씬 안전하고 안정적이라고 봄. 그 제품들은 시간이 지나면 악성코드처럼 굴고, 다크 패턴으로 구독료를 더 뜯어내곤 했음
    규제 당국은 Internet Explorer나 Media Player에 적용했던 식의 규제보다 보안이 훨씬 중요하다는 점을 이해해야 함. Apple App Store처럼 때로는 원제품 제조사가 보안을 맡고, 일부 장사꾼들이 보안을 팔아먹도록 제품 곳곳을 열어두지 않는 편이 낫기도 함. 닭장 철망이 자기 생존을 위협한다고 여우가 규제 당국에 불평하는 것과 비슷함
    [1] https://stratechery.com/2024/crashes-and-competition/
  • CrowdStrike는 Linux용 커널 모듈을 제공하고, 회사 노트북 설정 절차의 일부로 사용자가 Secure Boot 키를 수동 설치하길 기대함
    늘 위험해 보였지만, 체크박스를 채워야 하는 사람들은 결국 체크박스를 채움
  • 동의함. Microsoft의 핵심 역량은 전통적으로 하위 호환성이었지만, 각 보안 업체가 Windows의 가장 깊은 층을 건드리고 그걸 활용할 방법을 계속 탐색할 수 있다면 결국 서로 다른 Windows들이 생김
    시간이 지날수록 각 환경이 더 갈라지고, 시스템 안정성에 투자해서 얻은 이점도 희석됨. 한 조각에서 이긴 싸움을 다른 조각들에서 다시 싸워야 전체 안정성을 신뢰할 수 있기 때문임
    솔직히 미친 구조처럼 보임
  • Microsoft가 보안 업체를 사용자 모드로 밀어낼 새 기술을 갖고 있다는 말은 현재로서는 맞지 않음. 결론에서 살짝 암시만 할 뿐, 실제로는 아직 없음
    파일시스템 미니필터나 ObRegisterCallbacks 등에 해당하는 사용자 공간 대안은 존재하지 않음
  • EU의 이상한 반독점 조항 때문에 Microsoft는 보안 업체에게 커널 수준 접근을 제공해야 함

• 이 커널 수준 드라이버가 어떻게 WHQL 검증을 통과했는지 궁금함. Static Driver Verifier가 잡았어야 하는 것 아닌가? 일부 보안 업체는 이 절차를 우회할 수 있는 건가? Microsoft는 이 부분에 매우 조용함
  이런 지점이 과실 소송 변호사들이 파고드는 부분임. Brown Rudrick 파트너는 가장 가능성 높은 법적 이론이 과실이고, 의회가 CEO를 강하게 추궁하고 회사와 함께 책임을 묻고, 집단소송으로 이어질 수 있다고 봄. 아직 사실관계를 다 알지는 못하지만, CrowdStrike가 Microsoft 운영체제의 커널 수준 업데이트에 어떻게 접근했는지, Microsoft가 왜 자기 커널에 푸시되는 업데이트를 통제하지 못했는지도 아직 충분히 탐구되지 않은 차원이라고 함
  이미 첫 두 건의 집단소송이 시작되고 있음
  [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
  [2] https://www.channele2e.com/analysis/crowdstrike-legal-and-li...

  • 업데이트된 드라이버가 아니라 잘못된 설정 블롭이었기 때문임
    https://www.youtube.com/watch?v=ZHrayP-Y71Q
    https://www.youtube.com/watch?v=wAzEJxOo1ts
    그 검증은 운영체제와의 상호작용을 보는 것이지, 드라이버 고유 예외까지 잡아주지는 않음

• “보안과 가용성은 타협 불가”라고 하지만, Windows를 배포한 모든 사람이 실제 경쟁 선택지를 갖고 있었다고 가정해야만 성립함
  또 “커널 모드로 로드하는 두 번째 이점은 변조 저항성”이라고 하니, 결국 가용성은 타협 가능했던 셈임

  • 그 부분을 좀 더 설명해줄 수 있나? 실제 선택지가 없다는 점이 보안과 가용성이 타협 불가라는 말과 어떻게 연결되는지 모르겠음

• eBPF가 언급되지 않은 점이 눈에 띔. Linux에서는 표준이고 Windows에서도 사용할 수 있지만, 아직 Windows 본체에는 들어오지 않았음
  정적 분석이 이번 블루프라이데이 버그를 잡았을지는 모르지만, 현재 커널 모듈의 “마음대로 하세요” 모델보다는 보호 수준을 확실히 높여줌

• 이 분석이 꽤 마음에 듦. 적당히 기술적이고, 사용한 자료 링크도 있고, 디버깅 흐름도 보여주면서 세부사항이나 “우리가 얼마나 똑똑한지”에 매몰되지 않았음
  디버그 회고가 이렇게 더 많이 나왔으면 좋겠음. 보통은 100쪽짜리 분석이거나 모호한 몇 문단 중 하나로 끝남

• 논쟁적일 수 있지만, CrowdStrike가 아무리 나빴어도 Microsoft만이 사람들이 무엇을 할 수 있는지 결정하는 대안은 훨씬 더 나쁨
  이미 이 사건을 디지털 전체주의를 옹호하는 데 쓰려는 모습을 많이 봤음

  • Microsoft는 운영체제 공급사인 이상 언제나 컴퓨터를 망가뜨리는 업데이트의 잠재적 원천임. 여기에 제3자가 추가되면 위험 계층이 하나 더 늘어나는 것임

• Microsoft 자체가 CrowdStrike의 주요 경쟁자라는 점이 아직 별로 부각되지 않은 게 의외임

  • CrowdStrike는 Windows Defender를 넘어서는 기능을 제공한다고 생각했음. Microsoft에 직접 경쟁하는 다른 제품이 있나?

• 이 글이 책임을 돌리기 위해 마케팅팀과 법무팀의 얼마나 고통스러운 검토 단계를 거쳤을지 궁금함
  중요한 시스템에 어떤 운영체제나 배포판을 피해야 할지 판단하려면, 사고에서 배우려는 쪽과 “우리 잘못이 아니다”라고만 하는 쪽을 비교해 보면 됨. 이건 Microsoft만의 얘기도 아님

• Microsoft나 CrowdStrike의 발표 중에 이 충돌이 어떻게 품질 관리를 통과했는지 설명한 게 있었나? 100% 재현되는 충돌이 품질 관리 후반부 근처까지 갔다는 게 아직도 이해가 안 됨
  이런 건 개발자 단계나 첫 빌드 자동화 단계 같은 가장 이른 지속적 통합 단계에서 쉽게 잡혀야 하고, 사람의 품질 관리까지 갈 일도 아님

  • 이해한 바로는 미리 컴파일된 템플릿 스크립트를 배포하고, “콘텐츠” 업데이트가 설정값으로 그 템플릿을 채우는 구조임
    템플릿 스크립트는 테스트하고 콘텐츠도 검증하지만, 콘텐츠가 스크립트에 바인딩된 결과는 검증하지 않는 듯함. 쓰레기 콘텐츠 자체는 유효했지만, 실제 사용될 때의 동작은 유효하지 않았던 것으로 보임
    이 설계를 설명하는 그들의 표현이 불투명하고 혼란스러움
  • 이전 스레드에서 읽은 바로는, 테스트 환경이 실제 배포된 것을 테스트하지 않았음
    즉 테스트 이후 배포 전 패키징 단계가 있었고, 거기서 배포 파일들이 망가졌다는 얘기임
    사실이라면 테스트를 어떻게 통과했는지는 설명되지만, 개인적으로는 믿기 힘들 정도의 역량 부족이라고 봄
    그래도 더 구체적인 세부사항이 나왔는지는 궁금함
  • “파서 + 업데이트 프로그램”에 대한 퍼징 부족으로 보임