「Slack」がセキュリティホールをわずか5時間で修正、その秘策とは？

ユーザーの認証トークンを危険にさらし、ハッカーに個人データへのアクセスを許すセキュリティホールが「Slack」で見つかった。この問題点と攻撃の手法について説明する。

公開 2017年05月24日 12時15分

著者

Matthew Pascucci

[TechTarget]

印刷する

Slackが実施しているバグ報奨金プログラムが認証トークン漏えいからユーザーを救った

　クラウドベースのコラボレーションアプリケーションとしてユーザーを増やしている「Slack」にセキュリティホールが見つかった。攻撃者が悪用すれば、ユーザーの認証トークンを盗み出して再利用し、ユーザーのプライベートチャンネルやデータにアクセスできてしまう。このセキュリティホールは何が問題なのか。そして認証トークンはなぜ危険にさらされたのだろうか。

　Webセキュリティを手掛けるDetectifyのセキュリティ研究者であるフランス・ローゼン氏が発見したSlackのセキュリティホールは、攻撃者に他のSlackユーザーのチャットやメッセージ、ファイルコンテンツなどの情報へのアクセスを許してしまう。

　この脆弱（ぜいじゃく）性を悪用すれば、攻撃者は悪意あるページを介して、Slackユーザーのアカウントにフルアクセスできたという。双方向通信プロトコル「WebSocket」を悪意あるサイトにリダイレクトし、その過程でユーザーのセッショントークンを盗み出す方法だ。

併せて読みたいお薦め記事

拡大するSlack導入現場

認証を巡るセキュリティリスク

　ローゼン氏は最初、SlackアプリケーションのWebブラウザ版でこの問題を発見した。Slackに報告したところ、バグを5時間足らずで修正したという。ローゼン氏はこの件で、Slackのバグ報奨金プログラムから3000ドルを受け取った。

　このセキュリティホールを利用する攻撃が成立し得た最大の理由は、クロスドメイン通信の実行時にアプリケーションがメッセージを適切に検証していなかった点にある。攻撃者はこの弱点を突き、悪意あるリンクを作成して、自身が用意したページにユーザーを誘導できた。その上で、誘導先のサイトにおいて、自分がSlackにログインしていると思い込んでいるユーザーから認証トークンを盗み出すという手法だ。攻撃では、Slackが通信に利用するPostMessage関数とWebSocketプロトコルを使用していた。

　この攻撃の基本的な流れは以下の通りだ。

攻撃者は攻撃用のWebサーバを用意
そのサーバにリダイレクトされるトークンを待ち受ける
アプリケーションの認証に使われたトークンをダンプする
ダンプしたトークンを使って悪意あるリンクをクリックしたユーザーになりすます

　メッセージのオリジンを検証しないせいで、Slackはこうしたリダイレクトやトークンの盗難が可能な状態にあった。

　この攻撃の阻止という点で、セッションの暗号化が何ら役割を果たさなかったのは興味深い点だ。トークンの盗難を暗号化によって阻止できなかったのは、ユーザー本人が適切にログインしているかのように見えたからだ。アプリケーションからすれば、何も問題は起きておらず、認証は適切に実行されていた。検証の手順が欠けていたおかげで、攻撃者はトークンを入手し、それを自分のものとして再利用できた。

　今回のセキュリティホールが明らかになったときに、Slackが非常に迅速に対応し、わずか数時間でバグを修正したのは特筆すべき点だ。Slackのプラットフォームは企業のプロジェクトやチャットログなど機密性の高い情報もホスティングしていることから、Slackはセキュリティ強化に力を入れている。

　今回のようにバグの報告に迅速に対応することで、Slackは自社製品のセキュリティレベルに対するユーザーの信頼を一層高めることができる。バグ報奨金プログラムの実施は、ハッカーのコミュニティーにアプリケーションのストレステストをしてもらう良い方法といえる。今回Slackのセキュリティホールが悪意ある攻撃者が利用する前に発見して修正できたのも、Slackがバグ報奨金プログラムを実施したからといえるだろう。

印刷する