Yesterday, Moxa published an advisory regarding multiple vulnerabilities in their MXSecurity product. Among the issues fixed in the updates the advisory talks about, is a vulnerability I discovered - CVE-2023-39982.
First, before I get into the details of the issue, lets talk about the disclosure process and the disclosure timeline, what Moxa did amazingly well, and how other vendors should learn from Moxa.
Contacting Moxa PSIRT was probably the most pain-free experience I have ever had as a vulnerability researcher. I simply went to the easily-found "Report a Vulnerability" web page, typed in some details, whacked enter, and away it went for triage by Moxa.
There was no nonsense about having to go through a specific vulnerability disclosure platform, the form is short - one page - and it took me less than five minutes to fill out.
Other vendors should learn from this - if you make vulnerability disclosure too painful or difficult, people will either not bother disclosing vulnerabilities to you, or they will just drop them as 0days. I have done, and will continue to do, both of these things if I can't find a frictionless path to coordinated disclosure. Be like Moxa. Make it easy for security researchers to help you.
Within three calendar days, Moxa PSIRT had responded to me, letting me know the issue was being looked at. I had reported the issue on a Friday - so the turnaround time was actually "next business day".
The day after that, they sent a followup asking for clarification/further information. We had some emails back and forth, we agreed quickly on impact/etc, and it went off to their engineers to validate internally.
Less than two weeks later - their engineering team had not only validated it, but also planned a fix, which would be deployed during the next release cycle, so we hashed out when it would be disclosed.
Again - I'd like to highlight - Moxa PSIRT were super responsive, and made this whole process absolutely painless. They actually were more responsive than me in this issue.
26-05-2023: Discovered, disclosed to Moxa.
29-05-2023: Moxa respond.
30-05-2023: Moxa request further information.
30-05-2023: Sent further information to Moxa.
30-05-2023: Moxa acknowledge reciept of further information.
12-06-2023: Moxa confirm that they have verified its a bug.
16-06-2023: Moxa confirm a CVE will be issued, discuss disclosure for sometime in August.
20-07-2023: Moxa email to confirm the advisory will be published end of August. My response gets stuck in my drafts folder due to some unknown reason.
1-09-2023: Moxa publish their advisory and email me letting me know the CVE-ID has been published, etc.
Now, lets talk technical details.
Description: On the Moxa MXSecurity appliance, versions 1.0.0 and 1.0.1 (both tested), the SSH host keys are hard-coded in the appliance image and not regenerated on first boot.
A network-adjacent or upstream attacker with a copy of the appliance can trivially extract these cryptographic secrets and reuse them to target other Moxa users appliances for man in the middle attacks and decryption of SSH traffic. This has an impact on the confidentiality and integrity of SSH communications to the device.
This is generally regarded as having a CVSSv3 score of 7.5, CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.
This can be remedied by having the appliances SSH daemon generate keys on first boot - which it will do if the SSH keys are not on the appliance, so by simply deleting the keys that were "baked in" as part of a patch release it will be fixed.
The key fingerprints are listed below.
256 MD5:ce:b0:a8:2b:39:3f:59:97:c8:b2:66:a8:c5:6a:12:38 ssh_host_ecdsa_key.pub (ECDSA) 256 MD5:f6:47:1d:36:f4:39:57:16:16:b1:dd:55:ef:46:5d:d5 ssh_host_ed25519_key.pub (ED25519) 2048 MD5:c8:a8:1c:20:b7:9d:a8:41:f7:84:7e:53:4e:b8:46:99 ssh_host_rsa_key.pub (RSA)
The keys themselves can be found in the following Github repository, which is currently private, but will be made public sometime in the future when I do some housekeeping on my Git repos.
As for how I found the keys - I had simply installed both versions of the appliance in VMWare, mounted the guests filesystem in another VM, and was looking around to try understand the appliance to look for vulnerabilities in the web interface. This is ongoing - not found anything fun yet in the web UI.
As part of my usual appliance auditing process, one of the things I look for is hard-coded cryptographic secrets, so naturally, I went looking in the
/etc/ssh directory, and found these keys, which were the same across both appliance versions.
I verified these keys were in use by reinstalling the appliance a few times and comparing the keys remotely and locally.
## testing on moxasecurity 1.0.0 vmdk $ ssh-keyscan 192.168.0.91 | ssh-keygen -E md5 -lf - # 192.168.0.91:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.91:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.91:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.91:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.91:22 SSH-2.0-OpenSSH_7.4 2048 MD5:c8:a8:1c:20:b7:9d:a8:41:f7:84:7e:53:4e:b8:46:99 192.168.0.91 (RSA) 256 MD5:ce:b0:a8:2b:39:3f:59:97:c8:b2:66:a8:c5:6a:12:38 192.168.0.91 (ECDSA) 256 MD5:f6:47:1d:36:f4:39:57:16:16:b1:dd:55:ef:46:5d:d5 192.168.0.91 (ED25519) ## testing on moxasecurity 1.0.1 vmdk $ ssh-keyscan 192.168.0.131 | ssh-keygen -E md5 -lf - # 192.168.0.131:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.131:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.131:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.131:22 SSH-2.0-OpenSSH_7.4 # 192.168.0.131:22 SSH-2.0-OpenSSH_7.4 2048 MD5:c8:a8:1c:20:b7:9d:a8:41:f7:84:7e:53:4e:b8:46:99 192.168.0.131 (RSA) 256 MD5:ce:b0:a8:2b:39:3f:59:97:c8:b2:66:a8:c5:6a:12:38 192.168.0.131 (ECDSA) 256 MD5:f6:47:1d:36:f4:39:57:16:16:b1:dd:55:ef:46:5d:d5 192.168.0.131 (ED25519) # ssh-keygen -E md5 -lf ssh_host_rsa_key 2048 MD5:c8:a8:1c:20:b7:9d:a8:41:f7:84:7e:53:4e:b8:46:99 ssh_host_rsa_key.pub (RSA) # ssh-keygen -E md5 -lf ssh_host_ecdsa_key 256 MD5:ce:b0:a8:2b:39:3f:59:97:c8:b2:66:a8:c5:6a:12:38 ssh_host_ecdsa_key.pub (ECDSA) # ssh-keygen -E md5 -lf ssh_host_ed25519_key 256 MD5:f6:47:1d:36:f4:39:57:16:16:b1:dd:55:ef:46:5d:d5 ssh_host_ed25519_key.pub (ED25519)
And that is it.
To fix this issue (and others, reported by other people), just upgrade your MXSecurity appliance to the latest supported version.
Again, I'd like to thank the PSIRT at Moxa for being super helpful and generally excellent to work with on this issue.