mcpField
H
hunt-aspnet

hunt-aspnet

github.com/uphiagoセキュリティ1.3k40 回インストール8 週間前に更新
リポジトリ

hunt-aspnet について

hunt-aspnetは、バグバウンティ研究者やペネトレーションテスター向けのASP.NETセキュリティ評価スキルです。デシリアライズのリスク、公開された診断エンドポイント、放置されたサービスなどを調べる手順を示します。

主な機能

  1. 01ASP.NETの指紋確認とバージョン調査
  2. 02ViewStateのデシリアライズ評価
  3. 03診断エンドポイントの公開確認
  4. 04WCFとTelerikの攻撃面調査
  5. 05リクエストバリデーターの回避テスト
  6. 06誤検知を抑える検証手順

活用シーン

  1. 01WebFormsのViewState処理の評価
  2. 02trace.axdとelmah.axdの公開確認
  3. 03WCFサービスメタデータの列挙
  4. 04TelerikとSharePointの攻撃面の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uphiago/recon-skills --skill hunt-aspnet

インストール後、Claude Code で/hunt-aspnetを入力して読み込まれたか確認します。

詳細

最重要のターゲット

ASP.NET のデシリアライズの脆弱性は、RCE に至るとバグバウンティで最も高額な報奨金が支払われます。パッチ適用済みの場合でも、開示対象となる調査結果(署名のみの ViewState、二重パーサーの差異、リクエスト検証の癖)には、安定して Low-Medium の報奨金が支払われます。

最も価値の高いターゲット:

  • SharePoint ファーム(すべてのバージョン — 2013/2016/2019/SE)— 署名のみの ViewState + 制限の緩い ToolPane.aspx + 匿名の FormDigest により、CVE-2025-53770 ToolShell の前提条件となる一連の条件がそろいます
  • ASP.NET AJAX 用 Telerik UI — キーが漏えいした場合、Telerik.Web.UI.WebResource.axd は RCE のシンクとして文書化されています(CVE-2017-11317、CVE-2017-11357、CVE-2019-18935)
  • 従来型の ASP.NET Webforms エンタープライズアプリ — .NET Framework 4.x のまま使われている銀行ポータル、ディーラーポータル、人事システム
  • WCF サービス(*.svc?WSDL)— メインアプリより認証が緩い、忘れられた管理エンドポイントであることがよくあります
  • Sitecore CMS — ViewState と Sitecore 固有のデシリアライズチェーン(CVE-2021-42237)
  • DotNetNuke(DNN) — 過去に存在した ViewState RCE チェーン
  • Umbraco CMS — ViewState とカスタムのデシリアライズシンク

最も報奨金が高いアセットの種類: インターネットからアクセス可能な ASP.NET Webforms アプリ > WCF 管理サービス > Telerik 統合サイト > VSF を使用する従来型 ASP.NET MVC(非常にまれ)


攻撃対象領域の兆候

ASP.NET を示すレスポンスヘッダー:

X-AspNet-Version: 4.0.30319          (classic — disclosure on its own)
X-Powered-By: ASP.NET
X-AspNetMvc-Version: 5.2
Server: Microsoft-IIS/10.0
Set-Cookie: ASP.NET_SessionId=...
Set-Cookie: .ASPXAUTH=...            (Forms auth cookie)
Set-Cookie: .ASPXFORMSAUTH=...
Set-Cookie: ASP.NET_SessionId=...; SameSite=None  (suggests cross-origin embedding)

本文に現れる兆候(フォーム HTML 内):

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="..." />
<input type="hidden" name="__VIEWSTATEENCRYPTED" id="__VIEWSTATEENCRYPTED" value="" />
                                        ↑ EMPTY = signed-only, not encrypted = exploitable if key leaks
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="..." />
<input type="hidden" name="__REQUESTDIGEST" id="__REQUESTDIGEST" value="0x...,...">
                                        ↑ SharePoint CSRF token; if anon-issued, see hunt-sharepoint

調査する URL パターン:

/trace.axd                            (per-app trace viewer; sometimes anon-accessible)
/elmah.axd                            (ELMAH error log viewer)
/elmah.axd/?id=...                    (ELMAH RCE / stack-trace leak)
/*.svc                                (WCF services)
/*.svc?wsdl                           (WCF WSDL)
/*.svc/mex                            (Metadata Exchange)
/*.asmx                               (legacy SOAP)
/*.asmx?WSDL                          (legacy SOAP description)
/*.asmx?disco                         (legacy discovery)
/Telerik.Web.UI.WebResource.axd       (Telerik AJAX components)
/ChartImg.axd                         (DataVisualization controls; historic deserialization)
/ScriptResource.axd                   (script resource handler; sometimes leaks paths)
/WebResource.axd                      (web resource handler)
/_vti_bin/*                           (SharePoint Web Service Forwarder)
/api/                                 (Web API 2.x is ASP.NET on classic framework)
/signin                               (often FedAuth / WS-Federation)

技術スタックの兆候:

  • Server: Microsoft-IIS/10.0(または /8.5、/7.5)— Windows + IIS であることが確認できます
  • X-AspNet-Version ヘッダー — 従来型の .NET Framework(4.x)です。.NET Core/5+ ではこのヘッダーは出力されません
  • ASP.NET_SessionId、.ASPXAUTH、FedAuth を含む Cookie — Forms 認証またはクレーム認証です
  • フォーム本文内の __VIEWSTATE — Webforms です(MVC、Razor Pages、Blazor ではありません)
  • MicrosoftSharePointTeamServices ヘッダー(ELB によって削除されることがありますが、start.aspx の本文から漏れる場合があります)— SharePoint です

ステップごとの調査手法

  1. フレームワークのバージョンを特定します。 なんらかの 500 エラーを発生させ(古い ViewState の POST が確実な方法です)、エラー本文内にある Version Information: Microsoft .NET Framework Version:X.X.XXXXX; ASP.NET Version:X.X.XXXX.X を探します。このバナーから、ランタイムと ASP.NET のバージョン固有のパッチレベルの両方が判明します。.NET 4.0.30319 + ASP.NET 4.8.x が、現在最も一般的な組み合わせです。

  2. __VIEWSTATE を含むすべてのフォームを特定します。 ターゲットをクロールし、name="__VIEWSTATE" を grep します。MAC / 暗号化を回避できる場合、それぞれがデシリアライズ攻撃の候補となるシンクです。

  3. __VIEWSTATEENCRYPTED の値を確認します。 空(value="")の場合、ViewState は <machineKey> による署名のみで、暗号化されていません。検証キーを復元できれば、任意のデシリアライズが可能になります。空でない(value="something")場合、ViewState は署名と暗号化の両方が施されています。偽造には両方のキーが必要です。

  4. ViewState のパーサーエラーの差異(二重パーサーのアンチパターン)をテストします。 7 種類以上の ViewState 形式を送信し、レスポンスを分類します。

    • 単純なガベージ(AAAA)→ "Validation of viewstate MAC failed"
    • 現在のページから取得した実際のプレフィックス → "Validation of viewstate MAC failed"
    • 実際の ViewState のビットを反転したもの → "Validation of viewstate MAC failed"
    • サイズ超過(A * 100000)→ "Validation of viewstate MAC failed"
    • XML 形式(<xss/>)→ "The state information is invalid for this page and might be corrupted" ← 異なるパーサーパス
    • LosFormatter 形式のプレフィックス(/wEPDwUKMTcxNzgyOTQwMmRkkz9p4lzA...)→ "The state information is invalid for this page and might be corrupted"

    この差異は、2 つの異なるデシリアライズの入口があり、そのうち 1 つは一部のペイロード形式で MAC チェックより前に処理を振り分けることを証明しています。過去には、これによって MAC チェック前にパースを回避するエクスプロイトが可能になりました。

  5. ノード間ロードバランシングによる ViewState MAC エラーを探します。 POST が 500 を返し、"Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey..." が表示される場合、ファーム内に machineKey が同期されていない複数の WFE があるか、スティッキーセッションのアフィニティがありません。運用上、正規ユーザーに支障をきたします。セキュリティ上は、ファームのトポロジーが確認できます。

  6. trace.axd と elmah.axd を調べます。 どちらかが認証なしで 200 を返す場合、重大な指摘事項です(trace はすべてのリクエスト、ヘッダー、フォームデータを漏えいし、ELMAH はスタックトレースを含むすべてのサーバーエラーを漏えいします)。

  7. WCF サービス(.svc)を列挙します。 各サービスについて、?wsdl と ?mex(メタデータ交換)を取得します。MEX エンドポイントが、管理操作を含むサービスコントラクト全体を返すことがあります。

  8. リクエストバリデーターのバイパスをテストします。 ASP.NET のリクエストバリデーターは、デフォルトでクエリ文字列内の < をブロックします。バイパスできる可能性があるパターンは次のとおりです。

    • HTML エンティティでエンコードしたペイロード(&lt;script&gt; — ただし、これらは実行されません)
    • JSON / XML の POST ボディ内にエンコード(Content-Type が異なれば、同じバリデーターが適用されるとは限りません)
    • パスセグメント内(クエリ内ではない)— バリデーターの適用範囲はフレームワークのバージョンによって異なります
    • Cookie / Referer ヘッダー内(動作は異なります)
    • WebDAV PUT 経由でアクセスした場合の <%@ ... %> ASP ディレクティブ内(まれです)
  9. customErrors モードを確認します。 500 エラーで完全なスタックトレース、フレームワークのバージョン、ファイルパス、内部メソッド名が露出する場合は、customErrors mode="Off" が設定されています。本番環境では RemoteOnly にする必要があります。

  10. Telerik コンポーネントを探します。 Telerik.Web.UI.WebResource.axd?type=rau は、過去に悪用されたアップロードから RCE につながるチェーンです(CVE-2017-11317)。dialogParametersHolder パラメータのチェーン(CVE-2019-18935)には暗号化キーが必要ですが、それ以外の条件では RCE につながります。

  11. SharePoint 固有のデシリアライズ経路 — ToolPane.aspx + 匿名 FormDigest + 暗号化されていない ViewState のチェーンについては、hunt-sharepoint スキルを参照してください。

  12. リフレクションによる SafeControl の列挙。 SharePoint の Picker.aspx?PickerDialogType=<TypeName>(および DNN 相当のエンドポイント)は、クラス名を受け取り、「型は存在するが許可リストにない」場合と「型が存在しない」場合で異なるエラーメッセージを返します。Microsoft.SharePoint.*.WebControls.* 型のワードリストを入力して SafeControl の一覧を列挙します。これは CVE-2019-0604 系の調査に役立ちます。


ペイロードと検出パターン

スタックトレースのフィンガープリント(古い ViewState を使った POST でトリガー):

curl --max-time 30 --connect-timeout 10 -sk -X POST "https://target.example/page.aspx" \
  --data "__VIEWSTATE=AAAA&__VIEWSTATEGENERATOR=AAAA"
# Inspect body for:
#  - "Validation of viewstate MAC failed" → confirms signed ViewState
#  - "The state information is invalid for this page" → confirms ALTERNATE parser path
#  - "Version Information: Microsoft .NET Framework Version:X.X.XXXXX" → exact patch level
#  - "Microsoft.SharePoint.Client.ServerStub..." → SharePoint farm

ViewState パーサーエラーの差分プローブ(Python):

import requests, re, json
S = requests.Session(); S.verify = False
# Get fresh form
r = S.get("https://target.example/path/page.aspx")
real_vs = re.search(r'__VIEWSTATE" id="__VIEWSTATE" value="([^"]+)', r.text).group(1)
real_vsg = re.search(r'__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="([^"]+)', r.text).group(1)

# Test 7 payload shapes
for label, vs in [
    ("trivial",      "AAAA"),
    ("real",         real_vs),
    ("flipped-bit",  real_vs[:50] + "X" + real_vs[51:]),
    ("oversize",     "A" * 100000),
    ("base64",       "VGVzdE1hcmtlcjY3OFhZWg=="),
    ("xml-shaped",   "<xss/>"),
    ("losformatter", "/wEPDwUKMTcxNzgyOTQwMmRkkz9p4lzA" + "A"*50),
]:
    r = S.post("https://target.example/path/page.aspx",
               data={"__VIEWSTATE": vs, "__VIEWSTATEGENERATOR": real_vsg})
    title = re.search(r'<title>([^<]+)</title>', r.text)
    title = title.group(1)[:100] if title else "—"
    print(f"  [{label:14s}] {r.status_code}  {title}")

trace.axd の匿名アクセス確認:

curl --max-time 30 --connect-timeout 10 -sk -o /dev/null -w "%{http_code}\n" "https://target.example/trace.axd"
# 200 = full trace dump exposed → Critical
# 403 = mod set to localhost-only → check via X-Forwarded-For: 127.0.0.1

WCF サービスの列挙:

# Find all .svc files
curl --max-time 30 --connect-timeout 10 -sk "https://target.example/" -o body.html
grep -oE '/[a-zA-Z0-9/_-]+\.svc' body.html | sort -u
# For each found:
curl --max-time 30 --connect-timeout 10 -sk "https://target.example/Service.svc?wsdl" | xmllint --format - | head -60

リクエストバリデーターのバイパスパターン:

# Default: <script>alert(1)</script> in ?q= → "Potentially dangerous Request.QueryString value detected"
# Bypasses that sometimes work:
?q=%3cscript%3e            (URL-encoded — depends on validator config)
?q=<svg/onload=alert(1)>  (depends on validator version)
?q=<%00script>             (NUL-byte; older validators)
?q=javascript:alert(1)     (no < at all — passes validator)
Cookie: foo=<script>       (cookie body not validated by default)
Referer: http://x.com/<script>  (referer not validated in classic ASP.NET)

Telerik のエクスプロイト条件(CVE-2019-18935 — 暗号化キーが必要):

# Fingerprint Telerik
curl --max-time 30 --connect-timeout 10 -sk "https://target.example/Telerik.Web.UI.WebResource.axd?type=rau" -X POST
# If response is RadAsyncUploadHandler-style → Telerik present; try keys
# Public exploits require leaked machineKey AND telerikEncryptionKey

よくある根本原因

  1. viewStateEncryption="Auto" は、機密性の高い ViewState データがないページでは、デフォルトで署名のみになります。 多くの SharePoint ページはこのように設定されています。__VIEWSTATEENCRYPTED が空の場合、ViewState は署名のみです。validationKey を復元できれば、偽造が可能になります。

  2. Web ファームでの <machineKey> AutoGenerate。 各 WFE は初回起動時に異なるキーを生成します。ある WFE が発行した ViewState は、別の WFE では MAC 検証に失敗します。運用面では 500 エラーが発生し、セキュリティ面ではトポロジーが露呈します(エラーメッセージにクラスター名が表示されます)。

  3. 開発時の <customErrors mode="Off"> をそのまま残している。 メソッド名、ファイルパス、バージョン情報を含むスタックトレースが、匿名のインターネットユーザーに公開されます。

  4. 本番環境で trace.axd / elmah.axd を有効なままにしている。 <system.web><trace enabled="true"> ブロックに残され、忘れられていることがよくあります。

  5. 忘れられた WCF .svc 管理エンドポイント。 内部の管理ツール用に作られ、メインアプリをインターネットに公開した際にも無効化されていません。

  6. デュアルパーサーのアンチパターン:ObjectStateFormatter(レガシー)と LosFormatter(モダン)では、MAC 検証との前後関係が異なる順序でデシリアライズされます。 一部のペイロード形式では、MAC チェックより先にレガシーパーサーが実行されます。

  7. リクエストバリデーターが適用されるのは、URL エンコードされたボディとクエリ文字列のみです。 ヘッダー、Cookie、XML/JSON ボディ、multipart フィールドは、デフォルトでは検証されません。開発者はバリデーターがすべてに適用されると思いがちですが、そうではありません。

  8. <machineKey> をソースリポジトリにコミットしている。 GitHub に設定をコミットすると、validation キーや decryption キーが漏洩することがよくあります。hunt-misc によるソース偵察と組み合わせて、Telerik / SharePoint / DNN のキーを探してください。

  9. SafeControls の web.config エントリを、デシリアライズを制御する仕組みとして信頼している。 SharePoint の <SafeControl> リストは、Picker.aspx がインスタンス化できるクラスを決定します。継承チェックだけが制御手段となっている場合、バイパスが存在します(CVE-2019-0604 系)。


バイパス手法

防御策バイパス
__VIEWSTATEENCRYPTED が空でない(暗号化済み)ソースコードの漏洩/設定情報の漏洩/VS フォージプリミティブなど、いずれかの情報源から decryption キーと validation キーの両方を復元します。キーがなければ、デシリアライズは発生させられません
リクエストバリデーターがクエリ文字列内の < をブロックするペイロードを Cookie / Referer / JSON ボディ / multipart ファイル名に移します。クラシック ASP.NET では、バリデーターはこれらのコンテキストに適用されません
EnableViewStateMac="true" が強制されているweb.config の情報漏洩、または <machineKey> AutoGenerate のフィンガープリンティングで validationKey を復元します(ysoserial.net の --minify --islegacy モードでは、一部の MAC 検証の欠落を通過する ViewState が生成されます)
trace.axd がローカルホストのみに制限されているトレースモードが localOnly で、Request.UserHostAddress を使って検証している場合は、X-Forwarded-For: 127.0.0.1 を設定します(Forwarded-For を使うアプリもあります)
WCF .svc が匿名アクセスに対して 401 を返すまず ?wsdl と ?mex を試します。サービス操作に認証が必要な場合でも、メタデータは匿名で列挙できることがあります
Telerik のアップロード機能にパッチが適用済みTelerik のバージョンを確認します。2017Q1 より前(ビルド 2017.1.118 以前)は、元の RAU RCE です。CVE-2019-18935 については 2017Q3~2019Q3 を確認します
SafeControl の許可リストが適用されている継承チェック(instanceof PickerDialog)が、パッチ適用済み SP での制御手段です。バイパスするには、デシリアライズシンクを持つ SafeControl サブクラスを見つける必要があります。Picker.aspx から列挙してください
customErrors mode="On"(スタックトレースなし)無効な Content-Length や、customErrors ハンドラーより下位でパーサーレベルの例外を発生させる不正な ViewState など、別のエラーパスを強制します

ゲート 0 の検証

レポートを作成する前に、次の点を確認してください。

  1. 開示された情報を使って、攻撃者は現時点で何ができますか?

    • trace.axd が 200 を返し、完全なリクエストダンプが見られる → Critical(PII/セッション Cookie/Authorization ヘッダーが露出)
    • elmah.axd が 200 を返し、エラーログが見られる → High(スタックトレース+内部パス+場合によっては認証情報)
    • __VIEWSTATEENCRYPTED が空で、別の検出結果から machineKey を復元できる → Critical な RCE につながる連鎖
    • __VIEWSTATEENCRYPTED が空でも、キーを復元できない → Low-Medium(プリミティブは存在しますが、それ単独では悪用できません)
    • 500 エラーにスタックトレースが含まれる → Low(認証情報/接続文字列が含まれる場合を除く)
  2. 攻撃者が到達可能な影響に至る連鎖全体を再現しましたか。それともプリミティブだけですか?

    • triage-validation の Pre-Severity Gate と照合してください。「プリミティブを確認」しただけでは、影響に至る連鎖が完了するまで Critical にはなりません。
  3. トリアージ担当者は、レポートを見て 10 分以内に再現できますか?

    • 各手順は curl/Python でコピー&ペーストできるようにしてください。
    • RCE の連鎖では、公開されているエクスプロイトツールチェーン(ysoserial.net、viewgen、telerik-revda)と、具体的なガジェットチェーンへのリンクを記載してください。

影響の実例

シナリオ A — サポート終了後の SharePoint 2013 で、署名のみの ViewState と制限の緩い ToolPane

https://target-portal.example/_layouts/15/ToolPane.aspx?DisplayMode=Edit は匿名でアクセスしても 200 を返します。フォームには __VIEWSTATE(署名のみで、__VIEWSTATEENCRYPTED="")が含まれており、__REQUESTDIGEST は _api/contextinfo 経由で匿名発行されます。SP2013 がサポート終了済みで、パッチが今後提供されることはないため、この組み合わせは恒久的に未パッチのコードパスにおける CVE-2025-53770「ToolShell」の典型的な前提条件の連鎖です。報告された深刻度:Critical。デュアルパーサーテスト(手法のセクション 4)では、MAC 検証の前に XML 形式のペイロードがレガシーの ObjectStateFormatter に到達することを確認しました。これは、machineKey を完全に復元できなくても連鎖が到達可能であることを示す追加の証拠です(ただし、完全な RCE には両方が必要です)。

シナリオ B — レガシーな銀行ポータルで Telerik RadAsyncUploadHandler が露出

/Telerik.Web.UI.WebResource.axd?type=rau は Telerik のアップロードハンドラーを返します。Telerik のバージョンは(JS バンドルのメタデータで確認できるとおり)2016.3.1027 です。CVE-2017-11317 が該当し、そのバージョンの公開 Telerik DLL にはキーが組み込まれています。アップロード → /app_data/ に aspx を書き込み → リクエスト → RCE。報告された深刻度:Critical。

シナリオ C — エンタープライズ人事ポータルで trace.axd と elmah.axd の両方が露出

trace.axd は 200 を返し、直近 50 件のリクエストを表示します。その中には、API リクエストの Authorization: Bearer eyJ... ヘッダーが含まれています。elmah.axd は 200 を返し、例外の 1 つにデータベース接続文字列を含む完全なエラーログを表示します。報告された深刻度:Critical(認証情報が平文で匿名のインターネットユーザーに公開)。


検証

ASP.NET の調査準備が整っていることを確認するため、次のセルフテストを実行してください。

  1. ViewState の検出 — __VIEWSTATE パターンの認識を確認:

    echo '<input type="hidden" name="__VIEWSTATE" value="dDwtMTc5MjU3NjY0Mzt0PDtsPGk8MT47PjtsPHQ8O2w8aTwxPjs+O2w8dDw7bDxpPDE+Oz47bDx0PDtsPGk8MT47PjtAPDEyMzQ1Njc4OTA7Pj47Oz47Pj47Pj47Pg==" />' | grep -q "__VIEWSTATE" && echo "PASS: ViewState pattern detected" || echo "FAIL"
    
  2. ViewState の暗号化チェック — 暗号化と署名のみの違いを識別できることを確認:

    echo '__VIEWSTATEENCRYPTED=""' | grep -q 'VIEWSTATEENCRYPTED=""' && echo "PASS: signed-only recognized" || echo "FAIL"
    
  3. trace.axd のプローブ構文 — プローブが機能することを確認:

    echo "trace.axd" | grep -q "trace.axd" && echo "PASS: trace.axd path syntax correct" || echo "FAIL"
    
  4. Telerik RAU エンドポイントの構文 — Telerik ハンドラーのパスを確認:

    echo "/Telerik.Web.UI.WebResource.axd?type=rau" | grep -q "rau" && echo "PASS: Telerik RAU path syntax correct" || echo "FAIL"
    

4 つすべてのテストで、ASP.NET の攻撃対象領域を検出する機能を検証できます。


落とし穴

  • 署名のみの ViewState と暗号化された ViewState の混同 — __VIEWSTATEENCRYPTED="" が存在する場合、または存在しない場合は、署名のみです。これはプリミティブであり、RCE ではありません。完全な RCE には machineKey の復元が必要です。
  • ViewState MAC の検証は 2 つのパーサーで行われます — 二重パーサーのアンチパターンでは、レガシーの ObjectStateFormatter が LosFormatter による MAC 検証より前に解析します。XML 形式のペイロードは、MAC の有効性に関係なくレガシーパーサーに到達します。両方をテストしてください。
  • 認証情報なしで trace.axd が 200 を返す — スタックトレースのみであれば、重大度はせいぜい低です。トレース出力に実際の Authorization ヘッダー、セッション Cookie、または接続文字列が含まれる場合に限り、重大度はクリティカルです。
  • 古いエラーが残る elmah.axd — 数週間前のエラーで、現在有効な認証情報が含まれていないものは、情報提供にとどまります。重大度を主張する前に、タイムスタンプと内容を確認してください。
  • リポジトリ内の web.config にある MachineKey は、稼働中のキーとは限りません — デプロイ済みサーバーでは、リポジトリ内のバージョンとは異なる machineKey が使われている可能性があります。報告する前に、ViewState の偽造を試みて検証してください。
  • SharePoint の ToolPane に匿名でアクセスできても、FormDigest が必要です — ToolPane に到達可能であることは前提条件であり、脆弱性そのものではありません。完全な攻撃チェーンには、ToolPane + 匿名の FormDigest + 署名のみの ViewState + machineKey が必要です。
  • JS バンドルから分かる Telerik のバージョンは、悪用可能性を示すものではありません — JS バンドルのバージョンはクライアント側ライブラリのバージョンであり、サーバー側の Telerik DLL のバージョンではありません。WebResource.axd のレスポンスヘッダーを使ってサーバーのバージョンを確認してください。
  • customErrors mode="On" の処理 — customErrors によってスタックトレースが隠されていても、ハンドラーレイヤーより下のパーサーレベルの例外から情報が漏れる場合があります。不正な Content-Length、サイズ超過の ViewState、エンコードエラーをテストしてください。

関連スキルと攻撃チェーン

  • hunt-rce — ViewState のデシリアライズは、ASP.NET における主要な RCE 経路です。署名のみの ViewState + 漏えいした machineKey があれば、毎回 RCE に至ります。攻撃チェーンのプリミティブ:ASP.NET ViewState の二重パーサーによる MAC バイパスのアンチパターンを検出(署名済みだが暗号化されていない、<%@ Page enableViewStateMac="true" viewStateEncryptionMode="Never" %>)+ machineKey の復元(web.config の開示、elmah.axd、ソースの漏えい、または GitHub から)→ hunt-rce の ysoserial.net TypeConfuseDelegate ガジェット → w3wp.exe ワーカープロセスの ID で任意のコマンドを実行。
  • hunt-sharepoint — SharePoint ファームは、あらゆる ASP.NET のアンチパターンに加え、独自の攻撃対象領域も引き継ぎます。攻撃チェーンのプリミティブ:ASP.NET のフィンガープリントで SharePoint を特定(X-SharePoint ヘッダー + /_layouts/ に到達可能)→ 汎用的な ViewState 攻撃の前に、hunt-sharepoint に切り替えて SharePoint 固有の RCE 経路(ToolShell、SafeControl のリフレクション)を調査。
  • hunt-ntlm-info — NTLM/Negotiate を匿名で提示する IIS サイトからは、AD のトポロジーが漏えいします。攻撃チェーンのプリミティブ:IIS の背後にある ASP.NET アプリで WWW-Authenticate: NTLM を確認 → hunt-ntlm-info で Type-2 チャレンジを取得 → 内部フォレスト名を特定 → m365-entra-attack の探索結果と照合して Entra テナントを特定。
  • hunt-file-upload — Telerik RadAsyncUpload、Kentico、Umbraco、DotNetNuke には、過去にアップロードハンドラーを経由した RCE がありました。攻撃チェーンのプリミティブ:ASP.NET CMS をフィンガープリントで特定 → CMS のアップロードハンドラーに対して hunt-file-upload のバイパスマトリクスを適用 → Web からアクセス可能なパスに .aspx を書き込み → リクエストを送信 → アプリケーションプールの ID で RCE。
  • triage-validation — trace.axd/elmah.axd による情報漏えいがクリティカルとなるのは、実際に有効な認証情報やトークンが漏えいしている場合に限られます。スタックトレースのみなら、通常は重大度が低いです。攻撃チェーンのプリミティブ:報告されたすべての所見を提出前に triage-validation の 7 問ゲートに通し、レポート(redteam-report-template)を書く前に、「詳細なエラー」(情報提供)と「エラーログ内の有効なベアラートークン」(クリティカル)を区別してください。

コメント