Are Modern Web Browsers a Blind Spot on the Threat Landscape? We talked to SquareX About It.

DEF CON 32 Las Vegas, NV.

To most people a Web Browser is just an application that show them the sites they visit either via a typed in URL or a link clicked from somewhere. What they often fail to realize is that behind that display is quite a bit of code execution and rendering to product the visuals which we consume. Threat Actors and other malicious individuals have known about this for years and take advantage of the automated code and script execution during the rendering phase of a website for different types of attacks. The cybersecurity industry is also very aware of this and has developed many (man) tools and techniques to limit potential attacks via the browser.

Sounds like a stalemate, right? Sadly, this is not the case. Most of the current mitigations have challenges in either implementation, adoption, or administration making them cumbersome to deploy and manage at scale. Even if we can remove those challenges, there is one big issue with that currently gets overlooked: they are all still running on the device. Even sandboxed and virtualized browsers still run locally allowing for attackers to work on and identify escapes from the controlled environment and while (X/M/E)DR is still available and should catch anything that trickles through, we know that this does not always happen (especially with more sophisticated attacks).

We talked to Vivek Ramachandran from SquareX about how browser usage and vulnerabilities in protection tools are changing how we view the threat landscape and how SquareX is looking to address this. If you are not familiar with SquareX they are a cybersecurity company with an interesting focus; the browser (but you might have guessed that from my lead in). Vivek also presented research into how Last Mile Reassembly attacks are getting around Secure Web Gateways while at Black Hat and Def Con

So how does SquareX do things differently, and at scale? As we mentioned most options for browser protection utilize some form of virtualization, sandboxing, etc. while still rendering and executing everything locally on the device. SquareX pulls this back off the local device and creates a disposable browser using a cloud-based container. The container executes the code and renders everything off-device and streams it to the user without any code touching the system. This is different from many other cloud-based solutions where some code execution and rendering are performed locally (and leaving room for escapes). The core idea of managed and virtualized browsers is still there along with policies (rules) behind what is and what is not allowed behavior, but where all of this happens changes allowing for more control and visibility.

SquareX utilizes an extension on the user device so a browser that supports extension is required. Through the use an extension the end user gets to (from their perspective) continue to use their browser of choice removing obstacles found in most managed browser pushes. The extension has visibility into all the activities of the user, something that most modern EDR are still not capable of. With this extended visibility, if there is a malicious event during code parsing, rendering, or even file activity you can view the entire attack path from start to the application of policy none of which happens locally on the device.

The extension can be deployed via Group Policy or other MDM making it simpler to deploy at scale and with a target market of organizations with more than 2,000 endpoints this is going to come in handy.

After the extension is deployed and enabled on the browser, it goes to work. When an end user opens their local browser the SquareX infrastructure goes to work. A new container which is pulled from a frozen image is spun up for the browsing session. These images are built, validated and stored in isolated environments to limit potential compromise of those environments. Each new container hosts the browser, and the processes needed to run it, no new processes can be spun up in that container which also limits an attacker’s ability to pivot inside the container. They only have already existing processes and cannot change non-executable items to executable in memory, adding to this there are no additional network connections allowed between containers just to make things more interesting for anyone looking to try a breakout. All of this happens seamlessly for the user, so they only get the site they wanted or clicked on.

Still, inside that isolated environment monitors are tracking everything, policies are being parsed to see if behaviors violate them and file scanners are running to look for potentially malicious files. If there is a policy violation the system checks to see what the response is, isolate or block. If it is block, then it the event or file is blocked while alarm bells go off for the team responsible to monitoring and checking events. The user gets a notification that the action or file is blocked due to a policy violation (and some context around it, like it is a malicious file). If the policy is isolate a new isolated file viewer is spun up allowing the user to view the file in the cloud and not on their local device (with all the precautions, we mentioned above). Any malicious pivots will not be able to gain a foothold on the local system (think trickbot), but the contents of the fie can be safely viewed.

Now, remember those alarm bells we talked about? Well, there is a lot going on in the background when there is a policy violation, or a malicious file is identified. The system is designed to check across the environment to ensure that the malicious pivot or file is not downloaded or executed anywhere else. It will also combine any like events (based on file hash, site URL etc.) into the attack path to show correlation and context of any attack path.

This is all done in the background by the algorithm and via AI Copilot in use in for threat hunting and attack path building. The AI is not there to make decisions, but to do the busy work of event correlation and contextualization for the people more efficiently understand the cope and/or scale of an event across their organization.

Policies can be built quickly and easily either based on observed behavior (new phishing techniques) or via a natural language policy builder. The latter employes an LLM to translate the statement into pre-existing policy definitions and components. The engineer can then go through and accept or augment the base policy to their liking. These policies can then be deployed across the organization, or to specific groups depending on what you are looking to do and giving you the flexibility to augment or relax protections depending on the user or group in question.

Overall SquareX looks to have a very solid product on their hands here and one that should be able to scale quite well in large environments. The attack graph for a web-based attack is very interesting and adds a piece of the puzzle that is often missing (like in a BEC IR). As with every other product in existence, it is not perfect and is not all encompassing. The infrastructure, being in the cloud, can still be directly attacked to compromise it like every other cloud environment out there. SquareX has put in place solid mitigations to prevent this and to limit impact across the entire platform if that were to happen. You also need to, obviously, be online to get the browser protections from the extension. This means that if you are opening a link or a file from your email while not connected and it pivots to the browser, you will need to rely on your other mitigations for detection and protection of course any web-based pivots are also not going to work although any locally run scripts might, (think opening PDF files in a browser). Neither of these negate the value which can be gained from having a system like this in place. Cybersecurity people often talk about identifying and deploying systems to protect users from themselves and SquareX seems to fall into that category quite well. It also follows an old tactical statement which says, engage the enemy as far from your perimeter as possible. If you are letting the attacker onto your endpoints before looking at things, you are already in knife-fighting range making it more complicated to bring the right weapons to bear without collateral damage.

I am impressed by what I have seen and heard from SquareX so far. It is an efficient and effective technical product designed to address a human symptom. This is not an easy task to take on, yet they appear to have done so. They are also not ruling out the possibility that they might have overlooked something by offering a $50,000 bug bounty for anyone who can identify a breakout (to the local system) in their product. Some might view that offer as boasting, but to me it shows both confidence in the product and a willingness to offer an incentive to researchers to get creative and to help make the product better. My only issue is that I wished it were easier to make it available to smaller businesses. With a target market of 2,000+ endpoints this leaves a large section of the threat landscape open. Now, don’t get me wrong. I 100% understand why it is not easy to offer this to smaller companies and it is not really on SquareX, it would be almost impossible to offset the cost of the infrastructure for a smaller business and even at the MS(S)P level it would not likely be something which would be efficient to sell to the SMB space. I just lament that this is how things are. After performing several BEC IRs in the SMB space and how often they started with a link click, the SquareX solution is something that would certainly move the cybersecurity needle in the right direction. If you are a larger organization, it can certainly do this for you as well and it worth taking a look at given changed in attacker tactics when it comes to initial access.

No comments

Leave your comment

In reply to Some User