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

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?

 

  • In reply to Jelle:

    Jelle

    FYI:

    I just did the Qualsys SSL check with our XG210 and 17.5 GA:

     

    TLS seems to be ok

     

    But some weak cipher suites are enabled

     

    Overall rating is T but would be A if trust issues are ignored.

    I did not change anything in config files etc.

     

    Regards, Jelle

     

    I saw the same results when I tested my XG135.  Haven't tested my XG210 yet, but I may later.

  • In reply to AllanD:

    AllanD, Michael Dunn was doing some digging, and pointed out to me that there's two different httpd.conf files on the shell:

    /_conf/httpd/conf/httpd.conf

    and 

    /usr/apache/conf/httpd.conf

    I was referencing the first one, but I suspect you're referencing the second one, as I see similar lines you're mentioning in the second file. 

    The first one is used by webadmin, the user portal, and other system services, and I've tested numerous systems, and can confirm the same scan results Bill Roland reports, across my estate of firewalls. The second one is related to WAF, but I'm not certain how exactly it is used - if it's still used at all. For example, it always says it will allow TLS 1.0 & 1.1, but I can change that setting in webadmin, under "Webserver Protection > General", then test against https://www.ssllabs.com/ssltest/ and clearly see that TLS 1.0 and 1.1 are allowed or blocked, on any WAF listening ports, according to the webadmin setting. So while I can verify what you're seeing on the shell, I can't confirm the external behavior results you're reporting.

    Ignoring the .conf file contents for the moment, I want to make sure I'm really looking at the same thing that is actually failing for you. Can you give a bit more info on the audit failures you're getting? what ports are involved, etc..?

  • In reply to AlanT:

    AlanT

    I want to make sure I'm really looking at the same thing that is actually failing for you. Can you give a bit more info on the audit failures you're getting? what ports are involved, etc..?

    I think everything is documented pretty well already in this post:  https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/109122/failing-pci-scans-because-of-outdated-jquery-in-user-portal---is-there-a-fix/391199#391199

    When the default /usr/apache/conf/httpd.conf is used, which again gets reset with each firmware update, I fail on TLS 1.0 being supported along with 3DES issues.  When the file is edited to remove TLS1, 1.1, and 3DES I no longer fail on those items.  The port these vulnerabilities are found on are 443 which are all pointing to internal web servers so I believe you are correct when you say this is a issue with WAF.  My user portal is on 4443, web admin on 4444 (internal only).  As for:

    AlanT

    I'm not certain how exactly it is used - if it's still used at all.

    Based on the evidence in the above post it definitely is being used.  Otherwise making a change to it wouldn't be changing what is detected. 

     

    As a side note I don't know what changing the TLS version under Protection -> Web Server -> General Settings does.  It doesn't seem to have any effect on either config file.  I would think it should affect both but as a test I changed mine to TLS v1.0 and apply. I waited a couple minutes then checked both files under SSLProtocol.  The /usr/apache/conf/httpd.conf file still defaulted to "SSLProtocol all -SSLv2 -SSLv3" and the /_conf/httpd/conf/httpd.conf file still defaulted to "SSLProtocol -all +TLSv1.2".  So not sure what that actually does if anything.

  • In reply to AllanD:

    I second all of  comments.  I'm in the exact same boat to pass PCI.  My XG was pre-loaded with ver 17 when I received it.  After every firmware update I have to perform the same changes to the httpd files. 

     

    PCI compliance did eventually accept my dispute regarding the Jquery issue. 

  • In reply to AllanD:

    Ok, I think we're getting somewhere. At least we've pinned down the problem area, and we should be able to get to the bottom of this a little easier now. The file I was originally referencing is used for most everything other than WAF. We can ignore that in your case. The file you are changing shouldn't matter, but apparently does. 

    Can you (AllanD and JonathanP) post the sanitized contents of /cfs/waf/reverseproxy.conf? 

    Also, are you able to run an nmap scan (nmap -sV --script ssl-enum-ciphers -p 443 [ip or hostname]) and share the output of that? 

    Lastly, can you verify that 'cat /usr/apache/conf/httpd.conf |grep Include' returns a line 'Include /cfs/waf/reverseproxy.conf'?

     

    I've dug into this enough to know that changing the cipher settings in /usr/apache/conf/httpd.conf shouldn't matter. WAF should always use the cipher settings from reverseproxy.conf, and we need to understand why it seems different in your case. Hopefully the above info will pin it down a little closer. 

  • In reply to AlanT:

     - I want to iterate a couple facts before I do more testing on my side.  And I don't mean to be flippant but I feel I've proven that this is a software issue and as experts with the product you guys should be able to track this down on your own.  With that said:

    1) The settings in usr/apache/conf/httpd.conf absolutely affect WAF as demonstrated by my testing in a previous post

    2) The settings in usr/apache/conf/httpd.conf are rewritten on each firmware upgrade to a "default" file which is inherently insecure

    3) This is affecting multiple different XG models across at least two years of firmware updates

    4) The statements above have been verified by  whose system exhibits the exact same issue.  And I imagine many others out there have the same issue that just haven't had PCI compliance scanning done.

    With that said....

    AlanT

    Can you (AllanD and JonathanP) post the sanitized contents of /cfs/waf/reverseproxy.conf? 

    Ok....so my /cfs/waf/reverseproxy.conf is very large and probably not conducive to posting on a forum (we host Outlook Web access, Outlook Mobile Access, Outlook Anywhere, multiple websites, some using the Sophos Forms for login, etc).  That and sanitizing it would be a pain.  But right at the beginning, after the listening statements and before the first virtual host I have this:

    SSLProtocol -all +TLSv1.2
    SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS

    Which would indicate, to me, that's the settings it should be following but as demonstrated its not.

    AlanT

    can you verify that 'cat /usr/apache/conf/httpd.conf |grep Include' returns a line 'Include /cfs/waf/reverseproxy.conf'?

    I've dug into this enough to know that changing the cipher settings in /usr/apache/conf/httpd.conf shouldn't matter. WAF should always use the cipher settings from reverseproxy.conf, and we need to understand why it seems different in your case. Hopefully the above info will pin it down a little closer. 

    Output of 'cat /usr/apache/conf/httpd.conf |grep Include' is:

    XG310_WP01_SFOS 17.1.4 MR-4# cat /usr/apache/conf/httpd.conf |grep Include
    Include conf/modules.conf
    Include /cfs/waf/mpm.conf
    Include /cfs/waf/status.conf
    Include /cfs/waf/reverseproxy.conf
    XG310_WP01_SFOS 17.1.4 MR-4#

    So not sure if you can look through your programming....I see its including the settings in reverseproxy.conf which does have the more secure settings but I'm wondering if the settings in 'usr/apache/conf/httpd.conf' simply take precedence.

    AlanT

    Also, are you able to run an nmap scan (nmap -sV --script ssl-enum-ciphers -p 443 [ip or hostname]) and share the output of that? 

    Not real sure on the nmap, never used it, but I can try.  With that said am I supposed to edit the file back to "default" with the vulnerabilities first?  I would assume so but just making sure.  Or is the above enough to go on?  If usr/apache/conf/httpd.conf is taking precedence I would think removing the 'SSLCipherSuite' and 'SSLProtocol' lines would allow the identical ones within reverseproxy.conf to take effect?

  • In reply to AllanD:

    First off, on the original thread topic, the KB has been updated to be a bit clearer: https://community.sophos.com/kb/en-us/132741. Hopefully that helps with addressing auditors.

    AllanD
    I feel I've proven that this is a software issue and as experts with the product you guys should be able to track this down on your own.

    Fully understood, but unfortunately, that's not so clear. We have a large base of customers subject to PCI scans, and we aren't getting any similar problems reported to support. From our perspective, the features to address this were added in 16.5, end of story. Youre still reporting problems though, and we need to gather info to get  to the bottom of it.

    it might be helpful to better understand how it's supposed to work. I spoke with our engineering team who builds the WAF in XG, and they shared two clarifying points

    • The httpd.conf is never directly used in the WAF configuration. WAF uses the reverseproxy.conf file, but may use some httpd.conf settings as defaults. It doesn't matter what is in httpd.conf, only what is in reverseproxy.conf.
    • The TLS version and cipher settings are inherited from httpd.conf unless the TLS version is changed in the Webserver Protection > General tab in the UI. Overriding the TLS value replaces the cipher suite with a smaller PCI-safe list. 

    Somehow, that isn't holding true in your case. Can you PM me the current, full contents of your httpd.conf and reverseproxy.conf files? I want to get our engineering team to look at them in more detail. Whatever is happening here, seems fairly specific to something in your configuration.

  • In reply to AlanT:

    Ok....PM'd you the files.  Might want to get the same form although I would guess if you figure out whats going on with mine you'll figure out his issue too since it seems to be the same.

  • In reply to AlanT:

    AlanT

    First off, on the original thread topic, the KB has been updated to be a bit clearer: https://community.sophos.com/kb/en-us/132741. Hopefully that helps with addressing auditors.

    PCI compliance scanning company approved my dispute based on the updated KB article.  Thanks.

  • In reply to AlanT:

     I have PM'd the requested commands and output.  I hope this helps. 

  • In reply to AlanT:

    AlanT

    First off, on the original thread topic, the KB has been updated to be a bit clearer: https://community.sophos.com/kb/en-us/132741. Hopefully that helps with addressing auditors. 

    This one does describe why it's a false positive. From my perspective, there is still absolutely no need to use JQuery Framework for a simple Login-Screen.

    If you are using it after logging in for anything, that's ok but it's not ok to use it on a Login Screen of a Security Product.

  • In reply to HuberChristian:

    HuberChristian
    If you are using it after logging in for anything, that's ok but it's not ok to use it on a Login Screen of a Security Product.

    A fair argument, and I can't comment immediately on why its needed. We may be planning to remove jquery from the login environment in future, but I'll have to check on that. In the mean time, it is loaded, and does not pose a security risk.