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?

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
  • Apparently this is patched.  Just dispute the finding with Trustwave. 

    See KB from Sophos here:

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

  • 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?

  • 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. 

  •  - 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 said:

    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 said:

    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 said:

    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?

  • 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 said:
    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.

  • 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.

  • AlanT said:

    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.

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

  • AlanT said:

    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.

  • HuberChristian said:
    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. 

  •  - Any updates on this?  Still running 17.1.4 MR4, still failing PCI scans.  Just had one run this morning, here are the results:

    (SSL Certificate errors can be ignored...we have a multiple subject name SSL cert and their scans don't like it so I have to file a dispute for that.  Cant dispute the TLS though).

  • Would suggest to open:

    a. a new Thread about this TLS1.0 Issue.

    b. a new Support Case about this Issue. 

     

    So we can keep this here about the jQuery Topic and discuss the WAF issue separately. 

Reply Children
No Data