DoorDashのシステムに脆弱性があり、誰でもDoorDashの正規サーバーからDoorDashをテーマにした「公式」メールを送信できる可能性があった。
DoorDash社は現在、この問題にパッチを適用しているが、脆弱性を報告した研究者と同社との間で論争が勃発しており、双方が互いに不適切な行為であると非難している。
誰でも「公式」DoorDashメールを送信可能
DoorDash for Businessプラットフォームの単純な欠陥により、誰でも完全にブランド化された「公式」メールをno-reply@doordash.com から直接送信できる可能性がある。
偽名のセキュリティ研究者doublezero7によって発見されたこの欠陥は、脅威行為者によって悪用され、非常に説得力のあるフィッシング・キャンペーンやソーシャル・エンジニアリング詐欺を仕掛けることができる。
簡単に言えば、誰でもDoorDash for Businessの無料アカウントを作成し、バックエンドの管理者ダッシュボードを使用して、（任意の名前と電子メールアドレスを持つ）新しい「従業員」を追加し、食事代予算を割り当て、任意のHTMLを含む電子メールを作成することができる。
出来上がったメールは、DoorDashの公式テンプレートで、スパムではなく、受信者のメールボックスにシームレスに届く：
この発見の背後にあるセキュリティ研究者は、最近、この脆弱性が悪意のある行為者に悪用される可能性があることを示すために、その証拠を提供した。
「ルートは予算名の入力フィールドでした。それはデータベースに生のテキストとして保存され、それがレンダリングされる電子メールに転送された。
「そして、display:noneを使うことで、それを完全に隠し、細工されたペイロードに置き換えることができた。
“それは完全に電子メールクライアントの防御層に依存していた。通過したものはすべてレンダリングされた。入力フィールドは、『onerror』以外のon*イベントも有効にしていたが、これらは電子メールプラットフォームによってフィルタリングされる」と研究者は続けた。
上記のスクリーンショットに示されている “Claim Free 20$ Voucher “のテキストは、研究者がDoorDash for Businessのバックエンドで作成した概念実証済みのHTMLインジェクションです：
研究者は、この機能を悪用して送信されるメールは、DoorDashの顧客や加盟店に限定されない、つまり、脅威行為者は、DoorDashをテーマにしたメールでほぼすべての受信者を標的にできると述べています。
この脆弱性は、2022年に.NETが明らかにした、Uber.comから誰でもメールを送信できるようにするUberのメールシステムの未対応の欠陥と同じである。
15ヵ月後にエスカレート
に連絡する前に、この研究者は、長い開示に苛立ち、具体的な技術的詳細や概念実証は伏せたまま、欠陥と開示の試みを要約した簡単な脆弱性レポートを発表した。
「技術的な欠陥は決して複雑なものではなく、信頼できる電子メールのテンプレートに格納されたペイロードをレンダリングする典型的なものでした。
しかし発見者は、この脆弱性について提出されたHackerOneレポート（#2608277）が2024年7月17日頃に「情報提供」としてクローズされ、「エスカレーションされることはなかった」という事実を問題視しており、この欠陥は15ヶ月以上も悪用可能なままになっている。
公開されているタイムラインと研究者の説明によると、欠陥が修正されたのは11月3日の週で、研究者がドアダッシュ社に何度も直接電子メールを送った後だった。
「私が公に圧力をかけなければ、この脆弱性は今も有効だったでしょう」と研究者は主張している。
倫理的公開は頓挫、報奨金も提供されず
明確な時系列を確立するため、独自の検証を行ったが、ここで研究者の説明とドアダッシュ社の言い分が乖離し始めた。
研究者は、同社は圧力をかけられるまでこの問題を無視したと主張している。同社は、その圧力自体が倫理的な一線を越えていたと言う。
同社の脆弱性報告への対応に詳しい人物によると、研究者とドアダッシュ社とのやりとりは、研究者が開示期限に連動した多額の支払いを要求したことで決裂したという。この情報筋によると、研究者は調停の申し出も拒否し、金銭的な要求を繰り返したという。
研究者はこの報告を、報酬を得るに値する正当なセキュリティ上の発見であるとしている。しかし、DoorDash社はこの問題を対象外とみなし、このアプローチは恐喝のように感じられるとしている。
ドアダッシュの広報担当者は：
「DoorDashは、セキュリティ研究者と協力して潜在的なセキュリティ脆弱性の発見と修正を支援するバグ報奨金プログラムを運営しています。
今回のケースでは、この個人はDoorDashから金銭を脅し取ろうとしました。彼らはその後、当社のバグ報奨金プログラムから追放されました。
報告された問題は、当社のバグ報奨金プログラムの対象外でした。当社のセキュリティチームは、報告された問題に対処するための措置を講じました。
私たちは、私たちのプラットフォームを保護するために誠実に活動する研究者と協力し続けます。”
また、HackerOneにも連絡を取り、詳しい状況を確認した。
バグ報奨金プラットフォームは、研究者の報告が “情報提供 “として閉じられた理由についてはコメントしなかった。
しかし、HackerOneの広報担当者は、：
「私たちは顧客と連携してこの問題を検討し、HackerOneの行動規範と顧客のプログラムポリシーに沿った適切な措置が取られたことを確認しました。
HackerOneは、プラットフォーム、顧客、HackerOneコミュニティの安全性とセキュリティを確保するため、利用規約を真摯に受け止めています。
コミュニティメンバーがHackerOneの利用規約に違反したと判断した場合、私たちは迅速かつ適切な措置を取ります。”これには、プラットフォームの永久的な禁止が含まれる場合があります。
への電子メールでは、研究者は、欠陥が長期間パッチを適用されなかったことを繰り返し、支払いを要求するなど、同社に直接連絡する際に「倫理的でない」アプローチを使用したことを認めた：
「DoorDash社への最終的な電子メールは、深刻な無視の歴史を考慮し、沈黙と引き換えに補償付きNDAの締結を条件付きで申し出るものでした。
“ドアダッシュは最後通告から数時間以内にバグを修正した（その重大性が証明された）が、私の支払い要求を無視し、黙って欠陥にパッチを当てることを選んだ。”
現在パッチが適用されている欠陥は、DoorDashの電子メールを偽装するのに便利ではあるが、DoorDashのユーザーデータを公開したり、内部システムにアクセスしたりすることはできない。
他のフィッシング・ベクターと同様、受信者を騙して行動を起こさせる必要があり、実際の「重大性」については疑問が残る。
しかし研究者は、「サイレント・フィックス」とその後のバグ報奨金プログラムからの除外を報復的なものと見ている。
“私が（脆弱性を公表するという）決断を下したのは、会社が私のサービスを無料で奪い、16ヶ月の失敗を隠そうとし、そして私を黙らせようとしたことに直接起因しています。” “これはセキュリティ研究に対する非倫理的なアプローチだと思います。
“正直なところ、私の行動がすべて正しかったかどうかはわかりませんでした。しかし、最終的に彼らはその欠陥にパッチを当ててくれたので、少なくとも私はそれを達成することができました」と、この研究者は.NETに結んでいる。
このケースは、脆弱性報告がいかに険悪なものになりうるか、そして研究者と企業との間の期待のずれがいかにすぐに対立につながりうるかを物語っている。
この件に詳しい情報筋によると、この欠陥は今月公表された10月のDoorDashの情報漏洩とは無関係だという。
.ia_ad { background-color：#width: 95%; max-width: 800px; margin: 15px auto; border-radius: 8px; border：1px solid #d6ddee; display: flex; align-items: stretch; padding: 0; overflow: hidden; }：0; overflow: hidden; } .ia_lef { flex: 1; max-width: 200px; height: auto; display: flex; align-items: stretch; } .ia_lef a { display: flex; width: 100%; height: 100%; } .ia_lef a img { width: 100%; height: 100%; border-radius: 8px 0 0 8px; margin: 0; display: block; } .ia_rig { flex: 2; padding：display: flex; flex-direction: column; justify-content: center; } .ia_rig h2 { font-size: 17px !important; font-weight: 700; color：#line-height: 1.4; font-family：margin: 0 0 14px 0; } .ia_rig p { font-weight: bold; font-size: 14px; margin: 0 0 clamp(6px, 2vw, 14px) 0; } .ia_button { background-color：#border：1px solid #3b59aa; color: black; text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; cursor: pointer; padding：width: fit-content; } .ia_button a { text-decoration: none; color: inherit; display: block; } @media (max-width: 600px) { .ia_ad { flex-direction: column; align-items: center; } .ia_lef { max-width: 100%; } .ia_lef a img { border-radius: 8px 8px 0 0; } .ia_rig { padding：15px;
width: 100%;
}
.ia_button {
width: 100%;
margin: 0px auto;
}
}
MCPのための7つのセキュリティ・ベスト・プラクティス
MCP（モデル・コンテキスト・プロトコル）がLLMをツールやデータに接続するための標準になるにつれて、セキュリティ・チームはこれらの新しいサービスを安全に保つために迅速に動いています。
この無料のチート・シートには、今日から使える7つのベスト・プラクティスがまとめられています。
Comments