KDDIがWebメールサービスを再開、不具合の原因も判明 41
ストーリー by hylom
原因が分かるような分からないような 部門より
原因が分かるような分からないような 部門より
iwakuralain 曰く、
KDDIは不具合のため7月25日から停止していたau one net(旧DION)のWebメールサービスを、2008年8月14日に再開したと発表した（ニュースリリース）。
不具合は無関係なユーザーのメール本文やアドレス帳などが見えてしまうというものだったが、KDDIによると原因はとのことで、KDDIは問題のパラメータを修正、さらに、不具合を検知して利用者のメールの誤った閲覧を阻止する機能を追加導入した、とのことだ。なお、ログデータからは計3名の利用者のメールが、それぞれ他の1人のユーザーから閲覧できる状態だったそうだ。WEBメールを構成しているシステムにおいて、複数のシステムを制御するパラメータの設定に誤りがあり、システムに例外的な処理が発生した場合に本不具合が発生しました。 パラメータの設定誤りは2007年12月19日 (水) に実施したシステム改修作業の際に発生しました。
今回のケースはユーザからの申告を受けて調査を開始した事が発端となっているが、悪意ある者が申告をせずに悪用していた場合などを考えると事態はもっと深刻になっていたのかもしれない。
お客様の中に (スコア:5, おもしろおかしい)
Re:お客様の中に (スコア:1)
「患者様！患者様のなかに、電カルシステムの保守経験がある方、いらっしゃいませんか？」
＃壮大なストーリ。空転するアイディア。
電力 る システム かと思った (スコア:1, おもしろおかしい)
おるかっ！
…で、いいですか？
Re: (スコア:0)
Re:お客様の中に (スコア:1)
Re:お客様の中に (スコア:2, おもしろおかしい)
Re: (スコア:0)
せめてqmail (とか言ってみる。
Re:お客様の中に (スコア:1, 参考になる)
Re:お客様の中に (スコア:1)
Re: (スコア:0)
お、本当だ
生き残ったのは結局Sendmailか…
Re: (スコア:0)
Re:お客様の中に (スコア:1)
---
↓ここからどんどんマイナーなMTAが出てきます。
Re: (スコア:0)
PCRE を見るたび思い出します (スコア:0)
Re: (スコア:0)
これがfakeだったら面白いけどそんなことをやる余裕があるとは思えんか。
Re: (スコア:0)
今回の問題はWEBメールにのみ発生していたとのことなので、 MTA は関係ないんじゃないかと思われ。
$とかBとか (スコア:3, 興味深い)
$とかBとか見た瞬間、ん？漢字In/Outか！とか思ってしまいました。
エスケープシーケンスコードナツカシス。
屍体メモ [windy.cx]
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
> エスケープシーケンスコードナツカシス。
それよりこんな基礎的な不具合を作る開発体制に驚いた。
今どき単純にバイナリマッチしているだけ？もしかして。
叩けば他の問題がいっぱい見つかるのではなかろうか？
全く明らかにされていない原因 (スコア:2, すばらしい洞察)
Re: (スコア:0)
また、その理由は何ですか？
私だったら、「そのパラメータ誤りが発生した理由、および今後発生しない対策」かなあ。
今後、同じ問題を出さないことを理解したいから。
また、同じことを私もやらないように反面教師にしたいので。
Re:全く明らかにされていない原因 (スコア:1)
本当の原因
> また、その理由は何ですか？
KDDI には個人情報を紛失された挙句にお詫びの手紙を貰っただけという対応をされた事、TU-KA ユーザーで au への移行を希望しないユーザーへの仕打ちが頭にあるので、実際の被害及び「偶然他人もメールが見えた」程度であるから、悪意を持って見てやろうと狙われた場合に耐えうるのかが知りたい。
au one net 以前の旧Webメールもプロキシ経由では「ログアウトしています」連発で使い物にならず、連絡しても改善されなかった。セッション管理がダメなんじゃないかなと思う。それに置き換わった au one net は、一度も使えた試しがないのだが、旧Webメールは廃止という方針も出され、これに乗り換えないとダメなのかと思っていたから、ある程度の改悪ならまだしも今回の様な重欠陥が潜んでいるようであれば困る。
Re: (スコア:0)
アクセスごとにIPアドレスの変化するISPは存在するのか [hatena.ne.jp]
Re: (スコア:0)
「本当の原因」が知りたい理由をちょっと整理してみました。
前提条件として、「旧webメールから新webメール（で良いのかな？）に移行しなければならない」というものがまずあります。で、この際、移行先の新webメールが、悪意を持って見てやろうと狙われた場合に耐えうるのかが知りたいと。
なぜならば、旧webメールではそういった問題が無いはずだから。
------------
ここまでは、「なるほど確かにそうですね」と思ったんですが、そっから先が理解しきれませんでした。
1. 個人情報を紛失された挙句にお詫びの手紙を貰っただけという対応
2. TU-KA
Re: (スコア:0)
Re: (スコア:0)
どういう対応をお望みなんですか？
いわゆる「誠意」がなかったこと？それとも社長以下役員全員の土下座？
Re: (スコア:0)
# 中の人多数知ってるからAC。
typo (スコア:1, すばらしい洞察)
なじる意図はないのですが、次からはもちっと校正していただければ幸いです。
大間違いのような (スコア:0)
「発生」ではなくて「停止」ですよね。
善意の通報者 (スコア:1, 興味深い)
通報→不正アクセスで逮捕なんてことにならんのでしょうかね。
Re: (スコア:0)
特別なアクセス方法を用いていなければ特段逮捕要件を満たすとは思えないので、このケースではありえないんじゃないでしょうか。
「定義」の相違 (スコア:1, フレームのもと)
例えばACCS不正アクセス事件では，善意（かなぁ？）の通報者側の有罪が確定してますし．
人は見た目が120%
Re:「定義」の相違 (スコア:1, すばらしい洞察)
Re:「定義」の相違 (スコア:1)
・1. 脆弱性を指摘しただけ
・2. 該当の脆弱性も，アクセス制限などはかかっておらず，不正アクセスの要件には当たらない
と無罪を主張していました（ソース記事 [itmedia.co.jp]）．
結果として裁判官はこの主張を認めず有罪（執行猶予付）となった訳ですが，本人にしてみればまさに
> 通報行為から有罪に成った
ということになるのでは無いでしょうか？
# そもそも通報方法に問題があったのは間違いないですが…
人は見た目が120%
ACCS事件と比較するのは的外れ (スコア:1)
「善意の通報者」の立場や状況が異なるのに、ACCS事件が出るのは不適切ではないでしょうか？
（１）善意は同じだとしても、「立場」が顧客か非顧客か関わる必然性が異なる
（２）「状況」は、通報者が意図して起こしたものか、偶発的に起こったものか
（３）意図して再現可能なら、「提供者が対応する前に手法を第三者に公開」したか
office氏の事例は、不特定多数が利用可能なフォームだったから、正当な利用が無くても、
立場的には潜在的にサービス受益者だったと言えたかも知れません。
しかし、その手順 [cnet.com]は通常の利用において偶発的に起きる可能性が全く無く、
セミナー当日にもACCSは認識しておらず、office氏はセミナー終了後に報告 [geocities.jp]しました。
「4回の試行で1,184名の個人情報を取得」という数も、「実証の範囲」と見なすには多い量です。
セミナーでインパクトを強めたい、自己顕示欲が働いていたと見なされてもおかしくありません。
さらに、手法がセミナーより広範囲に拡散した事、実際に模倣した人間がいた事も、
公開した場所と手順が正しくなかった事を裏付けるには十分です。
これだけ違いがある以上、今回の事例なら、office氏同様の逮捕要件を満たすはずがありません。
それと、ACCS事件以降では「脆弱性報告の環境」が全く異なっている事も失念してるのでは？
ACCSの事例のような脆弱性発見でも、安全に通報出来るようにIPAの届出窓口 [ipa.go.jp]が出来ていますので、
「手法をサービス提供者の対応前に公開」という誤った手段を取る必要性が全くありません。
当然「修正前に出来るだけ自分で悪用」していては、IPAに届け出ても無意味でしょうけど。
office氏の行為は当時は微妙でしたが、今なら善意の通報者とは見なされない行為になりました。
届出窓口に通報したのに改善されない、その間にも被害が発生しているという状況があって、
義憤にかられてしょうがないなら、反撃されるリスクを負って告発するしか無いでしょう。
けど、そこまで至るケース自体聞きませんし、そういうのは事件として顕在化しているのではないですかね。
まあそれでも、@nifty パレットの事例 [bakera.jp]とかIPAの25回にわたる報告を無視 [bakera.jp]とかあるようです。
そういう場合、発見者がすべき事は、せめて自分が利用中なら退会して、情報の完全な削除を求める事で、
告発しなければならない重大な問題とするかどうかは、反撃されても戦える時間的な暇があるかどうか、
戦っている間にも生活の糧が不自由なく得られるかどうかによってくるのでは無いでしょうか。
補足、顕在化した事例 (スコア:1)
厳密には、報告を受けた所「だけ」は対応していたという事例ではあるのですが、
プログラムのデータアクセス方法に問題があったら、他に同じようなロジックで書いていて、
同じように対策が必要な場所を探す手間を省くという対処療法的な対応をされた場合、
報告者が油断して気がついていたにも関わらず自分の情報が漏洩する事も起きそうですね。
参考：IPAからの指摘を教訓にできなかったアイリスプラザ [bakera.jp]
Re: (スコア:0)
ACCS自身も、脆弱性を教えてくれる事には問題は感じていないと言っている。
その脆弱性を悪用し、その結果、不必要に個人情報をバラ撒いたから事件になった。
Re:「定義」の相違 (スコア:1)
連続投稿で申し訳ない，一応反論を．
確かに裁判に至った経緯は仰る通りで，河合氏（被告）の行為に問題があったのは確かだと思います．
しかし裁判では河合氏（被告）が行った行為が「不正アクセス」に当たるかどうか，すなわち「特別なアクセス方法」の定義も争われましたので，例としては適切だと考えています．
人は見た目が120%
Re: (スコア:0)
アクセス方法だけでセミナーが開けるほど「特殊なアクセス方法」だったでしょ？
Re: (スコア:0)