Topic
  • 3 replies
  • Latest Post - ‏2013-07-02T18:49:08Z by Jim Sharpe
Jim Sharpe
Jim Sharpe
98 Posts

Pinned topic New serious security hole(s) in v3.1?

‏2013-06-26T03:29:18Z |

We recently completed a security assessment of some new v3.1 Streams installations and discovered many new issues associated with the Streams Console port.  During the investigation, one test we performed was to upgrade an existing v3.0 test environment that did not exhibit any of the vulnerabilities immediately prior to v3.1 but now shows the same issues.  So the anecdotal evidence is that something has changed between v3.0 and v3.1 that opens many very serious security vulnerabilities. 

The security scan we performed identified several thousand vulnerabilities, many serious, that did not exist on the same host when running v3.0 but did immediately after performing the v3.1 install.

Most appear to be exposures to services completely unrelated to Streams and which don't belong at all on any production Streams server.  Here is a single example of a URL that was found to be problematic:

https://streamshost:8443/streams/admininstance/streamsScript/calender_admin.pl

There are literally hundreds of others referring to things like DNEWSWEB, BizDB, RobPoll, Antelope W4-Server, Cart32, WebWho+, Dmailweb, EZshopper, and the list goes on, and on.  Note that none of these vulnerabilities showed up on a security scan done just prior to installing v3.1 and all that was done to the server between the scans was to run the 3.1 installation binary and firststeps.  Also the vulnerabilities appear to move with the port defined for the Streams Console.  I.e., when we changed the port from 0 to 8443 the vulnerabilities now show up on 8443 rather than the previously selected port.

I really hope this is something that can definitely be addressed through some straightforward configuration because if not we will have no other choice but to revert back to v3.0.   Please feel free to contact me directly if there is any additional information I can provide.

 

  • Stan
    Stan
    76 Posts
    ACCEPTED ANSWER

    Re: New serious security hole(s) in v3.1?

    ‏2013-06-27T03:19:07Z  

    I reviewed the documents you provided from your security scan and have determined the warning messages are all false positives, meaning they are not true security issues.

     Your scan returns these warnings because Streams returns static text rather than an http response code under the following circumstances.  When the streams console receives any URL containing the path '..streams/admininstance/streamsScript..' it returns static text.   Anything on the URL following 'streamsScirpt' is ignored so does not change what is returned.

    If your scan tool allows, you can configure it to  ignore URLs with this path or to accept the static text as an acceptable response to the requests.  This will allow for clean and accurate security scans.

    Note that this behavior may change in a future release.
     

  • Stan
    Stan
    76 Posts

    Re: New serious security hole(s) in v3.1?

    ‏2013-06-27T03:19:07Z  

    I reviewed the documents you provided from your security scan and have determined the warning messages are all false positives, meaning they are not true security issues.

     Your scan returns these warnings because Streams returns static text rather than an http response code under the following circumstances.  When the streams console receives any URL containing the path '..streams/admininstance/streamsScript..' it returns static text.   Anything on the URL following 'streamsScirpt' is ignored so does not change what is returned.

    If your scan tool allows, you can configure it to  ignore URLs with this path or to accept the static text as an acceptable response to the requests.  This will allow for clean and accurate security scans.

    Note that this behavior may change in a future release.
     

  • Jim Sharpe
    Jim Sharpe
    98 Posts

    Re: New serious security hole(s) in v3.1?

    ‏2013-06-27T13:12:15Z  
    • Stan
    • ‏2013-06-27T03:19:07Z

    I reviewed the documents you provided from your security scan and have determined the warning messages are all false positives, meaning they are not true security issues.

     Your scan returns these warnings because Streams returns static text rather than an http response code under the following circumstances.  When the streams console receives any URL containing the path '..streams/admininstance/streamsScript..' it returns static text.   Anything on the URL following 'streamsScirpt' is ignored so does not change what is returned.

    If your scan tool allows, you can configure it to  ignore URLs with this path or to accept the static text as an acceptable response to the requests.  This will allow for clean and accurate security scans.

    Note that this behavior may change in a future release.
     

    Thank you for the prompt reply.  It was easy to validate this explanation through some simple tests with a browser and confirm that  the very long and scary looking list of reported vulnerabilities was indeed false positives.  We are still performing the tests, but so far after taking this into account it appears that v3.1 is not significantly different from previous versions in terms of security vulnerability.

    This behavior of returning static text for any URL containing that string does complicate security testing somewhat.  So as a feature request for future versions I would encourage you to consider returning a 404 or other appropriate error for file requests to things that do not exist.

  • Jim Sharpe
    Jim Sharpe
    98 Posts

    Re: New serious security hole(s) in v3.1?

    ‏2013-07-02T18:49:08Z  

    Thank you for the prompt reply.  It was easy to validate this explanation through some simple tests with a browser and confirm that  the very long and scary looking list of reported vulnerabilities was indeed false positives.  We are still performing the tests, but so far after taking this into account it appears that v3.1 is not significantly different from previous versions in terms of security vulnerability.

    This behavior of returning static text for any URL containing that string does complicate security testing somewhat.  So as a feature request for future versions I would encourage you to consider returning a 404 or other appropriate error for file requests to things that do not exist.

    I know it's bad form to reply to ones own post, but I have an update.  We have now completed the full security assessment of our v3.1 production installation and it passed squeaky clean.   The "trick" to eliminating all the false positive web vulnerabilities we were seeing above is to configure that  particular part of the evaluation to filter any URL strings containing the string described in Stan's message.  We believe this is a "safe" thing to do since the sws process will always return the same static text for any URL that contains that string thereby preventing any access to files referenced by the URL's we are not longer evaluating.