Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
gcedillo_dns Absent Member.
Absent Member.
1577 views

Java SSL KeyStore Password Disclosure Vulnerability

Hi

In a vulnerability scan on sentinel, he showed the vulnerability "Java SSL KeyStore Password Disclosure Vulnerability"

Is there any remediation for this vulnerability?

Thanks Regards
0 Likes
7 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Java SSL KeyStore Password Disclosure Vulnerability

Do you have some kind of reference to the perceived vulnerability, and the
implications of it, so it can be correlated to something more commonly
known through the industry? Ideally having a CVE number would be helpful
since that is the standard for known vulnerabilities.

It would also help to know more about your Sentinel system, at least the
version, SP, other patches, etc.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
gcedillo_dns Absent Member.
Absent Member.

Re: Java SSL KeyStore Password Disclosure Vulnerability

Hi

this is the explanation of the vulnerability.

" Customers using SSL are advised not to pass passwords on the command line as they are visible to any local user. Additionally, process information along with its arguments is usually sent to logging services such as Splunk.
Execute following commands to check if the system is vulnerable. One of these commands would show the password in its output which confirms that the system is vulnerable:
a. ps -ef | grep 'javax.net.ssl.keyStorePassword'
b. ps -ef | grep 'javax.net.ssl.trustStorePassword'
c. ps -ef | grep 'ssl.keyStorePassword' Please move the SSL management options to a properties file, if a password has been set for either of these:
1. Create the SSL properties file:
a. echo javax.net.ssl.keyStore=/path/to/your/keystore/file > ssl.properties
b. echo javax.net.ssl.keyStorePassword=serverStorePassword >> ssl.properties
c. echo javax.net.ssl.trustStore=/path/to/your/truststore/file >> ssl.properties
d. echo javax.net.ssl.trustStorePassword=serverTrustPassword >> ssl.properties
2. Set the file access rights to read-only:
chmod 400 ssl.properties
3. Add the following command line option to the JMX RMI instance (or the corresponding ssl option name for other software instance):
-Dcom.sun.management.jmxremote.ssl.config.file=/path/to/ssl.properties
4. Ensure that 'javax.net.ssl.keyStorePassword' and 'javax.net.ssl.trustStorePassword' options are removed from the command line.
5. Restart the service with the new options and verify that the changes have been applied properly. Workaround: Customers are advised to use the System.setProperty or similar code uses to set credentials in their projects. Please refer the following document to configure system properties (https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.htmlgdevf)."
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Java SSL KeyStore Password Disclosure Vulnerability

On 02/27/2019 01:34 AM, gcedillo dns wrote:
>
> this is the explanation of the vulnerability.
>
> " Customers using SSL are advised not to pass passwords on the command
> line as they are visible to any local user. Additionally, process
> information along with its arguments is usually sent to logging services
> such as Splunk.
> Execute following commands to check if the system is vulnerable. One of
> these commands would show the password in its output which confirms that
> the system is vulnerable:
> a. ps -ef | grep 'javax.net.ssl.keyStorePassword'
> b. ps -ef | grep 'javax.net.ssl.trustStorePassword'


This one is invalid; a truststore is, by definition, public information
(it holds certificate, which are the wrappers around public keys in
public/private keypairs). The default password is 'changeit', and
changing it doesn't improve security since nothing inside is (or should
be) secret. I'm sure there are a lot of hits because of this, but they're
bogus.

> c. ps -ef | grep 'ssl.keyStorePassword' Please move the SSL management
> options to a properties file, if a password has been set for either of
> these:
> 1. Create the SSL properties file:
> a. echo javax.net.ssl.keyStore=/path/to/your/keystore/file >
> ssl.properties
> b. echo javax.net.ssl.keyStorePassword=serverStorePassword >>
> ssl.properties
> c. echo javax.net.ssl.trustStore=/path/to/your/truststore/file >>
> ssl.properties
> d. echo javax.net.ssl.trustStorePassword=serverTrustPassword >>
> ssl.properties


Truststore stuff again.

> 2. Set the file access rights to read-only:
> chmod 400 ssl.properties
> 3. Add the following command line option to the JMX RMI instance (or the
> corresponding ssl option name for other software instance):
> -Dcom.sun.management.jmxremote.ssl.config.file=/path/to/ssl.properties


Or better yet, don't allow remote connections at all.

> 4. Ensure that 'javax.net.ssl.keyStorePassword' and
> 'javax.net.ssl.trustStorePassword' options are removed from the command
> line.
> 5. Restart the service with the new options and verify that the changes
> have been applied properly. Workaround: Customers are advised to use
> the System.setProperty or similar code uses to set credentials in their
> projects. Please refer the following document to configure system
> properties
> (https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.htmlgdevf)."


Out of all these, which ones matched on your Sentinel system? Could you
show the output, please?

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Java SSL KeyStore Password Disclosure Vulnerability

> This one is invalid; a truststore is, by definition, public information
> (it holds certificate, which are the wrappers around public keys in
> public/private keypairs). The default password is 'changeit', and
> changing it doesn't improve security since nothing inside is (or should
> be) secret. I'm sure there are a lot of hits because of this, but they're
> bogus.


But you can store the private key in the truststore, and the public info
is visible with just the keystore password, but the private key has a
second password, which might also be visibile in this manner?



>> c. ps -ef | grep 'ssl.keyStorePassword' Please move the SSL management
>> options to a properties file, if a password has been set for either of
>> these:
>> 1. Create the SSL properties file:
>> a. echo javax.net.ssl.keyStore=/path/to/your/keystore/file >
>> ssl.properties
>> b. echo javax.net.ssl.keyStorePassword=serverStorePassword >>
>> ssl.properties
>> c. echo javax.net.ssl.trustStore=/path/to/your/truststore/file >>
>> ssl.properties
>> d. echo javax.net.ssl.trustStorePassword=serverTrustPassword >>
>> ssl.properties

>
> Truststore stuff again.
>
>> 2. Set the file access rights to read-only:
>> chmod 400 ssl.properties
>> 3. Add the following command line option to the JMX RMI instance (or the
>> corresponding ssl option name for other software instance):
>> -Dcom.sun.management.jmxremote.ssl.config.file=/path/to/ssl.properties

>
> Or better yet, don't allow remote connections at all.
>
>> 4. Ensure that 'javax.net.ssl.keyStorePassword' and
>> 'javax.net.ssl.trustStorePassword' options are removed from the command
>> line.
>> 5. Restart the service with the new options and verify that the changes
>> have been applied properly. Workaround: Customers are advised to use
>> the System.setProperty or similar code uses to set credentials in their
>> projects. Please refer the following document to configure system
>> properties
>> (https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.htmlgdevf)."

>
> Out of all these, which ones matched on your Sentinel system? Could you
> show the output, please?
>


0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Java SSL KeyStore Password Disclosure Vulnerability

On 02/27/2019 09:23 AM, Geoffrey Carman wrote:
>> This one is invalid; a truststore is, by definition, public information
>> (it holds certificate, which are the wrappers around public keys in
>> public/private keypairs). The default password is 'changeit', and
>> changing it doesn't improve security since nothing inside is (or should
>> be) secret. I'm sure there are a lot of hits because of this, but they're
>> bogus.

>
> But you can store the private key in the truststore, and the public info
> is visible with just the keystore password, but the private key has a
> second password, which might also be visibile in this manner?


Fair enough, but then by definition it is no longer a truststore, but now
it is a keystore (meaning it holds at least one private key). If that is
being done out of the box, that's a bug. I just mean that if a true
truststore's password is shown, that's about as insecure as Google's
homepage being public (not insecure, and in fact that's the desired way to
do things).

Truststores and Keystores are the same types of objects, but one holds
public data only, and the other holds private keys. The public or private
key details, in either case, require the correct passphrase I believe, but
since a truststore is meant to be public the password is usually
well-known ('changeit') where a keystore will sometimes, as you mentioned,
have a second password (or so I've heard; I've only seen that done once).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Java SSL KeyStore Password Disclosure Vulnerability


> Truststores and Keystores are the same types of objects, but one holds
> public data only, and the other holds private keys. The public or private
> key details, in either case, require the correct passphrase I believe, but
> since a truststore is meant to be public the password is usually
> well-known ('changeit') where a keystore will sometimes, as you mentioned,
> have a second password (or so I've heard; I've only seen that done once).


And how many keystores can dancec on the head of a truststore in your view?

This seems like a semantic arguement, and therefore, I agree. Since
semantically you are correct.


0 Likes
Senthil D
Visitor.

Re: Java SSL KeyStore Password Disclosure Vulnerability

is anyone able to rad the password from ssl.properties. i tried the given steps it doesnt seems to be working.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.