pfSense weak DH vuln found with Kali

pooperman

just to get it right, DNSBL shall just redirect unwanted "data".
In order to keep integrity, it is using a cert and this cert is having insuffizient DH strength?

If so, according to my understanding there is actually no problem. In case someone breaks encryption it will just get all the rubbish that I do not want, correct?

johnpoz

@pooperman said in pfSense weak DH vuln found with Kali:

DNSBL

ask @BBcan177 maybe he can shed some light on what his package is doing... If its serving up something on https, then it should be using current best practices to do so..

pooperman

@johnpoz said in pfSense weak DH vuln found with Kali:

@pooperman said in pfSense weak DH vuln found with Kali:

DNSBL

ask @BBcan177 maybe he can shed some light on what his package is doing... If its serving up something on https, then it should be using current best practices to do so..

thanks for support!

will an @ and the name triggers something at the users interface in this forum ie. get an altert?
Or shall i contact him directly?

may I ask how and where you tested the DH key size (6th post)?

johnpoz

The @ should send him notification of this post.

The script I use to test ssl stuff is here
https://github.com/drwetter/testssl.sh

NogBadTheBad

He not been online for 11 days, I've made a post on reddit linking here.

BBcan177

@NogBadTheBad

The function that generates the cert is here:
https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/pkg/pfblockerng/pfblockerng.inc#L1024-L1049

I don't think its necessary for what the DNSBL server is serving, but you can change the settings in the code, delete the cert and then Force Update for the cert to be re-created with the new settings. If you test it successfully, let me know and I will change the code in the next release.

/var/unbound/dnsbl_cert.pem

johnpoz

Lets be clear is not the cert that the problem
https://docs.netgate.com/pfsense/en/latest/certificates/dh-parameters.html

What is pfblocker using that would be different than what the web gui is using?

We are not sure what they are actually hitting when they are testing.. All I can tell you is not the pfsense web gui.

So DNSBL listens on port what for SSL, you set this? 8443? How exactly does it serve this up where would it get its DH-parameters from? See the link above.

[2.4.4-RELEASE][admin@sg4860.local.lan]/etc: ls -la dh*
-rw-r--r--  1 root  wheel   245 Nov 17  2017 dh-parameters.1024
-rw-r--r--  1 root  wheel   424 Nov 17  2017 dh-parameters.2048
-rw-r--r--  1 root  wheel   595 Oct  4 08:37 dh-parameters.3072
-rw-r--r--  1 root  wheel   769 Nov 17  2017 dh-parameters.4096
-rw-r--r--  1 root  wheel  1115 Oct  4 08:37 dh-parameters.6144
-rw-r--r--  1 root  wheel  1464 Oct  4 08:37 dh-parameters.8192

BBcan177

@johnpoz

It uses lighttpd not nginx that is used by the pfSense gui:
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL

Would have to add the DH params to the dnsbl lighttpd conf file:
var/unbound/pfb_dnsbl_lighty.conf

That file is auto created so changes will be overwritten. Don't have time to look at it atm.

johnpoz

Yeah my guess but can not seem to find it in the conf is this
ssl.dh-file="{path to dhparams.pem}"

So not sure what its using if not called out?

To be honest this isn't really that big of deal - other than people doing such scans and thinking the problem is pfsense ;) hehehe

I set up pfSense and I was checking for general vulnerabilities.

No where did he mention installed "optional" packages xyz, and abc, etc..

stephenw10

Well to be fair he did discover something that should probably be updated, if only to prevent false positives as you say.

Steve

BBcan177

Edit the file (for pfBlockerNG-devel):

/usr/local/pkg/pfblockerng/pfblockerng.inc

And add the 6 "+" lines as depicted in this screenshot:

        $SERVER["socket"] == "127.0.0.1:8443" {
                ssl.engine      = "enable"
                ssl.pemfile     = "/var/unbound/dnsbl_cert.pem"
                ssl.dh-file       = "/etc/dh-parameters.4096"
                ssl.cipher-list  = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH"
                ssl.ec-curve    = "secp384r1"
        }

        $SERVER["socket"] == "10.10.10.2:443" {
                ssl.engine      = "enable"
                ssl.pemfile     = "/var/unbound/dnsbl_cert.pem"
                ssl.dh-file       = "/etc/dh-parameters.4096"
                ssl.cipher-list  = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH"
                ssl.ec-curve    = "secp384r1"
        }

Stop the pfb_dnsbl Service
Then remove the existing lighttpd config file.

rm /var/unbound/pfb_dnsbl_lighty.conf

Then Force Update for it to be re-created with the new changes.
Please post back after running your vulnerability scans.
Thanks!

johnpoz

As always @BBcan177 your johnny on the spot!

And also took the time to update the cipher list and curve.. Nice!

@stephenw10 agree its a good find, even if found in a round about way.

NogBadTheBad

@BBcan177 said in pfSense weak DH vuln found with Kali:

rm /var/unbound/pfb_dnsbl_lighty.conf

mac-pro:~ andy$ nmap --script ssl-dh-params.nse 172.16.0.1

Starting Nmap 7.40 ( https://nmap.org ) at 2019-03-26 09:27 GMT
Nmap scan report for pfsense (172.16.0.1)
Host is up (0.0018s latency).
Not shown: 995 filtered ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
443/tcp open https
8081/tcp open blackice-icecap
8443/tcp open https-alt

Nmap done: 1 IP address (1 host up) scanned in 6.40 seconds
mac-pro:~ andy$

Yea that fixed it :)

BBcan177

@NogBadTheBad said in pfSense weak DH vuln found with Kali:

Yea that fixed it :)

Thanks for testing... Will add it to the next release...

pooperman

many thanks for checking /helping and fixing it, to all.
Really appreciated!