WAF(Web Application Firewall)とは、通常のレイヤー2や3（IP, TCP/UDP）レベルのファイアーウォールよりもさらに上のレベルのアプリケーション層のファイアーウォールです。アプリケーションはレイヤー7とも言われ、ネットワークスイッチなどではアプリケーションの中身まで参照してスイッチングするスイッチはレイヤー7スイッチと呼ばれてきましたが、ファイアーウォールではレイヤー7ファイアーウォールと呼ばれる事は少なく、WAFと呼ばれる事が多いです。
WAFの目的は名前からも明白です。Webアプリケーションを脅威から守るために利用されます。WAFはWebアプリケーションをセキュリティ上の脅威から守る事ができますが、昔レイヤー2/3のファイアーウォールの能力が誇大に広告され、誤った認識で利用されていたように、WAFの能力も誤解されている事が少なくありません。
http://www.0x000000.com/?i=567 にmod rewriteを利用した簡易WAF(Web Application Firewall)の定義例が掲載されています。同じようなアイデアをお持ちの方、既に似たような設定を使われている方も多いとは思います。
もっと読む
日本ではサウンドハウスがSQLインジェクションによりクレジットカード情報を盗まれた事が記憶に新しいですが、F-Secureによると51万ページ以上のWebページがSQLインジェクションによりクラックされ、ドライブバイ攻撃に利用さているとしています。
IISサイトにはSQLインジェクションに脆弱なサイトが多いと言われていました。
Googleのリサーチでもアダルトサイト以外の一般サイトの方がマルウェアを含む確率が高いとしているのであまり驚くべき数字ではありません。
SQLインジェクションはJavaScirpt/HTMLインジェクションなどと異なり、簡単に防ぐ事が可能な脆弱性です…
# WAFでと言う意味ではなく、プログラムレベルで
# 完全に防げる脆弱性です。
Webサーバは攻撃対象にされる事が多く、昨年秋から数万台のLinux Webサーバがカーネルレベルルートキットに感染しマルウェア配布に利用されていた事例も記憶に新しいです。
有名サイト（ZD Net Asiaなど）に対して検索フォームとSEOと組み合わせた攻撃も記憶に新しいです。
攻撃の自動化もかなり進んでいるので「自分のサイトは大丈夫」と思っていられる状況ではなくなりつつあります。
最近CVEのコピー&ペーストが続いていますがこのブログに書いていた予想通りの展開なのでまたコピーです。
コアとはいえあまり重要ではない箇所の脆弱性ですが、Python 2.5.3にリモートコード実行の可能性がある脆弱性がレポートされています。
CVE-2008-1679
Overview
Multiple integer overflows in imageop.c in Python before 2.5.3 allow context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted images that trigger heap-based buffer overflows. NOTE: this issue is due to an incomplete fix for CVE-2007-4965.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 6.8 (Medium) (AV:N/AC:M/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 8.6Access Vector: Network exploitable , Victim must voluntarily interact with attack mechanism
Access Complexity: Medium
Authentication: Not required to exploit
Impact Type: Provides unauthorized access, Allows partial confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service
直したつもりが直っていないのはよくある事です。直したはずだったCVE-2007-4965は以下の通りです。
CVE-2007-4965
Overview
Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows.
CVE登録されているので私がコピー&ペーストするまでもないですが、予想通りにPythonの脆弱性が出てきました。
CVE-2008-1887
Overview
Python 2.5.2 and earlier allows context-dependent attackers to execute arbitrary code via multiple vectors that cause a negative size value to provided to the PyString_FromStringAndSize function, which allocates less memory than expected when assert() is disabled and triggers a buffer overflow.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 7.5 (High) (AV:N/AC:L/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 10.0Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Provides unauthorized access, Allows partial confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service
こういう脆弱性にはSELinuxが役立ちます。
未知の脆弱性に対してはSELinuxなどが無いと守るのは難しいです。
SELinuxの効用はわざわざ書くほど事ではない、と思っていましたがMACにより未知の脆弱性に対する防御がある程度できる事を正しく理解されていない場合もあるようです。
SELlinuxなどを導入していれば任意コード実行が試みられても、auditログに記録されログ監視システムなどで攻撃を直ぐに検出できる可能性が高くなります。
サーバを守る側は多くのプログラムを安全に保つ事が要求されますが、サーバを攻撃する側はたった一つの致命的脆弱性か攻撃パスを見つければ良いだけです。サッカーのPK戦のゴールキーパーのように守る側の方が圧倒的に不利なゲームです。この不利なゲームを効果的に戦うにはSELinuxなどのフェイルセーフな仕組みが必要不可欠です。
ゴールに全面（任意コマンド実行攻撃の目標全て）に蓋をするくらいの効果はありませんが、ゴール面積の7割くらいに障害物を置くイメージに近いと思います。守りやすさは比べ物にならないです。
WEBrick+Windowsでサービスしているところはあまり無いと思いますがファイルを不正に読み取られる可能性があります。
CVE-2008-1891
Overview
Directory traversal vulnerability in WEBrick in Ruby 1.9.0 and earlier, when using NTFS or FAT filesystems, allows remote attackers to read arbitrary CGI files via a trailing (1) + (plus), (2) %2b (encoded plus), (3) . (dot), (4) %2e (encoded dot), or (5) %20 (encoded space) character in the URI, possibly related to the WEBrick::HTTPServlet::FileHandler and WEBrick::HTTPServer.new functionality and the :DocumentRoot option.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 5.0 (Medium) (AV:N/AC:L/Au:N/C:P/I:N/A:N) (legend)
Impact Subscore: 2.9
Exploitability Subscore: 10.0Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information
http://www.macrumors.com/2008/04/18/apple-modifies-software-update-for-windows/
に新しいApple Software Updateのスクリーンショットが載っています。インストールもしていないのに、脆弱性が多く発見されている「Safari」（Webブラウザ）を勝手にインストールしてしまう、と非常に評判が悪かったのですがやっと修正したようです。
新しいApple Software Updateでは、インストール済みのアプリケーションのアップデートと新しいアプリケーションが明確に区別できるようになっている事が分かります。
ところで、QuickTimeも脆弱性の塊、と言えるソフトウェアです。全く使っていないユーザも多いと思われます。早くiTunesとQuickTimeの抱き合わせパッケージングも止めるべきだと思いますが、こちらは修正しない可能性が高いです。Safari強制インストールも問題ですが、QuickTimeの抱き合わせ問題も解消してほしいものです。
GoogleがカスタムアプリケーションのホスティングにPythonを採用しました。これにより多くのセキュリティ研究者の研究対象がPythonに向けられ、PHPで報告されていたような問題がセキュリティ脆弱性して多数レポートされるようになるのではないか、と予想していました。
さっそくセキュリティ脆弱性が多く発見されるライブラリの一つであるzlibライブラリにお馴染みの脆弱性が報告されています。
CVE-2008-1721
Integer signedness error in the zlib extension module in Python 2.5.2 and earlier allows remote attackers to execute arbitrary code via a negative signed integer, which triggers insufficient memory allocation and a buffer overflow.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 7.5 (High) (AV:N/AC:L/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 10.0
負の整数が指定された場合が考慮されていないので攻略コードを埋め込まれた圧縮ファイルで任意コードが実行できるようです。よくあるタイプの脆弱性です。
しばらくは色々レポートされる事だと思います。
追記：
ところでこの脆弱性は未パッチです。
http://www.python.org/download/
の最新リリースは、現時点(4/14)でも、2/22日リリースされた2.5.2になっています。このページにはパッチへのリンクもありましたが、この脆弱性とは全く関係ないページが表示されていました。コメントにも書きましたが開発者がセキュリティに大きな注意を払っていない事を前提に対策を考える方が良いです。これは何もPythonやPHPに限った事ではありません。
参考
http://www.atmarkit.co.jp/news/200804/08/appengine.html
関連：
追記：
予想通りの展開です。任意コード実行の脆弱性のCVEが公開されています。
技術評論社でブログっぽい記事を書かせて頂いています。4月3日からスクリプトインジェクション対策で注意すべき項目が掲載されます。一般的なスクリプトインジェクション対策「バリデーションしエスケープする」ではなく、万が一スクリプトインジェクションに脆弱であった場合でも被害を最小限に留める対策、見落とされがちな対策を中心に解説しています。
# 一度に書いた記事なのでどう分割されるか私も分かりません。
# 物によっては2回に分割するかもしれないので20弱くらい
# だと思います。
http://gihyo.jp/dev/serial/01/php-security
から最新の一覧を参照できます。
ご意見やご希望などございましたらこのブログから送って頂いても、メールで送って頂いても歓迎致します。ご興味がある方はご覧ください。
もっと読む
Smarty 2.6.19未満のregex_replaceは脆弱だったと言うよりは、今でも脆弱と言った方が良いと思います。
Smarty 2.6.19は2008/2/11にリリースされました。ちょっと古い話ですが、Smarty 2.6.19より前のバージョンのregex_replaceは脆弱、とアナウンスされています。
もっと読む
件名の通り、APCのStack Overflow脆弱性が公開されています。
http://sla.ckers.org/forum/read.php?3,21615,21615#msg-21615
このポストに書いてある通り、PHP4ではインクルード攻撃に脆弱なアプリならallow_url_fopenをoffにしていても効果はありません。PHP4+APCを使っている方は今すぐAPCをCVSバージョンにバージョンアップするか、APCをロードしない方が良いでしょう。
MomongaLinux等、パッケージをビルドする際にstack smashing attackから防御するstack protectorオプションを使ってビルドしているバイナリであればリンク先の攻撃方法では攻撃できません。しかし、インクルード攻撃に脆弱であれば、他の脆弱性を利用してカナリア値を盗む事も可能なので安全とは言えません。いずれにせよAPCを利用している場合はバージョンアップする方が良いでしょう。
追記：
CVSを見てみました。
http://cvs.php.net/viewvc.cgi/pecl/apc/apc.c?r1=3.20&r2=3.21
fileinfoがスタック変数、strcpyでオーバーフローしてます… 教科書通りの解りやすい脆弱性です…
この記事のタイトルは参照しているページのタイトルをそのまま使っています。
誤解を招く記事 – LAMPセキュリティを強化する4つの方法で、
実行できる最も重要な対策は、PHPを使わないことです。
と、理解できない対策を勧めています。セキュリティの事を解っていない素人が書いた事は、記事の内容と趣旨から明らかです。
しかし、IPAにも同じような事が書いてあったのですね。「例えば、PHPを避ける」ってなぁにその曖昧な書き方？で書かれています。去年から掲載されていたと思います。
IIS+ASPのアプリにダメダメなWebアプリが多いのも事実ですが、言語を問わずダメなプログラムだらけです。LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠では最近発見されたPythonベースのCMS、Ploneの脆弱性を紹介していますが、Java, Perlも同じです。
特に「LAMPセキュリティを強化する4つの方法」にPHPからPerl等に替えれば安全になるように勧めていますが、著者はPerlで作った恐ろしく穴だらけのCGIの数々を見たこともないのでしょう。探さなくてもそこら中にあるのですが…. フレームワークの利用は安全性向上に役立ちますが、フレームワークを使うだけでは安全になりません。JSFやRailsで作ったから、といって自動的に安全なWebアプリは作れません。
セキュリティを向上させるために他の言語に替えて再構築するリソースがあるなら、使っているプログラム（OS,Web,言語,フレームワーク,アプリ）きちんとバージョンアップをした上で、開発者が正しいセキュリティ知識を習得できるよう努力すべきです。
企業ならソースコードレベルの監査とコンサルティングを依頼した方が、言語を替えるよりよっぽど効果的で、コストも少なく効率的です。言語を替えても設計・ソースコードレベルでのセキュリティ監査はセキュリティ維持には欠かせません。
LAMPはLinux, Apache, MySQLとPHPまたはPerl, Pythonを利用したWebシステムの総称として利用されている用語です。
特にLinux/Apache/MySQL/PHPはよく見かけるシステム構成です。ホスティングサービスを提供する会社でこの構成をサポートしていない会社を探すのが難しいくらいではないかと思います。広く使われていますが、「十分に安全な状態」と言える状況で運用されているケースはほとんどありません。
関連エントリ
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。
結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。
もっと読む
LAMPセキュリティを強化する4つの方法
http://enterprisezine.jp/article/detail/311
書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。
# 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。