公式サイト乗っ取り事件から考える教訓

ドメインの管理や申請プロセスには落とし穴があった。光明に脆弱性を突いた事件を目の当たりにして、システム管理担当者がセキュリティの在り方を考える

2019年4月5日、それは突然の出来事だった


ラブライブは我々が頂いた!

 

我々がラブライブを入手する際、

手の込んだプログラミングを行ったり

こっそりとデータを傍受したりする必要はなかった

 

我々の方法は、移管オファーを行い元所有者が移管オファーを承諾しただけだった

元所有者はこれだけあっさりと、ラブライブを我々へと移管してしまった

 

これは当日、アニメ「ラブライブ」公式ページを開いた時のトップページ。

世界的に閲覧者の多い公式ページが、一夜にして乗っ取られる事件が発生した。

 

最終的にホームページの安全宣言が出されたのは、2019年4月11日。

通常の運用に戻すまで6日を要したことになる。

 

システム管理者として、時間と対応に追われるウェブ担当者の心中を察する事件だった。

原因は?

ウェブサーバーへの不正アクセスや侵入が原因となることが多いが、今回は、申請・管理プロセスの問題を突いた計画的なものだった。

 

申請者(加害者)がレジストラ(仲介業者)を介して、レジストリ(管理会社)に移管手続きをおこなう。レジストリは、更新前に別のレジストラを経由し、登録者(被害者)に確認を促すといったプロセスを踏んだとされる。

 

この確認作業の中に、「10日以内に登録者がその意思を有しない旨を回答しない場合、承諾があったものと見なす」というルールがあり、結局期間内に連絡が無いまま乗っ取りつながったようだ。

更なる懸念

もう一つ、この事件のプロセスで懸念する点は、メールの回答を承認作業としていることだ。

昨今、下記のような精巧なフィッシングメールが多く送られてくる。


Amazon お客様

 

残念ながら、あなたのアカウントAmazonを更新できませんでした。

これは、カードが期限切れになったか、請求先住所が変更されたなど、さまざまな理由

で発生する可能性があります。

アカウント情報の一部が誤っている故に、お客様のアカウントを維持するためAmazon情

報を確認する必要があります。今アカウントを確認できます。

 

 

Amazon ログイン

 

なお、24時間以内に確認がない場合、誠に遺憾ながら、アカウントをロックさせていただ

くことを警告致します。

 

アカウントに登録のEメールアドレスにアクセスできない場合

お問い合わせ:Amazonカスタマーサービス。

 

どうぞよろしお願いいたします。

Amazon


自分が申請した訳でもない確認メールが届いた時、果たして正しい判断が出来るだろうか。迷惑メールと勘違いしたり、フィルタリング機能で迷惑フォルダに振り分けられたりして、本人に正しく届かない場合もある。

 

それ程メールという手段は、本来、不果実な手段であると考えるべきだと思う。

技術を生かすには

IT技術は日々進化し、ネットワークの高速化や端末性能の向上により、何処でも情報が手軽に得られ、ウェブ上で契約作業も完結出来る。

しかし、それら技術を有効に扱うには、事前にマスタ情報とプロセス基盤の確立が不可欠だと考える。

 

今回の事件は、企業存続している以上、他人事ではない。

テクダイヤで基幹システムやプロセス構築をおこなう時に、私はいつもこう話す。

 

「プロセスの原則は紙で流せる業務にすること。ツールはプロセスの補助であり、応用プロセスは、基本を理解してから整理すること」

 

技術だけでなく、優れた企業力を発揮するためにも、まずは自分が管理している項目(マスタ)と手順(プロセス)を明確にして、日々の環境変化に合わせたPDCAを回せるよう、今一度確認してみてはどうだろう。

 

今回の事件は決して許されるものではないが、無理やりポジティブに考えるならば、これから更に複雑化するネットワーク環境に対して、一石を投じられ、制度の見直しの必要性を再考するきっかけとなるかもしれない。

コメントを残す

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)