shell.aplicationオブジェクトの脆弱性の説明

環境：2 kserver+iis 5で成功しました。権限はiusrのデフォルトです。 
iisパーミッション：スクリプト実行可能 記述：2 Kサーバでデフォルトでは、セットアップされたコンポーネントをserver.createobjectの方法で使用することができます。 
例えば、みんなが知っているADOデータベースコントロールですが、これらの専門的なコンポーネントを除いて 
また、WSHなどのシステムに提供されていたいくつかのコンポーネントは、FPOも同様に上記の方法で使用することができます。 
もちろん今はほとんどのaspバックドアがそれらを使っていますので、レジストリのこの二つのコンポーネントのCLSID値を削除または変更するネットチューブがあります。 
これらを無効にします。もちろん「コントロールパネル」の「削除プログラムの追加」に直接アンインストールしたものもあります。 
 でも、今使っているshell.appicationのコンポーネントは安全だと思っていたサーバーのコンポーネントです。 
MSDNにshellを通す objectはそれを見つけることができます。このコンポーネントはWSH、FPOとは関係がありません。それを通して私たちは何ができますか？ 
カタログを閲覧して、カタログをコピーしたり、ファイルサイズを移動したり、既存のプログラム（bat，exe，htta）を実行したりできます。 
パラメータは入れられません。 
 　 これらを実行するにはどのような権限が必要ですか？ 
 　 1.ASPファイルをスクリプトにアップロードして実行できるディレクトリを作りたいです。 
 　 2.サーバー上のハードディスクの権限がデフォルトのeverryoneなら完全に制御する 
 　 3.このコンポーネントは削除されていません（話がかかります） 
 　 以下は私が書いた例をshellといいます。 backdoorです。抜け穴はないと思いますが、新しい裏口を計算します。 
プログラムの物理パス: 
「 method="POST" 
  ブラウズするディレクトリを入力します。 
copy 
move 
パス: 
プログラム: 
Adam発表于：2002-08-03 12:01 
投稿: 2255 
登録: 199-08-29 
穴を開けてはいけないはずです。当時のFileSystemを知るべきです。 Objectもこれは抜け穴だと言う人がいません。 
あなたのコードを詳しく見ていません。FileSystemと同じです。 Objectは似たようなものでしょう。だから、私は手抜かりとは思いません。でも、後で他の人に注意します。 
cacls %systemroot%\system 32\shell 32.dll /e /d gusts