Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 59 replies
  • Answers 2 answers
  • Subscribers 36 subscribers
  • Views 51979 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Failing PCI Scans because of outdated jQuery in User Portal - Is there a fix?

AllanD

We are failing our PCI compliance scans on every XG firewall we have that has the user portal enabled.  Our PCI compliance scanning company is telling us this:

 

Description:  "jQuery is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Asynchronous JavaScript and Extensible Markup Language (AJAX) Request is performed without the dataType option, causing text/javascript responses to be executed.  This finding indicates that either the root domain url, sub-domain url, or an imported/sourced version of jQuery is below jQuery version 3.0. All three scenarios allow an attacker to execute cross site scripting attacks on the root domain."

Evidence: jQuery appears to be '2.1.3' and needs to be at '3.0.0' or higher

 

This is ONLY happening on the port used by the User Portal.  To verify this we changed the port to another number, had a host rescanned, and the vulnerability was found on that new port.

 

Is there anything I can do to get this fixed or do I have to wait for Sophos to update the jQuery version they are using?  Is there a bug report place I can put this if that's the case or who do I contact?

 



This thread was automatically locked due to age.
Parents
  • 0

    Apparently this is patched.  Just dispute the finding with Trustwave. 

    See KB from Sophos here:

    https://community.sophos.com/kb/en-us/132741

  • 0 in reply to JonathanP

    I sent the link to the scanning company and they don't like it.  They asked me to provide the current version of jQuery actually running on the box.  So I opened our user portal in Chrome then opened up the developer tools.  On the console tab I typed in jQuery.fn.jQuery and it returned "2.1.3".

     

    Not sure how they are mitigating the problem but their explanation isn't going to work for my PCI scanning company.  Anyone running 7.5 that can try doing the same?

  • 0 in reply to AllanD

    i did not dig to deep into this issue/challange but as far as i know, the product is harden. So basically if the PCI Scan only checks for the version, which i assume, it will most likely point out the "FP". But we fixed the "capability" of using this CVE. 

    So what i would like to know, how did the PCI-DSS audit point out, that CVE is still be affected? 

    Most likely, because it is fast and simply, they only scan the version, not the "real capability of using the vulnerability"

  • 0 in reply to LuCar Toni

    Here is the problem.  I talked to them and they said the version found, 2.1.3, has the vulnerability.  I told them that you guys "fixed it" and its a false positive.  I gave them the link to the KB article.  They read it and told me that the article doesn't say anything other then its a false positive and since it has nothing about what was done they cannot pass me.  They said the do not check further into it other then the version and won't do any other testing. 

    So either the software needs to be updated to 3.0.0+ or a detailed description of how the vulnerability is fixed needs to be in the KB article.  Otherwise I will continue to fail the scans.

  • 0 in reply to AllanD

    Interesting approach. So i would suggest to open a case to get the answer of the patch, which was applied. 

    But basically this is "a normal process". You do not publish the whole Harding process. 

    Sophos Support should give you more details. 

  • +1 in reply to LuCar Toni

    I have put in a support request.  Here is there answer which doesn't help at all:

     

    "Thank you for contacting sophos technical support today.  Just to let you that this issue in not currently a technical support issue as we provided this KB https://community.sophos.com/kb/en-us/132741.  Current there is no ETA when this version will be upgraded to 3.0 or higher.  If you require different answer please contact your account manager about this issue."

     

    I replied and told them I needed more information to satisfy our PCI scanning company and have received no response yet.

  • +1 in reply to AllanD

    This issue was allready reported by myself during the Beta Period. See: https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v17-5-early-access/f/sophos-xg-17-5-early-access/108784/planned-login-screen-change-for-17-5-final

     

    I do not understand at all, why they need a full JQuery for a simple Login Screen. This makes Loginscreen huge (2.2Mbytes which has to be transfered for each Request). 

    From my point of view, this is a good example on what happens, if in a Company the Marketing guys are going to decide about stuff like this instead of technicans/developers.

  • 0 in reply to HuberChristian

    Hi HuberChristian,

     

    We are aware of the issue with this False Positive and we would request you to contact your Partner or open a case with Sophos Support so this issue can be sorted out earlier. . 

     

    Please mention the link of this thread and the results of your PCI scan .Also mention the KB article. 

    https://sophos.com/kb/132741

  • 0 in reply to Aditya Patel

    Aditya Patel said:

    We are aware of the issue with this False Positive and we would request you to contact your Partner or open a case with Sophos Support so this issue can be sorted out earlier. .

    Please mention the link of this thread and the results of your PCI scan .Also mention the KB article.

    Again, this is not the answer. I have already contacted support and all support did was point me to the same article.  I told them I needed more information on that and I never got another reply.

  • 0 in reply to AllanD

    Which information do you need? 

    Seems like it is fixed. We did not update the version, instead we closed this CVE with a fix. 

    So - what should we give you for information? 

  • 0 in reply to LuCar Toni

    We need to know what was done to fix the vulnerability.  Something our PCI compliance scanning company can document as to why to approve a dispute of what they found.  Your article says "Its not really broke" without giving even the slightest bit of information of why its not still broke.  And since the scanning company simply looks to see what version its running and sees 2.1.3 they are failing us because again you are not providing anything other then "Trust us....its fine".

     

    Say every time you drove your car above 60 MPH the check engine light went on.  You contacted the manufacture and they told you "Oh...its a false positive." and you asked "But why does it do it?" and they just told you again "Its fine, its a false positive".  How much faith would you actually have in their answer or your car? 

  • 0 in reply to AllanD

    "Say every time you drove your car above 60 MPH the check engine light went on.  You contacted the manufacture and they told you "Oh...its a false positive." and you asked "But why does it do it?" and they just told you again "Its fine, its a false positive".  How much faith would you actually have in their answer or your car? "

    Would suggest another analogy. When you drive 60 MPH, you could open the hatchback from outside. You never did this before and you notice it in a report. The car vendor fix this issue and told you, it is not possible anymore. What do you do? Driving 60 MPH and trying to open the hatchback i would suggest.

     

    And this is your next step. If you do not believe our KBA, try to exploit the vulnerability.

     

    Maybe i am quite harsh. It is my approach in this case. 

     

Reply
  • 0 in reply to AllanD

    "Say every time you drove your car above 60 MPH the check engine light went on.  You contacted the manufacture and they told you "Oh...its a false positive." and you asked "But why does it do it?" and they just told you again "Its fine, its a false positive".  How much faith would you actually have in their answer or your car? "

    Would suggest another analogy. When you drive 60 MPH, you could open the hatchback from outside. You never did this before and you notice it in a report. The car vendor fix this issue and told you, it is not possible anymore. What do you do? Driving 60 MPH and trying to open the hatchback i would suggest.

     

    And this is your next step. If you do not believe our KBA, try to exploit the vulnerability.

     

    Maybe i am quite harsh. It is my approach in this case. 

     

Children
  • 0 in reply to LuCar Toni

    The problem is you are the one providing the firewall, you are running the outdated jQuery software, you should be the ones that can provide what you did to make it secure or at least some information.  It shouldn't be up to me or the PCI scanning company.  They identified you are running a outdated version with a specific vulnerability and are asking you for information on how it was fixed other then "its a false positive".  For all they know you did nothing and just put up a article saying its a false positive.

     

    And the reason this is important is because this XG product suffers from lots of other vulnerabilities that need manual intervention to fix.  Like the fact it supports 3DES encryption, TLS1.0, TLS1.1, and HTTP Track/Trace all by default and all that fail PCI compliance scans.  All these things need to be manually turned off through the console and get re-enabled every time there is a firmware update.

  • 0 in reply to AllanD

    You should talk to your Sales Rep about this to get a proper answer to this topic. 

  • +1 in reply to LuCar Toni

    LuCar Toni said:

    You should talk to your Sales Rep about this to get a proper answer to this topic. 

     

    Please don't take this wrong but I came to these forums for a answer.  When that wasn't looking very positive I put in a support request.  So if you, a Sophos staff member, cannot answer the question here and your support people (case #8496846) can't answer the question through their channels then the only reason I would be contacting my sales rep is to find alternatives to your product.

     

    With that said it is not something I want to do, especially after investing in 3 XG's and 12 - 14 REDs.  I like the product overall but for a security appliance it seems to have a decent amount of security related issues.

  • 0 in reply to AllanD

    I am here in my free time without any relation to the support and product management. Just trying to help people in getting some answers. 

     

    PS: The point about sales rep is to follow up the Support Case to get a proper "official" answer. 

  • 0 in reply to LuCar Toni

    Here's the response I got back from my scanning company after I filed the dispute:


    In order for us to properly process this dispute, we require the full jQuery version currently running on this system.

  • 0 in reply to JonathanP

    I opened a support ticket and got the following email this morning as well which doesn't help. :

     

    I have confirmed with our global escalations team (GES) that the XG is patched since MR2 however the detection will falsely be detected. 

    It it scheduled to be fixed in 18.5, however this may change and we do not have a set date for when this will be released. 

    Please let me know if you have any further questions, or if you are happy for the case to be archived?

  • 0 in reply to AllanD

    Hey AllanD,

    This thread seems to have de-railed somewhat. Let me try to put some tracks under it again.

    As you should expect, this report was already known to us, and some of the confusion comes from there being multiple CVEs reported in the initial reports we received, and this wasn't a simple case of "critical vuln found, fix immediately".  

    CVE-2016-10707 was found to be a false positive on XG, because the version of jquery we use is not affected, despite early reports to the contrary. You can find some comments on this buried here: https://github.com/jquery/jquery/issues/3133  Specifically: "The range in the database is incorrect, the only affected version is 3.0.0-rc.1. Both the earlier 2.1.x, 2.2.x & 3.0.0-beta1 and the later 3.0.0 don't exhibit the issue."

    Originally, a range of affected versions were reported, but later, this was reduced to just one version, which is not the version XG is using. If this cve is being flagged, it is a false positive on the part of your auditor, likely because it is using the originally mis-reported list of affected versions. The link above should help with supporting material for this.

    The other item is CVE-2015-9251, does affect the version XG is using, and that library is potentially vulnerable to a XSS attack - depending on implementation. XG's implementation does not allow it to access any external content, thus the risk has always been fully mitigated, lowering the priority to update. We will eventually upgrade to a newer version of jquery, but we're not ready for that effort just yet, so as a further interim step, in v17.1 MR2, we back-ported the fix from a later version, to the version we are running. As of v17.1 MR2, XG is not even theoretically affected, though because the version number remains the same, this will likely need to be addressed explicitly in your audits. 

    Hopefully that clarifies things a bit, and I'll follow up internally, to make sure that our KB articles are adequately detailed, to cover what I've said above. 

     

    One final note, though..

    AllanD said:
    And the reason this is important is because this XG product suffers from lots of other vulnerabilities that need manual intervention to fix.  Like the fact it supports 3DES encryption, TLS1.0, TLS1.1, and HTTP Track/Trace all by default and all that fail PCI compliance scans.

    That info is outdated. I'm not sure when this changed, but it's been a while, and doing a quick sanity check, my firewalls all report an A ('T' actually, but 'A' if certificate trust issues are ignored) on qualys ssl test site. None of the issues you mention are present in their report. you might want to have another look at that.

  • 0 in reply to AlanT

    (snip bunch of tech stuff)

    Thank you for the additional information.  I will submit this to our scanning company and go from there.  This is what they want to know, the KB article is extremely vague...they read it and said there is nothing substantial in the article to change my failing grade.  And your support people just keep pointing me to the KB article or telling me it will be upgraded to 3.* with version 18.0 and they have no ETA.

     

    That info is outdated. I'm not sure when this changed, but it's been a while, and doing a quick sanity check, my firewalls all report an A ('T' actually, but 'A' if certificate trust issues are ignored) on qualys ssl test site. None of the issues you mention are present in their report. you might want to have another look at that.

    I'm sorry but you are incorrect on this.  The reason none of these things are in the report is because I keep manually fixing them.  For example I just upgraded a XG310 from 17.1 MR3 -> MR4:

     

     

    I then re-run a PCI compliance scan.  Here is the results.  The IP address in question ends in .98:

     

     

    I highlighted the failures on 3DES and TLS 1.0.  So I telnet in and check the appache httpd.conf file and this is whats in it:

     

     

    Sure enough all those protocols are reenabled on each firmware upgrade.  I then have to manually edit that file to remove 3DES, TLSv1, TLSv1.1, and TraceTrack so it looks like this:

     

     

    and restart the services (per the instructions your support people gave me and I blogged about here). I then rescan and I no longer fail due to those items:

     

     

    So this issue has been around since v16.01 and has required a manual editing of that file for every firmware upgrade on every XG box we have.  This has been going on for at least two years now.  So I stand by my "this XG product suffers from lots of other vulnerabilities that need manual intervention to fix" comment.  If you have a better solution I'd love to hear it because I purposely don't do firmware updates as often as I should because I know I have to do this afterward every time.  And I'm not the only one this is affecting based on my previous forum post about it.

     

    (Side note:  My other failures stem from the scanning company not liking our SSL with multiple subject alternative names....they are going to allow us to dispute those.  The RED devices on port 3400 are taking some arguing since you guys are using a self signed certificate for those).

  • 0 in reply to AllanD

    hmm.. there's definitely something wrong on your system. I'll post the un-edited contents of my httpd.conf below, and you can see that only TLS 1.2 is allowed, and only a limited set of ciphers. I'm running 17.5 GA, but I went back and checked, and we removed TLS 1.0 and 1.1, and a bunch of ciphers in 16.01, MR2 (NC-8116). You can see it mentioned in the release notes here: https://community.sophos.com/products/xg-firewall/b/xg-blog/posts/sfos-16-01-3-mr2-released. 

    If you spin up a new VM, you should be able to see the same thing I'm seeing. I can't explain why your system is behaving differently, but if you can confirm that what you're seeing, and what I'm seeing are in fact the same thing, then open a support case, and PM me the case number. I'll make sure it's escalated and we look into it. 

     

    Here's the settings from my systems:

    <VirtualHost _default_:${userportal_listen_port}>
    Include /_conf/httpd/conf/userportal_alias.conf
    SSLProtocol -all +TLSv1.2
    SSLHonorCipherOrder on
    SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!EXP:!NULL:!ADH
    SSLEngine on
    SSLCertificateFile "${SSLCertificateFileWithPath}"
    SSLCertificateKeyFile "${SSLCertificateKeyFileWithPath}"
    SSLCACertificatePath "/conf/certificate/cacerts"
    Include /_conf/httpd/conf/userportal-static.conf
    </VirtualHost>

  • 0 in reply to AlanT

    I'm having the same issue.  I've got an xg 450.  I recently updated to 17.5.  After the update I had to edit httpd config as well.

     

    For example the original cypher line:

    ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS

    Modified cypher line:

    ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

     

    SSLProtocol all -SSLv2 -SSLv3

    Modified protocols line:

    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1