パスワードを忘れた? アカウント作成
3300 story

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, 参考になる)

    by lss (2577) on 2002年06月30日 15時51分 (#116286) ホームページ 日記
    記事の時点ではワームの名称は不明でしたが、 SymantecではFreeBSD.Scalper.Wormという名称 [symantec.com]になったようです。
  • by kei100 (5854) on 2002年06月30日 1時29分 (#116081)
    という迷信が、これで崩れ去ってくれればいいのですが・・・

    さて、ここから根拠もなく言ってきます。
    よって、マイナスモデレートされるべきかもしれません。

    <根拠なしの文>
    きっと、CodeRedで話題になったIISじゃないから安心と思って
    導入後、ずっと放置してあるApacheとかが
    主な長期的なキャリアになるのでしょうね・・・
    # いまだにCodeRed系も時々誘惑してるし、
    # 当てない人は、いつまでたっても当てないでしょうし・・・

    さて、今回のですが、
    ・分母の数が絶対的に多い
    ・脆弱性発見から、ワームが出回るまでの期間の短さ
    ・複数プラットフォームで、似たような脆弱性がある
    ・ワーム作者にとっては、*BSDのみならず、LinuxやWindowsや
    Mac(といってもOS Xだけかな?)も感染対象に出来るのですから、
    ある意味、名声を得るチャンスと思って張り切ってるかも。

    以上を考えると、CodeRedより悲惨な状態になるかもしれません。

    希望的観測で言うなら、
    ・Apacheを意識して動かしている人が多い。
    ・最近いくつも穴が見つかったので、
    管理者がセキュリティ関連の情報を注意している。
    ・CodeRed系の教訓から、HTTPプロトコルの中身をチェックする
    フィルタリングソフトを導入している。
    ・ワーム作者は、同時期に沢山穴が見つかったので、
    どの脆弱性を使ってワームを作ろうか悩んでいる。
    とかがある・・・かも。
    # まぁ、大抵「希望的観測」はミスを生むだけですが。

    さて、マルチプラットフォームな亜種は、いつ出るのかな・・・
    今年は、(ルータとかが)熱い夏になる・・・のか?
    </根拠なしの文>
    • by Anonymous Coward on 2002年06月30日 2時00分 (#116099)

      絶望的観測で言うなら、

      1. 自分が動かしているものは「Linux」だという意識しかない人が多い。
      2. 最近いくつも穴が見つかったので、管理者は混乱している。
      3. HTTPプロトコルなんて知らない。
      4. ワーム作者は、同時期に沢山穴が見つかったので、全部の脆弱性を使ってワームを作ろうとしている。

      というところでしょうか。

      私はApacheを使っていることを知っていますし混乱もしていませんが、正直な話、HTTPプロトコルは知りません。telnetでポート80に接続して「GETほげほげ」と入力して何かを入手したりすることくらいはできます。しかし「chunked encoding」なんてのは知りません。サーバの管理者は、そこまで知らないといけないのでしょうか?

      親コメント
      • >しかし「chunked encoding」なんてのは知りません。
        >サーバの管理者は、そこまで知らないといけないのでしょうか?
        知らなくてもApacheの管理者はやれますが、知ってればそれだけ
        多くのことに対応できるでしょうね。ま、一般論ですが。

        ちなみに「chunked転送」とは、送信時にコンテンツのサイズ(Content-Length)
        を指定せずにメッセージを送信する方法です。この際Transfer-Encoding: chunkedを
        ヘッダに付加します。
        動的なメッセージの場合、メッセージを生成しながら転送できるので
        (メッセージ全体を生成した後で転送する必要がない)、パフォーマンス面で
        有利です。
        クライアントのリクエスト、サーバのレスポンスともに使用することができますが、
        今回Apacheではクライアントからのchunkedされたリクエストの処理で脆弱性が
        発見されました。

        #HTTP依存はますます強くなっているので勉強しておくことをお勧めします。
        #まずはRFC2616 [w3.org]を見ましょう。
        親コメント
        • 知らなくてもApacheの管理者はやれますが、知ってればそれだけ
          多くのことに対応できるでしょうね。ま、一般論ですが。
          同感です。弱点が見つかったときの対応でいえば、知識があればあるほど、正式な解決方法以外の回避策を考えるときに有利だと思います。

          // というわけで、いろいろ勉強せにゃぁ。>ぼく :)

          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ちゃんねるでの議論をリアルタイムで読んでいたわけではありませんが。
          --
          鵜呑みにしてみる?
          親コメント
        • by fut (9276) on 2002年07月01日 13時23分 (#116702) ホームページ 日記
          最近、サーバの複合とか、プロキシの再転送とかを調整して
          いて、このchunked処理にはいろいろ問題がありそうだなと
          思っていたところへ、この騒ぎになりました。

          ちょっと忘れられているかもしれないDelegateにも、随分こ
          の処理がらみでパッチが出ていたり、処理ミスがあったよう
          です。また、HTTP/1.1指定によってHTTPコネクションを複数
          リクエストに渡って使用すると、途中のプロキシが対応して
          いなかったり、バグがあったりで、認証がらみでぼろぼろに
          なるような現象がよく出ます。

          仕様を作った方が悪いのか、仕様を正しく実現できないのが悪
          いのか、どっちもどっちですが、chunked encodingはバグの
          山のような気がしてなりません。
          親コメント
      • そこまで知らないてもいいと思います。私も「そういや、MS方面でチャンクエンコードのバグがどーのこーの、ってのがあったな」程度にしか知りませんでした。

        とりあえずサーバ管理者に必要なのは、それなりに十分な時間的余裕、bugtraqなどの「早い」情報源を適度に読める能力、サーチエンジン使ってそれが何かを調べるぐらいのリテラシー、ですかねえ。

        組織としてはダブルチェックできる体制ってのもほしいけど、こっちは個人の能力ではちょっとどうしようもないことが多くて悲しい。

        --
        -- Takehiro TOMINAGA // may the source be with you!
        親コメント
      • >サーバの管理者は、そこまで知らないといけないのでしょうか?

        HTTPプロトコルくらい知っておくべきでしょう。
        もしも、それで飯喰うのならばね。
        なんちゃってサーバ管理者なら、どーでもいいんですけど。
    • by Anonymous Coward on 2002年06月30日 19時20分 (#116337)
      >という迷信が、これで崩れ去ってくれればいいのですが・・・

      かつてSecurity Watchが終了した時に、

      『セキュリティ対策は、何かをしてしまえばそれで終わりではなく、こつこつと情報を集め、ひとつひとつ丹念に対策をとっていく、それを毎日延々と繰り返すというのがセキュリティ対策の第一歩だと私は思います。セキュリティホールはどんなOSやソフトであろうと、どんなに長い間安定して使われていようと、いつか突然でてきます。長い間、まったく問題無いと思われていたものに、ある日突然発見されたりするものです。よく冗談で「Unixはセキュリティに強いけど、NTはぼろぼろだ」とか言われますが、そんなことはありません。どんなOSにも例外無くセキュリティホールはあります。強いOSを使っているからと安心することなく、常に最新の情報を集め、対策を怠らないようにしないと大きな代償を払わなければならなくなります。』

      と書かれたいたことを思い出すなぁ。
      親コメント
    • うちの仕事がらみの某役所の話。

      三重県庁ウイルスバラマキ事件 [pref.mie.jp]の時には 「うちのメールサーバはUNIXだから大丈夫」

      当然ながら Apache は古いまま。 動くかどうかわかんないか

  • by tag (10007) on 2002年07月01日 1時05分 (#116494) 日記
    今回はおおごとになりそうだと思い、先々週に1.3.26が公開さ
    れた時にバージョンアップしました。しかし、面倒な作業を減
    らそうと、ちょっといい加減なやりかたをしてしまったかもし
    れません。

    皆さんは、どういうふうにバージョンアップをしていますか。
    教えて下さい。(できれば、どれくらい手抜きができるか、教
    えて下さい。)

    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で置き換えるしかな
    いのですかね。うまく動かなかった時に元に戻れるか、ちょっ
    と不安ですが、大丈夫でしょうか。

    今回のように緊急に置き換えが必要な時、皆さんはどういうふ
    うに作業しているんですか。教えて下さい。
    • >今回のように緊急に置き換えが必要な時、皆さんはどういうふ
      >うに作業しているんですか。教えて下さい。

      構成の複雑さによりけりじゃないですかね。
      上書きはモジュールがバージョンの差異で不具合を起こすことも
      ありますからバッサリ上書きというのもぞっとしないですが、
      単に./configureした程度のものなら、私ならバッサリやります。
      普通は仰るとおりにシンボリックリンクを使用するのが安全でしょう。
      非常に込み入ったことをしているなら作業に時間がかかって
      危険かもしれませんが。

      この間PHP-4.2.1が動いてる1.3.24を1.3.26に入れ替えましたが、
      そのときは急ぎだったのでhttpdと標準モジュールだけすげ替えました。
      一応CHANGESには目を通して大丈夫だろうという算段でやったのですが、
      今のところ問題ないように見えます(実は節穴だったりして)。
      httpd.confもだいぶいじってますが大丈夫でした。

      しかし、大事なのは緊急に備えて日頃から使用しているアプリケーションの
      動向をチェックしておくことでしょうね。それにつきます。
      ほったらかしにしておいて緊急時にあわてるのは避けたいです。
      #業務多忙な管理者には酷なことかもしれませんが。

      あと、このあたりのスレッド [apache.or.jp]なんかは参考になります。
      親コメント
    •  サーバの構成や、運用の携帯などで方法は様々ですが、一番良いのはごっそりバージョンアップするのがいいとは思いますが

       構成によっては危弱性のあるバージョンでも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
      親コメント
    • $./configure --オプションいくつか
      $make
      #apachectl stop
      #make install
      #apachectl start
      ですが、何か?
      親コメント
  • > 今回のWormはFreeBSDがターゲットのようですが、
    > 次はやはりLinuxを狙う亜種が出そうな感じです。

    勘ですが、おそらく既に存在しているのでしょうね。
    LinuxやWindowsで動作するApacheの方が多く、
    なおかつセキュリティに関心の薄いユーザ層が多いことを考えると
    そっちを狙った方が成功する確率はずっと高いわけで。
    FreeBSD用が最初に見つかったのはたまたまでは?と考えてしまいます。

    #ちなみに、6/20に警告してあげた知り合いのLinuxサーバは
    #さっきHTTPヘッダを見たらApache-1.3.22でした。そんなもんです。

    いまだにCodeRedがやってくることから考えても、この件は長びきそうです。
    • by fuji (2113) on 2002年06月30日 2時30分 (#116114)
      > #ちなみに、6/20に警告してあげた知り合いのLinuxサーバは
      > #さっき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 だから必ず問題がある、という
      わけではないはず。
      親コメント
      • しまった、予想通りの指摘をされてしまった。
        一応弁解すると、この「知り合い」はRedHatを使用していますが、
        Web用のサーバ(HTTP,FTP等)はソースから入れる人なので「対応していない」
        と判断したわけです。
        ちなみに、新しいバージョン(1.3.26)があるのにわざわざ古いもの(1.3.22)に
        パッチを当てて使い続けるような人ではありません。
        一時しのぎにrpmを使用することもしないでしょうし。
        (絶対に対処していない、とも言い切れませんが・・・)

        #HTTPヘッダのみで判断できないというのは私もわかります。
        #説明不足でした。
        親コメント
        • by Anonymous Coward
          いまさらだし墓穴掘りそうだけど。

          私もその気になればソースからバージョンアップしてもいいのですが、会社のサーバだとこれがちょっと怖かったりします。
          Debianのstableもそうですが、むやみにバージョンを
      • いや、ヘッダでバージョンがわかるという時点で、ちょっとポイント低いでしょ。httpd.confに

        ServerTokens Prod

        書いておかないと。(ただしProdは1.3.12以降)

        詳しくは
        http://httpd.apache.org/docs/mod/core.html#servertokens
        をどうぞ。
        • ヘッダのバージョン消したくらいで狙われなく(にくく)なるなんて考えてる時点でアウト
          • いや、こんなの↓よりは

            Server: Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.0.6

            このほうが

            Server: Apache

            少しはセキュリティにいいかな、とは思う。あとトラフィックも*ちょっと*減るし。

            そもそもレスポンスのserverヘッダって何か役に立ってるんだろうか。消すと何か問題がありますかね? (Netcraftが困る、とかいうのは除いて)
            • 結果がどうこうではなく、わざわざそのように設定した人間の意図が何かというところに問題が隠れているのでは?

              あと、お客様の個人情報を預かるサーバの場合には、説明責任を怠っているとも言える。

    • by MITsu_at_mit-net (4220) on 2002年06月30日 11時35分 (#116202)
      >> 今回のWormはFreeBSDがターゲットのようですが、
      >> 次はやはりLinuxを狙う亜種が出そうな感じです。

      > 勘ですが、おそらく既に存在しているのでしょうね。

      packet storm [decepticons.org]に、LinuxとSolaris用のexploitsがあがってたら、
      今頃大騒ぎになってた気がします。
      # 今出てる奴は、対象は「FreeBSD, NetBSD, and OpenBSD」となってます。
      親コメント
    • by Anonymous Coward on 2002年06月30日 14時25分 (#116263)
      LinuxやWindowsで動作するApacheの方が多く、
      なおかつセキュリティに関心の薄いユーザ層が多いことを考えると
      そっちを狙った方が成功する確率はずっと高いわけで。
      FreeBSD用が最初に見つかったのはたまたまでは?
      意図したものかもしれないよ。
      感染サーバ蔓延を第一に考えるなら、最初にLinux(特にRed Hat)用を作るはず。
      だってさ、HTTPでIPアドレスを直に指定してアクセスしたときに
      出てくる「Worked it!」の多さと言ったら・・・。

      そんなサーバ運営者がパッチ当てしてるとは思えないでしょ。
      しかも、FreeBSDだったら意図しないとapacheは入らないはずだし。
      親コメント
  • 問題ないでしょう。

    会社のサーバは基本的に俺がインストールマニアなので大丈夫(だと思う)
    心配なのは会社のサブドメインのなんちゃって管理者が管理しているサーバ。
    自称パワーユーザーともいう。
    海外からお叱りのメールをいただくのはもう嫌です。

    それにしても韓国方面からのSPAMなんとかしてください。
    MLで配られるのは勘弁。
    • by a Coward (5383) on 2002年06月30日 3時35分 (#116135) ホームページ
      私は会社でなんちゃって管理者をやっているのですが、
      パッチというか、RedHatが配るアップデートRPMが出たら
      無条件でアップデートしています。
      正直言って、アップデートされる内容は殆ど理解して
      いないのですが、そんなもんでも何とかなるようです。

      そんなんじゃ管理者失格だ!という真面目なお叱りも
      あるでしょうけど、専門じゃない人間には、これが
      精一杯です。
      親コメント
      • by Anonymous Coward
        RedHatで思い出した事ですが、一年程前に大学寮のProxy鯖を
        telnetdの脆弱性を利用して、鯖自体のハイジャックに成功した
        奴がいたな。

        結果的にrootがtelnetdのような余計なデーモンを殺したことで、
        事が一件落着したけどね。

        ちな
  • 大学なんて (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2002年06月30日 12時00分 (#116204)
    そんなもんでしょ。
    けどWinMXでトラフイック増やすのは辞めて欲しい。
    • by Anonymous Coward
      >そんなもんでしょ。

      うちの大学は俺が卒業してからFWいれやがりました。
      おかげで研究室のSSHサーバにログインできん。

      >けどWinMXでトラフイック増やすのは辞めて欲しい。

      WinMXはポート番号変えられますからねぇ...FWでは対処は難しいかも。
      SnortとかのIDSでWinMXのシグネチャ書いてたたき落とすくらいしかないかねぇ。
  • by Anonymous Coward on 2002年06月29日 23時44分 (#116031)
    マイクロソフトはCodeRed、Nimdaで痛い目にあっているはず。

    今回、Apacheの脆弱性でワームが拡散したらマイクロソフトはそれ見たものか、と何らかを表明するはず。

    また、オープンソースがマイクロソフトに攻撃されるのか?
  • by Anonymous Coward on 2002年06月30日 16時19分 (#116296)
    トップページは新しいのを使いつつユーザーのページには古いバージョンを使うところがあるんですがどうしたらいいんでしょうか?
    例えば1.3.6 [airnet.ne.jp]とか1.3.9 [rim.or.jp]とか。
    この2つはリダイレクトされたページはともかく、そこ自体は結構古いバージョンですよね。共にユーザーのページは古いほうにあるんですが。
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...