はじめに
SPF, DKIM, DMARCと調べましたが、すっかり忘れてしまいましたので復習です。
最近の迷惑メールで、DKIMだけ通っているメールがありましたので、
DKIMだけではなぜダメかもあわせて確認していきます。
DKIMの復習
送信者がキーペアを作る。
送信者はDNSに公開鍵を置く。
送信者はメール送信時、メールのいくつかの情報を秘密鍵を使って暗号化し電子署名としてヘッダに付ける。
受信者はDNSから公開鍵を取得する。
受信者は公開鍵を使い、メールのいくつかの情報と電子署名を復号化したものに差分がないか確認して改ざんを検知する。
迷惑メールの紐解き
ここでは、下記のようにアドレスを置き換えてヘッダを読み解いていきます。
自分のメール:hogehogenohoge@yahoo.co.jp
Return-Pathのメール:hogehoge@ayashiidomain.com
Fromとして悪用されたメール:hogehoge@yabaikamo.jp
(なおayashiidomain.com, yabaiykamo.jpは2022/12/29現在取得されていないドメインです)
さて、迷惑メールの内容ですが、本文は○○銀行からのご案内でした。
Return-Pathも、悪用されたメールも、○○銀行には似つかわしくない者で、
迷惑メール（フィッシング）だという事がわかります。
DKIMがPassしているよと、Yahooが教えてくれたのですが、
それはドメイン:ayashiidomain-com.20210112.gappssmtp.comがPassしているという内容でした。
Googleのサーバー(gappssmtp.com)から送られてくるメールのDKIMは改ざんがなかった、ということですね。
想像ですが、DKIMを通すためだけにGoogleを中継させたのではと踏んでいます。
素人からしたら「DKIMがPASSしている」というだけで大丈夫カモの1つの材料になってしまうのでは？
Yahoo!Japanはもう少し表記を考えたほうが良いのでは？と心配してしまいました。
余計なお世話ですね。
さて、届いたメールのヘッダを上から見ていきます。
1: X-Apparently-To: hogehogenohoge@yahoo.co.jp; Wed, 28 Dec 2022 XX:XX:XX +0900
自分のYahooメールに届いたものです。
2: Return-Path: <hogehoge@ayashiidomain.com>
あやしいドメインがReturn-Pathになっています。
3: X-YMailISG: (署名情報)
Yahooにより付与された署名がありますね。これがないと内部的に転送されないのかも。
4: X-Originating-IP: [209.85.216.99]
Yahooがつけたヘッダでしょう、送信者のIPです。調べてみるとGoogleでした。
YahooのMTAから見てこのIPから届いていることがわかります。
5: Received-SPF: none (mail-pj1-f99.google.com: domain of hogehoge@ayashiidomain.com does not designate permitted sender hosts)
これもYahooがつけたヘッダでしょう。
SPFのnoneは、Return−Pathにあるayashiidomain.comにSPFレコードがないためmail-pj1-f99.google.comが送信元として正しいか検証ができないことを示します。
6: Authentication-Results: mta7003.mail.djm.ynwp.yahoo.co.jp
YahooのMTAによるメッセージ認証のヘッダフィールドの結果です。
from=ayashiidomain.com;
fromはあやしいドメインとなっています。
domainkeys=neutral (no sig);
domainkeysはneutral/no sigなので、DomainKeys-Signatureがヘッダになかったとのこと。
dkim=pass (ok);
dkimはpassなので署名の検証は成功。
header.i=@ayashiidomain-com.20210112.gappssmtp.com;
header.iから、送信元ドメインがGoogleのSMTPだったことがわかります。
同時にDKIMの署名の検証に使われた公開鍵は、_domainkeys.ayashiidomain-com.20210112.gappssmtp.com にあることがわかります。
dmarc=none;
dmarcはnoneなので、おそらくDMARCポリシーが設定されていないことを示していると思われます。(_dmarc.ayashiidomain.comか_dのTXTレコードに無い）
header.from=yabaikamo.jp
メールヘッダのFromには、全く異なるやばいかもしれないjpドメインが指定されていたとのこと。
参考資料
DKIM 9.認証結果のヘッダへの表示(一般財団法人インターネット協会)
rfc8601(tex2e.github.io)
7: Received: from 124.83.142.69 (EHLO mail-pj1-f99.google.com) (209.85.216.99)
by mta7003.mail.djm.ynwp.yahoo.co.jp with SMTP; Wed, 28 Dec 2022 XX:XX:XX +0900
YahooのMTAがGoogleのSMTPから受け取ったことを示します。
GoogleのSMTPは自身をmail-pj1-f99.google.comときちんと名乗っています。
8: Received: by mail-pj1-f99.google.com with SMTP id c8-20020a1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.5
for <hogehogenohoge@yahoo.co.jp>; Tue, 27 Dec 2022 XX:XX:XX -0800 (PST)
Google内での転送でしょうか、mail-pj1-f99.google.comによるヘッダです。
9: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=ayashiidomain-com.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:mime-version:date:subject:to:from:sender
:message-id:from:to:cc:subject:date:message-id:reply-to;
bh=(略);
b=(略)
DKIMの署名です。
d=のドメインがgappssmtp.comなのでGoogleの持つサーバーで付けられているだろうことが推測できます。
10: X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:date:subject:to:from:sender
:message-id:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=(略);
b=(略)
また別にDKIM署名を別に付けているようです。
今度のドメインは1e100.netでこちらもGoogleのようです。
11: X-Google-Smtp-Source: (略)
Googleが何か付けているようですがわかりません。
12: X-Received: by 2002:a17:902:aa07:x:x:x:x with SMTP id be7-20020a170902aa07xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xx.xxxxxxxxxxxxxx;
Tue, 27 Dec 2022 XX:XX:XX -0800 (PST)
2002::/16は6to4用のアドレスらしいです。2002のあとの32bitがipv4のアドレスらしいので、
0ah.17h.09h.02h -> 10.23.9.2 の内部IPが受け取ったことを示すヘッダ。
Google内部ではIPv6で全て処理されており外に出ていくときにIPv4になるんでしょうか。
13: Return-Path: <hogehoge@ayashiidomain.com>
Return-Pathは変わらず。
14: Received: from falmtydlkr ([2001:19f0:8001:17c7:x:x:x:x])
by smtp-relay.gmail.com with ESMTPS id s1-20020a17090302c1xxxxxxxxxxxxxxasmxxxxxxplk.xx.2022.12.27.xx.xx.xx
for <hogehogenohoge@yahoo.co.jp>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Tue, 27 Dec 2022 XX:XX:XX -0800 (PST)
GoogleのSMTPリレーサーバーがfalmtydlkrというあやしい名前のipv6からメールを受け取っています。
2001:C00::/23はAPNICなので、アジアのどこかのノードでしょうか。
ここが送信元のようです。
15: X-Relaying-Domain: ayashiidomain.com
16: Message-ID: <xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@yabaikamo.jp>
17: Sender: <hogehoge@ayashiidomain.com>
どうもGoogleのMTAを持つDKIMを、うまいことリレーすることで悪用しているようです。
セキュリティとして問題ないのか
今回のようなフィッシングメールが届いて破棄するまでのフローで、視点としていくつか有ると思います。
SPF、DKIM、DMARCの技術的な視点、正しくメールを送受信する視点、Yahoo!Japanのメーラーの視点、受信者の視点、ドメイン所有者の視点。
それぞれ見ていきます。
SPF, DKIM, DMARC
技術的な視点から見ると、今回のケースはDKIMだけ通っています。
パスしたDKIMは、Google(gappssmtp.com)の第三者署名の検証であって、作成者（yabaikamo.jpドメイン）の署名ではありません。
DMARCが通らなかったのは、DKIMが作成者署名でなく、かつSPFがayashiidomain.comにレコードが設定されておらず通らなかったからです。
注)各検証が見る2つのFrom
SPF：MAIL FROMのいわゆるエンベロープFROM
DKIM：本文のFromいわゆるヘッダーFrom（このドメインがDKIMの署名のdタグと一致していると作成者署名、異なっていると第三者署名＝今回のGoogleの署名）
それぞれの結果から、それぞれの仕組みで正当に評価されていましたので、
総合的に評価できる場合、セキュリティ的に問題ないでしょう。
正しくメールを送受信する
今回はフィッシングが明らかでしたが、送信者、受信者ともにメールの真正性を証明・確認したい場合、
DKIMは第三者署名ではなく作成者署名である必要がありました。
第三者署名を付けるサーバーも含め、そこまでの経路で改ざんされていることが検出できません。
メールの送信者は、SPF+DMARC、DKIM+DMARCのどちらかのセットがパスするよう準備すべきでしょう。
Yahoo!Japanのメーラー
今回の発端となったDKIMがパスしている情報。
メールヘッダを見ず、DKIMがパスしているか判断するための情報を提供してくれるという意味では、ユーザビリティとして一定の評価はできます。
しかし、Yahoo!Japanを利用するユーザーはフィッシング対策に使われる技術に明るい人ばかりではないので、単にDKIMがパスしているという表記では、誤解を招く部分があるように思います。
第三者署名と書くとお墨付きのような印象も与えるので、メールの作成者による署名ではない、など多少ネガティブな文言を入れないと、評価できない人からすると余計に混乱させる情報になってしまいます。
ユーザー層を考えて、認証情報の表現についてもう少し深く踏み込んだ結果を表示させる必要があるでしょう。
なんとなく、えげつない広告表示がひと昔前の雰囲気があるので、UIUXが改善されるのはもっと先になる予感がします。
ユーザー
Yahoo!Japanの人もプロでも詐欺メールを完全に見分けることは出来ないと言っている通り、ユーザーが100%判別するのは困難です。
Yahoo!Japanでは認証、ヘッダ情報を見る機能や、ブランドアイコン、広告Blockなどの一定のセキュリティ機能を提供してくれているので、そういった情報とSPF, DKIM, DMARCの結果もあわせて判断できれば、セキュリティ上の問題は軽減されるでしょう。
ドメイン所有者
yabaikamo.jp管理者からすると、今回の場合、SPF/DKIM/DMARCの結果には問題ありませんでした。
フィッシング攻撃者がそれらをパスさせるためには、
・DKIMのキーペアを知ってる かつ _domainkeyが設定されている
・DNSゾーンに対する権限を持っている(SPF/DKIM/DMARCすべてを掌握できる)
いずれかが必要になります。
ドメイン管理者としては、DKIMの鍵の管理をしっかり行う、DNSの権限は最小限に絞る、あたりができる対策でしょうか。
自分のドメインが勝手にフィッシングのFromにされないためにも、
SPFの設定、DMARCポリシーのTXTレコードの2つは設定しておくとが有効でしょう。
これはメールを送らない場合でも設定すべき項目です。
話は少し逸れますが、ドメインを悪用されないための対策としては、他にDomain Transferを無効にする設定をする、勝手に証明書を発行されないようCAAレコードを登録するなどがあります。