Welcome to Part 3 of Okta Attack Techniques!
In this article, we will cover how an attacker or any malicious actor can abuse three different Okta AWS applications to gain access to the AWS environment. The attacker can achieve this by laterally moving from the Okta environment to the AWS environment through these applications. If you are not familiar with Okta or have not read the last two articles we posted, we recommend reading them here: Part 1, Part 2
In the first part of this article, we will demonstrate how the relationship between the Okta environment and the integration AWS applications works and where we got the roles or permissions set for our Okta user.
The applications we will work with are the following:
- AWS IAM Identity Center
- AWS Account Federation
- AWS Console Password Sign-in
Figure 1 – AWS application
Let’s dive into how those applications work, to understand how we can abuse them to get initial access to the AWS environment.
AWS IAM Identity Center
Federating with AWS IAM Identity Center (successor to AWS Single Sign-On) enables an Okta sign-in experience to AWS and a single way to manage access to the AWS console, AWS command line interface, and AWS IAM Identity Center-enabled applications centrally, across all your AWS Organizations accounts. Administrators can federate Okta to the AWS IAM Identity Center once and configure roles and access centrally in AWS IAM Identity Center.
The AWS IAM Identity Center then provisions roles, assignments, and trust configurations automatically across multiple AWS accounts. After authenticating with their Okta credentials, end users can see and access their assigned AWS accounts and roles and their AWS IAM Identity Center-enabled applications.
Figure 2 – AWS IAM Identity Center Integration architecture with Okta.
In this application, Okta users are provisioned to the AWS environment via SCIM using the https protocol. Each Okta user has their Okta role (can be custom or standard), and when this user is provisioned to the AWS environment, and you add this user to the AWS account, you have to assign this user a permission set. That means each user assigned to this application will get some permission set that allows them to perform actions in the AWS environment. As a result, an attacker can abuse this application to gain access to the AWS environment and use the permission set that belongs to them to escalate their way in this environment.
AWS Account Federation
By federating Okta to Amazon Web Services (AWS) Identity and Access Management (IAM) accounts, end users get single sign-on access to all their assigned AWS roles with their Okta credentials. In each AWS account, administrators set up federation and configure AWS roles to trust Okta. When users sign-in to AWS, they get Okta single sign-in experience to see their assigned AWS roles. They can then select a desired role, which defines their permissions for the duration of their authenticated session. Customers with large numbers of AWS Accounts can check out the AWS Single Sign-On app as an alternative.
Figure 3 – AWS Account Federation Integration architecture with Okta.
AWS Console Password Sign-in
AWS Console Password Sign-in, end users can sign in with their Okta credentials and get one-click access to the AWS Console. Using the Okta Browser Plugin for Secure Web Authentication (SWA), end users can set and update their AWS account credentials. When end users navigate directly to the AWS Console, the plugin automatically posts their Okta credentials securely over an SSL connection and signs them in without further interaction. For federation-based alternatives, check out the AWS Federation or AWS Single Sign-On apps.
Figure 4 – AWS Console Sign-inIntegration architecture with Okta.
This application is not complex like the others, as it allows the user to login to the AWS console via your Okta tenant. In some cases, the Okta admin is able to configure the application to allow the user to reveal the password. As a result, with the right privileges, an attacker or any malicious actor can reveal this password and then log in to the AWS environment. In this case, we don’t know if the Okta user has permissions set role in the AWS environment because it’s not necessary to assign one of them in order to create the integration between the environment, as it’s just username and password.
Attack Scenario 1
In this scenario, we will demonstrate what action you can take if you have a user with the standard role “Group Membership Administrator”, in which case you can use this role in order to find a way to log in the AWS Environment.
Figure 5 – Attack Diagram
It’s the right time to ask yourself if the “Group MemberShip Administrator” Standard role has some limited resource sets or if we have the ability of this role on all the groups in our Okta tenant.
This is Okta’s official answer for this question:
This absolutely will be one of the recommendations at the end of this article 😀.
Let’s start to enumerate the basics; so we have an SSWS Token of “Group Membership Administrator” on all the groups in the Okta tenant.
First, we list all the groups we have in our Okta tenant using the Okta group API:
Figure 5 – List all the groups in the Okta tenant.
We are focusing on the “XM Group Test 1” group and now we are going to take the ID of this group to list all the members inside this group.
Figure 6 – List all the members in the group.
We list all the members in this group and we can use this information for several goals:
- Select target user to attack
- Gather information about applications assigned to the group
The next step in our case is to try to gather information about the application assigned to the groups. Let’s try to use “List Assigned Application”.
Figure 7 – Empty response to see which application is assigned to the group
To get the information, we need to do a workaround. To find the application, we can take one of the users we found in Figure 6 and use the Okta user API to list all the applinks that are associated with our user.
Figure 8 – Get the application that is assigned to the user
Note: We don’t know for sure that this application is assigned to the group or to the user directly. One way to know for sure is to add users to this group and see if applications are added to the applink. If so, that means the assignments to the group automatically assign the user to the application.
Let’s check our theory, and check the applink of our user “Group Membership Administrator” and then we will add these users to the group of “XM Group Test 1”.
Figure 9 – figure out which application is assigned to the group
As we can see in Figure 9, we first ran the “Get-OktaAppLink” to check if the user “GroupMembership [email protected]” was already assigned to an application, and we got the response null. In the next step, we added our user to the target group “XM Group Test 1” and after we did it, we again ran the applink command and we found a new application assigned to the user. This means we found a workaround to know if the group was assigned to the application.
In this case, we added our user to the group that was assigned to the “AWS” application. Now, we can use this user in order to log in to the AWS application. Because we have the credentials for our user with group membership admin standard role, and also now thanks to the fact our group is assigned to an application, we can log in to the AWS environment.
Remediations
- It is recommended not to use the standard role ‘Group Membership Administrator’ and instead use a custom role with the following permission: ‘okta.groups.members.manage’. The reason for this is that custom roles can be restricted to a specific resource set, allowing you to grant these privileges only for a small scope of groups or even just one. This helps prevent malicious actors from enumerating additional resources in your Okta tenant.
Attack Scenario 2
In this scenario, we will demonstrate what actions you can perform in cases where you have a user with the standard role “Application Administrator”, in which case this role can be used to find a way to log into the AWS Environment and to configure a SAML Role that will be more than relevant in the AWS Environment.
Figure 1 – Attack Diagram.
In this scenario, we show why the “Application Administrator” standard role is a strong role that, if an attacker or any malicious actor gets their hands on this user, it can be dangerous. We start this scenario with an SSWS Token that is associated with the standard role “Application Administrator”.
Now the first action is always enumeration. Let’s list all the applications in our Okta tenant and focus on the “AWS Account Federation” application.
Figure 2 – List all the Okta tenant applications.
Now, because we have a “Application Administrator” standard role, we can assign users to applications. As a result, we can add users to the application and then to get access to the AWS environment.
Let’s assign a user to the application and then list all the users assigned to the application to check that our user is successfully assigned to the application:
Figure 3 – Assigned user to Application
In Figure 3, we can see in “AWS Account Federation” the fields Role, SAML Roles, which means we basically have the ability to enumerate the roles that are assigned to users. From an attacker’s perspective, this information allows us to understand which users we want to target, especially the ones with an admin in their role.
During the integration of Okta with the “AWS Account Federation”, to enable full integration and to provision roles, we need to create AWS user access key credentials with read access to get all the roles that are created in the AWS environment and provision them to the Okta tenant environment. To list all the AWS roles provisioned to the Okta environment, we need to use the Okta internal API that allows us to get this information.
Figure 4 – List all the roles that provision from the AWS environment
Now, we want to assign roles and SAML roles for users, so we will use the Okta request when trying to update a role or SAML role. Then we intercept this request in a proxy and create a PowerShell to implement in our tool.
Figure 5 – Update role for our user.
To summarize, this case demonstrates the power of the “Application Administrator” Standard Role, since with this privilege we were able to control all the applications in Okta Environment and to enumerate the applications, assign users to the app, update the role, and a whole lot more than that.
Remediations
- It is recommended to not use the standard role “Application Administrator” and instead use a custom role with the following permission: ‘okta.apps.manage’. This is because custom roles can be restricted to a specific resource set, allowing you to grant these privileges only for a small scope of applications or even just one. This helps prevent malicious actors from enumerating additional resources in your Okta tenant.
Conclusion
If you’ve read this far, congrats, you are now an Okta attack techniques master! Of course we don’t suggest attacking anything for its own sake; the point here is to understand how attackers see your networks, applications, and environments and to learn how to improve your organizational security posture.
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}