information can be captured, altered, and caused a denial of service (DoS)

[AnhVH7]

I found the issue report about the sercurity of the meshcentral's server. Short mean the information can be captured, altered, and caused a denial of service (DoS). Any one know that? Please help me rate whether the following security error is serious or not.

Below is the link to original post: https://jvndb.jvn.jp/ja/contents/2023/JVNDB-2023-025702.html

Describe the bug In the application's network request, the rejectUnauthorized attribute is set to false. This property is used to verify the server's certificate in HTTPS connections. Setting rejectUnauthorized to false can cause applications to bypass certificate

Use insecure TLS versions (such as SSLv3, TLSv1.0, and TLSv1.1) in your application. These TLS versions have known security vulnerabilities and weaknesses, exposing applications to potential security risks.

Use an insecure HMAC algorithm: HMAC-MD5, which is widely considered to be a less secure algorithm and is not recommended for continued use in a secure environment because it is susceptible to exhaustive searches and brute force attacks. Therefore, in practical applications, more secure algorithms such as HMAC-SHA1 should be used first.

Thank you.

[buckybytes]

This vulnerability report deals with SSL certificate based attacks. The way this works is basically:

You or your devices connect to the server using a fake DNS server. This can happen if the device is already compromised, or if it is connected to a network that is already compromised. That DNS server must have a record that points your meshcentral server's domain to an IP address controlled by the attacker. The attacker then has a meshcentral server running on the bad IP address.

At this point, the attacker can obtain limited information about the devices that attempt to connect (IP address, basically) to the relay service. They could also intercept credentials when someone logs into the server through the web Interface.

IF they get to this point successfully, they may be able to brute force a certificate to escalate to being able to successfully connect agents to the fake server, which would grant them control. Alternatively, if the already had access to your meshcentral-data folder, they wouldn't need to find a vulnerability in the certificate.

I have a feeling that the only real resolution on this would be to require every server to have valid, CA signed certificates, and disallow any use of self-signed certificates. This would be a "bad thing" for what I would imagine to be a pretty large portion of the installations out there.

Until then, you can mostly mitigate this attack vector by:

Disallowing logging in from the Internet side of the server. Enable 2FA / OAuth2 for login Set static DNS servers on your agent devices

It might even complicate things for the attacker further if you use a CA signed certificate as opposed to a self-signed certificate. It is probably a good idea to monitor any certificates issued for your domains as well using a service like this:

https://developers.facebook.com/tools/ct/search/

I've started doing this for many of my sites, and have found it helpful in detecting Phishing attacks on my sites with publicly available certificates. (Let's encrypt / Whatever google service caddy uses) It's also saved me some debugging time when I accidentally deploy a server, or one that get's lost in the shuffle.

Maybe someone with more knowledge of how these situations are handled in the code would be able to provide an answer more specific to meshcentral, but this is my current strategy based on my assumptions.

[inzi]

If you have a valid DNS name for your mesh server, you can use letsencrypt and script renewal of a wildcard certificate and use that, depending if you're domain is registered with a provider that is supported (like namecheap or godaddy).

You can use that signed cert for MC or your front end.

Local network considerations will have to be taken into account.

[buckybytes]

@inzi

Maybe I'm reading it wrong, but I believe this issue involves MC not verifying if a certificate is valid. Using a valid certificate wouldn't change anything if it isn't being verified.

Also, I'm curious what you mean by "local network considerations" in your post. How does the SSL cert affect configuration depending on the local network? The network local to the server, user, or agents?

[krayon007]

I'm sure Ylian will correct me if I'm wrong, but a few things... Looking at the original post, this is specifically talking about the MPS server, which is dealing with CIRA connections with AMT. Also, with AMT, you have to explicitly push the certificates into the firmware, and no CA is involved. In this case, setting rejectunAuthorized to true, wouldn't fix anything, becuase the cert is not rooted in anything that NodeJS trusts... Further, when we set this to false, it was because we explicitly checked the certificates during the TLS handshake. There's a couple options you can set, so that you can force the client to give you it's certificate, then you can query the certificate and check to make sure it is what you expected. Likewise on the client side, you can set a function pointer to call you when the server gives you its cert, so you can check it the same way... I quickly browsed the mps code in question, and it looks like it does exactly that.

[buckybytes]

I figured it would be something like that.

It looks like the github account referenced @tianjk99 in the CVE might have just been some automated process attempt at finding issues. It was only briefly active, and it only has the one repository with CVE info.

[Ylianst]

Hi. So, this reported issue is super vague and so, it's going to be difficult to figure out exactly what the problem is.

By default, MeshCentral generates a self-signed TLS certificate that users generally replace with a trusted certificate (Let's Encrypt) once the server goes into production. So, it's fully expected to start out with an unverified certificate. In production that will not be the case.

For TLS1.0 and 1.1, this is likely the Intel AMT MPS port (Default 4433). This port by default will accept connections from older AMT devices that do not support TLS 1.2 and TLS 1.3. You can turn off this adding:

"mpshighsecurity": true

In the settings section of the config.json. This will cause port 4433 to only accept TLS 1.2 and TLS 1.3. Intel should get such a security posting for not updating older AMT to TLS 1.2 using a firmware update. Right now, they just tell people to change the entire computer which is not acceptable in my view and not taking security seriously.

For HMAC-MD5, this is really dumb. HMAC-MD5 is used for HTTP Digest and it is not vulnerable to brute force attacks. Yes, HMAC-SHA256 for HTTP digest would be nice, but really completely not necessary once you understand how Digest works. However, people just do dumb security scans in the code, see things and flag them without any understanding of the use. Both AMT and most browsers only support HTTP Digest with HMAC-MD5 and unless that changes, it's not possible to use something else. Again, from a security perspective, this is totally fine, no need to update and so, no one does, and yes, you end up with these false alerts.

[Ylianst]

By the way if there is a specific attack vector that anyone finds. I do take security seriously with MeshCentral. Email me right away, my email is with this GitHub account, you can also use my PGP key here if needed.

My view of the reported issue above is that they auto-scanned the MeshCentral code and fond "TLS1.0", "HMAC-MD5" and "rejectUnauthorized : false" and auto-created this issue. It's not a good way to do security scans.

I will note that, if you are an administrator of a MeshCentral server, please take the time to security setup your server. Put a real TLS cert, enable forced 2FA on users, disable the MPS port if you don't need it, put MeshCentral behind a reverse proxy, etc. The more assets you have to protect, the more care should be taken to secure your server. MeshCentral can't do security for you.