You are actually asking two questions here. One is about censorship resistance (can somebody block the bootstrapping process?) and the other about authentication (can a bad person pretend to be a Tor relay?). Here are answers to both questions:

1. Censorship resistance: Yes, a nasty network administrator can indeed block the bootstrapping connections which download the network consensus from the directory authorities. In fact, this is done by the Great Firewall of China. (Part of) The solution to this problem are bridges. Bridges are basically unpublished Tor relays which no longer have this single point of failure.
2. Authentication: As you write, the Tor source code includes a hard-coded list of the directory authorities' IP addresses as well as their cryptographic key fingerprints. This is the trust anchor. After your Tor client fetched the network consensus which contains all Tor relays, it verifies that it is authentic by checking the signature over the consensus. Nobody can give you a manipulated consensus because your client already knows the authorities' keys. The consensus then contains the key fingerprints of all Tor relays which makes it very hard to "man-in-the-middle" such a connection. Of course, this assumes that you got your copy of Tor over a secure channel. In practice, you probably downloaded it over HTTPS from https://www.torproject.org and checked the PGP signature. Unfortunately, secure software distribution is a difficult problem.

You are actually asking two questions here. One is about censorship resistance (can somebody block the bootstrapping process?) and the other about authentication (can a bad person pretend to be a Tor relay?). Here are answers to both questions:

1. Censorship resistance: Yes, a nasty network administrator can indeed block the bootstrapping connections which download the network consensus from the directory authorities. In fact, this is done by the Great Firewall of China. (Part of) The solution to this problem are bridges. Bridges are basically unpublished Tor relays which no longer have this single point of failure. Additional information can be found under point 'h' here.
2. Authentication: As you write, the Tor source code includes a hard-coded list of the directory authorities' IP addresses as well as their cryptographic key fingerprints. This is the trust anchor. After your Tor client fetched the network consensus which contains all Tor relays, it verifies that it is authentic by checking the signature over the consensus. Nobody can give you a manipulated consensus because your client already knows the authorities' keys. The consensus then contains the key fingerprints of all Tor relays which makes it very hard to "man-in-the-middle" such a connection. Of course, this assumes that you got your copy of Tor over a secure channel. In practice, you probably downloaded it over HTTPS from https://www.torproject.org and checked the PGP signature. Unfortunately, secure software distribution is a difficult problem. Additional information is available here.