How likely it is that a (MySQL) client leaks credentials when VPN tunnel was not set previously?

Question

Context

I work on a very common case. I configured two servers: an OpenVPN and a MySQL (172.16.X.X) server hidden behind it. Let’s assume everything is perfectly configured and patched server side.

Note:

• MySQL server has no public network interface
• MySQL has no TLS configured. It does not use PAM authentication via PAM plugin. It accepts authentications from anywhere.
• It uses a NAT to access the internet (NAT is done by OpenVPN server).
• OpenVPN pushes its routes (172.16.X.X) allowing connected clients to find the MySQL server.

On the client side (192.168.X.X), I have several users who will connect to MySQL server through the VPN, using their own local OpenVPN client. With the previous assumption, unless I’m a fool (which is a possibility, you tell me), no MITM attacker would be able to get the MySQL password.

Note:

• Clients have no pre-configured route for the distant VPN network (172.16.X.X).

Probable scenario

Let’s imagine: as a user, I try to connect this MySQL “hidden” server and it fails, because ooops… my openVPN software failed to start the tunnel without notice.

Now a malicious machine can be somewhere in the local network - people uses laptops anywhere these days - sniffing my miserable attempt to connect to a non-existing MySQL (172.16.X.X) server.

Questions

Will any MySQL client software send cleartext credentials to the default route, even if no MySQL server is found?

Is it possible for an attacker who knows the genuine MySQL server (172.16.X.X) exists to impersonate it by setting up a rogue MySQL server on the local network (192.168.X.X)?

If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Thank you for your help!

Answer 1

To answer this question you must first understand the mysql-na handshake through to authentication.

If you are using default username & password authentication where the password is stored as sha1(sha1(password) hash in mysql.users then authentication works as follows (there's more steps but to keep this brief it's roughly the following):

1. Client connects to server
2. Server sends greeting, version and the supported capabilities of the server as well as a SALT to be used for the session
3. Client requests authentication to begin, then sends SHA1(password) XOR(SALT + sha1(sha1(passsword)))

So first off credentials are not sent in the clear using this method, they are however if you use mysql_pam plugin as these are passed to PAM for authentication completion.

However using mysql-na you must be aware that and if an adversary can sniff a successful client-server auth handshake, then they can use the mysql-unsha vulnerability (https://github.com/cyrus-and/mysql-unsha1) to gain access without knowing the actual password.

With this clarified let's address you questions specifically

• Will any MySQL client software send cleartext credentials to the default route?

This depends entirely on your mysql configuration if you are using PAM to authenticate then it is likely you will see credentials "on the wire", to be 100% on this it's worth running a packet capture on the server and inspecting the resulting pcap with wireshark / tshark.

• If the network exists in my routing table?

As per above, depends on your MySQL configuration by default you should not see credentials in cleartext but this does not prevent attackers gaining access via mysql-unsha.

• If the IP I try to reach exists locally?

Please clarify are you speaking about your VPN client machine LAN ? this depends on your routes and whether the VPN allows split-tunneling.

• If the IP I try to reach exists locally and runs a MySQL server?

Again this needs to be clarified it's far too vague.

• If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Your questions need to be made clear, first and foremost so that you can communicate them out to third parties clearly and consistently, the take aways here for you are.

Under default configuration MySQL will use Mysql-NA for authentication which is username + password, this is not in the clear as only hashes are exchanges HOWEVER this is vulnerable to the mysql-unsha attack as outlined above which could allow an attacker to authenticate as a user which they have observed authenticating without knowing the original password only the sha1(password) hash.

Answer 2

MySQL is using a protocol on top of TCP for connections between remote systems. This means that a TCP connection need to be created successfully before any data gets transferred, which includes sending authentication information.

This means that under the assumption that the database is only reachable by VPN and that no one can impersonate the database no credentials will be leaked this way.

But if it is unknown if this assumption is true in your network. If it is not true then credentials might be leaked. The risk of this can not be estimated without knowing more about your network setup and security measures and also how attractive you are a a target, i.e. how much an attacker will invest. But, you can reduce the risk for example connecting to the database with TLS additionally to using a VPN.

Answer 3

It's very unlikely, but in some very difficult cases someone can get your credentials. Possible, but improbable.

1. Attacker assumes control of your gateway

   By controlling the gateway, he can intercept any connection attempt and modify them.

2. Your tunnel fails and you try to connect

   Attacker now can know you have an MySQL server somewhere, an can add a routing entry on the gateway pointing to a server he controls, using the same IP.

3. Attacker sniffs your password

   IF you try to connect again, AND the VPN is off, AND the attacker sniffed the last try, AND the attacker have a routing entry on the gateway poiting to a server he controls, AND he is running a sniffer, then he can get your credentials.

Very unlikely, will take a lot of preparation, depends on luck (or lack of), requires gateway control, but possible.