それで、共同採掘のための最大のプールの1つであるViaBTC Poolを訪れました。 選択はランダムで、下の図に基づいています。
このチャートは、2017年9月23日時点で最も人気のあるビットコインマイニングプールの市場シェアに基づいています
アカウントを登録し、電話をリンクし、Google認証システムを介して2要素認証を有効にしました。 「ViaBTCにサインインするときに認証する」オプション（入り口の2fa）も含まれていました。
これは、潜在的な被害者のアカウントがとても安全に見えた方法です ：
行こう！
1.サイトはCSRF攻撃から保護されていません。
CSRF（クロスサイトリクエストフォージェリー-XSRFとも呼ばれます）は、HTTPプロトコルの欠点を利用するWebサイト訪問者に対する攻撃の一種です。 被害者が攻撃者によって作成されたサイトにアクセスすると、攻撃者に代わって、何らかの悪意のある操作（攻撃者のアカウントへの送金など）を実行する別のサーバー（支払いシステムサーバーなど）にリクエストが密かに送信されます。 この攻撃を実行するには、リクエストの送信先のサーバーで被害者を認証する必要があります。また、このリクエストはユーザーからの確認を必要としません。
この場合、Webアプリケーションのユーザーが悪意のあるサイトにアクセスすると、彼のメールは攻撃者のアドレスに変更されます。
次のように機能します。
- Webアプリケーションのユーザーは、攻撃者のサイトにアクセスします。
- 被害者は何も疑いませんが、その時点でpool.viabtc.comにメールアドレスを変更するリクエストが送信されました。
- 悪意のあるハッカーはすぐにメールで手紙を受け取り、操作を確認します。
- レターのリンクをクリックすると、攻撃者は次のことを確認します。
いいね！ メールは正常に添付され、攻撃者は被害者のアカウントに自動的にログインしました。 しかし、無数の暗号通貨の富についての想像上のハッカーの濡れた空想は、同じリダイレクト「その家」によって中断されます。 はい、これは3番目の認証ステップのウィンドウです（ログイン時の2fa、覚えていますか？）：
2.ログイン時に2要素認証をバイパスする
さらに、2要素認証の実装に重大な脆弱性が発見されました。 Webアプリケーションの一部の機能では、フロントエンドでのみ2番目の認証要素による確認が必要でした。 リクエストをバックエンドに直接送信すると、適切な認証なしで正常に実行されます。
したがって、攻撃者は、同じ2要素認証に合格しなかったにもかかわらず、入り口で2要素認証を無効にすることができます 。これはもちろん非常に便利な機能です 。
自分で見てください：
- 攻撃者は以下のリクエストを使用して、認証中に2faを無効にします。
- 攻撃者はメインページに移動しますが、認証は要求されません。
リクエストをサーバーに直接送信する他に何ができますか？ 被害者のブラウザ自体がメールを変更するリクエストを送信した最初の脆弱性を思い出しましょう。 ユーザーが電子メールを変更する必要がある場合、フロントエンドは2番目の認証要素を通じて確認を求めます。 ただし、リクエストを直接送信する場合、確認は不要です。 このセキュリティの欠如により、攻撃者はCSRFを使用して電子メールを変更することができました。
この段階で、攻撃者はアカウントとその機密情報にアクセスできました。 ただし、たとえばパスワードの変更などの重要な操作は、2要素認証によって保護されます。
3.二要素認証の完全なバイパス
Webアプリケーションでは、SMSコードまたはGoogle Authenticatorからのコードの2つの操作確認方法を使用できます。 しかし、別の方法-電子メールコードを発見しました。
どうやって？ SMSで動作を確認するプロセスに注目しました。 これは、コードを送信する要求と、受信したコードを使用して確認する要求で構成されます。 次のようになります。
「このリクエストでは、「sms」を「email」に変更するといいと思います。
そして、これは論理的な「sms_code」から「email_code」です。
私は何と言ってもいい、手品で詐欺なし ！
はい、攻撃者は被害者のSMSにアクセスできません。 はい、彼は被害者のGoogle認証システムアカウントにアクセスできません。 しかし、彼は電子メールにアクセスできます（CSRFのおかげでアカウントに関連付けられていました）。
それで、最終ステップ：
- 攻撃者は、Google認証システムアカウントの再割り当て操作の確認コードのリクエストを送信します。
- 電子メールでコードを取得します。
- 電子メールコードを使用して操作を確認します。
- 2番目の認証要素を独自のものに変更します。
このような簡単な方法で、攻撃者はWebアプリケーションの通常のユーザーアカウントを取得しました。
おわりに
脆弱性チェーンにより、アカウントを完全に盗むことができますが、これはもちろん重要です。 それでも、脆弱性を修正するのは難しくありません。
- CSRFトークンを埋め込みます。
- サーバー側のチェックを実行します。
- メールによる確認を無効にします。
しかし、さらに詳しく見ると、これらの脆弱性は診断可能な症状にすぎません。
- 開発者には、Webアプリケーションのセキュリティに関する基本的な知識はありません。 少なくとも、ハッキングされたOWASP TOP TENの知識は、CSRFのような平凡な脆弱性の出現を排除します。
- 開発者は、フロントエンドがWebアプリケーションのバックエンドの唯一のデータソースであり、そこからのデータを信頼しすぎると考えています。 しかし、これはそうではありません。サーバー側に直接リクエストを送信できます。
- Webアプリケーションの機能に関する厳密なポリシーはありません。 開発者は、実稼働バージョンのWebアプリケーションにデバッグ機能の存在を許可しました。
主なことは、私が発見したこれらのいくつかの脆弱性を修正することだけではありません。 問題の根本を調べることが重要です。 技術チームは結論を導き出し、セキュリティに関する知識を絶えず改善する必要があります。 はい、おそらくこの考えは平凡で明白です。 しかし、毎月、別の暗号通貨取引所をハッキングするという大々的な見出しがあります。 おもしろいことは、それは巨大なリスクを伴う新しいテクノロジーのようで、何百万というお金があなたの財布を永久に去ることができるが、CSRFが何であるかを知らない同じ開発者のようだということです。 私はすべてです。
タイムライン
- 12/13/2017-報告されました。
- 12/14/2017-受け入れられました。
- 2017年12月15日-修正。 彼らは料金を支払った。
UPD：有料1 BTC。 当時の為替レートは約18,000ドルでした。