実際の攻撃が発生し情報漏洩が起こったケース。
ホワイトハッカーの報告ではないので、目にした記事が正しいという前提でまとめてみます。

Trelloとは？

SaaSのタスク管理ツールです。
カンバン方式のタスク管理用スペースを簡単に立ち上げられる便利なツールです。

攻撃の結果起こったこと

15万ユーザーの情報が販売されていました。

Trelloから抜かれた情報はメールアドレス、フルネーム、ユーザー名と、直接漏洩した項目はあまりおおくありません。
特徴的なのはTrelloではない別のAPIから抜き出したデータを集約し、そのユーザーが他にどんなツールを使っているか、どんな背景を持っているかなどが推測できるようしたものとなっている点です。

単純なTrelloの情報漏洩というよりは、Trelloを踏み台にした他への攻撃の基礎データになりうるものとして加工されていると考えて良いと思います。

攻撃手法

データを抜いた人がどのように攻撃したかはこちらが詳しいです。

これはシンプルで、

• 事前に5億個のメールアドレスのリストを用意した

• リストにあるメールアドレスをTrelloのAPIにクエリしてヒットしたものを抜き出した

というものです。

5億個のメールアドレスは、ダークウェブで販売されていたものなどを活用したのではと言われています。
Trello以前に他のツールなどへの攻撃で抜き出されたものと思われます。

悪用されたTrello APIの仕組み

1. ユーザーの基本情報 (メールアドレス、フルネーム、ユーザー名) が認証なしでアクセスできた

なぜそもそも基本情報が認証なしでアクセスできてしまうのかという点ですが、Trelloのアクセス権の性質によるものと思います。
記事から引用します。

Trelloにはタスクを格納するスペースであるボードへのPublicアクセスが可能なんです。
Trelloの操作画面によると、アクセス権のPublicというものは

となっています。
URLさえわかればボードを参照できるが、編集はボードのメンバーとして登録されているユーザーのみとなっていますので、編集には認証が必要だということのようです。

このアクセス権ですと、参照のみでアクセスした認証していないユーザーがボードの情報を参照できますが、この時に例えばタスクの担当者が誰かなどが見える必要がありますね。
おそらくこのユースケースのために認証がかかっていなかったのではないかと思われます。

なお現在ではユーザーの基本情報も認証していないとアクセスできない状態に切り替わっているそうです。

Trello側はあくまで「Publicなデータなので問題ない」という反応だったのですが、では本当にユーザー名やメールアドレスがPublicでよかったのかという点は気になりました。

2. 流量制御の仕組みを把握されて悪用されてしまった

流量制御の仕組みは把握されると突破されることが可能になってしまうという例としてコメントしたいと思います。

流量制御とは特定の時間の長さあたりのアクセス数に上限を設け、それ以上の頻度でアクセスがあった時には何らかの形でアクセスを絞ることを指します。
例えば同じIPアドレスからのアクセスが秒間10回以上あったらアクセスしすぎなのでそれ以上のアクセスを許容せず遮断する、などです。
これに引っかかった時に組織によってはSOC (セキュリティ監視チーム) への通報やログを残してトラッキングできるようにするなどの対策を取ることもあります。

今回攻撃側はTrelloの流量制御がIPアドレスを使った流量制御であることを把握しており、流量制御に引っかからないように複数のProxyサーバーをローテーションして流量制御に引っかからないようにデータを抽出したそうです。

実際Trello側は報告により情報が流出していることは把握できたものの、システムから攻撃の形跡を追うことができなかったとか。

普通と違う挙動を検知する仕組みが必要になってきた

API脆弱性の調査はただの個人的な趣味なので、認識している件数は専門家ほど多くはありません。
しかし印象としてだんだん事例として見つかるものが高度化してきた印象を受けています。
以前は認証がそもそもなかったとか、流量制御がかかってないとか、そう言った基本的なものが多かったですが、現在はユースケース固有の盲点をついたものが増えてきているように思います。

認証の世界では昔認証 (IDパスワードのマッチング) ができれば十分だという世界から、現在では普通と違う挙動が検知できて当たり前の世界になってきました。

例えば会社で使うようなもの、Microsoft 365やGoogle Suiteなどが早かったかと思いますが、新しいデバイスでのログインなどがメールで通知され、注意喚起されますよね。
TwitterやFacebookなど、会社で使わないようなものもそう言った注意喚起のメールが当たり前になってきました。

このように、IDとパスワードが合致しても、通常と違う挙動を検知してアクセスをブロックしたり、アカウントのオーナーに注意喚起をするような仕組みを「リスクベース認証」と呼びます。

APIの世界でも同じように、認証のみならず認可に至るまで、リスクベースでの検知が必要になってきているのだと思います。

ただこの場合認証と違って難しいのは、ユースケースありきでAPIごとに違う対応を求められるからなんです。

認証は割とシステム後の独自性が出にくいところですよね。したがって早期にソリューションとして提供され始め、検知の観点や精度が専門家によりどんどん上げられている領域かと思います。

認可の部分はユースケースごとに何が正常アクセスの範囲かを定義しなければならず、独自色の強いところです。
自分たちのAPIやAPIが提供する機能をきちんと把握し、ユーザーの利用シナリオを把握した上での盲点がどこかと言った分析が必要になってきています。

その他参考情報

Trelloのコメントや、Trelloのボードのアクセス権「Public」のリスクに関する注意喚起の記事 (2022) へのリンクがあります。

ユーザー情報を認証なしで漏らしてしまう可能性のあるものとして、パスワードを忘れた場合のリセット機能について触れています。

https://telefonicatech.com/en/blog/trello-platform-information-leakage-analysis

Redditで自分のデータが漏洩されたデータに入っているか確認する方法をディスカッションしているもの。本件に関するユーザーの反応などが見えて面白い。

https://www.reddit.com/r/trello/comments/19dgj7u/have_trello_been_hacked_breached/

Trelloが今回のデータはPublic Dataだと言っているが、本当にPublic Data扱いで良いのかという点に着目した記事。

本件に関するAPIセキュリティの専門家のコメントや対策。