Who says an attacker auth Web site cannot ask for the MFA code behind the scenes and supply it? Problem is no one, especially Twilio employees shouldn't never click and never trust any link they receive from trusted or untrusted source. They should use the links they already have bookmarked.
For properly implemented MFA (FIDO/U2F tokens) an attacker-spoofed website can't ask for the code behind the scenes - i.e. they can ask, but they'll get a code that won't work on the proper site.
Not sure about MFA with a USB key but for the sake of the argument, if they are using App-based MFA as their own Authy, I would think a headless browser in the backend of the fake site accessing the proper site on behalf of the real user would do the trick. It asks the code for the user on the real site and the user replies on the fake site and the fake site supplied the real code to the real site. The only thing needed is that the user gets and supply the code that was asked on their behalf to the fake site.
Is what you're responding to, and such an attack cannot work with them. The parent comment already clearly understands the flaws of Authy, you don't need to talk through it.
I'll try to explain the key difference between totp and webauthn style flows, as it relates to security here.
Conceptually, you can think of it as the hardware token (the yubikey or whatever) gets the site domain name the user is on from a trusted source (the browser), and then sends back a secret that is specific to that hardware device and domain. If they're on the real site, the token sends the right secret, but the attacker can't intercept it since it's sent directly between the local browser and usb device. If they're on a fake site, the secret will only work for that fake domain, not the real one, so the attacker can't forward it and have it work.
Many large tech companies use hardware tokens of this sort now, and for a company of twilio's size it's quite reasonable to expect that they provide such a token to employees and mandate using it when accessing customer data.
No, MITM does not circumvent that, unless you can MITM the TLS connection and convince the browser (not the user) that you're actually connecting to the proper domain, e.g. hacked private keys or malicious CA issuing fake certs, which is quite rare.
For U2F, there is no possibility for a user mistakenly approving one site's challenge on another site, if the challenge request is coming from (and the response would be sent to) https://badsite.com, then any challenge that's not for https://badsite.com would be automatically rejected by the browser even before asking the user anything. (This is the type that is usually implemented through a USB key.)
