Hi,
A recent PCI fail, which stated XXS vulnerability has made me investigate some issues.
We are currently using V1.9.2.2 with I thought all the security patches, but I just noticed SUPEE 7405 had an update. Is there anyway of checking whether ours is the current version of 7405?
So I am therefore wondering if an upgrade to V1.9.2.4 would be the better solution rather than keeping a tab on the security patches...ie whether i have installed them or not?
So whilst reading through the report there I noticed that there was mention of OS Commerce. Is it possible that some old installed fails on my server could still be there? I realise no one really knows without looking, so I am wondering where I might look?
For example this is failing: osCommerce 2.2ms1 Multiple Script XSS - what is this? Why would I have it?
It all seems a little weird, maybe even just 'an example' because if I knew where it might be I would just delete it.
osCommerce 2.2ms1 Multiple Script XSS is a very old vulnerability. Probably a mistake or a real problem with the URL http://www.YOURSITE.com/default.php on your site. Take a look here to see more information:
https://www.exploit-db.com/exploits/22392/
As for the patch of SUPEE 7405, you can find tons of information about it here: https://magento.com/security/patches/supee-7405
Basically it says if you did the v1.0 of the patch, you should also grab the v1.1 and patch that ( I know ) but if you haven't done either, then do them both.
I would start by asking which ever scanner you used what files / urls are affected by this vulnerability and work to fix them be it removal or patching.
If they are unhelpful try (i have used several that are not helpful at all)
If all else fails you could request a re-scan and before it starts rotate your http access logs and use a log viewer on the logs after it finishes and look for the anomalies yourself which will be very time consuming unless you know what you are looking for.
After going through a PCI investigation I can offer the advise of keeping magento updated to the highest patch you can achieve and its extensions and also looking at the payment gateway Braintree as it massively reduces the risks to you if your taking direct card payments
Without taking a look at your PCI scan report and your server environment, it will be very hard to pinpoint if the mention of OsCommerce is just an example or if there's an OsCommerce installation in your server.
Did the report mention the file path to the XSS Vulnerability? That should at least give you somewhere to look and see if there's really an old OsCommerce installation hiding somewhere.
I swear my last message went missing, anyway the rest of the guys covered what I said but I have two bits of info extra:
osCommerce 2.2ms1 Multiple Script XSS specifically relates to a file called default.php and is a really old exploit so it may be an false positive (More info here: ExploitDB info)
SUPEE 7405 v1.0 and v1.1 means you have to run patch v1.1 if you haven't run it on CE 1.9.2.2. (Detail here: Official Blog post)
Hope this helps
Talesh
Many thanks for all that
If SUPEE 7405 is already installed, is there anyway of finding out if V1.1 was also installed?
I presume because of the venerabilities, chances are it was not?
on the report there is several of this:
Vulnerability: osCommerce 2.2ms1 Multiple Script XSS
Compliance Status:Fail
Port TCP port 443
Synopsis: The remote web server is vulnerable to a cross-site scripting flaw. Impact: osCommerce is a widely installed open source shopping e-commerce solution. An attacker may use it to perform a cross-site scripting attack on this host.
Resolution: Upgrade to a newer version
The above is what most of the report states
Or this one. which is slightly different:
Vulnerability: CGI Generic Cookie Injection Scripting
Compliance Status:Fail
Synopsis: The remote web server is prone to cookie injection attacks.
Impact: The remote web server hosts at least one CGI script that fails to adequately
sanitize request strings with malicious JavaScript. By leveraging this issue, an attacker
may be able to inject arbitrary cookies. Depending on the structure of the web
application, it may be possible to launch a 'session fixation' attack using this
mechanism. Please note that : - SecurityMetrics did not check if the session fixation
attack is feasible. - This is not the only vector of session fixation.
See also : http://en.wikipedia.org/wiki/Session_fixation
http://www.owasp.org/index.php/Session_Fixation
http://www.acros.si/papers/session_fixation.pdf http://projects.webappsec.org/Session-
Fixation
Data Received: Using the GET HTTP method, SecurityMetrics found that : + The
following resources may be vulnerable to cookie manipulation : + The 'cat' parameter
of the /catalogsearch/result/index/ CGI : /catalogsearch/result/index/?cat=
<script>document.cookie="testllmd=764;" </script> -------- output -------- category: 3,
ajax: 1, reqUri: '/catalogsearch/result/index/?cat=<script>document.cookie="testl
lmd=764;"</script>' }); //]]> ------------------------ + The 'order' parameter of the
/xxxxxxx-for-motorsports-and-motorcycling.html CGI : /-for-motorsports-andmotorcycling.
html?order=<script>document.c ookie="testllmd=764;"</script> --------
output -------- category: 53, ajax: 1, reqUri: '/xxxxxx-for-motorsports-andmotorcycling.
html?order=<script>d ocument.cookie="testllmd=764;"</script>' }); //]]>
------------------------ + The 'dir' parameter of the /xxxxxxx-for-motorsports-andmotorcycling.
html CGI : /-for-motorsports-and-motorcycling.html?dir=
<script>document.coo kie="testllmd=764;"</script> -------- output -------- category: 53,
ajax: 1, reqUri: '/xxxxxx-for-motorsports-and-motorcycling.html?dir=<script>doc
ument.cookie="testllmd=764;"</script>' }); //]]> ------------------------ + The 'order' parameter of the /xxxxxx-for-motorsports-and-motorcycling.html CGI : /xxxxxx-formotorsports-
and-motorcycling.html?order=<script>document.c ookie="testllmd=764;"
</script>&dir=desc -------- output -------- category: 53, ajax: 1, reqUri: '/xxxxx-formotorsports-
and-motorcycling.html?order=<script>d ocument.cookie="testllmd=764;"
</script>&dir=desc' }); //]]> ------------------------ + The 'dir' parameter of the /for-
motorsports-and-motorcycling.html CGI : /xxxxx-for-motorsports-andmotorcycling.
html?order=name&dir=<script>d ocument.cookie="testllmd=764;"
</script> -------- output -------- category: 53, ajax: 1, reqUri: '/xxxxxx-for-motorsportsand-
motorcycling.html?order=name&dir= <script>document.cookie="testllmd=764;"
</script>' }); //]]> ------------------------
Port: 80
So, also from what others have said I am 'over thinking' the report, see I am looking for information and all the report has down is highlight more questions.
Where as the solution irrespective of the issue, is:
Resolution: Restrict access to the vulnerable application. Contact the vendor for a patch or upgrade.
So updating to latest patches or update to 1.9.2.4 ?
Many thanks
It does seem like there's an OsCommerce installation somewhere.
You should be able to find it by going through your non-Magento directories.
Its hard to advise for/against moving to 1.9.2.4 vs running the v1.1 of the patch without knowing a lot more information about your store. Maybe the guys who have spent a lot of time patching/upgrading can help.
As for the warning, don't be surprised if its a false positive, but as I said, look for default.php in your filesystem since thats the offending oscommerce file triggering that warning and determine if it was a legitimate concern or not.
Hi,
Many thanks for that, I will double check, but as far as I can see there are no 'non magento folders'
Maybe I have missed something?!?!
I wish I had guessed security metric earlier, I'm not a massive fan of their scanner as its a complete mess with no throttling and idiots behind the wheel. Worst case scenario for me was them scanning every site on my dedicated server and choking apache to breaking point during peak hours. After that I let my cisco firewall deal with them which passed several PCI scans before they noticed they were getting bounced.
I would find the osCommerce as that is just bad to have old files accessible on your server especially vulnerable ones.
Update to 1.9.2.4 then re-scan if you are worried.