Nessus Scan Vulnerability Remediation - Need Assistance

[Manish Parikh]

My prod MoM (EM) server has come under a Nessus scan vulnerability that needs immediate remediation. I've opened up a case but not getting anywhere. So reaching out to the community. Surprisingly my DEV Env MoM (EM) is identical to Prod MoM yet that server didn't get hit with that vulnerability.

 

Since this is security hit for my org, it needs to be resolved ASAP or it could affect "athority to operate" for APM altogether.

 

Thanks in advance for any/all help with this issue.

 

Here are the details of the vulnerability:

 

35291 - SSL Certificate Signed Using Weak Hashing Algorithm

Synopsis

An SSL certificate in the certificate chain has been signed using a weak hash algorithm.

Description

The remote service uses an SSL certificate chain that has been signed using a cryptographically weak hashing algorithm (e.g. MD2, MD4, MD5, or SHA1). These signature algorithms are known to be vulnerable to collision attacks. An attacker can exploit this to generate another certificate with the same digital signature, allowing an attacker to masquerade as the affected service.

Note that this plugin reports all SSL certificate chains signed with SHA-1 that expire after January 1, 2017 as vulnerable. This is in accordance with Google's gradual sunsetting of the SHA-1 cryptographic hash algorithm.

Note that certificates in the chain that are contained in the Nessus CA database (known_CA.inc) have been ignored.

See Also

https://tools.ietf.org/html/rfc3279

http://www.nessus.org/u?e120eea1

http://technet.microsoft.com/en-us/security/advisory/961509

Solution

Contact the Certificate Authority to have the certificate reissued.

Risk Factor

Medium

CVSS Base Score

4.0 (CVSS2#AV:N/AC:H/Au:N/C:P/I:P/A:N)

CVSS Temporal Score

3.5 (CVSS2#E:ND/RL:OF/RC:C)

References

BID	11849
BID	33065
CVE	CVE-2004-2761
XREF	OSVDB:45106
XREF	OSVDB:45108
XREF	OSVDB:45127
XREF	CERT:836068
XREF	CWE:310

Plugin Information:

Publication date: 2009/01/05, Modification date: 2017/06/12

Ports

tcp/5443

The following certificates were part of the certificate chain sent by
the remote host, but contain hashes that are considered to be weak.

|-Subject : C=US/ST=New York/L=Islandia/O=CA technologies Inc/OU=CA APM/CN=ca.com
|-Signature Algorithm : MD5 With RSA Encryption
|-Valid From : Nov 26 06:16:57 2013 GMT
|-Valid To : Jul 16 06:16:57 2035 GMT

---------------------------------------------------------------------------------------------------------------------------------------------------

In prod environment, I use APM Workstation which uses port 5443 to access the UI. I do the exact same for the Dev env but doesn't seem to flag that at all

 

 

[Haruhiko Davis]

Why replace the certs with your own?

[Manish Parikh]

Well, if I don't then I still need to perform remediation of this vulnerability.

[Haruhiko Davis]

Sorry, meant to say why *not*

[Manish Parikh]

I do want to use our own but doesn't look like it's working. That's why I have a case open for this.

[Haruhiko Davis]

https://docops.ca.com/ca-apm/10-5/en/administrating/configure-enterprise-manager/configure-enterprise-manager-communications

[Haruhiko Davis]

https://communities.ca.com/blogs/hdavis/2017/06/07/ca-apm-updating-jetty-with-your-own-keystore-password

[Hallett German]

Converting to a discussion since it is a specialized issue  . A quick resolution might be addressed by a case. 

[Manish Parikh]

Already have a case open but doing this in parallel to speed up the process.

[Haruhiko Davis]

Can you confirm which the items you changed to make APM use your certs?

When you run Java keytool, can you view your certs in your keystore and truststore?

What piece of APM specifically is it complaining about?

[Manish Parikh]

I ran the following script that was provided by CA Services. 

   

   #! /bin/sh

   # Set to path of keytool (in EM jre)

   KEYTOOL="/apps/CA/Introscope9.5.3/jre/bin/keytool"

   # combine .key and .cer, plus BAE CA certificate into a single .pkcs12 file

   openssl pkcs12 -export -inkey $1.key -out $1.pkcs12 -in $1.cer -certfile BAE-Root.cer -passin pass:password -passout    pass:password

   # import pkcs12 file into the keystore. It uses the first ocmponent of the pathname as the alias

   $KEYTOOL -importkeystore -srckeystore $1.pkcs12 -alias 1 -srcstoretype PKCS12 -srcstorepass password     - destkeystore keystore -deststoretype JKS -deststorepass password -destalias ${1%%.*}

   # list the entries in the keystore

   $KEYTOOL -list -keystore keystore -storepass password

 

This works for cert updating for WebView (port 8443) and CEM GUI (port 8444) but this didn't work for APM Workstation that uses port 5443

[Haruhiko Davis]

Did I give you that?

Did you also go into your EM properties file and configure it to use the keystore and trustore?

Did you import your root and intermediary certs into the default or create a new truststore?

[Manish Parikh]

Did I give you that?

   -No, it was provided to me by Paul Barnnett

Did you also go into your EM properties file and configure it to use the keystore and trustore?

   -Yes

   introscope.enterprisemanager.keystore.channel2=internal/server/keystore

   introscope.enterprisemanager.port.channel2=5443

Did you import your root and intermediary certs into the default or create a new truststore?

   -import into the default truststore

   BAESystems-Inc-Root-Base64.cer

If you want I can do a quick WebEx with you and show you everything I've done

[Haruhiko Davis]

Where is your truststore located? Did you update your startup parameters to point to the truststore and its password?

https://docs.oracle.com/cd/E29585_01/PlatformServices.61x/security/src/csec_ssl_jsp_start_server.html

[Haruhiko Davis]

Instead of importing to the existing keystore, have you tried generating a new one and pointing to it?

[Manish Parikh]

No, I have not tried generating a new one and pointing to it. I am not very familiar with this entire keystore and/or truststore thing. Hence I've opened the CA Support case

 

I don't mind getting walked-through the process via a WebEx using the CA support case if you want to do that.

[Haruhiko Davis]

Yeah; let me know. Will have time tomorrow if that's the case.

I'm also looking at whether this is being caused by the EM public and private keys.

But if it's just the default cert in the keystore, then maybe it'll be easier to just generate a new keystore and place your cert in it.

[Manish Parikh]

Hiko_Davis I am available today or tomorrow. I'll email you.

[Manish Parikh]

So, I've fixed the problem - thanks to Hiko_Davis

 

Apparently the keystore had 2 aliases listed one of which was the original CA cert:

 

[caadmin@xxxxxxxxxxx server]$ keytool -list -keystore keystore -storepass *********

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

server, Nov 26, 2013, PrivateKeyEntry,
Certificate fingerprint (SHA1): XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
cemprod, Dec 8, 2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

 

As you can see there are 2 aliases "server" and "cemprod". On the other MoM in my Dev environment, that keystore only has one alias "cemdev"

 

So, I removed the "server" alias using the following command:

[caadmin@************ server]$ keytool -delete -alias server -keystore keystore -storepass **********

 

Once you have performed that above please ensure to restart the EM/MoM where you made that change.

 

I think this would make a great KB article for customers out there.

 

Please ensure that a doc is written about it (to check for keystore entries and analyse those entries and how to fix it by removing it)

 

Hallett_German - please make this response as "correct answer/solution".

[Haruhiko Davis]

Don't forget this change requires a restart of the EM.

[Manish Parikh]

I corrected it above in my reply.

[Hallett German]

Manish. Since I converted this to a discussion as noted earlier , there is no correct answer available  . I did mark that response as a success, 

[Manish Parikh]

Hallett_German is it possible for you to convert it back to a question then my response/explanation to be the "Correct Answer"?