Apache Airflow のミスコンフィグ：認証情報の漏洩と AWS／Slack／PayPal などへの影響

https://gbhackers.com/apache-airflow-misconfigurations-leak-login-credentials/

2025/03/06 gbhackers —Apache Airflow のミスコンフィグに関する最近の調査により、ログイン認証情報／API キー／クラウド・サービスのアクセス・トークンなどを攻撃者に対して露出する、深刻な脆弱性の存在が明らかになった。このワークフロー・プラットフォームにおけるミスコンフィグの主な原因は、安全が確保されないコーディング手法や、古いバージョンの使用などにあり、金融／医療／e コマース業界などでの、データ・セキュリティ侵害につながるものだ。つまり、AWS／Slack／PayPal の認証情報や、内部データベースの認証情報が、適切に保護されていない状態になっていた。

Apache Airflow のアーキテクチャと脆弱性

Apache Airflow は、GitHub で 22,800 のスターを獲得している OSS ワークフロー管理システムであり、分散システム上で DAG (Directed Acyclic Graphs) を用いてタスクをオーケストレーションするものだと、Intezer のレポートでは説明されている。

Airflow では、外部サービスとの統合のために、変数 (認証情報を保存するキー・バリュー形式のストア) と、接続 (暗号化された認証パラメータ) を利用されるが、それらのミスコンフィグが脆弱性の原因となり得る。Intezer の研究者たちは、認証情報の漏洩につながる主要因として、以下の４項目を挙げている。

  1. DAG スクリプトへの認証情報のハードコード
    タスク・コードに認証情報を直接にエンベッドする手法が、依然として広く使用されている。 以下は、PostgreSQL のパスワードが、本番環境の DAG で公開されている例である：
postgres_conn = PostgresHook(

    postgres_conn_id='prod_db',

    host='db.example.com',

    password='s3cr3tP@ssw0rd'  # Hardcoded credentials

)
password exposed
password exposed

このようなアンチ・パターンのコードは、Airflow のセキュア接続フレームワークを回避し、バージョン管理システムや UI 監査ログでの、認証情報に対する可視化を許すものとなる。

  1. 暗号化されていない変数と接続メタデータ
    Airflow の Fernet 暗号化機能により変数が保護されるが、ミスコンフィグが生じると機密情報の復号化にいたり易い。以下は、Slack の Webhook トークンが平文で格納された例である：
slack_token = Variable.get("alert_webhook")  # Returns 'xoxb-1234-abcd' unencrypted

また、AWS のアクセスキーを、接続のための Extra フィールドに保存することで、Fernet の保護が迂回される事例も発見された。

  1. レガシー・ログの脆弱性：CVE-2020-17511
    Airflow 1.10.13 未満のバージョンでは、CLI ツールを使用する際にパスワードがログに平文で記録されるという脆弱性が存在する。この脆弱性を悪用する攻撃者は、タスク・ログから資格情報を取得する可能性を手にする：

INFO – Executing: airflow users create -u admin -p insecure_password123

Password located in logs
Password located in logs
  1. 公開されたコンフィグレーション・ファイル
    expose_config = True のような、誤った airflow.cfg 設定により、Fernet キーとデータベース URI が公開されてしまう。あるインスタンスでは、変数のセキュリティにとって重要な復号化キーが公開されていた。
fernet_key = qWISL8cA12345EXAMPLE_KEY
攻撃対象領域と観測されたペイロード

これらの脆弱性の悪用に成功した攻撃者は、以下のシステムに対する不正アクセスの可能性を得る：

  • クラウド・インフラ：本番環境にリンクされた AWS IAM キー
  • 内部システム：MySQL／Snowflake／Hadoop クラスターのデータベース認証情報
  • コラボレーション・ツール：ソーシャルエンジニアリング・キャンペーンを可能にする Slack トークン
  • 決済処理業者：取引操作用の PayPal API キー

研究者たちが強調するのは、公開された Docker イメージ名 (例：internal-registry.example/biometric_processing:v2.1) が、悪意のコンテナに置き換えられることで、サプライチェーン攻撃が容易になるというケースである。

また、セキュリティ保護されていない Airflow インスタンスにより、想定外のデータ漏洩が発生すると、GDPR／CCPA 規制に違反する可能性も生じる。それぞれの運用者における、全世界の収益の４%が、その罰金の最高額となる。

過去に発生した、Colonial Pipeline 侵害が示唆するのは、認証情報の漏洩から生じた問題により、ランサムウェア展開と業務中断にいたる可能性である。

緩和策
  1. バージョン・アップグレード：Airflow 2.0 以上へと移行し、REST API エンドポイントの認証を義務付け、機密ログを消去する。
  2.  ネットワークのセグメント化：IP ホワイトリストと VPN を介して、インスタンスへのアクセスを制限する。
  3. 秘密情報の管理：変数を使用する代わりに、Vault または AWS Secrets Manager と統合する。
  4. コードレビュー：pre-commit フックを実装し、detect-secrets などのツールを使用して、ハードコードされた認証情報を検出する。
detect-secrets scan --update .secrets.baseline

企業におけるワークフローの自動化が進むにつれて、オーケストレーション・プラットフォームでのセキュリティ確保が不可欠となっている。

露出するインスタンスの多くは、2020年以降に非推奨となったバージョンを使用している。この状況が強調するのは、パッチ管理の重要性とDevSecOps 統合の緊急性である。

サイバーセキュリティ・チームに求められるのは、これらのミスコンフィグが攻撃者により悪用される前に、Airflow の導入状況を監査することである。

Apache Airflow が広い範囲で利用され、また、変数 (認証情報を保存するキー・バリュー形式のストア) を用いて認証が行われるという、レガシーな運用形態が残されていることが分かる記事でした。もちろん、それはミスコンフィグの結果として生じるものですが、それにしても怖いことだと、素人目にも感じられます。ご利用のチームは、ご確認をお急ぎください。よろしければ、カテゴリ MisConfiguration も、ご参照ください。