パスワードを忘れた？ アカウント作成
Close
7516 story

SourceForge.jpのプロジェクトWebサーバがクラックされる 41

ストーリー by Oliver
みんなの共有物 部門より

n225 曰く、 "SourceForge.jpのフォーラムに記載の通り、SourceForge.jpのプロジェクトWebサーバがクラックされ、Webサーバの実行権限でいくつかのコマンドが実行されました。
原因は、リンク先に記載がありますが、プロジェクトが設置していたPHPスクリプト(XoopsというCMSのAgenda-X追加モジュール)の脆弱性を突かれた模様です。なお、クラックされたサーバは SourceForge.jp のシステム本体とは切り離されているため、ユーザ情報やプロジェクトの情報の流出は無いらしいです。
原因となったプロジェクトのWebサイトは当面運用を停止し、他のプロジェクトのWebページは運用を継続するらしいですが、PHPはsafe_modeで動作させるように変更したため、既存のPHPスクリプトが動作しなくなる可能性がありますので、プロジェクトWebサイトの運用担当者の方はご確認ください。"

『SourceForge.jp では，みなさんを信頼し，プロジェクトWebの運用をお任せしています．プロジェクトWebで利用しているソフトウエアのセキュリティ情報などには十分注意するようにしてください．』

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

SourceForge.jpのプロジェクトWebサーバがクラックされる More

  • 対応が遅くない？ (スコア:3, 参考になる)

    by tamago915 (19926) on 2004年02月13日 18時35分 (#495228) 日記
    事態の経過を時系列で追ってみると、
    • 2004年1月21日：PHP スクリプトの脆弱性を突かれる
    • 1月23日：Web ページの一部を改ざんされる
    • 1月29日：当該モジュールの修正版がリリースされる
    • 2月3日：SourceForge.jp に改ざんが報告される。即時対応。
    • 2月13日：SourceForge.jp の掲示板に事態を報告。
    ですね。

    改ざん(1/23)から対応(2/3)まで11日間、対応から報告(2/13)まで10日間かかっているわけですが、これだけかかるのはやむを得ないことなのでしょうか。

    # 被害を小さく抑えることができたのは評価できるので ID
    • > 1月29日：当該モジュールの修正版がリリースされる
      > 2月3日：SourceForge.jp に改ざんが報告される。即時対応。

      うーん。SourceForge.jpは改ざんが報告されてから即時対応してますよね。
      なので、フォーラムに報告するまでに時間がかかったとしても、改ざんの報告を受けてからの対応自体は遅くないのではないかと個人的に思います。
      フォーラムへの報告は遅い気がしますが。

      ただ、改ざんが報告されなかったら、ずっと気づかなかったのかなぁ。

      # メールでは今日の11:30過ぎに通知が来ました。
      シェア
      親コメント
      • あと「修正版のリリース」というのも、今回の件の何に関連してかの情報もないですよね。
        改竄の発見に起因するなら「SFへの改竄の報告」の方が、普通は修正版リリースの前にくると思います。

        件のセキュリティフィックスを受けて、使用している箇所を確認したら改竄が発見された。
        しかし改竄行為の痕跡(ログ)はそれ以前の21～23日に掛けて発見されたということかな。
        シェア
        親コメント

    • 2004年1月21日に SourceForge.jp でホスティングしているプロジェクトが設置していた PHP スクリプトの脆弱性を突かれ，Web サーバの権限でいくつかのコマンドを実行されました．

      とあるのに

      2004年1月23日に当該プロジェクトのスクリプトの脆弱性

  • 危険だなあ (スコア:3, 参考になる)

    by ptosh (272) on 2004年02月13日 18時55分 (#495240) 日記
    問題のモジュールのソースを見てみました。
    どうも、外部から指定した不正なインクルードファイルを
    実行させるような攻撃だったみたい。

    このモジュールはXOOPS本体ではなくて、
    外部の人が公開しているものらしいけれども、
    (セキュリティ面での)コードの質が悪いなあ。
    XOOPSのように多くの人がモジュールを提供しあう 形態のアプリケーションの危険性が
    あらわになったと思います。

    それから、特にPHPなどはプログラマの層が広いので、
    今回のような危ないコードの事例を集めれば、
    参考になるように思います。
    すでにどこかにありますか？
    --
    ptosh

    • Re:危険だなあ (スコア:1, 興味深い)

      by Anonymous Coward on 2004年02月13日 19時16分 (#495256)
      「モジュールを提供しあう形態のアプリケーションの危険性」ってところが
      いまいち理解できないところがあるのだが、モジュールを管理するコアの
      アプリケーションで外部提供のモジュールの動作についても
      設計上制限を加えるべきという話？

      そうでなければ、共有サーバで、サーバモジュール版のPHPを
      non-safeで動かす危険性の方も同時に論じないと穴は埋まらない。
      SourceForgeの様にオープンかつ手軽に場を提供してくれる場合は特に。
      シェア
      親コメント

      • Re:危険だなあ (スコア:1)

        by ptosh (272) on 2004年02月13日 20時23分 (#495283) 日記
        「モジュールを提供しあう形態のアプリケーションの危険性」ってところが いまいち理解できないところがあるのだが、モジュールを管理するコアの アプリケーションで外部提供のモジュールの動作についても 設計上制限を加えるべきという話？
        いえ、モジュールの安全性まではコアの開発者もコントロールできないという意味です。

        ただ、モジュールを組み合わせることができるのがXOOPSの面白さなので、
        開発者や利用者に安全な運用を啓蒙していってもらいたいです。
        --
        ptosh
        シェア
        親コメント

        • いえ、モジュールの安全性まではコアの開発者もコントロールできないという意味です。

          そうでしょうか？
          モジュールの作者はどうあれモジュールをインストールしたのはコアのメンバー（開発者ではないかもしれませんが）であるはずです。
          これについて安全性を確認は出来たはずです。
          #今回とは違い、クローズドな「ソフトのプラグイン」とかについては、客観的に判断するしかないですけど・・。

          個人的には、ある程度プロジェクトが大きくなったならセキュリティについて専門的知識をもった人間の監視の目が必要になってくるのかなぁと思いました。
          #特に、スキルのまばらな顔もしらない開発者が集まるオープンソースな場合にはなおさら監督するひとは必要な気がする。

          他のご意見についてはおおむね賛成でしたがこの部分だけ。
          シェア
          親コメント
          • > モジュールの作者はどうあれモジュールをインストールしたのは
            > コアのメンバー（開発者ではないかもしれませんが）であるはず
            > です。

            　Xoopsはモジュールに対しては単なるプラットフォームにすぎず、プラグインはコアチームとはまったく無関係に自由に公開することができます。
            　安全性の確認ができないという点では、OSの開発者がアプリの安全性を確認できないのと同程度でしょう。
            シェア
            親コメント

        • Re:危険だなあ (スコア:0)

          by Anonymous Coward
          了解です。その上で、コントロール外でどれだけ安全なものを作ってもらえるか辺りが、課題になるところですよね。
          Microsoft他のベンダのように「認定○○」とコントロール内に入れるには、認定する要員が足らない。
          安全性くなる方向にいくような雛形や情報の提供に努めていくしかないのかな。
          • 安全性に関して評価し認定すのはある時点のコードに対してという事になりますが（それ以降改変されたものに対しても認定が継承されることはありえませんから）、そうなると「すばやく実装＆すばやく公開」というスタイルが使えなくなるんですよね。

            最新の

  • こっちの対応は早い (スコア:2, 参考になる)

    by azitt (13075) on 2004年02月14日 2時11分 (#495462)
    /.Jで取り上げられたからか、XOOPS日本チームの対応 [xoops.org]は早かったですね。
    たとえサードパーティによるモジュールの欠陥であって、自分たちには関係なかったのだとしても、
    きちんと火の粉を振り払う姿勢は好きですよ。

    俺は、自社のイントラサイトにXOOPS2を使わせていただいているのだが、
    会社の基幹に繋がっていることもあって、外に出せずにいます。
    また、自分で書いたモジュールを配布しないのも、FWで囲われたところでつかっているものなので、
    セキュリティに自信がないから。
    オープンソースの信念に反している気もするが、人様に迷惑もかけたくないし。;-)
    (そのうち公開したいと考えてはいるのだが)

    # コミュニティはROMってるID

    --
    azitt is not an agitator ;-)

  • XOOPS日本チームからのお知らせ (スコア:2, 参考になる)

    by osamu (301) on 2004年02月14日 2時17分 (#495464)
    XOOPS日本公式サイトからお知らせが出ています。
    これによると、現在公開されているAgenda-X 1.2.2も修正が必要とのこと。
    Agenda-Xモジュールでの脆弱性について [xoops.org]
    フォーラム [xoops.org]でも取り上げられています

  • 素人の質問です。 (スコア:1, 興味深い)

    by Anonymous Coward on 2004年02月13日 20時29分 (#495288)
    素人の質問で申し訳ないのですが、前々から気になっていたので教えてください。
    今回のようなクラッキングを受けた場合、「被害を受けた」ということはわかっても、
    どうやって原因を究明すればいいのでしょうか？
    自分も弱小ながらWebサーバを運営しているので、
    原因の究明方法を教えていただければうれしいです。

    • Re:素人の質問です。 (スコア:2, 参考になる)

      by sum (10437) on 2004年02月13日 21時31分 (#495327) ホームページ
      今回の件に限って言えば、クラッカーが実行したPHPスクリプトのURLが
      正規のPHPスクリプトへGETで渡されているようなログが残っていると思われます。
      ただし、そのような形式のログは外部のRSSなどのファイルを入手する場合にも
      記録されることがあるので、ログの前後の繋がりや正規のPHPスクリプトが
      そういった形式のログを残すようなものであるかも同時に確認する必要があると思います。

      特定のスクリプトが脆弱性を持っていることが既に判っていて、不正操作の痕跡を探す場合には
      そのスクリプトに着目してログを機械的に探せるので、チェックは比較的容易です。
      シェア
      親コメント

    • Re:素人の質問です。 (スコア:1)

      by ptosh (272) on 2004年02月13日 20時43分 (#495295) 日記
      apacheのログに、ありえないパラメータが記録されていたんじゃないでしょうか。
      --
      ptosh
      シェア
      親コメント

    • Re:素人の質問です。 (スコア:1)

      by heno (10869) on 2004年02月13日 20時48分 (#495296) 日記
      tripwire, forensic といったキーワードはいかがでしょう。
      シェア
      親コメント
    • みなさんの貴重なご意見ありがとうございました。
      今後はこれを参考にさせていただきます。

  • こんなのまで脆弱性だと (スコア:0)

    by Anonymous Coward on 2004年02月13日 20時01分 (#495275)
    その辺のプロバイダのweb serverなんて常に穴が開きっぱなしのような。
    • ウェブサーバの実行権限が取られたのはPHPがmod_phpで
      スクリプトがウェブサーバの権限で動いてるからだと思う。
      いうなればsuexecが無かった頃のcgiと同じ状態。
      んでmod_phpでsuexecと同様の事をしようとすると
      Apacheをrootで動かさないといけなくなってまた危険。

  • Free office! (スコア:0, オフトピック)

    by Anonymous Coward on 2004年02月13日 22時00分 (#495341)
    Perlスクリプトの脆弱性をついて個人情報を抜き取ったofficeさんが無罪であるのと同様に
    PHPスクリプトの脆弱性をついてWebサーバの実行権限で
    コマンドが実行されてしまっていても不正アクセス禁止法の適用対象とはならないので
    報告する必要はないのではないでしょうか。
    • office氏が今回の事件について無罪であるかは意見が分かれているところだと思うんですけど(というか、「個人情報を公開したところまで」無罪だと思っている人は少ないでしょ？)

      不正アクセス法の条文を寡聞にして知らないのですが、「Webページの改ざん」は不正アクセス法の適用対象にならないのでしょうか？

      # そもそも文章の意味が全くわからないんですけど。
      # 「興味深い」理由はもっとわかりませんが。

      # ちなみにoffice氏の「威力業務妨害」での逮捕はおかしいと思っている一人ですけどね。
      シェア
      親コメント

      • Re:Free office! (スコア:0)

        by Anonymous Coward
        そんなに長い条文じゃありませんので
        不正アクセス法の条文を読んでから発言してください。

        自分でできる事をすぐに他人に押し付けるのが不思議。
        条文読まずに何故「おかしい」とおもえるのか不思議。
        それでいて、他人に迎合したかのような言い回しも不思議。
        • 大変失礼しました。これからはそうさせてもらいます。
          後、公の場で他人の個人情報を勝手に公開するのが法律的に問題ないというのも(この下のACの方)知りませんでした。どうもすいません。しかしひどい話だなぁ。
          シェア
          親コメント

      • Re:Free office! (スコア:0)

        by Anonymous Coward
        > (というか、「個人情報を公開したところまで」無罪だと思っている人は少ないでしょ？)

        「個人情報の公開」が違法となる法律は寡聞にして知らないのですが、(^^;

        そうであるべきだ、そうであって欲しい

  • 他のXoopsサイトとかXoopsの中の人とか (スコア:0)

    by Anonymous Coward on 2004年02月14日 0時09分 (#495414)
    危険なのでは。更新放置してる人も少なくないと思います。
    で、この場合サーバー丸ごと迷惑かけちゃう事になるのでしょうか。

    また気になるのはXoopsのモジュールが脆弱性を含み、SQLインジェクションのような問題をアプリケーション全体にもたらしている、という話を以前に人づてに聞いており、今回の事が無くてもXoopsにコミットしている人たちの中にも気付いている人がいたのではないかと思うのですが、、対策が取れなかったという事なのかな。

    # CA出来てないんですよね。
    # XSSやSQLインジェクションといった脆弱性の検査ツールって無いんですかね

    • Re:他のXoopsサイトとかXoopsの中の人とか (スコア:1, 参考になる)

      by Anonymous Coward on 2004年02月14日 1時16分 (#495446)
      なんか勘違いしてる人が多そうなので言っておくと、
      今回の件はXOOPSが標準で提供してるモジュールではなくて、XOOPSプロジェクトではない
      外部の開発者が別プロジェクトとして提供しているモジュールの脆弱性によるもの。
      はっきり言えば、その辺の"単体"で提供されるPHPプログラムが持つ脆弱性となんら変わりがない。
      実際XOOPSがなくても、該当するファイルだけあれば穴が突けます。

      SourceForgeが利用者の融通を利きやすくするためか、PHPの動作制限が緩い設定で
      運営を行っていたので、それと相まって色々と出来てしまった。
      だからPHPに関してだけだと、
      ・ユーザの持ち込むPHPスクリプトの全て
      ・サーバでのPHPの動作設定
      の2点の見直しが必要なのであって、
      "XOOPSが…"とか言ってると足元すくわれます。

      ユーザの持ち込むスクリプトのチェックなんて全部は出来ないのが普通だと思うので
      管理者の自衛策としては「PHP動作設定の再チェック」が重要。
      シェア
      親コメント
    • Xoopsって中身がかなりChaoticなので、どこに脆弱性が潜んでいるか心配で心配で仕方ありません。
      誰か、コア周りだけでもいいのでサニタイズチェックをしっかりしてくれないかといつも他力本願に思っているのですが、やはり自分でやるしかないのでしょうか……。

  • つうかまあ効率は悪いかも知れんが (スコア:0)

    by Anonymous Coward on 2004年02月14日 4時05分 (#495490)
    いっそ各プロジェクト毎にUMLのVM(っていうのは構造上違うが）一つずつ
    割り当てて勝手にしろ状態にしては？
    とりあえずそうすれば全体に波及することは防げるでしょ。
    もちろん脆弱なコードのサーベイはいままでどおりやるのは前提として。
    • 仮想的なマシン環境を各プロジェクトに割り当てるって事ですか？

      環境隔離には最高に近いでしょうが、恐ろしいほどの量のメモリと
      IPアドレスが必要になるんじゃないですかね。

      運営側にとってはそこまでコストをかけてまで実現するほどのサービスではないと思うんだけど。有償サービスにするというなら話は別ですが。
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家