Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
seal-security-nuget-demo-net7 — .NET 7 포크 버전의 seal-security-nuget-demo: 동일한 CVE-2024-21907 악용 스토리이지만, .NET SDK 7에 고정된 고객을 위해 재조정되었습니다. | Kitploit
도구/GitHubGitHub/isecuritytw/seal-security-nuget-demo-net7
Vulnerability AnalysisDevSecOpsSupply Chain SecurityLearning & EducationCurated Resources
GitHubisecuritytw/seal-security-nuget-demo-net7

seal-security-nuget-demo-net7

.NET 7 포크 버전의 seal-security-nuget-demo: 동일한 CVE-2024-21907 악용 스토리이지만, .NET SDK 7에 고정된 고객을 위해 재조정되었습니다.

저장소 보기

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
3개월 전아직 검토되지 않음
공유

브라우저 + CLI 데모 (NuGet/C#) — .NET 7 에디션

왜 .NET 7 포크인가?

이것은 표준 seal-security-nuget-demo(net9.0을 대상으로 함)의 대상을 변경한 포크입니다. 익스플로잇 스토리, 컨트롤러, 그리고 봉인된 패키지 목록은 동일합니다 — TargetFramework만 다릅니다.

이 포크가 존재하는 이유는 대부분의 엔터프라이즈 고객이 요청 시 최신 .NET SDK로 전환할 수 없기 때문입니다. .NET 7은 2024년 5월 14일에 지원이 종료되었지만, 실제 프로덕션 환경에서는 호환성, 인증, 또는 운영상의 이유로 여전히 이를 사용하고 있습니다. 이것이 바로 Seal Security가 설계된 정확한 사례입니다: 고객이 메이저 버전 업그레이드를 할 수 없거나(또는 하지 않으려 할 때), Seal은 취약한 의존성을 동일한 버전으로 제자리에서 패치하며, 공개 API 변경이나 고객 앱의 코드 수정이 없습니다. 이 데모는 고객에게 net8/net9을 먼저 설치하도록 요청하는 대신, 고객의 실제 스택에서 이 대화가 이루어지도록 합니다.

이 포크는 global.json을 통해 SDK를 7.0.x로 고정하여 데모 중에 실수로 업그레이드가 발생하지 않도록 합니다.


개요

이 데모 애플리케이션은 Newtonsoft.Json 12.0.2을 사용하여 사용자 입력을 구성 객체로 파싱하는 간단한 ASP.NET Core 환영 페이지입니다. 앱에는 이름 필드가 있으며, 이름을 입력하고 Go를 클릭하면 가 표시됩니다. 내부적으로는 입력을 Newtonsoft.Json의 에 전달합니다. 그게 전부입니다 — 인기 있는 JSON 라이브러리의 완전히 표준적인 사용법입니다.

"Welcome, alice!"
JsonConvert.DeserializeObject<NestedConfig>()

문제는 Newtonsoft.Json 12.0.2(및 13.0.1 이전 버전)에 CVE-2024-21907 — CVSS 점수 7.5 (HIGH) 의 높은 심각도 서비스 거부(DoS) 취약점이 있다는 것입니다. 이 데모는 Seal Security가 메이저 버전 업그레이드 없이 취약점을 제자리에서 패치하는 방법을 보여줍니다.


취약점: CVE-2024-21907

취약점이란 무엇인가?

Newtonsoft.Json의 JsonConvert.DeserializeObject<T>() 메서드는 깊게 중첩된 JSON 페이로드를 조작하여 악용될 수 있습니다. 타입이 지정된 객체(POCO)로 역직렬화할 때, 라이브러리의 JsonSerializerInternalReader는 진정한 재귀 호출(CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue → CreateValueInternal)을 수행하여 스택 오버플로우를 일으키고, 이로 인해 애플리케이션이 충돌합니다(서비스 거부).

익스플로잇이 작동하는 방식

앱은 사용자 입력을 받아 Newtonsoft.Json을 통해 파싱합니다. 입력이 URL인 경우, 앱은 먼저 콘텐츠를 가져옵니다 — 구성 로더, API 테스터, 웹훅 수신기에 사용되는 현실적인 패턴입니다:

root@kitploit:~
public class NestedConfig
{
    [JsonProperty("n")]
    public NestedConfig? N { get; set; }
}

var config = JsonConvert.DeserializeObject<NestedConfig>(name);

정상 입력: alice 입력 → "Welcome, alice!" 표시

익스플로잇: 이름 필드에 이 URL을 붙여넣고 Go를 클릭합니다:

root@kitploit:~
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

앱은 URL임을 감지하고 json-payload(깊게 중첩된 JSON {"n":{"n":{...}}})를 가져와 Newtonsoft.Json을 통해 재귀적인 NestedConfig 클래스로 역직렬화하여 스택 오버플로우를 트리거합니다.

JsonSerializerInternalReader는 모든 중첩 수준에 대해 CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue를 재귀합니다. 약 5,000 수준 깊이에서 스레드 스택이 소진되고 애플리케이션이 StackOverflowException으로 충돌합니다 — 프로세스가 즉시 종료됩니다(우아한 오류 처리가 불가능).

실제 영향

이 취약점으로 공격자는 다음을 수행할 수 있습니다:

  • 애플리케이션 충돌 — 악성 JSON 페이로드 전송
  • 서비스 거부(DoS) 발생 — 모든 사용자에게 영향
  • 서버 리소스 소진 — 반복적인 악용을 통한
  • 속도 제한 우회 — 각 요청이 프로세스를 충돌시키므로

왜 Newtonsoft.Json 13.0.1로 업그레이드하지 않는가?

공개적으로 제공되는 수정 사항은 버전 13.0.1로 업그레이드해야 합니다. 그러나 메이저 버전 업그레이드는 종종 다음을 도입합니다:

  • 직렬화 동작의 호환성이 깨지는 API 변경
  • 특정 버전을 기대하는 다른 라이브러리와의 호환성 문제
  • 모든 직렬화/역직렬화 코드 경로에 대한 광범위한 테스트 요구 사항
  • 프로덕션에서 런타임 동작 변경 위험

이로 인해 "그냥 업그레이드" 수정은 개발자 시간 수 주가 소요될 수 있는 프로젝트가 되며, 그동안 취약점이 노출된 상태로 남게 됩니다.

Seal Security가 수정하는 방법

Seal의 패치 버전(12.0.2-sp1)은 공개 API를 변경하지 않고 재귀 깊이 보호를 추가합니다. 패치는:

  1. 무제한 재귀를 방지하기 위한 기본 MaxDepth 제한 추가
  2. 스택 오버플로우 대신 적절한 예외로 깊은 중첩을 우아하게 처리
  3. 공개 API를 변경하지 않음 — 기존 코드는 수정 없이 계속 작동

이것은 Newtonsoft.Json 13.0.1에 적용된 것과 동일한 완화 전략으로, 드롭인 교체로 12.0.2에 백포트된 것입니다.


기타 취약한 의존성

이 데모에는 Seal Security가 패치할 수 있는 다른 취약한 NuGet 패키지도 포함되어 있습니다:

log4net 2.0.5 - CVE-2018-1285 (CVSS 9.8 CRITICAL)

log4net의 XML 구성 파싱의 XML 외부 엔티티(XXE) 취약점. log4net 구성 파일을 제어할 수 있는 공격자는 다음을 수행할 수 있습니다:

  • 서버에서 임의의 파일 읽기
  • 서버 측 요청 위조(SSRF) 수행
  • 서비스 거부(DoS) 발생

System.Net.Http에 대한 참고: 표준 net9 데모에는 CVE-2017-0249에 대한 취약한 System.Net.Http 4.3.0 참조도 포함되어 있습니다. .NET 7에서 System.Net.Http는 BCL의 일부이고 독립 실행형 패키지 참조는 잔존 메타 패키지이므로 이 net7 포크에서는 이를 생략했습니다 — dotnet add package --source <local-nupkg>(Seal CLI가 봉인된 버전을 적용하는 정확한 방식)에 알려진 엣지 케이스가 있습니다. 이를 제거하면 데모의 스토리를 변경하지 않고도 seal fix 단계가 안정적으로 작동합니다(HttpClient는 여전히 정상 작동하며 런타임이 제공합니다).


사전 요구 사항

  • .NET 7.0 SDK (Microsoft에서 다운로드)
  • Windows x64용 Seal Security CLI v0.3.238 (직접 다운로드)

    Windows CLI 바이너리는 v0.3.238 이후로 중단되었습니다. v0.3.238은 Windows에서 NuGet 수정에 완전히 기능합니다.

  • Seal Security 토큰 (Seal 대시보드에서)

자세한 Windows Server 설치 및 실행 가이드는 README-WINDOWS-SERVER.md에 있습니다. 아래의 빠른 시작은 동일한 단계를 간결한 형태로 다룹니다.


빠른 시작 (로컬 Windows Server)

1. 환경 변수 설정

PowerShell:

root@kitploit:~
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"

2. 취약한 앱 실행 (Seal 적용 전)

root@kitploit:~
cd seal-security-nuget-demo-net7

# 복원 (nuget.org 및 Seal 피드에서 가져옴 — nuget.config 참조)
dotnet restore

# 빌드 및 실행
dotnet build
dotnet run

http://localhost:5000을 엽니다 — 앱이 취약한 의존성으로 실행 중입니다.

정상 입력으로 테스트

이름 필드에 alice를 입력하고 Go를 클릭합니다. "Welcome, alice!" 가 표시되어야 합니다.

익스플로잇 페이로드로 테스트

이름 필드에 다음 URL을 붙여넣고 Go를 클릭합니다:

root@kitploit:~
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

패치 전 결과: 브라우저에 오류 / 연결 재설정이 표시됩니다 — 앱이 JsonSerializerInternalReader.CreateValueInternal에서 StackOverflowException으로 충돌했습니다. 프로세스가 종료되었습니다.

3. Seal Security 수정 적용

root@kitploit:~
# (선택 사항 — 위에서 이미 수행) 먼저 의존성 복원
dotnet restore

# 취약점 수정을 위해 Seal CLI 실행
seal fix . --mode remote -v

# 봉인된 버전을 가져오기 위해 다시 복원
dotnet restore

# 패치된 앱 빌드 및 실행
dotnet build
dotnet run

이제 앱은 패치된 버전(Newtonsoft.Json 12.0.2-sp1, log4net 2.0.5-sp1)을 사용합니다.

패치 후 결과: 동일한 익스플로잇 URL을 붙여넣으면 페이지에 "Blocked by Seal patch: MaxDepth of 64 has been exceeded." 가 표시됩니다 — Newtonsoft.Json의 패치된 재귀 제한이 깊은 페이로드를 거부했습니다. 서버는 정상적으로 계속 실행됩니다.

4. 패치된 버전 확인

root@kitploit:~
dotnet list package

Seal Security 패치를 나타내는 -sp1 접미사가 있는 패키지가 표시되어야 합니다.


Seal Security CLI 통합

핵심 규칙

CLI 단계는 의존성이 설치된 직후, 그러나 최종 빌드 이전에 추가되어야 합니다.

root@kitploit:~
# 1. 의존성 복원
dotnet restore

# 2. <--- 여기서 Seal CLI 실행
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"
seal fix . --mode remote -v

# 3. 다시 복원 (봉인된 버전을 가져오기 위해)
dotnet restore

# 4. 빌드
dotnet build

수정 모드

모드설명
all사용 가능한 모든 수정 사항을 자동으로 적용
remoteSeal UI에서 승인된 수정 사항만 적용
local.seal-actions.yml에 정의된 수정 사항만 적용

이 저장소의 .seal-actions.yml은 이미 local 모드에 대한 세 가지 봉인된 재정의를 나열하므로 seal fix . --mode local -v는 오프라인에서 작동합니다(아티팩트 서버에는 여전히 토큰 필요).


아티팩트 서버 구성

nuget.config 설정

nuget.config는 환경 변수와 함께 Seal Security를 사용하도록 사전 구성되어 있습니다:

root@kitploit:~
<configuration>
  <packageSources>
    <add key="Seal" value="https://nuget.sealsecurity.io/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <Seal>
      <add key="Username" value="%SEAL_PROJECT%" />
      <add key="ClearTextPassword" value="%SEAL_TOKEN%" />
    </Seal>
  </packageSourceCredentials>
</configuration>

필수 환경 변수

변수설명
SEAL_TOKENSeal Security 액세스 토큰
SEAL_PROJECT프로젝트 ID (예: nuget-demo-net7)

네트워크 허용 목록 (제한된 환경용)

Seal CLI는 다음에 대한 아웃바운드 HTTPS(TCP 443)가 필요합니다:

  • cli.sealsecurity.io — 스캔 / 수정 구성
  • authorization.sealsecurity.io — 토큰 검증
  • nuget.sealsecurity.io — 봉인된 .nupkg 다운로드
  • d2zko6i8myndc4.cloudfront.net — 실제 봉인된 아티팩트를 제공하는 CDN (.sealsecurity.io 호스트 이름이 여기로 리디렉션됨)
  • api.nuget.org / 표준 nuget.org 엔드포인트 — 봉인되지 않은 의존성용

방화벽이 열린 후 PowerShell에서 확인:

root@kitploit:~
Test-NetConnection cli.sealsecurity.io -Port 443
Test-NetConnection authorization.sealsecurity.io -Port 443
Test-NetConnection nuget.sealsecurity.io -Port 443
Test-NetConnection d2zko6i8myndc4.cloudfront.net -Port 443

모두 TcpTestSucceeded: True를 보고해야 합니다.


.NET 7 관련 참고 사항

항목중요한 이유
global.json이 SDK를 rollForward: latestFeature로 7.0.x에 고정net8/net9이 병렬 설치된 머신이 데모 중에 SDK를 조용히 전환하는 것을 방지합니다.
System.Configuration.ConfigurationManager가 7.0.0으로 고정표준 net9 데모는 8.0.0을 사용하는데, 이는 net8만 대상으로 하며 net7에서 복원에 실패합니다. 7.0.0은 log4net이 필요로 하는 동일한 API 표면을 가지고 있습니다.
csproj에서 NU1701 억제log4net 2.0.5는 .NET 7이 런타임에서 수용하지만 복원 시 경고하는 레거시 net4x TFM을 광고합니다. 경고는 표면적인 것이며, 억제는 데모 중 빌드 출력을 깨끗하게 유지합니다.
Windows x64용 Seal CLI v0.3.238Windows 바이너리가 있는 마지막 릴리스; NuGet 수정에 완전히 기능합니다. Windows 바이너리는 이 버전 이후로 중단되었으므로 최신 릴리스를 제안하지 마십시오.

데모 핵심 포인트

  • 코드 변경 없음 — 애플리케이션 코드는 패치 전 버전과 동일합니다. NuGet 패키지 버전만 교체되었습니다.
  • 동일한 API — 12.0.2-sp1은 12.0.2에 대한 바이너리 호환 드롭인 교체입니다.
  • 고객의 실제 스택을 대상으로 함 — net9.0이 아닌 net7.0. SDK 업그레이드가 필요 없습니다.
  • 심층 방어 — 전이적 의존성을 포함한 모든 코드 경로를 보호합니다.
  • 공개 패치 — 모든 패치는 오픈 소스이며 감사 가능합니다.
  • EOL .NET도 패치됨 — 이것이 핵심 가치입니다: Microsoft는 더 이상 .NET 7에 대한 보안 업데이트를 제공하지 않지만, Seal은 고객의 기존 의존성 표면을 안전하게 유지합니다.

사용 가능한 봉인된 NuGet 패키지

이 데모에서 사용되는 패키지:

패키지취약한 버전봉인된 버전CVECVSS
Newtonsoft.Json12.0.212.0.2-sp1CVE-2024-219077.5 HIGH
log4net2.0.52.0.5-sp1CVE-2018-12859.8 CRITICAL

Seal 피드에서 사용 가능한 기타 봉인된 NuGet 패키지(이 데모에는 없음, 참고용으로 나열):

패키지취약한 버전봉인된 버전CVECVSS
log4net2.0.02.0.0-sp1CVE-2018-12859.8 CRITICAL
System.Net.Http4.3.04.3.0-sp1CVE-2017-02497.3 HIGH
Snappier1.1.01.1.0-sp1CVE-2023-286387.0 HIGH
jQuery.Validation1.17.01.17.0-sp1CVE-2021-212527.5 HIGH

라이선스

MIT 라이선스 — 자세한 내용은 LICENSE 파일을 참조하십시오.

도구 다운로드