pfSense weak DH vuln found with Kali
-
Not sure what your running... I don't recall tweaking any of my httpd settings on pfsense... I can fire one up out of the box on vm and scan again with ssltest..
But have no idea where your seeing dh that low
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 4096 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 x6b DHE-RSA-AES256-SHA256 DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHA DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 x9e DHE-RSA-AES128-GCM-SHA256 DH 4096 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256Just ran ssltest against pfsense and only see the cipers that do dh all at 4096
Only thing that comes back with possible vuln is
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches -
mac-pro:~ andy$ nmap --script ssl-dh-params.nse 172.16.0.1 Starting Nmap 7.40 ( https://nmap.org ) at 2019-03-25 18:49 GMT Nmap scan report for pfsense (172.16.0.1) Host is up (0.0019s 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 | ssl-dh-params: | VULNERABLE: | Diffie-Hellman Key Exchange Insufficient Group Strength | State: VULNERABLE | Transport Layer Security (TLS) services that use Diffie-Hellman groups | of insufficient strength, especially those using one of a few commonly | shared groups, may be susceptible to passive eavesdropping attacks. | Check results: | WEAK DH GROUP 1 | Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA | Modulus Type: Non-safe prime | Modulus Source: RFC5114/1024-bit DSA group with 160-bit prime order subgroup | Modulus Length: 1024 | Generator Length: 1024 | Public Key Length: 1024 | References: |_ https://weakdh.org Nmap done: 1 IP address (1 host up) scanned in 5.73 seconds mac-pro:~ andy$Just looked at my certs in keychain, they're all 2048
-
I will fire up a clean vm...
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 Elliptic curves offered: sect283k1 sect283r1 sect409k1 sect409r1 sect571k1 sect571r1 secp256k1 prime256v1 secp384r1 secp521r1 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 DH group offered: Unknown DH group (4096 bits)What are you running on pfsense that listens on 8081?
-
-
Key size is not the same has DH size... Sorry but out of the box the DH is 4096..
I just fired up a 2.4.4p1 clean VM... nothing more than clicking ok in the wizard and this is what the out of the box gui offers
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 4096 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 x6b DHE-RSA-AES256-SHA256 DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHA DH 4096 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 x9e DHE-RSA-AES128-GCM-SHA256 DH 4096 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Running client simulations (HTTP) via sockets Android 4.2.2 No connection Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256) Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256) Android 7.0 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Chrome 65 Win 7 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Chrome 70 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Firefox 59 Win 7 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Firefox 62 Win 7 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) IE 6 XP No connection IE 7 Vista No connection IE 8 Win 7 No connection IE 8 XP No connection IE 11 Win 7 TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit DH (ffdhe4096) IE 11 Win 8.1 TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit DH (ffdhe4096) IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256) IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Edge 13 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Edge 13 Win Phone 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Opera 17 Win 7 TLSv1.2 ECDHE-RSA-AES256-SHA, 256 bit ECDH (P-256) Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Tor 17.0.9 Win 7 No connection Java 6u45 No connection Java 7u25 No connection Java 8u161 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Java 9.0.4 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) OpenSSL 1.0.1l TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)So not sure what he is testing, but it sure isn't pfsense gui..
-
DNSBL is also running on my pfsense
maybe kali checked the DNSBL cert?
@johnpoz thanks for rechecking! -
@pooperman is running pfblocker as well.
https://forum.netgate.com/topic/141220/pfblockerng-very-slow-at-dns
-
@pooperman said in pfSense weak DH vuln found with Kali:
DNSBL is also running on my pfsense
maybe kali checked the DNSBL cert?
@johnpoz thanks for rechecking!Yup stop DNSBL and you'll get a pass.
-
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?
-
@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..
-
@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)?
-
The @ should send him notification of this post.
The script I use to test ssl stuff is here
https://github.com/drwetter/testssl.sh -
He not been online for 11 days, I've made a post on reddit linking here.
-
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-L1049I 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 -
Lets be clear is not the cert that the problem
https://docs.netgate.com/pfsense/en/latest/certificates/dh-parameters.htmlWhat 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 -
It uses lighttpd not nginx that is used by the pfSense gui:
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSLWould have to add the DH params to the dnsbl lighttpd conf file:
var/unbound/pfb_dnsbl_lighty.confThat file is auto created so changes will be overwritten. Don't have time to look at it atm.
-
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..
-
Well to be fair he did discover something that should probably be updated, if only to prevent false positives as you say.
Steve
-
Edit the file (for pfBlockerNG-devel):
/usr/local/pkg/pfblockerng/pfblockerng.incAnd 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.confThen Force Update for it to be re-created with the new changes.
Please post back after running your vulnerability scans.
Thanks! -
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.
