MNPで携帯電話を乗っ取りSMS認証を突破される

さっきまで使えてたスマホ、通話音が…しない 勝手に解約されたかも 被害男性の証言

偽造運転免許証をもちいて携帯電話のMNPを申込みんで携帯電話を乗っ取り、オンラインバンクのSMS認証を突破されてしまうという問題が多数発生しているらしい。記事の中でも「パスワードを使い回さないなど、やはり個人の対策が重要だ」と書かれているとおり、一番の問題はパスワードを適切に管理出来て居なかった事にある。

SMSを使用した多要素認証は、NIST(米国立標準技術研究所)でも条件付き推奨としている。推奨するための条件は、「他の認証方式と併用すること」「代替の認証方法を用意すること」「危険性の評価し公表すること」三つだ。SMSは電話会社での管理が適切である事を前提としており、技術的あるいは社会的方法で容易に突破されうる事が分かっているからだ。

SMSは攻撃に弱い認証方法であるという前提を理解して、正しくパスワードによる認証を使う事が大事です。「サービス毎に異なるパスワードを使う」「パスワードはランダムな文字列にする」「前述二つを実施するのはパスワード管理ツール無しでは無理なので、適当なツールを利用する」の三点をしっかりまもろう。

そしてエンジニアもSMS認証は弱いと言う事をちゃんと認識してサービスを設計しよう。

PPAP問題はパスワードをメールで送るのを止めても解決しない

PPAP(パスワード付きZIPファイルと、そのパスワードを別送する)が無意味どころか、むしろ危険を増している事がようやく認識されるにいたった。だが、もう一つの問題、そもそもZIP2.0暗号方式を使って暗号化することの無意味さが知れ渡っていないようだ。

ZIP2.0暗号方式には計算量的脆弱性があり、比較的少ない計算量で総当たり攻撃をおこなえることが知られています。ハイエンドGPU(RTX 2080Ti 価格20万円程度)を4枚搭載したパソコンを使用すれば、15桁のパスワードでも15時間程度で解読できてしまう事が報告されています。ということは文字数を増やして16文字にすれば56日となるかというと、これ以上パスワードの文字数を増やしても解読に変わる時間は延びません。内部的に96bit(15文字程度)の状態しか持てないため、これ以上パスワードを長くしても意味が無いのです。

ZIP形式のファイルはこの問題を解決するために、今ではAES方式暗号に対応しています。ですが、Windowsが標準ではAES方式のZIPファイルに対応していないために、利便性を優先してZIP2.0を使用する事が常態化しています。セキュリティは利便性とのトレードオフになる事が度々ありますが、利便性を優先して実効性のない暗号方式を採用し、そのために無駄な作業や別の危険を増やすのは本末転倒でしょう。

暗号化したファイルのパスワードをメール以外・・・例えば電話で伝えるのは進歩です。でもZIP2.0形式を使い続けるなら、そこに実効性はありません。利便性と実効性を考えたなら、素直に暗号化などせずに添付して送るのが一番良いでしょう。

ではどうすれば良いのでしょうか?私がお勧めするのはメールを使用しない事です。メールの根本的なセキュリティ問題は認証機能が無い事にあります。そこで認証機能のしっかりしているSNSなり、Google Drive等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。

セキュリティ上、メールサーバーはどんなサービスを利用すべきか。

業務上使用しているメールサーバーのセキュリティについて考慮したことがあるだろうか?実態として問題なく利用できるメールサービスは限られている。

セキュリティ上、パスワード漏洩等のインシデント発生時に被害の程度や範囲を特定する必要がある。このためには最低限でもPOP/IMAP/SMTP/WebMailの認証ログを閲覧し不正な接続の有無や接続元を特定する必要がある。だが実態として認証ログを閲覧出来る事が明記されているメールサービスは少ない。

サービスを提供する事業者は第三者間の電気通信を中継している都合、電気通信事業者とてし法律の制約を受ける。そこには通信の秘密を守る義務が含まれており、通信相手の接続元などの情報を提供することが出来ないためだ。

自社でメールサーバーを運用するのであれば、電気通信事業法上の制約を受けることなくログを閲覧出来る。かといってメールサーバーの運用には多くのノウハウがあり、中小企業でメールサーバーを運用できる技術者を確保する事は難しい。

以下にセキュリティ上の認証ログを閲覧出来るメールサービスを例示しておく。色々と探したのだが、三つしか見つけることが出来なかった。

Google Workspace
Microsoft 365
カゴヤ・ジャパン株式会社 メール専用サーバ

番外として下記も紹介しておく。認証ログを閲覧する事は出来ないが、代わりに接続元IPアドレスを制限する事が出来る。境界型セキュリティで安全を担保する前提であれば、接続元IPアドレスを制限したり、代理サーバーを介在させたりすることで、同様の要件を満たす事はできる。
WebArenaメールホスティング

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

DELLのセキュリティー事件簿

元記事:実態調査が示すセキュリティー事故の最新動向

DELLのもうちょっと良い事例は無かったのだろうか?
インシデント(セキュリティー事故)が発生するのは仕方ないにしても、あまりにも稚拙な対策が混じっていて失笑を禁じ得ない。

CASE1、CASE2・倫理観低下が招いた事故

論理感等という曖昧なものに原因を求めてはならない。分からない言語のメールだからそれを無視したり、業務効率向上の為のチャットソフト利用を拒絶する事が、論理感の高い行動とは言わないだろう。

根本的な原因は、恐らくはリスクのある外部サービス利用に対する過度な制限や、外部サービス利用承認プロセスの不備、ネットワーク利用状況の監視体制の不備にあると推測する。下手な利用制限がかかっていなければメジャーな翻訳サイトを避けて稚拙な翻訳サイトを使ったり、適切な監視がなされていればチャットソフトの利用に気がつかないと言うことはないからだ。

制限、許可、監視のバランスがとれていないことが根本の原因にあるなかで、制限だけを増やすのは問題の解決には至らない。制限を回避する新たな方法を編み出すようになり、従業員との信頼関係が損なわれる結果が目に見える。

CASE3・CASE4・ランサムウェアに感染

そもそもバックアップを取れていないことが致命的に問題だ。バックアップがとれていればデータが失われても1日分程度の話しであり、データを失うと言う致命的事態には陥らない。バックアップは一般ユーザーの権限ではアクセス出来ない(最低限で書き込めない)場所に、過去4~5日分(気がついたときには上書きされていたら意味が無いので、夏期休業などの最長休業期間より長い日数分)をバックアップしていれば良い。

標的型メールを模倣する訓練において開封率の低下を目指すことに意味は無い。本来なら開封した場合のエスカレーションが確実に行われることや、開封によって感染したことをセキュリティ監視チームが発見できる事が重要になる。なぜなら100人中1人でも開封すれば被害に繋がるし、またどんなに訓練を重ねたところで、文面などから完璧に不正なメールを判断するのは不可能に近いからだ。

CASE6・CASE7・基本的な対策を怠った

CASE6のすべてのPCのOSを最新に するのは確かに必要な処置だろう。だが起こった問題「商談情報を撮影して個人のPCにメールで送ったりしていた」に対する対策としては「機密情報の撮影を禁止」と言うルールを設けただけである。いかにルールを作っても、ルールが守られていることを監視監督する等の運用面が苫なわなければ、仕事のためにルールを無視する事が必ず起こる。

CASE6の根本的な原因は、メールの送信先や送信元に対する監視が機能していない事にある。個人で取得していると思われるメールに対する送信だけでも監視していたなら、問題が発生する前に警告する事が出来たはずだ。

CASE7についてはログが無い以上、今後調査が進展する可能性もない。「漏洩した情報を特定できない」という報告をする以外にない。