パフォーマンスエンジニア。JABEE広報委員会委員。ICQ2025-Tokyo実行委員会委員。ITシステムの性能、信頼性、セキュリティの専門企業株式会社Spelldata代表。 https://xitter.cf/t.co/5UhBgP97uS 「逆襲のSlackware」運営 https://xitter.cf/t.co/AvKJaWTGf1

千葉県習志野市
Joined February 2008
この件には、たくさんの質問やコメントをいただきました。 「DMARCは導入して終わりではない」と言うと、「どこまでやればいいのか」という声も聞こえます。 でも、ITの世界は次から次へと変わるのが普通です。 仕様は後から継ぎ足され、攻撃者は新しい手口を見つけ続けます。 これは矛と盾の関係と同じです。 攻撃が変われば、防御も変わり続けなければなりません。 終わりがないから、技術の世界は面白く、探求する甲斐があります。 私は、変化が大好きです。
こちらのドコモ宛てに届いた「楽天カード」を名乗るフィッシングメールのヘッダを分析しました。 SPF・DKIM・DMARCはすべてpass、BIMIのロゴ表示まで付いています。 偽装ではなく、楽天カードの正規の署名付きメールを再送する「DKIMリプレイ攻撃」に、「SPF Bypass」を組み合わせた手口です。 ■経路 ①10/14 21:19、楽天カードが利用しているOKWeb3(okweb3.jp、現在の提供会社はPKSHA Communication社)の送信基盤(楽天カードのSPFで許可済みのIP)から、攻撃者のアドレス宛てに正規メールが送信 ②約18時間後、無関係なサーバーからドコモ宛てに再送 元の宛先と、実際に届いた宛先が違います。 ■なぜDMARCがpassするのか DKIM署名は、本文と署名対象のヘッダが改変されていなければ、誰が再送しても有効です。 署名ドメインはFromと同じmail.rakuten-card.co.jpなので、DMARCもpassします。 p=rejectでも、リプレイは防げません。 SPFもpassしていますが、これはエンベロープ送信者を空にし、HELOに使った攻撃者自身のドメインで判定させたものです(いわゆるSPF Bypass)。 Fromとはアラインしないため、p=rejectのドメインならこれだけでは届きません。 DMARCを通したのはDKIMリプレイです。 ■被害を広げた原因:署名対象がFromだけ DKIM-Signatureは h=From:From でした。 署名されているのはFromだけで、Subject・To・Content-Typeは署名対象外です。 攻撃者は件名を「楽天カード登録情報の更新について」に差し替え、MIME境界(boundary)も書き換えています。 RFC 6376 Section 5.4はFromの署名をMUSTとしていますが、それ以外は必須ではないため、仕様違反ではありません。 しかし、Fromだけの署名では、再送時に改変できる範囲が最大になります。 このDKIM署名は、楽天カードの鍵を使ってOKWeb3の送信基盤で付与されています。 署名範囲を決めているのは送信基盤側なので、まず送信基盤側で是正すべき問題です。 ■もう一つの根本原因 任意の外部アドレス宛てに、正規の署名付きメールが届く経路があったことです。 フォームの自動返信などを本番の送信ドメインで送ると、攻撃者にリプレイの素材を渡すことになります。 ■現状 現在、このDKIMセレクタはDNSに存在しません(全権威サーバーでNXDOMAIN)。 鍵を消せば以後の再送は止まりますが、すでに配送されたメールは、ロゴ付きのまま受信箱に残ります。 ■再発防止策(送信側) 1. DKIMの署名範囲を広げる(送信基盤側の対応) From以外に、Subject・To・Cc・Date・Message-ID・Reply-To・Content-Type・MIME-Versionも署名します。 さらに、存在しないヘッダも含めてオーバーサインし、ヘッダの追加・差し替えを防ぎます。 これは署名を行う送信基盤側、今回はOKWeb3が実装すべき対策です。 送信を外部に委託しているドメイン所有者も、委託先が何に署名しているかを確認する必要があります。 2. 未確認の宛先に送るメールを、本番の送信ドメインから分離する フォームの自動返信や登録確認メールは、本番の通知とは別のサブドメインから送ります。 そのサブドメインにはBIMIを設定しません。 利用者の入力内容を本文にエコーせず、送信数も制限します。 3. DKIM鍵を3か月ごとにローテーションし、リプレイを検知したら即座に失効させる 定期的なローテーションで、古い署名を再送できる期間を最長3か月に抑えます。 M3AAWGのDKIM鍵ローテーションの指針は「少なくとも6か月ごと」なので、3か月ごとはそれより厳しい運用です。 あわせてDMARC集計レポートを監視します。 「DKIMはpassしているのに、自社のSPFに含まれないIPから大量に送信されている」という記録は、リプレイの兆候です。 検知したら、定期の周期を待たずに鍵を失効させて再送を止めます。 4. SPFの許可範囲を最小化し、隠蔽化する クラウドなどの共有基盤を広く許可すると、その基盤の他の利用者からのメールもSPF passになり得ます(BreakSPF)。 許可するのは必要なIPだけにします。 さらにSPFを隠蔽化し、どの送信基盤を使っているかを分かりにくくすることで、利用しているメール配信基盤の脆弱性を探すことを困難にできます。 ■DMARCは実装して終わりではない DMARCは、実装して終わりではありません。 p=rejectにして、BIMIを設定しても、それで終わりではありません。 今回のように、利用しているサービス自体が脆弱であれば、突破されます。 委託先の送信基盤も含めて、DMARCレポートを継続的に監視し、異常を早期に検知して対処し続けることが必要です。
1
18
1
83
2,797
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
「2026年の大規模情報流出22件 ── 95.5%は企業対策で防げた」 2026年に多発したハッキング被害(総流出規模:約1億1,924万件以上)は、企業側がしっかり対策していれば間違いなく防げました。 「誰が何をやっても防げなかった(不可抗力)」と言える事案は実質ゼロ。 大半の大規模流出は、セキュリティの基本を怠ったことによる「人災」です。 全22事案を検証し、そう断言できる【3つの理由】をまとめました。 ─────────────── ① 侵入原因の大半が「鍵のかけ忘れ」レベルだった ─────────────── 数百万〜数千万件規模の流出を出したソースネクスト(約2,252万件)やバーガーキング(約1,118万件)など、アプリ連携を狙われた事案(A2B攻撃)の実態は極めて初歩的です。 ・サーバー側で「ログイン中の本人か」を確かめる認可制御を怠り、会員番号等のパラメータを書き換えただけで他人のデータが次々と出力された ・短時間に何百万回も不審な要求が届いているのに、遮断する「通信制限(レートリミット)」すら設定していなかった ・skyticket(約1,464万件)では、管理画面が外部に露出していたうえ、予約完了画面がログイン不要で誰でも閲覧できる状態だった ・修正パッチがとっくに公開されている「既知の欠陥」を放置していた企業も多数 これらは「最新鋭の防御を破られた」のではなく、「玄関の鍵を開け放して泥棒に入られた」のと同じです。 ─────────────── ② 万が一侵入されても「流出」は防げた(データ管理の杜撰さ) ─────────────── 侵入を100%防ぐのが難しくても、「顧客情報を持ち出させない」「流出規模を極小化する」対策は完全に企業側の責任です。 ・第一興商(約872万件) 業務委託先PCわずか1台のウイルス感染が発端。そもそも現場のPC1台に800万人分もの生データを丸ごと保存させていた運用そのものが致命的な過失。 ・タイムズカー(約660万件) 何年も前に退会した元会員や、入会を途中でやめた人の「運転免許証画像」までオンライン上に漫然と放置。 「不要になった個人データは消去する(データ最小化)」という鉄則を守っていれば、被害規模は何分の一にも抑えられました。 ─────────────── ③ 唯一「未知の攻撃」だったKDDIすら、基本の手抜きで被害拡大 ─────────────── 2026年の主要事案で唯一、メーカー未認識の欠陥(ゼロデイ)を突かれたKDDIのメール基盤。 初期侵入自体は技術的に防ぐのが困難でしたが… ・流出した約762万件のパスワードの一部が、暗号化もハッシュ化もされていない「平文(生の文字列)」のまま保存されていた このため個人情報保護委員会から行政指導を受けています。侵入は不可抗力でも、パスワード暗号化という基本さえ守っていれば、メール盗み見などの二次被害は確実に防げました。 ─────────────── ▼ 95.5%が「防げた」と言える根拠データ ─────────────── 上記①〜③の視点から、2026年に公表された全22事案(2026年10月16日時点)を客観的に分類・検証した結果が以下のデータです。 ・【区分A】基本的対策で侵入自体を防げた(理由①に該当):13件(59.1%) ・【区分B】多層防御・データ管理で流出を防げた(理由②に該当):8件(36.4%) ・【区分C】当時の技術水準では侵入阻止が不可抗力(理由③に該当):1件(4.5%) ★結論:全体の【95.5%(21件)】が企業側の適切な対策で防げた、あるいは被害を極小化できた事案です。唯一の区分C(KDDI)も平文保存の過失があるため、完全な不可抗力は実質ゼロと言えます。 以下、全22事案の攻撃手口・原因・可防性の検証リストです。 ━━━━━━━━━━━━━━━━━━━━ ◆ 2026年 国内不正アクセス・情報流出事案一覧(公表日 降順) ━━━━━━━━━━━━━━━━━━━━ 【2026/10/15】ソースネクスト株式会社 [サービス] 会員管理システム [被害規模] 約2,252万件(22,519,960件) [流出情報] 氏名、メアド、PW、住所、生年月日、電話番号、会社名等(クレカ除く) [攻撃手口] アプリ解析による会員情報取得APIへの不正アクセス(A2B攻撃) [判定] 【区分A:防げた】 [技術的根拠] APIのセッショントークン検証、オブジェクト単位の認可制御(BOLA対策)、大量照会を遮断するレートリミット未実装が原因。 【2026/10/15】株式会社ビーケー・ジャパン [サービス] バーガーキング公式アプリ [被害規模] 約1,118万件 [流出情報] 会員ID、メアド、氏名、電話番号、生年月日、性別、都道府県、注文履歴の有無 [攻撃手口] 公式アプリ会員管理システムへの不正アクセス [判定] 【区分A:防げた】 [技術的根拠] アプリ連携バックエンドAPIにおける認証・認可制御の不備。異常トラフィックの遮断が機能していれば防止可能。 【2026/10/15】株式会社メドレー [サービス] 産婦人科向け業務支援システム「アットリンク」 [被害規模] 最大787医療機関の患者情報(人数精査中) [流出情報] 氏名、診察券番号、受診予約、問診回答、最終月経日、マタニティダイアリー等の機微情報 [攻撃手口] Webシステム・管理領域への不正侵入 [判定] 【区分B:防げた】 [技術的根拠] 特権ID管理の厳格化、機微な医療データのテナント別暗号化、内部ログ監視があれば流出の極小化が可能。 【2026/10/13】株式会社アルカディア [サービス] 自治体・学校向け防災情報配信「SpeeCAN RAIDEN」 [被害規模] メール約313.6万件、電話約10.5万件、FAX約1.5万件 [流出情報] 氏名、連絡先(メール/電話/FAX)、契約担当者情報、配信本文履歴 [攻撃手口] サーバー(raiden3、s2)への外部侵入 [判定] 【区分A:防げた】 [技術的根拠] サーバー公開設定の不備、管理系ネットワークのアクセス制御・IP制限の欠如。管理網の分離とMFAで遮断可能。 【2026/10/13】株式会社ライドオンエクスプレスホールディングス [サービス] 「銀のさら」「釜寅」「すし上等」公式サイト・アプリ [被害規模] 最大約650万件 [流出情報] 氏名、住所、電話、メアド、生年月日、PWハッシュ値、注文履歴、家族情報、配達先情報 [攻撃手口] IDCFクラウドへのランサムウェア攻撃および自社サーバー不正アクセス [判定] 【区分B:防げた】 [技術的根拠] クラウド責任共有モデルに基づく別基盤への不変バックアップ保持、顧客データの分散・トークン化で被害を極小化可能。 【2026/10/09】株式会社アドベンチャー [サービス] 旅行予約サイト「skyticket」 [被害規模] 約1,464万件(うちPWハッシュ約413万件)、返金口座17,780件、バス予約約1.2万件 [流出情報] 氏名(パスポート名含む)、連絡先、住所、振込名義、返金先口座番号、予約内容等 [攻撃手口] 管理機能の不正操作、業務管理システムの脆弱性悪用、バス予約完了画面の未認証閲覧 [判定] 【区分A:防げた】 [技術的根拠] 管理機能へのMFA・IP制限、既知脆弱性の改修、Web完了画面へのセッション認可実装(IPA指針準拠)で完全に遮断可能。 【2026/10/09】ブックオフグループホールディングス株式会社 [サービス] 子会社会員管理システム [被害規模] 最大約643万件 [流出情報] 氏名、住所、生年月日、電話、メアド、ハッシュ化PW、カード番号等 [攻撃手口] 会員管理サーバーの脆弱性を突いた不正アクセス [判定] 【区分A:防げた】 [技術的根拠] Web/サーバーアプリケーションの脆弱性未改修。定期的な診断に基づくパッチ適用とWAF配備で防御可能。 【2026/10/08】株式会社第一興商 [サービス] 「ビッグエコー」「DKダイニング」等店舗予約・会員基盤 [被害規模] 約872万4,000件(顧客約863.1万件、従業員約9.3万件) [流出情報] 氏名、性別、生年月日、メールアドレス、電話番号 [攻撃手口] 業務委託先(日本コロムビアグループ)従業員PC1台へのマルウェア感染 [判定] 【区分B:防げた】 [技術的根拠] 委託先PCローカルへの大量顧客データ保存禁止、DLP(持ち出し防止)導入、シンクライアント化で流出を阻止可能。 【2026/10/08】株式会社ローソン [サービス] 「ローソンID」および「ローソンアプリ予約」 [被害規模] 2,155,371件(ローソンID:約215.5万件、予約:26件) [流出情報] メールアドレス、氏名、性別、電話番号、住所、一部クレカ番号(26件) [攻撃手口] アプリの本人情報表示機能に対する不正アクセス(A2B攻撃) [判定] 【区分A:防げた】 [技術的根拠] アプリ連携バックエンドにおける本人識別・認可検証ロジック不備(IDOR)。セッション検証の実装で完全に防止可能。 【2026/10/07】株式会社IDCフロンティア [サービス] 「IDCFクラウド」(東日本リージョン1) [被害規模] 495の企業・自治体(データ暗号化・復元不能)、問い合わせ情報等約600件流出 [流出情報] 仮想サーバー内データ(多数の企業システム)、問い合わせ氏名・連絡先 [攻撃手口] クラウド基盤管理ネットワークに対するランサムウェア攻撃 [判定] 【区分B:防げた】 [技術的根拠] 管理網のゼロトラスト分離、ハードウェアMFA、管理層とテナント領域の完全分離により大規模障害・被害を封じ込め可能。 【2026/10/05】株式会社物語コーポレーション [サービス] 「焼肉きんぐ」公式アプリ 会員管理システム [被害規模] 約1,079万件(10,788,963件) [流出情報] 氏名、電話番号、メールアドレス、会員番号等 [攻撃手口] 公式アプリ会員管理システムへの外部侵入(A2B攻撃) [判定] 【区分A:防げた】 [技術的根拠] APIにおけるオブジェクト認可不備および大量データ要求の監視・レートリミット欠如が原因。API Gatewayで防御可能。 【2026/10/05】GMOリサーチ&AI株式会社 [サービス] アンケートサイト「infoQ」 [被害規模] 894,082件(ポイント不正交換611件・約287万円) [流出情報] 氏名、生年月日、住所、電話、メアド、暗号化PW、会員ID、保有ポイント等 [攻撃手口] サイトで使用していたソフトウェアの脆弱性を突いた侵入 [判定] 【区分A:防げた】 [技術的根拠] 公開された既知脆弱性(CVE)に対するパッチ未適用。WAFによるシグネチャ遮断で防止可能。 【2026/10/02】第一生命保険株式会社 [サービス] 従業員向け人事システム [被害規模] 約12万人(現役約5万人、退職者約7万人) [流出情報] 従業員番号、氏名、住所、電話、性別、所属、職位、職務、上長氏名等 [攻撃手口] 人事管理システムに対する不正アクセス [判定] 【区分B:防げた】 [技術的根拠] 機密人事DBへの最小権限アクセス、退職者データのオフライン分離・早期廃棄(データ最小化)で流出を極小化可能。 【2026/09/29】株式会社セイコーマート [サービス] 「セイコーマートアプリ」および会員サーバー [被害規模] 574,647人(不正閲覧確認) [流出情報] 氏名、住所、生年月日、電話番号、メールアドレス等 [攻撃手口] アプリ中継サーバーを経由した会員保有サーバーへの侵入 [判定] 【区分A:防げた】 [技術的根拠] アプリ中継層と基幹DB層のファイアウォール分離、DB直接照会権限の剥奪、API認可検証で侵入遮断可能。 【2026/09/28】タイムズモビリティ株式会社 [サービス] 「タイムズカー」Webシステム [被害規模] 約660万アカウント(うち本人確認書類画像約160万件) [流出情報] 氏名、住所、生年月日、電話、メアド、免許証情報、運転免許証等の画像、ハッシュ化PW等 [攻撃手口] Webシステムに対する不正アクセス [判定] 【区分B:防げた】 [技術的根拠] 退会者・申込未完了者データの定時消去、画像データの暗号化・隔離保管、Web層からの直接閲覧権限分離で極小化可能。 【2026/08/28】株式会社イエローハット [サービス] WEB作業予約システム [被害規模] 最大1,801,499名 [流出情報] 氏名、電話番号、メールアドレス、会員番号 [攻撃手口] 予約システムに対する不正プログラムによる攻撃 [判定] 【区分A:防げた】 [技術的根拠] Web予約アプリにおける入力値検証不備(IPA「安全なウェブサイトの作り方」準拠で防止可能)。 【2026/08/01】株式会社Eストアー [サービス] EC基盤「ショップサーブ」 [被害規模] 延べ8,853,839件 [流出情報] 氏名、住所、電話、暗号化PW、一部カード情報、店舗管理ID/PW等 [攻撃手口] サーバー上で不正プログラム(Webシェル等)を実行され外部送信 [判定] 【区分A:防げた】 [技術的根拠] サーバーOS/ミドルウェアの適時パッチ適用、Webシェル等の不正実行検知(EDR)、ファイルの整合性監視で防止可能。 【2026/06/30】アフラック生命保険株式会社 [サービス] 「アフラック よりそうネット」等 [被害規模] 約440万人(うち口座情報約22万人) [流出情報] 氏名、生年月日、住所、電話、証券情報、口座情報等 [攻撃手口] 正規照会形式を模倣した短時間・大量データ照会型攻撃 [判定] 【区分A:防げた】 [技術的根拠] API/Webエンドポイントにおけるレートリミット(流量制限)、Bot対策、大量データ照会時の自動セッション遮断で防止可能。 【2026/06/23】KDDI株式会社 [サービス] ISP事業者向けメールシステム [被害規模] メアド約1,223万件、パスワード約762万件 [流出情報] 電子メールアドレス、メールパスワード(一部平文保存) [攻撃手口] 第三者製ソフトウェアの未知の脆弱性(ゼロデイ)悪用 [判定] 【区分C:不可抗力(※ただし平文保存は明確な過失)】 [技術的根拠] メーカー未認識のゼロデイ侵入は当時防止が極めて困難。ただしPWの平文保存は明確なガイドライン違反(個人情報保護委員会が指導)。 【2026/04/15】株式会社イエローハット(子会社) [サービス] 子会社会員専用サーバー [被害規模] 3,179,454件 [流出情報] 氏名、電話番号、会員データ等 [攻撃手口] 子会社サーバーに対する不正アクセス [判定] 【区分A:防げた】 [技術的根拠] 親会社・子会社間のセキュリティパッチ適用ガバナンス、定期的な脆弱性診断で防止可能。 【2026/02/16】学校法人東海大学 [サービス] 業務委託先システム [被害規模] 最大延べ193,118人 [流出情報] 氏名、所属、学生・教職員情報等 [攻撃手口] 業務委託先事業者に対するランサムウェア攻撃 [判定] 【区分B:防げた】 [技術的根拠] 委託先へのセキュリティ要件定義の厳格化、定期的な監査、暗号化データの隔離保管で極小化可能。 【2026/01/13】株式会社スマレジ [サービス] 外部連携アプリベンダー管理下データ [被害規模] 136,000件 [流出情報] 顧客関連データ [攻撃手口] 外部連携アプリベンダーの管理システムに対する不正アクセス [判定] 【区分B:防げた】 [技術的根拠] APIトークンの最小スコープ設定、外部連携先に対するセキュリティ基準適合評価の徹底で極小化可能。 ━━━━━━━━━━━━━━━━━━━━ ◆ 総括 ━━━━━━━━━━━━━━━━━━━━ データを見れば明らかなとおり、映画に出てくるような超絶技巧のハッカーに破られたわけではありません。 ・「やるべき認可・通信制限をしていない」 ・「公開済みのパッチを当てていない」 ・「不要な顧客データを消さず放置している」 ・「パスワードを生データのまま保存している」 高度な攻撃(ゼロデイ)を突かれたKDDIの初期侵入1件を除き、すべては企業側の「初歩的な手抜き(セキュリティ怠慢)」が引き起こした人災です。企業がやるべき基本対策さえ講じていれば、これら1億件超の被害は間違いなく防げました。
🤖 Made with AI
2
6
7,315
入力エコー攻撃の事例で見えた兆候のうち、MAIL FROMの空、未署名のContent-Typeと不自然な境界文字列、「+all」のSPFは、このツールの受信者向けの判定項目に入れています。一方、送信側で入力内容をメールに載せているかどうかは、ヘッダからは判定できません。兆候が無いことは、本物であることの保証にはなりません。
メールのヘッダを貼り付けるだけで、受信したメールのなりすましの兆候と、送信側の設定の安全性・到達性を確認できる無料ツール「メールヘッダ診断」を公開しました。 受信者向けには、Fromとアラインし、受信側で合格したSPF・DKIMが1つもなければ「なりすましメール」と表示します。本物の送信者のメールでも、アラインした認証が無ければDMARCはfailになるので、この判定になります。転送やメーリングリストを経たメールでも起こり得ます。 送信者向けには、DKIMの署名範囲、鍵長、SPF・DKIMのアライメント、DMARCポリシーなどを、安全性と到達性に分けてA〜Fで示します。ランクは最も悪い条件で決まります。ランクの基準はMailDataが定めたもので、RFCで定められたものではありません。各条件には、根拠となるRFCのSectionを添えています。 解析はブラウザの中だけで行い、ヘッダや本文をMailDataのサーバーに送りません。 maildata.jp/mail-header-chec…
5
21
2,524
SPF・DKIM・DMARCがすべてpassし、BIMIのロゴまで表示されたフィッシングメールがあります。 正規の送信基盤が署名したメールの再送と、フォーム入力をそのまま載せる仕組みの悪用によるものです。 設定が仕様どおりでも、DKIMの署名範囲が狭い場合や、入力内容を自動返信に載せている場合は防げません。 楽天カード名義の事例と、Google・Robinhoodの事例をもとに、手口と送信側の対策をまとめました。
問い合わせフォームの自動返信に、お客様の入力内容をそのまま載せていませんか。 正規の送信基盤から送られ、DKIMで署名されたメールは、SPF・DKIM・DMARCをpassし、BIMIのロゴも表示されます。入力欄に攻撃者が文面を書けば、その文面が自社の正規メールとして届きます。GoogleのOAuthアプリ名、Robinhoodのアカウント登録項目は、どちらもこの経路で悪用されました。 自動返信を作っているのがWeb担当、メール認証を設定しているのが情報システム担当、という組織では、両者で一度、自動返信に何を載せているかを確認してみてください。載せるなら、通知用とは別のサブドメインから送り、BIMIを設定せず、HTMLはエスケープするのが記事の示す条件です。 maildata.jp/tips/input_echo_…
77
2
261
19,174
日本全国で「チンギス!!!」の叫び声が響いた! #VIVANT
6
3,605
こちらのドコモ宛てに届いた「楽天カード」を名乗るフィッシングメールのヘッダを分析しました。 SPF・DKIM・DMARCはすべてpass、BIMIのロゴ表示まで付いています。 偽装ではなく、楽天カードの正規の署名付きメールを再送する「DKIMリプレイ攻撃」に、「SPF Bypass」を組み合わせた手口です。 ■経路 ①10/14 21:19、楽天カードが利用しているOKWeb3(okweb3.jp、現在の提供会社はPKSHA Communication社)の送信基盤(楽天カードのSPFで許可済みのIP)から、攻撃者のアドレス宛てに正規メールが送信 ②約18時間後、無関係なサーバーからドコモ宛てに再送 元の宛先と、実際に届いた宛先が違います。 ■なぜDMARCがpassするのか DKIM署名は、本文と署名対象のヘッダが改変されていなければ、誰が再送しても有効です。 署名ドメインはFromと同じmail.rakuten-card.co.jpなので、DMARCもpassします。 p=rejectでも、リプレイは防げません。 SPFもpassしていますが、これはエンベロープ送信者を空にし、HELOに使った攻撃者自身のドメインで判定させたものです(いわゆるSPF Bypass)。 Fromとはアラインしないため、p=rejectのドメインならこれだけでは届きません。 DMARCを通したのはDKIMリプレイです。 ■被害を広げた原因:署名対象がFromだけ DKIM-Signatureは h=From:From でした。 署名されているのはFromだけで、Subject・To・Content-Typeは署名対象外です。 攻撃者は件名を「楽天カード登録情報の更新について」に差し替え、MIME境界(boundary)も書き換えています。 RFC 6376 Section 5.4はFromの署名をMUSTとしていますが、それ以外は必須ではないため、仕様違反ではありません。 しかし、Fromだけの署名では、再送時に改変できる範囲が最大になります。 このDKIM署名は、楽天カードの鍵を使ってOKWeb3の送信基盤で付与されています。 署名範囲を決めているのは送信基盤側なので、まず送信基盤側で是正すべき問題です。 ■もう一つの根本原因 任意の外部アドレス宛てに、正規の署名付きメールが届く経路があったことです。 フォームの自動返信などを本番の送信ドメインで送ると、攻撃者にリプレイの素材を渡すことになります。 ■現状 現在、このDKIMセレクタはDNSに存在しません(全権威サーバーでNXDOMAIN)。 鍵を消せば以後の再送は止まりますが、すでに配送されたメールは、ロゴ付きのまま受信箱に残ります。 ■再発防止策(送信側) 1. DKIMの署名範囲を広げる(送信基盤側の対応) From以外に、Subject・To・Cc・Date・Message-ID・Reply-To・Content-Type・MIME-Versionも署名します。 さらに、存在しないヘッダも含めてオーバーサインし、ヘッダの追加・差し替えを防ぎます。 これは署名を行う送信基盤側、今回はOKWeb3が実装すべき対策です。 送信を外部に委託しているドメイン所有者も、委託先が何に署名しているかを確認する必要があります。 2. 未確認の宛先に送るメールを、本番の送信ドメインから分離する フォームの自動返信や登録確認メールは、本番の通知とは別のサブドメインから送ります。 そのサブドメインにはBIMIを設定しません。 利用者の入力内容を本文にエコーせず、送信数も制限します。 3. DKIM鍵を3か月ごとにローテーションし、リプレイを検知したら即座に失効させる 定期的なローテーションで、古い署名を再送できる期間を最長3か月に抑えます。 M3AAWGのDKIM鍵ローテーションの指針は「少なくとも6か月ごと」なので、3か月ごとはそれより厳しい運用です。 あわせてDMARC集計レポートを監視します。 「DKIMはpassしているのに、自社のSPFに含まれないIPから大量に送信されている」という記録は、リプレイの兆候です。 検知したら、定期の周期を待たずに鍵を失効させて再送を止めます。 4. SPFの許可範囲を最小化し、隠蔽化する クラウドなどの共有基盤を広く許可すると、その基盤の他の利用者からのメールもSPF passになり得ます(BreakSPF)。 許可するのは必要なIPだけにします。 さらにSPFを隠蔽化し、どの送信基盤を使っているかを分かりにくくすることで、利用しているメール配信基盤の脆弱性を探すことを困難にできます。 ■DMARCは実装して終わりではない DMARCは、実装して終わりではありません。 p=rejectにして、BIMIを設定しても、それで終わりではありません。 今回のように、利用しているサービス自体が脆弱であれば、突破されます。 委託先の送信基盤も含めて、DMARCレポートを継続的に監視し、異常を早期に検知して対処し続けることが必要です。
Replying to @TechnoTreasure
ヘッダ詳細のご要望が多いので 画像ですみませんが。
11
1,151
104
2,552
222,785
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
新製品RS1キーボード 開発秘話💡 分割キーボードを開発した経緯 ------- 開発者コメント ------- 分割キーボードは比較的ニッチな市場ではありますが、REALFORCEユーザーアンケートでも「今後REALFORCEに期待するキーボード」として上位に挙がっていました。 左右に分割することで、自然な肩幅のままタイピングできる点は、REALFORCEユーザーをはじめとする、タイピング環境にこだわりを持つ方々に一定のニーズがあると考え、開発をスタートしました。 さまざまな形状や配列の製品が存在する分割キーボードで、RS1キーボードは一般的な日本語キーボードに慣れている方でも違和感なく使い始められるよう、日本語キーボードを左右に分割したシンプルなレイアウトを採用しました。 主なターゲットは、現在REALFORCEをお使いの方や、分割キーボードに興味を持っている方です。 初めて分割キーボードを使う方にも導入しやすいよう、機能をシンプルにまとめ、タイピングに特化したキーボードとして開発しました。 RS1キーボード: realforce.co.jp/products/ser…
9
56
9
216
25,461
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
JABEEが協賛する公開シンポジウム 「高等教育と職業を繋ぐ学修成果測定」が開催されます。 高等教育における学修成果の評価について、報告・議論が行われます。 開催日時:2026年10月24日(土)10:00~12:00 開催方法:オンライン 参加申込は案内をご覧ください。 events.teams.microsoft.com/e…
2
4
352
子どもの頃の夢は俳優、最後の仕事はチーフエンジニア。 ウガンダ・ムバララの暮らし向きのよい家庭に女の子として生まれた。 孫3人、ひ孫3人に恵まれた。 引退したあと、86歳のときHIV/AIDSで世を去った。 あなたは80億人のうち、誰として生まれるだろう? #80億分の1 1in8b.life/ja/s/d-UGA-86-F-u…
907
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
【注意喚起】 2026年10月9日、直近で相次いでいる不正アクセス事案に関する件として各所からの情報提供に基づき更新し、JPCERT/CCが注意喚起をしています。ご確認ください。xitter.cf/jpcert/status/21083719…
直近で相次いでいる不正アクセス事案に関する注意喚起を、各所からの情報提供に基づき更新しました。また、ケースDとしてアプリケーションサーバー上にWebシェルを設置されるケースを新設しました。侵害調査にご活用ください。引き続き関連の情報提供もお待ちしています。^MH jpcert.or.jp/at/2026/at26003…
10
786
8
1,915
203,819
NICTとJPCERT/CCが、国内で相次ぐ不正アクセスについて注意喚起を出しました。 NICTは、公開されているスマートフォンアプリを解析してAPIの仕様を調べ、バックエンドを攻撃する手口を「A2B攻撃(App-to-Backend Attack)」と名付けています。 JPCERT/CCも同様の手口のほか、既知の脆弱性の悪用など複数の攻撃パターンを報告しています。 ポイントは、アプリ自体に脆弱性がなくても、バックエンドの認証・認可や入力値検証に不備があれば被害につながることです。 攻撃者はアプリの画面を使わず、APIを直接呼び出します。 狙われている脆弱性には、SQLインジェクション、SSRF、RCE、そしてAPIの認可の不備(IDOR/BOLA)があります。 認可の不備の典型例はこうです。 注文履歴を見るAPIで、注文番号を他人の番号に書き換えると、他人の情報が返ってくる。 ログインしているか(認証)は確認しているのに、そのデータを見てよい人か(認可)を確認していないために起きます。 このリクエストは形式も正常で、トークンも本物なので、WAFやCDNでは見分けられません。 これから「当社の製品なら防げます」という宣伝が増えると思います。 WAF、レート制限、不要なAPIの停止、管理機能の閉域化は、被害を抑えて修正までの時間を稼ぐ手段として有効です。 しかし、根本対策はバックエンドで認可と入力値検証を確実に実装することです。 製品の導入と並行して、次の点を点検してください。 ・すべてのAPIで、データの持ち主とリクエストした人を照合しているか ・IDが連番など、推測しやすいものになっていないか ・古いバージョンのAPIや検証環境が、公開されたまま残っていないか ・APIトークンの権限は最小限か、有効期限があり、すぐ無効化できるか NICT:nict.go.jp/press/2026/10/13-… JPCERT/CC:jpcert.or.jp/at/2026/at26003…
3
13
1,589
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
#小田原ちょうちん祭り 皆さんいきました?
2
28
791
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
Elon Musk 一句话戳破现代教育最大的弊病: “所有人都在教工具,没人教你问题是什么。” 现实里大家是怎么上课的? 先开一门“螺丝刀课”,再开一门“扳手课”,学生把各种工具名字背得滚瓜烂熟。 可真走到发动机面前,全都傻眼了:因为从头到尾没人告诉他,这台发动机到底是哪儿卡住了、为什么要拆它。 工具的意义,只有在你想拆开发动机的那一瞬间才会诞生。 先有问题,螺丝刀才是武器;没问题硬背,它就只是脑子里一个占内存的名词。 他还把“为什么我们学完就忘”这件事给聊透了: 手机可以存海量垃圾,大脑不行。维持记忆的生物成本极高,大脑整天都在疯狂“清空回收站”。 如果一个知识点回答不了“它跟我手头的问题有什么关系”,最多撑一周,脑子就自动给你抹掉了。 学数学和物理更是这样: 底层原理是树干,具体公式只是叶子。树干没立起来,硬往空中挂叶子,风一吹全掉光了。 现在网上铺天盖地全是“教你精通某个软件”的速成班。 可软件三年一换,甚至明年就被新工具洗牌了;但真实世界的问题不会变。 先搞懂你想拆的那台机器。 只要问题立在那儿,工具自己会来找你。
89
326
53
1,686
129,901
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
プレジデント・オンラインに「犯罪者と政府系ハッカー AI時代のサイバー攻撃に日本企業はどう備えるか」を寄稿。日本のサイバーセキュリティ能力に関するランキング表の考察、最近の中東やアジア情勢の示唆、AI時代の脅威について分析しました。 @Pre_Online president.jp/articles/-/1200…
2
19
3
48
1,981
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
2026年度デミング賞本賞は山田秀先生が受賞されました。また、弊社刊行の『品質経営改革』(佐々木眞一著)が日経品質管理文献賞を受賞しました。 おめでとうございます。 2026年度(令和8年)デミング賞各賞の受賞者について prtimes.jp/main/html/rd/p/00… @PRTIMES_JPより
1
6
179
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
東京都市大学を訪問しました。 同大学には、3学部に5件のJABEE認定プログラムがあります。 意見交換では、JABEE認定の国際的な有効性、受審に伴う負担、JABEEの知名度向上、認定プログラム修了後のキャリアパスなどについて、幅広くご意見を伺いました。 #JABEE #東京都市大学
1
8
314
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
アクチュアリー試験対策、統計検定1級対策にも使える! 『確率論・統計学 中心極限定理,確率過程とその先へ』藤田岳彦 吉田直広(東京図書) 初等確率統計の続きとして、中心極限定理、確率過程とその先へ読者をいざなう。 x.gd/FnbnP
29
2
244
11,769
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
江東区大島にある東京都立科学技術高等学校を訪問しました。 同校はSSH(スーパーサイエンスハイスクール)に指定され、国際的に活躍できる科学技術人材の育成に取り組んでいます。 高校段階から科学技術やエンジニアリングへの関心を高めるための取組について意見交換をさせていただきました。
1
5
299
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata retweeted
「#情報セキュリティ白書 2026」PDF版を公開しました。サイバー対処能力強化法及び同整備法の成立に伴う官民連携強化や、攻撃サーバーの無害化措置等、組織・体制整備などの取組について解説しています。 詳しくはこちら👇 ipa.go.jp/publish/wp-securit…
2
471
39
1,223
88,578
この記事で指摘している、見落とされやすい事は、no-cacheを付けても更新が反映されない条件です。 no-cacheは使う前に確認するだけなので、Last-ModifiedやETagが内容の変更に連動していなければ304が返ります。 nginxのETagは更新時刻とサイズから作られるため、rsync -tなどで更新時刻が残り、サイズも変わらない変更では、古いCSSが使われ続けます。
CSSやJavaScriptの ?ver= によるキャッシュバスティングが効くかどうかは、サイト側ではなく、CDNがクエリ文字列をキャッシュキーに含める設定かどうかで決まります。 CloudflareのStandardはクエリ文字列ごとに別のファイルとしてキャッシュしますが、CloudFrontの静的コンテンツ向け管理ポリシーCachingOptimizedはキャッシュキーに含めません。 同じサイトでも、CDNを乗り換えただけで ?ver= が効いたり効かなかったりします。 自分のCDNがどちらかは、一度も使っていない値を ?ver= に付けてcurlでリクエストすれば確かめられます。 初回からHITが返るなら、CDNはクエリ文字列を無視しています。 WordPressでは本体とプラグインの ?ver= が残るので、少なくとも ver はキャッシュキーに含める設定が必要です。 perfdata.jp/blog/blog-2026-0…
1
5
1,471