PfSense 2.3.4-Release fails PCI Compliance Scan
-
I have a client that requires PCI compliance scans, and the company the Bank makes them use is called Control Scan.
It pops on port 9443 which is where I set the Webconfig, normally it's locked down to only my company's IP range, but they request access to all opened ports.
Script allows response
splitting (phpWebSite)CVE-2004-1516 5.0 Medium FAIL
CRLF injection vulnerability in
index.php in phpWebSite
0.9.3-4 allows remote attackers
to perform HTTP Response
Splitting attacks to modify
expected HTML content from
the server via the
block_username parameter in
the user module.I googled the living junk out of this and found jack. Even the list of PfSense vulnerabilities don't even show it. Not to mention, it's freaking ancient. I highly doubt pfSense 2.3.4 which came out in 2017 and is the current latest release version would have a 13yr old exploit in it.
I called Control Scan and they knew nothing about it. I have a Watchguard in the client at the moment, so they can pass the compliance.
I may hook up the pfsense and have control scan look at it, but wanted to put an alert in here just in case.
If anyone has any idea on what could be causing it, please post here.
-
Had to fix I had originally put 2.4 when I meant to put 2.3.4… Sorry for the confusion.
-
"It pops on port 9443 which is where I set the Webconfig"
While it would be interesting to look into what exploit they are saying..
Why and the world would your web gui be open to the public internet in any scenario at all?
-
And your remote-access VPN is … where?
-
normally it's locked down to only my company's IP range, but they request access to all opened ports.
Guys, the OP already stated he did this per request. The request was BS though. As far as they are concerned, it's not open. I would have left it locked to my location, or deleted the firewall rule until they finished testing. Add it back in via VPN or from the LAN side later.
(rant) All the people I have dealt with doing these scans have had no clue on networking or security. Basically monkeys trained to push a button, then print some meaningless report. (/rant) -
Normally, YES it only locked down to my IP ranges. We can't do site-to-site with them because they have the same internal IP as another client, but the other client pays us 10x what these guys pay us. This client is highly allergic to spending money, like anaphylaxis. So we can't change it. The other client also will not change their IP schema.
I have an sslvpn login and now that a watchguard is in place, it talks to my dimension server anyway. I also have screenconnect, a.k.a ConnectWise Control and can always log into a machine and hop on the web interface but some times the cheaper clients have slower servers and I am impatient.
The report, while full of words, pages full in fact, provides exactly zero useful information. It's all generic, and doesn't say what ACTUALLY caused it.
As far as these PCI Compliance scans and the scanners than scan them, yeah I could rant too.
-
That result is for a CMS called phpWebSite, not pfSense. The index.php page on pfSense doesn't even have a block_username parameter. Nor does any page. Not sure how that got tripped, but the scan is flawed.
As others have pointed out, remote scanners should have no special access to scan you. If that isn't open to the world, it doesn't matter for those scans. A scan from inside your network is different, however.
-
Normally, YES it only locked down to my IP ranges. We can't do site-to-site with them because they have the same internal IP as another client, but the other client pays us 10x what these guys pay us. This client is highly allergic to spending money, like anaphylaxis. So we can't change it. The other client also will not change their IP schema.
I have an sslvpn login and now that a watchguard is in place, it talks to my dimension server anyway. I also have screenconnect, a.k.a ConnectWise Control and can always log into a machine and hop on the web interface but some times the cheaper clients have slower servers and I am impatient.
The report, while full of words, pages full in fact, provides exactly zero useful information. It's all generic, and doesn't say what ACTUALLY caused it.
As far as these PCI Compliance scans and the scanners than scan them, yeah I could rant too.
You can use NAT to create that tunnel between to ends with the same network. https://forum.pfsense.org/index.php?topic=15748.0 this should help you in the right direction
-
"That result is for a CMS called phpWebSite, not pfSense"
They prob scanned the wrong IP ;)
