メールソフト
今日読んだ記事
https://www3.nhk.or.jp/news/html/20250107/k10014687141000.html
カシオ計算機 不正アクセスで8400人余の個人情報流出
その後、会社が外部の専門家などと調査を進めたところ、従業員や取引先、それに顧客の合わせて8478人の氏名やメールアドレスなどの個人情報が流出したということです。
これはもう、一斉にメールアドレスを変えて、関係先に通知するしかないだろうな。
今回の不正アクセスは、従業員がフィッシングメールを開いたことがきっかけだったということで、会社は、専門家のもとでセキュリティー対策を強化するとともに社内教育を徹底して再発防止に努めるとしています。
たぶん、日本では、DDoSを除けば、このケースが一番多いんじゃないか、という気がする。
ところが、相当な知識がある方たちも、メールに騙されたケースがあった、みたい。
https://innovatopia.jp/cyber-security/cyber-security-news/45869/
Chrome拡張機能に大規模ハッキング被害：ChatGPT関連など16個のアドオンで60万人超が影響
Googleからの公式メールを装ったフィッシングにより開発者アカウントが乗っ取られました。
（中略）
拡張機能は通常、ブラウザ内の機密データへのアクセス権限を持っているため、攻撃者にとって魅力的な標的となっているのです。
（中略）
今回の攻撃では、フィッシングメールを使用して開発者の認証情報を窃取し、正規の拡張機能に悪意のあるコードを注入するという手法が取られました。
Chromeの拡張機能を提供する開発者、ということは、どう見ても情報技術のベテランに近い方たちだと思う。そういう人たちでも、騙されるんだ！というのが、驚きというか、ショックというか。
よく言われる「俺は、絶対に詐欺なんかには引っかからない！」と豪語している人ほど騙されやすい、なんだかそれに近い気がする。
私は、疑わしいメールは、必ずソースコードを確認している。説明の順番で、真性のメールから説明する。
このメールのソースコード、以下のようなのがメールの先頭についている。（伏せ字だらけで申し訳ないけれど、読む人が読むと私が誰かバレてしまうので、、、。）
Return-Path: <21-897380-[******** 内緒1 *******************]@cmreturn.nikkeibp.co.jp>
Received: from [******** 内緒2 *******].net ([******** 内緒2 *******].net [AAA.BBB.CCC.DDD])
by [******** 内緒3 ********].net (Postfix) with ESMTP id DXXXXXXXXXX
for <[私のメールアドレス]>; Tue, 7 Jan 2025 11:40:55 +0900 (JST)
Received: from [******** 内緒4 *******].net ([******** 内緒4 *******].net [AAA.BBB.CCC.EEE])
by [******** 内緒2 *******].net (Postfix) with ESMTP id CYYYYYYYYYY
for <[私のメールアドレス]>; Tue, 7 Jan 2025 11:40:55 +0900 (JST)
Received: from cmml016-m1.nikkeibp.co.jp (cmml016-m1.nikkeibp.co.jp [FFF.GGG.HHH.III])
by [********** 内緒4 **********].net (Postfix) with SMTP id BZZZZZZZZZZ
for <[私のメールアドレス]>; Tue, 7 Jan 2025 11:40:55 +0900 (JST)
Message-ID: <C_M_M_I_D.21_19_897380_0_209232.30578.##########@cmreturn.nikkeibp.co.jp>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nikkeibp.co.jp;
s=bpcm20-----; t=17362-----;
bh=0njeaqldAI--------------------+BNVUREgfSDKE=;
h=From:To:Subject:Date:MIME-Version:X-Mailer:List-Unsubscribe-Post:
List-Unsubscribe:Content-Type;
b=ThmcSSbCQEqUsKXhYBqHUuB----------l1EMlbv//zlm3bkl^^^^^^^^^^SiNO/+
/TAF729iJvW0Y----------3oFI3FXe4N/63XXET---------------gC0xqqtyH6a
x0tVmrXz6i6P7----------nVANITeRCC6psf70g=
From: =?ISO-2022-JP?B?GyRCRnw3UBsoQkJQGyRCJWEhPCVrGyhC?= <tgml-nmsys@nikkeibp.co.jp>
To: <[私のメールアドレス]:>
Subject: =?ISO-2022-JP?B?GyRCQCQzJhsoQjM0GyRCPFIkTjU7PVFAb04sISIbKEJFVjI4MBskQjxWPG8kTjtFTU0bKEI=?=
=?ISO-2022-JP?B?GyRCISJGQ0Q5SixATyRyGyhCMRskQjp9JEshWkAkMyYbKEJFVhskQkFtTXchWztvTEwbKEI=?=
=?ISO-2022-JP?B?GyRCJTUlcyVXJWtMNU5BGyhC?=
Date: Tue, 7 Jan 2025 11:40:55 +0900
MIME-Version: 1.0
Reply-To: <cmreturn@nikkeibp.co.jp>
Errors-To: <cmreturn@nikkeibp.co.jp>確認するのは、この８行目、
Received: from cmml016-m1.nikkeibp.co.jp .....の部分。これは、「偽装」できない。 この nikkeibp.co.jp の部分が純正かどうか、よくわからない場合には、以前はそのドメイン名の「評判」や「登録者」を無料で調べるサイトがあった。nikkeibp.co.jp は、繋いで見ればすぐにわかる。（この、疑わしいサイトにつなぐ時のやり方は、後述する。）
20行目の
From: =?ISO-2022-JP?B?GyRCRnw3UBsoQkJQGyRCJWEhPCVrGyhC?= <tgml-nmsys@nikkeibp.co.jp>
これは、ここに記載されている内容がそのままメールのタイトル部分に表示され、このメールの場合には、[日経BPメール]と表示される。
ところが、このFromフィールドには、自由に何でもかける。例えば私が、メールソフトに「アメリカ合衆国大統領ドナルド・ダック」と設定すれば、そのまま表示される。（本物が日本語で自分を名乗るかどうかは別にして、、、。）
次に、偽物の例。メールソフトでは、以下のように表示された。
例えば、このメールの場合、
(1) そもそも、表題の日本語がおかしい。
(2) 本物なら、特にこうしたセキュリティ絡みなら、メールアドレスではなく私の個人名で来ることが多い。
というのは別にして、疑わしい時はソースを開く。
最近、内容のパターン（様式）がちょっと変わった気がする。（以前だったら、この記事を書く気にならなかった。）
Delivered-To: [私のメールアドレス]
Received: by 2002:aaa:bbb:cccc:dd:eee:ffff:gggg with SMTP id l17csp10xxxxxxxxxx;
Fri, 3 Jan 2025 01:44:25 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFQHwSdr7rgD7yzn+QKe7R7WWM**********76wMT3SkpS+zuA**********t7KchaTYrg
X-Received: by 2002:aaa:bbb:hhhh:ii:jjj:kkkk:llll with SMTP id 98e67*****1d1-2f452**********859969a91.11.17358******06;
Fri, 03 Jan 2025 01:44:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=173*****65; cv=none;
d=google.com; s=arc-20240605;
b=(4行省略)
uYfhmVn********w8wSyT/lCBx2RmeKmbc1JsP+o/TJEIOEbZm13**********lh8jeM
glkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=mime-version:message-id:subject:to:from:date;
bh=Wma4QcU/vZggyZyjCGh8BAjjvnPQJ**********O4k0=;
fh=kOSG6//BTyGJUxl6yktYXE4th**********2yO+SUE8=;
b=(4行省略)
1jv+8CLOQXh01+bVdDUv+CHUwNyO78MqE6OM5sZqBDvKjtlqZa**********2yhpaQEi
lHZQ==;
dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
spf=fail (google.com: domain of order-update@amazon.co.jp does not designate AAA.BBB.CC.DDD as permitted sender) smtp.mailfrom=order-update@amazon.co.jp
Return-Path: <order-update@amazon.co.jp>
Received: from [私の使っているメールサーバ] ([私の使っているメールサーバ]. [EEE.FFF.GGG.HHH])
by mx.google.com with ESMTPS id 98e67ed59e1d1-2f44789ad********2072a91.89.2025.01.03.01.44.24
for <私のメールアドレス>
(version=TLS1_2 cipher=ECDHE-ECDSA-******-***-SHA256 bits=128/128);
Fri, 03 Jan 2025 01:44:25 -0800 (PST)
Received-SPF: fail (google.com: domain of order-update@amazon.co.jp does not designate AAA.BBB.CC.DDD as permitted sender) client-ip=AAA.BBB.CC.DDD;
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of order-update@amazon.co.jp does not designate AAA.BBB.CCC.DDD as permitted sender) smtp.mailfrom=order-update@amazon.co.jp
Received-SPF: Fail (SPF fail - not authorized) identity=mailfrom; client-ip=AAA.BBB.CCC.DDD; helo=amazon.co.jp; envelope-from=order-update@amazon.co.jp; receiver=ikuo.kobayashi.t9@hosei.ac.jp
Received: from amazon.co.jp (unknown [AAA.BBB.CCC.DDD])
by [私の使っているメールサーバ] (Postfix) with ESMTP id 789********2
for <私のメールアドレス>; Fri, 3 Jan 2025 18:44:23 +0900 (JST)
Date: Fri, 3 Jan 2025 17:44:13 +0800
From: "Amazon.co.jp" <order-update@amazon.co.jp>
To: <私のメールアドレス>
Subject: =?utf-8?B?44CQ6YeN6KaB44Gq44GK55+l44KJ44Gb44CR44GK5a6i5qeY44Gu44GK5pSv5omV44GE5pa55rOV44GM?=
=?utf-8?B?5om/6KqN44GV44KM44G+44Gb44KT?=注目すべきは、この26行目と27行目。
ARC-Authentication-Results: i=1; mx.google.com;
spf=fail (google.com: domain of order-update@amazon.co.jp does not designate AAA.BBB.CC.DDD as permitted sender) smtp.mailfrom=の部分で、Amazonを名乗っているけれども、実際にはこのメールは gmailから送られていると思う。その google.comが 「このメールは自分が order-update@amazon.co.jpだと名乗っているけれど、そのドメイン側は、AAA.BBB.CCC.DDDを許可された送信元として認めていないよ」ということになるんだろうか。
認証結果が「失敗」と、メールの「宛名書き」部分に書いてある、それなのに、メールソフトはそんなことは表示してくれない。
その理由はなぜか。
https://baremail.jp/blog/2024/03/28/3779/
メールのARCとは？ ARCの仕組み、設定が必要なケースを解説
Receivedヘッダはメールの経路追跡、デバッグ、スパム検出の手がかりとして使用されていましたが、その情報が正しいのか検証する仕組みはないため信頼性が低いという課題がありました。
信頼性は低いにしても、例えば三井住友銀行が .cn（中国）のドメインからメールを送ってくるだろうか、というのは、すぐにわかった。（一般の方には、これは読めないだろうとも思ったけれど。）
少なくとも、ARCを使っていないメールサーバからのメールの場合、逆の例、本物であるにもかかわらず、「このメールは迷惑メールの可能性があります」という検証結果が出ていたケースがあった。某大手自動車会社のエリアメールが、私のところに来る中では代表格かも知れない。
おそらくは、それが「迷惑メールの可能性」を表示できなかった最大の理由かも知れない。
某大手自動車会社を笑えないのは、実は私の会社のwebページも「不正な認証鍵を使っています」と、ブラウザに表示される。というのは、契約しているベンダーさんに鍵の更新を依頼したら、「間違って古い鍵をまたつけて」しまったそうで、「こういう事情なので再設定を」と、海外の認証局に連絡しても、その「事情」そのものを疑われたのか、対応してもらえず、諦めて放置した結果、「不正な認証鍵」のままになってしまった。国内ではかなり有名なベンダーなのに、担当者が暗号鍵の扱い方を知らなかったとしか思えない。（そういうメールのやりとりがあった。）5年くらい前かなぁ。もう、ベンダーが信じられなくて、自前でサーバ管理をやるぞ、と思いながら、学校の授業の準備だの、受注した案件の開発などで忙殺されて、放置したまま。紺屋の白袴。
話を戻す。
それでも、こうした「検証結果」を受信側のメールソフトでも全面に表示することで、フィッシングメールが一目でそうだとわかるようにして欲しい気がするのだけれど。
私自身、「ちょっと疑わしいメール」が入った際に、いちいちヘッダを読まなくて済むのでありがたい。ましてや、コンピュータの専門家でない方にとっては、「明らかな偽物」については、そうした表示が必要ではないか、という気がする。（Macメールは「迷惑メールの可能性」の表示が出る。）
上記に引用したサイトにあったけれども、もっと多くのメールサーバがARCを導入し、メールソフトも積極的に「このメールは、詐欺メールの可能性があります」というのを、もっと表示すべきではないか、と思う。豪雨災害の際の避難情報への対応に近いかも知れない。「迷惑メールじゃないかも知れない」可能性があっても、念の為、「迷惑メールの可能性があります」と表示する。それくらいのことをしないと、冒頭にカシオ計算機と、Chrome拡張機能開発者のニュースを引用したけれど、なんだか「プロ」ですら騙される現状には対処しきれないかも知れない。
ちなみに、私は、今はMacで仕事をしているけれど、Windows機が普段使いの業務処理マシンだった時は、メールは、VMwareという仮想コンピュータを設定して、Linuxの仮想マシン上で処理していた。
仮想マシンでは、メールやブラウザのアクセス履歴以外の「データ」は、何も持っていない。だから、スクリプトが走ろうが、ウィルスを注入されようが、全く怖くはなかった。
最近、MicrosoftがWindows 11で、WSL(Windows Subsystem for Linux)を出してくれているけれど、メールソフトやブラウザで、積極的に「仮想OS」のサブシステムを利用するのは、リスク回避の一つの方法かも知れない。
つまり、メールソフトがスクリプトを含んでいる場合、「メールを表示する」のは、バックグラウンドで走らせたLinuxなどのサブシステム上で、そのファイルシステムを一旦切り替えて実施して「こういうファイルと、こういうファイルにアクセスするスクリプトがこのメールには含まれていますが、実行しますか？」という確認をする。ユーザがOKしたら、ホストOSというか、実際のマシン上で実行する。
こういう方法は、できるのではないか、と思う。（普通、メールにスクリプトが含まれる方が稀だから、ほとんどのケースで問題にならない程度の気がするけれど。どこかのURLからリソースを読み込むだけなら、鬱陶しいメッセージも出ないはず、だと思うし。）
同様に、ブラウザでアクセスした先で、web ページに含まれている scriptを実行する際にも、一旦「仮想マシン」上でスクリプトを実行して、「このwebページには、これこれ、こういうファイルにアクセスするスクリプトが含まれています」という表示を出すことは、可能ではないか、と思う。
画像などをアップロードする場合には、ブラウザからリアルなディスク内にアクセスする必要があるけれど、その場合にはHTMLのタグが限られているから、見分けがつく。
などと考えてみた。
まだまだ、メールソフトや、ブラウザの開発者側でできるセキュリティ対策はあるような気がする。
それにしても、またしても、か？
https://www3.nhk.or.jp/news/html/20250107/k10014687191000.html
りそな銀行 個人向けネットバンキングで不具合 サイバー攻撃か
本当に、日本でも公的機関にもっと本腰を入れて「対策」を練ってもらいたい気がするけれど、、、。そういう無理は求めないとしたら、、、。
例えば、DDoS攻撃を受けた会社から、その時のアクセスログを10万円とか50万円とかで買い取って、アクセスログを分析する。そこから、botのIPアドレスを抽出して、IPアドレスのブラックリストを作成する。ブラックリストを頻回に更新するサーバを立ち上げて、その「ブラック・リスト・サーバ」からリストを更新するAPIというか、モジュールをgithubなどで提供し、ブラックリストのサブスクリプションを、年間契約で1万円とかで提供してくれるなら、ドケチの私でも1万円なら契約するかも知れないし、顧客にも勧めると思う。
停電が起きたり、電車が止まったりするくらいなら、対策費用を公益法人とかに税金から流してもらっても、私は全然問題ないというか、是非そうして欲しいのが本音だけれど、日本の場合には、「迷惑メール」を通報すると、通報した私が「迷惑メールの送信者扱い」されてしまったり、ぶっちゃけ、情報技術は三流国という気がする。
と考えてくると、どっちみちすでに日本はデジタル赤字数兆円、という国なのだから、こうしたセキュリティ対策も、海外の会社依存であっても構わないかな？その結果、デジタル赤字が十数兆円とか、二十数兆円とかになっても、仕方ないんじゃないか、という気がする。インフラが止まるよりもマシだと思う。
三流国の下は、なんなんだろうか。「日本、そっくりさん国家」か？その下は、「存在する価値なし国家」になるのか？
（Daigoさん、鬼龍院翔さん、ごめんなさい。カンガルー肉、おいしいと思います。）
「映す価値なし」降格のGACKT、DAIGOと鬼龍院翔に「謝るな」 ファン感激「このメンバーでリベンジを」
長くなった。
以上