API と Log in With Google：脆弱な実装による暗号通貨ウォレット・アカウントの乗っ取り

Buggy ‘Log in With Google’ API Implementation Opens Crypto Wallets to Account Takeover

2022/07/07 DarkReading — 世界中に 200万人以上のユーザーを有し、$3 billion 相当の Bitcoin を管理する暗号通貨ウォレット・サービスに、外部認証ログインの実装方法に関連する API の脆弱性が存在することが判明した。現在において、この脆弱性は修正されているが、研究者たちは、この発見は API を安全に実装することの難しさを物語っていると指摘している。

Salt Security の研究部門である Salt Labs のレポートによると、この一連の脆弱性 (CVE は割り当てられていない) の悪用に成功した攻撃者たちは、システム内のユーザー・アカウントの大部分の乗っ取りが可能になることがわかった。この脆弱性により、攻撃者はユーザーに代わり、資金の移動を含む複数の金融行為や、完全なアクセス権の取得が可能となる。

Salt Securi の研究者たちは、「ユーザー・アカウントへのログインに成功した攻撃者は、資金移動／取引履歴の閲覧／ユーザーの個人情報 (名前／住所／銀行口座番号などの機密データなど) の閲覧などの、あらゆるユーザー機能を利用できる可能性がある」と述べている。

発見された脆弱性のうち、１つ目は、モバイル・アプリの一般的な機能である、Apple／Google／Facebook／Twitter などの外部サービスを使ったログイン機能に関連する。研究者たちが、”log in with Google” オプションを調査したところ、不正な Google ID を正当なユーザーのものとして認証するよう、操作できることが判明した。

２つ目は、二要素認証 (2FA) の回避を可能にする脆弱性だ。PIN リセットのメカニズムにレート制限がないことが判明し、ユーザーの携帯電話やＥメールに送信されるコードを抽出するための、自動的な攻撃を行うことが可能になっている。

研究者たちは、「このエンド・ポイントには、レート制限／ユーザーブロック／一時的なアカウント無効化の機能が一切含まれていない。基本的には、999,999個の PIN オプションを全て実行し、１分以内に正しい PIN を取得できるようになった。これらのセキュリティ脆弱性のみでは、攻撃者が悪用できる昨日が限定される。しかし、攻撃者は、これらの脆弱性を連鎖させることで、全ての口座残高を自分の口座に転送するなど、非常にインパクトのある攻撃を仕掛けることが可能だ」とも述べている。

Salt Securi の Vice President of Research である Yaniv Balmas は、「これらの脆弱性を、危険なものにする要因は２つある。第１に、とても簡単に悪用できることが挙げられる。そして第２に、悪用に成功すると、個人や企業の口座から数百万ドル（あるいはそれ以上）が盗まれる可能性があることだ」と説明している。

脆弱な API 実装と重要な教訓

前述の通り、この暗号通貨ウォレット・プロバイダーは、問題の API を直ちに修正したが、「この分析からは重要な教訓が得られる」と Balmas は説明している。

Balmas は、暗号通貨の市場全体が比較的若く、この分野のサービスの大半が、コア技術の一部としての API に大きく依存していることを指摘している。彼は、「その機能との自動的なやりとりを容易にするために、大半の暗号通貨サービスは、ある種の API を公開している。この API への依存は、別の問題を表面化させる」と述べている。

彼は、「API はダイナミックで急速に進化する、コアビジネス機能のインターフェースとして設計されており、ユーザーの観点から見ると、それらは非常に肯定的なものとなる。しかし、この同じ動作が、気づかないうちにセキュリティ問題や脆弱性への扉を開いてしまう。それゆえ、私たちの研究活動では、時にはビジネスに深刻な影響を及ぼす、脆弱な API セキュリティを頻繁に目にすることがある」と付け加えている。

利用が拡大する API セキュリティの課題

アジャイル開発の普及に伴い、企業が API を利用するようになった結果として、攻撃対象が広がり、脅威アクターによる悪用が容易になっている。アプリケーション・セキュリティ企業の Imperva と、リスク戦略企業の Marsh McLennan が、API に関連する侵害について行った最新分析では、2022年の米国企業は総額で $12 billion〜$23 billion の損失に直面していることが判明した。

その一方で、Salt Labs が３月に発表したレポートによると、2021年の API 攻撃は、なんと 681 ％ も増加していることが分かった。また、正規のトラフィックと比べて、悪意の攻撃トラフィックが２倍以上の割合で増加していることも判明した。ここでも、問題の多くが、実装や設定のミスに起因している可能性がある。たとえば５月に、Shadowserver Foundation の研究者たちは、38万台の Kubernetes API サーバーがパブリック・インターネットに露出し、その割合はオンラインで観測可能な、全世界の Kubernetes API インスタンスの84%に相当することを発見している。

API 攻撃対象領域の追跡と監視が推奨される

Balmas は、「API の性質におけるもう一つの問題は、API エコシステムが大きくなると、その把握が非常に困難になることだ」と指摘している。複数のアプリケーションや社内サービスが、それぞれ独自の API セットを公開しているため、メンテナンス担当者が、どの API が公開されているのかを、ある時点で把握できなくなる場合がある。彼は、「企業の API を保護するためには、API の可視化／統合のための対策が、重要な一歩となることがある」と述べている。

さらに、暗号通貨プラットフォームや、その他の API ヘビーユーザーは、自らが公開する API の攻撃対象に、さらなる注意を払うべきだと指摘している。彼は、「この新たな攻撃対象は、注意深く追跡／監視する必要がある。また、脆弱性の悪用が生み出す異常を発見するために、トラフィックに対して継続的な行動監視を適用すべきだ」と述べている。

“log in with Google” や “log in with Facebook” は、とても便利なので、ついつい使ってしまうというケースがありますが、このインシデントでは Google 側の問題が悪用されたようです。さらに、２FA に対するブルートフォース攻撃が可能であったことで、実被害が発生したのだろうと推測できます。一連の攻撃は、API を介して行われたものであり、この侵害経路に対するチェックが不十分であることも判明しています。なお、SaltSecurity の State of API Security Q1 2022 は、たくさんのチャートを用いた、とても見やすいレポートになっています。また、2021年10月の「OWASP API Top-10： API を脅かす脆弱性を分析して対策を講じる」も良記事ですので、よろしければ、ご参照ください。