Apache の脆弱性を攻撃するツールが登場 36
ストーリー by yourCat
ScriptKiddyに備えよ 部門より
ScriptKiddyに備えよ 部門より
jeff2曰く、 "Apache の脆弱性を攻撃するコードが出回り始めたようです
コード自体はPacket Storm辺りを探せば見つかるようです。今回は、Apache、mod_ssl、Apache-SSL(未確認)も既に修正版が出回っているので、万一まだ入れ替えていないところは早急に入れ替える必要があるでしょう。"
Apache-1.3.23 を使いたい方は (スコア:3, 参考になる)
apache-1.3.23 などを使いたいかたにパッチもご用意しております。 :-) http://pkgcvs.turbolinux.co.jp/cgi-bin/cvsweb.cgi/apache/1.3.23/apache... [turbolinux.co.jp] にあるパッチを使ってくださいね。
あと、apache-1.3.22 以前で利用する mod_ssl にも問題があるので、mod_ssl の組み合わせでいく方は apache-1.3.23 + mod_ssl-2.8.7-1.3.23 + [このパッチ] の組み合わせでどうぞぉ。
Re:Apache-1.3.23 を使いたい方は (スコア:2, 参考になる)
Re:Apache-1.3.23 を使いたい方は (スコア:0)
TurboLinux6.5Jですが、問題なくビルド／インストールできました。
ありがとうございました。
Re:Apache-1.3.23 を使いたい方は (スコア:1)
TL6.5 ってことは、apache-1.3.17 ですよね。えー、僕としては Turbolinux 8 Workstation で、apache モジュールを入れ替えるのがメンドクサイから 1.3.23 なのであって、そうでなければ、公式アナウンスどおり 1.3.26 に上げてしまえばいいと思うんですけど……。
ていうか、それじゃ PHP 動いてなくないですか？ 使ってない？
Re:Apache-1.3.23 を使いたい方は (スコア:0)
1.3.26でモジュールのバイナリ互換がないので、1.3.26にアップデートしないまま使いたかっただけなのです。
（他のWebアプリサーバ用のモジュールを使いたいので）
ちなみに、TLJのftpに上がっている1.3.23も、1.3.26にしたときと同じようにフォル
Re:Apache-1.3.23 を使いたい方は (スコア:1)
Apache-SSL (スコア:2, 参考になる)
(by セキュリティホールmemo [ryukoku.ac.jp])
TL7用のrpm (スコア:1)
Re:TL7用のrpm (スコア:2, 参考になる)
Apache-1.3.24 あたりから以前の apache-1.3 とモジュールのバイナリレベルでの互換性がなくなってるみたいです。。 モジュールを再度コンパイルすれば大丈夫みたいなのです。
多分、error_log に Segmentation fault したとかいう内容が たくさん出ているんじゃないかと。 そうだったら、多分このモジュールの問題です。
Re:TL7用のrpm (スコア:1)
そそ、古いモジュールの確認方法なのですが、turbolinux の場合だと
して、2002年6月19日以降のファイルが apache-1.3.26用になります。 それ以前のものは rpm -e してくださいね。
Re:TL7用のrpm (スコア:1)
1.3.23-3では対応されていなかった、libphp4.soの移動もちゃんとされていますし。
httpd.confの修正が必要なんでしょうか？
Re:TL7用のrpm (スコア:1)
ならば、httpd.conf の LoadModule と AddModule のそれっぽいところをコメントアウトしながら試してみていただけますか？
Re:TL7用のrpm (スコア:1)
phpモジュールが原因でした。こちらも最新のものにアップデートしたらOKでした。
大変助かりました。ありがとうございます。
Re:TL7用のrpm (スコア:1)
ふーっ、よかったよかった。 死ぬかと思いましたよ(ワラ）
Re:TL7用のrpm (スコア:1)
Re:TL7用のrpm (スコア:1)
で、それにアップデートすると、アップデートしたWebServerの応答が全部 "The document contains no data." になるんです。httpdを止めると "The connection refused .... " になるので、httpd自体は動作しているみたいなんですが。
Re:TL7用のrpm (スコア:2, 参考になる)
Re:TL7用のrpm (スコア:1)
別枝ですでにコメントありましたね、失礼。
Re:TL7用のrpm (スコア:1)
mod_sslは依存関係でエラーが出たので、最新のものを入れてたんですが、phpの方は見落としていました。
ありがとうございます。
Re:TL7用のrpm (スコア:1)
Re:TL7用のrpm (スコア:1)
たぶんそちらのTL7はmod_throttleがインストールされてなかったのでは？
rpm -qa | grep mod_
で、インストールされているモジュールを全部確認して、全てアップデートする必要があるみたいです。
Re:TL7用のrpm (スコア:0)
> 取得しないとダメです。
この辺、rpm の依存関係で解決してくれたりしないの？
Re:TL7用のrpm (スコア:1)
普通のライブラリなら RPM が依存関係見てくれるんですが、Apache とプラグインの間のインタフェイスは両者間の勝手なとりきめですからねえ。RPM の管轄外です。
PHP の Zend みたいに、API にバージョンがついていればパッケージ側で小細工のしようがあるんですが、apache の API にはバージョンはないのでしょうか？
Re:TL7用のrpm (スコア:1)
ありました。"/usr/include/apache/ap_mmn.h" のマクロ MODULE_MAGIC_NUMBER_MAJOR と MODULE_MAGIC_NUMBER_MINOR がそれにあたるようです。apache-1.3.23 が 19990320-11 で、apache-1.3.26 が 19990320-13 ということなので、構造体のサイズ的には互換性があるけれど、API 的に互換性がないということです。apache の RPM が何らかの形でこれを provide してプラグイン側 RPM が require すれば、依存関係ができるはずです。
コンパイル済みプラグインからこの値を取得する方法は不明。
Re:TL7用のrpm (スコア:1)
Apacheをアップデートするときに見るのは、依存関係の強い（Apacheがバージョンアップしたら必ず再コンパイルが必要な）モジュール、Turboの場合はmod_sslだけですね。ちなみにTurboのApache srpmは、apache-*.rpmとmod_ssl-*.rpmを作ります。mod_ssl単体のsrpmはないです。
他のモジュールは必ずしもApacheのバージョンが上がったからといって、再コンパイルが必要になるわけじゃないので．．．．rpmのSPECファイルは必要なものはチェックできるけど、「インストールしてなくてもいいけど、インストールされていればバージョンはXX以上」というようなチェックは書けなかったのではないかと思いますが。
コードのコメントより (スコア:1, 参考になる)
* - Can not be exploited on 32-bit *nix variants
* - Is only exploitable on win32 platforms
* - Is only exploitable on certain 64-bit systems
*
* However, contrary to what ISS would have you believe, we have
* successfully exploited this hole on the following operating systems:
*
* Sun Solaris 6-8 (sparc/x86)
* FreeBSD 4.3-4.5 (x86)
* OpenBSD 2.6-3.1 (x86)
* Linux (GNU) 2.4 (x86)
だ、そうです。早急に対策が必要みたいです。
Linux方面でも、各ディストリビューションの対策パッケージが
出そろってきたようなので、とっととアップデートしましょう。
とはいえ、クラッキングされたサイトだらけになる予感...
Re:コードのコメントより (スコア:2, すばらしい洞察)
ソラ環境、32ビット環境も対象なのね（ってあたりまえだな
CodeRed は攻撃コードが広域に流れてから、ワームが登場するまで、半月くらいでしたっけ？
あーあ、今年もワーム夏の陣かな…。
みんつ
Re:コードのコメントより (スコア:0)
ssp [ibm.com]付きで Apache をコンパイルするとどのような挙動になるのか試してみたいところです
(乗っ取りはできないが、子プロセスが死ぬ？？かな？)
SunのCobalt (スコア:0)
大量被害の予感…
Re:SunのCobalt (スコア:0)
CobaltのFTPは何処？ (スコア:0)
README に書かれている experimental ディレクトリが消えている…
Re:CobaltのFTPは何処？ (スコア:1)
かと言って、RPMパッケージを自分でインストールすると、 後々のパッケージ管理と競合しそうで嫌なので、 僕の管理するサーバでは暫定的にリバースプロキシサーバを立てて誤魔化してます。
Re:CobaltのFTPは何処？ (スコア:1)
目的:
・本設定のために追加機材を使用しない。
・既存の Apache の設定は一切変更しない。
・作業に手間をかけない。
方針:
・外部からの 80/TCP への接続は 3128/TCP (Squid) にリダイレクト。
・3128/TCP で稼動する Squid を httpd-accelerator mode で動かす。
機材:
Cobalt RaQ3
インストールするパッケージ:
squid-2.4.STABLE3-1.6.2.i386.rpm
openldap-1.2.12-3.i386.rpm
* RedHat Linux 6.2 update から get する。
squid の設定:
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
redirect_rewrites_host_header off
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow all
icp_access allow all
httpd_accel_host virtual
httpd_accel_uses_host_header on
ipchainsによるリダイレクトの設定:
ipchains -A input -s [IP addess for itself]/255.255.255.255 -d [IP addess for itself]/255.255.255.255 80:80 -p 6 -j ACCEPT -l
ipchains -A input -s [IP addess for itself]/255.255.255.255 -d 127.0.0.1/255.255.255.255 80:80 -p 6 -j ACCEPT -l
ipchains -A input -s 127.0.0.1/255.255.255.255 -d 127.0.0.1/255.255.255.255 80:80 -p 6 -j ACCEPT -l
ipchains -A input -s 0.0.0.0/0.0.0.0 -d [IP addess for itself]/255.255.255.255 80:80 -p 6 -j REDIRECT 3128
ipchains -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 3128:3128 -p 6 -j REJECT -l
*最初の３行は、ホスト自身から80/TCPへのアクセスを許可する設定。
４行目は他ホストからの80/TCPを3128/TCPで処理させる設定。
５行目は他ホストからの3128/TCPへの直接接続を禁止する設定。
動作確認:
/var/log/squid/access.log, /var/log/httpd/access を見て
意図した動作であるかどうかを確認する。
正しく動いていないときは ipchains -F 。
不正なチャンク形式エンコードに対する脆弱性の解消確認:
Packet Storm あたりから入手した exploit コードを用いてテストする。
Apache のエラーログに、
[Wed Jun 26 12:34:05 2002] [notice] child pid 10607 exit signal Segmentation fault (11)
が出なくて、Squid のアクセスログに
1025062349.972 6 61.206.141.236 NONE/413 1213 NONE error:request-too-large - NONE/- -
が出れば、たぶんＯＫ。
Re:CobaltのFTPは何処？ (スコア:1)
先の squid.conf はテスト用設定で http_access allow all なんて
危険な設定が入ってるからリバースプロキシだけじゃなく、
オープンなプロキシとして動いてしまいます。
もうちょっとマシな設定はこれ。
acl の virtualdomain とか virtualhost は
環境に合わせて調整が必要です。
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
redirect_rewrites_host_header off
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl virtualdomain dstdomain www.example.co.jp
acl virtualhost dst xxx.xxx.xxx.xxx
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow virtualdomain
http_access allow virtualhost
icp_access allow all
httpd_accel_host virtual
httpd_accel_uses_host_header on
pierreさんありがとう！参考になります。 (スコア:0)
業者の対応次第だったりします（泣）。
NECのノートにも (スコア:0)
いうモバイルからのリモートアクセスの機能でapacheが使われ
ているのですが、サポートに電話で質問したら修正を出す予定
はないそうです。
ユーザリスクでapache入れ替えるしかない模様。