<前の日記(2011年06月26日) 次の日記(2011年07月07日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1461   昨日: 2967

2011年06月30日

SoftBankガラケーの致命的な脆弱性がようやく解消

ソフトバンクモバイルのガラケーWebブラウザで、https:接続する際の仕様に変更があった。昨年10月に予告が発表され、元々は2月に実施される予定だったのが、6月30日に延期されていたもの。これまで、https:サイトへのリンクのすべてが https://secure.softbank.ne.jp/ 経由に書き換えられる仕様だったが、この機能が廃止された。

これは、昨年6月に、ソフトバンクモバイル宮川CTOにTwitterで約束を取り付けていた*1もので、このとき一般には、SSL使用時におけるcookieの非標準的な挙動を排するためのものと受け止められたかもしれないが、じつはそういう趣旨のものではなく、致命的なセキュリティ上の欠陥を排除するための措置である。

経緯

ソフトバンクモバイルのガラケーWebでは、かなり古くから(JPhoneだったころから)、https:サイトへの接続方法が、他キャリアとは異なるものになっていた。他キャリアでは、インターネットにおけるごく普通のSSL接続と同様、ブラウザからWebサーバまでを直接SSLで接続するもの(end-to-endのSSL)であったのに対し、ソフトバンクモバイルでは、HTML中のリンクのURLを書き換えて、例えば、https://example.com/index.html へのリンクをすべて、https://secure.softbank.ne.jp/example.com/index.html へと強制的に変更して、secure.softbank.ne.jp のゲートウェイ上で通信内容の書き換えを行うようになっていた。通信内容書き換えの目的は、ケータイID(X-JPhone-UID)の付与などであろう。

ガラケーが昔ながらのガラケーであった数年前までは、この仕様も、「まあ許されないとまでは言えないもの」と思っていた*2。なぜなら、ガラケーにはJavaScript機能がない。アドレスバーもないので、アドレスバーによる本物サイト確認は元々できない。*3*4

ところが、昨年の4月、これがまずいことになっていることに気づいた。

事の始まりは、一昨年、NTTドコモが「docomo 2.0」としてJavaScript導入に踏み切った際、徳丸浩氏が「iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性」を指摘したことに遡る。その後、徳丸氏から、じつはソフトバンクモバイルでも端末の一部で同様の問題がある(のだが、回避策がないので公表ができない)という話を打ち明けられた*5。その時点まで、ソフトバンクモバイルの端末にJavaScript機能はないと思っていたのだが、いつの間にか、仕様にないのに一部の端末でJavaScript機能が搭載されているという話だった。自分がテスト用に持っていた端末816SHで確かめてみると、たしかにJavaScriptが動いた。

実証実験

これはまずいかもわからんね、ということで、具体的な危険を確認するため、Gmailを対象にして実験を行った。以下はそのときの記録である。

携帯電話器の写真
図2: 実証実験の様子(テスト用画面)

この画面は、私の管理するWebサーバ(攻撃者のサイトと想定)にhttps:のページを作り、以下のHTMLを記述して、IFRAMEとしてGmailサイトを埋め込んだ様子である。画面の上半分がIFRAME部分であり、Gmailにログインした後の状態で試したため、IFRAME中に私のGmailの受信トレイが表示されている。画面の下半分はテスト用のHTML(攻撃側の想定)である。

<iframe src="/mail.google.com/" id="foo"></iframe>
<script>
  function d() {
    return document.getElementById("foo").contentDocument;
  }
</script>
<a href="javascript:alert(d().body.innerText)">Get text</a><br>
<a href="javascript:alert(d().body.innerHTML)">Get html</a><br>
<a href="javascript:alert(d().cookie)">Get cookie</a>

IFRAMEタグでは、SRC属性に「/mail.google.com/」と指定しているが、このページ(https://takagi-hiromisu.jp/test.html)をソフトバンクモバイルの端末で訪れると、表示されるページのURLは、https://secure.softbank.ne.jp/takagi-hiromitsu.jp/test.html(※1)となり、IFRAMEの部分のURLは、https://secure.softbank.ne.jp/mail.gmail.com/(※2)となる。

これは、Webセキュリティの基本*6である same origin policy(同一生成元ポリシー)でいうところの「生成元」が、私の攻撃テスト用ページとGmailページとで同一(https://secure.softbank.ne.jp)になっている。

ということは、私の管理下にある※1のJavaScriptから、※2のコンテンツにDOM経由でアクセスできるということになるはずである。

以下の図3は、上の図2の「Get text」「Get html」「Get cookie」のリンクを踏んだときの様子である。

携帯電話器の写真 携帯電話器の写真 携帯電話器の写真
図3: 実証実験の様子(テスト用リンクを踏んだとき)

このように、Gmailの内容やcookieの内容を攻撃者側から取得できてしまっていることがわかる。同様にして、Gmail側を操作することもできるだろう。

つまり、ログイン中のサイトの情報を盗み出されたり、勝手に操作されてしまう被害(セッションハイジャックされたときと同等の被害)が出る危険があるということである。(Gmailに限らず。)

どう対処したか

これを脆弱性届出窓口に届けるべきか迷った。届けてしまうと、発見者には、取り扱いが終了するまで公開しないよう「お願い」されることになる。しかし、おそらくこの件は長期間直されないまま結果が出ないと予想され、その間何も言えなくなることの方が問題だと考えた。

この問題は、製品の脆弱性ではないし、Webサイトの脆弱性でもない。ソフトバンクモバイル向けにガラケーサイトを提供しているすべてのサイト運営者にも関わることであり、言わば「プロトコルの脆弱性」に類するものと考えた。脆弱性届出のガイドラインでは、次のように書かれている。

III.本ガイドラインの適用の範囲

・国内で利用されているソフトウエア製品
国内で、多くの人々に利用されている等のソフトウエア製品が該当します。「暗号アルゴリズム」や「プロトコル」を実装しているものも含みますが、一般的な「暗号アルゴリズム」や「プロトコル」等の仕様そのものの脆弱性は含みません。

情報セキュリティ早期警戒パートナーシップガイドライン

迷っている間に、何人かの脆弱性発見に慣れた方々に、「こんな脆弱性があるのですが、どうすべきですかね」と話しかけてみたところ、「その件は先日届け出た」という情報を得た。なるほど、既に先に気づいて届け出た人がいると。ならばということで、私としては届出をしないで、独自の活動をすることにした。根本的な解決は、端末の修正ではなく、この方式の廃止だと考えたからである。*7

そして、昨年6月、iPhone用の電波チェッカーの件でソフトバンクモバイルの宮川CTOとTwitterでお話をすることができた際に、ついでに、この件についてもお願いをしてみた。

実は、このやりとりの途中で、SBCSIRT(Softbank Telecommunications Security Incident Response Team)宛に、詳しいことを書いた以下のメールを送っていた。

Subject: secure.softbank.ne.jpの件 (Re: 脆弱性通知: 「電波チェッカー」で...)
Date: Wed, 16 Jun 2010 11:25:41 +0900

SBCSIRT〓〓様

(略)

別件についてここで続けさせていただいてよろしいでしょうか。secure.softbank.ne.jp についてです。

ソフトバンクモバイルの携帯電話のWebブラウザで、https:// のページにアクセスすると、secure.softbank.ne.jp を通すようにリンクが書き換えられる仕組みになっています。(以下参照。)
http://creation.mb.softbank.jp/web/web_ssl.html

これは「ユーザID」をSSL通信時にも利用できるようにするためなどの措置であると理解しています。

しかしこれは、JavaScript機能のある端末では重大なセキュリティ欠陥となります。

なぜなら、すべての https:// のサイトが同じ secure.softbank.ne.jp のドメイン上で表示されるのですから、Webのsame-origin policyが完全に破れ、任意ドメインのサイトから任意ドメインのサイトにアクセスできてしまいます。

たとえば、Gmailをソフトバンクモバイル端末で使うとき、普通にログインしますと、
https://secure.softbank.ne.jp/mail.google.com/.....
というURLで、ログイン状態になります。このとき、ログイン状態の維持は、secure.softbank.ne.jp に対して発行されたcookieによってブラウザ上で制御されます。

ということは、
<iframe src="/mail.google.com/" name="foo"></iframe>
というHTMLを、攻撃者の https:// サイト上に設置すれば、攻撃者は、alert(foo.document.body.innerText); といったJavaScriptでGmailのテキストを取得することができてしまいます。同様に、
alert(foo.document.cookie);
といったJavaScriptで当該cookieを取得することもできてしまいます。

ログイン中の画面を盗み読むことができるだけでなく、任意の操作も可能ですから、致命的な欠陥と言えます。

私がこの問題に気づいたのは、今年4月のことでした。もっと早く気づくべきだったと悔やんでいますが、ソフトバンクモバイルの一部の端末でJavaScriptが動くということを知らなかったためです。フルブラウザとケータイブラウザが分けて提供されている意味は、ケータイブラウザにはJavaScriptを搭載しないというつもりなんだろうと思っていました。

この問題について、私は、IPAの脆弱性届出窓口には届け出ていません。その理由は以下の理由からです。

1. この問題は、特定のWebサイトの脆弱性でもないし、ソフトウエア製品の脆弱性とも言い難い。いわばプロトコルの脆弱性であり、IPAの届出制度の取り扱い対象外だと思う。

2. 修正によって解決する方法がないと思われる。この仕組み自体を廃止して、各Webサイト側が対処するしか解決しないと思われる。

3. 何か月か前に同じ問題について既にIPAに届け出た人がいるという情報を得た。

ここで直接そちらに連絡を差し上げているのは、問題解決が困難と思われるからです。

上で「修正によって解決する方法がない」と書きましたが、修正方法として考えられるのは以下などの候補だと思いますが、それぞれ不適切であると思います。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

=> この方法は、どんな副作用が出るか予想もつきません。すべての機能が期待した通りにうまくいくかどうか大いに不安です。今後新機能が追加されるときに何が起きるかもわかりません。

(b) https://secure.softbank.ne.jp/www.foo.com/bar.html という形態をやめて、https://www.foo.com/bar.html の通信を直接書き換えるようにする方法。通信内容を書き換える(ユーザIDの付与等)ためには、SSL通信の中継をする必要があるので、man-in-the-middle attackと同様の方法によって実現する。このときに、端末側でSSLサーバ証明書のエラーが出てしまうのを避ける必要があるので、ゲートウェイ上で、アクセス先ドメイン用の偽の証明書をオンデマンドに自動生成し、その発行者となる独自CAのルート証明書を事前に全端末にインストールしておく。

=> この方法は、実現可能(偽証明書のオンデマンド生成は、企業向けの監視システムで実現されていると耳にします)と思われますが、偽証明書によるSSLというものをはたして、電気通信事業者がやってよいのかという疑問があります。私企業が社内ネットワークの監視目的で導入するのは許されても、電気通信事業者が一般向けのサービスにおいてそれを実施するのは、電気通信事業法違反かどうかわかりませんがスレスレだと思いますし、倫理的に許されないと思います。

(c) ゲートウェイ上のフィルタリングでなんとか攻撃を防ぐ方法。

=> 無理だと思います。

(d) JavaScript機能を凍結する方法。全端末を修正してJavaScript機能を凍結する。

=> 2010年夏モデルからJavaScriptを公式にサポートすると発表されているので無理ではないでしょうか。

以上のことから、secure.softbank.ne.jp は廃止するしかないと思います。

廃止によって何が失われるかですが、ユーザID付与の機能について言えば、元々、SSL経由で送られてきたユーザIDは、偽装されている可能性があるため、認証に使用することができません。

なぜなら、ソフトバンクモバイルは、現在、特定のAPNとProxyを使用することで、PCからゲートウェイ経由でアクセスすることができるため、
http://creation.mb.softbank.jp/web/web_ip.html
のIPアドレスでアクセス制限しているWebサイトであっても、任意のHTTPリクエストを送られる可能性がある状態であり、PCから直接SSLで接続されると、任意のX-JPhone-UID: を送られてしまうのですから、SSL経由でのX-Jphone-UID: はいずれにせよ使用できない状態です。

したがって、secure.softbank.ne.jp は廃止してしまってよいと考えます。

私は、この問題が放置されることを懸念しています。修正による解決が困難で、廃止するしかないときに、廃止の決断ができないで、半年、1年、あるいは何年も放置されるのではないかと懸念しています。

私としては、各Webサイトの安全を守るために、対策方法を周知していかなければならないと考えています。その一つは、secure.softbank.ne.jp を通さないようにするためのリンク方法を見つけ出して周知していくことです。

しかし、周知するにあたって、なぜそうしなければならないかの理由を説明しなければなりません。そのためには、この問題があることを説明せざるを得ません。

一般的には、脆弱性が修正されるまで、もしくは脆弱性を通知してから一定の期間は脆弱性の内容を公表することは控えるべきという考え方が、責任ある情報開示の手順とされていますが、今回のように、修正が見込まれないものについては、回避策を周知することも正当であると思っています。

しかし、できれば、ソフトバンクモバイル自身によってそれを行っていただきたいと思います。つまり、まず、secure.softbank.ne.jp の廃止を予告したうえで、暫定措置として、secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知することです。そのためには、廃止の妥当性を説明するために、そもそもSSLで送られてきたX-JPhone-UID:を使用してはならないことの周知も必要と思います。

いかがでしょうか。

高木 浩光@自宅

これ対するSBCSIRTからのお返事は頂けなかったが、上のように宮川CTOとTwitter上で直接対話することとなった。

ソフトバンクモバイルの対応は適切だったか

正直、いくら「廃止するしかない」とお願いしたところで、実現は無理かもしれないと悲観的に思っていた。なぜなら、廃止すると不具合の生じるWebサイトがあちこちにありそうで、そこからの苦情対応に追われることになりそうだからだ。

一方で、昨年5月の時点で、2010年夏モデルから、ソフトバンクモバイルは、Ajaxなどに対応し、正式にJavaScriptをガラケーWebに搭載すると発表されていた(ケータイWatchの記事)。

その後、その夏モデルの一つである「944SH」について、徳丸氏が購入してテストしたという知らせが入った。それによると、新端末では、上記のSBCSIRTへのメールの中で書いていた(a)の対策がとられているっぽいとのことだった。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

944SHの発売日は2010年6月18日なので、Twitterでのやりとりから2日後である。つまり、これが「お願いへの対応」ということはないだろう。おそらく、別の方が先に(数か月前に)脆弱性として届け出ていた件への対応、もしくはソフトバンクモバイルが自力で気づいて対応していた結果であろうと考えられる。

一方、従来機種でJavaScriptを勝手にサポートしていた機種については、危険が残ったままということになるが、ソフトバンクモバイルは、別件の脆弱性への対応で、2010年5月27日の時点で、それらの機種ではJavaScriptをオフに設定するよう告知していた。*8

ソフトバンクモバイルによる告知はわりと徹底されていたようで、メールによる告知もされていたようだし、旧機種の販売においては、JavaScriptをオフにするよう説明した紙を同梱していたようだった。(そのわりには、「ソフトウェアアップデート」によるJavaScriptオフ設定への強制変更という措置はとられなかったが。*9

そうすると、ソフトバンクモバイルとしては、この事案も含めて「もう解決済み」というスタンスなのかもしれないという話になる。secure.softbank.ne.jp廃止の約束はどうなったのか。このまま「解決済み」として、廃止の話は立ち消えになってしまうのではないかとの不安がよぎる。

対処済みと言えるならば、脆弱性情報を公表して、危険性を呼びかけるということも考えられた。しかし、せっかく、宮川CTOがTwitterの場で廃止を約束してくださっているのだから、それを信じたいと思い、しばらく静観することにした。

そして、Twitterでのお願いから4か月後の10月15日、ソフトバンクモバイルから、secure.softbank.ne.jp廃止のお知らせが出た(ITmediaの記事)。廃止の実施はそれからさらに3か月半後の2月1日だという。ずいぶん時間がかかるなと思ったが、廃止が決定されただけでも大いなる英断であると思ったので、とやかくは言わなかった。

それがその後、廃止が2月1日から6月30日へと、5か月も延期されたときには、さすがにいかがなものかと思った。脆弱性の解消である旨も伝えられておらず、ITmediaの記事でも「サイト開発の利便性向上などを目的に」と伝えられているだけだった。

おそらくは、いわゆる「公式サイト」などソフトバンクモバイルと契約のあるサイトに対しては、事前に情報が伝えられて、サイト改修の必要性について説得が試みられていたのだろうと思うが、5か月もの延期が、そうした提携先のわがままによるものだったとすれば、情報を知らされないまま危険を放置することになった一般のWebサイトにとっては、やりきれないものがあるのではないか。

私としては、SBCSIRTへのメールの中で、暫定措置を提案していた。「secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知すること」と具体的に提案したのだったが、それは実現されなかった。

secure.softbank.ne.jpの機能が生きている限り、Webサイト側での自衛策はそれしかない。また、それさえ提供されれば、廃止までに各Webサイトで事前に対処できるわけで、スムーズに移行できたはずではないか。実現が不可能だったのだろうか。

Webサイト運営者らの反応と対応

secure.softbank.ne.jpは6月30日の早朝に廃止され、Twitterでいくらか反応が出ていた。ざっくり集めたものを以下に示す。

やはり、不具合が生じているようだが、secure.softbank.ne.jp廃止は、避けて通るべきではなかった重要な措置であるのだから、こうした措置を遅らせるようなことを言わないようにと願う。

その他、検索して調べてみたところ、2月の時点でもいくらか反応が出ていたようだ。

また、この仕様変更によってどのような不具合が生じ得るかについてのまとめもあった。

ここに記載されている情報によると、「SSP(SoftBank Solution Provider)認定企業に限り、申請すれば2月以降も「GW中継SSL」を利用できるようだ。SSP認定企業ならこの方法も選択肢に入れて対処できる」とある。

しかし、そうした申請をする企業は、secure.softbank.ne.jpを使い続けることの危険性を知らされているのだろうか。*10

廃止の理由を単に、「セキュリティの向上。従来はゲートウェイサーバーが一旦SSLを解いていたが、今後は端末とWebサーバー間でSSLが解かれることがない」というものとして解釈していると、「うちのサイトではSSLが解かれても別に問題ない」と、誤った判断をしてしまう虞れがある。

不具合の出たWebサイト運営者におかれては、大変なこととはお察しするが、廃止の重要性に鑑みて、粛々と対応を進めて頂きたい。間違っても、secure.softbank.ne.jpを復活せよなどと要求するようなことはしないで頂きたい。

かんたんログイン廃止、ケータイID廃止に向けて

ソフトバンクモバイルは、2010年10月の時点で、この件についての利用者向けのお知らせを出している。

上のように、いわゆる「かんたんログイン」が(SSLサイトで)使えなくなることを知らせている。

昨年4月27日の日記「まだまだ他でも破綻しているケータイID認証 」で「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」とまとめたように、ソフトバンクモバイルの端末において、httpsサイトでケータイIDのなりすましを防ぐ方法は存在しない。

ケータイIDを使った「かんたんログイン」なる方式は、そもそも安全に実装できないのだから、この際やめてしまうべきであることは、これまでにも述べてきた通りである。

今回の事態からも、キャリアがインターネット標準から離れた独自方式を安易に投入して、技術コミュニティとのオープンな議論を断絶するようなやり方は、将来に長期にわたってやっかいな問題を引きずりかねないもので、いずれ自分の首を絞めることになるものと、そのような教訓が得られるはずではなかろうか。

その他の類似のケース

ガラケーWebでない、一般のインターネットのWebにおいても、1990年代には、DeleGateを用いて、「-_-」記法を用いて http://www.delegate.org/-_-http://example.com/ の形式で利用する中継サーバを立ち上げて、漢字コード変換や、大阪弁変換フィルタのようなサービスを提供するなどのことが行われていた。

今から思えばおおらかな時代であったわけだが、21世紀になると、JavaScriptが定着し、cookieを用いたログイン機能を持つサイトが当たり前となり、Webの仕組みがsame origin policy(同一生成もとポリシー)に強く依存して成り立つ時代になると、そのようなサービスは危険を生じさせ得るものとなっていた。

今でも、URL中に中継先を指定するサービスが残存しているところがあると思うが、そういうサービスで、中継先のサイトにログインしないように注意しないといけない。いくつかのそうしたサービスでは、そうしたログインができないようにcookieを削ったり、ログインを要するサイトへの中継を遮断するなどの対策をとっているようである。

そうしたサービスで対策のないものは、脆弱性に該当すると言える場合もあるかもしれない。

関連(この問題に気づいたころに書いたもの)

*1 「Togetter - UDID他についてソフトバンクモバイルCTOとのやりとり」の後半部分参照。

*2 最初にこの仕様に気づいた当時(たぶん2004年ごろ?)の印象では。2008年に、ソフトバンクモバイルの担当者の方と議論をする機会があり、この仕様について、「大丈夫かあやしいのではと思っている」という発言をした記憶があるが、その時点では、この事態にまだ気づいていなかった。

*3 SSLの通信内容が途中で傍受可能になるのはけしからんと主張するにしても、ソフトバンクモバイルはコテコテの電気通信事業者なので、電気通信事業法に基づき通信の秘密は守られていると言われれば、ポリシーの問題でしかない。コテコテの電気通信事業者が通信内容を改竄するのはけしからんと主張するにしても、他のキャリアもhttp:ページでは書き換えをやっているし、業務上必要な処理であって利用者に黙示の同意があると言われれば、そうですかとしか言いようがなかろう。

*4 cookie空間がドメイン間で共有されてしまうという問題もありそうだったが、Set-Cookie:の際に「path=/」の属性指定をしている場合にだけ問題となる(JavaScriptがない前提で)だろうから、Webサイト側の問題とされてしまう展開が予想されていた。今思えば、それでもそれを問題提起するべきだったかもしれない。(関連:2010年5月1日の日記「共用SSLサーバの危険性が理解されていない」参照。)

*5 この件は、その後、昨年5月24日(ソフトバンクモバイルへの脆弱性通知から半年待った時点)に公表されている。「Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題」参照。

*6 ガラケーWebの世界でどうだかは知らないが。

*7 脆弱性届出制度が、「一般的な暗号アルゴリズムやプロトコル等の仕様そのものの脆弱性」を対象外としているのは、このように、特定の製品固有の脆弱性ではない問題について、発見者の活動を制限しないよう配慮したことによるものである。(情報システム等の脆弱性情報の取扱いに関する研究会 2008年度報告書のp.30「4.3.暗号アルゴリズム及びプロトコルの脆弱性の取扱い」参照。)(たとえば、暗号アルゴリズムの脆弱性について、学会発表を妨げるようなものであってはいけない。関連:「脆弱性情報公表の自由 〜 コントロールを取り戻せ」参照。)

*8 これは、2010年5月24日に徳丸氏が発表した「Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題」への対応。

*9 私のテスト用端末「816SH」では、2010年7月にソフトウェアアップデートがあったが、そのときにJavaScriptオフへの措置は講じられなかった.

*10 「SSP認定企業」のページしかsecure.softbank.ne.jp上に表示させないことによって、攻撃者側がsecure.softbank.ne.jp上にJavaScriptコードを記述できなくなるから、危険は解消するというつもりかもしれないが、secure.softbank.ne.jpの使用を継続している「SSP認定企業」のサイトの1つにでもXSS脆弱性があれば、同じく使用継続している他の「SSP認定企業」のサイトにも同じ危険が生じる。また、使用継続しているサイトの1つに、ブログサイトなどがあってJavaScriptの記述が自由だったりすると、同様に他のサイトに危険が生ずる。このことが使用継続を申請した「SSP認定企業」に知らされているかどうか。

本日のTrackBacks(全1件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20110630]

 6月30日のsecure.softbank.ne.jp廃止*1にともない、みずほダイレクトにおいて、ソフトバンクの携帯電話からログインできなくなるという障害が報告されています(リリース)。  他の銀行はどうかと思い、軽く調べて始めたところ、モバイルバンキングでは今でもsecure.soft

検索

<前の日記(2011年06月26日) 次の日記(2011年07月07日)> 最新 編集

最近のタイトル

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2011年06月26日) 次の日記(2011年07月07日)> 最新 編集