AWS ALB を使用するアプリを狙う ALBeast 攻撃：多くのユーザーが危険に晒されている

Thousands of Apps Using AWS ALB Exposed to Attacks Due to Configuration Issue

2024/08/21 SecurityWeek — 認証において AWS の Application Load Balancer (ALB) を使用している 15,000ものアプリが、攻撃に対して脆弱である可能性があると、アプリケーション・セキュリティ企業の Miggo が明らかにした。この Miggo が ALBeast と命名した攻撃に対する AWS の反論は、ALB 自体の脆弱性ではなく、コンフィグに起因する問題だというものだ。

AWS ALB は、リクエストの内容に基づいて、トラフィックをルーティングするロードバランサーであり、その行き先は EC2 インスタンス／コンテナ／IP アドレス／Lambda 関数などになる。

このリスクについて４月に報告を受けた AWS は、ALBeast 攻撃に対する防御をサポートするために、ユーザーに提供されるドキュメントを更新し、新しいコードを追加したと、Miggo は述べている。

Censys の検索では、インターネットに公開された、AWS ALB インスタンスが、370,000 台以上あることが判明している。Miggo の主張は、そのうちの 15,000台以上にコンフィグの問題があり、攻撃に対して脆弱な可能性があるというものだ。さらに同社は、インターネットに露出していないアプリであっても、ネットワークにアクセスできる攻撃者に狙われる可能性があると指摘している。

Miggo は、「まず、攻撃者は、自身のアカウントで認証を設定した、独自の ALB インスタンスを作成する。続いて、この ALB インスタンスを用いて、自身で完全にコントロールするトークンに署名した後に、ALB のコンフィグを変更し、被害者が想定する発行者フィールドを装う」と詳述する。

さらに同社は、「その後に AWS は、攻撃者の偽造トークンに対して、被害者が想定する発行元の名前で署名する。したがって、最終的に攻撃者は、この偽造トークンを被害者のアプリケーションに使用し、認証と認可の両方をバイパスする」と述べている。

Miggo によると、ALBeast 攻撃により、ビジネス・リソースへの不正アクセスやデータの流出が可能になるという。

ユーザー側の対策として、ALB 認証を使用するアプリがトークン署名者を確認し、ALB からのトラフィックのみを受け入れるように設定することで、この攻撃を防ぐことが可能にある。

SecurityWeek が問い合わせたところ、AWS の広報担当者からは、下記のような回答が得られた：

AWS — この攻撃手法は、リクエストを認証しないという誤ったコンフィグが行われた顧客アプリケーションに対して、すでに攻撃者がダイレクトに接続していることが前提となる。したがって、これを AWS ALB や AWS サービスの認証／認可バイパスと呼ぶのは正しくない。

ユーザーに対して推奨されるのは Security Groups を使用して、ALB のセキュリティ・ベスト・プラクティスに従い、ALB からのリクエストだけを受け付けるように、アプリケーションをコンフィグすることである。

AWS の顧客のうち、このように誤ったコンフィグが行われているアプリケーションは、数パーセントに過ぎず、研究者の推定よりもかなり少ない。我々は、ALB を使用するアプリケーションにおける、コンフィグのベスト・プラクティスを共有するために、それぞれの顧客と、個別に連絡を取った — AWS

そんなコンフィグができていまって良いのかという、疑問が残る、AWS の見解ですね。AWS サービスの認証／認可バイパスと呼ぶのは間違いとか、AWS サービスの認証／認可バイパスを引き起こすコンフィグが正しいとかの、問題ではないように思えます。よろしければ、AWS で検索も、ご利用ください。