Video Screencast Help
Search Video Help Close Back
to help
Not able to make it to Vision this year? Get a sampling in the Best of Vision on Demand group.

SSH and Apache Tomcat

Created: 28 Oct 2010 | 5 comments
Prashant Thumar's picture
0 0 Votes
Login to vote

 

Hello,

How can I find which version of Apache Tomcat and SSH Protocol used by SBG 9.0.1??

Is there any procedure to update SSH and Tomcat to the latest version??

 

Thanks for the updates...

Comments

Ian McShane's picture
28
Oct
2010
0 Votes 0
Login to vote

No.

Hi there,

The update of core components are handled as part of the SBG release process.  There is no mechanism for them to be upgraded out of band.

Is there a specific reason why you want to be able to upgrade SSH or tomcat?

 

//ian

Prashant Thumar's picture
28
Oct
2010
0 Votes 0
Login to vote

Vulnerable components

Hi Ian,

 

Thanks for your reply..

One of our customers have run some Vulnarability assesment in their network and found this 2 vulnerable components in SBG and they want to patch this components.

 

Regards,

Prashant Thumar

John_H's picture
28
Oct
2010
1 Vote +1
Login to vote

More information

Prashant,

 

    Can you tell us specifically whaqt vulnerable components were found and what analysis software is being used.  Also can you tell me the last time that software was update.  I only ask because I have had several instances in the past where the vulnerability assessment software had not been updated and was giving false positives.

 

-John

Prashant Thumar's picture
28
Oct
2010
0 Votes 0
Login to vote

More Information (Detail)

Hi John,

Find the below result of vulnerability scanner.. Customer have used Nessus Vulnerability Scanner (latest Version).

 

1.1.1 Insecure cryptographic protocol – Old version SSH protocol

Abstract

Aujas identified that the remote service offers an insecure cryptographic protocol. The remote SSH daemon supports connections made using the version 1.99.

These protocols are not completely cryptographically safe so they should not be used.

Severity

Medium

Complexity

Hard

From

Remote

Impact

An attacker may use this flaw to sniff the traffic over the network to get the sensitive information since protocol offers an insecure cryptographic protocol.

Affected IP(s)

172.16.27.58

Recommendation

It is recommended to Disable compatibility with version 1 of the protocol & use higher version SSH protocol.

POC

As depicted below

References

 -

 

 

1.1.2 Apache Tomcat Transfer-Encoding Header Vulnerability

Abstract

The remote Apache Tomcat service is vulnerable to information disclosure or a denial of service attack due to a mishandling of invalid values for the 'Transfer-Encoding' HTTP header as sent by a client.

Severity

Medium

Complexity

Hard

From

Remote

Impact

An attacker may use this flaw to gather information about the remote host and possible launch denial of service attack.

Affected IP(s)

 

172.16.27.58

Recommendation

It is recommended to Upgrade to version 5.5.30 / 6.0.28 or greater.

POC

-

References

 -

 

Regards,

Prashant Thumar

Ian McShane's picture
28
Oct
2010
0 Votes 0
Login to vote

Hi, No problems. It is an

Hi,

No problems.

It is an unfortunate, but true fact, that a number of the available vulnerability reporting tools merely query product/component versions and generate exceptions based on this data, rather than actually performing any tests to verify whether the vulnerability exists.

 

For example, there was a vulnerability announced earlier this year I think for OpenSSH regarding a buffer overflow vulnerability.  As long as SBG is deployed and managed in the documented and supported ways (i.e you MUST NOT perform any modification to the included components or configuration outside of the UI or managed CLI functions) then it was not possible for the vulnerability to be exploited on SBG - despite vulnerability tools saying it was.  Of course, this version of openSSH was patched as part of our engineering process anyway but it was not an exposed vulnerability on our platform.

Of course, any vulnerabilities that are exposed are triaged and fixed with extremely high priority but to my knowledge, again due to the secure implementation methods we have engineered into SBG, this has never occurred.

If you have specific queries regarding vulnerabilities, you can contact support for more indepth information regarding why SBG is not affected.

 

Hope that helps.

 

//ian