Can Firejail contain the risk of a hijacked Firefox Browser in Debian 10?

[ghost]

Browser exploitation frameworks like BeEF are used as a first attack vector in order to gain control of the victim's web browser and then launching secondary attacks on the compromised system.

Is Firejail able to contain the risk of a hijacked Firefox browser in order to defend against further attacks of the system?

Which Firefox versions are currently supported and which options should be used under the mentioned scenario?

Thanks for your advice!

[reinerh]

Is Firejail able to contain the risk of a hijacked Firefox browser in order to defend against further attacks of the system?

Yes, the impact of a compromise is getting reduced.
For example paths that contain secrets (e.g. ~/.ssh/) are not accessible from inside the jail, so they can't be stolen.

Which Firefox versions are currently supported and which options should be used under the mentioned scenario?

The profiles should work best with the most recent versions. But older versions will probably also work.
You should not need any special options. If you want to customize something, add your changes to /etc/firejail/firefox.local (e.g. to blacklist additional paths).

[rusty-snake]

Debian 10 is used which ships with Mozilla Firefox 78.12.0esr.
It's unfortunately a bit of a pain to get the latest Firefox version running on Debian stable.

Is anything broken?

Is it possible to install extensions like uBlock and NoScript to mitigate a browser exploit further when using an AppImage with Firejail?

Of course.

Some exploits heavily rely on dbus and rtkit-daemon for further browser control.
Can this be limited in the configuration?

D-Bus: yes, it is by default
rtkit-daemon: IDK, where does it places it's socket?

[ghost]

I am starting Firefox with the following command:

firejail --seccomp --dns=1.1.1.1 firefox

I get directly the following warning:

Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protcol set

I tried to use the --net and protocol options as suggested, but that leaves Firefox without internet access.

As soon as my browser is under attack, I notice a couple of repeating warnings:

(firefox-esr:9): libnotify-WARNING **: 07:18:00: Failed to connect to proxy (firefox-esr:9): Gtk-CRITICAL **: 07:18:00 gtk_widget_get_window: assertion GTK_IS__WIDGET (widget) failed

###!!! Parent DispatchAsyncMessage Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, IPDL protocol error: Handler returned error code!

###!!! Parent RunMessage Error: Channel error: cannot send/recv

(firefox-esr:9) dconf-WARNING **: 11:14:15: failed to commit changes to dconf: Unkown or unsupported transport ?DBUS_SESSION_BUS_ADDRESS= unix? for address ?DBUS_SESSION_BUS_ADDRESS=uni

The malicious behavior I notice when the browser is hijacked includes the following:

• Browser tabs are opened in new windows.
• Search bar results in the top are proxied and search results appear in Russian or standard websites redirect to completely different URLs.
• Form content is marked

Is it possible to document, log and audit an attack with additional options in Firejail or with additional tools?

Which additional counter measures would you suggest?

[SkewedZeppelin]

search results appear in Russian

This is very common with DuckDuckGo as it sources from both Bing and Yandex. It is not a sign of attack.

As soon as my browser is under attack

If you genuinely believe you are being attacked and are asking for help here you need to provide more actionable information.

firejail --seccomp --dns=1.1.1.1 firefox

• using firecfg to ensure programs are sandboxed by default is preferred to manually prefixing programs with firejail
• seccomp is already set in the firefox profile
• you are better off setting up the encrypted dns built-into firefox under Settings > Network Settings > Enable DNS over HTTPS

Some exploits heavily rely on dbus and rtkit-daemon for further browser control.

What exploits are you referring to?

[SkewedZeppelin]

@HeimdallAse

Please clarify if you are testing the browser yourself or if you are being attacked by a third party.

[ghost]

I use the "Enable DNS over HTTPS" feature of Firefox (No Proxy) on a VM (fresh snapshot every day) and today used the simple command:

firejail firefox

This is not a lab situation. I am attacked by a third party. The circumstances are bit difficult to explain. Our IT department was outsourced offshore and since then things started to become funky with no local support available and a series of incidents.

After connecting to the VM and accessing the systems of my organization via the browser, the traffic statistics of my VPS provider show an incoming traffic spike of roughly 600MB shortly before my browser gets hijacked. After that the statistic goes completely blank and cannot be tracked any longer. The attacker has complete control over the browser, can open taps, create links, manipulate text field content etc. Attempts to crash the browser are not successful (system keeps lagging for up to 30 seconds), but the attacker is able to target the network connection and thereby terminates my SSH session. Checking the syslog shows many rtkit-daemon entries during the mentioned events.

Any advice would be greatly appreciated how to document and analyze the attacks.

[topimiettinen]

I didn't install BeEF, but quickly checking the sources, it seems that it can perform operations at browser level (by simply using the poorly designed APIs) and it can use other browser weaknesses or weak configuration (for example Flash, ActiveX, Java enabled) to execute other programs. Then stuff like Metasploit can be used to escalate privileges.

For the insecure APIs there's maybe nothing that Firejail can do. The browser will happily tell the attacker its type, version, operating system and processor architecture. It's possible to fingerprint the browser and the user with lots of techniques (some mentioned in https://coveryourtracks.eff.org/). Flash is obsolete and ActiveX isn't available for Linux. Browser settings can be tightened, for example enabling Java (not JS) is a bad idea.

Firejail can prevent the browser from executing other programs in the system (with some loss of functionality and user friendliness) with --private-bin, --private-lib, noexec and other features. This may not block fileless malware using ROP/JOP gadgets. The default profiles should be a good starting point for further hardening efforts. Also FDNS could be used to allow-list DNS access to only safe sites or at least block bad sites (though the attackers could just use IP addresses, which might be countered with country-blocking firewalls, which could be countered with VPNs, etc.). Mandatory Access Control (AppArmor and especially SELinux) can also help.

But if the attackers utilize unknown 0day vulnerabilities for Firefox, they may also have 0days for the kernel (or Firejail) and it may never be possible to say that anything could be contained completely. Layered defences can help since the vulnerabilities may need specific conditions for them to work, but then there are hardware level vulnerabilities like Spectre, TLBleed, TagBleed and Rowhammer which typically bypass all layers.

It's also possible that the attackers are not even targeting maximum system privileges, their objective may be achieved with just tricks with browser API level.