testing-thick-clients

シッククライアントのテスト

シッククライアントでは、アプリケーションの一部がテスター自身のマシン上で動作します。そこが重要な調査機会です。バイナリ、設定、メモリ、通信はすべてアクセス可能です。こうしたアプリで繰り返し発生する問題は、クライアントを信頼してしまうことです。つまり、ユーザーが制御できるマシン上で認可を強制したり、機能を隠したり、シークレットを保持したりすることです。調査では、この攻撃対象領域を洗い出し、信頼の置き場所が誤っている箇所を示します。

使用する場合

• バックエンドと通信する、インストール型デスクトップアプリケーション（.NET/WPF、Java/Swing、Electron、Qt、ネイティブ Win32）を評価する場合
• 通信が HTTP ではない、またはプロキシに対応していないため、Burp に何も表示されないファットクライアントの場合
• データベースに直接接続する 2 層アプリの場合
• デスクトップアプリのローカルストレージ、IPC、更新の完全性、DLL 読み込みをレビューする場合

使用しない場合

• ブラウザー／Web アプリとその API — testing-web-applications と testing-apis を使用してください。ここで扱うのはインストール型デスクトップクライアントのみです。
• JS のリバースエンジニアリングが主な Electron 内部の調査（app.asar の展開やバンドルの難読化解除）では、コードには reversing-obfuscated-javascript を使用し、アプリの信頼境界の調査にはこのスキルを使用してください。
• セキュリティテストを目的としない、バイナリの純粋なリバースエンジニアリング — analyzing-binaries を使用してください。マネージドコードの場合は analyzing-dotnet-assemblies を使用してください。
• モバイルアプリ — testing-mobile-applications を使用してください。
• メモリ破損によるクラッシュをエクスプロイトにする場合 — exploiting-memory-corruption を使用してください。

まずアーキテクチャを把握する

最も重要なのはアプリの層数です。侵害されたクライアントから何ができるかは、層数によって変わります。

• 2 層（クライアント → データベースに直接接続）：クライアントはデータベースの認証情報を保持する必要があります。設定やメモリ内に接続文字列があれば、アプリと同じようにデータベースへ直接アクセスできます。シッククライアントで最も価値の高い発見事項なので、まずここを調べてください。
• 3 層（クライアント → アプリケーションサーバー → データベース）：クライアントは API と通信します。攻撃対象領域は、Web テストに加えて、以下で説明するローカルの攻撃対象領域も含みます。

次にスタック（マネージド（.NET、Java）、Electron、ネイティブ）を特定します。以降の各手順で使用するツールは、スタックによって決まります。

ローカルの攻撃対象領域

アプリがテスターのマシンに保存するデータには、すべて読み取り可能です。

• 設定とシークレット。 接続文字列、API キー、暗号化キーは、app.config／.exe.config、.ini、JSON、レジストリ、%APPDATA% に保存されていることがあります。同じバイナリに含まれるキーでシークレットを「暗号化」していないか確認してください。キーを復元すれば、シークレットは平文になります。
• ファイルシステムとレジストリの操作。 アプリを操作しながら Procmon（Sysinternals）を実行すると、アプリがアクセスするすべてのファイルとレジストリキーを確認できます。Regshot を使えば、操作の前後でレジストリを比較できます。インストールディレクトリやサービスの ACL が弱いと、ローカル権限昇格につながります。
• ローカルデータベース。 SQLite などのストアには、データやトークンがキャッシュされていることがよくあります。直接開いてください。
• メモリ。 復号されて利用されるシークレットはプロセス内にあります。ダンプに対して strings を実行するか、Process Hacker / System Informer を使えば復元できます。
• バイナリ。 dnSpy/ILSpy（.NET。難読化には de4dot も使用）または Java デコンパイラーを使ってマネージドコードを逆コンパイルすると、ハードコードされたロジック、キー、隠れたエンドポイントが見つかります。

非 HTTP トラフィックの傍受

クライアントがプロキシに対応していない、または HTTP を使用しない場合、Burp だけでは何も検出できません。

• HTTP だがプロキシに非対応 — プロキシ（システムプロキシ、proxifier 形式のリダイレクト、または hosts／DNS）を経由するよう強制し、プロキシの CA を信頼させます。.NET アプリは、設定しないとシステムプロキシを無視することがよくあります。
• 非 HTTP の TCP／TLS — mitmproxy の透過モードまたはリバースモード、あるいは不可視プロキシの構成を使用し、まずプロトコルを把握するために Wireshark を併用します。以前の解説では Echo Mirage が挙げられていますが、現在の Windows では信頼性に欠けるため、ランタイムフックを優先してください。
• ランタイムフック — デスクトッププロセス上の Frida で send／recv または TLS ルーチンを直接傍受します。アプリがピンニングを使用している、または独自の暗号処理で通信をラップしている場合、ネットワーク層と格闘するより効果的です。

クライアント側の信頼 — 中核となるクラス

クライアント内でのみ適用される制御はすべて回避可能だと想定し、それを実証してください。

• 無効化されたボタン、非表示のメニュー、クライアント側フラグで制御された「管理者」機能 — メモリ内のフラグ、または逆コンパイルしたバイナリ内のフラグを切り替えます。サーバー側で再確認されなければ、その機能を利用できます。
• クライアント側の入力検証とビジネスルール — プロキシ経由で回避し、サーバー側で再検証されるか確認します。
• クライアント側で決定される認可 — 古典的なシッククライアントの脆弱性です。UI はユーザーが実行できない操作を隠しますが、バックエンドは ID のみで認可します。ボタンではなく、操作そのものをテストしてください。

更新チャネルと DLL の読み込み

• 更新の完全性 — アプリが HTTP 経由で更新を取得する場合、または署名検証なしで HTTPS 経由の更新を取得する場合、更新チャネルはコード実行経路になります。アップデーターがインストール対象をどのように検証するか確認してください。
• DLL の検索順序ハイジャック — 検索パス上の書き込み可能なディレクトリから DLL が読み込まれる場合、アプリのコンテキストでローカルコードが実行されます。アプリのインポートと読み込みパスを列挙してください。

スコープと認可

シッククライアントのバックエンドは本番環境のインフラストラクチャであるため、あらゆるネットワークテストと同じスコープおよび認可ルールが適用されます。ローカルでの分析は自由に行えますが、クライアントが送信するものはすべて、クライアントの環境に到達します。

2 層構成の場合は、クライアントに明示的に伝える必要があります。データベース接続文字列を復元すると、アプリケーション層で適用されるはずの制御を回避する、直接的で、多くの場合きわめて強い権限を持つデータベースアクセスが可能になります。調査結果を実証するためにアクセスを確認してください。影響を示す範囲を超えて本番データを調べてはいけません。また、そのアクセスをエンゲージメントのアクセスインベントリ（maintaining-engagement-state）に記録してください。

退けるべき合理化

• 「Burp にトラフィックが表示されないので、テスト対象はありません。」 クライアントがプロキシに対応していないか、プロトコルが HTTP ではありません。プロキシを強制するか、プロセスにフックしてください。トラフィックは存在します。
• 「設定ファイル内のシークレットは暗号化されています。」 鍵がバイナリに含まれていれば、それは暗号化ではなく難読化です。鍵を復元して読み取ってください。
• 「管理者機能がグレー表示なので、保護されています。」 クライアント側の制御は認可ではありません。制御を切り替え、サーバー側で再適用されるか確認してください。それが調査結果です。
• 「デスクトップアプリなので、バックエンドには手が届きません。」 2 層アプリはデータベースの認証情報を渡します。データ層が安全だと決めつける前に、接続文字列を探してください。
• 「ローカルのみの問題は深刻度が低い。」 インストール先の ACL の弱さ、DLL ハイジャック、署名されていないアップデーターは、見た目だけの問題ではなく、ローカルコード実行や権限昇格につながる経路です。

参考資料

• testing-web-applications — 3 層クライアントのバックエンド API サーフェス
• analyzing-dotnet-assemblies — マネージド .NET クライアントの逆コンパイル
• reversing-obfuscated-javascript — Electron アプリのバンドル
• exploiting-memory-corruption — ネイティブクライアントにメモリバグがある場合
• maintaining-engagement-state — 復元した DB アクセスと認証情報の記録