The newer models support U2F, which is a challenge-response thing: the website prompts you to insert your YubiKey and tap it, and the key signs a response and sends it back to your browser.
I believe this adds protection against phishing because the browser communicates which origin (that is, which domain name) is sending the challenge, and that gets hashed into the signed response. So if trust-me-im-google.com proxies google.com, it can ask you for a one-time password, and the one-time password will be valid when google.com gets it, so the MITM can get your login cookie. But if you're using U2F, the signed response will say "Yes, I would like to authenticate to trust-me-im-google.com", and google.com will reject that.
That's very cool. Could you elaborate on the method in which the key accepts the challenge? I was under the impression that a Yubikey only acted as a USB keyboard - which ensured it's security by isolation.
The other answers are correct, but even before U2F the yubikey supported other methods as well. The have a classic HMAC based ChallengeResponse-Mode, a smartcard and PIV interface.
I believe this adds protection against phishing because the browser communicates which origin (that is, which domain name) is sending the challenge, and that gets hashed into the signed response. So if trust-me-im-google.com proxies google.com, it can ask you for a one-time password, and the one-time password will be valid when google.com gets it, so the MITM can get your login cookie. But if you're using U2F, the signed response will say "Yes, I would like to authenticate to trust-me-im-google.com", and google.com will reject that.