The ANonce that is sent in the first message is indeed not protected. It is randomly chosen by the AP, and is sent in clear-text.
The MIC in the second message only protects the SNonce, and thus cannot be used to verify the ANonce. However, upon receipt of the SNonce, the AP will calculate the PTK, based on:
- the ANonce it generated randomly in the first step
- the SNonce that it received from the supplicant (which has not been validated yet, as the MIC can only be validated with a valid PTK)
The AP then has calculated the PTK, and can easily verify the MIC, and thus the SNonce. However, if the MIC checks out, it follows that the ANonce probably has not been spoofed, otherwise the PTK calculated by the AP would be different from the PTK calculated by the supplicant (as they used a different ANonce), and the MIC would not check out.
The standard states (of course), that in case the MIC does not check out, the message must be discarded. So, whereas an adversary CAN modify the ANonce, it will lead to a unsuccessful handshake.
Moreover, as an extra defense, the ANonce is again sent in an EAPOL-Keyframe in the 3rd message of the handshake (see image below). The recipient MUST verify that the ANonce in this protected EAPOL-Keyframe is the same as the ANonce that was sent in message 1. Simply said, message 1 is repeated here, but now with a MIC to protect the ANonce, just like you suggested it should be done, however as we did not have enough information to calculate a MIC in step 1, it is done here in step 3. (source: 802.11i standard)
This website has Wireshark screenshots which show you that the ANonce is sent both in message 1 and message 3, and that the 3rd message contains a MIC to protect the ANonce (comparably, message 2 contains the SNonce and the MIC to protect it). I've copied them here for archiving purposes:
Message 1:
Message 2:
Message 3:
Message 4: