2017/09/22

特殊なハッキング方法 – チケットトリック

cracker hacker cyber 攻撃 侵入
2017 年 9 月 22 日 Marc Laliberte 著

多くの職場に、コミュニケーションツールやコラボレーションツールが急速に浸透しています。Yammer や Slack などのアプリケーションは、プライベートチャットルームとしての役割を果たし、従業員同士が進行中のプロジェクトについて議論したり、機密性の高い情報を伝達したりする目的で使用されます。これらのツールは通常、使いやすさを考慮して設計されています。そのため、会社の電子メールアドレスを使って登録するだけで、これらのツールにアクセスし、社内のディスカッションにアクセスできるようになる場合も多いようです。登録の手順を実行すると、コミュニケーションツールから会社のアドレスにメールが送信され、リンクをクリックすると、アカウントの確認が完了します。登録作業はこれで終了し、メールのリンクをクリックする以外の確認手順は必要ありません。

社内のグループに登録する際に @[company] というメールアドレスを要求するようにしておけば、セキュリティ対策として十分だと思えるかもしれません。けれども、ソーシャルエンジニアリングや古くからあるハッキング方法を駆使することなく、社外の誰かに会社のアカウントにアクセスされてしまう恐れは絶対にないのでしょうか。残念ながら、研究者の Inti De Ceukelaire 氏が、発見し、公開した、少し特殊な方法を使うと、このセキュリティチェックを回避できるようです。De Ceukelaire 氏はこの方法を、「チケットトリック」と呼んでいます。

チケットトリックという名前は、会社の専用コミュニケーションルームにアクセスする目的で使用される、ヘルプデスクやサポートの「チケット発効」ツールに由来しています。たとえば、gitlab.com では、プロジェクト専用の @gitlab.com 電子メールアドレスにメールを送信することで、バグチケットを作成します。このアドレスに送信されたメールは、その GitLab プロジェクトにアクセスできる全員が閲覧する、そのプロジェクトの「issues」セクションの下に自動的に表示されます。つまり、Gitlab プロジェクトを作成できる人は @gitlab.com のメールアドレスへの読み取りアクセスが可能だということです。

GitLab には、専用の Slack チャネルもあり、De Ceukelaire 氏の研究が公開されるまでは、@gitlab.com のメールアドレスを持つ誰もが、自分のメールアドレスに送信されてくる確認リンクをクリックすることで自動的にアクセスできるようになっていました。De Ceukelaire 氏は、自分の GitLab プロジェクト用のチケット作成メールアドレスを使って GitLab 専用の Slack チャンネルに登録できることを発見しました。そして、Slack からチケット作成用アドレスに確認が送信され、プロジェクトの「issues」追跡セクションの下に表示されました。この確認リンクをクリックしたところ、GitLab 専用の Slack コミュニケーションへの無制限のアクセスが可能であることがわかりました。

De Ceukelaire 氏は、Yammer、Facebook Workplace、Kayako、Zendesk などのツールにも、同様の脆弱性を発見しました。この一連の調査・研究で、チャットツール(主に、サポートへの連絡に使用するツール)で使用される @[company] アドレスへのアクセスを可能にする、少し特殊な方法がいくつかあることがわかりました。以上を踏まえて、同氏は、チケットトリックから会社を保護するためのいくつかの方法を推奨しています。

まず初めに、メールによる検証を必須にし、その後に、メールで作成されたサポートチケットにユーザがアクセスできるようにします。De Ceukelaire 氏が説明しているように、この脆弱性は、メールでサポートチケットを作成できる場合や、ユーザが検証済みでない電子メールアドレスでサポートチケットにアクセスできる場合に存在するものです。

次に、メールによるチケットの作成を許可する場合に、専用のサブドメイン名(@reply.company.com や @support.company.com)などを使用することを検討します。コミュニケーションツールへのアクセスを親ドメイン(@company.com)だけに制限すれば、サブドメインに送信される電子メールによってプライベートのディスカッショングループへの自動アクセスが許可されることはありません。

最後に、ビジネス用のコミュニケーションソフトウェアを開発するベンダに対しては、確認メールの送信元アドレスを生成する際に、notification+[random_text]@company.com などのランダムなトークンを入れるようにすることが推奨されます。こうすることで、攻撃者に送信元アドレスを簡単に推測され、そのアドレスを使って標的とする会社にサポートアカウントを登録されてしまうのを回避できます。– Marc Laliberte