Microsoft Outlookがアドレス帳に登録された正規ドメインと似た字形の文字を使ったフィッシングドメインを区別しないという報告 40
ストーリー by nagazou
差別も区別もしないYO 部門より
差別も区別もしないYO 部門より
headless 曰く、
Microsoft Outlook が IDN ホモグラフ攻撃によるフィッシングドメインを正規ドメインと区別しないという 2 件の報告が相次いで公開されている (報告 1、 報告 2、 Ars Technica の記事、 Windows Central の記事)。
IDN ホモグラフ攻撃は国際化ドメイン名 (IDN) で利用可能な ASCII 外の文字でラテン文字と似た字形の文字をドメイン名に用い、(なりすましの対象となる) 正規ドメインに偽装するものだ。フォントによっては全く同じ字形で表示されるため、人の目で識別することは困難なこともある。ただし、ソフトウェアが騙されることはないと考えられていた。
しかし 2 件の報告によれば、Outlook ではホモグラフ攻撃によるフィッシングドメインからの電子メールを受信した場合かつ、その正規ドメインで同じユーザー名の連絡先がアドレス帳に登録されている場合、フィッシングメールを既知の正規ドメインから送られたものとして表示するのだという。つまり、アドレス帳に登録されている連絡先の写真などがフィッシングメールに表示されることになる。
Microsoftはいずれの報告に対しても「なりすましが発生する可能性があるにしてもデジタル署名なしに送信者を信頼することはできない」「修正を行えば別の問題を引き起こす可能性が高い」などとし、修正は行わないと回答したという。ただし、8 月 24 日の時点で最新版の Outlook バージョン 16.0.14228.20216 では問題が発生しなくなっていたようだが、Microsoft は修正の有無を回答しなかったとのことだ。
お節介選手権 (スコア:2)
電子署名を勝手に除去してくれる某キャリアメールvs似た文字を勝手に置き換えてくれるOutlook
メールサーバで全部済ませてくれると言うのは効率的にも端末の消費電力的にもありがたいが、DMARCすら色々な運用上の難しさから普及していないのに、こんなことされてもね…。
Re: (スコア:0)
相手先のOutlookが改行削除する機能を無効にしていないと
話が通じなくて本当に困る
マイクロソフトのメーラーの伝統的な挙動 (スコア:2, 参考になる)
いまさら頭おかしい挙動の一つや二つ増えたところで驚くことではない。
Re: (スコア:0)
そういやMicrosoft Internet Mailの時代からマイクロソフトのメーラってイカれた仕様ばかりだったよな。
すげー実装だ (スコア:1)
フィッシングドメインからのホモグラフ電子メールアドレスと
アドレス帳のホモグラフ対象メールアドレスとを
文字列判定をせず
画像判定しています
ってことなんですかね？
# なかのこびとさんもたいへんだんだよー
Re: (スコア:0)
「もしかして？」機能なんだろうか。
# 小さな親切大きなお世話（オートコンプリートとか自動文字/単語置換とか）の一環？
Re: (スコア:0)
正規化処理を挟んでるんじゃないかと思うけど、なぜそこに入れた? という疑問が。
Re: (スコア:0)
そりゃ、例えば日本だとメールアドレスを全角で登録するような人がいるから、でしょ。
Re: (スコア:0)
ん？
Outlookだと全角でメールアドレス入れても届くのか？
それはそれで問題なんじゃ・・・
Re:すげー実装だ (スコア:1)
IDNのNameprepってそういうもんだよ。
Re: (スコア:0)
ひぇ～。
あれって、ドメイン名に適用されるものと思っていたのにメールアドレスにも適用されるんですね・・・。
https://www.nic.ad.jp/ja/newsletter/No33/080.html [nic.ad.jp]
Re: (スコア:0)
たとえメールアドレスに全角を入れたとしても、よく似た文字を使った別のメールアドレスを同じものとして扱う必要は一切ないんだが。
同一視するのがうれしいケースがあるとすれば、手入力した文字列でメールアドレスを検索するときくらい。
文字列検索用のロジックをメールアドレスの同一判定にまで適用する意味があるのはどういう時なのか知りたい。
Re:すげー実装だ (スコア:2, 参考になる)
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。だから、校合はともかく必要なの。
で、受信者の正規化のアルゴリズムと送信者の正規化のアルゴリズムが違っている場合は、このストーリーみたいな話が起こりうる。手書きとかOCRとか、そういう問題ではないと思うよ。
Re: (スコア:0)
必要なのはそうだけど、どうなってたら一致と見做すかはメールの規格で決まってるんだから、それ用のアルゴリズムを使ったら良い話ですよね。
やり方は、メールサーバを作ったことがあるような企業だったらどこでも知ってるはず。
あるいは元々そうしてたけど、アホなユーザから「アドレス帳に(全角英数字で)入れてるのが候補に出ないんだけど!」とクレームが来て、
ユーザ本位な企業体質から言われるままに対応しちゃったとかですかね。
…それよりは、最初からメールアドレスの仕様も何も考えず、
とりあえず何かやるときは使うことになってる「アプリ組み込みタイプのAccessDBライブラリ」をそのまま持って来ちゃってて、
その万能過ぎる検索性能のせいでやらかす仕様になってたのが後々問題になって来た、という方がありそうですかね。
Re:すげー実装だ (スコア:2)
まぁこの件はMSの実装がオカシイだけですね。
なんというか iso-8859 系話者は case-insensitive な文字列比較が好きなんだけど、
それと同様に似た文字を合致させる(ウムラウトを無視してヒットさせたりする）
機能をドメイン名にまで何も考えずに適用してしまっているんでしょうね。
Google検索でもウムラウトとか無視して検索してくれますからね。
我々みたいなウムラウトってどうやって入力するんだ、
みたいな人からすると便利っちゃあ便利な時はあるんだけども。
個人的にこれ系の実装でいままで一番びっくりしたのは寿司＝ビール問題とかよりも
Oracle のパスワード比較で case-insensitive だったところですね…
[Q][W][E][R][T][Y]
Re: (スコア:0)
ウムラウトならまだ見て分かるが、ギリシャ文字のοとかキリル文字のоとかになると、本当にラテン文字のoと区別がつかないからね。
Re: (スコア:0)
Oracle使うユーザーは昔のやつ一切手を入れずそのまま動かせるのが条件みたいなのが多いから…
一文字でも変更必要だと、それにかかる費用を請求するから担当呼べ！とマジで逝ってると思えるヤツも実際いたし。
Re: (スコア:0)
セキュリティ的な問題を無視して互換重視みたいなのは設定で切り替えできるようになってると良いな。
Re: (スコア:0)
向こうからすると、「へ」「べ」「ぺ」と「ヘ」「ベ」「ペ」は違う文字だ！と信じている日本人のほうがクレージーに見えたりして。
Re: (スコア:0)
↑かいてるうち関連リンクの
メルぺイが一部加盟店で利用制限へ。フィッシングメール急増のため
が変だと、いま気づいた。
Re:すげー実装だ (スコア:1)
Oracleについては、いまはそうなってますね
[Q][W][E][R][T][Y]
Re: (スコア:0)
シ ツ ン ソ みんな同じじゃないですかー
Re: (スコア:0)
英語圏でもAとÄ Â Åは同じだと思われてるんじゃないのか
Re: (スコア:0)
送信者なんていくらでも偽装できるのだし
送信者がアドレス帳にある人と同一だと判定しなければならない理由がいまいちわからないなぁ。
勝手に表示を省略して変更しちゃう機能が邪魔だとしか思えないんだけど、
どんなメリットが有るの？
# あれ一度間違ってキャッシュされると、なんかコマンドでクリアするんでしたっけ？
Re: (スコア:0)
日本だとそう多くはないのだが、ラテン文字圏だと、似たような名前や同姓同名が結構いる。間違えても社内ならまだいいが、社外だと洒落にならんことがある。そういう間違いを防ぐために、アドレス帳の顔写真の代わりに会社のロゴを登録しておくと、少なくとも送信者は瞬時に判別できる。当然のことながら、稚拙な偽装アドレスも見抜ける。
もちろん、偽装されている可能性はあるけど、アカウントを乗っ取られていることもあるし、乗っ取りや偽装がなくても送信者の不注意による危険なメールの転送もあり得るから、基本的には本文や添付ファイルの形式・サイズなどの妥当性で判断するしかない。
そして、メールアドレスを精査するのは、怪しいと判断したときだけ。メールアドレスだけで判断できる眼力は俺には無い。
Re: (スコア:0)
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。
Gmail の . の扱いに対応しなきゃとか、色々あったのかも知れませんね。
Re: (スコア:0)
よくあるURL検知避け対策でしょう。
わざわざ "https://www．example．org (ドットは半角に置き換えてね)" のように書いたりするアレへの対策です。
Re: (スコア:0)
マイクロソフトは、全角カタカナと半角カタカナを区別するかどうかの挙動をバージョンアップで変更したり、
全角英数字と半角英数字でもおなじく挙動をバージョンアップで変更したりされたことがあったので、
びっくりしたことがある
Re: (スコア:0)
Explorerの検索ボックスで ~= が部分一致なんだけど、～＝ でも部分一致で、MSには強烈に頭おかしい人がいるんだなとは思ってた。
いつもの康煕部首 (スコア:1)
srаdとsradの⾒分けがつかないバカには、どうせ⾺⿅と馬鹿の⾒分けもつかないから、もういっそ一緒くたにしてしまおう、いい加減人力に頼るのはやめよう、というMSからのありがたーいメッセージだね。#ただし環境による
Re:いつもの康煕部首 (スコア:1)
srаdとsradの⾒分けがつかないバカ
ごめん、よーわからんわ。
$ w3m -dump 'https://srad.jp/comment/4110360' | grep srad | cut -c 5-16 | hexdump -c
0000000 s r 320 260 d 343 201 250 s r a d \n
000000d
Re: (スコア:0)
グリフが全部入っていない文字フォントを優先して使ってたりする
ビンボーくさい環境だと見分けがつきやすい。
つまり、
1. 古いJISの範囲のみ日本語フォント
2. フォールバック用の汚いunicodeフォント
とかすると、汚い字が出てくるのでわかる。
「⾺⿅と馬鹿」のところも違う。
Re:いつもの康煕部首 (スコア:1)
なるほど
cmd.exeにコピペしてみた
＃Windowsコマンドは頭がいいな
Re: (スコア:0)
ブラウザでページ内検索すると、片方しかヒットしないので、それでも確認できますね。
目一杯拡大しても、当方の環境では同じ文字としか見えませんが。
どうでもいいが (スコア:0)
なりすましってミズスマシとちょっと似てる
Outlookの陥し坑 (スコア:0)
・2019以降、使用環境が決め打ちっぽくなって設定が効きにくい
https://www.ikt-s.com/outlook2019-old-accountset/ [ikt-s.com]
・送信した添付ファイルがwinmail.datという謎データに化けることがある
https://support.microsoft.com/ja-jp/topic/%E3%83%A1%E3%83%BC%E3%83%AB%... [microsoft.com]
・送信メールの控えが残らないことがある
https://answers.microsoft.com/ja-jp/msoffice/forum/all/outlook2019/000... [microsoft.com]
# 久々に検索したら、対処法もまた変わっているようだ
Microsoftだし (スコア:0)
Excelのvlookupと同じ関数でマッチさせてるのでは。
# デフォルトの近似一致を使う場面がどれだけあるのかと
Re:Microsoftだし (スコア:1)
この一週間、VLOOKUPで派遣の女の子にさんざんいぢめられたので今日はもう寝る。
Re: (スコア:0)
なんてうらやましい・・・・・・・！
Re:Microsoftだし (スコア:1)
WindowsNT3.51かWindows2000の頃の話題だけど、
「日本語検索では濁点半濁点の有無を区別しない」って仕様で、その結果「ハハ」「パパ」「ババ」を同一視するっていう……ウムラウトとかと同じ扱いをしたんだな。
「シャム猫」と「ミートソース」なんていうちょいとアレなジョークもありましたっけ。