2015-12-02

銀行から1万4000件の情報流出」をシステム目線妄想したい

http://anond.hatelabo.jp/20151201162600

上の増田を読んでて、SEやっている人間としては気になったので妄想してみる。

前提

そもそも何が漏れたのさ? WHAT

出会い系サイト銀行振り込みした人の電話番号・振込日時・金額。詳細は上記の増田参照。

誰の情報流出したの? WHOES

出会い系サイト運営者らの口座の情報

ここの口座の入出金明細の中に、出会い系サイト利用者から業者への振り込み履歴があり、そこに利用者電話番号記載されていた。

まり、盗まれたのは出会い系サイト顧客情報出会い系サイト利用者個人情報)で、

被害にあったのは出会い系サイト運営者の口座ということになる。

どこから漏れたのよ? WHERE

「残高照会ダイヤルから

これは、銀行電話自動応答システムの1つで、

口座番号とかを入力して、残高や入出金明細を音声で照会できるという、いわゆる音声自動応答サービス

使用する際は本人認証必要になるが、以下のいずれかが求められる。

どちらかが正しければ本人と確認され、入出金明細が自動音声で読み上げられる。

今回、この「残高照会ダイヤル」にセキュリティホールがあり、それを悪用されて情報流出してしまった。

…「今回」というより、つい先日まで流出し続けていた、という表現のほうが正しいかも。

誰が盗んだの? WHO

銀行提供している音声応答サービスなので、基本誰でも盗める。

上記の増田によると、架空請求業者悪用していた模様。

報道を見ると、今回発覚したのは、

流出した電話番号架空請求電話がかかってきたという警察から情報提供で明らかになった

ということらしい。

いつから流出してたの? WHEN

こちらも報道にある情報から察するに、平成16年2月平成27年10月と見られる。

このシステムは先月下旬に改修されましたが、平成16年2月から使われていたため、実際に流出した情報さらに多いおそれがある

セキュリティホール自体がいつからあったか不明だが、システム稼働同当時から不具合だとすれば、約12年ほど放置流出していた可能性がある。

これは銀行内部で当該システムの改修履歴調査しない限り、正確にはわからない。

警察から指摘を受けて1週間で修正したそうなので、調査自体はそう難しくないと思われる。

本題 HOW

そもそも何で出会い系サイト運営者の口座だけ被害にあったの?

出会い系サイト運営者の口座は通帳のない特殊な口座(「照合表口」という口座)であり、

それらの口座の場合に、上記の残高照会ダイヤルから不正情報を抜き取れるというセキュリティホールがあった。

入出金が頻繁にある事業者などは、いちいち通帳に記載するわけにも行かないので、こういう口座を使う。

(通帳の代わりに照合表というのが発行される)

まり、抜き取れる情報出会い系サイト運営者の口座だけではなく、照合表口のものは全部抜き取れたということになる。

ただ、通常は振込名義と金額・日時位しかからないので盗んでも大した価値はない。

しかし、出会い系サイト運営者の講座の場合、振込名義の部分にサイト利用者電話番号入力されていたらしい。

この番号に架空請求業者が凸などして実際の被害が出たとのこと。これも上記の増田を参照いただきたい。

まとめると、「出会い系サイト運営者の口座の情報けが流出したのではなく、流出したものの中で出会い系サイトのもの悪用された」ということ。

実際に流出たかどうかはわからないが、出会い系以外の口座の情報も盗もうと思えば盗める状態だった。

…「被害」を「口座の情報が盗まれ状態にあった」とすれば、照合表口の利用業者全てが被害者と言う事になる。書いてて怖くなった。

で、どういうセキュリティホールで、どうやって漏れたのさ

通帳を発行しない口座では、本来は「残高照会ダイヤル」で「(2)通帳に印字されている最終残高」による認証ができない仕様になっている必要がある。

通帳がないのだから当然のこと。

なのだが、どうも上記の照合表口では最終残高として「ある特定数字」を入力すると、本人と認証されてしまう不備があったらしい。

で、この不備を悪用して「残高照会ダイヤル」を通じて情報が盗まれ

この口座への振込依頼人が依頼人名として電話番号記載していたため、「出会い系サイト利用者電話番号」が漏洩することになった。

本命妄想 なにそのセキュリティホール

ある特定数字

「ある特定数字」とはなんぞや、と言うことだが、架空請求業者が頻繁に使用していた(1日数十回とか?)らしいので、

自動応答サービスで一々入力することを考えると、かなり分かりやす数字若しくは短い数字と思われる。

  • 1234567890
  • 1111111
  • 141421356
  • 31415926

とか。

で、SEやっている人ならピンと来るかもしれないけど、

これって、試験用に開発者が使っていた数字じゃなかろうか。

SEじゃない人向けに解説すると、システム開発者プログラム書いてシステムを作ると、正常に稼働しているか試験します。

  • 正しくない通帳残高を入れたらエラーになるか(誤って照会できてしまわないか)
  • 正しい通帳残高を入れたら正しく照会できるか
  • aの条件の時、正しい通帳残高を入れたら正しく照会できるか
  • bの条件の時、正しい通帳残高を入れたら正しく照会できるか

その際に実際のお客様の番号とかを試験に使うわけにはいかないので、試験用のダミー口座を作ったりします。

ただ、試験パターンが何千何万となってくると開発者億劫になるし、ころころ変わる通帳の最終残高を毎回設定するのが大変なので

「通帳の最終残高認証OK時の試験パターンを楽にこなすために、全部の口座で無条件に残高認証OKの番号を用意しよう」という発想になったのではないかなと。

妄想した流れ
  • 正しい動き

照合表口であるYES暗証番号が合っているかYES→照会OK

                      →NO→照会NG

       →NO→暗証番号or通帳残高が合っているかYES→照会OK

                           →NO→照会NG

  • 今回のケース

                            ↓ここで通帳残高の「ある特定数字

照合表口であるYES暗証番号or通帳残高が合っているかYES→照会OK  情報窃取!

                           →NO→照会NG

       →NO→暗証番号or通帳残高が合っているかYES→照会OK

                           →NO→照会NG

まり、以下の2つの要素が組み合わさって、今回の事件になってしまったのではないだろうか、と妄想してみた。


書いてて思ったが、これ通常の口座でも使えていたら、更にエライ事になってたな。

・・・と、最後妄想まで長かったけど、間違いとか俺はこう思うねとかあれば指摘してもらえると一増田としては嬉しいです。

最後に、担当SE達に合掌。他山の石とさせていただきます。いつ、同じような目に自分が遭うかわからないから

参考URL

ITprohttp://itpro.nikkeibp.co.jp/atcl/news/15/113003910/

トラックバック - http://anond.hatelabo.jp/20151202023252

記事への反応(ブックマークコメント)