<前の日記(2007年12月15日) 次の日記(2007年12月22日)> 最新 編集

高木浩光@自宅の日記

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

2007年12月16日

一太郎Zero-day攻撃発覚経緯の謎 ―― 非国民は誰?

目次

  • 一太郎zero-day攻撃発覚経緯の謎
  • Symantecは脆弱性分析のプロではない
  • 日本人Symantec社員は非日本国民か
  • 非国民は誰?
  • ジャストシステム社も経済産業省告示を無視?
  • 現行の届出制度はzero-day攻撃に対応していない

一太郎zero-day攻撃発覚経緯の謎

先週こんな報道があった。

またか。

「また一太郎か」という意味ではなく、「また Symantec か」という意味でだ。

一太郎関連製品のバッファオーバーフロー系の脆弱性はこれまでに8回見つかっており、うち3回は、攻撃に悪用される前にIPAとJPCERT/CCを通じて事前に修正されたもの(JVN#90815371, JVN#47272891, JVN#29211062)で、残りの5回はいずれもzero-day攻撃が発生した中で発覚している。その際の報道を並べてみると次のようになる。(24日追記:ITmediaとマイコミジャーナルを追加した。)

このように、第一報はすべて「シマンテックが」「Symantecが」だ。なぜこうなるのだろう? 偶然にしては不自然ではないか?

これはこういうことが起きているのではないだろうか。

まず、Symantecの当該ウイルスデータベースを見てみると、いずれも「Wild Level: Low, Number of Infections: 0 - 49, Number of Sites: 0 - 2」となっている(例えば、最も古いTrojan.Tarodropを参照)ことから、おそらく、どれも 1件の報告(ウイルス検体の提供)があっただけなのだろう。

次に、ウイルス対策ソフト会社は数社あるにも関わらず、すべてSymantecに検体が提供されたということは、おそらく、検体の提供元は同じ人物ないし、同じ組織ではないだろうか。

つまり、典型的な targeted attackが昨年から継続して仕掛けられており、しかもそのターゲットが同じ組織に絞られているのではないか。

ここで思い出すのが、2006年5月の「第10回 コンピュータ犯罪に関する白浜シンポジウム」で聴講した警察庁担当者の講演内容だ。これは次の通り報道されている。

  • 「警察を標的にしたスピア型フィッシング・メールが増加」---警察庁 坂明氏, 日経IT Pro, 2006年5月29日

    「警察や防衛庁を標的とする,特定の対象を狙った偽装メール,いわゆるスピア型フィッシング・メールが増加,かつきわめて精巧になってきている」--- 警察庁 生活安全局 情報技術犯罪 対策課(サイバー犯罪対策課)課長 坂明氏は5月26日から28日にかけて開催された「第10回 コンピュータ犯罪に関する白浜シンポジウム」の講演で,警察庁を標的とする攻撃が増加していることを明らかにした。

じつは私も勤務先のメールアドレスは go.jp で終わるものなので、それらしきメールを受信したことがある。2005年6月のことで、これは [memo:8513] で報告した記録がある。このときは、少し後に非政府の個人アドレスにも届いているという報告もあった。その後何度かは同様のメールを見かけたものの、2006年の白浜シンポジウムで上記の講演を聴講した時点では、もはや見かけなくなっていた。一太郎の添付ファイルの付いたメールも見たことがない。zero-day攻撃は、かなり対象を絞って、密かに行われているのではないだろうか。

一太郎の未知の脆弱性を突いたzero-day攻撃は、ごく限られた組織に対してだけ行われているのではないかと憶測する。それが、警察庁なのか、防衛省なのか、他の政府組織なのか、もしかすると民間組織なのか、その情報は持っていないの知らないが、狙われやすいのは重要な任務を担う政府の担当者のアドレスだと考えるのが普通だろう。

標的にされているその組織が、あるいはその組織の情報システム管理者が、毎度、ウイルス検体をシマンテック社に提供しているとすればどうだろうか。報告先としてシマンテックを選択している理由も単に、その組織の情報システム御用達のウイルス対策ソフトがシマンテック製だとすると、どうだろう。

というと、こういう疑問が出てくるかもしれない。つまり、「ウイルスメールを見つけた情報システム管理者が契約先のウイルス対策ソフト会社に報告する――それのどこがいけないのか?」と。

それはやっぱり駄目だろう。少なくとも政府機関がそんなことでは駄目ではないか。

Symantecは脆弱性分析のプロではない

まず第一に、結果として皆が不利益を被っているという実害が生じている。それは何かというと、10月30日の日記「一太郎plug-inをIEとFirefoxで無効に 〜 ジャストシステムは本当の脅威を教えてくれない」の件である。

10月30日の日記に書いたように、一太郎の脆弱性は、(おそらく過去の8件の何れも)Webブラウザ用一太郎plug-inの脆弱性でもあり、悪意あるWebサイトを訪れただけで攻撃が成功するという、危険度の高い脆弱性であるのだが、ジャストシステムはそのように発表せず、「出所の不明な一太郎文書ファイルを開かないようご注意ください」などと、あたかも、ローカルファイルを開かなければ問題ないかのような誤った情報を流していた。

これは、ジャストシステム社に脆弱性分析能力が欠けている(あるいは、脆弱性情報を正しく利用者に伝えることについての社会的責任の認識が欠けている)ことも原因の一つであるが、一次情報源である Symantecがそう言っていることも原因になっているのだろう。一太郎zero-day攻撃のニュースは、次のように、いつも Symantecの blog「Security Response Weblog」が一次情報源になっている。

この中で、利用者向けの注意として「出所の不明な一太郎文書ファイルを開かないようご注意」ということが書かれている。

Since this vulnerability has yet to be patched, you should be extra careful when using Ichitaro and refrain from opening Ichitaro files received from untrusted sources. Also remember to keep your security software up-to-date and follow safe computing practices.

New fiscal year in Japan, new zero-day in Justsystem's Ichitaro, Joji Hamada, Symantec, 2007年4月7日

We are not currently aware of any patches available to fix this issue, so until JustSystems releases a patch, we would advise all Ichitaro users to treat unsolicited .jtd files with extreme caution.

Zero-day Vulnerabilities: Following the Trailblazers, Hon Lau, Symantec, 2007年12月13日

先週発覚した最新の件でも、「we would advise all Ichitaro users to treat unsolicited .jtd files with extreme caution」などと言っており、これは、日本での報道内容に影を落としている。

このように、報道では「信頼できないファイルは開かないといった心構えで回避」できることになってしまっているのは、Symantecの一次情報がそう書いているからだろう。日経BPの勝村記者なんぞはこれを自分の考えとして書いてしまっている。一方、INTERNET Watchの記事では「Symantecでは……呼びかけている」と、あくまでもSymantecがそう言っているということを伝えるに止めているが、読者は、それで回避できる程度の危険度の低い脆弱性だと読むだろう。(ちなみに、ITmediaの記事は回避方法について触れていない。)

ジャストシステム社は今回、このことについて、次のように発表した。

現象とその対処方法

2007年12月13日、当社製品の多くが共用しているプログラムライブラリファイルに脆弱性が確認されました。この脆弱性が悪用されると任意のコードが実行され、パソコンが不正に操作される危険性があります。

悪意の攻撃者は不正に改ざんしたファイルを作成するなどし、そのようなファイルを電子メールの添付ファイルにして送りつけたり、 Webサイトに置くことで攻撃を仕掛けます。お客様がそのようなファイルを開いたり、リンクをクリックすることで、意図せず不正な文書ファイルを読み込み、悪意の攻撃を実行させてしまう恐れがあります。

本モジュールは今回発見された脆弱性を修正するもので、これを導入することにより原因となる箇所において不正な動作は発生しなくなります。

セキュリティ更新モジュール導入にかかわらず、身に覚えのない電子メールに添付されている文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な文書ファイルを開かないよう、ご注意ください

ジャストシステム製品の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, 2007年12月14日

いちおう、「リンクをクリックすることで」と書かれている。これの意味するところを見逃さなければ、正しい報道ができるはずなのに、誰もやっていない。

それは、ジャストシステムのこの発表文の出来が悪いことを意味する。「リンクをクリックした後、ダウンロードの確認画面で『開く』を選択すると」という意味だと誤解する読者もいるだろう。伝えるべきは、「悪意あるWebサイトを訪れただけで」ということなのだが、それを書いていない。

「経営判断」でわざとそれを書かないようにしているのかとも思えるところだが、実際のところ、この発表文は10月のときの発表文をコピペしただけだ。

もし、一次情報源である Symantecが「悪意あるWebサイトを訪れただけで」と書いてくれたなら、危険性は正しく周知されただろう。

Symantecにそれができないのは、彼らは脆弱性分析のプロではないからだ。彼らは、個々のマルウェアの挙動を分析するリバースエンジニアリングのプロフェッショナルではあるが、脆弱性の影響範囲を評価するプロではない。彼らの仕事は、ウイルス対策ソフトを売ることであり、脆弱性の危険性を社会に伝えることではない。同じ1つの脆弱性を突く複数のマルウェアが次々と登場すれば、それらひとつひとつがウイルス対策ソフトのパターンファイルに登録され、それは彼らのソフトの対策能力の向上を意味するが、それを脆弱性単位でひと括りにしてはむしろ損になってしまう。また、ウイルスは脆弱性を突かなくても感染し得るものなので、彼らのビジネスにとって脆弱性分析は必要ではない。

Symantecが脆弱性について素人であることは、彼らが「stack overflow」と誤った用語を使っていることからもわかる。スタックがオーバーフローするわけではない。彼らのblog記事からリンクされているSecurityFocusの脆弱性データベースでは「Stack Buffer Overflow Vulnerability」と書かれており、もう少し正確に言うときは「stack-based buffer overflow」と言う。オーバーフローするのはバッファであり、当該バッファがスタック上にあるタイプ(ヒープではなく)という意味である。

The malicious document uses a unicode stack overflow to execute its code on the system, dropping and executing a Trojan horse named Backdoor.Papi.

Justsystem's Ichitaro zero-day used to propogate Trojan, John Canavan, Symantec, 2007年12月13日

The exploit causes a stack overflow in the application (JustSystem Ichitaro JSGCI.DLL Unspecified Stack Buffer Overflow Vulnerability) and then seizes execution control to drop a Backdoor.

Zero-day Vulnerabilities: Following the Trailblazers, Hon Lau, Symantec, 2007年12月13日

あるいは、彼らにとって、日本でしか使われていないソフトウェアの脆弱性は、どうでもよいことなのかもしれない。この脆弱性の影響範囲を知るには、一太郎を入手してインストールするなどして、plug-inの存在に気づく必要があるが、マルウェアがバッファオーバーフロー脆弱性を突いていることは、一太郎を入手しなくても分析できる。一太郎を入手してまでその影響範囲を探ることは、外国企業である彼らにとって関心のないことなのかもしれない。

日本人Symantec社員は非日本国民か

もうひとつの問題は、主に日本国に影響を及ぼす脆弱性でありながら、その影響分析が外国の企業でしか行えない状態になっていることである。

ウイルス検体は、基本的に、ウイルス対策ソフトベンダーの外に提供されることはないだろう。今回のようなケースでは、一太郎の製造元であるジャストシステムに対して、脆弱性を修正するのに必要な情報として検体が提供されているだろうが、ジャストシステムも、それを外部に提供することはないだろう。

そうすると、他の誰も脆弱性の詳細を確認することができず、影響範囲について憶測でしか語ることができなくなってしまう。8月のときの私のように。

日本国は、経済産業省の告示に基づき、脆弱性情報の取り扱い体制を構築している。告示は、「発見者基準」を次のように定めている。

  • ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号

    検ニ楷霆爐療用範囲

    本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が不特定多数の者に影響を及ぼし得るものに適用する。

    1.日本国内で利用されているソフトウエア製品
    (ソフトウエア製品において通信プロトコル等の仕様を実装した部分を含む。)

    2.主に日本国内からのアクセスが想定されているウェブサイトで稼働するウェブアプリケーション

    后ヂ仂櫃ソフトウエア製品である場合の脆弱性関連情報取扱基準

    一.発見者が製品開発者ではない、又は、発見者が製品開発者であり発見若しくは取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限らない場合

    対象がソフトウエア製品であり、かつ、発見者が製品開発者ではない、又は、発見者が製品 開発者であり発見若しくは取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限 らない場合における脆弱性関連情報の取扱いの流れを以下に示す。

    (顱鉾見者は、脆弱性関連情報を受付機関に届け出る。

    (略)

    1.発見者基準

    (1)発見者(自ら開発等を行ったソフトウエア製品に影響範囲が限られると認められる脆弱性関連情報を発見又は取得した製品開発者を除く。)は、発見又は取得した脆弱性関連情報を経済産業大臣が別に指定する受付機関に届け出ること。ただし、当該製品開発者に対し同じ内容を届け出ることを妨げない。

    (2)発見者は、以下の点を明示した上で脆弱性関連情報を届け出ること。(略)

    (3)違法な方法により脆弱性関連情報を発見又は取得しないこと。

    (4)発見者は、当該脆弱性情報が受付機関及び調整機関から公表されるまでの間、当該脆弱性関連情報を第三者に漏えいしないよう適切に管理すること。ただし、当該脆弱性関連情報 を正当な理由により第三者に開示する場合、あらかじめ受付機関に問い合わせをすること。

    (略)

一太郎の脆弱性は 8件発覚しているわけだが、悪用される前に発見された 3件*1を除く、zero-day攻撃に悪用された 5件の脆弱性について見てみると、そのどれも、脆弱性関連情報取扱基準に則った処理が行われていないようだ。JVNの VN-JPを見ると、悪用される前に発見されて届け出られた 3件のものしか掲載されていない。

つまり、脆弱性の発見者である Symantecは、IPAに脆弱性情報を届けていないと推定される。

もっとも、日本国の経済産業省告示が、米国の会社には及ぶことはないのかもしれない。だが、前述の Symantec Security Response Weblog の著者を見ると、外国人氏名の名前に並んで、「Shunichi Imano」、「Joji Hamada」という日本人ふうの名前がある。

もっとも、この2名が日本国民かはわからないし、日本に居住しているか、勤務先が日本に存在するのかもわからないので、経済産業省告示の及ぶ対象かどうかはわからない。

非国民は誰?

では、zero-day攻撃の標的にされた、ウイルス検体の提供者であるところの、謎の組織はどうだろうか。それが日本の政府機関である可能性は高いし、少なくとも日本に関係する組織であることは疑いの余地がないだろう。

日本の政府組織が、経済産業省告示を無視して、外国企業に情報提供しているのだろうか? まさかそれはないだろう。せいぜい、単に、日本の政府組織に所属する情報システム管理者が、独断で Symantecに情報を流している可能性の方があり得そうな話だ。

ただ、受信したウイルスを Symantecに提供する行為は、直ちに、告示を無視した背信行為とまでは言えない。なぜなら、「脆弱性を発見したわけではない」という抗弁が可能だからだ。脆弱性の発見者は Symantec社であり、検体の提供者は脆弱性の発見をしていないのだと。

しかしどうだろう? 2006年8月の初回はそのような考え方も理解できるが、その後、同様に繰り返し起きた 4件についてはどうか。同じ組織ないし人物が提供しているのなら、「新たな未知の脆弱性を突くものかもしれない」と認識しつつ、Symantecに提供したのではなかろうか?

外国企業に情報提供することが悪いことと言っているのではない。少なくとも、告示の基準に従うべきだろう。民間人ならまだしも、公務員なら当然に。

とはいえ、そう責められるものでもないかもしれない。ウイルス検体を Symantecに提供している人物が、単なる IT素人なだけかもしれない。「セキュリティといえばウイルス対策ソフト」という認識の素人であれば、シマンテックやトレンドマイクロに相談すれば話はすべて解決してくれると思っているのではなかろうか。

ジャストシステム社も経済産業省告示を無視?

その意味では、一太郎の製造元であるジャストシステム社も、「セキュリティといえばウイルス対策ソフトのこと」という認識の IT素人である疑いがある。これについては10月30日の日記の「パソコン初心者並みの認識のソフト会社」の節で書いた。シマンテックがウイルスの感染状況を「Risk Level 1: Very Low」と発表したものを、脆弱性の危険性と取り違えて「危険度判定:低」などと発表する素人ぶりだった。

それだけではない。ジャストシステム社も経済産業省告示を無視していると言えるかもしれない。この告示には次の定めもある。

  • ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号

    二.発見者が製品開発者であり、発見又は取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限られる場合

    対象がソフトウエア製品であり、かつ、発見者が製品開発者であり、発見又は取得した脆弱 性関連情報の影響範囲が自社のソフトウエア製品に限られる場合における関係者の行動基準を 以下に定める。

    (1)製品開発者は、自ら開発等を行ったソフトウエア製品に影響が限られると認められる脆弱性関連情報を発見又は取得した場合、対策方法を作成し、当該脆弱性関連情報及び対策方法を受付機関及び調整機関に通知すること

    (2)受付機関及び調整機関は、(1)による通知を受けたときは、当該脆弱性情報及び対策方法をインターネット等を通じて公表すること。ただし、調整機関はそれらを公表すべき日について、当該製品開発者から意見を聴取した上で定めること。

ここで解釈が微妙になるのは、発見者が外国企業であって、国内で初めてその事実を知らされたのが製品開発者である場合に、製品開発者は「発見者」と言えるのかどうかだ。

また、既に他から公表されている情報を元に知った場合に「発見者」と言えるのかどうかという点もある。届出様式には「情報の入手先」の選択肢として「ウェブサイトから入手」も用意されていることから、必ずしも公知の情報を届け出てはならないわけではなさそうだが、公知の同じ案件がたくさんの人によって届け出られるというのも冗長であろうから、基本的には初期段階で知った者が「発見者」であろう。

だが、常識的に考えて、ジャストシステム社は「発見者」に該当するだろう。なぜなら、脆弱性の存在自体は公知になっていても、脆弱性の再現手順(届出様式で必須の記入項目)を知っているのは Symantecとジャストシステムだけだからだ。

そして、その「脆弱性の再現手順」が Symantec社とジャストシステム社の手にしかないが故に、脆弱性の影響範囲を正しく日本国民に伝えることが不可能となり、日本国にとっての公益が損なわれている。

とはいえ、ジャストシステム社は、ウイルスの感染状況と脆弱性の危険度を混同するような IT素人なので、しかたがない。

現行の届出制度はzero-day攻撃に対応していない

そうすると、現状で欠けている問題の根本はこうだろう。

zero-day攻撃の標的にされた組織が、そこに未知の脆弱性があると発見するに至らなかったにしても、検体をウイルス対策ソフト会社に提供するのではなく、国内の適切なところに届け出るような仕組みになっていれば、それでよいはずだ。未知の脆弱性が突かれているかは、届出を受けた機関が分析すればよい。

ウイルスの届出といえば、IPAが既にやっている。

これは1990年から行われているもので、平成7年通商産業省告示第429号「コンピュータウイルス対策基準」に基づくものである。

しかし、その内容は、基本的に、ウイルス感染事故発生時の各自の対策のあり方を示すものであり、「事後対応」として、「ウイルス被害の拡大及び再発を防止するため、必要な情報を経済産業大臣が別に指定する者に届け出ること」という記述はあるものの、これは、zero-day攻撃時の脆弱性分析を目的としたものではない。

実際、この「届け出ること」という定めは形骸化しており、ウイルスを見かけても届けない人、ネットワーク管理者、企業は少なくないだろう。それは、昔のウイルスは感染することで手にするものが大半だったのに対し、2000年以降は、メールで届くワームのように、感染する前に手元に届くようになったため、「被害に遭ってもいないないのに、受信しただけで一々届け出るなんて、妥当性がない」と考えられるようになったためだと思う。

この制度が役に立っているのは、定期的に発表される届出件数の数字だけで、ウイルスが増えたか減ったかといった実態把握の目的にしかなっていない。(感染機能を持たない単発型のトロイが増えている最近では、この増減状況の情報さえ信頼性が低下していると思われる。)

また、このウイルスの届出と、脆弱性の届出は連携しておらず、組織も別々になっていると私は理解している(あまりよく知らないけども)。

ウイルス届出窓口の目的は、「こんなウイルスが流行っています!」と注意喚起することにあるため、窓口の関心事は、ある程度の規模で拡散しているウイルスの情報にあり、targeted attackのように個別に専用に作られたマルウェアにはおそらく関心が低いであろう。そこに、zero-day脆弱性という貴重な情報が潜んでいても、ウイルス届出窓口の関心事ではないと思われる。

つまり、今必要なことは、未知の脆弱性を突いたマルウェアを収集できるよう、届出の仕組みを変えることではないだろうか。

もっとも、IPAに、マルウェアの分析をする能力はないかもしれない。分析を外注するしかないかもしれない。

結局は民間のウイルス対策ソフト会社に分析を外注することになる(コスト的にそれが妥当)のだとしても、それは、被害者から直接Symantecに検体が提供されてしまっている現状と同じことではない。なぜなら、通常、ウイルス対策ソフト会社の仕事はパターンファイルを作ることであり、提供された検体はパターンファイルの作成にのみ利用されるところ、IPA等からの発注で行われる分析では、公益に資するよう分析内容を指定し、脆弱性発見時に脆弱性の詳細を報告することを役務として指定できるはずだからだ。

zero-day攻撃を見つけるためにすべてのウイルスを集めて分析するというのは現実的でないが、少なくとも、政府機関に送り付けられたウイルスについては自国で分析するのが当然ではないか。外注先が外資系企業で、実際の分析が外国で行われることは、まあ、しかたないにしても、国の発注によって分析させることが必要であろう。ましてや、zero-day攻撃の一次情報が、外国企業の blogで他人事のように暴露された記事(Symantecは入手元を明らかにしていないが)というのは、国辱ととらえてしかるべきではないか。

明後日、「SecurityDay2007」でパネル討論

明後日18日は、SecurityDay2007というイベントで、パネル討論に登壇する。会場は「青山TEPIA 4階ホール」とのこと。

追記(24日)

18日のパネル討論のスライドが以下にある。

また、上の「報道を並べてみる」のところに追記した。

*1 同時期に公表された複数の脆弱性を1件としてカウントしている。

検索

<前の日記(2007年12月15日) 次の日記(2007年12月22日)> 最新 編集

最近のタイトル

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|
<前の日記(2007年12月15日) 次の日記(2007年12月22日)> 最新 編集