■「銀行から１万４０００件の情報流出」をシステム屋目線で妄想したい

http://anond.hatelabo.jp/20151201162600

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

前提

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

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

誰の情報が流出したの？ WHOES

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

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

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

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

どこから漏れたのよ？ WHERE

「残高照会ダイヤル」から。

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

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

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

• 「（1）キャッシュカードの暗証番号」
• 「（2）通帳に印字されている最終残高」

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

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

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

誰が盗んだの？ WHO

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

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

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

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

ということらしい。

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

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

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

セキュリティホール自体がいつからあったかは不明だが、システム稼働同当時からの不具合だとすれば、約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つの要素が組み合わさって、今回の事件になってしまったのではないだろうか、と妄想してみた。

• 1)本来無効化すべきであった試験用の「ある特定の数字」が照合表口の場合は無効化されずに残っていた（試験データの消し忘れ）
• 2)本来照合表口であれば暗証番号のみ判定すべき所を通帳残高もor条件にしていた（条件分岐のミス。通常の口座と同じIF文通ったんでね？）

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

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

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

参考URL

ITpro：http://itpro.nikkeibp.co.jp/atcl/news/15/113003910/

Permalink | 記事への反応(2) | 02:32

ツイートシェア