Stay informed of new publications and releases
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
This blog post is authored by Rojan (@uraniumhacker) and Tanner (@itscachemoney).
Anti-phishing tools and products are used widely at various enterprises to prevent malicious emails from landing in employees’ inboxes. Anti-phishing tools are set up in multiple ways: as proxies where all emails, regardless of the mailbox, are scanned before reaching the mailbox or reporting service for employees to report suspicious emails manually. Some companies provide phishing reporting services for their users as well. For example, as a customer, if you receive a suspicious email, you can report it to phishing@company.com to mass report such situations. We exploited the behavior of these services to gain access to various companies’ internal Software-As-A-Service (SaaS) services. This vulnerability is hard to fix, and in some cases, email security service providers have opted out of fixing it due to how it is exploited and have asked organizations to add additional security measures in their SaaS services. Additionally, SaaS services have started adding authentication requirements to prevent exploitations.
In this blog post, when we mention anti-phishing tools, we are talking about email security gateways and phishing vendors designed to provide services to tag, detect and squash potentially malicious emails before they reach inboxes. Some examples of these products are ProofPoint, Barracuda Networks, and Palo Alto Networks Cortex XOAR. Some of these services act as proxies and scan all incoming emails, while others are more for reporting services such as Cortex XOAR.
Automated email gateways are proxies between the mail service and receiving mailbox. For example, looking for MX records for various large corporations will only sometimes point to Office 365, GSuite, or internal SMTP services. Most of the time, the MX records point to records such as mx-CUSTOMER_ID.gslb.pphosted.com. In such cases, ProofPoint’s email security gateway will scan incoming emails, then send them to the appropriate mailbox based on the From header.
On the other hand, reporting services are ad-hoc and act based on emails reported to them by a user. In this case, the user could be the company’s customers, employees or both. In these situations, an organization will have an established phishing reporting mailbox, such as phishing@company.com. When a user forwards a potentially malicious email to the mailbox, the XOAR service will perform various scans to detect/decide if the email is malicious.
Regardless of the setup, most email security services have one behavior in common: scanning for malicious links and attachments within an email address. Whenever a potentially malicious email is reported or seen by the security gateways, these products will “blow” up any URLs and hyperlinks in the email address. This is done to analyze the email for any potential phishing page, such as phishing login pages or malicious files such as malware links, malicious JS files, etc that could exploit the receiving user’s systems.
However, this feature has an inherent problem when sensitive links get analyzed. In the past, we have seen similar features disclose sensitive URLs to the public via misconfigured scanning technologies such as URLScan (https://medium.com/tinder/how-to-categorize-and-prevent-risks-of-sensitive-links-in-urlscan-d6cd0a58b0da). In this specific research; we decided to expand further than just disclosed URLs and instead focused on abusing SaaS services.
Most SaaS services are designed for enterprise teams rather than individual users. Most SaaS services provide a team feature where users of a specific domain can register and join the organization to make it easier for employees and organizations to register and log in quickly. A couple example of these services are services such as:
When a domain capture is enabled, a user can access all workspaces, teams, etc., in their organization once they have verified ownership of their registered email address.
Email verification is a security and product usage feature to ensure the correct user creates an account. An email verification kicks in various processes: signup, password reset, email changes, and sometimes profile changes. During our research, we decided to abuse some standard email verification techniques and features of email security gateways to access various internal services.
One common flaw among various email verification authentication is the lack of authentication in verifying the email. For example, commonly, this is how an email verification technique works when signing up:
In the last phase, most services do not require the user to re-authenticate before verifying the email addresses. We found this to be a typical behavior in various email services. Similar behavior also existed when you change the current email address in an existing account:
Knowing the email verification behavior of SaaS services and that most also provide domain capture where a verified email can create and access workspaces for the organization, the only remaining vector in this chain is email security gateways. As we already covered, anti-phishing products “blow” up any hyperlinks. The same behavior also occurs when these security gateways see hyperlinks for email verification requests from SaaS services. In the end, our attack flow looks something similar to this:
Early in our research, we identified that Atlassian’s signup flow allowed unauthenticated email verification. The flow allowed signing up with an email and password combination. When signup was completed, the email verification link could be opened by anyone (including the gateways we were targeting). Once the email was verified, Atlassian’s API would disclose all joinable JIRA and Confluence cloud instances.
When testing an organization, we identified a public phishing@ email address for customers/users to forward any potentially malicious emails acting as the company. We were able to signup in Atlassian with the phishing@ email address. The email verification was then auto-clicked by the phishing scanning system, thus verifying our account in Atlassian. We then attempted to join one instance and list its registration requirements. This specific instance had an allowlist allowing the company domain to join the JIRA instance.
We further confirmed that we could join the sites by going through the site registration process. Once registered, we had access to all JIRA tickets for the organization, including but not limited to security reports such as reports they had received on bug bounty platforms.
One of the organizations we tested during this was Netflix. Reading through Netflix’s help portal, we identified a phishing reporting email that users could publicly forward emails to:
Further checking, we identified that Netflix used multiple SaaS services, including Atlassian. During the test, we created an account in Atlassian with a phishing@netflix.com email address. As a result, Atlassian sent an email verification to that email address. Since the email inbox used an analysis service, the application auto-clicked on the GET-based email verification URL that did not require authentication. This then gave us a valid account in Atlassian with a verified @netflix.com email address. Similar to the above example, we could access then internal Atlassian sites that allowed any netflix.com email address to join.
We reported the vulnerability to Netflix once we confirmed access to internal sites. Netflix quickly patched the vulnerability by temporarily turning off the link follow. In addition, Netflix introduced us to their vendor that supported the phishing@netflix.com inbox. Upon discussing with the vendor and Netflix, we concluded that it would also be helpful to report the unauthenticated email verification issue to Atlassian. Atlassian also accepted the report and changed the signup flow to require email verification before setting the password in the account. As a result, attackers now need to know the email verification link to access and add the password to the account thus making the vulnerability hard to exploit.
In contrast to accessing internal SaaS services, the email security gateways itself can be used to further spread phishing emails from trusted looking resources with help of services like Amazon Simple Email Service (SES).
AWS SES allows organizations to automate sending emails with any verified identifies (domains or email address). This is a frequently used feature by many organizations to send automated emails to their users. Similar to domain capture & email mailboxes, SES is a perfect target surface when an organization uses email security gateways that scan any emails despite if the mailbox is actually valid or not. For example, an email security gateway could scan an email coming to jill.cycle@ophionsecurity.com even if that email does not exist in Ophion Security’s mailbox.
In situations where an email security gateway scans any mails coming through, SES could be a perfect attack vector. With a non-sandboxed, simply adding a new email would trigger the verification process.
The email security gateway would parse the email and unfurl any URLs in the email. This will include the email verification link sent by AWS. Once unfurled, the email address will be marked verified in AWS SES and can then be used to send realistic looking email from the email.
In addition to sending trusted emails to any mailbox, this also allows for sending emails to internal Google groups of the organizations. Sending targeted emails to internal groups will further allow spraying targeted phishing links such as Okta logins and more to the organization. Tanner has written an excellent blog on exploiting internal mailing lists to send targeted phishing attacks: https://medium.com/@cachemoney/exploiting-application-logic-to-phish-internal-mailing-lists-486b94fc2ef1
Email security gateways can allowlist specific domains or URL patterns to not unfurl when analyzing email content. These include URLs that are sensitive and match specific tokens like email verifications, password reset, and more.
SaaS services can remove themselves from the exploit chain by changing the email verification process to require user authentication or additional steps. A great example of a fix would be what Atlassian did by moving the account setup process into the email verification rather than separating the two.
We want to especially thank Netflix for working with us. They were among multiple organizations highly receptive to the report and understood the potential impacts. They also helped us communicate the concern with the email security gateway vendor. Overall, one of the best bug bounty programs that reflects company values of innovation and curiosity with every bug report they get.
Unfurling behavior can result in a range of various vulnerabilities. We covered some in this blog, and there are probably numerous others that can be found or abused.