サイバー脅威
Apache APISIX API ゲートウェイにおけるセキュリティ上の懸念
API（Application Programming Interface）ゲートウェイが抱える潜在的リスクについて解説した記事に関連して、本稿ではApache APISIX API ゲートウェイとそのセキュリティに焦点を当てます。
API（Application Programming Interface）ゲートウェイが抱える潜在的リスクについて解説した記事に関連して、本稿ではApache APISIX API ゲートウェイとそのセキュリティに焦点を当てます。
Apache APISIX API ゲートウェイのコンポーネント
まず、Apache APISIX APIゲートウェイへの理解を深めるために、コンポーネントとインフォメーションフローを確認してみましょう。
- APISIX core、Lua製プラグイン、多言語プラグインのランタイム、WASMプラグインのランタイム
- オブザーバビリティ(可観測性)、セキュリティ、トラフィック制御のための機能を追加するビルトインプラグイン
- GUI（Graphical User Interface）を使用した「ゲートウェイの設定のためにAdmin API と直接通信するダッシュボード（オプショナル）」
APISIX coreは、様々な機能（ルートマッチング、ロードバランシング、サービスディスカバリ、設定管理、管理用APIのセットアップ等）を提供します。また、コンポーネントには、Luaや多言語（Go、Java、Python、JavaScript等）プラグインをサポートする「APISIXプラグインのランタイム」も含まれます。
さらに、APISIXはAdmin APIと直接通信するWebダッシュボード（オプショナル）を提供しています。このダッシュボードの導入により、GUIを使用したゲートウェイの設定が簡易化されます。
デフォルトのマスターAPIトークンを使用するリスク
設定ミスは、ソフトウェアデプロイメントに関連した「最も一般的なセキュリティ上の脅威」であると考えられています。通常、設定（クラウド環境を含む）に関しては、各ユーザが全責任を負います。そのため、ユーザは対応時に万全の注意を払う必要があります。また、アンマネージド（ユーザ側が管理を行う）サービスを展開する場合は、特に注意が必要です。
各機能が適切に使用されることで、はじめて効果的なセキュリティ対策を実施することができるため、ユーザ教育において「セキュリティデフォルト（Security Defaults）」について学ぶことは大変重要です。デフォルトとして、より安全なパターンを使用することで、アプリケーションのセキュリティを確保することや不注意による設定ミスを防ぐことが可能となります。
管理インターフェースのマスターパスワードを変更しないことは、セキュリティ上のリスクを抱えることになります。例えば、マスターパスワードを定期的に変更しない場合や脆弱なパスワードがデフォルトで使用されている場合には、攻撃者に管理アクセスを提供してしまう恐れがあります。
残念ながら、APISIXにはAdmin APIにアクセスするためのデフォルトのマスターAPIトークンが存在します。そのため、デフォルトのAPIキーを使用し続けることには大きなリスクが伴います。なお、ソフトウェア開発者にとっては、インスタンスごとにランダムなトークンを生成する代わりに、ハードコードされたAPIトークンを使用する方が便利であると考えられます。
もし、APISIXがセキュリティ対策を優先し、ランダムなAPIトークンを生成すれば、デフォルト認証に対する懸念が解消されることになるでしょう
しかし、現状では、複数のインスタンス（デフォルトの管理トークンを含む）が公開されているため、攻撃者に悪用される恐れがあります。また、ここでは、セキュリティの基本ルールである「管理用APIの非公開」が遵守されていません。
なぜ保護されていないアドミ二ストレーションプレーンインスタンス（Administration Plane Instances）が存在するのでしょうか。
いくつかの攻撃は、研究者が作成したハニーポットを標的として実施されたと推測されています。その一方で、設定ミスや不適切なデフォルト設定を悪用した攻撃があった可能性も否めません。さらに、変更されていない「公開済みのパスワードやトークン」が悪用された可能性も考えられます。このように、当問題は複層的であり、多くの領域にわたる課題を抱えています。
まず、ハードコードされたマスターパスワードは一般に公開されています。
また、アドミ二ストレーションプレーンも公開されています。従って、ユーザはコンテナ化されたアプリケーションのデフォルト設定およびランタイムポートの開放に関して細心の注意を払う必要があります。
脆弱性の悪用によるIP制限の回避
「IP制限ルール（ユーザがアドミニストレーションプレーンにアクセスすることを防止）」を採用するWAF（Web Application Firewall）を導入することで、セキュリティが強化されます。なお、このルールは、APISIX APIゲートウェイレベルにおいてのみ採用されています。
2022年にCVE-2022-24112が公開されました。これは、その年に攻撃者によって最も悪用された脆弱性（カスタムヘッダの使用によるIP制限のバイパス）の一つです。デフォルトのアドミニストレーションパスワードが変更されていない環境下で本脆弱性が悪用された場合、APIゲートウェイを介したRCE（リモートコード実行）攻撃が可能となります。
デフォルトのAPIキーを用いることや設定ファイル内のネットワークルールのみでアクセスを制限することは「最善のセキュリティ対策」ではありません。複数のデバイスが接続されているプライベートネットワーク全体を通じて、アドミニストレーションプレーンが利用可能な状態は、セキュリティ上のリスクを高めます。また、ネットワークに接続されたデバイス自体が攻撃対象となることで、ゲートウェイが侵害される可能性が高まります。
IP制限に起因する脆弱性CVE-2022-24112の公開から、私たちはいくつかの教訓を得ることができます。その一方で、Apache APISIXのデフォルト設定が「REC攻撃に対して脆弱である」という事実は、残念ながら引き続き軽視されています。
トレンドマイクロの調査では、デフォルトの認証情報を悪用する手口によりRCE攻撃が実行されていました
まず、攻撃者はデフォルトの認証情報を利用して、保護されていないインスタンスを特定します。次に、APISIXゲートウェイのLuaスクリプト機能を使用してルートを作成します。そして、このルート作成により、ゲートウェイを介したRCE攻撃が可能となります。
APISIXゲートウェイを介してLuaコードを実行する方法は複数存在しますが、いずれにおいてもサンドボックスは構築されません。そのため、APISIXゲートウェイを介してLuaを実行する攻撃者は、利用可能なすべてのモジュールに制限なくアクセスすることができます。
その結果、攻撃者はゲートウェイを介したさまざまなサイバー犯罪（マルウェアやクリプトジャッキングペイロードの展開、DoS攻撃の実行、なりすまし攻撃やクラウドアカウントの侵害につながる機密データの流出等）を実行することが可能となります。
APISIXダッシュボードの潜在的リスク
APISIXダッシュボード（オプショナル）にも類似したセキュリティ上の問題が存在します。このダッシュボードは、ゲートウェイ設定を簡素化しますが、Admin APIが外部から遮断されている状態であっても直接アクセスすることが可能です。通常、ダッシュボードアプリケーションは、アクセスを許可するために認証情報を要求します。しかし、デフォルトの（特にコンテナ化された環境における）ユーザ名およびパスワードは 「admin」に設定されています。
APISIXダッシュボードが公開されている場合、「RCE攻撃に利用される可能性がある脆弱性」が発生します。
公開されているAPISIXサービス
2024年1月、複数のポートを介してAPISIXサービスを実行している622個の「ユニークなIPアドレス」がShodanサーチにより明らかになりました。
公開されているインスタンスのコンテンツをデフォルトのトークンを用いてチェックしたところ、少なくとも39個が完全にオープンであり、機密データへのアクセスが可能となっていました。
2023年、トレンドマイクロはAPIゲートウェイのユースケースに関するレポートを発表しました。本レポートは、以下の内容を含みます。
- アップストリームにアクセスするためのシークレット管理
- トークンの発行とゲートウェイ認証メカニズム（安全なIDプロバイダ、 IdP設定等）
- ロギングと認証情報の窃取
- プラグインとスクリプトの作成
前述した通り、Luaコード実行に際して、サンドボックスは構築されません。ユーザは、Lua製プラグインやスクリプトを使用し、かつ、ユーザ入力に依存する場合には、ゲートウェイに脆弱性（RCE脆弱性を含む）が生じる可能性があるため注意が必要です。例えば、ユーザがHTTPヘッダをパースする脆弱なコードを記述した場合、攻撃者は制限なしにペイロードを実行することが可能となります。
APIゲートウェイは、組織や企業のAPIインフラストラクチャ全体にアクセスするための「セントラルアクセスポイント」として利用できるため、攻撃者にとって格好の標的となります。攻撃者がゲートウェイを介したアクセスに成功した場合には、機密情報（すべてのバックエンド認証トークンやIdP設定のシークレット等）が漏洩する可能性があります。その結果、特にIdP設定情報の漏洩により、なりすまし攻撃やハーベスト攻撃が可能となります。さらに、APIエコシステム全体が攻撃者に悪用される恐れもあります。
APISIXのデフォルトシークレット管理システムでは、ストレージ（ゲートウェイの設定を保存）が重要な役割を果たしています。
APISIXは、Kubernetesユーザに人気のetcdを利用しています。これは、分散システム上の重要な情報や設定データを管理するために使用されるオープンソースのキーバリュー型データベースです。設定は暗号化されずに保存されるため、etcdインスタンスにアクセス可能な人物であれば誰でも保存されている機密情報を確認することができます。なお、APIエンドポイントの静的なapiキーは、etcdシークレットの一つです。
APISIXバージョン3.1以降、ユーザはプラグインの設定を暗号化して保存できるようになりました。しかし、これはデフォルトではなく、追加の設定を必要とします。
異なる方法として、Vault内にシークレットを保存することも可能です。この場合、必要に応じて、設定内のシークレットを参照することができます。トレンドマイクロは、シークレットを保存する際にVaultを使用することを推奨しています。なお、Vaultへのアクセスには、セキュリティ確保のために、少なくとも一つのシークレットが必要となります。
一般的に、環境変数にシークレットを格納することは推奨されません。トレンドマイクロが2022年に発表したレポートでは、「機密情報保持のために環境変数を使用すること」に関する危険性を分析しています。また、時として環境変数は誤って使用されることがあります。そして、この誤用が重大なセキュリティ上の問題につながる可能性があります。
トレンドマイクロのレポートでは、公開されているコンテナレジストリについて詳しく解説しています。また、本レポートでは、コンテナイメージから漏えいする可能性のあるハードコード化されたシークレットの保護についても特集しています。
100％安全なシステムは存在しません。開発者は、環境変数やセキュリティに対する深い知識（実行時のみ環境変数をインジェクトすること、ハードコーディングを実施しない等）や経験があるために、安全に環境変数を扱うことができます。
セキュリティリスクをもたらす不要な環境変数の削除およびカスタムコンテナイメージを使用したAzure サーバレスソリューションのセキュリティ強化例を本稿では紹介します。
過剰なロギングのリスク
アクティビティログは、トラブルシューティングを行う際に役立ちます。ログは、管理者や開発者がシミュレーションを通じて問題の所在や原因を特定する際に必要とされます。しかし、過剰なロギングはストレージの容量不足を招き、攻撃対象（特にユーザが機密情報を記録している場合）となる恐れがあります。なお、ユーザ同士が未解決の問題について助言を求めるために、ログをアップロードすることは日常的に実施されています。
権限のない者が記録された機密情報（アクセストークン等）にアクセスした場合に起こり得ること
この答えは、リクエスト送信時における機密情報の格納場所（URL、ヘッダ、ボディ等）、アクティビティログ（内容、程度等）、情報の機密度など複数の要因により左右されます。
HTTP GETリクエストのパラメータとしてトークンを渡す場合、 トークンの有効期限やパーミッションについて確認する必要があります。トークンの有効期限が延長されている場合や過剰な権限が付与されている場合には注意が必要です。
出展：Grafana Labs
トレンドマイクロは、http-logger pluginをデフォルト設定でテストしました（http logging serverのURLのみ設定）。そして、認証ヘッダを含むすべてのヘッダがデフォルトで存在していることを確認しました。
設定（configuration）は、ユーザがすべて行うことができるため、セキュリティリスクが伴います。そのため、各ユーザはモニターの対象やログの必要性を慎重に判断することが求められます。また、機密情報の漏洩を回避するための設定を理解することも重要です。
例えば、APISIXドキュメントの解説にある「想定されているデフォルト」では、限定された情報のみ提供されています。デフォルト設定に依存することはセキュリティ上の危険を伴うため、繰り返しとなりますが、ユーザはログの目的や必要性を認識することが大切です。
機密情報を記録する際には、情報の機密性を保持するためにTLS（Transport Layer Security）を使用した安全な送信およびストレージ（特にロギングプラットフォーム上）のセキュリティ確保が重要となります。
特に、サードパーティIdPサービス（Keycloak、AWS Cognito等）を使用し、データベース内にコンフィギュレーションシークレットを保存する場合、TLSを用いることは極めて重要です。
APISIX APIゲートウェイプラグインに関連するリスク
コミュニティプラグインに関しては、「経験が異なる複数の関係者による管理（Multiple Parties with Different Levels of Experience）」が脆弱性発生の要因となる可能性があります。そのため、コミュニティプラグインが「セキュリティ上の問題がある製品」に分類されているケースも見受けられます。プラグインを使用する際には、機能面だけでなく、セキュリティ面についても考慮することが大切です。
APISIX APIゲートウェイは、プラグインを複数のカテゴリ（トランスフォーメーション、認証、セキュリティ、トラフィック、オブザーバビリティ〈観測可能性〉、サーバレス）に分類しています。各カテゴリには、それぞれ異なるリスクが伴います。例えば、トランスフォーメーションプラグインのリスクは、APIリクエスト、レスポンス、そして構文解析 (Parsing)におけるユーザ入力に関連します。また、認証プラグインでは、ストレージの安全性や不適切な認証の実装に関連したリスクが伴います。そして、オブザーバビリティプラグインでは、過剰なロギングに関連するリスクが伴います。
認証プラグインの一つは、RFC-7617を実装したBasic認証（ユーザ名とパスワードを使用）です。このような簡易な認証方法は、APIゲートウェイのセキュリティに対する姿勢を表しています。なお、当メカニズムはユースケースでは非推奨とされています。
このプラグインを設定すると、認証のためにエンコードされた有効なユーザ名とパスワード（認証ヘッダに設定）が要求されます。
図14は、パスワードを含む認証情報がプレーンテキストで保存されていることを示しています。仮に、これがサードパーティサービスの認証に必要であり、かつ、イニシャルリクエストから渡されていないのであれば、APIゲートウェイがシークレットを保存することは理にかなっています。しかし、それ以外のケースであれば、パスワードの暗号化やVault参照が可能だとしても、APIゲートウェイがシークレットを保存することには疑問が残ります。
生パスワード（Raw Password）を保存することは、APIゲートウェイレベルにおける認証では不要と考えられます。実際、これにより攻撃者がパスワードを悪用することが可能となるため、セキュリティ上の脆弱性として認定されています。
認証情報に関しては、生パスワードではなく、ソルト付きハッシュを作成、保存することで安全性が高まります。その結果、仮に侵入された場合であっても、攻撃者はソルト付きハッシュのみにアクセスすることとなります。攻撃者がソルト付きハッシュから、認証に必要なプレーンテキストのパスワードを復元することは困難です。
APIゲートウェイの悪用
攻撃者はAPIゲートウェイを標的にする際、セキュリティ上の設定ミスを悪用します。本章では、APISIX APIゲートウェイを例に挙げて解説します。
無料で利用可能なコンピューティングリソースを悪用することで、攻撃者はクリプトジャッキングマルウェアを展開します。このマルウェアは、さまざまな利益（DDoS攻撃で使用される大規模なネットワークを構成するボット等）を攻撃側へもたらします。
さらに、攻撃者はマルウェア拡散のために、APIゲートウェイを悪用します。APIゲートウェイは通常、HTMLリソースとして用いられる可能性は低く、バックエンドリソースとして活用されています。ソフトウェアのダウンロードリンクを返すAPIサービスでは、侵害された「APIゲートウェイのインスタンス」を「不正なリンクとして機能」するように設定される恐れがあります。これは主にサプライチェーン攻撃に利用されます。
より標的を絞った攻撃では、攻撃者はAPIゲートウェイの機能を悪用することで、認証情報や企業の機密情報を収集します。収集された機密情報は販売される可能性があります。また、認証情報は、なりすまし攻撃の実行時に利用される恐れがあります。
ハニーポットを用いて収集したデータ
トレンドマイクロのハニーポット（設置期間2023年10月～ 2024年1月）には、「APIがリンクされたWebサイト」に対する攻撃を監視、分析する設計が施されていました。80番ポートでホストされているWebサイトは、攻撃者をAPIにおびき寄せるために使用されました。なお、このAPIは、より高い数値のポートでホストされ、Webサイトのソースコードにリンクされていました。
設置期間中、WebサイトとAPIエンドポイントは、それぞれ約24,000件と約15,500件のリクエストを受けました。ボットによるrootリクエストを除くと、一般的なエクスプロイトによる試行が約11,500件確認されました。
このセットアップでは、攻撃者が「APISIXを介した管理（Managed via APISIX）」であるか否かを確認する場合には、APIとのインタラクションを図る必要があります。
APISIXに対する標的型攻撃は、14回確認されました。これらの攻撃の特徴として、特定のURL、追加のAPIリクエストパラメータ、そして一般的なユーザ名とパスワードの組み合わせを使用した管理ダッシュボードへのアクセスを挙げることができます。
まとめ
最も一般的なセキュリティ上の課題の一つとして、設定ミスを挙げることができます。デフォルト設定に依存することは大きなセキュリティリスクとなるため、セキュリティ設定（特にハードコードされたマスター認証情報）は必ず変更してください。加えて、ソフトウェアのアップデートや公開されている脆弱性（CVE-2022-24112を含む）に対して対策を講じることも重要です。これらの脆弱性は、悪用された場合、APIゲートウェイ全体が制御されるばかりでなく、集中型システム（APIエコシステム全体を集約）へのエントリポイントを攻撃者に提供するリスクが生じます。
脆弱性の性質やAPISIXのコア機能を考慮すると、ユーザは最新のAPIゲートウェイの導入だけでなく、カスタマイズされたLuaスクリプトの使用に対しても同様に注意を払う必要があります。
さらに、ストレージ（etcd等）や各アドミニストレーションプレーンおよびダッシュボードへのアクセス保護も重要です。APIゲートウェイにリンクされたバックエンドにも脆弱性が存在する可能性があるため、WAF（Web Application Firewall）以外のネットワーク保護メカニズムの適用が推奨されます。
最新のソフトウェアアプリケーションは、セキュリティ面を考慮して設計されていないことも多いため、感染リスクを最小化するために、システム管理者にはベストプラクティスを実施することが求められます。アプリケーションのバックエンドがCSP（Cloud Service Provider）やオンプレミスプラットフォームに分散されている場合、複数のバックエンドへのアクセスを単一のポイントに集約することは、特にハイブリッドクラウドソリューションにおいて一般化しつつあります。しかし、このアプローチを導入する前に、ユーザは単一のアクセスポイント集約に伴う「新たなセキュリティリスク」を把握する必要があります。十分なセキュリティが確保されていない場合、このようなアクセスポイントが侵害されると組織や企業全体に被害が及ぶ恐れがあります。
APIゲートウェイは、オンプレミスバックエンドへのアクセスを集約することで、マルチクラウドサーバレスフレームワーク（Multiple Cloud Serverless Framework）の統合やIDプロバイダの設定をサポートする機能的な手段を提供します。しかし、設定ミスや過剰な権限付与は、なりすまし攻撃やクラウドアカウントの侵害につながる可能性があることを今一度認識する必要があります。
参考記事
Apache APISIX In-the-wild Exploitations: An API Gateway Security Study
By; Trend Micro Research
翻訳：新井 智士（Core Technology Marketing, Trend Micro™ Research）