単純な入力../smsを使用すると、authy.comを介して2FAを使用するサイトで2番目の要素をバイパスできます（ そして、それらのかなりの数があります ）。
最も興味深いのは、そのような迷惑な脆弱性がAuthyのせいではなく現れたことであり、幸運にもこの一連のバグを発見しました。
そのため、authyを使用するプロセスは簡単で、2つのAPI呼び出しで構成されます： api.authy.com/protected/json/sms/AUTHY_ID?api_key=KEYは新しいトークンを要求し、 api.authy.com / protected / json / verify / SUPPLIED_TOKEN / AUTHY_ID？Api_key = KEYは、ユーザーから受信したトークンを確認します。 両方の呼び出しが200ステータスを返す必要があり、リクエストは成功したと見なされます。
1.すべては、SDKライブラリのチェックから始まりました。 authy-nodeを除くすべてが正常に見えます。authy-nodeは、URLに挿入する前にトークンをエンコードしませんでした-this._request（ "get"、 "/ protected / json / verify /" + token + "/" + id、{}、callback、qs ）;
トークンフィールドにVALID_TOKEN_FOR_OTHER_AUTHY_ID / OTHER_AUTH_ID＃を挿入し、APIリクエストを書き換えて、常に200ステータスを返すようにすることができました。これは、2番目のステップの確認と見なされ、攻撃者がアカウントに入ることを許可しました。 実際には、＃以降はすべてフラグメントと見なされ、サーバーに送信されず、/ protected / json / verify / VALID_TOKEN_FOR_OTHER_AUTHY_ID / OTHER_AUTH_IDの形式のリクエストは200を返し、通常のリクエストと区別できません。
2.その後、authy-pythonで興味深いバグが見つかりました。urllib.quoteは、スラッシュ以外のすべての記号をエンコードしました（理由はわかりません）。 うーん、スラッシュで何ができますか？ たぶん/../を挿入してみてください？ ご存知のように、/ .. /、/％2e％2e /、さらに/％252e％252e /は、ブラウザーで「1つのディレクトリに移動する」ことを意味します。 ただし、サーバーにはこのような機能は絶対に必要ありません。 ただし、テストのために../smsを送信することにしました。 理由はまだわかりませんが、.. / smsを挿入して、呼び出しを/ sms呼び出し（/verify/../sms/authy_id）に変更/検証し、200を返してアカウントに入れました。
3.そして、最近、Authyアーキテクチャに関するDanielのインタビューを読んだことを思い出しました。 AuthyはSinatraを使用しており、Sinatraはラック保護をドラッグしていると言いました。これには、私が思い出すように、path_traversalというモジュールがありました。
ここで最も興味深いのは、 何らかの理由で path_traversalがパスをデコードし、 / .. /の前にディレクトリを削除したことが判明したことです。 理論的には、これは潜在的なパストラバーサルの脆弱性から開発者を保護することになっています。 実際には、これがこのような深刻な脆弱性の原因となっています。
だから、順番に：
1.トークンフィールドに../smsと入力します
2.クライアントはこれを..％2fsmsとしてエンコードし、 api.authy.com / protected / json / verify /..% 2fsms / authy_idにリクエストを行います
3. path_traversalは、api.authy.com / protected / json / verify /../ sms / authy_idの早い段階で受信したURLをデコードし、すべてを/で除算し、/ verifyディレクトリを削除します
4.これで、アプリケーション自体が修正されたパスapi.authy.com/protected/json/sms/authy_idを受信します。このパスはSMSを被害者に送信し、200のステータスと応答を返します{"success"：true、 "message"： "SMSトークンが送信されました"、 "携帯電話 "：" + 1-XXX-XXX-XX85 "}
5.トークンを確認したいクライアントは、200ステータスを確認し、トークンが正しいと結論付けます。 APIのカスタム実装を使用する場合でも、クライアントはsuccess = trueを探している可能性が高く、これも回答に含まれています。
トークンフィールドに../smsを入力するだけで、Authyを使用してすべてのサイトで2要素認証をバイパスできます。
記号の挿入による最初の要因の回避に関する同様の脆弱性に関する別の素晴らしいテキストがあります| 別の人気のある2FAプロバイダーDuo Securityでは、私はそれを翻訳するのが面倒です 。
ハッカーを探しているリンクがありましたが、削除されました。 朝の演習中にこの種の脆弱性を見つけた場合は、個人のメールに書いてください。