0x00脆弱性の説明

2019年5月15日に高リスクの脆弱性が公開されました。脆弱性には、Windows 2003、Windows 2008、Windows 2008 R2、Windows XPシステムなど、幅広い影響があります。このサーバーの脆弱性方法は、リモートデスクトップポート3389およびRDPプロトコルを介して攻撃されます。この脆弱性は、今年の最も有害な脆弱性であり、以前のランサムウェアであるEternal Blue Virusと同様です。 CVE-2019-0708の脆弱性は、ユーザーのID認証をチェックすることにより、相互作用なしに認証をバイパスし、RDPプロトコルを介して直接接続して、悪意のあるコード実行コマンドをサーバーに送信できることです。攻撃者によって悪用されると、サーバーの侵入、ウイルス、およびWannaCry Eternal Blueの脆弱性のような大規模な感染が引き起こされます。 2019年9月7日の午前1時頃、Metaspolitはそのエクスプロイトを更新しました

2019年5月、Microsoftは、リモートデスクトップサービス（RDS）のコードに存在する「BlueKeep」としても知られるリモートコード実行脆弱性CVE-2019-0708のパッチアップデートをリリースしました。この脆弱性は事前に認識されており、ユーザーの相互作用は必要ありません。したがって、潜在的な武器化されたワームの性的搾取の危険性があります。この脆弱性が正常に悪用されている場合、システム権限を使用して任意のコードを実行できます。 Microsoft Security Response Centerの推奨事項は、この脆弱性もWannaCryやAtheemauditなどの攻撃と同様にワーム攻撃になる可能性があることを示唆しています。この脆弱性の深刻さとユーザーへの潜在的な影響により、MicrosoftはWindowsユーザーを保護するためにサポートされなくなったWindows XPオペレーティングシステムのパッチを発行するためのまれな早期警告ステップを踏んでいます。

0x01脆弱性の影響

この脆弱性は、Windows 7、Windows Server 2008 R2、Windows Server 2008、Windows 2003、Windows XPなど、古いバージョンのWindowsシステムに影響します。 Windows 8およびWindows 10以降は、この脆弱性の影響を受けません。

0x02 CVE_2019_0708_BLUEKEEP_RCE.RBはじめに

このPRは、RDPを介してリリースされた後に脆弱性を悪用するCVE-2019-0708（別名BlueKeep）のエクスプロイトモジュールを追加します。 RDP Termdd.Sysドライバーは、内部的にのみMS_T120へのバインディングを適切に処理しないため、不正な切断プロバイダー表示メッセージをリリース後に使用できます。制御可能なデータとリモートの非ページのプールヒープジェットを使用して、アイドルチャネル用の間接コールウィジェットを使用して任意のコード実行を実装します。

このモジュールはもともと @Zerosum0x0と@Ryhansonによって開発され、その後@OJ、@ZeroSteiner、 @rickoates、 @wvutters-r7、 @wchen-r7、 @tsellers-r7、 @todb-r7などによってさらに開発されました。 MetasploitのRDPやその他のライブラリの機能強化を活用するために、モジュールはPython外部モジュールからネイティブRubyモジュールに移植されます。現在の実装と比較して比較する場合、元のPythonモジュールはコミット履歴にあります。

このモジュールは現在、Windows 7およびWindows Server 2008 R2の64ビットバージョンをターゲットにしています。 Windows Server 2008 R2の場合、RDPSNDチャネルを介してヒープジェットを有効にするためにレジストリキーを変更する必要がありますが、すべてのWindowsオペレーティングシステムでデフォルトで有効にされる他の代替チャネルがあります。

ユーザーは追加のターゲット情報を提供する必要があるか、ターゲットホストをクラッシュさせるリスクがあるため、このモジュールは現在、手動モジュールとしてリストされています。モジュールは、脆弱なホストのみをチェックし、特定のターゲットオペレーティングシステムに関するいくつかの初期情報を表示するデフォルトのポイントのみのターゲットオプションを実装しますが、ユーザーは補助偵察に基づいてより正確なターゲットを指定する必要があります。

未収、ベアメタル、バーチャルボックス、VMware、およびHyper-Vには特定のターゲットがありますが、ターゲット環境には、基礎となるアドレスをさらに移動する他の変数が存在する場合があります。

0x03脆弱性分析

1。 PDU

MS-RDPBCGR（リモートデスクトッププロトコル：接続およびリモート処理）ドキュメント、ビットマップキャッシュPDUのフルネームはTS_BITMAPCACHE_PERSISTENT_LIST_PDUであり、キーリストPDUデータは、キーリストPDUに組み込まれています。永続的なキーリストPDUは、クライアントからサーバーに送信されるRDP接続シーケンスPDUです。

RDPジャンクションシーケンスの接続完了ステージを図1に示します。

図1。リモートデスクトッププロトコル（RDP）接続シーケンス

永続的なキーリストPDUヘッダーは、図2に示すように、次のように構築された一般的なRDP PDUヘッダーです。

図2。クライアントの永続的なキーリストPDU

MS-RDPBCGRのドキュメントによると、TS_BITMAPCACHE_PERSISTENT_LIST_PDUは、前のセッションで送信されたキャッシュビットマップから保存されたキャッシュビットマップキーのリストを含む構造です。図3に示すように。

図3。永続的なキーリストPDUデータ（BITMAPCACHE PRESSINTERT LIST PDU）

設計上、BitMap Cache PDUは、RDPクライアントによって使用され、サーバーにキーに関連付けられたビットマップのローカルコピーがあることを通知し、サーバーがクライアントにビットマップを再送信する必要がないことを示します。 MS-RDPBCGRドキュメントに基づいて、BitMap PDUには4つの特性があります。

RDPサーバーは、カーネルプールを割り当てて、キャッシュされたビットマップキーを保存します。

RDPサーバーによって割り当てられたカーネルプールサイズは、構造内のnumentriesCache Xフィールドによって制御でき、BitMapCache PersistentのTotalentriesCache XはRDPクライアントのリスト構造です。

ビットマップキーは複数回永続的なキーリストPDUで送信できるため、ビットマップキャッシュPDUを複数回合法的に送信できます。各PDUはBbitMaskフィールドのタグでマークされています。

ビットマップキーの数は169に制限されています。

BitMapCache Persistent List PDUのこれらの4つの機能に基づいて、169に制限されたビットマップキーの数をバイパスできる場合、データはカーネルに書き込むことができます。

2. PDUを使用してカーネルにデータを書き込む方法

MS-RDPBCGRドキュメントによると、通常復号化されたBitMapCache Persistent List PDUは次のとおりです。

F200-TS_SHARECONTROLHEADER:3360TOTALLENGTH=0x00F2=242BYTES1700-TS_SHARECONTROLHEADER:3:PDUTYPE=0x00170x0017=0x0010 |0x0007=ts_protocol_version | pdutype_datapduef03-ts_sharecontrolheader3:pdusource=0x03ef=1007e A030100-TS_SHAREDATAHEADER3:3360SHAREID=0x000103EA00-TS_SHAREDATAHEADER:3360PAD101-TS_SHAREDATAHEADER3336 0:STREAMID=Stream_Low（1）0000-TS_SHAREDATAHEADER:3360UNCOMPRESSEDLENGTH=02B-TS_SHAREADATAHEADER:PD UTYPE2=PDUTYPE2_BITMAPCACHE_PERSISTENT_LIST（43）00-TS_SHAREDATAHEADER:GENERALCOMPRESSTYPE=00000-TS_SHARE DataHeader:GeneralCompressedLength=00000-TS_BITMAPCACHE_PERSISTENT_LIST:3360NUMENTRIES [0]=00000-TS_B itmapcache_persistent_list:3360numentries [1]=01900-ts_bitmapcache_persist_list3:3360numentries [2]=0x19=250000-ts_bitmapcache_persist_list3333333:nummumentries [3 ]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:numEntries[3]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:numEntries[3]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:numEnt Ries [4]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:3360TOTALENTRIES [0]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:333 60Totalentries [1]=01900-TS_BITMAPCACHE_PERSISTENT_LIST:3360TOTALENTRIES [2]=0x19=250000-TS_BITMAPCACHE_PERSIST ENT_LIST:TOTALENTRIES [3]=00000-TS_BITMAPCACHE_PERSISTENT_LIST:3360TOTALENTRIES [4]=003-TS_BITMAPCACHE _persistent_list:3360bbitmask=0x030x03=0x01 |0x02=festive_first_pdu | stabe_last_pdu00-ts_bitmapcache_persiste nt_list:pad20000-ts_bitmapcache_persist_list:pad3ts_bitmapcache_persistent_list:3360entr IES:A31E5116-CACHE2、key0、low32-bits（ts_bitmapcache_persist_list_entry:key1）48292278-cache2、key0、hi GH32ビット（TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY:KEKEY2）61F7899C-CACHE2、KEY1、LOW32ビット（TS_BITMAPCACHE_PERSIS TENT_LIST_ENTRY:3360KEY1）CDA966A8-CACHE2、KEY1、HIGH32ビット（TS_BITMAPCACHE_PERSISTENT_LIST_ENTRY:KEY2）

カーネルモジュールrdpwd.sysでは、関数ルーチンShareclass : SBC_HANDLEPERSISTENTCACHELISTがBitMapCache Persistent List PDUを解析する責任があります。構造内のBbitMaskフィールドがビット値0x01に設定されると、現在のPDUが永続的な最初のPDUであることを示します。次に、SBC_HANDLEPERSISTENTCACHELISTはWDLIBRT_MEMALLOCを呼び出してカーネルプール（カーネルメモリを割り当てる）を割り当てて、図4に示すように永続的なビットマップキャッシュキーを保存します。値0x00は、現在のPDUが永続的な中央PDUであることを示します。値0x02は、現在のPDUが永続的な最後のPDUであることを示しています。持続中央のPDUと永続的な最後のPDUを解析すると、SBC_HANDLEPERSISTENTCACHELISTは、図5に示すように、以前に割り当てられたメモリにビットマップキャッシュキーをコピーします。

図4。SBC_HANDLEPERSISTENTCACHELISTプールの割り当てとTotalErtriesCacheLimitチェック

図5。SBC_HANDLEPERSISTENTCACHELISTコピービットマップキャッシュキー

Windows 7 x86のスタックトレースの2番目のパラメーターとSBC_HandlePersistEntCacheListのTS_BITMAPCACHE_PERSISTENT_LIST構造を図6および図7に示します。

図6。SBC_HANDLEPERSISTENTCACHELISTスタックトレース

図7。TS_BITMAPCACHE_PERSISTENT_LIST構造SBC_HANDLEPERSISTENTCACHELISTの2番目のパラメーターとして

図4に示すように、BitmapCachElistPoollen=0xc *（Total Length + 4）およびTotal Entriescache0 + Totalentriescache1 + Totalentriescache2 + Totalentriescache3 + TotalentriesCache4。

この式に基づいて、「Word値」TotalErtriesCache x=0xffffを設定して、BitMapCachElistPoolenを最大値にすることができます。ただし、図8に示すTotalErtriesCache Xごとに、TotalErtriesCacheLimitチェックがあります。

TotalErtriesCachelimit Xは、図8に示すように、capapi_capability_niTがrdpwdを介して呼び出される場合、capapi_load_load_ts_bitmapcache_capabilityseset_rev2機能で開始されるts_bitmapcache_capabilityset_rev2構造に由来します。図9に示すように、PDUの確認を解析します。

図8。RDPWD！ capapi_load_ts_bitmapcache_capabilityset_rev2

図9。RDPWD！ capapi_combine_ts_bitmapcache_capabilityset_rev2

capapi_combine_ts_bitmapcache_capabilityset_rev2は、サーバースタートしたnumcellcaches（0x03）およびtotalentriescachelimit [0-4]（0x258、0x258、0x10000、0x0、0x0）をクライアントのリクエスト（0x03）およびcothelcaches（0x03）およびcombines （0x80000258、0x80000fffc、0x0）、図9のEDXおよびESIレジスタに示すように。

図10に示すように、クライアントはnumcellcachesとtotalentriescache [0-4]を制御できますが、図11に示すように、サーバースタートしたnumcellcaches（0-4]およびtotalentriescachelimit [0-4]]（0x258、0x258、0x10000、0x0、0x0）で制御することはできません。

図10。ts_bitmapcache_capabilityset_rev2

図11。Capapi_combine_ts_bitmapcache_capabilityset_rev2関数

この情報を使用すると、最大bitmapcachelistpoollen=0xc *（0x10000 +0x258 +0x258 + 4）=0xc3870を計算できます。

図12。永続的なキーリストPDUメモリダンプ

ただし、BitMapキャッシュリストプールのRDPクライアントがすべてのデータを制御できるわけではないことが観察されています。制御されたデータの各8バイトの間に、4バイトの制御されていないデータ（インデックス値）がありますが、これはシェルコードストレージにそれほど友好的ではありません。さらに、0xc3870サイズのカーネルプールは複数回割り当てることはできません。これは、永続的なキーリストPDUを合法的に1回しか送信できないためです。ただし、カーネルプールが同じメモリアドレスで割り当てられる特定の統計的特徴がまだあります。さらに、図13に示すように、特にX64でのヒープ割り当てに非常に役立つビットマップキャッシュリストプール割り当ての前に、常に0x2B522C（x86）または0x2B5240（x64）カーネルサイズのプールがあります。

図13。永続的なキーリストのPDU統計的特性

3。 rect pdu

MS-RDPBCGRドキュメントによると、PDUを更新すると、RDPクライアントはサーバーにセッションの再割り当てを要求します。この構造には、汎用PDUヘッダーとrefreshrectpdudata（変数）が含まれています。 14。

図14。長方形のPDUデータを更新します

数字のフィールドは、AreastoreFreshフィールドに含まれる長方形構造の数を定義する8ビットの署名のない整数です。 AreatoreFreshフィールドは、図15に示すように、TS_RECTANGLE16構造の配列です。

図15。長方形（TS_RECTANGLE16）が含まれています

更新されたRect PDUは、一連の「包括的長方形」操作を介してサーバーに通知し、サーバーがセッションを再割り当てするようにします。デフォルトのチャネルに基づいて、チャネルIDは0x03EA（サーバーチャネルID）です。図1に示すように、接続シーケンスが完了すると、RDPサーバーは更新マトリックスPDUを受信/解析でき、最も重要なことには、合法的に複数回送信できます。 TS_RECTANGLE16構造は8バイトに制限されていますが、RDPクライアントは8バイトのみを制御できますが、arbitrary意的なデータをカーネルに書き込むことができます。

4。 Rect Rect PDU

通常の復号化されたリフレッシュrect PDUを図16に示します。