BREACH attack vulnerability on SSL/TLS connections. This vulnerability is present in the HTTP compression of the web configurator.

zendzipr

The vulnerability was detected due to the enabled HTTP compression being enabled

I confirmed with ```
curl -I -H 'Accept-Encoding: gzip,deflate' HOSTNAME

HTTP/2 200
server: nginx
date: Wed, 17 Jan 2024 17:49:37 GMT
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN
last-modified: Wed, 17 Jan 2024 17:49:37 GMT
set-cookie: PHPSESSID=de7936802006df43579a79b60711c866; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
content-encoding: gzip


After reviewing, I determined the configuration appears to be hardcoded at /etc/inc/system.inc line 1915.

Is this something that can be modified locally or do we have to wait for a patch?

JonathanLee

@zendzipr set the GUI processes to 1 not 4 see if that helps. It should show one GUI connection not 5 when you log on.

“Enter the number of webConfigurator processes to run. This defaults to 2. Increasing this will allow more users/browsers to access the GUI concurrently.”

I set mine to one never looked back. I was originally set to 4 I noticed it would use all 4 for one login. Changed it to one now only one state listed per login

Gertjan

@zendzipr said in BREACH attack vulnerability on SSL/TLS connections. This vulnerability is present in the HTTP compression of the web configurator.:

to be hardcoded at /etc/inc/system.inc line 1915.

Is this something that can be modified locally or do we have to wait for a patch?

Well, the hard in coded is gone, as you've found "/etc/inc/system.inc line 1915" ^^

If you know all about nginx config file settings - and what pfSense needs so it works, be free to change whatever you want.
edit : and report back your findings

Btw : the GUI web server isn't a public web server.
Typically, it's only accessible on one of the pfSense LAN - not WAN - type interfaces - the one you've labeled "LAN for admin access only". So, if the GUI web server get breached, the guy was already connected to (with a cable !!) to pfSense so he also has access physically to the box.
No need to think about web server access settings in that case ^^

mer

@Gertjan said in BREACH attack vulnerability on SSL/TLS connections. This vulnerability is present in the HTTP compression of the web configurator.:

Btw : the GUI web server isn't a public web server

Or at least it shouldn't be :)

zendzipr

This vulnerability can be exploited, regardless of whether it is internal or external.

An internal vulnerability is just as dangerous as an external one, especially in a compliance-based environment like PCI.

johnpoz

@zendzipr said in BREACH attack vulnerability on SSL/TLS connections. This vulnerability is present in the HTTP compression of the web configurator.:

especially in a compliance-based environment like PCI.

If your pci network can talk to pfsense web gui, your doing pci wrong in the first place..

jimp

There is a lot more to it than "the web server supports compression, therefore it's vulnerable."

The GUI web server employs CSRF protection which is one of the methods for mitigating such attacks.

Can you successfully demonstrate an attack that succeeds against the GUI web server?

johnpoz

Oh Snap - someone should let google know ;)

zendzipr

Thank you for your valuable insights. It's evident that the BREACH attack vulnerability, while a technical security concern, primarily represents a compliance issue for me. In environments where regulatory compliance and standard adherence are critical, addressing this vulnerability is about enhancing security and fulfilling necessary compliance requirements.

While the immediate security risks might vary, the need to address this vulnerability for compliance purposes is clear. As such, my focus is on effectively mitigating this issue to ensure that our systems are secure and meet the required compliance standards.

jimp

Compliance isn't an issue here.

For it to be a problem it has to be proven to actually be a problem, which hasn't happened.

Whatever scan is flagging it is giving bogus results, it's a false positive.

If you want to alter the source to shut the scanner up, that's up to you.