Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
攻撃者の視点から見ると、これは非常に興味深いです。なぜなら、登録されているすべてのユーザー、そのメールアドレス、所属しているグループ、プロフィール、さらにはデバイス（モバイルとそのOS）を確認できるからです。
ホワイトボックスレビューでは、**「保留中のユーザーアクション」や「パスワードリセット」**が複数存在しないことを確認してください。
ここでは、Oktaに作成されたすべてのグループを見つけることができます。異なるグループ（権限のセット）がユーザーに付与される可能性を理解することは興味深いです。 グループ内の人々や各グループに割り当てられたアプリを確認できます。
もちろん、adminという名前のグループは特に興味深いです。特にGlobal Administratorsグループを確認し、最も特権のあるメンバーを特定してください。
ホワイトボックスレビューでは、グローバル管理者は5人を超えてはいけません（2人または3人が理想です）。
ここでは、すべてのユーザーのデバイスのリストを見つけることができます。また、それが積極的に管理されているかどうかも確認できます。
ここでは、名前、姓、メール、ユーザー名などの重要な情報がOktaと他のアプリケーションの間でどのように共有されているかを観察できます。これは興味深いです。なぜなら、ユーザーがOktaでフィールドを変更できる（名前やメールなど）場合、それが外部アプリケーションによってユーザーを識別するために使用されると、内部者が他のアカウントを乗っ取る可能性があるからです。
さらに、Oktaのプロフィール**User (default)では、各ユーザーが持っているフィールドと、ユーザーが書き込み可能**なフィールドを確認できます。管理パネルが見えない場合は、プロフィール情報を更新するために移動し、どのフィールドを更新できるかを確認してください（メールアドレスを更新するには確認が必要です）。
ディレクトリは、既存のソースから人々をインポートすることを可能にします。ここでは、他のディレクトリからインポートされたユーザーを見ることができると思います。
私はこれを見たことがありませんが、Oktaがユーザーをインポートするために使用している他のディレクトリを見つけるのは興味深いです。もしそのディレクトリを侵害すれば、Oktaで作成されたユーザーの属性値を設定し、Okta環境を侵害する可能性があります。
プロファイルソースは、ユーザープロファイル属性の真実のソースとして機能するアプリケーションです。ユーザーは、一度に1つのアプリケーションまたはディレクトリからのみソースされることができます。
私はこれを見たことがありませんので、このオプションに関するセキュリティとハッキングに関する情報は感謝されます。
このセクションのDomainsタブで、メールを送信するために使用されるメールアドレスと、会社のOkta内のカスタムドメインを確認してください（おそらくすでに知っているでしょう）。
さらに、Settingタブでは、管理者であれば**「カスタムサインアウトページを使用する」**を選択し、カスタムURLを設定できます。
ここには特に興味深いことはありません。
ここでは、構成されたアプリケーションを見つけることができますが、それらの詳細は後の別のセクションで確認します。
興味深い設定ですが、セキュリティの観点からは特に興味深いことはありません。
ここでは、すべての構成されたアプリケーションとその詳細を見つけることができます：誰がそれにアクセスできるか、どのように構成されているか（SAML、OpenID）、ログインURL、Oktaとアプリケーション間のマッピング...
Sign Onタブには、Password revealというフィールドもあり、ユーザーがアプリケーション設定を確認する際にパスワードを表示できるようになります。ユーザーパネルからアプリケーションの設定を確認するには、3つのドットをクリックします：
そして、アプリに関する詳細（パスワード表示機能が有効かどうかなど）を確認できます：
アクセス認証を使用して、ユーザーのリソースへのアクセスを定期的にレビューし、必要に応じて自動的にアクセスを承認または取り消す監査キャンペーンを作成します。
私はこれが使用されているのを見たことがありませんが、防御的な観点からは良い機能だと思います。
セキュリティ通知メール：すべて有効にするべきです。
CAPTCHA統合：少なくとも目に見えないreCaptchaを設定することをお勧めします。
組織のセキュリティ：すべてを有効にでき、アクティベーションメールは長くかかるべきではありません（7日間は適切です）。
ユーザー列挙防止：両方とも有効にするべきです。
ユーザー列挙防止は、次のいずれかの条件が許可されている場合には効果を発揮しません（詳細はユーザー管理を参照してください）：
セルフサービス登録
メール認証を伴うJITフロー
Okta ThreatInsight設定：脅威レベルに基づいてログを記録し、セキュリティを強制します。
ここでは、正しく設定された設定と危険な設定を見つけることができます。
ここでは、ユーザーが使用できるすべての認証方法を見つけることができます：パスワード、電話、メール、コード、WebAuthn... パスワード認証子をクリックすると、パスワードポリシーが表示されます。強力であることを確認してください。
Enrollmentタブでは、必須またはオプションのものを確認できます：
電話を無効にすることをお勧めします。最も強力なのは、おそらくパスワード、メール、WebAuthnの組み合わせです。
すべてのアプリには認証ポリシーがあります。認証ポリシーは、アプリにサインインしようとするユーザーが特定の条件を満たしていることを確認し、それに基づいて要件を強制します。
ここでは、各アプリケーションにアクセスするための要件を見つけることができます。各アプリケーションに対して、少なくともパスワードと別の方法を要求することをお勧めします。しかし、攻撃者として、より弱いものを見つけた場合、それを攻撃できるかもしれません。
ここでは、異なるグループに割り当てられたセッションポリシーを見つけることができます。例えば：
MFAを要求し、セッションの有効期限を数時間に制限し、ブラウザ拡張機能を通じてセッションCookieを持続させず、場所とアイデンティティプロバイダーを制限することをお勧めします（可能であれば）。例えば、すべてのユーザーが特定の国からログインする必要がある場合、その場所のみを許可することができます。
アイデンティティプロバイダー（IdP）は、ユーザーアカウントを管理するサービスです。OktaにIdPを追加すると、エンドユーザーは最初にソーシャルアカウントまたはスマートカードで認証することによって、カスタムアプリケーションにセルフ登録できるようになります。
アイデンティティプロバイダーのページでは、ソーシャルログイン（IdP）を追加し、インバウンドSAMLを追加することによってOktaをサービスプロバイダー（SP）として構成できます。IdPを追加した後、ユーザーの場所、デバイス、またはメールドメインなどのコンテキストに基づいて、ユーザーをIdPに誘導するルーティングルールを設定できます。
アイデンティティプロバイダーが構成されている場合、攻撃者と防御者の視点からその設定を確認し、ソースが本当に信頼できるかどうかを確認してください。攻撃者がそれを侵害すれば、Okta環境にもアクセスできる可能性があります。
委任認証により、ユーザーは組織のActive Directory（AD）またはLDAPサーバーの資格情報を入力することによってOktaにサインインできます。
再度確認してください。攻撃者が組織のADを侵害すれば、この設定のおかげでOktaにピボットできる可能性があります。
ネットワークゾーンは、IPアドレスに基づいて、組織内のコンピュータやデバイスへのアクセスを付与または制限するために使用できる構成可能な境界です。1つまたは複数の個別のIPアドレス、IPアドレスの範囲、または地理的な場所を指定することによってネットワークゾーンを定義できます。
1つまたは複数のネットワークゾーンを定義した後、グローバルセッションポリシー、認証ポリシー、VPN通知、およびルーティングルールで使用できます。
攻撃者の視点からは、許可されているIPを知ることが興味深いです（および、特権のあるIPが他にないか確認）。攻撃者の視点から、ユーザーが特定のIPアドレスまたは地域からアクセスする必要がある場合、この機能が適切に使用されているか確認してください。
エンドポイント管理：エンドポイント管理は、管理されたデバイスがアプリケーションにアクセスできることを保証するために、認証ポリシーに適用できる条件です。
まだこれが使用されているのを見たことがありません。TODO
通知サービス：まだこれが使用されているのを見たことがありません。TODO
このページでOkta APIトークンを作成し、作成されたトークン、権限、有効期限、およびOrigin URLsを確認できます。APIトークンは、トークンを作成したユーザーの権限で生成され、作成したユーザーがアクティブである場合にのみ有効です。
Trusted Originsは、あなたが制御し信頼するウェブサイトがOkta APIを通じてあなたのOkta組織にアクセスすることを許可します。
APIトークンはあまり多くないべきです。なぜなら、もし多く存在すれば、攻撃者がそれにアクセスし、使用しようとする可能性があるからです。
自動化により、エンドユーザーのライフサイクル中に発生する一連のトリガー条件に基づいて実行される自動アクションを作成できます。
例えば、条件は「Oktaでのユーザーの非活動」や「Oktaでのユーザーパスワードの有効期限切れ」であり、アクションは「ユーザーにメールを送信」または「Oktaでのユーザーライフサイクル状態を変更」などです。
ログをダウンロードします。これらは現在のアカウントのメールアドレスに送信されます。
ここでは、ユーザーによって実行されたアクションのログを、Oktaやアプリケーションを通じてのログインなどの詳細と共に見つけることができます。
これは、Oktaでアクセスされた他のプラットフォームからログをインポートできます。
到達したAPIレート制限を確認してください。
ここでは、会社名、住所、メール請求連絡先、メール技術連絡先、およびOktaの更新を受け取るべき人とどのような種類のOktaの更新があるかについての一般的な情報を見つけることができます。
ここでは、他の技術とOktaを同期するためのOktaエージェントをダウンロードできます。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
