DNN（別名DotNetNuke）9.1.1より前のバージョンでは、Cookieを介したリモートコード実行が可能です。「2017-08（重要）DNN Webサイトでリモートコード実行が可能」とも呼ばれます。
DotNetNukeとは？
DotNetNukeは、C#で書かれ、.NET基盤に基づく無料のオープンソースWeb CMS（コンテンツ管理システム）です。技術的な知識がほとんどなくても数分でDNN Webバージョンを展開できるため、DotNetNukeはインターネット上で非常に人気があり、広く使用されています。DotNetNukeのもう1つの重要な機能は、VB.NETまたはC#で構築されたサードパーティ製のカスタムモジュールを作成またはインポートできることです。
DNNは、Windows向けにWindows Server、IIS、ASP.NET、SQL Serverを含むスタック上にインストールできます。DNNは新規ユーザーのメールによる確認登録もサポートしていますが、このセキュリティ機能を機能させるには、有効なSMTPサーバーを構成する必要があります。
DNNの主な機能
• モジュラーアーキテクチャ: DNNは、コミュニティが開発したモジュール（機能モジュール）を追加インストールすることで簡単に拡張できます。管理者は管理画面から新しいモジュールをアップロード（.zipパッケージ）するか、サーバー上のディレクトリに直接展開してインストールできます。
• ユーザー管理: このシステムは、ポータルとモジュールに対して詳細なセキュリティと権限設定（ロール/権限）の機能を提供します。ユーザーアカウント、ロール、権限はDNN内で集中的に管理されます。
• コンテンツ管理: WYSIWYG編集、記事・画像・ドキュメントの管理をサポートします。ワークフロー/公開システム（承認プロセスに沿った投稿）とコンテンツのバージョン管理を備えています。コンテンツは共通のデータベース（SQL Server）に保存されます。
• APIと拡張統合: DNNは、開発者がカスタムモジュール（WebForms、MVC、Razor）を開発し、外部サービスと統合するための.NET APIを提供します。多数のサードパーティライブラリ（テーマ、ECモジュール、フォーラムなど）が利用可能で、機能を拡張できます。
• インターフェースとテーマ: スキン（テーマ）システムはコンテンツとインターフェースを分離し、柔軟なWebデザインを可能にします。DNNで作成されたWebサイトは、スキンを変更することで外観を変更できます。
• モジュールインストールの仕組み: DNNモジュールはZIPファイルにパッケージ化され、管理画面からインストールするか、手動で展開してインストールできます。DNNはコンパイル済みモジュール（.NET DLL）と動的Razorモジュールの両方をサポートします。すべてのモジュールは、各ページの権限設定を通じてアクセスを許可または取り消すことができます。
オペレーティングシステム: Windows 10
.NET Framework: 4.5.1+
Web サーバー: Microsoft IIS 10
データベースサーバー: Microsoft® SQL Server® 2019 Express, SQL Server Management Studio
Dotnetnuke バージョン 9.1.0
次のGoogle dorksを使用すると、インターネット上で利用可能なDotnetnukeの展開バージョンを見つけ、Webサイトに基づいて確認できます。
inurl:dnn.js
inurl:dnn.modalpopup.js
inurl:dnn.servicesframework.js
inurl:dnn.xml.js
inurl:dnncore.js
inurl:/Portals/0/
inurl:/DesktopModules/
inurl:/DNNCorp/
inurl:/DotNetNuke
inurl:/tabid//Default.aspx
inurl:/tabid//language/*/Default.aspx
intext:"by DNN Corp "
環境構築はこの記事に従って行えます
アセンブリの属性を「デバッグ可能」な属性に変更します。これは、実行時に一部の最適化が適用され、デバッグの妨げになる可能性があるため非常に重要です。一部のブレークポイントがヒットしなかったり、一部の変数が存在しないことがあります。 dnSpy（32ビット）でDotNetNuke.dllを読み込み、[Edit Assembly Attributes (C#)] を選択します。
次の行を
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
から
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
に変更します。
次に、[Compile] を選択し、このモジュールを元の場所に保存します。 次に、dnSpyを管理者権限で起動し、[Debug] -> [Attach to Process] を選択します。
プロセスw3wp.exeを選択します。
このプロセスにアタッチしてデバッグする理由は、IIS上のWebアプリケーションが通常ワーカープロセスを使用するためです。ワーカープロセスは、各アプリケーションプールに対してIIS Webサーバーに送信されたWebリクエストを処理する役割を担います。ワーカープロセスは1台のマシンに複数存在でき、すべて同じ名前 w3wp.exe です。注意点として、w3wpプロセスが実行されていない場合があります。IISは最初のWebリクエストを受信するまでワーカープロセスを起動しないからです。
デバッグの話に戻ります。プロセスにアタッチした後、[Debug] -> [Windows] -> [Modules] を選択します。
モジュールをクリックし、[Open All Modules] を選択します。
これでAssemblyウィンドウに、関連するすべてのモジュールが表示されます。
デシリアライズとは、バイトストリームを解釈し、アプリケーションが実行可能なデータに変換するプロセスです。 デシリアライズの主な問題は、ほとんどの場合、ユーザー入力データを使用できることです。つまり、アプリケーションが要求する形式に悪意のあるペイロードを挿入でき、ロジックを操作したり、データを漏えいさせたり、さらにはリモートでコードを実行したりできる可能性があります。 DotNetNukeは、匿名ユーザーのパーソナライズ設定を保存するためにDNNPersonalization Cookieを使用します（認証済みユーザーの設定はプロファイルページを通じて保存されます）。レポートによると、この脆弱性はDNNPersonalization Cookieの処理部分で発生します。このCookieはユーザープロファイルを読み込むために使用されますが、存在しないページ（404エラー）にアクセスすると認証なしでもトリガーされる可能性があります。このバグのエントリーポイントは、DotNetNuke.dllモジュールのLoadProfile関数にあります。dnSpyでこのモジュールを逆コンパイルして、詳しく分析します。 PersonalizationController#LoadProfile(int, int) 内
userIdがnullでない場合、テキスト変数にリクエストのDNNPersonalization Cookieの値が代入され、Globals#DeserializeHashTableXmlが呼び出されます。
Globals#DeserializeHashTableXml は XmlUtils#DeSerializeHashtable を呼び出します。
処理の流れは次のとおりです:
Burpを使用して、404ステータスをトリガーするリクエストとDNNPersonalization Cookieを送信します。
ここでは、404を処理する関数 Handler404OrException が呼び出しチェーンをトリガーし、Personalization.LoadProfile(int,int) を呼び出していることがわかります。
上記のコードで注目すべき点は、現在のリクエストがIsAuthenticatedかどうかをチェックするif条件です。先ほど実行したリクエストは、存在しないエントリーポイントへの認証なしリクエストです。では、なぜ現在のリクエストが認証済みユーザーとして実行されるのでしょうか。 さらにデバッグを続け、スタックの末尾近くに戻ると、AdvancedUrlRewriter#Handle404OrExceptionに次のようなelse if分岐があります。
ここでは、現在のリクエストの context.User が null かどうかを確認し、null の場合は context.User に現在のスレッドユーザーを代入します。ブレークポイントを設定すると、次の結果が確認できます。
IsAuthenticated変数は現在trueになり、割り当てられたユーザーはIISサーバーのIIS APPPOOLグループに属する現在のスレッドを実行しているユーザーです。そのため、リクエストは認証済みユーザーとして実行されます。このロジックが存在する理由は、404ハンドラーがHttpContext.Userが設定される前に呼び出され、後続の処理フローがUser.IsAuthenticatedに依存するためです。Null参照エラーを避けるために、開発者はUserオブジェクトに現在のスレッドのWindowsPrinicipalオブジェクトを代入しています。
XmlSerializerは、Microsoft独自のシリアライズクラスで、XML文字列とオブジェクトの相互変換に使用されます。名前空間は System.Xml.Serialization です。 XmlSerializerの使用例:
XmlSerializerを介したRCE攻撃の条件は、XmlSerializerのコンストラクタに渡すデータ型を制御できることが必須です。つまり、ガジェットに到達するデータ型をXmlSerializer.mappingプロパティに渡す必要があります。
XMLデシリアライズ攻撃で最も一般的なガジェットは ObjectDataProvider です。このガジェットは ysoserrial .net ツールで作成できます。
基本的に、このクラスを使用すると、任意のクラスの任意のメソッドを呼び出すことができます。
たとえば、以下のようなパラメータを渡して Process.Start を呼び出すことができます。
ObjectDataProvider o = new ObjectDataProvider(); o.MethodParameters.Add("cmd.exe"); o.MethodParameters.Add("/c calc"); o.MethodName = "Start"; o.ObjectInstance = new Process(); Console.ReadKey();
上記のコードを使用して、XMLデシリアライズペイロードを構築します。
ResourceDictionary はWPF開発に使用されます。WPFのため、XAML言語を使用する必要があります。まず、ResourceDictionaryを使用してコマンドを実行するペイロードを見てみましょう。
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:d="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:b="clr-namespace:System;assembly=mscorlib" xmlns:c="clr-namespace:System.Diagnostics;assembly=system"> <ObjectDataProvider d:Key="" ObjectType="{d:Type c:Process}" MethodName="Start"> <ObjectDataProvider.MethodParameters> <b:String>cmd</b:String> <b:String>/c calc</b:String> </ObjectDataProvider.MethodParameters> </ObjectDataProvider> </ResourceDictionary>
このXAMLの説明:
上記のコードの実行は、ObjectDataProvider -> Person.Evil() に相当します。XmlSerializerを介してRCE攻撃を実行する場合、フローは次のようになります: ObjectDataProvider -> XamlReader.Parse() -> ObjectDataProvider -> System.Diagnostics.Process.Start("cmd.exe","/c calc")
目標は、デシリアライズ実行時にコードを実行できるオブジェクトを見つけることです。POCでは、DotNetNuke.Common.Utilities.FileSystemUtils の PullFile 関数を使用して「任意のファイルアップロード」を悪用します。
obj.xml が得られます:
ペイロードを送信します
DNNがCookieをデシリアライズした後、HTTPサーバーに /cmd.aspx へのリクエストが届きます。つまり、デシリアライズが成功し、WebシェルがDNNにアップロードされたことになります。
同様に、DotNetNuke.Common.Utilities.FileSystemUtils の WriteFile 関数を利用してファイルを読み取ります。
