Safari Vulnerability Enables Attackers to Steal Credentials with Fullscreen BitM Attacks

According to MITRE, Browser-in-the-Middle (BitM) is an attack where “an adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system.” This attack has been used by many attackers to trick victims into unknowingly entering credentials and providing sensitive information on an attacker controlled window. The attack was first disclosed in a paper by researchers from the University of Salento in 2021, and we have seen many cases of BitM being used in the wild since then.

However, one key flaw of the BitM attack is that it still requires the victim to land on a malicious site and perform an action to open up the noVNC pop-up window. As the parent window still has a malicious URL in its address bar, this will likely raise suspicion among more security aware users at the point of credential entry. 

SquareX’s research team has observed multiple instances of the browser’s FullScreen API being exploited to address this flaw by displaying a fullscreen BitM window that covers the parent window’s address bar, as well as a limitation specific to Safari browsers that makes fullscreen BitM attacks especially convincing. The article below will recap how BitM attacks work, explore the Fullscreen API requirements and why Safari browsers are particularly vulnerable to fullscreen BitM attacks.

Traditional Browser-in-the-Middle (BitM) Attacks

To illustrate how a typical BitM attack works, we will use a real attack that targeted Counter-Strike 2 gamers. Incentivized by cryptocurrency and skin giveaways, victims were tricked into entering their Steam credentials. These compromised accounts were then sold on the black market for up to $300,000. Here is how it works:

Note: The case study below actually used the Browser-in-the-Browser (BitB) technique, where instead of using remote desktop, the attackers uses HTML, CSS and JavaScript most commonly to mimic login pop-ups of popular SaaS or Single Sign-On (SSO) services. We chose this example as it is a well documented attack and because the social engineering and principles behind this attack can also be used in BitM attacks. 

1. Attackers create fake promotional videos on YouTube about the CS2 giveaway, with a link and/or QR code to claim the gift. 

Image Source: Silent Push 

There were also several instances where attackers distributed these phishing links by commenting on videos of popular live streamers or gaming Discord channels.

Image Source: No Text to Speech

2. Victims click on the link or scan the QR code, landing them on a fake Steam website containing a Get the Card button.

 Image Source: No Text to Speech

3. The user clicks on the button, triggering what seems to be a legitimate Steam login page. In reality, the attacker likely used HTML, CSS and JavaScript to create a perfect replica of Steam’s login site, including the URL.

Note: In a BitM attack, the pop-up will instead be an attacker-controlled remote browser (e.g. a noVNC client) that displays the legitimate Steam site. BitM attacks are much more powerful than BitB attacks because it allows the victim to access their account after entering their credentials, leaving them unaware that they have been phished. Without realizing they are now operating on a remote browser, the victim can also open up other tabs where they may log in to other enterprise apps and access confidential information - all under the attacker’s purview.

Image Source: No Text to Speech

4. Once the victim enters their account name and password, these credentials are collected by the adversaries and sold for profit.

Stolen Steam credentials sold on playerauctions[.]com/steam-account/ 

(Image Source: Silent Push)

As highlighted in the introduction there is still one key flaw to BitM/BitB attacks. The URL displayed on the parent window still clearly indicates an illegitimate site. Thus, this attack is unlikely to work for more security aware targets who know to check for suspicious URLs before entering their credentials. The Fullscreen BitM absolves this problem.

Malicious URL on parent window (Image Source: No Text to Speech)

Fullscreen API 

To understand why the Fullscreen BitM attack is possible, it is important to first have a good grasp of how the Fullscreen API works in browsers. By definition, the Fullscreen API allows methods to “present a specific Element (and its descendants) in fullscreen mode, and to exit fullscreen mode once it is no longer needed”.

To present an element in fullscreen mode, its requestFullscreen() needs to be called. For example, the video element elephant-video can be displayed in fullscreen with the following code:

const elem = document.getElementById("elephant-video");
if (elem.requestFullscreen) {
  elem.requestFullscreen();
}

The fullscreen mode can then be exited by calling the exitFullscreen() method or hitting the F11 or Esc keys. The former exits the top most fullscreen, while the latter exits all fullscreens.

For the requestFullscreen() method to be called, browsers require a transient user activation. In other words, the user has to interact with the site or a web element on the site to activate fullscreen mode. Critically, this can be any user interaction - none of the major browsers have guardrails on the type of user interaction or web element that needs to be involved. This means that attackers can easily disguise a fullscreen button by labelling it as a sign in button or other elements that are part of the site or web application’s regular workflow.

Why is Safari particularly vulnerable to fullscreen BiTM attacks?

While the attack works on all browsers, fullscreen BiTM attacks are particularly convincing on Safari browsers due to the lack of clear visual cues when going fullscreen. In Firefox and Chromium-based browsers such as Chrome and Edge, there is a messaging requirement whenever fullscreen is activated. Here is an example for Chrome when expanding a YouTube video:

Out of the three browsers, Firefox has the clearest messaging, including details on the domain that is going fullscreen. However, this notification is subtle and transient in nature -  the alert disappeared after approximately 4 seconds. Most individuals may not be security aware enough to be suspicious of fullscreens even if they see the notification. Additionally, attackers can leverage “dark modes” or color schemes similar to the warning’s color to make the pop-up less visible. 

Chrome fullscreen messaging notification in normal (top) and dark (bottom) mode

Firefox fullscreen messaging notification in normal (top) and dark (bottom) mode

When it comes to the Safari browser, there is no messaging requirement when the requestFullscreen() method is called. The only sign that Safari provides when entering fullscreen mode is a “swipe” animation, which is barely noticeable and more importantly, not a signal that most users associate with going fullscreen. As a result, there is practically zero visual indicator when fullscreen mode is activated in Safari browsers, a critical flaw that allows Fullscreen BitM attacks to be especially evasive in Safari browsers. 

Fullscreen Browser-in-the-Middle

Now that we know how both BitM and the Fullscreen API work, we illustrate how the two can be combined to create the extremely convincing Fullscreen BitM attack. 

Fullscreen Browser-in-the-Middle Attack Demo (Safari)

Note: All applications used in this blog are for illustrative purposes, they are not more or less vulnerable to Fullscreen BitM attacks than other SaaS apps.

1. Similar to a regular BitM attack, the victim lands on a phishing site that impersonates a popular SaaS app through various social engineering tactics. In this case, through a fake Google ad, the victim lands on a malicious site impersonating the popular web design app Figma.

These sites can be hosted on commonly whitelisted domains like AWS and Vercel to evade detection by SASE/SSE solutions. 

Attacker targets victim via a malvertising campaign

Victim lands on a malicious site impersonating Figma

2. Thinking that they are on the legitimate site, the victim clicks on the fake Log in button, which qualifies as a transient user activation that calls the requestFullscreen() method of the BitM window. Before the click, this window was minimized and invisible to the victim. 

Clicking on fake Login button calls the requestFullscreen() method, opening up a fullscreen BitM window displaying the attacker’s remote browser

3. Calling the requestFullscreen() method opens up a BitM window with an attacker-controlled remote browser showing the real Figma login page in fullscreen. Unlike traditional BitM pop-ups, the fullscreen BitM window completely covers the parent window, leaving no suspicious URLs on screen when the victim enters their credentials.

In Chrome and Firefox, a pop-up message will be shown to the user to indicate that they are entering full-screen mode. However, as shown earlier, the messaging is transient and subtle, and can be further obfuscated using similar color schemes. In Safari browsers, there is no messaging at all, providing no clear visual cue to the user that they are now interacting with a fullscreen pop-up.

Victim enters their credential into the legitimate Figma site on the attacker’s remote browser

4. The victim successfully signs into Figma, without any indication that their credentials have been stolen. They will also be able to open up additional tabs in the remote browser to access other applications, enter their credentials and conduct their work - all in an attacker monitored browser. 

Victim successfully logs onto Figma and conducts their work, unaware that they have been phished

Victim unknowingly opens new tabs and logs into other enterprise SaaS apps in the attacker-controlled browser

The Fullscreen BitM attack highlights a key flaw in browser APIs - specifically the lack of security controls on how the Fullscreen API can be used. It also demonstrates a critical evolution in web attacks. Attackers are no longer relying on rudimentary phishing techniques or targeting browser bugs that are easily patchable by browser vendors. Instead, they are exploiting legitimate functionalities within the browser, such as these APIs, for malicious activities. We have disclosed this vulnerability to Safari, however we received a wontfix response claiming that the FullScreen API methods and “swipe” animations are working as intended and as such there will be no patch on this security flaw. This is also reflected in the wontfix responses that we received in all the responsible disclosures that we have made as part of the Year of Browser Bugs project.

Safari response to SquareX’s vulnerability disclosure

Attack demo for Fullscreen BitM for Google Chrome

Attack demo for Fullscreen BitM for Mozilla Firefox

Attack demo for Fullscreen BitM for Microsoft Edge

Protecting Against Fullscreen BitMs

It is well established that EDRs have no visibility in the browser and thus are unable to detect even traditional BitMs. Similarly, as briefly mentioned above, it is possible to bypass SASE/SSE by hosting the parent site on trusted domains such as AWS and Vercel that are commonly whitelisted by enterprises. As SWGs rely on network traffic to infer application layer attacks, using the remote browser technique will also mean that there is no malicious traffic that could trigger a detection. Unfortunately, none of the enterprise security tools above have direct access to rich browser metrics such as DOM changes, user interaction and site permissions that are necessary to Fullscreen BitM attacks. 

As we see more sophisticated attacks that exploit architectural flaws in the browser, it is critical to have a browser-native solution that has full visibility into the browser to differentiate between legitimate and malicious activities. SquareX’s Browser Detection and Response (BDR) enterprise solution can protect against Fullscreen BitM attack and other client-side web attacks. As a browser extension, SquareX is a first-class browser citizen with privileges to access critical browser metrics to detect and mitigate advanced attacks on employees in the browser and is compatible across all major popular browsers. 

SquareX Browser Detection and Response

SquareX’s industry-first Browser Detection and Response (BDR) solution detects, mitigates and threat-hunt client-side web attacks targeting employees in real time. There are three key components to the BDR:

• Web Threat Detection & Mitigation including identity attacks, malicious extensions advanced spearphishing attacks and malicious files
• Browser DLP including genAI DLP, clipboard DLP, file DLP and insider attacks
• Private App Access to provide secure access to web applications and private apps via the browser, including for BYOD/unmanaged devices

The solution comes in the form of a lightweight browser extension that is compatible with all major popular browsers including Chrome, Edge, Safari and Firefox and can be easily deployed across both managed and unmanaged devices.

How does SquareX’s Browser Detection and Response work?

Monitor

As a browser native solution, SquareX has access to rich browser metrics including DOM mutation, website permissions, network requests and browser APIs. SquareX also tracks all file upload/download, clipboard content and browser extension activities to identify malicious activity and prevent data loss. 

Detect

With the browser telemetry above, SquareX can detect any malicious activity happening in the browser across the five most common attack vectors - identity attacks, malicious extensions, malicious files, malicious sites and clipboard, including client-side application layer attacks that go undetected by EDRs and SASE/SSEs, without requiring any intercepting proxies.

Mitigate

In addition to blocking attacks, SquareX provides additional mitigation actions whenever malicious activity is detected, enabling employees to continue working in a safe environment. This includes an industry-first file isolation capability, browser isolation and content disarm and reconstruction (CDR), where malicious macros are removed from compromised files.

Threat Hunt

SquareX allows security teams to have a detailed view of the enterprise’s browser attack surface, including the ability to correlate attacks across the organization, threat actor attribution and full visibility into the attack sequence, including our proprietary attack vision and acquire artifact features, which allows security teams to simulate the exact user view leading up to the attack and acquire malicious file/clipboard data samples respectively.