PCI Compliance - CVE-2015-4000

RouterOS General
1

When running a PCI compliance test against a Mikrotik CCR1009 (6.40.5 (stable)) I’m having trouble getting a passing result for CVE-2015-4000 (Logjam).

I’ve tried
/ip ssh set strong-crypto=yesbut still fail the CVE-2015-4000 test.

In a quest for more information I tried…

Using testssl.sh from https://github.com/drwetter/testssl.sh./testssl.sh --logjam x.x.x.x:50022
x.x.x.x:50022 doesn’t seem to be a TLS/SSL enabled server
The results might look ok but they could be nonsense. Really proceed ? (“yes” to continue) → yes
Service detected: Couldn’t determine what’s running on port 50022, assuming no HTTP service => skipping all HTTP checks

Testing for LOGJAM vulnerability
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected

I can’t get the commands found at https://tools.keycdn.com/logjam to work.
openssl s_client -connect x.x.x.x:50022 -cipher ‘EXP’
Error with command: “-cipher EXP”
140257917114008:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1380:

Honestly a bit lost troubleshooting this sort of thing. What are other ways I can test this? Any suggestions?

2

Hi n0muh,

what do you mean, it fails the compliance test? It says
“LOGJAM (CVE-2015-4000), experimental not vulnerable (OK)”
and further “no DH EXPORT ciphers, no DH key detected” - which looks good to me.
If you would like to use the out-dated EXPORT ciphers with openssl you would probably need an older version of it.

3

Well, what does not look good to me is this:

x.x.x.x:50022 doesn’t seem to be a TLS/SSL enabled server
The results might look ok but they could be nonsense.

So I wonder at first place whether the test attempts to follow the SSH startup procedure or only the TLS(SSL) one. If it cannot act as a proper SSH client, it is clear that it does not get to the DH type negotiation and reports no DH ciphers to be found at all, which is a true statement but you have to read it in conjunction with the other true statement, x.x.x.x:50022 doesn’t seem to be a TLS/SSL enabled server.

4

SSH does not use TLS/SSL, using testssl.sh with it will not work. Try https://tls.imirhil.fr/ssh

Results of RouterOS SSH server don’t look very promising, no strong ciphers, HMACs or host keys and plenty of bad ones. https://tls.imirhil.fr/ssh/demo.mt.lv:22

5

Thanks All for taking the time to respond.


I should have been clearer. My explanation was a little misleading, ./testssl.sh --logjam x.x.x.x:50022 isn’t the compliance test. I was just trying to use it to troubleshoot. The compliance test is not a public service.
https://imgur.com/a/5dO9stQ


These results also concerned me but from what R1CH has stated, SSH doesn’t use TLS/SSL. Wrong tool for the job I guess. Shows my lack of understanding.

R1CH, are there any linux shell tools that I can use to interrogate the Mikrotik’s ssh port and return this same information?

Is this a misconfiguration? Could someone from Mikrotik Support clarify if this device will pass the tests that are shown failing in the sceenshot? https://imgur.com/a/5dO9stQ

6

For command line scanning of DH parameters, give this a try: https://github.com/GDSSecurity/SSH-Weak-DH

For those curious, strong-crypto=yes enables 2048 bit DH parameters and disables 3des / md5 from ciphers / HMAC but dsa keys and sha1 remain enabled.

/ip ssh set strong-crypto=yes:

[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha1. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha1. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.

/ip ssh set strong-crypto=no:

[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[*] INTERMEDIATE (might be feasible to break for nation-states). Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 1024. Group size proposed by client in bits: min=1024, nbits=1024, max=1024.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha1. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[*] INTERMEDIATE (might be feasible to break for nation-states). Algorithm: diffie-hellman-group-exchange-sha1. Negotiated group size in bits: 1024. Group size proposed by client in bits: min=1024, nbits=1024, max=1024.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha1. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=8192, max=8192.
[*] INTERMEDIATE (might be feasible to break for nation-states). Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 1024. Group size proposed by client in bits: min=1024, nbits=1024, max=1024.
[+] STRONG. Algorithm: diffie-hellman-group-exchange-sha256. Negotiated group size in bits: 2048. Group size proposed by client in bits: min=2048, nbits=2048, max=2048.
[*] INTERMEDIATE (might be feasible to break for nation-states). Algorithm: diffie-hellman-group1-sha1. Negotiated group size in bits: 1024. Group size proposed by client in bits: min=1024, nbits=1024, max=1024.

Note this output is only about the DH parameters, cipher choices / HMACs are still weak compared to a modern SSH server.

7

I’m also failing a PCI compliance scan due to SSH having “Weak SSH Key Exchange Algorithms Supported” and “Weak SSH Hashing Algorithms Supported”. I’ve already enable strong encryption for SSH and recreated the ssh keys, but that hasn’t disabled SHA1 and the scan is still detecting that.

8

I can confirm that a PCI scan by a company popular in the USA will fail on ROS as recent as 6.40.8 with SSH strong-crypto set to ‘yes.’ Those same routers did pass maybe a year ago on an even earlier version of ROS but only after strong-crypto was set to ‘yes.’

The report indicates the SSH service supports weak modulus 1024-bit Oakley Group 2 DH (CVE-2015-4000). I thought strong-crypto addressed exactly that problem. The way I read the report it seems to me it still should.

Fortunately updating to 6.42.9 bugfix/long-term gets the PCI scan to pass the scan on SSH. So whatever the problem was it has been addressed.