What do the client random, the server random and the Finished messages contribute to the security of a TLS session?

The two randoms make every session's keys unique, so recorded traffic cannot be replayed into a new session. The Finished messages carry a MAC over the entire handshake, so any message an attacker altered or removed (for example to force a weaker cipher suite) makes the check fail.

Session keys. Both sides compute a master secret from the premaster secret and both randoms, then derive the encryption and MAC keys from it. Even if the same client talked to the same server twice with the same premaster, the keys would differ, because the server random is new each time. That is what stops the replay from the unprotected garage door: an attacker who recorded yesterday's encrypted "open" can send those bytes into a new connection, but they were encrypted under yesterday's keys and fail the integrity check. Within one connection, each record carries an implicit sequence number, so repeating or reordering records fails too.

Finished. Most of the handshake travels in plaintext, so an attacker could try to edit it, for example by removing the strong cipher suites from the ClientHello so both sides settle for a weak one (a downgrade attack). Each side's Finished message contains a value computed from the master secret over the hash of every handshake message it saw. If anything was changed in transit, the two sides saw different transcripts, the values do not match, and the connection is torn down. And because the value depends on the master secret, only someone who completed the key exchange can produce it.

Go deeper:

• The Illustrated TLS 1.2 Connection — the key calculation from both randoms and the Finished verify data, computed by hand.
• Wikipedia — Downgrade attack — how attackers force weaker protocol options, with real TLS examples.