ドコモ口座不正引き出し事件

投稿者: | 2020年10月4日
LINEで送る
Pocket
このエントリーをはてなブックマークに追加

(個人的な備忘録 兼 現実の事件をロジック図解してみるシリーズ。あ、シリーズになるかどうかはわかりませんが)

先日起きたドコモ口座をめぐる預金の不正引き出し事件について、NHKのWebに図が載っていました。

しかし、これだけだとイマイチよくわからなかったので、自分であれこれ調べて書いてみた次第です。

【参考にしたサイト】

そうすると、だいたいこんな感じですか。(間違いや説明不足があったら教えてください)。

  • ①「攻撃者」は まず被害者Aさんの銀行口座(本物。以下、真正口座と呼ぶ)の情報をなんらかの手段で入手。
  • ②AさんになりすましてAさん名義のドコモ口座を開設(Aさん自身は知らない口座。以下、不正口座と呼ぶ)。
  • ③真正口座と不正口座をひもづける(連携させる)。
  • ④その後、ドコモ口座に対して銀行口座からの入金を指示すると
  • ⑤ドコモ口座から銀行に対して口座振替依頼が行われ
  • ⑥既に③で連携が済んでいるので銀行はそれに応じて出金をしてしまう

さて、こんな構図の中でどこに問題があったと言われているかというと、

問題1:②のドコモ口座開設のハードルが低かった。もともとはドコモ回線契約者のみに提供されていたサービスで、回線契約時に本人確認が行われていたが、その縛りをなくした際、メールアドレスのみで開設可能になっていた。

問題2:③の銀行口座ひもづけの際の認証が弱く、銀行によって異なるが実質的には暗証番号のみで認証が行われていたケースもあった。暗証番号は実店舗のATM端末に足を運んでキャッシュカードを使うというハードルがあったから数字4桁のみの「弱い認証」で通っていたものであり、Web口座振替の認証をそれに頼ってはいけなかった。

問題3:攻撃者が何らかの手段で暗証番号を含む口座情報を入手していた。これについてはフィッシングサイトやリバースブルートフォース等いくつかの仮説が疑われている段階。

以上3点についてはこの攻撃を可能にしてしまった直接の原因(問題)ですが、もう一つその背景にあるのではないかと指摘されているのが、「記事1」にあるこの問題です↓

問題4:⑤で使われたWeb口座振替というのはもともとは公共料金等の事業者向けのサービスであり、「事業者が金額を計算して請求してくる」というハードルがあったため不正は起きづらく、弱い認証でもなんとかなっていた。しかしそれを④のような「個人が出金指示を出せる」サービスと連携する際に銀行とドコモの間で意識ズレがあり、認証の弱さ(問題1,2)が放置されてしまった。

……とりあえずわかったのはこんなところですね。

以下、ロジック図解的観点で、図を書くときに注意した事項を追記します。

↓次ページへ(ページ番号をクリックしてください)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください