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.

    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: 3209761063

    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.


    Vulnerability Detection Result
    Result: jQuery < 3.0.0 XSS Vulnerability
    Installed version: 1.12.0
    Fixed version: 3.0.0

    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.


    Vulnerability Detection Result
    Server Temporary Key Size: 1024 bits

    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.


    Vulnerability Detection Result
    The following certificates are part of the certificate chain but using insecure signature algorithms:
    Signature Algorithm: sha1WithRSAEncryption

    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:


    Vulnerability Detection Method
    Check which hashing algorithm was used to sign the remote SSL/TLS certificate.


    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 (
    • OSVDB-112004: /index.php: Site appears vulnerable to the 'shellshock' vulnerability (
    • 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/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.

  • Rebel Alliance Developer Netgate

    1. If you suspect a vulnerability in pfSense, a public forum is not a place to post about it. See and follow the correct procedure for responsible disclosure.

    2. 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.

    3. 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?

Log in to reply