Hello and welcome to all readers.

In this post we will show some common vulnerabilities that can be found in custom built browsers, which are mainly used by banking. What these browsers offer users is browsing security, just for the fact that they are exclusive browsers.

Some of its advantages would be the following:
• Single installation
• Automatic update
• Controlled access to accounts
• Improve the browsing experience

Features allowed by the browser:
• Home button to the company site
• Website reload button
• Add favorite button

Now for a greater context of why we wanted to analyze this type of browser, basically to validate and verify the possible risks that are opposed to the security offered by the browser.

The first vulnerability found is DLL hijacking. This tricks the legitimate and trusted application into loading an arbitrary DLL. The binaries responsible for calling the DLL and its functions are scpbradguard.exe and scpbradserv.exe which runs as a Windows service.

This type of kidnapping would allow three objectives to be achieved:
• Execute malicious code
• Get Persistence
• Privilege escalation

Let’s get down to business again!

First of all we identify the services that run after installing the browser. For this we use Process Monitor with some filters, so we avoid loading unnecessary information.

With the filter activated we can identify that there are two missing DLLs VERSION.dll and WINHTTP.dll, but we will focus on the second one.

The next step is the identification of its functions, this information is necessary for the creation of the malicious DLL.

In this case use CFF Explorer, but you could perfectly use IDA or Ghidra but personally if in-depth reverse engineering is not necessary, I think the first tool would be enough.

With the information obtained, the DLL is programmed in C++ and compiled with Visual Studio 2019, then the DLL is copied to the root directory of the binaries or simply copy the binary to any Windows directory with the DLL.

Proof of Concept DLL Hijacking:
https://www.youtube.com/watch?v=OGQcbUuXmpo

Within the analysis carried out on the browser, the first thing that was verified was whether it correctly complied with its security policies on browsing and blocking third-party sites.

In the first instance it was verified that the navigation bar is disabled, avoiding changing the domain already defined by the browser. For this type of restriction, two evasions were performed. The first is by HTML and the second by means of executable parameters, which will be explained below.

Open Redirect via HTML File

In order not to lengthen and bore with the post, we are going to get to the point!

Within the tests, it was concluded that by creating an HTML type file it is possible to execute the domain redirection. Now the only problem that was found was that the domain had to be whitelisted for the redirect to be executed, this means that the domain had to contain the name of the company.

For this, a simple evasion was used, which consists of adding the domain name, followed by the HTTPS protocol. With this we overcome the white list and the interpretation of the redirection would take the domain after the “@” character since the rest would be the username:password@domain format.

Now to execute the file it is enough to load the HTML in the browser using DragDrop, but this would not be realistic. So, to avoid this mishap, the same browser, when installed, allows you to keep it as default, which would facilitate its execution.

Next, we can see how the file is loaded correctly by the browser, allowing the redirect to a domain that is not on the white list.

Open Redirect via Parameters

There is another way that is less realistic but that still allows to evade the restriction, through parameters allowed by the browser.

We can find the -url and -new-window parameters that allow opening an arbitrary domain, but it is still necessary to keep the url format to avoid the whitelist.

For more information on the CommandLineOptions used:
https://wiki.mozilla.org/Firefox/CommandLineOptions

To take this to a real exploitation, an intermediary binary (Malware) would be necessary to activate the command every time the browser is called.

Attack flow via Phishing

The following flow represents how a possible attack would be using the Open Redirect vulnerability that maintains the custom browser towards users who use said browser.

For this the attacker sends the file by some means to the user. The most common would be via email, then the user downloads and runs the file, being redirected to a malicious site.

Open Redirect Proof of Concept:
https://www.youtube.com/watch?v=QWx46GboBFE