チケットトリック：ユーザーサポートサービスによる数百の企業のハッキング

ハッカーが企業のメッセージングツールをクラックできる脆弱性が数か月前に発見されました。 この脆弱性を悪用することは、マウスを数回クリックすることほど難しくありません。マウスが正常に使用されると、会社の内部ネットワーク、Twitterなどのソーシャルネットワーク上の従業員のアカウント、通常はYammerとSlackのチームにアクセスできます。







見つけた名前とロゴを思いついた。 当たり前だと思ってください。



問題の問題はまだ存在します。 これは、すべてをすぐに整理できる場合には当てはまりません。 過去数か月にわたって、私は状況を修正するために、バグトラッププログラムの一環として、数十の企業と脆弱なサービスプロバイダーに連絡しました。 これは非常に多くの組織に適用されるため、全員に連絡することはできません。 私が尊敬する一部の人々の推奨に従い、問題の影響を受ける組織の許可を得て、私はこの資料を発行し、関係者全員がすぐに行動できるようにします。 次に、私がチケットトリックと呼んだものについて説明します。

ドア：企業のメールボックスを使用して登録する

Slack、Yammer、Facebook Workplaceなどの一般的なビジネスコミュニケーションプラットフォームでは、会社の従業員が会社のメールボックスを使用してサインアップする必要があります。 従業員は、仕事用メールに送信されたアドレスを確認するためにリンクをクリックするとすぐに、サービスの会社のグループに参加し、グループの他のメンバーとの内部通信にアクセスできるようになります。









Slack：同じ企業ドメインでメールボックスが開いているユーザーは、デフォルトでチームに参加できます。 これは、SSOに置き換えるか、招待のみで接続モードに設定できます









Yammer：会社のメールボックスを持っている人はだれでも会社のチームに参加できます









Facebook Workplace：企業のメールアカウントを持っている人なら誰でもチームに参加できます。

ドアキー：サポートサービスまたは電子メールメッセージから呼び出しを作成する機能

▍方法番号1：エラー追跡システム

GitLabで研究を始めました。 @ gitlab.comに有効なメールボックスを持っている人は誰でもSlackのチームに参加できます。









SlackのGitLabチームに接続する



同時に、GitLabは、@ gitlab.comで作成された一意のアドレスに送信することにより、エラーメッセージを作成する機能を提供します。 すべてがどこに向かっているのか見ますか？









GitLabは、電子メール経由でエラーメッセージを生成する機能を提供する多くのバグ追跡システムの1つです。



興味のために、私に提供された電子メールアドレスを使用してエラーメッセージを生成し、Slackのチームに参加しようとしました。









gitlab.slack.comで登録する



登録後すぐに、コールのリストを更新し、新しいエラーメッセージの形式でアドレス確認レターがプロジェクトに追加されたことを確認しました。









確認メール



追加したエラーメッセージには、GitLab Slackコマンドへの接続に必要な「マジックリンク」が含まれていました。









確認リンク付きのメール



リンクをクリックして、機能するかどうかを確認しました。 彼女は働いた。 参加できるチャンネルのリストが提供されました。 私はすぐにアカウントを削除し、GitLabに問題を報告しました。









チャンネルのリストを含む編集されたスクリーンショット



GitLabチームは、同じ日曜日の夕方に送信したメッセージに返信しました。









脆弱性レポート



すぐに接続モードをSlackのチームに変更し、招待のみで接続できるようにしました。 さらに、こうした機能の危険性を顧客に知らせるために、追加の対策を講じました。

▍方法2：サポートサービス

パブリックバグトラッカーを備えたWebサイトは多くないため、より一般的な攻撃ベクトルがあるかどうかを調べるために、さらに掘り下げることにしました。 結局のところ、それは存在し、私が予想するよりもはるかに頻繁に発生します。それはカスタマーサポートサービスです。



support@company.comに送信された電子メールは、Zendesk、Kayako、（Fresh）Desk、WHMCS、または同様の独自システムなどのオンラインサポートポータルで見つかることがあります。 その結果、私はこれを試して、クラッカーが顧客サポートシステムから必要なメール確認リンクをどうにか取得できるかどうかを調べることにしました。



ほとんどのサポートポータルはシングルサインオンテクノロジーと統合できます。認証されたユーザーは自動的にサポートサービスにログインします。 これにより、使いやすさが向上します。 私がチェックしたサイトの半分以上は、メールアドレスの確認を必要としませんでした。 つまり、誰でも任意の電子メールアドレスでシステムに登録し、このアドレスを使用して作成されたサポートリクエストを読み取ることができます。 Vimeoのオンラインビデオプラットフォームは、検証を必要としない多くの企業の1つでした。



その結果、Slackが確認メールアドレスを送信するために使用するのと同じメールアドレス（feedback@slack.com）を使用してVimeoにアカウントを登録しました。









feedback@slack.comを使用してVimeoに登録する



便利なSlack Find Your Workspace機能を使用して、SlackでVimeoチームを見つけ、メールアドレスsupport@vimeo.comでサインアップしました。









アドレスsupport@vimeo.comを使用してvimeo.slack.comに登録します。



一方、feedback @ slack.comからsupport@vimeo.comに、アドレスを確認するためのリンクを含むメールが送信されました。



support@vimeo.comが手紙を受け取ると、feedback @ slack.comから作成されたテクニカルサポートのチケットとして分類されます。これは、まさに私が登録した住所です。



次に、Vimeoのサポートを見て、チケットを確認しました。









Vimeoのサポート



Vimeoチームに参加するために必要な住所確認リンクが含まれた訴えが1つありました。









住所確認リンク



Vimeoチームは、見つかったエラーに関する私の報告にすぐに応答し、バグ検索プログラムの一環として2000ドルを提供しました（＃ 220102 、公開待ち）。



この脆弱性は、電子メール検証を提供しないサポートポータルを統合するすべてのWebサイトに適用されます。 しかし、すべてがさらに悪化しました。



KayakoとZendeskにさらに2つの穴があることを発見しました。これにより、通常の設定でメールアドレスを確認するプロセスをバイパスできました。 これにより、SSOサービスが無効になっていて、メールアドレスの確認が必要な場合でも、攻撃を正常に実行できました。 これらの問題を、脆弱性の責任ある開示プログラムの一環として6月1日に報告しました。 両方のプロジェクトがすべてを修正しました。



さらに、登録後にアドレスの確認を必要とするが、その後の変更後は確認しないWebサイトも脆弱です。

問題を拡大する

会社がSlackを使用せず、安全だと思う場合、私が発見した脆弱性がどれほど一般的であったかを考えると、おそらくそれほど良くありません。 たとえば、Yammerなどの他のビジネスコミュニケーションツールもこの攻撃の影響を受けます。









名前を公開していない会社が所有するYammer内部ネットワークに接続できました



また、@アドレスをサポートするために送信された手紙を読むことができるため、これらのアドレスに送信されたパスワードリセットリンクも確認できます。 結局のところ、かなりの数の企業がこのアドレスを使用して、サードパーティのサービスやTwitterなどのソーシャルネットワークに登録しています。



これは、攻撃者が、@をサポートするなど、アドレスに関連付けられているアカウントを押収できることを意味します。









Twitterパスワードのリセット









100万人以上のフォロワーがいる複数のTwitterアカウントを取得できました



場合によっては、会社のWebサイトの特権アカウントもこれらの電子メールアドレスに関連付けられています。 アドレスno-reply@company.comで登録することにより、support @ company.comのパスワードリセットトークンをインターセプトし、すべての顧客情報へのアクセスを許可した特権アカウントへのアクセスを取得できました。



上記の方法がいずれも機能しない場合、攻撃者はメールを使用して作成されたサポートサービスへの既存および将来のチケットを読み取り、それらに応答する機会がありました。 私の友人は、何かがうまくいかなかったため、会社のサポートサービスの住所に手紙を送りました。 この問題に対処するために、ある会社が脆弱であることが判明したため、そのアドレスを使用してシステムに登録し、「私のサポートケース」セクションに移動して、手紙がどのように表示されるかを確認しました。 このサービスにアカウントを持っていなかったユーザーからサポートサービスに送信された手紙を読むことができ、それらに返信することができました。 このような攻撃の結果、実際にサポートサービスと通信していると考えるユーザーは、ハッカーに対応します。

企業とサービス所有者の回答

私が発見した脆弱性を各企業がどのように排除するかを知りたいと思いました。 最後に何が起こったのかを示します。



ほとんどすべての影響を受けた企業は、私の要求に非常に専門的に反応しました。 発見された脆弱性に対して8,000ドルの報酬を与えることを決めた人さえいました。 時々私は否定的な答えを受け取り、いくつかは単に私を無視しました。



GitLabエラー追跡システム（＃ 218230 、開示）の管理はすぐに行動を起こしました。つまり、会社のドメインで開かれたアドレスは信頼されなくなり、さらに、Slackの設定が変更されました。 さらに、ユーザーが同じ間違いをしないように、 ドキュメントに変更を加えました。



より高いレベルでこれを防ぐことができるかどうかを調べるために、Slackの問題（＃ 239623 、公開保留中）を報告しました。 彼らはこの脆弱性に直接責任を負わないという事実にもかかわらず、かなりの数の顧客に影響を及ぼします。



Slackは問題を深刻に受け止め、ランダムなトークンが含まれるように返信なしアドレスを変更しました。 これにより、ソフトウェアサポートサービスに対するこのような攻撃を確実に防ぐことができます。 ただし、この問題は、エラー追跡サービスやその他の電子メール統合システムに関連しています。 これはSlackサービス自体の脆弱性ではないという事実にもかかわらず、会社から1,500ドルの$しみない報酬を受け取りました。









Slackは、サポートサービスへの攻撃を防ぐために、無応答アドレスにランダム化されたトークンを追加しました。



さらに、私はYammerに連絡してこの問題を報告しようとしました。 最初は、返事を受け取りませんでした。 2週間後、次の電子メールを送信し、脆弱性の説明と共にYammerチームに転送したと答えました。 これまでのところ、彼らはSlackで行ったように、より高いレベルで問題を解決するための積極的な対策を講じていません。









攻撃者は、私が発見した脆弱性を使用してYammerワークスペースに参加できます



脆弱性検索プログラムの一環として、 カヤコとZendeskに連絡し（＃ 235139 、開示）、SSOバイパスの可能性を報告しました。 企業はこの問題を解決し、それぞれ1000ドルと750ドルをくれました。

よくある質問

当社に影響を与える可能性のあるものを見つける方法



この脆弱性は、電子メールメッセージを使用してサポートデスクチケットを作成できる場合、および未確認の電子メールアドレスを持つユーザーがチケットを利用できる場合に関係します。 さらに、公開されているバグトラッカーに存在します。または、システムがユーザーメッセージに応答して、会社のドメイン内の一意のアドレスを提供し、後でチケット、フォーラムの投稿、プライベート通信、またはユーザーアカウントに。



企業がこの脆弱性の影響を受けやすい場合、どのように対処できますか？



この問題を解決するためのいくつかのアプローチを見てきました。 AirBnb、LinkedIn、GitHubなどの企業は、 reply .linkedin.comやmail .github.comなど、異なるドメインのアドレスを提供しています。 これらのアドレスを使用して、YammerやSlackなどのサービスに登録することはできません。 GitLabは、エラー追跡サービスでのこのような攻撃を防ぐために、このヒントを含めるようにドキュメントを更新しました。



電子メール、サポートポータル、またはシングルサインオンシステムに関連する機能を無効にすることを決定した人もいます。 他の人は、メールアドレスをチェックするための適切なシステムを実装しています。 また、@などの企業アドレスを使用して、Twitter、Slack、Zendeskなどのサービスに登録することはお勧めしません。



公共サービスまたはビジネスコミュニケーションシステムがこの脆弱性の影響を受けやすい場合、どのように対処できますか？



カスタマーサービスメールボックスを使用してシステムに登録するユーザーに追加のセキュリティ対策を実装できますが、これは通常非実用的で非効率的です。 たとえば、Facebook Workplaceは、 notification +ajivdw9kpwld@fbworkmail.comのようなランダムに生成されたアドレスから手紙を送信するため、より良いアプローチがあります。 攻撃者は、アドレスがどのようなものか推測できません。 私の要請に応えて、Slackは同様の機能を実装することも決定しました。



何百もの企業が依然として脆弱であるため、なぜこの情報を開示するのですか？

多数の脆弱な企業は、それらすべてを知らせることを不可能にしています。 安全に関するアドバイスを求めなかった企業を訴えるリスクがあります。 私は、この脆弱性の影響を受ける少数の企業、および一般にアクセス可能な脆弱性開示プログラムを実装するサービスプロバイダーに連絡しました。 現在、この情報を開くことは難しい決定であり、ハッキングにつながる可能性がありますが、 歴史から、エラーに関する情報を隠すことはさらに悪いことがわかります。

まとめ

• 通常、企業の内部セキュリティシステムは外部セキュリティシステムよりもはるかに脆弱です。 このようなシステムの研究では、従業員がパスワード、会社の機密情報、顧客データをメッセージングシステムに投稿し、そのようなシステムで会社のチームに参加したすべての人がアクセスできることが示されています。
  
  
• 脆弱性の検索を止めることはできません。 それらの外観はどこでも期待できます。 ここで説明した問題は、セキュリティの専門家がチェックした何百ものサイトに長年存在していましたが、私が知る限り、誰もこの問題に気付きませんでした。
  
  
• 大企業は従業員が何をしているのかわかりません。 発見された脆弱性について、巨大な決済処理会社のCISOと話し合いました。 彼は、従業員がSlackを使うべきではないので、これは彼らにとって問題ではないと私に保証しました。 彼らはそのような問題のための独自の内部システムを持っています。 私は、従業員自身が自分の危険とリスクで開いている8つのSlackチャンネルに接続することで、彼が間違っていることを彼に証明しました。 これらのチャンネルは世界中の322人によって使用されました。 最後に、私は5,000ドルの報酬を得ました。
  
  
• 企業のメールアドレスを使用して参加できるSlackチームを知りたい場合は、 チームの検索機能を使用します 。
  
  

親愛なる読者！ あなたの会社はチケットトリックに対して脆弱ですか？