Hi looking for some advice if possible. I have a PCI audit for the first time through SecurityMetrics. I’m at a loss as to how to resolve these three PCI scan failures through Webmin or Virtualmin. I have looked everywhere but at a total loss of how to resolves these (or maybe they are false positives).
CGI Generic XSS (comprehensive test) on ports 10000 & 200000
virtualmin team should probably address this (in it is a real problem, not sure).
a “workaround” would be to limit access to ports 10000 and 20000. just as they mention in “resolution”. eg. limit access to specific ips only (through a firewall rule), or require some htaccess login, before virtualmin/usermin login.
that would block any scanners.
As Managed Hosting provider, we almost daily help our clients to pass different security scan, including PCI scan.
For clients who require Control Panel for daily tasks management, for example, mail accounts - we always install Virtualmin to our servers during many years.
So, to pass a PCI scan we always restrict access to ports 10000 (Webmin) and 20000 (Usermin) using firewall. Either permanently, if the client has provided us with an IP address(es) to whitelist, or temporarily, during a PCI scan.
I’m confused, if a car can be started without a key, parking it in a garage with a lock does not change the fact the car can still be started with out a key.
Hiding VM from and attack doesn’t fix the issue if its actually vulnerable to an attack.
The only question that should be asked, are those issues raised real or false. If real they need fixing if false then they can be ignored.
Thank you all for these first replies. I’m reluctant to restrict the 10000 & 20000 ports via firewall as I’m afraid when we change our ISPs or login off corporate network that I’ll never remember years from now to open up the firewall the new IPs (thus get locked out & not recall why).
I hope the webmin @staff are willing to investigate this either as a real issue or false positive.
Maybe I’m missing something, but I can’t reproduce this as an actual XSS. I can’t get JavaScript to run based on query parameters (copying their example exactly or anything else I’ve tried).
I’m not sure I believe there is any such vulnerability. I can’t reproduce it. When I include a script tag in the user parameter, it is just a script in quotes. It’s no more dangerous than me typing out <script>alert("Oh no!");</script> here. That’s not an XSS, it’s just a string.
I’m not sure I understand what the %00 in the script tags is supposed to accomplish, but it doesn’t make a string into executable code, as far as I can tell.
So, I’m going to need someone to explain to me how this is a vulnerability first.
Thanks for digging into this, really appreciate it. It’s possible this is a false positive coming from SecurityMetrics running the PCI scan. I’m not developer so some of this escapes me. Our donation platform is requiring me to be in PCI compliance which is how this has come up. If there’s a reference I can send them as to a false positive that would be great (if that’s what this is).
I don’t know the payload other than what appears in the report failure (below as text).
Using the GET HTTP method, SecurityMetrics found that : + The following resources may be vulnerable to cross-site scripting (comprehensive test) : + The ‘user’ parameter of the /session_login.cgi CGI : /session_login.cgi?user=<%00script>alert(219);</script%00> -------- output --------
As far as I can tell, this scanner is naively assuming that if you can make <script>alert(219);</script> appear in the output it is a vulnerability, even if it’s in a string and doesn’t execute in the browser.
I may be missing an option for escaping the string (I’m not extremely familiar with all the methods attackers use), but their test code does not escape the string, and you can see in the output they show that it does not escape the string…so, at the very least, this specific test is definitely bogus. They did not trigger execution of arbitrary JavaScript.
Some people prevent all sorts of scripty-related stuff in query strings entirely. e.g. no < or >. Which we don’t do here. But, maybe we should. I don’t think a username can have either character, so no harm in stripping it (we could strip or error on all invalid username characters, even… user accounts - What characters should I use or not use in usernames on Linux? - Server Fault ).
But, here’s what I see:
The scanner did not trigger execution of JavaScript. I don’t know why they’re reporting it as such. That just got the login form to show the username that passed in the query string, which is expected behavior and not an XSS.
If there is an XSS vulnerability here, I can’t find it. I’m not ruling it out…there are all sorts of surprises in the specs and in how browsers handle things, and I’m not an expert on XSS.
Limiting the login form to only accepting valid username characters would make this (wrong) test pass.
I am loathe to kowtow to scanner developers who do the most naive thing possible and call something harmless a vulnerability, but also we don’t have any reason to accept characters that are invalid in usernames in the user parameter.
I guess this is why some sites require use of special characters in a password and then limit that selection?
Just consider it a ‘best practices’ change. One less thing to worry about. It does make me wonder about the ‘view password button’. I doubt the automated script would catch that though.
Thanks Joe for taking a deep dive in this. I’m going to move forward by seeing if I can get them to agree allowing this as a false positive. If not, I’ll push them on more exact details.
We’ve discussed limiting it to only username-valid characters. I don’t think that’s necessary (I don’t think we’re allowing XSS currently), but also there is no reason to accept any special characters in that parameter, since it has to be a valid username.
I suspect the scanner parses the HTML after the payload is generated and spots unescaped HTML inside a quoted attribute’s value, then wrongly flags it as exploitable. But in reality—it’s not.
For unescaped HTML inside an attribute’s value to be dangerous, it would have to break out of the quotes—and that’s not possible here, since we’re correctly escaping quotes of the user’s input.
just an idea for webmin/usermin logins in general :
what if login was htaccess like enforced? web-server level, so, not loading any js/css/html untill user logged in.
or maybe as a hardening option someplace?
i guess that would save a lot of these false-positives and attack scenarios for good.
