Vulnerability Assessment Scan of pFSense 2.4.4
-
Using OpenVAS I ran a UN-credentialed scan from the LAN interface on pFSense 2.4.4 with the following results. I have to find out why my SSH creds aren't working with OpenVAS.
LOW
It was detected that the host implements RFC1323.The following timestamps were retrieved with a delay of 1 seconds in-between:
Packet 1: 522776423
Packet 2: 3209761063Summary
The remote host implements TCP timestamps and therefore allows to compute the uptime.Vulnerability Detection Method
Special IP packets are forged and sent with a little delay in between to the target IP. The responses are searched for a timestamps. If found, the timestamps are reported.MEDIUM
Vulnerability Detection Result
Result: jQuery < 3.0.0 XSS Vulnerability
Installed version: 1.12.0
Fixed version: 3.0.0Summary
jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.Affected Software/OS
jQuery prior to version 3.0.0.MEDIUM
Vulnerability Detection Result
Server Temporary Key Size: 1024 bitsSummary
The SSL/TLS service uses Diffie-Hellman groups with insufficient strength (key size < 2048).Vulnerability Insight
The Diffie-Hellman group are some big numbers that are used as base for the DH computations. They can be, and often are, fixed. The security of the final secret depends on the size of these parameters. It was found that 512 and 768 bits to be weak, 1024 bits to be breakable by really powerful attackers like governments.MEDIUM
Vulnerability Detection Result
The following certificates are part of the certificate chain but using insecure signature algorithms:
Signature Algorithm: sha1WithRSAEncryptionSummary
The remote service is using a SSL/TLS certificate in the certificate chain that has been signed using a cryptographically weak hashing algorithm.Vulnerability Insight
The following hashing algorithms used for signing SSL/TLS certificates are considered cryptographically weak and not secure enough for ongoing use:-
Secure Hash Algorithm 1 (SHA-1)
-
Message Digest 5 (MD5)
-
Message Digest 4 (MD4)
-
Message Digest 2 (MD2)
Beginning as late as January 2017 and as early as June 2016, browser developers such as Microsoft and Google will begin warning users when visiting web sites that use SHA-1 signed Secure Socket Layer (SSL) certificates.
NOTE: The script preference allows to set one or more custom SHA-1 fingerprints of CA certificates which are trusted by this routine. The fingerprints needs to be passed comma-separated and case-insensitive:
Fingerprint1
or
fingerprint1,Fingerprint2Vulnerability Detection Method
Check which hashing algorithm was used to sign the remote SSL/TLS certificate.LOG
Vulnerability Detection Result
The target server did not return 404 on requests for non-existent pages.Vulnerability Detection Result
Here is the Nikto report:- Nikto v2.1.6
Server: nginx
- The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
- No CGI Directories found (use '-C all' to force check all possible dirs)
- Server leaks inodes via ETags, header found with file /favicon.ico, fields: 0xXXXXXXXX 0XXXXX
- Hostname '192.168.XX.XX' does not match certificate's names: pfSense-XXXXXXXXXX
- The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack.
- OSVDB-112004: /: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278).
- OSVDB-112004: /index.php: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278).
- OSVDB-3092: /xmlrpc.php: xmlrpc.php was found.
- /help.php: A help file was found.
- 7625 requests: 0 error(s) and 8 item(s) reported on remote host
- End Time: 2018-11-12 01:04:52 (GMT0) (160 seconds)
Vulnerability Detection Result
The remote web server is not enforcing HPKP.HTTP-Banner:
HTTP/1.1 200 OK
Server: nginx
Date: replaced
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
X-Frame-Options: SAMEORIGIN
Last-Modified: replaced
Set-Cookie: replaced
Expires: replaced
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff -
-
Hi,
Consider this : A LAN interface and the console access have a thing in common : a place where trusted devices live, like the device the admin is using to administer pfSense.
If you do no trust devices on LAN, then move them where the belong : on another OPTx interface.
Run your test again on one of these interfaces.. -
The Intel wifi card does not work in pFSense 2.4.4 so I have a wifi AP connected. It's quite easy to hack a wifi AP even with WPA2. It only takes one piece of software to be vulnerable for someone to break into a system and disable any firewall or IDS/IPS.
That's what I would do if I was attacking a pFSense router. Hack the wifi, gain inside/trusted access, hack the vulnerable software on the device, disable security features, open ports to give me access remotely whenever I wanted.
Are the OpenVPN self signed certs using SHA1 and 1024 bits? If so the entire VPN is vulnerable.
The US DOD moved to 2048 bits on SSL/TLS certs years ago.
-
Why don't you check vpn certs yourself? Its there. And the default is 2048 with sha256 too.
Now, having a wifi with access to internal pf interface isn't a good security practice anyway.
And depending on how much restrictfull you are, you can limit access to specific ip's too.
Yes, all this is considered mitigation
But then access to ANY firewall device administration must be restricted, since an unknown vulnerability can surface anytime anywhere. -
-
If you suspect a vulnerability in pfSense, a public forum is not a place to post about it. See https://www.pfsense.org/security/ and follow the correct procedure for responsible disclosure.
-
Most of that seems pretty mundane. The SSL/TLS warnings must be talking about OpenVPN or something else. The GUI uses 4096 DH parameters by default, and the default GUI cert uses SHA256.
-
The detection in that last thing is quite broken somehow. Shellshock? That was fixed years ago. That OSVDB-112004 entry is also for Apache, and pfSense uses nginx. Maybe you have that port forwarded into something else?
-