Selfkleptomaniac

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

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

Popularity: 2% [?]

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

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

続く、かも。

Popularity: 3% [?]

ぜんぜん更新されないhp miniのLinuxディストリビューション「MIE」に不安を覚えたのと、ネットブック風デスクトップやharbour-launcherが気に入らなかったので、Fedoraに戻ることにした。

インストールはいたって簡単で、liveusb-creatorを利用してUSBメモリにイメージを作成して、USBスロットに挿してからf9キーを押しながら起動、デスクトップに表示されるインストーラのアイコンから普通にインストール作業を進める。

ここまではいいのだが、それですべてというわけにはいかない。一番困ったのが、デフォルト状態では無線LANがうんともすんともいわないこと。

# lspci -v|grep Network
01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 0

Broadcom社のBCM4312という製品を動作させる必要があるようだ。RPM Fusionにこれに対応したドライバがあるので以下の要領でyumで追加できるようにした。

# su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \

http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

# yum install broadcom-wl

ところが、インストール時のカーネル2.6.29だと問題なく動作するのに、yum updateでカーネルを更新してしまうと動作しなかった。いろいろ調べてみたが、結局ここで見つけた手順に従い/etc/modprobe.d以下の適当なところで

# yum install wl-kmod
# echo "install ssb /sbin/modprobe wl;/sbin/modprobe --ignore-install ssb" >> /etc/modprobe.d/dist-oss.conf

として再起動したところ、無事に動作した。

それから、外出先でWillcomのUSBモデムNS001U(netIndex)を使いたかったのでこちらも設定したが、特に難しいこともなく、普通に「システム」→「管理」→「ネットワーク」から新しいハードウェアとして一般的なモデムを選択し、USBモデムが/dev/ttyACM0として認識されていたのでモデムデバイスとして指定、それからデバイスとしてプロバイダ情報にあれこれ書き込み、「Willcom」として保存すると、/etc/sysconfig/network-scripts以下にifcfg-willcomというファイルが出来上がっていて、/etc/ppp/peers/willcomもさっくり用意されるので、あとは

# ifup willcom

で接続できた。めでたしめでたし。

Popularity: 4% [?]

仕事でいわゆるデコメール、アレンジメール、ようするに携帯向けHTMLメールを送信するプログラムを作成することになり、いろいろ悩んだので同じことになる人がいないようにメモしておく。

docomoには仕様書があるが他のキャリアにはなかったので、ほとんど勘で作業することになった。困ったポイントは（１）auのcidは@の数と書式に制限がある（２）SoftBankはboundary文字列の長さに変な制限があること。

HTMLメールに関しては、各キャリアともガラパゴスといわれるのも仕方がない仕様だと思う。外部の画像ファイルの読み込みを制限する必要があるのは理解できるが、それでもマルチパートのメールとしての書式くらいは守ってほしいものだ。

とりあえずいくつかの端末で動作したので公開しておく。今後不具合が見つかった場合に改修するかもしれない。

改行は全てCRLFとする。 【】内はフォーマットではなく　フォーマットの詳細。

docomo

MIME-Version: 1.0
FROM: me@example.com
Subject: 【mime encodeしたJIS文字列】
TO: you@example.com
Content-Type: multipart/related; boundary="------------boundary1"
Content-Transfer-Encoding: 7bit

--------------boundary1
Content-Type: multipart/alternative; boundary="------------boundary2"
Content-Transfer-Encoding: 7bit

--------------boundary2
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

【mime encodeしたJIS文字列】

--------------boundary2
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable

【quoted printableにエンコードしたJISのHTML】
(画像は<IMG src="cid:0@0">のような書式になる）

--------------boundary2--

--------------boundary1　←複数の画像がある場合はここから画像データまでを繰り返す
Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif"
Content-Transfer-Encoding: base64
Content-ID: <0@0>

【base64_encodeしてchunk_splitした画像データ】

--------------boundary1--

au

MIME-Version: 1.0
FROM: me@example.com
Subject: 【mime encodeしたJIS文字列】
TO: you@example.com
Content-Type: multipart/mixed; boundary="------------boundary1" 

--------------15b49b545
Content-Type: multipart/alternative; boundary="------------boundary2" 

--------------boundary2
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

【mime encodeしたJIS文字列】

--------------boundary2
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable

【quoted printableにエンコードしたJISのHTML】
(画像は<IMG src="cid:0@0">のような書式になる）

--------------boundary2--

--------------boundary1　←複数の画像がある場合はここから画像データまでを繰り返す
Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif"
Content-Disposition: attachment; filename="【mime encodeしたJIS文字列】.gif"
Content-Transfer-Encoding: base64
Content-ID: <0@0>　←必ず「数字@数字」とする

【base64_encodeしてchunk_splitした画像データ】

--------------boundary1--

SoftBank

MIME-Version: 1.0
FROM: me@example.com
Subject: 【mime encodeしたJIS文字列】
TO: you@example.com
Content-Type: multipart/related;
        boundary="------------boundary1"　←21文字にする必要がある
--------------boundary1
Content-Type: multipart/alternative;
        boundary="------------boundary2"　←21文字にする必要がある

--------------boundary2
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

【mime encodeしたJIS文字列】

--------------boundary2
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable

【quoted printableにエンコードしたJISのHTML】
(画像は<IMG src="cid:0@0">のような書式になる）

--------------boundary2--

--------------boundary1　←複数の画像がある場合はここから画像データまでを繰り返す
Content-Type: image/gif; name="【mime encodeしたJIS文字列】.gif"
Content-Disposition: inline;filename="【mime encodeしたJIS文字列】.gif"
Content-Transfer-Encoding: base64
Content-ID: <0@0>

【base64_encodeしてchunk_splitした画像データ】

--------------boundary1--

途中PHPの関数名が出てきているが、気にしない。あと、PHPでquoted printableにするのにはimap_8bit関数を使った。

Popularity: 4% [?]

WillcomのUSBモデムNS001U(netIndex)がhp mini用UbuntuであるMIEで使えた。

本体にNS001Uを差し込んでdmesgを開くと、期待したようにttyUSB0ではなくttyACM0として認識されていた。

# dmesg | grep tty
.....
[   84.975909] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
....

そこで、ダイアルアップ接続用の設定ファイルを作成する。

# cp -a /etc/ppp/peers/provider /etc/ppp/peers/willcom

で、このファイルの中身を下のように変更する。

 # vi /etc/ppp/peers/willcom
....
#connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T ********"
connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T 0000000000##64"

# Serial device to which the modem is connected.
#/dev/modem
/dev/ttyACM0

# Speed of the serial line.
#115200
460800

user "your-willcom-user-name"
....

スピードの設定は何が最適なのかよくわからないので適当。「connect」はWillcomを利用するときの電話番号、「user」はユーザ名となる。そしたら

$ sudo pon willcom

これで接続に成功した。

Popularity: 21% [?]

WILLCOMがスーパーボーナス一括払いみたいなことを始めている。2年間の月額料金が980円とのことだが、機種代金を一括で支払ってしまったら月額料金はもっと下がってしまう。

Popularity: 4% [?]

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

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

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

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

Popularity: 3% [?]

暴論ではあるが、実際にそういう事例を見てきたので、ちょっと書きとめておく。

PC向けサイトは、あらゆる攻撃にさらされている。攻撃用スクリプトの実行も非常に簡単で、HTMLのソースには誰でもアクセスできる。URLバーもあって、GETの値を書き換えてみるくらいのことは当たり前に出来る。しかし、携帯サイトでは、以下のような事情もあり、それほどセキュリティについては真剣に対応しなくてもなんとかなってしまう現状がある。

■攻撃者を選ぶサービスである

携帯向けサービスの場合、サイトへのアクセス経路が必ずキャリアのゲートウェイになるので、意図しないアクセスを全てブロックするのは簡単だ。だから、攻撃者はどこかの踏み台サーバからの匿名的なアクセスではなく、何らかの契約情報にひもづけられたアクセスであることを余儀なくされる（パケットの改ざんレベルはここでは問わない）。公式サイトであれば、端末固有のIDが送信されてしまうので、なおさら匿名性は低い。

もちろん、世の中にはありとあらゆる手段で自分の持ち物以外の携帯を手にしている人もいるだろうし、嘘の情報で契約されたものもあるだろう。だが、そんなものを手にしている人たちが、せこせこと月額315円の携帯サイトを攻撃することなどあまり考えられない。普通は、もっと重大な悪事に使うだろう。

したがって、たいていのユーザが容易に自分の身元が割れそうな状態でサイトにアクセスしていることになるので、それほどひどい悪事が行われる可能性はPCと比較するとかなり少ない。

■攻撃が難しいデバイス

どこかで拾った携帯、あるいはとなりの人のをちょっと失敬した端末で攻撃を企てる人がいるとしよう。DoCoMoの携帯だから現在アクセスしているURLを表示できる！喜び勇んで眺めてみると、そこにはどうやら個人情報にひもづくらしいキーと値がセットされている。では、ここを改ざんして他人に成り済ましてみよう！

ところが、PCサイトであればブルートフォース攻撃などちょっとしたスクリプトで簡単にできるのに、アクセス制限のかかった携帯サイトが相手の場合、あの世界的に有名な打ちにくいボタンでせこせこ入力する以外には、ほとんど手段がない。よって、微笑ましいほどの数のパターンしか試すことができないのだ。なんとか工夫したところで、やっぱりたかが知れている。大人数でやればいいのかもしれないが、人を集めるコストと、人数が増えることによる秘密の漏えいリスクを考えると、やっぱり割が合わない。

■Javascriptが使えない

もちろん一部の端末では使えるのだが、基本的にフルブラウザ（TM)でない限りは携帯サイトではJavascriptは利用されない。したがって、Javascriptを起点としたXSSなどの攻撃が意味をなさない。もちろん、サービスの管理画面などPC側の画面では問題になるだろうが、逆にいえばここだけ抑えればなんとかなってしまう。

もちろん、以上の理由から携帯サイトのセキュリティなど無意味だ、というのは間違った考え方ではある。それに、実際には携帯独自のセキュリティホールだって（NDAの壁があって世の中には出回っていないが）当然存在しているので、セキュアなサービスを作るのが一概にPCより楽だというつもりはまったくない。だが、PCの世界では当たり前のように対策していたことが、携帯サイトばかり作っているとついついおろそかになってしまう傾向は絶対にあると思う。

最近、作成中のサービスで某ベンダのセキュリティ診断を受けたのだが、事前対策中に上のようなことを強く思わせる問題がいくつもあった。昔はこんなんじゃなかったのになあ、というのが開発者たちの感想だった。そう、昔はこんなんじゃなかったのだ。HTMLのソースも見られない環境に慣れてしまうと、単純な攻撃に対する意識はどんどん薄れていってしまうのだ。気をつけよう。

Popularity: 5% [?]

PHPでLocationヘッダを出力してリダイレクト処理をするとき、

<?php

header("Location: http://www.example.com/");
exit;

?>

こんな感じでリクエストを普通にリダイレクトで飛ばすのが大半なわけだが、このリクエストがHEADで来た場合、リダイレクト先へのリクエストも当然ながらHEADになってしまう。

携帯サイトでOBJECTタグを使った場合、auなどはダウンロードページのOBJECTタグのURLに記述された先へHEADリクエストが飛ばされる（ことがある）。そこでOKが返らないとちゃんと動作しない。いつも飛ぶわけではなさそうなので、キャッシュの問題もあるのかもしれないが再現性があんまりなくて深追いしていない。

で、たとえばセッションで認証していたりする場合、$_SERVERのREQUEST_METHODを参照してHEADリクエストの場合は別処理にしてやるなどしないと、OBJECTタグでアクセスする先のファイルで認証エラーが発生したらログインページにリダイレクトで飛ばそうなんて処理を入れたら、HEADリクエストのままリダイレクトされてしまうので正常に動作しない。

しかし、それはそれでHEADリクエストを使って認証をかいくぐる方法なんかが考案されたらまずい。とはいえ、

$_SERVER['REQUEST_METHOD'] = 'GET';

とかやってももちろんLocationヘッダでリダイレクトしたらHEADリクエストのまま飛んでいってしまう。

というわけで、OBJECTタグでアクセスする先のファイルで認証を入れたい場合は、失敗したらいっそ404を返してファイルが存在しない、とかしてやった方がいい。少なくともHEADリクエストのままどこかに飛んでいってページが正常に表示されなくなるよりはまし。

Popularity: 4% [?]

SoftBankのサポートページのPDFファイルにはこんな記述がある。

・専用USIMカードはSoftBank3Gに挿しても使用することはできません。
・SoftBank３Gへ戻す場合には、USIMカード交換（有償）が必要となります。

確かに実機で検証するとこんなエラー画面になる。

ここまではSoftBankの説明どおりである。

実にけしからん。iPhoneなんかやめた、と思い切って他の端末を友達から安く買ったという人はいったいどうすればいいのか。消費者の見地からこれは実に見過ごせない由々しき問題である。

ところで、SoftBankといえばその前身はVodafoneである。

SoftBank3Gではだめだというなら、ではVodafoneならどうなのだろう。誰もがそんなことを思うことには疑いの余地はない。

というわけでさっそく実験。iPhone 3GのUSIMカードを取り出して適当なVodafone 3Gの端末に入れて起動してみる。

起動した。となりの黒い箱は犠牲となったiPhone。

起動しただけかもしれないのでさっそく電話する。

通話できた。

ちなみにSIMロックが解除されたヤクザな携帯端末もちゃんと起動する。

もちろん、iPhone 3GのSIMロックを解除したわけではないので、念のため。第一、iPhone 3G専用をうたっているあのSIMカードは、そもそもiPhone 3Gを買った人じゃないと手に入らないので、何かの犯罪を教唆しているわけでもない。

あ、パケット通信はできないよ。

あと、番外編としての豆知識。

１　iPhone3Gは電源が入ったままSIMカードを抜いても大丈夫だった。
２　SIMカードをドックの口に挿す人間は必ずいる。
３　iPhone 3GとかSIMロック解除とかいうキーワードはすさまじくSEO効果が高い。

何かを勘違いしてアクセスしてきた人たちにはサービス画像。

Imaginary iPhone

iPhone実機が買えなかったので想像して描いたiPhone。

Popularity: 74% [?]