0ktapus for humans

Preface

On August 7th this year an attack called #oktapus started to get uncovered by Group-IB. The attack was targeting Okta customers, but how does the sentence “9,931 accounts at more than 130 organizations were compromised by a phishing attack on Twilio and Cloudflare employees” make sense? These are just two companies and only one of them reported the attack to be successful. So how does that data make sense? Let me start with an old joke: A man is flying in a hot air balloon and realizes that he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts, “Excuse me. Can you help me? I promised a friend I would meet him half an hour ago, but I don’t know where I am.” The man below says, “Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees north latitude, and between 58 and 60 degrees west longitude.” “You must be an engineer,” says the balloonist. “I am”, replies the man. “How did you know?” “Well…” says the balloonist. “Everything you told me was technically correct, but I have no idea what to make of your information and the fact is I am still lost.”

I am going to skip the retort about the balloonist being a manager, but we get the point. #management and #engineering have a communication gap and in #security it’s even worse, as we #engineers talk jargon and details, trying to impress our peers rather than explaining what we are seeing. I am going to do what Richard Feynman did to the Challenger report, oversimplify it. I am going to make hypotheses without complete data and skip details, but give a big picture that is #ciso readable and action-oriented to help address the following:

1. If you are an Okta customer, should you be worried and what should you do?
2. What does the recent attack mean in terms of security threats and the direction it is taking. (and why you should care about #itdr)

What do we know so far?

Around August 4th a #phishing attack targeting the texting infrastructure company Twilio was launched. The attack targeted its Okta infrastructure, while trying to dig deeper at attacking Okta customers. There was also a failed attack targeting Cloudflare. We know the attackers also gained access to Signal Messenger. The attack was first reported by Group-IB and each of the companies attacked, including DoorDash, all acted in a very responsible and transparent way. They reported timelines and #iocs , provided screenshots and reversing reporting. But no one has said what it means for customers and users. So here are a few points, in order of importance to you, an Okta or #AzureAD customer.

1. The attack was very well planned, but not very technologically sophisticated. They used a known toolkit that emulates the Okta login page, mainly for desktop, but they also targeted mobile. Meaning this was a smart attacker making the most of the tools they have. Why target Okta now? Well because, like RSA 13 years ago, they hold the keys to the kingdom in many organizations. For you, the customer that thinks that MFA (often based on weak factors like SMS) solves all your Identity threats, well, this is not the case. We passed the stage where outrunning the slowest of the group was enough. Now you do need to outrun the bear, or at least a big enough part of the pack. Later in this article I will give you tips on how to outrun the pack.
2. Most text messages over the internet go through companies like Twilio, so if someone wants to attack users using SMS, you would go after such companies. If I were to attack such companies, intending to hijack authentication sessions, capturing SMS traffic for authenticators would be my move. I am not sure if either Okta or Twilio commented on what role Twilio plays in Okta SMS traffic, but I would not be surprised if the former was used to carry authentication messages. It is interesting that they have a dependency on one another.
3. Also, I would guess Okta leverages Cloudflare, because this is not the first attack relating to both. Someone is trying to host and hijack Okta-hosted login pages. Okta allows you to pick one of three options: (i) Okta hosted domain and application, (ii) Okta hosted application, but not domain (custom domain names) and (iii) you host everything.
4. Right now the most valuable assets are credentials. The attack goal was to steal as many of them as possible, partial or full. Specifically, targeting organizations that are part of the global software supply chain. These credentials in turn can be used to attack the next step. This is not the last time it will happen. You need to be able to address an attack on your identity infrastructure provider.

Recommendations

Get rid of SMS usage as an authenticator.

Many customers still have SMS or phone calls as an authentication factor. This needs to go away, even as a recovery factor, unless you keep a close eye on using it for recovery. What factor should I use if my install base refuses to use anything on their personal phones? Are they willing to only access from company devices? If the answer is yes, just install Okta fastpass or Duo Security on their endpoint and use a biometric as a factor. If the answer is no, still consider pressure, mainly due to overall data security. It’s a bit complicated to want access to company data without company oversight. TOTP is not fun, but can also work. Most solutions these days support phone built-in solutions and do not mandate the client.Last solution should be a Yubico security keys, not because they are bad, but rather as the person that dealt with provisioning RSA tokens, physical tokens take forever to get to where they are going, while they are the most effective measure, just ask the person that had his kid flush one down the drain, what they can do then.

To effectively get rid of SMS, you will need to get a sense of who has SMS registered as a second factor, and who is actively using it. Also you need to know if SMS was used as a factor while accessing sensitive applications like the Okta admin console. If you have not migrated to OIE (Okta Identity Engine) yet, you might want to have a stronger policy on specific applications allowing SMS only on the lower-important ones. If you do have OIE, there is a way to allow SMS only for recovery purposes.

Understand that phishing works even with MFA

I attended a conference where I heard that there are phishing resistant factors. I was told the same thing at RSA in 2008. We know how that worked out for the people in question. People are phished, not technologies. People don’t look at the key on the browser or don’t read the URL. Until continuous authentication becomes a thing, phishing will continue to work. But there are steps you can take to reduce the risk:

1. If you are a medium size company, start by using your own domain in Okta, it’s simple and easy and gives you a much better user experience.
2. If you are a larger company also customize the user experience as much as you can and go with identifier-first flows.These are harder to phish. Don’t know what these are? Call me or your Okta/Azure/Auth0 rep or see the figure above.
3. SP initiated flows are your friends. It’s hard to change every single application you try to access. Host your own launch pad and point to real applications. It’s not hard work and it makes it hard to replicate.
4. After all else fails, monitor for session hijacking and replication. First, it helps even when it’s not phishing but also for insider threat. You don’t care how the session was stolen (or handed over), you just detect that a session was switched in mid-flight and if the IP is not known, make people re-login. If they use FIDO and fingerprints, it’s low friction with just one tap. Which leads to my final recommendation…

Monitor your Identity infrastructure

Identity is the new firewall/endpoint and it is under attack. This was the 4th major attack in 6 months. You can chose to push #itdr lower in your priorities, but what happens if the next call you get from your IDP is because your name was among the 130 companies whose data was lost? Can you answer quickly to your management chain questions such as:

1. Was there any access to sensitive resources at these times from compromised accounts?
2. Who accessed resources, changed factors or impersonated users during the time of the suspected activity.
3. Were there suspected hijacked sessions during that time or after?
4. What was your business exposure?

If you can’t answer these, I suggest we demo to you how this can be done quickly without commitment. If you suspect you might have been impacted, we give free assessments too.

Apologies

Once a year I like going places that have no or limited internet connection and do fun things like hiking and biking. This year was the worst timing ever, between Cloudflare and Twilio attacks and Gartner IAM, I missed out on a lot, but have little regrets. Here is my take on #oktapus, but one week later.