As indicated in the comments below the question, RSA is commonly not used as modular exponentiation of a symmetric key. Instead, either the key is encrypted using PKCS#1 v1.5 padding or - preferably - OAEP, or a shared secret with a randomized value in the range $\big[0, N\big)$ is used for the modular exponentiation. In the latter case an actual key is derived using a KDF (key derivation function), sometimes also simply called a "PRF" (see e.g. TLS 1.2). This is known as RSA-KEM.
There are basically two ways that tampering of the key through a man-in-the-middle (MitM) attack can be avoided:
- establishing trust in the RSA public key;
- verification of the shared secret and/or derived keys.
If you pre-share and trust a public key of a static key pair then you'd have a static key exchange, i.e. the public key is trusted, but you would not provide forward security. That means that every subsequent symmetric key can be calculated if the private key is known by the adversary.
The trust of the public key can be established in different ways. For a static key pair the public key could be trusted using PKI. If you need to trust an ephemeral public key the receiver could sign it with a private key which is part of a key pair that is trusted.
Another way is to verify the established session key afterwards. That can be done either explicitly or implicitly.
In explicit verification of the shared secret the party that decrypted the key uses it to generate a MAC over static data known by both parties and sends the MAC. That party can now be sure that the right symmetric key has been established.
In implicit verification the key is simply used to send authenticated messages back and forth. The verification of the authentication of these packages indicates that the right key has been established.
Of course, only the party of which the public key is trusted is authenticated. Similarly, if any MAC is verified, then that only shows that the party holding the private key has been able to decrypt. So if you need authentication of the remaining party then that needs to be handled separately.
In TLS this is performed by simply having the other party create a signature that can be verified. This also requires that the public key of that key pair is trusted in advance; in the end you need to always establish trust in something before you can authenticate the party.
TLS client authentication is hardly ever used. Instead it is replaced by authentication frameworks or password based authentication. Or the identity of the client is never established at all - until a purchase is made anyway.
Note that authentication of keys established using RSA key establishment is not different from establishing keys with, for instance, Diffie-Hellman - although with the latter there are two key pairs to consider. In the end, the same kind of techniques can be used.
