A Brief Look At 2 IdaaS Attack Paths
What is IdaaS?
In a nutshell Identity as a Service providers are cloud based services that organizations leverage to provide a means for employees to remotely access some organizational resources such as email, chat, file storage, etc. Often times an organization will link the IdaaS service to an internally managed authentication system (such as Active Directory or a custom LDAP solution) so that the employees are logging in with the same set of credentials used in their corporate environment at work. Usually an employee will access the IdaaS solution remotely over https, enter his/her corporate username and password, use their corporate two factor authentication solution, log in, and then proceed to access organizational resources (email, file storage, company messaging, etc.). Some organizational resources will require a corporate VPN connection to access while others will not (more on that later).
A few commonly known/used IdaaS providers include:
- Okta ([company].okta.com),
- Microsoft (login.microsoftonline.com and enter company email address), and
- OneLogin ([company].onelogin.com)
This post focuses mostly on okta and onelogin. There are several new IdaaS solutions with different areas of focus.
Below I will share some attack paths that I have taken during prior red team operations.
Attack Path: 2FA Man In the Middle Phishing
Since IdaaS solutions provide a means for employees to remotely access corporate resources, these solutions will definitely be attack points for red teams and real world attackers. The first attack path I wanted to point out is the concept of two factor man in the middle phishing.
Kuba Gretzky introduced this concept when he released his Evilginx2 tool:
Kuba has a detailed blog describing the inner workings of this tool:
As more organizations have shifted to two factor authentication on publicly facing VPN and login portals, the effectiveness of traditional credential harvest phishing has been limited a bit. However, EvilGinx2 was introduced as a means to show that attackers can still be successful even when most methods of two factor authentication are enabled (U2F 2FA is the exception). In summary, EvilGinx2 essentially proxies the login process by standing up a fake login page that looks identical to the target login site and proxying each phase of the login traffic, including the 2FA login.
Below is an example from peerylist showing an overview of how EvilGinx2 does man in the middle 2FA phishing (their example shows a google site as the target):
Simple steps an attacker could take:
- Check to see if the org uses okta or one login. This is as simple as searching for [organization].okta.com or [organization].onelogin.com.
- Configure an EvilGinx2 phishlet for the organization’s okta or onelogin login page (there are several templates to work from available in EvilGinx2).
- Craft a phishing email with the fake login link and send. The attacker could search the DNS TXT records for the organization to see what services may be listed there dns impersonate one of those services.
- Once an employee falls for the phish, the attacker gets the login credentials as well as the okta or onelogin session token.
EvilGinx2 allows the attacker to capture both the login credentials and the token. The attacker can then import the captured IdaaS session token into a browser (using browser plugins such as EditThisCookie) to gain access to that active IdaaS session. Once an attacker has imported the stolen session token into their browser, all organizational resources (shown as “tiles” in okta and onelogin) that do not require VPN access will now be accessible by the attacker.
Below is an example Okta tile page (from okta’s website) that a user sees once logged in:
Below is an example OneLogin tile page (from onelogin’s website) that a user sees once logged in:
In a real environment these tiles accesses will be specific to each organization. Often times email, company messaging, or file storage solutions may be accessible without needing VPN access. An attacker being able to access that information can be detrimental to an organization and provides a relatively quick path to accessing sensitive data without an attacker needing to gain shell access to a corporate system.
To recap: Any organization using an IdaaS provider and not using U2F two factor authentication should proactively explore this attack vector. This may mean having your internal red team (or a contracted third party red team) target your IdaaS login portal via phishing with tools like EvilGinx2. This will give your blue team the opportunity to explore what their visibility and detections look like for compromised IdaaS tokens and will also evaluate their ability to revoke compromised session tokens.
Attack Path: Password Attacks
Since each organization using an IdaaS solution will have a publicly facing login portal for employees to authenticate to, password spraying (or even credential stuffing) attacks will also be an attack path. Common password spraying attacks may take a list of usernames and try common weak passwords like “August2020!” or “Qurantine2020!” and see if any accounts successfully authenticate. There are several tools available that make this easy in an automated manner for various IdaaS providers.
Several organizations that use two factor authentication on their login portals use a push-based means of two factor authentication where the employee logging in will receive a “push” to their mobile device that he/she will click “Yes” or “Accept” on as a means of 2FA. With this type of 2FA, an attacker can still be successful gaining access to an IdaaS login portal via password spraying…this would just require a targeted user to click “Yes” or “Accept” when he/she receives the 2FA push (initiated by the attacker logging in) on their mobile device. While the chances of this happening may be minimal, there are still corner cases where this could happen. One example is perhaps there are employees who are not very security conscious and would likely accept any 2FA push sent to their phones. Another example is the attacker happens to login very close to the time the actual user logged in, which may cause the employee to accept the attacker initiated 2FA push as a “duplicate”. Running this type of attack proactively (and in an approved/controlled manner) could also help verify whether or not the blue team has visibility on when a password spray or credential stuffing attack is happening and will help confirm whether rate limiting or other prevention controls are operating as expected.
Post Compromise
Once an attacker has successfully “2FA Phished” a user and is inside of their IdaaS portal, the attacker will likely have access to the user’s email, company messaging (solutions like Slack), and maybe file storage (perhaps a cloud provider like GDrive or Box is used to store files and does not need VPN in order to access). An attacker accessing these items alone could be detrimental to an organization. An attacker could read the compromised user’s email (probably some sensitive company information there), search messaging platforms for secrets (ex: credentials posted in Slack), find sensitive information in documents, etc. An attacker could also conduct “internal phishing” using the compromised user’s email and send malicious documents or links to fake login portals to other employees in his/her contact list. Or perhaps the attacker could message other employees using the messaging platform (ex: Slack) and social engineer them to open a malicious attachment. Imagine if the compromised employee has access to source code repos (ex: Artifactory) or HR data (ex: Workday) via the IdaaS login, and neither of these require VPN access. The level of access and the impact of that access could quickly grow from here.
Summary
I recommend that any organization using an IdaaS solution (ex: okta or onelogin) proactively assess their publicly facing IdaaS login portals via 2FA man in the middle phishing with tools like EvilGinx2. This can be done using your internal security team or by hiring a third party red team contractor. This will help identify the state of blue team visibility/detections around IdaaS account compromise and help assess the org’s ability to revoke compromised session tokens (since password resets alone usually do not remediate compromised session tokens). One detection that blue teams can look into is the use of the same session token from more than one source at one time. Testing this proactively can help to see whether that type of visibility is currently in place in your org.
Using U2F as the means of two factor authentication would be effective against this attack, however a lot of organizations may not have the ability to revert solely to U2F for various reasons. Another helpful remediation would be to move as many okta/onelogin tiles as possible behind the corporate VPN. That way, once an attacker gains access into a targeted user’s okta/onelogin panel, there are very limited options that the attacker can access (since the attacker would likely not be on corporate VPN). I believe this type of federated access is becoming more and more common (especially with tech companies) and so I believe proactively looking at this part of your environment will be very beneficial from a detection and prevention standpoint, before it is targeted by a red team or attacker.
