Oktapus

ACM.123 Reviewing one of the most dangerous attacks in 2022 to design an authentication system less susceptible to attack

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Data Breaches | Okta | IAM | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It’s always a good idea to review past data breaches like I did in the last post to determine what happened and how you can prevent a similar attack in your own organization. In my last post, I wrote about how we might design a batch job authentication flow and potential threats. I mentioned that we don’t want batch job administrators and cloud users to fall victim to something like the Oktapus breach. Let’s take a closer look at what caused this breach and how we might prevent it.

Researchers from Group-IB reported on one particularly far-reaching attack in 2022. They named the attack Oktapus — because it make use of Okta, a product that helps identify users and grant them access to systems.

Okta has been in the news a few times in the past year, but this particular attack was not their fault. Attackers tricked users to enter credentials on a fake authentication page that looked like the pages where they log into Okta.

Technically, the attack was the fault of the users that entered their code into the fake platform, right? They were tricked into doing so via a phishing attack. Perhaps the users should have recognized that the page where they submitted the code was a fake, but sometimes when you’re in a hurry to get your job done you might not notice the details that indicate the page is a fake.

What if we designed our systems and trained our users to make it harder for a breach like this to occur and easier for users to identify and report. In some cases, companies do not train employees to be cautious enough, or use systems and processes that are easy to spoof and fool users.

What if one of my less technical interns was using the batch job system I am trying to create? What if they got an email or text message and thought I had sent it to them? It’s easy for me to imagine them clicking on something they shouldn’t. Some of them have little technical experience. I hire them to help me test my class labs, which I want to be simple for non-technical users. Sometimes they perform the very basic parts of penetration steps like running a Burp scan.

Let’s take a closer look at how the users got tricked and consider how we might prevent that in the system we are creating.

How did the Oktapus attackers trick users into giving up credentials?

We can review the details reported by Twilio, one of the companies affected by the Oktapus attack. The report they produced is a very generous and helpful account and I wish more breach reports would look something like it, instead of the copy and paste letters drafted by lawyers associated with most breaches that I wrote about in the following post.

In the following incident report we learn that Twilio users received highly targeted attacks that matched a message that might come from the Twilio IT department.

That article shows two examples of the text messages users received. The URLs were specific to Twilio so this was an very targeted attack. The attackers registered a domain name specific to that company. Users clicked the link in the text messages to change their passwords as directed.

When the users clicked on the link they were taken to pages that looked like what they would expect to see for the company systems where they manage their passwords. The following article has pictures of the the lookalike login pages, details about the code and targets in the attack.

All that is interesting, but what we really want to figure out is how to prevent this attack in the new system we want to implement. How can we ensure our users and administrators do not enter their user names and passwords into a fake website?

Preventing users from clicking links in text messages — don’t send them!

If Twilio has a standard process that texts users when their passwords are expiring, it would be easier for attackers to trick them into clicking this link because they would be expecting something similar. It may be that Twilio does have such a workflow, since they specialize in text messages. If so, they should perhaps refrain from including links in text messages and tell users to go directly to a portal by typing the URL In the browser to login and to never click a link in an email or text message. They could make the URL something easy for users to remember and tell the users to double check the URL is correct before entering a password.

If the company has no such process of texting login links to users, then they should have made it very clear to new hires and existing employees that they will never receive a text message for this purpose. Twilio does outline in their post that they provided additional training to their staff.

As I mentioned in my prior post on a potential batch job authentication flow, I think SMS messaging is too risky due to all the Smishing (SMS — phishing) attacks going around at the moment to receive a message and respond with a code. It seems that sending a link in a text message or email might also be risky. I will probably avoid that altogether.

Let’s continue reviewing the impact of the Oktapus attack.

Limiting sensitive actions to corporate networks

Through the phishing attack (or smishing, if you prefer) the attackers gained access to customer service accounts at Twilio. Once the attackers got the credentials for customer service professionals, they could take any actions the customer service professionals could take.

Perhaps these attackers took the actions on a system that resided on the Twilio network. If the attackers could take their actions from any system on any network, then there were no network controls in place to prevent sensitive actions from occurring on a non-Twilio network.

We can design our system so that particularly sensitive actions can only be initiated from valid networks in addition to being performed by valid credentials. We can also design two step processes so that a single step cannot be used to trigger sensitive actions. We could even require two people for highly sensitive operations.

How stolen Twilio credentials impacted Signal

Once attackers were able to access Twilio they could then compromise customers of Twilio’s customers. One of Twilio’s customers, Signal, is known as a more secure option for messaging. Signal offers end-to-end encryption — for end user communications — and they do not store users’ data.

How this attack affected Signal:

The key part of that article for our purposes is the following:

• An attacker gained access to Twilio’s customer support console via phishing. For approximately 1,900 users, either 1) their phone numbers were potentially revealed as being registered to a Signal account, or 2) the SMS verification code used to register with Signal was revealed.
• During the window when an attacker had access to Twilio’s customer support systems it was possible for them to attempt to register the phone numbers they accessed to another device using the SMS verification code. The attacker no longer has this access, and the attack has been shut down by Twilio.

Signal users that register new devices using SMS would be at risk. Apparently the text messages were visible to Twilio’s customer support team.

The role of encryption — what it does and does not protect

The fact that an employee at Twilio had access to the text messages in flight that was being sent to a customer indicates lack of end-to-end encryption for SMS messages containing critical 2FA codes and messages or metadata containing PII (user phone numbers).

Attackers could use this information to potentially register a new device to a Signal customer account and obtain *new* messages transferred over the Signal system. However, because Signal itself does not store customer data, the attackers could not obtain user messages and information other than what is explicitly required to transfer messages to end users.

First, this breach reinforces the encryption fallacy I wrote about in this post:

End-to-end encryption did not help Signal users because the unauthorized device registered to their account had permission to access the encrypted data and decrypt it.

However, if Twilio had implemented end-to-end encryption using keys not accessible to the customer support credentials, the customer support staff would not have had access to the two factor codes because only the customers would be able to decrypt their own data. Additionally, if the metadata surrounding the messages such as to which phone number the message was sent for which customer had been restricted from customer support staff without re-entering MFA or some other control besides an active user session, then the data used to register the unauthorized devices would not have been available to the attackers.

If we are going to send SMS messages to batch job administrators, we need to understand that encryption will not help us if our own employees’ credentials are compromised who are administering batch jobs. If the credentials allow access to the messages and the ability to decrypt the messages the encryption doesn’t disallow an attacker with those credentials from accessing the messages.

However, if we are going to use SMS messages to send sensitive data such as MFA codes or sensitive batch job information to our administrators, we would want to make sure those SMS messages are encrypted in such a way that support people at AWS working on Pinpoint or in customer service cannot see the contents of our messages.

I wrote about using Lambda and Amazon Pinpoint to send messages quite a while back and that got delayed due to trying to get set up to send messages, and because I had to finish other things first.

Can someone at AWS see your messages in PinPoint? Consider this documentation:

At the time of this writing:

Amazon Pinpoint uses HTTPS and Transport Layer Security (TLS) 1.0 or later to communicate with your clients and applications. To communicate with other AWS services, Amazon Pinpoint uses HTTPS and TLS 1.2. In addition, when you create and manage Amazon Pinpoint resources by using the console, an AWS SDK, or the AWS Command Line Interface, all communications are secured using HTTPS and TLS 1.2.

Considering that that the IETF has recommended that organizations stop using TLS 1.0 in 2008 and officially deprecated it in March 2021 hopefully TLS 1.0 is not in use in your applications if you are using Pinpoint APIs. That part of the architecture is on you.

This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346)… TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions.

Regarding KMS keys:

To encrypt your Amazon Pinpoint data, Amazon Pinpoint uses internal AWS KMS keys that the service owns and maintains on your behalf. We rotate these keys on a regular basis. You can’t provision and use your own AWS KMS or other keys to encrypt data that you store in Amazon Pinpoint.

It sounds like AWS controls the KMS keys in this case and you’ll need to trust that their employees don’t have access to decrypt data using those keys, or you can take additional steps to encrypt the messages before you submit them to the Pinpoint APIs.

One way we can further protect our batch jobs in this scenario is to ensure the data in the SMS message alone cannot trigger a batch job. AWS employees or attackers who have infiltrated AWS systems if something becomes compromised won’t have all the factors required to start a critical job.

We can also take addition steps to encrypt data before submitting it to the system that sends the text messages — but then how will the end user who receives the encrypted message decrypt it? They would need an encryption key or access to an app to decrypt the message using the corresponding key. Alternatively, I could encrypt the data with a user’s public key so only they can decrypt it with their private key if I keep the message small.

Therein lies the complexity and why I am going to opt to not send sensitive data in text messages at the moment. Perhaps I’ll revisit that later.

Cloudflare — hardware security keys to the rescue

Cloudflare was impacted by the same attack but in this case the results were a bit different. Attackers were able to trick users into visiting the site and possibly entering credentials but they were thwarted by hardware security keys.

While individual employees did fall for the phishing messages, we were able to thwart the attack through our own use of Cloudflare One products, and physical security keys issued to every employee that are required to access all our applications.

https://blog.cloudflare.com/2022-07-sms-phishing-attacks/

Note that the Cloudflare One products are a zero trust network control. I wrote about SASE products like this one here:

Once again, network controls can help limit attacks to your corporate network when attackers steal credentials. They may have the credentials, but they don’t have access to the network.

I’ve written about the importance of hardware security keys before as well. They are my top recommendation for small business and start ups with limited security resources:

As noted, I am not fully convinced using a Yubikey with the AWS CLI is a good idea:

I showed how to create policies to enforce MFA and how you might use an authentication app instead.

But if we are entering an MFA second factor into a website application, a hardware key might help.

I’ll continue to explore these topics in future posts as they will drive our choices for an authentication architecture for batch jobs.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab