T

register_globals?そんなのデフォルトでオフですよ

Ruby on Railsのmass assignment絡みの脆弱性について、すごくよくまとまった記事。Railsで開発している人は必見ですね。

かつてPHPにはregister_globalsというこれと似た機能があり、現在はデフォルトでオフかつ5.4以降は廃止されたのですが、それまでは散々恐ろしい問題を引き起こしていました。PHPのウェブアプリケーションにセキュリティ問題が多いという評判が定着してしまったのは、これが主な原因といっても過言ではありません。PHPは何年もかけてようやく負の遺産を返済することができたのですが、Railsにはこのregister_globals相当の機能があり、今回見つかった脆弱性はかつてPHPが経験したことをそのままなぞっているようで興味深いところです。

ちなみに、Railsの本と名乗っていながら冒頭からRubyのオブジェクトの仕組みからメタプログラミングについて詳細に解説しまくる名著『実践Rails』では(初版なら)142ページ目にこの問題についての解説があります(Safari Onlineはこちら)。さすがです。

というわけで、何年も前に指摘されていた脆弱性に今頃慌てふためいている愚かでコンピュータサイエンスを学ぶには無能すぎてRailsくらいしか使えないくせにPHPerだなんだと他人の尻馬に乗って調子こいてたボケナス共は、土下座してmodelの修正に取りかかるがよい。わっはっは。

Twitterのフィッシング詐欺みーつけた

TwitterのDMを利用したフィッシングサイトがうちにも届いたので晒しておきます。ドメインは「http://twittelr.com/」というなかなかうまい偽物で、短縮URLだと「http://t.co/IzH3H7F」です。

「OMG this too funny of a blog about you, worth shaing with everyone lol http://t.co/IzH3H7F 」

こんなDMが来たらTwitterにそっくりな画面のサイトに飛びますが、ログアウト状態でセッションが切れたみたいなページが出るので、ログインしようとしたら多分パスワードを盗まれます。「’; DELETE FROM users;–」みたいなパスワードの人がいたら面白いなあ、と思ったんですが試してみたけどダメでした。

そっくり、というかまんまですね

クリックするとバレちゃいます。

猫じゃない!

いちおうwhoisしておいたんですが、まあどうせ連絡先は偽物でしょうね。

Domain name: twittelr.com

Registrant Contact:
   zhang yu
   yu zhang sdfgsdfghf@msn.com
   0463965823 fax: 0463965823
   changhailu12hao
   nanning guangxi 230254
   cn

Administrative Contact:
   yu zhang sdfgsdfghf@msn.com
   0463965823 fax: 0463965823
   changhailu12hao
   nanning guangxi 230254
   cn

Technical Contact:
   yu zhang sdfgsdfghf@msn.com
   0463965823 fax: 0463965823
   changhailu12hao
   nanning guangxi 230254
   cn

Billing Contact:
   yu zhang sdfgsdfghf@msn.com
   0463965823 fax: 0463965823
   changhailu12hao
   nanning guangxi 230254
   cn

DNS:
ns7.cnmsn.net
ns8.cnmsn.net

Created: 2011-09-23
Expires: 2012-09-23

SoftBankはちょっと怖い

SoftBankのユーザ向けサービス「My SoftBank」に、ちょっと奇妙な機能がある。PC版のサービスで、ワンタイムパスワードを発行して所定のフォームからログインすると、端末からアクセスしたURLの履歴を期間指定して一覧できる。

ところで、SoftBankといえばドメイン名がないなど独自の書式のURLを特に自社サービスや課金まわりで多用することで知られている。例えばYahoo!ケータイのトップ画面はhttp://ptl/menu/だ。他にも、デジタルコンテンツのダウンロードに固有なURLなどがあるわけだが、その手のものもいろいろと見えてしまう。また、GPSの送信履歴からいろいろと面白い行動履歴を追うこともできる。

変なCSRF対策

au端末のみアクセス可能なサイトでクロスサイトリクエストフォージェリー対策が必要になったのだが、ワンタイムトークンとかのよくある手段だとおもしろくないので、何かないかと考えてみた。

auの端末からのリクエストには、端末の契約情報に紐づいた一意のID(サブスクライバID)がリクエストヘッダとして送信される。そこで、こんなのを作ってみた。

(1)リモートアドレスでauのデートウェイからのリクエスト以外は弾く
(2)POSTリクエストを受け付けるURIはサブスクライバIDで異なる

まあ(1)はよくあることなのでいいとして、(2)はこんな感じになっている。公開するURLは「http://example.com/form」とかいう形式になっている。au端末からそのURLへのリクエストがあると、サーバ側で「https://example.com/xxxxxxxxxx/」にリダイレクトする。この「xxxxxxxxxx」はサブスクライバIDとサーバ側に保持している特定のsaltとなる文字列(例えば創世記の全文)から生成されたハッシュ値になっている。リクエストしてきた端末のサブスクライバIDから生成したハッシュ値とURIのハッシュ値が一致すればリクエストを通して、そうでなければ弾く。リダイレクト処理が入るので「http://example.com/form」へのPOSTリクエストはリクエストボディーの内容が消えたGETのリクエストになってしまうから、もし第三者がこのURLに対してCSRFを仕掛けてきても無効化される。ハッシュ値付きの正しいURLにPOSTリクエストを投げるようにしたくても、端末が送信するサブスクライバIDとsalt値とハッシュ値の生成ルールが分からなければ犠牲者の端末専用のURLが推測できないため攻撃用のフォームを作ることができない。

あとは.htaccessなどで存在しないディレクトリへのアクセスをリライトしてしまえばおしまい。

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

とかいう感じ。いやっほう。

あんまり見たことないやり方なので破り方があるかどうかちゃんと検証できてない気がするけど、思いつかないので実戦投入した。

携帯サイトのセキュリティ対策(ざっくり)

携帯サイト構築で忘れがちなセキュリティ対策を記録しておく。もちろん、外部に公開されているサーバで余計なポートが開放されていたり要らないサービスが起動していたりするのは論外。

SSL

SSLを利用している場合、基本的にSSLv3とTLS1以外を利用することはないので切っておく。特にNull暗号をオフにしておく必要がある。

Apacheだとこんな感じ。

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL

Poundだとこんな感じ。

ListenHTTPS
  Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!eNULL:!aNULL"

Apache

リクエストヘッダのHost部分を書き換えられることを前提とした設定をしていないケースが多いと思われる。VirtualHostの先頭にデフォルトの設定を入れて対応する。mod_rewriteは入っているものとみなす。

Apacheのバージョンが低い場合のTRACEメソッドの禁止も追加。


  DocumentRoot /var/www/html
  ServerName default.host.name
  RewriteEngine on
  RewriteCond %{REQUEST_URI} !^/server-status
  RewriteRule .* - [F]
  #TRACEメソッドの禁止
  RewriteCond %{REQUEST_METHOD} ^TRACE
  RewriteRule .* - [F]

Aliasで指定されたiconsやmanualは不要なので削除。

#Alias /icons/ "/var/www/icons/"
#   
#
以下このディレクティブの最後まで。

PHP

基本的な設定はされているものとして、忘れがちなのをいくつか。php.iniの場合は

バージョン情報を晒さない。

expose_php = Off

リモートファイルをスクリプトとして読み込ませない。

allow_url_fopen = Off

リモートファイルをスクリプトとして読み込ませない。

display_errors = Off

続く、かも。

iPhoneのカメラでプライバシー情報ダダ漏れだった

iPhoneで撮影した画像(おもに赤ん坊)をここにたくさん掲載していたが、同僚がExif ViewerというFirefoxのプラグインを見つけて画像情報を見たら、撮影場所の位置情報が見れたというので驚いた。スクリーンショットを保存したつもりができていなかったようで見せられないが、GoogleMapにリンクまで作成してくれるので見事に自宅の場所までわかる。

iPhoneの仕様ではメールでの送信などではGPS情報を削除しているようだが、iPhotoで同期した画像からは消えないので、そのままブログに掲載すると予期していない情報を公開してしまう可能性がある。

というわけで、jheadを使ってデータを修正した。

#!/bin/sh
FIND=/usr/bin/find
EXIFTOOL=/usr/bin/exiftool
JHEAD=/usr/bin/jhead
PATH=$1

$FIND $PATH -type f  | while read FILE
do 
        RESULT=`$EXIFTOOL -gps:GPSLatitude $FILE`
        if test -n "$RESULT"
        then
                $JHEAD -purejpg $FILE
                echo $FILE
        fi
done

WordPressのアップロード用ディレクトリにある画像ファイルに一括でjhead -purejpg path/to/file.jpgを実行してExifデータを削除しておけば間違いはない。元の画像は別にあるので問題ないだろう。今後もアップロードしてしまうことがあるだろうから、とりあえずcronでチェックすることにする。

TRACEなどのリクエストメソッドの禁止

ほぼ同じ内容のエントリを見つけたけど、よく忘れるのでここにメモしておく。

最近の傾向として、ウェブアプリケーションの導入前にセキュリティ審査が入ることが多くなったのだが、その際にApacheのバージョンが2.0.55より前の場合は

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
    RewriteRule .* - [F]
</IfModule>

こんな感じでmod_rewriteを使ってTRACE(とかTRACKとかOPTIONS)メソッドを蹴るようにしないといけない。まあ、TRACKはIISでサポートされているけどApacheにはない(RFC2616のHTTP1.1の仕様にもない)のでいいんだけれども。

Apacheが2.0.55以降だと

TraceEnable Off

で済んでしまう。

ソーシャルネットワークのなりすましテクニック

ブルース・シュナイアーの最近のエッセイに、ソーシャルネットワークのなり済ましテクニックが紹介されていた。

ソーシャルネットワークを使って成りすましをやってのける方法という記事があるらしく、シュナイアーのエッセイはその紹介なのだが、手口は次の通り(元記事ではMySpaceとFacebookだけど日本なのでmixiとgreeにしよう):

・適当な人にmixiでフレンドリクエストを送る
・フレンド登録してくれる人がいたらgreeでその人たちを探す
・greeでも見つかった人がいたら、そこでもフレンドリクエストを送る

これで準備完了。フレンドリクエストを送った相手が犠牲者になる。

・犠牲者のmixiとgreeの友達リストを見比べて片方にしか登録していない人を探す
・見つかったら、その人の写真とプロフィールをコピーして新規にアカウントを作る
・作ったアカウントから犠牲者にフレンドリクエストを送る

これで、かなり信憑性のある偽アカウントが出来上がる。あとは詐欺師のアイデア次第。

「今度飲みに行こうよ!18日に新宿とかどう?」で、やって来たところをボコボコにして金品を奪うとか。

確かに、複数のソーシャルネットワークを使っているとこれは引っかかりそうだ。気をつけないとなあ。

ステルス・サーチエンジン

何をしているのかはわからないけど、ステルス検索というサービスをやっているらしいBlekkoという会社があるようだ。

dmesgに怪しげなログが残っていた。普通、DoS攻撃とかで残るようなログなので、それにしてはヌルい回数だからおかしいなとIPアドレスを調べてみたら、Blekkoという組織からのアクセスだった。

TCP: Treason uncloaked! Peer 38.108.180.137:31690/80 shrinks window 数字:ずらずら. Repaired.

Blekkoとは:

$ whois 38.108.180.133
[Querying whois.arin.net]
[Redirected to rwhois.cogentco.com:4321]
[Querying rwhois.cogentco.com]
[rwhois.cogentco.com]
%rwhois V-1.5:0010b0:00 rwhois.cogentco.com
38.108.180.133
network:ID:NET-266CB40018
network:Network-Name:NET-266CB40018
network:IP-Network:38.108.180.0/24
network:Postal-Code:94065
network:State:CA
network:City:Redwood City
network:Street-Address:100 Marine Parkway
network:Org-Name:Blekko
network:Tech-Contact:ZC108-ARIN
network:Updated:2008-09-17 10:42:07
network:Updated-by:John Knowles

%ok

ステルス・サーチというくらいだから、なるほどackを返さないとかやってるみたいだ。とりあえず実害はないので気にするのはやめる。

携帯電話向けサイトのセキュリティ

以前、こんなことを書いたわけだが、最近ちょっと毛色の違う携帯サイトへの攻撃が増えているのでメモ。

携帯電話の強みとして、マイクロペイメントの仕組みが充実しているという点がある。ようするに、従量課金で100円のコンテンツを売る場合、PC向けサイトだとクレジット決済で手数料がコンテンツの価格の半分近くになったりしてなんとも不合理だが、携帯電話の料金として徴収してしまうシステムだと100円のものは(ほぼ)100円で買えるわけで、その点で携帯電話は非常に強力なプラットフォームだ。しかも、契約情報と関連した端末固有のIDがサーバに送信され蓄積されるシステムのため、それが犯罪に対して一定の抑止力となっている。

それをふまえて、先のエントリではたかだか月額315円のサイトをだまくらかしても得られる利益はたかが知れているというようなことを書いていた。しかし、昨今では例えばアフィリエイトと組み合わせて、大量の契約済端末で月額課金サービルスに登録してアフィリエイトサイトから大量の見返りを得ておいて、支払い前に振り込め詐欺用の使い捨て電話として端末を売却し、アフィリエイトの見返りのみを手にしてドロンというケースが相当な件数で発生しているようだ。アフィリエイト会社に成果発生して料金を支払うコンテンツ提供会社は、キャリアからの支払い情報に大量の「支払い不能」契約を発見するが、支払い情報を手にすることができるのがそもそも何ヶ月か後だったりするので、成果発生して得られるはずの料金を手にすることが出来ず、かといってアフィリエイト会社にその分を請求することもままならない状況に陥ってしまう。

確かにこの不景気で支払い不能による料金未回収が増えたとはいえ、上のようなパターンの詐欺も見過ごせない程度の規模になりつつあるようだ。