- MasterCardは、mastercard.com の一部トラフィックを案内する Akamai DNSサーバー名 の1つを
akam.net ではなく akam.ne と誤って設定しており、このタイプミスは2020年6月30日から2025年1月14日まで、ほぼ5年間残っていた
- セキュリティ研究者の Philippe Caturegli は、ニジェールの国別トップレベルドメイン配下にある akam.ne が未登録状態だと確認し、300ドルと約3か月をかけてドメインを確保して悪用の可能性を遮断した
- akam.ne でDNSサーバーを稼働させると、世界中から1日あたり 数十万件のDNSリクエスト が流入し、同じタイプミスをしていた組織の中でも MasterCard が最大の事例だった
- このドメインが悪用されていれば、誤配送されたメールの受信、影響を受けるWebサイト向けの SSL/TLS証明書 の取得、一部Windows認証情報の手動受信につながる可能性があった
- MasterCardは「システムにリスクはなかった」と説明してタイプミスを修正したが、その後 Bugcrowd を通じて LinkedIn 投稿の削除要請まで行われ、公開のあり方をめぐる議論が残った
ほぼ5年間放置されたDNSタイプミス
- MasterCardは、mastercard.com ネットワークの一部トラフィックを案内するために、Akamai の共有 DNSサーバー5台 を使用している
- 2020年6月30日から2025年1月14日まで、このうち1台が誤った名前で設定されていた
- 正しいサーバー名は
akam.net で終わる必要がある
- 問題の設定は
akam.ne を指していた
akam.ne は、西アフリカのニジェールの国別トップレベルドメイン管理下にあるドメインである
研究者が先にドメインを確保
- セキュリティコンサルティング会社 Seralys の創業者 Philippe Caturegli がこのタイプミスを発見した
- Caturegli は、akam.ne がまだ登録されていないと見て、ニジェールのレジストリを通じてドメインを確保した
- 費用は 300ドル
- 登録完了までほぼ 3か月 かかった
- DNSサーバーを有効化すると、世界中から毎日数十万件のDNSリクエストが届いた
- 同じタイプミスをしていたのは MasterCard だけではなかったが、届いたリクエスト数では最も大きな組織だった
タイプミスドメインが生み得たリスク
- Caturegli が akam.ne でメールサーバーを立ち上げていれば、mastercard.com や他の影響を受けたドメイン宛ての 誤配送メール を受信できた可能性がある
- アクセス権を悪用すれば、影響を受けるWebサイトのトラフィックを受けて中継できる SSL/TLS証明書 を取得できた可能性もあった
- 従業員のコンピューターから Microsoft Windows の認証情報を手動で受信できた可能性も残っていた
- Caturegli はこうした行為を試みず、MasterCard に対してドメインを引き渡せると通知した
- 通知には Krebs on Security の著者も参照先として含まれていた
MasterCardとBugcrowdの対応
- MasterCard は数時間後にミスを認めたが、運用上のセキュリティに実際のリスクはなかったと述べた
- 「システムにリスクはなかった」
- 「このタイプミスは修正された」
- その後 Caturegli は Bugcrowd を通じてメッセージを受け取った
- その内容は、Caturegli が akam.ne を確保した後に LinkedIn で公開したことが、倫理的なセキュリティ慣行に合致しないという趣旨だった
- MasterCard が当該投稿の削除を求めているという内容も含まれていた
- Caturegli は、自分は Bugcrowd プログラム経由で報告したことはなく、問題は MasterCard に直接報告したと答えた
- 彼は、公開前に影響を受けるドメインを登録して悪用を防ぎ、その費用も自ら負担したと説明した
DNSキャッシュが拡大し得る影響範囲
- 一般に組織は少なくとも2台の権威DNSサーバーを持つが、リクエストの多い組織は負荷分散のためにより多くのDNSサーバードメインを使用する
- MasterCard は5台のDNSサーバーを使っているため、攻撃者がそのうち1台だけを掌握した場合、全DNSリクエストの約 5分の1 しか見られないように思えるかもしれない
- しかし実際には、インターネット利用者は Cloudflare や Google などの 公開DNSリゾルバ に依存しているため、影響はさらに大きくなり得る
- リゾルバの1つが誤ったネームサーバーに問い合わせ、その結果をキャッシュすればよい
- DNSレコードに長いTTLを設定すれば、大手クラウド事業者を通じて誤った指示が広がる可能性がある
- Caturegli は、長いTTLを使えばトラフィック再ルーティングの範囲は単純に5分の1よりはるかに大きくなり得ると見ている
問題のサブドメインと過去の登録履歴
- Caturegli が公開したスクリーンショットでは、誤設定されたDNSサーバーが MasterCard の az.mastercard.com サブドメインに関連している
- このサブドメインが正確にどのように使われているのかは不明である
- 命名規則から見ると Microsoft Azure クラウドの本番サーバーに関連するドメインと見られ、Caturegli は当該ドメイン群が Microsoft のインターネットアドレスに解決されると述べている
- akam.ne は過去にも登録されたことがある
- 2016年12月、
um-i-delo@yandex.ru のメールアドレスを使うユーザーが登録した
- Yandex は、このアカウントがモスクワの「Ivan I.」に属すると表示している
- DomainTools.com のパッシブDNS記録によると、2016年から2018年までドイツのインターネットサーバーに接続されており、2018年に失効した
- 元 Cloudflare 社員は、Caturegli の LinkedIn 投稿コメントで類似事例を扱ったレポートへのリンクを共有した
- 一部組織が AWS DNSサーバー
awsdns-06.net を awsdns-06.ne と誤入力していた可能性があるタイプミスドメインの事例である
- DomainTools によると、このタイプミスドメインも Yandex ユーザーに登録され、同じドイツのISPである Team Internet にホスティングされていた
1件のコメント
Hacker News の意見
この事例のように、公開登録できるネームサーバーは ダングリング DNS 問題の比較的まれなサブタイプにすぎず、より一般的なのは、攻撃者が確保できるクラウドプロバイダーの IP アドレスへドメインが直接マッピングされているケースである
クラウドサービスは範囲が広く、グローバルな可視性が不足している場合が多いため、クラウドを使う企業はサブドメインのどこかにこうした脆弱性がある可能性が高い
バグバウンティプログラムは「サブドメイン乗っ取り」を一律に除外することが多いが、見つかれば容易に悪用でき、こうした設定ミスによって機密情報が流出した内部・公開データも存在する
現在の脆弱性公開の環境は、企業が実際の脆弱性認定を回避しやすく、善意の研究者は倫理的・法的制約のために、提供者が求めるレベルの証拠を提示しにくいものになっている
こうした脆弱性によって実際に TLS 証明書の発行 が簡単に可能になるというリスクも過小評価されている
[1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
[2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
[3] https://pauley.me/post/2022/cloud-squatting/
[4] https://arxiv.org/pdf/2204.05122
たとえば、解放済みの S3 バケットを指す CNAME、Azure Website/WebApp インスタンス、非 Elastic IP を指す A レコード、もはや組織の AWS アカウントに属していない Route53 ネームサーバー、削除・無効化された Heroku/Shopify/GitHub Pages アカウント、倒産したトランザクションメール事業者のドメインを指す MX レコードなどがある
原因は、IT の分散化によって詳しくない人がインフラを作り、解体時に DNS を忘れ、子会社・ブランド・地域別組織が多くポリシーの発見と強制が難しく、国別の Web サイトやアプリが多く、セキュリティチームに知らせていない外部業者の利用が積み重なるためである
この分野のイスラエルのサイバーセキュリティ企業で Field CTO として働いているが、昨日も大手コンピュータ部品会社と、その会社のドメイン・PageRank・リンクを利用して「運営」されているインドネシアの賭博サイト 12 件ほどについて話したし、こうした会話は毎週繰り返されている
「何らかの方法で google.com を乗っ取れば Google ユーザーを侵害できる」というのは有効なセキュリティ脆弱性ではないが、今回のように 未登録・期限切れドメイン の乗っ取りが侵害につながるなら、有効な脆弱性と見るべきだ
企業が報告を却下するには明確な証拠を出す必要があり、その報告に由来する悪用が証明されたり、企業が変更を行って報告書の再現手順がもはや動作しなくなったりした場合には、報奨金の支払いまたは罰金の対象にできる
クラウド IP を大量に割り当て、古い IP を繰り返し探すことで、本来よりはるかに多い容量を得て、より高いレート制限でリクエストを送っていた
今はもう通用しないと思うし、今では誰もが知っている手法だ
この話で Bugcrowd の部分は予想外だ
メールのスクリーンショットは「Platform Behavior Standards Team」から来たように見えるが、そうだとすると、Bugcrowd がプラットフォーム外での行動まで規制しようとしてプラットフォーム基準を過度に広く解釈したか、Mastercard が公式の Bugcrowd スタッフを詐称したことになる
どちらもあまり受け入れがたい
[1] https://www.bugcrowd.com/resources/hacker-resources/platform...
その主張をよくしていた人が見れば、もっと分かりやすく説明できそうだ
すでに不正を行ったと判定されたかのように書かれており、選択肢は従うか、なぜ悪いのか追加説明を求めることだけだ
自分は不正をしていないと説明する機会がない
企業側から見れば、報奨金の支払いと内部レビューのコストが減り、法的にもそれらしい否認可能性を確保できる
「実際の脅威はなかった」といった対応は、次回、セキュリティ研究者がこの会社や他社で影響の証拠をさらに集めようとして、より深く侵入するよう促す可能性が高い
会社の広報担当者に「問題ない」と言わせたいなら、影響が小さく見積もられても研究者が受け入れられるだけの十分な報酬を支払うべきだ
すでに研究者は正しく行動したように見えるにもかかわらず、ニュースを抑え込もうとして研究者に圧力をかけたのは、クレジットカード会社にそうする理由があったのか、それとも広報担当者の誤った職務認識なのか、あるいは情報セキュリティ上のミスの最終責任者が自分の任期中の恥を避けるために会社のリソースを使ったのか、疑問だ
セキュリティ研究者 に、結果を公開することを恐れさせたいのだ
数年前のウクライナでは、オンライン取引の全部または大半が masterpass というサービスで検証される必要があり、Mastercard版の3DSのようなものに見えた。
ところが企業のWebではよくあるようにSSL証明書が期限切れになり、特定種類のMasterCardカードによるオンライン取引の全部または大半が、その瞬間に完全に止まった。
Mastercardは1年以上証明書を更新せず、顧客である私や銀行のIT部門がいくら連絡しても無駄で、後になってサービスをひっそり終了した。
調べてみると、サービスはMicrosoft系（IIS）で作られており、証明書チェーンは聞いたことのない中間証明書で異常に長く、ウクライナからかなり遠い第三世界の国でホスティングされていた。
Mastercardの視点では、その国の取引がすべて現地主体間の取引であっても、基本的に疑わしいと見ていたようだ。
米国では期限切れになったのを見たことはなく、国別トラフィック処理がどうなっているかは分からないが、Mastercardではなく別の場所へトラフィックがルーティングされていたように聞こえる。
akam.neが2016年にYandexメールを使うモスクワの「Ivan I.」に登録され、2016〜2018年にドイツのサーバーへ接続された後に失効したという点が気になる。
同様に、AWS DNSサーバー
awsdns-06.netをawsdns-06.neと誤入力した組織を狙ったようなタイポスクワッティングドメインもYandexアカウントで登録され、同じドイツのISPであるTeam Internet（AS61969）にホスティングされていたというくだりは特に怪しい。「アクセスを悪用していれば、影響を受けたWebサイトのトラフィックを受け取り中継できるSSL/TLS証明書を取得できたはず」と「当社のシステムにリスクはなかった」は、どちらか一方が間違っていなければならない。
双方とも嘘をついたり誇張したりする動機はある。
CS:GOサーバーなら洗練された攻撃者の最悪の攻撃は誇張かもしれないが、世界最大級の決済処理会社の話をしている場合は誇張ではない。
10分調べるだけでも同じ結論に至る。
そうしない理由は、そのリストが悪意ある行為者にインフラの手がかりを与えるからだ。
MasterCardは嘘をついているか、無知で無能かのどちらかだ。
az.mastercard.comが実際に何で、何をしているかに大きく依存する。x@mastercard.com宛てのメールを受け取るという話は正しくなさそうで、これは用途不明のサブドメインにすぎない。TLSはおそらく可能だろうが、リスクはそのドメインが何なのか次第で、
mastercard.comを訪れるユーザーにすぐ影響するものではなさそうだ。ドメインのDNS制御権だけで十分で、TXTレコードや自分が制御するHTTPサーバーへリクエストを送らせる方式が可能だ。
Mastercardの大きなミスであることは明らかだが、そもそも元のトップレベルドメインと1文字違いのドメインを存在させておくこと自体もミスのように見える。
たとえば
.comと.co、.netと.neのような場合で、問題を招く構造だ。そうしたドメインがなければ登録もできず、誤ったDNSリクエストは単にどこにも行かなかったはずだ。
タイポはトップレベルドメインだけでなく名前のどこでも起こり得るし、タイポがなくても、人気サイト名と1ビットだけ異なるドメインを押さえる ビットスクワッティング によって各種コンピューターエラーからトラフィックを得られる。
例のある論文もある。
[1] https://en.wikipedia.org/wiki/Bitsquatting
[2] https://www.securitee.org/files/bitsquatting_www2013.pdf
基本的には編集距離1のタイポドメインを、可能な限り一緒に登録しておく方式だ。
WikipediaによるとAkamaiはMarkmonitorの顧客の1社なので、このドメインがすでに登録されていなかった点は意外だ。
非国別コードドメインも、国別コードトップレベルドメインから1文字抜けた形と重なることがあり得るので、大きな違いはない。
ただし、この種の設定ミスは優れたDNSチェックツールなら検出できる。
登録されたネームサーバーの1つが解決できない、あるいはネームサーバー同士が同じゾーンのシリアル番号または実際の応答を返さない、といった形で表れる。
.isではドメインを登録するには正常に動作するネームサーバー2台を提供する必要があったが、.comは今ではそこまで厳しくない。そのドメイン名は akamai に引き渡すべきだった。
同じアドレスに他のリクエストも来ており、akamaiが責任を持って処理すべきだ。
「われわれが自らを調査したところ、過ちはなかった」という典型的な対応だ。
Mastercardは全世界に少なくとも34億枚のブランドカードを持ち、2024年第3四半期に世界の信用・デビット・現金取引443億件を処理した、数十億ドル規模の上場企業である。
過ちを認めることは市場では短期的に損になり得るが、否定する文化は企業文化を損なう。
ClownStrikeと何ら変わらず、略奪的・寄生的な信用・デビットネットワークには混乱が訪れる頃合いだ。
「誤字は修正され、システム上のリスクはなかった」といった言い方はいつも同じで、こういう声明には本当に腹が立つ
問題を認めれば株価が数百万ドル吹き飛ぶ可能性があるが、否定すれば変わり者たちがもう少しぐちぐち言うだけ。
侵害の証拠がなければ強制するのは難しく、侵害の証拠があれば刑務所行きになる
分かっている人なら、何かが悪用され得ないと断言できるほど安全だと感じることはほとんどない