The Dilemma of Attacking Okta, Red Team Operations

Introduction

Intro-Login

An ominous login page, mysterious isn’t it? This page is seen by hundreds of employees/customers of companies like Discord, Microsoft, Paypal, GoDaddy, Roblox, etc. This is an Okta login page, successfully authenticating yourself with one of these will usually redirect you to a companies internal services, such as: Jira, Confluence, Metrics systems, the whole shebang!

Okta?

Okta is “an American identity and access management company” that allows companies to easily manage and control access to different parts of their infrastructure. Okta is usually used to authorize and manage access to internal services. As a hacker this information is very valuable; so many attack vectors include Okta access as a prerequisite, or even an end goal.

The Authentication Dilemma

Given all thats on the table for Okta, and the companies that are involved, Okta has their work cut out for them in terms of keeping employee accounts safe.

Okta offers many authorization methods, some examples include:

  • Basic username:password Pairing

  • Common 2FA: Google Authenticator, Email, SMS, etc.

  • MFA (biometrics, location information, YubiCo’s YubiKey)

  • 3rd Party Auth Services: Oauth, OpenID, SAML and FIDO.

  • Customized API/HTTP Auth


This is perfect for companies that try their best to be as secure as possible, but for attackers this is yet another hoop that you have to jump through in order to achieve that initial access you are depending on.

Attacking Okta Authentication

Trying to gain unauthorized access to ANY okta account may seem like trying to infiltrate Fort Knox. But like all things let’s try to break this big problem down into smaller problems:

  • Accessing Employee Information (usernames, corporate emails, phone numbers)

  • Accessing Employee Credentials (passwords)

  • Accessing Needed MFA Vessels (2FA Codes, Physical Tokens, Biometrics)

Now once again the first two aren’t that hard. Some mass phishing or remote access would do the trick. The main issue is companies that use fairly secure authorization methods, a perfect example of this of YubiCo’s YubiKey.

They are the “un-phishible” hardware authorization solutions. Google, Amazon, Microsoft, Twitter, and Facebook all use YubiKey to add an extra layer of security to both employee and end user accounts, but we will talk about them later.

The Actually Secure Companies

Some companies only use common username:password login systems, maybe 2FA using Google Authenticator/SMS. Most adversaries can easily get past this using an Adversary in The Middle (AiTM) attack with a service like Evilginx2.

Actually secure companies use hardware/biometric solutions. These are by far some of the most secure authorization solutions on the market. it seems as hardware based solutions are the best of the two, due to the simple fact biometrics can be easily stolen/reproduced (article on the topic).

Back to hardware solutions, why are they so secure? This is something that only the employee has access to this solution. There is also a “single origin verification protocol” that makes phishing these keys even harder.

YubiKey :rage:

YubiKeys use a protocol known as “origin binding”, in lay-mans terms: when a key is registered is in binded to a certain domain, so if you try logging in on another domain, your key wont allow it.

What happens is the browser signs the request to the security token with the website URL. The security token’s response based on the secret includes this as a result. So if you try to login to d0main.com instead of domain.com and get a U2F 2nd factor auth, the browser will generate a request based on d0main.com. Even if the malicious site, d0main.com, copied/repeated the public key info for the second factor auth request from domain.com, the browser would hash and sign the request as coming from d0main.com as a result. The resulting login token would not match up with what domain.com expected. The login would fail. - YCombinator thread

This simple check pretty much stops attackers from phishing YubiKeys. Of course that statement is only true in a perfect world, there could always be a vulnerability in the keys firmware, or in the browser itself (which is the intermediary between the login page and the key itself). An article on Chrome’s WebUSB is linked below:

An Un-patchable Vulnerability

With the concurrent growth of both employee security and the value of internal access, it is no longer uncommon to phish employees. But why take the time of your day to phish employees with a low success rate. when you can take a variate amount of time to extort/blackmail employees with a much higher success rate.

There are plenty of things certain people have to hide from their employers, but this is up to you, as a red teamer, to find.

Fin

What do you all think about Okta as an authentication service? Let everyone know!

9 Likes

I was testing once Okta in one company I was working for, and it is quite good protection. It also needs to be configured very well as in my test, new employees on the onboarding session was never instructed to configure it on the first day. The test was related to many vectors like Service Desk password reset, user authentication system etc. but when I finally got domain user and password from fresh employee (about 1 month old) I tried to login to some web apps protected by Okta, and I found that user never setup his 2fa. So when I was redirected from eg. Sharepoint to Okta for 2fa I was asked to set it up, and in this company it was only forced to use “security question” eg. like what is your favorite meal or other easy to guess, so I set it up, and was able to login to all systems where user was assigned to. This problem was more related to wrong onboarding procedures and some misconfigurations. Finally as a mitigation of the test, new employees on onboarding session are forced to set up Okta account and not only security question is mandatory, but also mobile phone/software or something else.

So even most secure solutions can be shitty if they are configured not correctly or procedures around them are bad.

Okta has also a lot of alerting which you can also ingest to SIEM, so if additionally SOC team is monitoring this it is even “more secure”.

And from user perspective it works very good and it is user friendly.

One tip for testing, if you see security question about favorite food, try “pizza”. In my test it mostly woks :stuck_out_tongue:

6 Likes

A fun old story about the “favorite food” question; always try the food that is either (a) geographically close to the business you’re testing, (b) a food that is commonly consumed in the state/country, or (c) whatever you find boxes of if in a pentest you get to search the trash.

Besides that, very informative and useful post. Nowadays Okta is very widespread.

3 Likes

BTW - https://sec.okta.com/articles/2022/12/okta-code-repositories :upside_down_face:

1 Like