Just wondering if anyone can confirm…
To explain, we are struggling with Trustwave (we accept credit cards at our “real” store and are bound to them for now for processing). For our online store, they do their scans and keep saying our site is not compliant… this time around for the CVE-2001-1013 error which deals with UserDir. Our host has confirmed that UserDir is disabled, so that cannot be what is throwing the false positive for Trustwave.
Could it be that CS's custom 404 pages return a 200 code somehow? My testing says no, but…
Thanks for any advice or info.
If your server is using 'backdated' software (patches applied to old version) then you'll be protected.
NVD - CVE-2001-1013
Since the exploit was discovered in 2001, it must have been patched already.
To fix this, there is an area to 'dispute' this exploit find in the trustwave report area.
Simple use the first selectable drop-down and inform them of the OS using and appropriate version (changelogs are typically ideal).
This will require SSH access for the most part OR your host to intervene on your behalf (costs money).
I'm working with a different client for the same purpose atm (different CVEs)
J.
Jesse - Thanks for the reply. Yeah, running latest everything on server and already disputed, and our host has been more than helpful without charging us. Just frustrating… seems like we get it automatically overridden from Trustwave, and then the next month/scan it turns up again. (Also difficult for TW to understand the WebDisk in cPanel too, but that's another story.)
Anyway, thanks, we'll see again what they say about the dispute.
I was just wondering if a 200 was indeed being returned somehow in a header even though CS's 404 page is called correctly.
Any other comments welcome and appreciated…
Just an update, latest scan turned up clean. Scan before that turned up with same errors and the disputes were vaguely denied. ?
There still must be something up with CS's 404 pages being deciphered as 200's or something by TW and thereby throwing the error.
Anyone else?
Can you provide the dispute CVE?
Jesse - thank you for responding. I'm doing another scan to see if things are consistently going to come up clean, or if the random errors will come back. I'll post back when I get results.
If I do need to post back CVE for you, what are you looking for… a) their explanation of the error, b ) my explanation of the dispute, or c) their response to my dispute?
Update - latest scan shows we are not compliant again as before, due to CVE-2001-1013 errors. Here is some info from the latest error :
Vulnerability:
HTTP Server Username Probing
The web server running on this host allows attackers to probe for user names via requests for user home pages (e.g., http://host/~username). Many different types of web servers exhibit this behavior, but it is most commonly associated with Apache HTTP Server.
CVE: CVE-2001-1013
NVD: CVE-2001-1013
Bugtraq: 3335
CVSSv2: AV:N/AC:L/Au:N/C:P/I:N/A:N(5.00)
Service: apache:http_server
Evidence:
Virtual Hosts: www.somedomain.com
Discovered username: someuser
Discovered path: /~someuser
HTTP status code: 200
Non-existent user path: /~non_existant_user
HTTP status code for non-existent user: 404
tcp/443
Remediation:
Configure the HTTP server to specify the same error documents for both 403 (Forbidden) and 404 (Page Not Found) responses. Additionally, if Apache is being used, the UserDir directive should be disabled in the Apache configuration file (httpd.conf).
As I mentioned, our host has confirmed that UserDir is disabled. And again, the prior scan to this one turned up clean. ?
Any other help is most appreciated…
I can't assist without touching the server, not something I can diagnose from the forum unfortunately.
Is your host unable to assist with this, specifically as if you are using cPanel/WHM this should be done for you out-of-the-box.
Regards,
J.
Thanks anyway, understood. Yeah, our host has tried. Very frustrating… mostly because scans will come up clean for awhile, then the errors will come back like before.
Also to add for example, in our dispute evidence, it shows the following :
Virtual hosts www.ourdomain.com
Discovered username someuser
Discovered path /~someuser
HTTP status code 200
Non-existant user path /~non_existant_user
HTTP status code for non-existant user 404
I guess this is why I was wondering if CS's default 404 page (with store logo, 'back' link', home page link, etc.) was somehow appearing to Trustwave as a 200, which would then understandably be an issue.
When I enter in the url www.ourdomain.com/~someuser as Trustwave claims, I get the 404 page. So, not sure what is throwing the error.
200 = “OK”,
If I look up a client site with the same domain, it 'catches' the inbound 404 - redirects to a '200' which presents the CS-Cart “Page Not Found” element, then “404's” the page as being not found after CS-Cart has loaded.
So to explain myself clearly, the CS-Cart error catch is causing your “server” issue.
I suggest that you inform Trustwave the that error 200 catchall is being handled by a script (CS-Cart) and they are reporting a seemingly false server-sided positive / other security controls are in place.
root@server [~]# lynx domain.com/~cscart
Looking up domain.com first
Getting http://domain.com/~cscart
Looking up domain.com
Making HTTP connection to domain.com
Sending HTTP request.
HTTP request sent; waiting for response. [color=#ff0000][This is the '200' catch][/color]
Read 546 KiB of data, 1.5 KiB/sec.
HTTP/1.1 302 Moved Temporarily
Data transfer complete
HTTP/1.1 302 Moved Temporarily
Using http://www.domain.com/~cscart
[b]Getting http://www.domain.com/~cscart[/b]
Looking up www.domain.com
Making HTTP connection to www.domain.com
Sending HTTP request.
HTTP request sent; waiting for response.
Read 689 KiB of data, 2.3 KiB/sec.
Alert!: HTTP/1.1 404 Not Found
Amen, and amen, that's what I have been trying to explain to them. But jumping through their hoops to get to the right people has been a battle.
THANK YOU greatly for this additional info, it further confirms what I initially thought in the original post here. I hope Trustwave can finally issue an override so these errors don't keep coming back.
Odd that more people aren't having this issue with CS and their processors… or perhaps nobody pays attention to compliance?
Thanks again, fingers crossed…
[quote name='wwgreen' timestamp='1329443984' post='131447']
Odd that more people aren't having this issue with CS and their processors… or perhaps nobody pays attention to compliance?
Thanks again, fingers crossed…
[/quote]
A client has being using TrustWave since early 2011, never had a problem with scans until November.
Basically TrustWave wanted proof that we were doing the right thing, I provided everything necessary and had these items disputed successfully except for one component which I resolved in about two hours.
Generally speaking if you have a dedicated server or VPS then you won't get half the hassles that they give you.
Hooray for now, response from Trustwave :
We have accepted this dispute based on the information provided indicating that your organization can confirm that all requests for username pages on this system result in the same error 404 response being returned.
This, after an hour on the phone with them and getting to the top level in support. Hope future scans turn up clean and CS is truly compliant.
Thanks again for your help, Jesse, much appreciated. Hope this post helps resolve any other similar issues with compliance and how CS's pages are processed.
Didn't take much lol.
PS: Their online portal works better than phone support if you can paste SSH commands/returns.
Not to open this can of worms again, but I just did a 'Fetch as Googlebot' for kicks on a url within our site that I know does not exist… CS's 404 page loads for the user fine as it always has done, but 'Fetch' says it returns a 301 header. ?
Doh!
Once again, is CS really returning a 404 to the engines so it can keep things cleaned up?
[quote name='wwgreen' timestamp='1331841259' post='133211']
Once again, is CS really returning a 404 to the engines so it can keep things cleaned up?
[/quote]
That's right, we return 404 header.
Thanks, Zeke. But, puzzled then why I get the following when using Fetch…
Googlebot Type: Web
Download Time (in milliseconds): 163
HTTP/1.1 302 Moved Temporarily
Date: Fri, 16 Mar 2012 15:49:32 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: -1
Last-Modified: Fri, 16 Mar 2012 15:49:32 GMT
Location: http://www.mydomain.com/links.html
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
?
200 = FOUND
SERVER SAYS “IT AIN'T HERE”
SERVER SAYS = 301 REDIRECT
CUSTOMER VIEWS 301, REDIRECTS TO 404
Caps for emphasis on path