APIの認証機能とかはっきり言って実装はめんどくさい。そしてAPIの仕様を公開しなければなかなかバレない。TLSがかかっていればスニッファーでも簡単には見る事はできない。そう考えるとますます実装が億劫になる。なので後回しになっていたと見た。しかしなぜ発表し謝罪したのか？最初に報道したのはどこだ？なんか内部の人間がリークしたんじゃないかと踏んでいる。
Conversation
Notices
-
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 00:09:08 JST 
まめも
-
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 00:13:09 JST
まめも
@h12o 具体的なITの知識が記載されていないし、TLSはかけていて漏洩はないといっている。これらの情報からAPIの認証がかかってなかったと思われる。つまりAPIの仕様がわかればいくらでもデータがぶっこぬけたんだろう。
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 00:13:10 JST 
h12o
@mamemomonga
>>
しかし、複数の関係者によりますと、このアプリはサービス開始の時点からセキュリティー対策が不十分で、少なくとも230万人分以上のユーザーの位置情報やチャット上のやりとりの履歴などが一時、一定のITの知識があれば外部から閲覧可能な状態になっていたことがわかりました。開発した「Suishow」は、去年12月から複数回にわたって指摘を受け、事態を認識していましたが、チャットの履歴はことし3月まで、位置情報の履歴は少なくとも4月末まで外部から閲覧可能な状態が続いていたということです。
また、国の個人情報保護委員会などへの報告や利用者への通知も行っていなかったということです。
<<
https://www3.nhk.or.jp/news/html/20231021/k10014232891000.html -
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 00:14:59 JST
まめも
@h12o まあその「複数の関係者」からのリークだろうね。
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 00:44:02 JST
h12o
@mamemomonga 私は、「認証の不備」ではなく「認可制御の不備」の方が確率的に高いと思っています。
APIへのアクセスは、ログイン済みユーザーアカウントごとにBearerトークンを生成してHTTPリクエストに載せる方が一般的で、これは「APIの認証がかかって」いる状態ですが、「SSL/TLSを利用したモバイルアプリの通信を傍受し解析する知識」があれば解析は可能です。
この前提で脆弱性が成立するかどうかは、認可制御が正しく行われているかどうかが鍵です。
認可制御が正しく行われていない典型的な例は、ユーザーアカウントが連続した数値で表現されていて、APIのパラメータでそれを指定する場合です。たとえばまめもさんがID=10000、h12oがID=10001だとして、パラメータの10000を10001にかきかえればまめもさんがまめもさんの認証情報で（h12oの認証情報を使わずに）h12oの情報を取得できることになります。
-
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 00:44:02 JST
まめも
@h12o Bearerトークンは普通何らかのhash化が施されるから解析できないんじゃないですかね？シリアル値をそのまま入れるような運用がされてたと考えるということですか？
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 00:44:10 JST
h12o
@mamemomonga とおっしゃるのはこのへんを元にしていますでしょうか?
>>
アクセス可能だった時期と情報、影響囲の推定値は下記の通り。ただし、いずれも実際に情報が漏えいした事実は確認できなかったとしている。
<<>>
「SSL/TLS（データを暗号化して送受信する仕組み）を利用したモバイルアプリの通信を傍受し解析する知識と、クラウドサービスのAPIへのリクエストを組み立てるための知識」があれば、データベースに不正にアクセスできる状態だった
<<
https://www.itmedia.co.jp/news/articles/2312/07/news174.html「APIの認証がかかってなかった」とまでは言い切れないように思います。「SSL/TLSを利用したモバイルアプリの通信を傍受し解析する知識」があれば、認証情報ごと傍受し解析することができます。認証情報がアプリにハードコードされていたのだとしたら認証があるようでないに等しいので「APIの仕様がわかればいくらでもデータがぶっこぬけた」と言えます。（つづく）
-
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 00:49:21 JST
まめも
@h12o Bearerトークンでの認証がユーザの認証と紐づいておらず、その後全てのクエリに答えるようになっていたという事ですか？
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 00:49:22 JST
h12o
@mamemomonga 認可制御の不備であれば、Bearerトークンそのものを解析する必要はありません。APIリクエストに正しいBearerトークンを載せればいいだけで、それは攻撃者が自身の認証を通せばいいからです。
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 01:05:22 JST
h12o
@mamemomonga 「APIの認証がかかってなかった」と言い切れないだけで、実は本当にAPIの認証がかかってなかったことも考えられはしますが、一方で、「（ログインしているユーザー以外のデータであっても）全ての（ユーザーのデータを引っ張ってこれる）クエリに答えるようになっていた」ことも考えられます。
たとえば`/api/v1/:uid/matchingapplist?format=json`というAPI（`:uid`は利用者のID）でインストールされているマッチングアプリの一覧が取得できるとします。
まめもさんがuid=10000、h12oがuid=10001だとして、まめもさんがまめもさんとして認証された状態で、それに紐づいたBearerトークンを使って、`/api/v1/10001/matchingapplist?format=json`にクエリを出して、h12oのmatchingapplistが取れてしまったら、これは認可制御の不備ということになります。
-
Embed this notice
h12o (h12o@mastodon.tokyo)'s status on Friday, 08-Dec-2023 01:07:30 JST
h12o
@mamemomonga そして、こういう実装は割とありがちです。理由は、認可制御マトリックスを正しく作ってテストすることが面倒だからで、「実装が億劫になる。なので後回しになっていた」のではないかな、という想像自体は自然なことだと思います。
-
Embed this notice
まめも (mamemomonga@momo.mame.moe)'s status on Friday, 08-Dec-2023 01:07:30 JST
まめも
@h12o いずれにしても、それらの不備を内部で指摘されても後回しにして一向に対応しなかったから今回のリーク起こったのではないかというのが今回の件の最も興味深い点です。
-
Embed this notice
All GNU social JP content and data are available under the