Apacheの脆弱性を狙うWormが遂に登場 62
ストーリー by yourCat
穴があれば虫も湧く 部門より
穴があれば虫も湧く 部門より
jeff2曰く、 "ZDNetに『Apacheサーバを襲う新型ワーム』という記事が出ています。遂に出るものが出たという感じですが、Code Red WormのようにApache Wormも猛威を振るうようになるのでしょうか?
今回のWormはFreeBSDがターゲットのようですが、次はやはりLinuxを狙う亜種が出そうな感じです。
FreeBSD security ML, BUGTRAQ ML, セキュリティホールMEMO ML等にも情報が流れているので、更なる情報が必要な方はチェックされたほうがいいかも知れません。また、Apacheを利用されていて、まだセキュリティパッチの適用または修正版に入れ替えていない対象プラットフォームのマシンの管理者は、待った無しで対策をする必要がありそうです。"
攻撃ツールに続いてワームか。涌くのが早いな。いずれも最近見つかった脆弱性を利用している。
FreeBSD.Scalper.Worm (スコア:3, 参考になる)
○○だからor○○じゃないから安全 (スコア:2, 参考になる)
さて、ここから根拠もなく言ってきます。
よって、マイナスモデレートされるべきかもしれません。
<根拠なしの文>
きっと、CodeRedで話題になったIISじゃないから安心と思って
導入後、ずっと放置してあるApacheとかが
主な長期的なキャリアになるのでしょうね・・・
# いまだにCodeRed系も時々誘惑してるし、
# 当てない人は、いつまでたっても当てないでしょうし・・・
さて、今回のですが、
・分母の数が絶対的に多い
・脆弱性発見から、ワームが出回るまでの期間の短さ
・複数プラットフォームで、似たような脆弱性がある
・ワーム作者にとっては、*BSDのみならず、LinuxやWindowsや
Mac(といってもOS Xだけかな?)も感染対象に出来るのですから、
ある意味、名声を得るチャンスと思って張り切ってるかも。
以上を考えると、CodeRedより悲惨な状態になるかもしれません。
希望的観測で言うなら、
・Apacheを意識して動かしている人が多い。
・最近いくつも穴が見つかったので、
管理者がセキュリティ関連の情報を注意している。
・CodeRed系の教訓から、HTTPプロトコルの中身をチェックする
フィルタリングソフトを導入している。
・ワーム作者は、同時期に沢山穴が見つかったので、
どの脆弱性を使ってワームを作ろうか悩んでいる。
とかがある・・・かも。
# まぁ、大抵「希望的観測」はミスを生むだけですが。
さて、マルチプラットフォームな亜種は、いつ出るのかな・・・
今年は、(ルータとかが)熱い夏になる・・・のか?
</根拠なしの文>
Re:○○だからor○○じゃないから安全 (スコア:2, 参考になる)
絶望的観測で言うなら、
というところでしょうか。
私はApacheを使っていることを知っていますし混乱もしていませんが、正直な話、HTTPプロトコルは知りません。telnetでポート80に接続して「GETほげほげ」と入力して何かを入手したりすることくらいはできます。しかし「chunked encoding」なんてのは知りません。サーバの管理者は、そこまで知らないといけないのでしょうか?
Re:○○だからor○○じゃないから安全 (スコア:4, 参考になる)
>サーバの管理者は、そこまで知らないといけないのでしょうか?
知らなくてもApacheの管理者はやれますが、知ってればそれだけ
多くのことに対応できるでしょうね。ま、一般論ですが。
ちなみに「chunked転送」とは、送信時にコンテンツのサイズ(Content-Length)
を指定せずにメッセージを送信する方法です。この際Transfer-Encoding: chunkedを
ヘッダに付加します。
動的なメッセージの場合、メッセージを生成しながら転送できるので
(メッセージ全体を生成した後で転送する必要がない)、パフォーマンス面で
有利です。
クライアントのリクエスト、サーバのレスポンスともに使用することができますが、
今回Apacheではクライアントからのchunkedされたリクエストの処理で脆弱性が
発見されました。
#HTTP依存はますます強くなっているので勉強しておくことをお勧めします。
#まずはRFC2616 [w3.org]を見ましょう。
Re:○○だからor○○じゃないから安全 (スコア:2, 興味深い)
// というわけで、いろいろ勉強せにゃぁ。>ぼく :)
Apache って標準の Not found のページなどを chunked transfer encode で返すんですね。ごく最近知って驚いたのですが、考えてみたら、 HTTP/1.1 で Content-length をつけずにデータを渡すためには、 Connection: close する以外には chunked を使うしか方法がないのでした(たぶん)。
なお、 transfer encode は要求と応答のどちらでも使うことができ、ここでぼくが言っているのは応答が chunked transfer encode を使っているという話です。 1.3.24 などの弱点は要求が chunked を使っている場合の話だと思うので、 Not found ページと今回の弱点は直接の関係はありません。誤解のなきよう。
余談ですが、ぼくが chunked transfer encode について知ったのは、2ちゃんねるで mod_gzip を入れる話が出たときでした。 dechunking とかいう言葉が出てきて意味がわからなかったので、話についていくために RFC その他の資料を読んで勉強したのでした。2ちゃんねるでの議論をリアルタイムで読んでいたわけではありませんが。
鵜呑みにしてみる?
chunked ennoding (スコア:1)
いて、このchunked処理にはいろいろ問題がありそうだなと
思っていたところへ、この騒ぎになりました。
ちょっと忘れられているかもしれないDelegateにも、随分こ
の処理がらみでパッチが出ていたり、処理ミスがあったよう
です。また、HTTP/1.1指定によってHTTPコネクションを複数
リクエストに渡って使用すると、途中のプロキシが対応して
いなかったり、バグがあったりで、認証がらみでぼろぼろに
なるような現象がよく出ます。
仕様を作った方が悪いのか、仕様を正しく実現できないのが悪
いのか、どっちもどっちですが、chunked encodingはバグの
山のような気がしてなりません。
Re:○○だからor○○じゃないから安全 (スコア:1)
とりあえずサーバ管理者に必要なのは、それなりに十分な時間的余裕、bugtraqなどの「早い」情報源を適度に読める能力、サーチエンジン使ってそれが何かを調べるぐらいのリテラシー、ですかねえ。
組織としてはダブルチェックできる体制ってのもほしいけど、こっちは個人の能力ではちょっとどうしようもないことが多くて悲しい。
-- Takehiro TOMINAGA // may the source be with you!
Re:○○だからor○○じゃないから安全 (スコア:0)
HTTPプロトコルくらい知っておくべきでしょう。
もしも、それで飯喰うのならばね。
なんちゃってサーバ管理者なら、どーでもいいんですけど。
Re:○○だからor○○じゃないから安全 (スコア:1, 興味深い)
かつてSecurity Watchが終了した時に、
『セキュリティ対策は、何かをしてしまえばそれで終わりではなく、こつこつと情報を集め、ひとつひとつ丹念に対策をとっていく、それを毎日延々と繰り返すというのがセキュリティ対策の第一歩だと私は思います。セキュリティホールはどんなOSやソフトであろうと、どんなに長い間安定して使われていようと、いつか突然でてきます。長い間、まったく問題無いと思われていたものに、ある日突然発見されたりするものです。よく冗談で「Unixはセキュリティに強いけど、NTはぼろぼろだ」とか言われますが、そんなことはありません。どんなOSにも例外無くセキュリティホールはあります。強いOSを使っているからと安心することなく、常に最新の情報を集め、対策を怠らないようにしないと大きな代償を払わなければならなくなります。』
と書かれたいたことを思い出すなぁ。
Re: ○○だからor○○じゃないから安全 (スコア:0)
うちの仕事がらみの某役所の話。
三重県庁ウイルスバラマキ事件 [pref.mie.jp]の時には 「うちのメールサーバはUNIXだから大丈夫」
当然ながら Apache は古いまま。 動くかどうかわかんないか
Re: ○○だからor○○じゃないから安全 (スコア:0)
逆でしょ。
「新しいのが出たからバージョンアップしましょう!」っていうのが
Re: ○○だからor○○じゃないから安全 (スコア:0)
「お客さん、バージョンアップすると動かなくなるかもしれませんよ」と、メンテナンス工数を削減するのが、サーバ屋の現実。
Re: ○○だからor○○じゃないから安全 (スコア:1)
Apacheのバージョンアップの方法 (スコア:2, 興味深い)
れた時にバージョンアップしました。しかし、面倒な作業を減
らそうと、ちょっといい加減なやりかたをしてしまったかもし
れません。
皆さんは、どういうふうにバージョンアップをしていますか。
教えて下さい。(できれば、どれくらい手抜きができるか、教
えて下さい。)
Solarisではmake時にインストールディレクトリを指定してい
ます。/usr/local/apacheはそこへのリンクにしてあります。
新バージョンが出た時には、版指定ディレクトリへインストー
ルします。confファイルの変更を調べ、特に重大な変更がなけ
れば、旧のconfでの設定情報を移植します。テストサーバ(例
えば10080番ポートで起動)で動きをチェックし、最低限の表
示がちゃんとなされることを確認します。コンテンツ管理者に
も動作をチェックしてもらいます。ちなみに、コンテンツは普
通のHTMLファイルと簡単なCGIだけです。
これだけチェックして、/usr/local/apacheのリンクを新版に
変更し、外部公開用ポート(80番ポート)のapacheを再起動し
ました。
単純なコンテンツしかないので、こんな簡便なやり方で、えい
やっとできるのですが、もうちょっと慎重に動作検証したほう
がいいでしょうか?
FreeBSDでもapacheを動かしているのですが、こちらはバージョ
ン対応のディレクトリはないですね。古いバイナリは1.3.19
だった(更新サボってました)のですが、1.3.26のバイナリを
作り、それだけを置き換えておきました。モジュールの再コン
パイルが必要だという議論がありましたが、僕のサーバでは不
必要でした。
RedHat LINUXではapacheを動かしていなかったの、更新は必要
なかったのですが、もしやるとしたらrpmで置き換えるしかな
いのですかね。うまく動かなかった時に元に戻れるか、ちょっ
と不安ですが、大丈夫でしょうか。
今回のように緊急に置き換えが必要な時、皆さんはどういうふ
うに作業しているんですか。教えて下さい。
Re:Apacheのバージョンアップの方法 (スコア:2, 参考になる)
>うに作業しているんですか。教えて下さい。
構成の複雑さによりけりじゃないですかね。
上書きはモジュールがバージョンの差異で不具合を起こすことも
ありますからバッサリ上書きというのもぞっとしないですが、
単に./configureした程度のものなら、私ならバッサリやります。
普通は仰るとおりにシンボリックリンクを使用するのが安全でしょう。
非常に込み入ったことをしているなら作業に時間がかかって
危険かもしれませんが。
この間PHP-4.2.1が動いてる1.3.24を1.3.26に入れ替えましたが、
そのときは急ぎだったのでhttpdと標準モジュールだけすげ替えました。
一応CHANGESには目を通して大丈夫だろうという算段でやったのですが、
今のところ問題ないように見えます(実は節穴だったりして)。
httpd.confもだいぶいじってますが大丈夫でした。
しかし、大事なのは緊急に備えて日頃から使用しているアプリケーションの
動向をチェックしておくことでしょうね。それにつきます。
ほったらかしにしておいて緊急時にあわてるのは避けたいです。
#業務多忙な管理者には酷なことかもしれませんが。
あと、このあたりのスレッド [apache.or.jp]なんかは参考になります。
Re:Apacheのバージョンアップの方法 (スコア:2, 参考になる)
構成によっては危弱性のあるバージョンでもTransfer-Encoding: chunkedをBadRequestされたケースもありました。
この場合特に急がず、ゆっくりと情報収集してごっそりバージョンアップできますね。
また、運用的にもうすぐコンテンツが終了でサーバ自体を使わなくなるというケースもありました。これはPHP4.1.2の他、追加モジュールがあったので、すべてをあげるはさすがに怖く、コンテンツ終了まで祈って逃げ切りたい衝動を抑えつつ、危弱性をとりあえず回避させるDSOモジュールがBugTraqにあげられてましたので、こちらを入れることで逃げ切ることにしました。
BugTraqにあげられた文章
http://archives.neohapsis.com/archives/bugtraq/2002-06/0282.html
ソースのDL先
http://www.awayweb.com/pub/src/
また、つい先日メンテナンスでサイトを停止させてもらった後にこの問題が出たサイトについても上の方法で次回のメンテナンスが出来るまで回避することにしました。
ごっそりやる場合はやっぱり、テスト機などでなるべく同構成に近い形でテストを繰り返してやるような形ですね。
RPMの場合設定ファイルのバックアップを取得してごっそりアップグレードして、不具合があったらダウングレード(http://www.awayweb.com/pub/src/)じゃだめなのかな?(う、やたことない)
ソースの場合は、私の場合/usr/local/apacheなどひとまとまりになってることが多いのでそれごとまるまるバックアップとしてコピーして、新しいのを./configure make make install。
でも構築時のconfig.status等を保存しているので、それを元にconfigのオプションを同一にしています。
こんなとこかな。いずれにしてもドキドキですよね(笑
---Shogo Sato
Re:Apacheのバージョンアップの方法 (スコア:1)
うっ…。失礼しました。(TT
---Shogo Sato
Re:Apacheのバージョンアップの方法 (スコア:1)
$make
#apachectl stop
#make install
#apachectl start
ですが、何か?
LinuxやWindows用も (スコア:1)
> 次はやはりLinuxを狙う亜種が出そうな感じです。
勘ですが、おそらく既に存在しているのでしょうね。
LinuxやWindowsで動作するApacheの方が多く、
なおかつセキュリティに関心の薄いユーザ層が多いことを考えると
そっちを狙った方が成功する確率はずっと高いわけで。
FreeBSD用が最初に見つかったのはたまたまでは?と考えてしまいます。
#ちなみに、6/20に警告してあげた知り合いのLinuxサーバは
#さっきHTTPヘッダを見たらApache-1.3.22でした。そんなもんです。
いまだにCodeRedがやってくることから考えても、この件は長びきそうです。
Re:LinuxやWindows用も (スコア:2, 参考になる)
> #さっきHTTPヘッダを見たらApache-1.3.22でした。そんなもんです。
たとえばRedHatのerrataは、Apache-1.3.22や1.3.23に、1.3.26からの
バックポートパッチを当てたものになっています。
http://www.redhat.co.jp/support/errata/RHSA/RHSA-2002-103J.html
なので、バージョンが 1.3.22 だから必ず問題がある、という
わけではないはず。
Re:LinuxやWindows用も (スコア:1)
一応弁解すると、この「知り合い」はRedHatを使用していますが、
Web用のサーバ(HTTP,FTP等)はソースから入れる人なので「対応していない」
と判断したわけです。
ちなみに、新しいバージョン(1.3.26)があるのにわざわざ古いもの(1.3.22)に
パッチを当てて使い続けるような人ではありません。
一時しのぎにrpmを使用することもしないでしょうし。
(絶対に対処していない、とも言い切れませんが・・・)
#HTTPヘッダのみで判断できないというのは私もわかります。
#説明不足でした。
Re:LinuxやWindows用も (スコア:0)
私もその気になればソースからバージョンアップしてもいいのですが、会社のサーバだとこれがちょっと怖かったりします。
Debianのstableもそうですが、むやみにバージョンを
HTTPヘッダを見たら(Re:LinuxやWindows用も) (スコア:0)
ServerTokens Prod
書いておかないと。(ただしProdは1.3.12以降)
詳しくは
http://httpd.apache.org/docs/mod/core.html#servertokens
をどうぞ。
Re:HTTPヘッダを見たら(Re:LinuxやWindows用も) (スコア:0)
Serverヘッダって、消すと問題ありますか? (スコア:0)
Server: Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.0.6
このほうが
Server: Apache
少しはセキュリティにいいかな、とは思う。あとトラフィックも*ちょっと*減るし。
そもそもレスポンスのserverヘッダって何か役に立ってるんだろうか。消すと何か問題がありますかね? (Netcraftが困る、とかいうのは除いて)
Re:Serverヘッダって、消すと問題ありますか? (スコア:0)
あと、お客様の個人情報を預かるサーバの場合には、説明責任を怠っているとも言える。
Re:LinuxやWindows用も (スコア:1)
>> 次はやはりLinuxを狙う亜種が出そうな感じです。
> 勘ですが、おそらく既に存在しているのでしょうね。
packet storm [decepticons.org]に、LinuxとSolaris用のexploitsがあがってたら、
今頃大騒ぎになってた気がします。
# 今出てる奴は、対象は「FreeBSD, NetBSD, and OpenBSD」となってます。
Re:LinuxやWindows用も (スコア:1, 興味深い)
感染サーバ蔓延を第一に考えるなら、最初にLinux(特にRed Hat)用を作るはず。
だってさ、HTTPでIPアドレスを直に指定してアクセスしたときに
出てくる「Worked it!」の多さと言ったら・・・。
そんなサーバ運営者がパッチ当てしてるとは思えないでしょ。
しかも、FreeBSDだったら意図しないとapacheは入らないはずだし。
きちんと管理していれば (スコア:1)
会社のサーバは基本的に俺がインストールマニアなので大丈夫(だと思う)
心配なのは会社のサブドメインのなんちゃって管理者が管理しているサーバ。
自称パワーユーザーともいう。
海外からお叱りのメールをいただくのはもう嫌です。
それにしても韓国方面からのSPAMなんとかしてください。
MLで配られるのは勘弁。
Re:きちんと管理していれば (スコア:3, 参考になる)
パッチというか、RedHatが配るアップデートRPMが出たら
無条件でアップデートしています。
正直言って、アップデートされる内容は殆ど理解して
いないのですが、そんなもんでも何とかなるようです。
そんなんじゃ管理者失格だ!という真面目なお叱りも
あるでしょうけど、専門じゃない人間には、これが
精一杯です。
RedHatと言えば (スコア:0)
telnetdの脆弱性を利用して、鯖自体のハイジャックに成功した
奴がいたな。
結果的にrootがtelnetdのような余計なデーモンを殺したことで、
事が一件落着したけどね。
ちな
大学なんて (スコア:1, おもしろおかしい)
けどWinMXでトラフイック増やすのは辞めて欲しい。
Re:大学なんて (スコア:0)
うちの大学は俺が卒業してからFWいれやがりました。
おかげで研究室のSSHサーバにログインできん。
>けどWinMXでトラフイック増やすのは辞めて欲しい。
WinMXはポート番号変えられますからねぇ...FWでは対処は難しいかも。
SnortとかのIDSでWinMXのシグネチャ書いてたたき落とすくらいしかないかねぇ。
マイクロソフトはどういうのかなぁ? (スコア:0)
今回、Apacheの脆弱性でワームが拡散したらマイクロソフトはそれ見たものか、と何らかを表明するはず。
また、オープンソースがマイクロソフトに攻撃されるのか?
黙して語らず? (スコア:1)
例えここでApacheを叩いたとしても,現在,IISのシェアが圧倒的でないMicrosoftにとってあまり得になるとは考えにくいわけで.
何かの話(ex.オープンソースは危険だ.たとえば…)のたとえ話としてネタになることはあっても,これを機にオープンソースコミュニティを総攻撃…とはならんでしょ.多分.
Re:マイクロソフトはどういうのかなぁ? (スコア:1)
勝手に修正して回るワクチンワームができるだろうよ。
NetCraft社がFreeBSDで動いているサーバに
ワクチンワーム送り回ると早く解決するかも。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:マイクロソフトはどういうのかなぁ? (スコア:1)
Nimdaのこともあるので、特に口撃されるようなことはないと思いますよ。
MSがどうこうより、いい加減な設定で動かされているApacheがあまり無いと祈りたいです。
Re:マイクロソフトはどういうのかなぁ? (スコア:2, おもしろおかしい)
ってことはApacheも「最も普及してる」から狙われた、と解釈する義務(笑)がありますね、MSは。
Re:マイクロソフトはどういうのかなぁ? (スコア:0)
今回の脆弱性って設定でどうにかなるものではないのでは・・・?
Re:マイクロソフトはどういうのかなぁ? (スコア:1)
Re:マイクロソフトはどういうのかなぁ? (スコア:1)
そうなんですか?
今回のワームってこれが問題になってるんですよね?
> http://www.cert.org/advisories/CA-2002-17.html
今は管理してるApacheが無いもので、いい加減にしか見てなかったんですが、てっきり設定で回避できるのかと思ってました。
でも、たとえ回避できたとしても、最新のにアップデートするのが最良なのはおっしゃるとおりですね。
Re:例え言ったにしても (スコア:1)
大抵 Un*x か、Linux 系なサイトが殆どのはずで、
Win** + IIS で再構築、といった選択肢は
おそらく無いと思われますが。
# あるいは、これを機会に apache からの乗り換え
# キャンペーン実施?
Re:マイクロソフトはどういうのかなぁ? (スコア:1)
Re:マイクロソフトはどういうのかなぁ? (スコア:0)
IISのワームが増えたりして…
Re:マ●クロソフト (スコア:0, 余計なもの)
つまらん...
ISPのApacheのバージョン (スコア:0)
例えば1.3.6 [airnet.ne.jp]とか1.3.9 [rim.or.jp]とか。
この2つはリダイレクトされたページはともかく、そこ自体は結構古いバージョンですよね。共にユーザーのページは古いほうにあるんですが。
Re:ISPのApacheのバージョン (スコア:0)
Re:ISPのApacheのバージョン (スコア:0)
どちらもバージョンアップする必要がありますよ。
+1 おもしろおかしい (スコア:1)
# mishimaは本田透先生を熱烈に応援しています
Re:+1 おもしろおかしい (スコア:1)
元ネタを知らないと、検索語にどの部分を選ぶかが微妙……。
鵜呑みにしてみる?