カテゴリー: Security

Javaの脆弱性

書かない日記なので書きませんがJava（JRE,JDK,SDK）の脆弱性が多数CVEとして公開されています。数日前のアップデートで更新されていると思いますが、WindowsUpdateのついでにJavaもアップデートの確認をした方が良いです。

アプレットを使ったリモートからの任意ファイルの読み取り、DNS Rebinding攻撃に対する防御などいろいろアップデートされています。

勝手に更新するように設定していたはずのPCでもJavaアップデータのバグか何かで更新ができていないPCもあるのでちょうど良い機会のなので念のために確認するのも良いと思います。

JRE1.6ならJRE Update 3(1.6.0_03), JRE1.5ならUpdate13, JRE1.4なら1.4.2_16になっていればOKです。

CVEの一部
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5274
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5273
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5239

IEの脆弱性

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3893

Unspecified vulnerability in Microsoft Internet Explorer 5.01 through 7 allows remote attackers to execute arbitrary code via unspecified vectors involving memory corruption from an unhandled error.

ということで、IEすべてにリモートコード実行の脆弱性があり

http://www.microsoft.com/technet/security/bulletin/ms07-057.mspx

がFIXだそうです。

普通にWindowsUpdateを動かしていれば今日中にはアップデートされると思います。

JSPWiki?

JSPWikiの脆弱性がCVEに書いてあったので見てみました。

JSPWiki: http://jspwiki.org/

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

Cross-site scripting (XSS) vulnerability in
JSPWiki 2.5.139-beta allows remote attackers to inject
arbitrary web script or HTML via the redirect parameter
to wiki-3/Login.jsp and unspecified other components.

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

Multiple cross-site scripting (XSS) vulnerabilities
in JSPWiki 2.4.103 and 2.5.139-beta allow remote
attackers to inject arbitrary web script or HTML
via the (1) group and (2) members parameters in
(a) NewGroup.jsp; the (3) edittime parameter in
(b) Edit.jsp; the (4) edittime, (5) author, and
(6) link parameters in (c) Comment.jsp; the (7)
loginname, (8) wikiname, (9) fullname, and (10)
email parameters in (d) UserPreferences.jsp and
(e) Login.jsp; the (11) r1 and (12) r2 parameters
in (f) Diff.jsp; and the (13) changenote parameter
in (g) PageInfo.jsp.

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

JSPWiki 2.4.103 and 2.5.139-beta allows remote
attackers to obtain sensitive information (full path)
via an invalid integer in the version parameter
to the default URI under attach/Main/.

要約すると「クロスサイトスクリプティングをはじめセキュリティの事を全く考えずに作ってしまいました」という感じ(?)です。

安定版のソースをダウンロードして見てみました。JSPWikiとなっていたので、全部JSP?と思いましたが違いました。zipで６MBあるので結構な分量です。

[yohgaki@dev JSPWiki]$ find . -name “*.jsp” | wc -l
55
[yohgaki@dev JSPWiki]$ find . -name “*.java” | wc -l
430
[yohgaki@dev JSPWiki]$ find . -name “*.jar” | wc -l
29

インストールに必要な環境

* Java (1.4 for 2.2)
* To know what a WAR file is and how to use it.
* A Servlet 2.3 -compliant web server. JSPWiki of course runs on 2.4 -compliant servers, we just don’t require anything more than 2.3. Containers that are known to work include:
o Tomcat (4.0 and higher) works quite nicely. For best results, we recommend Tomcat 5.5.
o See below for more container-specific notes
* A server to run your Wiki on. It does not have to be a very big server: JSPWiki has been run on a 266 MHz Pentium II with 192 Mbytes of memory.
* Some patience (the setup is not as easy as I would like it to be)
* If you want to email things, you need JavaMail and the Java Activation Framework JARs. Email is needed for password recovery, or error logging (log4j) if you wish to configure it that way.

初めての脆弱性レポートなのか調べてみると

http://secunia.com/advisories/13285/

がありました。

Release Date: 2004-11-24
Last Update: 2005-02-21

3年前くらいによくありそうなQueryパラメータのクロスサイトスクリプティング脆弱性がレポートされています。どうしてこんな感じになってしまったのか時間がある時に調べたいです。

Webカメラの脆弱性

WebカメラのなどのデバイスはWebサーバ機能を持っています。脆弱性がありそうだな、と思っていましたが調べてみるとかなり危険な状態のようです。

* Cross-browser XSS phishing
* Replacing the legitimate video stream with our own
* Adding a Backdoor Root Account
* Stealing the ‘passwd’ File

最近のWebカメラはメモリも十分でプログラムも実行できるので普通のWebサーバとしても利用できるくらいになっています。ネットワークWebカメラの運用には注意が必要なようです。

Gmailに脆弱性

GnuCitizenとばしてますね。先日はPDFによるコード実行脆弱性を公開（ただし、詳細不明）していました。その前はQuickTimeでした。今度はGmailの脆弱性だそうです。

The technique used in this example is known as Cross-site request forgery, or simply put CSRF.

CSRF脆弱性だったそうです。リンク先のページではフィルタ設定を改竄するスクリーンショットが掲載されていました。

対策は簡単、予測不可能なリクエストIDを全てのデータ変更リクエストにつけるだけです。手っ取り早いのはセッションIDを流用する方法ですが、セッションID漏洩のリスクが増加するのであまりお勧めできません。次に簡単なのはセッション変数としてIDを保存する方法です。この方法を採用したのかな?POSTメソッドなので単純にセッションIDを利用したのかな?

追記：
中身は同じなのかも知れませんが、XSS(?)でも似たような攻撃ができたようです。

Google Vulnerability

ImageMagickに脆弱性

少し前にPythonの画像処理デフォルトモジュールの脆弱性について書きました。「普通はデフォルトのライブラリは使わずにImageMagickとかを使うよね」というツッコミが入っていたので、画像ライブラリは脆弱性が多いことも紹介していたのですが、そのImageMagickに脆弱性です。DoS, Off by One, Integer overflowです。

http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=596
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=595
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=594

影響する画像形式は一般的な画像形式でないので、あまり影響は大きくないのです。最近ImageMagickなどは脆弱性が多い、と書いていたので載せました。

AdobeはAdobe Readerのブラウザプラグインは止めるべき

AdobeはAdobe Readerのブラウザプラグインは止めるべきだと思います。PDFがブラウザから見れてもうれしい事は少なく、反対に迷惑な場合が多いです。Firefoxの人気拡張にPDF Downloadがある事からも私だけでなく、多くの方が迷惑だと思っていると考えられます。せめてプラグインのインストールはデフォルトでオプションにして、欲しい人だけインストールできるようにするべきです。

Adobe Readerですが、どうもPDFからシステム上のファイルを簡単に覗き見できる、ということらしいです。

[Full-disclosure] 0day: PDF pwns Windows

http://www.gnucitizen.org/blog/0day-pdf-pwns-windows

I am closing the season with the following HIGH Risk vulnerability:
Adobe Acrobat/Reader PDF documents can be used to compromise your
Windows box. Completely!!! Invisibly and unwillingly!!! All it takes
is to open a PDF document or stumble across a page which embeds one.

元ネタのGnuCitizenサイトにアクセスできないので具体的な攻撃方法は不明。

http://blog.ohgaki.net/index.php/yohgaki/2007/09/14/noscripta_rafia_a_s

に書いたようにNoScriptで全てのプラグインはデフォルトで実行しない設定にしている方が安全だと思います。

攻撃方法が詳細が分からないので、何とも言えませんが、Adobe ReaderからPDFを読み出してもファイルを読んで、外部に送れるような問題であれば防ぐのは難しいです。少なくともプラグインを禁止していれば「ページを見て攻撃される」リスクはかなり軽減すると思います。

追記
GNUCitizenにアクセスできたのでみてみると

My advise for you is not to open any PDF files (locally or remotely)

と、「ローカルでもリモートでも、PDFファイルは開くな」と記載されています。アタックベクタが不明なので、対処方法は安全性が保証できるPDF以外は開かないのが良いと思います。少なくとも、ブラウザプラグインでクリックしたら開いた、という状況は良くないと思います。

実は少し前に流行っていたPDFファイル付きスパムメールのPDFを自分で開いた事がないです。これにファイルを盗み見れる攻撃が仕込まれていたとすると脅威ですね。

PDFプラグインの実行はNoScriptでも制御できます。
詳しくは
http://blog.ohgaki.net/index.php/yohgaki/2007/09/14/noscripta_rafia_a_s

Pythonも同じか?!

PHPのモジュールには脆弱なコードが多かったが、PHPのモジュールに限らないはず、と言っていましたがまた別の例がありました。

Full-Disclosure（9/16）に投稿されたメッセージによると

The module imageop contains a lots of int overflow, which result in heap overflow, and maybe memory dump.
The files imageop.c and rbgimgmodule.c are examples.

という状態らしいです。モジュール（ライブラリ）は叩けば埃が沢山出てくると思います。

imageopのコードフラグメントを見ると整数オーバーフローに全く注意していないコードになっているのは明らかです。

「標準モジュールでimageopなんてモジュールだれも使ってないよ。ImageMagickなど使っている」と反論がありましたが

Maybe the real question is, if they don’t know how secure an int overflow in imageop module, maybe other modules are vulns too.

と、投稿者は書いています。確かにその通りだと思います。

で、ImageMagickですが今は以前に比べてあまり脆弱性が報告されなくなりましたが少し前まで脆弱性が山ほどレポートされていました。最近レポートされている脆弱性もあります。

http://osvdb.org/searchdb.php?action=search_title&vuln_title=ImageMagick&Search=Search
http://secunia.com/search/?search=ImageMagick

裏を返せば古いバージョンを使っていて脆弱なシステムも意外と多いかも?と思ってしまいます。これはPythonに限った事ではありません。

画像、映像、音声処理ライブラリは脆弱性の固まりだと思っていた方が良いです。

コマンドを呼び出していれば他の言語と同じ、速度や使うリソースの問題がありますが、Javaはこの点に関してかなり有利だと思います。

Second Lifeプロトコルハンドラのバグ

Second Lifeは使ったことが無いので知らなかったのですが、IEを拡張してsecondlife://プロトコルを追加しているのですね。このプロトコルハンドラが脆弱でユーザIDを盗める脆弱性があるそうです。

Second Life is configured to handle ’secondlife://’ protocol urls. Internet Explorer, and browsers based on Internet Explorer, copy all information from a src or href attribute to launch the SecondLife application. Using this, a malicious website can specify an iframe or anchor tag which redirects login through a server not under Linden Lab control.

現在のところ修正中らしいです。

You can remove the association for the secondlife:// protocol until we release a fixed client by deleting the registry entry.

Second Lifeを利用している方は上記に記載されているようにWindowsレジストリを削除した方が良いと思います。

NoScriptのIE版があればiframeも禁止できるのですけどね。

PHPにもプロトコルハンドラを簡単に追加できるのですが、ハンドラの開発者がセキュリティ対策を行っていないと穴だらけになってしまいます。IEの場合も事情は一緒なのかも知れません。

プロトコルハンドラを拡張しているアプリ（主にネットワークゲーム?）には注意が必要なのかも知れません。

Content-Access-Controlヘッダ

Flashも同じような事ができるので、JavaScript（XMLHttpRequest)でもできるようにしてしまおう、という規格…

This restriction on “read” access to web resources is very strict and generally appropriate. However, there are scenarios where an application would like to “read” data from another resource on the web without these restrictions and in these scenarios the browser’s default “security sandbox” has to be extended or eased.

つまり「Same Originポリシー」を緩くする規格です。

使い方は簡単

Content-Access-Control: allow <*.example.org> exclude <*.public.example.org>
Content-Access-Control: allow <webmaster.public.example.org>

Means that every subdomain of example.org can access the resource including webmaster.public.example.org, but with the exclusion of all other subdomains of public.example.org.

Content-Access-Control: allow <example.org> <*.example.org>

Means that example.org and all its subdomains can access the resource.

です。選択的にアクセス可能なドメインをContent-Access-Controlヘッダで処理できる、という訳です。

セキュリティ的には「Same Originポリシー」を緩くするのはリスクが高くなる事を意味します。Webセキュリティの根幹である「Same Originポリシー」はどちらにしてもブラウザとプラグイン任せなので、少し緩くしても同じ、という考えなのでしょう。

XMLHttpRequestのプロキシは必要なくなります。確かに作り易くはなりますが必要なのか考えさせられます。

NoScriptの使い方

Firefoxユーザなら必ずインストールして使用する事をお勧めするのがNoScript拡張です。

参考：新しい紹介文を書きました。

• 簡単にインターネットから内部ネットワークを守る方法

NoScriptはデフォルトでJavaScriptの実行を拒否します。これだけでもかなり安全にWebサイトを参照できるようになります。しかし、NoScriptはプラグインの実行も拒否できるようになっています。Java, Firefox, Silverlight,その他全ての拡張を選択して実行を拒否できます。残念ながらJava, Sliverlight以外はデフォルトで実行可能に設定されています。

もっと読む

一部(?)のSIPデバイスは危ない

VoIPはセキュリティ上の脅威としてトップレベルに位置する機能です。Zone-Hに書いてある内容が幅広いSIPデバイスに適用できるとするとかなりの脅威です。

The research that was published indicates that, for at least one vendor, it is possible to automatically call a SIP device from that vendor and have it silently accept the call, even if it is still on the hook – instantly turning it into a classic bugged phone. Whereas historic telephony bugs needed physical targeting of the line running to a property or place of business, the presence of VoIP in the equation allows bugging from anywhere in the world with equal ability. Now anyone can do from their armchair what only spies and law enforcement used to be able to do from inside the telephone switch / pit / distribution board, though it’s still illegal to do so.

少なくとも一つのベンダのSIPデバイスは話し中でも密かに着信し盗聴できた、としています。盗聴器が必要ないので気軽(!?)に盗聴できます。

どれくらいのデバイスに同様の問題があるか気になります。

参考：
SIP Phoneの検索結果
http://www.google.co.jp/search?q=SIP+Phone

生体認証システムの脆弱性

元々生体認証は再生攻撃に弱く、通信経路の安全性確保は必須であることは常識だと思うのですが…. 生体認証システムには設計が脆弱な物もあるようです…　どの製品と明記されていませんが、このホワイトペーパーに書いてある製品はダメ過ぎです。

Anti DNS Pinning/DNS Rebinding/DNS multi-pinning

備考：かなり古いブログですが公開し忘れしていた分です。

この話題はどちらかというとWebブラウザとプラグインの問題と言えるので書いていませんでした。Web開発者としては早く直してほしい問題ですがサーバのコードを書く側としては対策をできません。なぜかこの話題の日本語リソースがあまり無いようです。とりあえず私のブログにも書いておくことにします。

WebブラウザとプラグインはSame Originポリシーで守られています。基本的にはXMLHttpRequest、Javaアプレット、Flashはそのコードを送ったサーバにのみリクエストが送信できるようになっています。クッキーもコードを送ったサーバ（ドメイン）のクッキーにのみアクセスできるようになっています。

Same Originポリシーが無いと悪意があるサイトにアクセスするだけでいくらでもクッキーに保存されたセッションIDなどを盗めます。これを防ぐ為にブラウザはDNS Pinning(IPアドレスを固定するセキュリティ対策）と呼ばれる手法を利用しています。

DNS Pinningが無いとファイアーウォールで保護されている内部のコンピュータにアクセスしたり、IPアドレスベースでの認証の回避が可能になります。DNS Pinningが無い場合にどのように攻撃されるか簡単に解説します。

DNS Pinningの必要性

ブラウザがURLを解釈する際、ホスト名をIPアドレスに変換するためにDNSサーバに問い合わせを行います。サーバ名はDNSによって管理されサーバのIPアドレスは必要に応じて自由に変更できるようになっています。

攻撃者がドメインを管理して、悪意があるDNSサーバを運用している場合、ブラウザからの最初の問い合わせには実際に存在する攻撃用のページをホストしているサーバのIPアドレス（通常のグローバルIPアドレス）を返します。

仮に攻撃用のURLは次のURLだとします。
http://www.example.jp/attack.html

被害者がURLにアクセスさせる攻撃用attack.htmlのコンテンツにはXMLHttpRequestを利用してwww.example.jpサーバにリクエストを送信するJavaScriptを記述します。ページが記述してあるwww.example.comとXMLHttpRequestの送信先であるサーバ(www.example.com）は同じサーバであるのでブラウザはアクセスを許可します。

DNS Pinningが無い場合、ブラウザはサーバ名を解決するためにDNSで再度名前の解決を行います。攻撃者がホストしている悪意のあるDNSサーバはwww.example.comの名前解決リクエストがきた場合は内部のIPアドレス、例えば192.168.0.1、192.168.0.2、192.168.0.3等を返させます。この様なDNSサーバを用意することにより攻撃者は簡単に本来アクセスできてはならない内部ネットワークのコンピュータにアクセス可能になります。

例えば、IPアドレスが192.168.0.1のコンピュータはSOHOルータでCSRFに脆弱な場合、Firewallを無効にしたり、VoIP対応ルータの場合通話を盗聴されたりVoIPサービスを不正利用される可能性があります。さらなる攻撃を行うために内部ネットワーク構成のスキャン等を行う事も可能になります。

この様にDNSによって名前の解決を毎回行っていると内部ネットワークへの不正アクセスを許してしまいます。これを防ぐためにブラウザやブラウザの拡張はDNS Pinning(DNSリクエストのキャッシング)を行います。同じサーバ名にリクエストを送信する場合、DNSによって名前の解決を行わず既に解決済みの結果を利用します。

このように解説すると、悪意のあるDNSサーバを用いた攻撃は明白で全ての実装が最初からこのような攻撃を考慮していたはず、と思われる方もいるかも知れません。しかし、実際にJava AppletがDNS Pinningを実装していなかったり、XMLHttpRequestオブジェクトがDNS Pinningを実装していかったりしたケースがありました。

攻撃例としてFirewall設定の変更やVoIPの不正利用を取り上げていますが、実際にAnti DNS Pinning/DNS Rebidingを利用したFirewall設定の改竄やVoIPの不正利用などの攻撃は行われています。

Anti DNS Pinning/DNS Rebinding

Anti DNS Pinningは名前が示すとおりDNS Pinningを回避する手法の名前です。Stanford大学の論文でより直感的に分かりやすい名前としてDNS Rebindingが利用されています。DNS RebidingはAnti DNS Pinningの別名と考えても差し支えありません。

書きかけです。近日中に再編集します。