Open Redirect in Oracle BlueKai

Phishing threat actors are continuously seeking new methods to increase the chances of success in their campaigns. Phishing is still one of the main initial access vectors into target networks. One technique that makes phishing emails particularly difficult to block is the use of open redirect vulnerabilities to distribute malicious links. Although often underestimated and left unaddressed for months or years, open redirect vulnerabilities can present a considerable risk to your users. Open redirect bugs often occur in the form of a parameter inside a query which contains a URL to redirect a user to. 


In late 2020, a client of mine was targeted in a spear-phishing campaign that leveraged a universal open redirect vulnerability in the Oracle BlueKai Data Management Platform. The vulnerability was responsibly disclosed to Oracle Security in December 2020. At the time of writing, the vulnerability remains unpatched and has not been assigned a CVE number (despite multiple other open redirects having one - see here). However, an attacker was able to conceal a malicious URL inside the BlueKai open redirect bug and was able to bypass the target’s secure email gateway (SEG) as a result.


Example of a malicious URL using an Open Redirect:


http://*.domain.*/dir/dir?redir=https%3A%2F%2F<malicious URL>


The <malicious URL> part is where the attackers were able to append their credential harvesting page to steal Office 365 account details. Email security tools are often unable to pick up that this is a malicious link as it comes from a trustworthy hostname with an established reputation. However, clicking on the link takes the user straight to the attacker’s credential harvesting page.


I recreated a proof-of-concept (PoC) for demonstration purposes of the scenario in which we saw this vulnerability in Oracle BlueKai being leveraged in the wild:



We also used a URL to demonstrate the common weakness enumeration definition (CWE-601: URL Redirection to Untrusted Site) to highlight the issue to Oracle Security:



Disclosure Timeline

  • 7 December 2020 - Discovery of In The Wild Exploitation
  • 8 December 2020 - Responsible Disclosure to Oracle (secalert_us@oracle.com)
  • 8 December 2020 - Oracle responds and assigns it the ID of "S1391642 - OPEN REDIRECT"
  • 23 December 2020 - First of many monthly Status Reports by Oracle
  • 23 June 2021 - Requested an update on the Open Redirect bug, six months after initial disclosure
  • 9 July 2021 - Oracle says the redirection is "key to the way the service functions" and there are "no plans yet to change the behaviour in the near future". Oracle employee considers the "issue as closed"
  • 17 July 2021 - Email sent to Oracle requesting permission to disclose the issue publicly on this blog considering the case was "closed" and is a "key way the service functions"
  • 22 July 2021 - Product Security Group Manager of Oracle responds saying the bug has been "escalated internally", but has determined that the redirect behaviour is a "known issue that is commonly found in Internet Scale advertising platforms like Google, Adobe, and BlueKai", adding that Oracle is "exploring various mechanisms to prevent misuse of redirects"
  • 22 July 2021 - Response sent to Oracle saying that public disclosure will be delayed to give the Product Security Group more time to review and potentially fix the issue
  • August - December 2021 - No response from Oracle other than automated Monthly State Reports with no additional information
  • 21 December 2021 - Public disclosure on this blog to raise awareness

Some vendors often fail to consider patching these bugs and have taken years to fix them. However, they are often shared or sold around cybercriminal communities and leveraged for a wide array of campaigns. In November 2020, Cyjax analysts also uncovered multiple links related to the email marketing service, Adobe Campaign, being abused in phishing attacks. The attackers had spotted an open redirect bug and began exploiting a large wave of phishing attacks.


https://[redacted]-t.[redacted].net/r/?id=he5e7463,33113b4d,33113b55&p1=phishing-website.com


http://rt1-t.confirmation.[redacted]-mail.com/r/?id=hd6347f9%2C151fc709%2C151fc79b&p1=phishing-website.com#victim@example.com


In February 2021, the Microsoft Threat Intelligence Center (MSTIC) reported that it was tracking a phishing campaign using a domain generation algorithm (DGA), free email services, and compromised email accounts to launch a massive phishing campaign. These emails are linked by open redirect URLs that begin with a distinct pattern: 


https://t.[redacted].tld/r/?


MSTIC highlighted that the use of the open redirect is both an automated detection evasion technique and a way to trick human users into clicking the redirector URLs, which show a legitimate domain followed by the malicious link. [1]


Call To Action


Attackers often look for open redirect links inside marketing emails. There are several steps application developers should take when designing a system to prevent creating open redirects. The primary being that these systems should be applying backend checks to ensure the user is only able to be sent to a small number of predefined domains or URLs. All others - such as threat actor-created pages - should ideally be rejected via verification checks.


Open redirect links are a difficult component to combat and a part of the overall security challenge that phishing continues to present. We recommend organisations review mail flow rules - including certain IP ranges or domain-level allow lists, to ensure phishing emails are unable to slip through. Security researchers should continue to research these issues and highlight phishing campaigns they detect using these open redirect vulnerabilities to get these issues fixed sooner rather than later.


Further Reading:

Popular posts from this blog

Lessons from the Conti Leaks

Overview of Russian GRU and SVR Cyberespionage Campaigns 1H 2022

One Way Or Another: Initial Access Vectors