OAuthにおける認可コード横取り攻撃とその対策
OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア
カスタムURLスキームの乗っ取りとその対策
カスタムURLスキームの乗っ取りとその対策 May 17, 2021 カスタムURLスキームは、モバイルアプリ内のコンテンツへ直接誘導するディープリンクに広く利用されている¹。そのような中で、2020年3月にLINEはカスタムURLスキーム line:// の使用を非推奨とした²。非推奨の理由をLINEは「乗っ取り攻撃が可能なため」と説明し、代わりにHTTP URLスキームによるリンクを推奨している。この変更に対して私は、なぜHTTP URLスキームによるリンクだと乗っ取り攻撃を防げるのか疑問を抱いた。この疑問に答えるためにLINEアプリの乗っ取りを試み、対策の有効性を確認した。 要約 HTTP URLスキームによるディープリンクは対象のアプリを一意に特定できるため、不正アプリによるリンクの乗っ取りが発生しない。カスタムURLスキームでは複数のアプリが同じスキームを宣言できるため、モバイル
SMS OTPの自動入力によるリスクとその対策
フィッシングサイトへの自動入力のリスク SMS OTPとWebサイトが紐付かない状態では、正規のSMS OTPがフィッシングサイトへ自動入力されるリスクが生じる。現実的なリスクとして、GutmannらはMITMと組み合わせた「ログインにおける2要素認証の回避」と「ソーシャルログインの偽装による電話番号確認の回避」、「オンライン決済における取引認証の回避」の3つのシナリオを示している⁷。2要素認証の回避につながるリスクは、iOSの自動入力がPayPayの偽サイトで発動した前回の検証で確認している。今回の検証ではAndroidの自動入力がPayPalの偽サイトで発動するか確認する。 2要素認証の回避 PayPalの偽サイトは前回と同様にMITMフィッシングフレームワーク「Evilginx2」で複製し、一般利用者が誤ってアクセスしないようインバウンド接続を制御した。Android 11のChro
Slackで認定されたURLリンク偽装の脆弱性
Slackで認定されたURLリンク偽装の脆弱性 Apr 27, 2020 フィッシング詐欺における偽サイトへの誘導では、正規サイトのURLをかたってリンクをクリックさせる手口が後を絶たない。この手口は主にメールや掲示板からの誘導で悪用されるが、グループチャット内でもURLリンクを偽装できれば脅威になると考えた。ビジネスチャットツールとして世界的に利用されているSlackでのURLリンク偽装（#481472）について解説する。 URLリンクの偽装 HTMLでは、ハイパーリンクとして表示するURLと、実際にリンクするURLを個別に設定できる。例えば、以下のHTMLはレンダリングにより https://example.com となる。表示上は example.com へのリンクに見えるが、実際には akaki.io へリンクする。 <a href="https://akaki.io">https
Yahoo! JAPAN IDに登録された電話番号の列挙
Yahoo! JAPAN IDに登録された電話番号の列挙 Feb 3, 2020 Webサービスのアカウントに登録されている携帯電話番号を特定できれば、そのサービスの利用者を標的としたスミッシング（SMSフィッシング）が可能になると考えた。日本最大級のポータルサイトである「Yahoo! JAPAN」のアカウントリカバリー機能では、Yahoo! JAPAN IDに登録した電話番号からアカウントの存在を確認できる。この機能の挙動を利用して他人のIDに紐づく電話番号を列挙できる状態だった。発見した脆弱性はYJ-CSIRTへ報告し、既に修正されている。 ユーザー列挙の脆弱性 入力値の違いにより生じるエラーメッセージや応答時間などの差異を手がかりに、アカウントの識別情報を収集する行為を「ユーザー列挙（User Enumeration）」という。例えばアカウントを登録する際に以下のようなエラーが発生し
SMSで送信元を偽装したメッセージを送る
送信元表記が送信者IDのケース SMSのメッセージを受信した際に表示される送信元には、電話番号の代わりに任意の英数字も表記できる。この英数字の送信元表記を「送信者ID（Sender ID）」という。JC3の図では 通信事業者Ａ が送信者IDに当たる。 なお送信者IDの利用可否は受信側の通信事業者の対応状況によって異なる。Twilioの販売パートナーであるKWCの説明によると、日本国内ではNTT DOCOMOとSoftBankが送信者IDに対応し、KDDIは対応していないとのこと²。私はKDDIの回線を所有していないため、受信側がKDDIの電話番号を使用している場合の挙動は検証できていない。 まずはiOSの公式メッセージアプリに届いていたAmazonからのメッセージのスレッドで偽装を試みる。送信者IDは Amazon となっているため、TwilioでSMSを送信する際のFromの値に Ama
オリジンIPの特定によるクラウド型WAFのバイパス
オリジンIPの特定によるクラウド型WAFのバイパス May 27, 2019 昨年末に「How i was able to pwned application by Bypassing Cloudflare WAF」を読んで、CloudflareのWAFをバイパスする方法とそれがバグバウンティで認定された事例を知った。記事を書いた@vis_hacker氏は調査に「CloudFlair」というツールを使用しており、このツールを開発した@christophetd氏も同様の方法で報奨金を獲得していた¹。 Cloudflareに限らずクラウド型WAFのバイパスは2016年頃には既に話題になっており、論文も書かれていた²。2013年のBlackHat USAではDDoS保護のバイパスとして発表され³、DDoS保護サービスを提供するベンダーが注意喚起を行なっている⁴ ⁵。脆弱性として興味深かったので詳
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
