Windows Update-傍受
Windows Updateの実行時に行われたHTTPリクエスト/レスポンスを監視しようとしています。
IEでプロキシを使用して構成されたWindows 8マシンがあります。 winhttpのためにnetsh経由でインポートしました：
netsh winhttp import proxy source = ie
プロキシはポート8080の別のマシンで実行されており、SSLをインターセプトするように構成されています。
Burpプロキシまたは通常のSquidプロキシ（ssl_bumpを使用）の両方で試しました。ルートCA証明書は、Windows 8マシンのローカルマシンストアの信頼されたルートCAの下にインストールされます。 IEまたはChromeから参照した場合、提示されたサーバー証明書がプロキシCAによって署名されているため、警告なしでhttpsサイトにアクセスできます）。
ただし、Windows Updateを使用しようとすると、エラーが発生します。
「アップデートの確認中に問題が発生しました」
これは既知の問題であり、BluecoatはWindows UpdateのSSLインターセプトの例外を追加することを勧めています：
https://kb.bluecoat.com/index?page=content&id=KB3959&actp=RSS
MicrosoftはTMGについても同じ推奨事項を示しています。
http://support.Microsoft.com/kb/949104
したがって、Windows Updateサービスは通常の方法で証明書をチェックするだけではなく、実際には別のCAリストに対して検証するか、Windows Updateサイトからの特定のサーバー証明書を特に必要とするようです。
問題は、Windows Updateによって行われたHTTP要求を確認できるように、これを回避するにはどうすればよいですか？
この問題はしばらくの間私に挑戦しましたが、それを乗り越える方法を見つけました。通常、Windows Updateエラー80245006または803D000Aとして表示されます
2015年3月にSuperPhishers DeciteSubCAIdentity.pyというツールを作成しました。これにより、Windowsの内部チェックをバイパスして、証明書が本当にMicrosoftからのものかを確認できます。その名前は、当時のSuperFish Lenovo論争の劇です。
簡単な部分は、RSAプロキシがRSA> = 2048やSHA256RSAなどのモダンなものを生成することです。sslsplitを使用して、SHA256ダイジェストを生成するように変更しました。 Windowsは、アップデートとストア証明書にSHA256を必要とするか、0x803D000で失敗します
難しいのは、CA証明書がMicrosoftであるというWindowsチェックをバイパスすることです。
基本的に、CA証明書が正当であることのチェックを実装する2つの関数があります。これらはどちらもwuaueng.dllおよびstorewuauth.dllで決定サブCAIdentityと呼ばれています。NektraDeviare2を使用して、機能決定サブCAIdentityがフックされ、常に完了してEAX = 3のままになっています。これにより、Microsoftチェックに合格し、更新または保存機能が通常どおり続行されます。
両方のDLLでこの関数にパッチを適用すると、Windowsストアトラフィックのインターセプトが可能になります。傍受したトラフィックを確認するか、ICAPを実行して楽しみを書き換えます。
私はここでビデオを作りました： https://www.youtube.com/watch?v=EyDaTkU2sKY
コードとテクニカルライトアップはこちら： https://github.com/MiWCryptAnalytics/DetermineSubCAIdentity
Thomas Porninはdllを変更する必要があるという点で正しい-私がディスク上のdllを変更したとき、SFCはそれらを適切なものに置き換えた。ただし、システムプロセスに挿入されたDeviare2をメモリ内で実行すると、Windows 8.1は気にしないようでした。
これがお役に立てば幸いです。初めてWindows Updateのトラフィックがクリアテキストで表示されるのを楽しんだことを願っています。
可能な更新の中には、トラストストア自体のデフォルトの内容の更新があります。 Windowsがデフォルトのトラストストアを使用していた場合、そのストア内のCAは偽造された更新を編集して、競合他社を追い出す可能性があります。また、OSのあらゆる部分を変更する可能性があります。 OSの場合、更新のパスは非常に敏感です。 100ほどのCAに更新の力を与えることは非常に危険です。それらのすべてが適切に仕事をするために本当に信頼できるわけではありません（たぶん、起こったことはありませんが、まだ...）。
Windows Update SSLサーバーの偽の証明書を "信頼された発行元" ストア（ "ローカルコンピューター"の1つ）に追加することをお勧めします。その場で偽の証明書を発行するBurpが制御するCAではなく、偽のサーバー証明書自体を含めます（Burpが特定の非動的な偽の証明書を特定のサーバーに使用できるかどうかはわかりません）。このストアは通常、SSLサーバー用ではなく、ドライバーの署名を検証するためのものですが、Microsoftが証明書を処理する方法を考えると、これは機能し、期待どおりの動作をする可能性があります（現在、Windowsマシンでこれを試すのに便利ではありません）。
Windowsコードが簡単にアクセスできるトラストストアを使用せず、代わりにWindows Updateサーバーの受け入れ可能な証明書のリストをハードコーディングする場合は、DLLの変更、マルウェアの書き込みは生計を立てるため、OSは積極的にそれを防御しようとします。