韓国最大のモバイルチャットアプリで発見されたワンクリック・エクスプロイト
(stulle123.github.io)- KakaoTalk Androidアプリでは、ディープリンク、WebView、XSSが組み合わさることで、ユーザーが悪意あるリンクを一度クリックするだけでアクセストークンの漏えいからアカウント乗っ取りにまで至る可能性があった
- 中核となる侵入口はKakaoTalk
10.4.3のCommerceBuyActivityWebViewで、ディープリンク検証の不備とJavaScriptの有効化、Authorizationヘッダーの露出が重なって問題を引き起こしていた - 攻撃チェーンは
buy.kakao.comのリダイレクトとm.shoppinghow.kakao.comの DOM XSS を利用し、WebView内で任意のJavaScriptを実行する仕組みだった - 漏えいしたトークンは、Kakao Mailへのアクセス、パスワード再設定、Windows/Mac向けKakaoTalkまたは KiwiTalk クライアントの登録に利用できた
- 脆弱性には CVE-2023-51219 が割り当てられ、報告後にKakao Corp.は
buy.kakao.comを停止し、関連するリダイレクトと脆弱なCommerceBuyActivityを削除した
脆弱性の範囲と前提
- KakaoTalkはGoogle Play Storeで1億回以上ダウンロードされている韓国を代表するチャットアプリであり、決済、配車、ショッピング、メールなどを含むオールインワンアプリの性格を持つ
- 通常のチャットルームではエンドツーエンド暗号化（E2EE）がデフォルトで有効になっておらず、Kakao Corp.が送信中のメッセージにアクセスできる構造となっている
- オプションのE2EE機能である Secure Chat は存在するが、グループメッセージングや音声通話には対応していない
- PoCの目標は、被害者アカウントにKakaoTalk for Windows/macOSまたはオープンソースクライアント KiwiTalk を登録し、非エンドツーエンド暗号化チャットメッセージを読むことだった
侵入口: CommerceBuyActivity WebView
CommerceBuyActivityWebViewは、攻撃者に有利な条件をいくつも備えていた- 外部公開（exported）されており、
kakaotalk://buyのようなディープリンクで起動できる settings.setJavaScriptEnabled(true)によりJavaScriptが有効化されている- JavaScriptから
intent://スキームを通じて、外部公開されていないアプリコンポーネントにもデータを送ることができる intent://URIのComponentやSelectorがnullに整理されず、URI処理も不十分だった
- 外部公開（exported）されており、
- このWebViewはHTTPリクエストの
Authorizationヘッダーにアクセストークンを載せて送信していた - WebViewデバッグが有効になっていたため、
chrome://inspectで挙動を確認でき、外部アドレスへ移動させるとGETリクエストとともにAuthorizationヘッダーが露出した - 攻撃者がこのWebView内でJavaScriptを実行できれば、悪意ある
kakaotalk://buyディープリンクをクリックさせるだけで、ユーザーのアクセストークンを盗むことができた
URL検証の回避とDOM XSSの連結
CommerceBuyActivityは任意の攻撃者URLを直接読み込むのではなく、入力されたディープリンクをhttps://buy.kakao.comで始まるURLに組み立てていた- たとえば
kakaotalk://buy/fooはhttps://buy.kakao.com/fooとして読み込まれる - パス、クエリパラメータ、fragmentは攻撃者が制御できた
- たとえば
https://buy.kakao.com/auth/0/cleanFrontRedirect?returnUrl=エンドポイントは任意のkakao.comドメインへリダイレクトできたため、kakao.comサブドメイン上でXSSを探す攻撃範囲が広がっていたm.shoppinghow.kakao.comでは、検索クエリがinnerHTMLsinkに渡されるエンドポイントが見つかり、簡単なペイロードで DOM XSS が可能だった- 以前存在していた保存型XSSも見つかったが、2024年5月時点では修正済みとみられることが明記されている
- この組み合わせにより、ユーザーが悪意あるディープリンクをクリックすると
CommerceBuyActivityWebView内で任意のJavaScriptが実行され、Authorizationヘッダーのアクセストークンを外部へ送信できた
トークンでKakao Mailとアカウント再設定にアクセス
- 漏えいしたKakaoTalkアクセストークンは、被害者の Kakao Mail アカウントへのアクセスに利用できた
- 被害者がKakao Mailを使用しているか確認したうえで、別のトークンを取得し
talk.mail.kakao.comにアクセスする流れが可能だった - 被害者にKakao Mailアカウントがなくても、被害者名義で新しいアカウントを作成でき、新しいメールアドレス作成時に
Set As Primary Emailを選ぶと、既存の登録メールアドレスが追加確認なしで上書きされる可能性があった - Kakao Mailへのアクセス後、次の段階は KakaoTalkパスワードの再設定 だった
- 追加で必要となる被害者のメールアドレス、ニックネーム、電話番号は、同じアカウント設定API呼び出しから取得できた
accounts.kakao.comのパスワード再設定プロセスにはSMS 2FAがあったが、Burpでリクエストとレスポンスを傍受・改変し、メール認証フローへ切り替えることができた- 認証コードは被害者のKakao Mailで確認できた
PCクライアント登録とメッセージアクセス
- 被害者の認証情報でKakaoTalk for Windows/macOSまたはKiwiTalkにログインすると、第二認証要素が必要だった
- この認証は4桁PIN方式で、PINがPC版に表示されてモバイルアプリに入力されるか、逆にモバイルアプリに送信されてPCアプリに入力される仕組みだった
- PINは総当たりしにくく、関連エンドポイントには5回試行後にブロックされるレート制限があった
- しかし漏えいしたアクセストークンを使うことで、KakaoTalkバックエンドにPINを送信または照会できた
- この過程により、攻撃者が制御するデバイスを被害者のKakaoTalkアカウントに登録し、エンドツーエンド暗号化されていないチャットメッセージを読むPoCが完成した
公開、修正、研究資料
- 脆弱性には CVE-2023-51219 が割り当てられている
- 研究者は、ほかのセキュリティ研究者がKakaoTalkの広い攻撃面を分析できるよう ツール を公開した
- 脆弱性は2023年12月、Kakao Bug Bounty Program を通じて報告された
- 報告者は、報奨の対象が韓国人に限定されていたため、報奨は受け取れなかったと明かしている
- Kakao Corp.は直ちに
https://buy.kakao.comを停止し、/auth/0/cleanFrontRedirect?returnUrl=リダイレクトを削除し、その後のバージョンで脆弱なCommerceBuyActivityも削除した
1件のコメント
Hacker Newsのコメント
特にドメインが正規に見える脆弱性なら、祖母が怪しいリンクに気づくのは難しく、韓国のヒエラルキー的な職場文化も一役買っていると思います
上司が機能の締め切りを交渉不能な形で投げてきて、セキュリティ脆弱性は目に見えない一方でUIは見えるので、適当に削ってリリースすることになります
結局、セキュリティホールの多いアプリになり、Kakaoの株価が下がるまではまともに直さない気がします
セキュリティ面は韓国の職場文化のせいというより、いわゆる「ネカラクベ」としてまとめられるNaver、Kakao、LINE、Coupang、Woowa Brosのような主要IT企業は、平均よりはるかに良い職場文化と報酬を持つ傾向があるからだと思います
おそらく国内向けアプリなので、世界的に人気のあるアプリほど十分に検証されていないというほうが近いです。ただし私の経験では、報酬は米国や一部の韓国スタートアップより低かったです
違いは、韓国では政府部門と財閥がIT市場の大きな割合を占めていて、スタートアップ文化が違いを生み出す余地があまりない点に見えます
Kakaoもかつては格好いいスタートアップでしたが、成功してからは財閥をまねようと努めてきたように感じます
文化のせいで韓国ではより深刻かもしれませんが、西側でも確実に起きており、実質的には普遍的な問題に近いです
米国のある程度の規模のホワイトカラー企業、とくにテック・金融・コンサルティングやFAANGで数年働けば、西側も同じだと分かります
中堅エンジニアたちは次の昇進サイクルに乗るためにVPに同調し、企業は「フラットな組織」というマーケティングがうまいだけで、実際には宣伝文句に近いです
PMやSVPが指示を出すと、誰も正面から問いたださず、不満を言いながら実行することが多く、こうした企業文化マーケティングをそのまま信じる態度が浅い優越感につながっているのがさらに苦いところです
最近ソウルを旅行したとき、そのアプリにログインするためにモバイルチャットアプリのアカウントを作る必要があり、ユーザー体験も良くなく、ほとんどが韓国語だったのでかなり苦労しました
あまりプロフェッショナルな運営という印象は受けませんでした
KakaoTalkとNaverが、西側のWhatsApp/MetaやGoogleのような役割をほぼ担っていました
多国籍企業との競争が大きくなったにもかかわらず生き残っているのは立派だと思います。他の多くの国ではこの10年で現地のテック企業がほとんど意味を失ってしまい、それは残念なことです
そのため路上でタクシーを拾うのも難しく、ほとんどがアプリで呼んだ客だけを乗せているように見えました
一度、ようやくタクシー運転手と接触できたのですが、「外国人」だから乗せないと言われました。本当に差別だったのか、現金払いが嫌だったのか、韓国語が通じなかったからなのか、誤解だったのかは分かりません
後で成功したタクシー乗車も、街の反対側へ山を越えていく経路になってしまい、デートしていた相手に電話して、運転手に道が違うと説明してもらう必要がありました。準備不足で見知らぬ国に行くと起こるリスクだと思います
2015年初めに訪れたときのGoogleがその例でした
韓国のアプリが何語であることを期待していたのでしょうか、フランス語ですか？
ただ、本物のUberというより、Uberのインターフェースを使うKakaoTaxiプロキシに近いと理解しています
メインのチャットアプリにギフト機能のような今回の脆弱性を可能にした付加機能はありますが、タクシー配車はKakaoTalkではなく、レンタルスクーター、電動自転車、鉄道・航空券予約も提供するモビリティアプリKakao Tで行います
決済プラットフォームKakaoPayとの連携はありますが、サービス自体は別アプリにあり、中央IDで複数サービスにアクセスするAndroidのGoogleにより近いです
そのため、アプリにアクセス地点が多い理由も自社サービス連携のためだと思います
WeChatのように、KakaoPayはKakaoTalkに十分統合されているので、大多数のユーザーはKakaoPayアプリではなくKakaoTalk内だけでKakaoPayを使います
別個のKakaoPayアプリがあるという事実は大きな影響がなく、KakaoPayアプリなしでもKakaoTalkで送金、受け取り、決済ができます
ふたを開けてみると、そのクライアントは誤ったユーザーにメッセージを見せるバグだらけでした
モバイルチャットアプリは「速く動いて壊す」式で開発すべきではなく、Kakaoのようなオールインワンアプリの自然な結果がこういう姿なのだと思います
そうでないなら、クライアントのバグというよりサーバーバグに近いように見えます
そしてTelegramは、これまで使ったチャットアプリの中で最も安定しており、機能が豊富で、使いやすい部類でした
「国内外に居住する韓国人」でなければならないとされています
https://bugbounty.kakao.com/home
お金を受け取れると思って提出し、後から韓国市民権者に限定されると知ったのなら、もっと悪かったでしょう
付け加えると、報奨金も非常に低く、最低5万ウォン、約35ドルから最高1,000万ウォン、約7,100ドル程度です
外国人としてこの9年間ソウルでスタートアップを作りながら、似たようなことを何度も経験しました
長期戦のためのものなのか、少数に戻る短期的利益のためのものなのかを見極めるべきです
実環境で悪用されたことは知られているのでしょうか？