Security vulnerabilities?

merald

What is the process of reporting security vulnerabilies? Or get confirmed that they is fixed in release?

Are going to put in pfsense in a PCI DSS environment and made a nessus scan. Got this results:

4/1/2014 Nessus / Scans / Hosts / Vulnerabilities

HIGH lighttpd < 1.4.34 Multiple Vulnerabilities
HIGH lighttpd < 1.4.35 Multiple Vulnerabilities
MEDIUM NTP monlist Command Enabled
MEDIUM SSL Certificate Cannot Be Trusted
MEDIUM SSL Certificate with Wrong Hostname
MEDIUM SSL SelfSigned Certificate
MEDIUM Web Server Allows Password AutoCompletion
LOW SSL Certificate Chain Contains RSA Keys Less Than 2048 bits
LOW SSL RC4 Cipher Suites Supported
INFO Service Detection
INFO Nessus SYN scanner
INFO CGI Generic Injectable Parameter

peersu

The only ones that are actually an issue are the LIGHTTPD ones; everything else you can fix with having an actual SSL cert or manual server configurations. Not sure of the procedure to patch the web server vulns without breaking anything… caveat being I'm also pretty new to Pfsense in general.

jimp

2.1.1 is coming soon (days at most) and contains a newer lighttpd

merald

I am very impressed of your fast response to this. If we take it in production I will buy support from you guys.

SSL is of course fixed by using certs from our own CA. My main concern is 3things;

1.
HIGH lighttpd < 1.4.34 Multiple Vulnerabilities
HIGH lighttpd < 1.4.35 Multiple Vulnerabilities

MEDIUM Web Server Allows Password AutoCompletion (PCI-DSS variant)

Description
The remote web server contains at least HTML form field containing an input of type 'password' where 'autocomplete' is not set to 'off'.

While this does not represent a risk to this web server per se, it does mean that users who use the affected forms may have their credentials saved in their browsers, which could in turn lead to a loss of confidentiality if any of them use a shared host or their machine is compromised at some point.

Solution
Add the attribute 'autocomplete=off' to these fields to prevent browsers from caching credentials.

Output
Page : /
Destination Page: /index.php

Page : /index.php
Destination Page: /index.php
Port Hosts
443 / tcp / www
10.1

3. MEDIUMNTP monlist Command Enabled

Description

The version of ntpd on the remote host has the 'monlist' command enabled. This command returns a list of recent hosts that have connected to the service. As such, it can be used for network reconnaissance or, along with a spoofed source IP, a distributed denial of service attack.
Solution

If using NTP from the Network Time Protocol Project, either upgrade to NTP 4.2.7-p26 or later, or add 'disable monitor' to the 'ntp.conf' configuration file and restart the service. Otherwise, contact the vendor.

Otherwise, limit access to the affected service to trusted hosts.
See Also

https://isc.sans.edu/diary/NTP+reflection+attack/17300
http://bugs.ntp.org/show_bug.cgi?id=1532
http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10613
Output

If you can fix number 2 also it will be a fully PCI compliant device! More than your fellows Barracuda Networks can do ;) Number 3 counld be fixed by just disable the ntp service, but if you want… :)

jimp

@merald:

1.
HIGH lighttpd < 1.4.34 Multiple Vulnerabilities
HIGH lighttpd < 1.4.35 Multiple Vulnerabilities

Fixed in 2.1.1

@merald:

MEDIUM Web Server Allows Password AutoCompletion (PCI-DSS variant)

Fixed by going to System > Advanced and checking "Disable webConfigurator login autocomplete"

@merald:

3. MEDIUMNTP monlist Command Enabled

Fixed on 2.1.1

merald

Awesome! As fast as 2.1.1 is released it going in to production in a PCI DSS environment. Not many appliances you can remove initial user as "admin", do comply with requirement "No vendor accounts" and just use AD-accounts instead. Great work you all! Any last tips about running it on virtual server as VMware?

merald

Hi all

New scan of 2.1.1

Unfortunately some new one came up:

Not sure how to handle this, false positive?

CGI Generic Cross-Site Request Forgery Detection (potential)
Description

The spider found HTML forms on the remote web server. Some CGI scripts do not appear to be protected by random tokens, a common anti-cross-site request forgery (CSRF) protection. The web application might be vulnerable to CSRF attacks.

Note that :

Nessus did not exploit the flaw,
Nessus cannot identify sensitive actions – for example, on an online bank, consulting an account is less sensitive than transferring money.

You will have to audit the source of the CGI scripts and check if they are actually affected.
Solution

Restrict access to the vulnerable application. Contact the vendor for a patch or upgrade.
See Also

http://en.wikipedia.org/wiki/Cross-site_request_forgery
Output
The following CGIs are not protected by a random token :
/index.php

And then for the squid package that did not got any vulnerabilites before:

Squid 2.x / 3.x < 3.1.22 / 3.2.4 / 3.3.0.2 cachemgr.cgi DoS
Description

According to its banner, the version of Squid running on the remote host is 2.x or 3.x prior to 3.1.22 / 3.2.4 / 3.3.0.2. The included 'cachemgr.cgi' tool reportedly lacks input validation, which could be abused by any client able to access that tool to perform a denial of service attack on the service host. Note that Nessus did not actually test for this issue, but instead has relied on the version in the server's banner.
Solution

Either upgrade to Squid version 3.1.22 / 3.2.4 / 3.3.0.2 or later, or apply the vendor-supplied patch.

Alternatively, restrict access to this CGI or limit CGI memory consumption via the host web server's configuration options.
See Also

http://www.squid-cache.org/Advisories/SQUID-2012_1.txt
Output
Version source : Server: squid/2.7.STABLE9
Installed version : 2.7.STABLE9
Fixed version : 3.1.22 / 3.2.4 / 3.3.0.2

Squid 2.x / 3.x < 3.1.23 / 3.2.6 / 3.3.0.3 cachemgr.cgi DoS
Description

According to its banner, the version of Squid running on the remote host is 2.x or 3.x prior to 3.1.23 / 3.2.6 / 3.3.0.3. The included 'cachemgr.cgi' tool reportedly lacks input validation, which could be abused by any client able to access that tool to perform a denial of service attack on the service host.

Note this fix is a result of an incomplete fix for CVE-2012-5643.
Further note that Nessus did not actually test for this issue, but instead has relied on the version in the server's banner.
Solution

Either upgrade to Squid version 3.1.23 / 3.2.6 / 3.3.0.3 or later, or apply the vendor-supplied patch.

Alternatively, restrict access to this CGI or limit CGI memory consumption via the host web server's configuration options.
See Also

http://www.squid-cache.org/Advisories/SQUID-2012_1.txt
Output
Version source : Server: squid/2.7.STABLE9
Installed version : 2.7.STABLE9
Fixed version : 3.1.23 / 3.2.6 / 3.3.0.3

Squid 2.x / 3.x < 3.1.22 / 3.2.4 / 3.3.0.2 cachemgr.cgi DoS
Description

According to its banner, the version of Squid running on the remote host is 2.x or 3.x prior to 3.1.22 / 3.2.4 / 3.3.0.2. The included 'cachemgr.cgi' tool reportedly lacks input validation, which could be abused by any client able to access that tool to perform a denial of service attack on the service host. Note that Nessus did not actually test for this issue, but instead has relied on the version in the server's banner.
Solution

Either upgrade to Squid version 3.1.22 / 3.2.4 / 3.3.0.2 or later, or apply the vendor-supplied patch.

Alternatively, restrict access to this CGI or limit CGI memory consumption via the host web server's configuration options.
See Also

http://www.squid-cache.org/Advisories/SQUID-2012_1.txt
Output
Version source : Server: squid/2.7.STABLE9
Installed version : 2.7.STABLE9
Fixed version : 3.1.22 / 3.2.4 / 3.3.0.2

What you experts say?

merald

bump :o

merald

Bump again. I offer my Help to do Security scans of new releases, anyone intrested?