4 ms·

This is why I have always wondered about the secondary domains companies have for major incidents or auth or internal employees. If you train people to think th

This is why I have always wondered about the secondary domains companies have for major incidents or auth or internal employees. If you train people to think that several can exist, few will question another appearing. Shouldn’t having multiple domains for different use cases be considered a security risk going forward? Is it already considered a bad practice?

lbriner 4y ago
Good idea. Seems like you could use DNS or .well-known to provide canonical domains that could be checked by devices/email clients.
MBCook 4y ago
Given Twilio is an SMS company it seems like they would/should have an “official phone number” that any company related SMSes would come from. That would make this kind of attack harder. (Maybe they already have this, the article doesn’t say) Very unfortunate incident, and rather scary if this is targeting multiple companies.
- toomuchtodo 4y ago
  Only trust corp comms for corp comms (Gmail/Outlook, Slack, Teams). No SMS! (Twilio also owns Authy for 2FA)
- tauntz 4y ago
  The sender number/name for SMS can be easily changed and should not be relied on for _anything_. Twilio even offers that as a service (as do most bulk-SMS providers): https://support.twilio.com/hc/en-us/articles/223181348-Alphanumeric-Sender-ID-for-Twilio-Programmable-SMS https://support.twilio.com/hc/en-us/articles/223181348-Alpha...
  - toast0 4y ago
    That greatly depends on telco policies at the destination. In the US, alpha senders aren't allowed. Shortcode (5 or 6 digit numeric senders) spoofing is highly frowned upon to the point where you can't send from the same shortcode with multiple aggregators. Other countries vary between anything goes, aggregator takes anything in the sender field, some high profile names are checked, or all sender names need to be run through the telecoms regulator and validated by the aggregator and cell carrier. Of course, there's (usually?) no customer id transparency between the carrier and the aggregator, so if there's a misconfiguration at the aggregator, one customer may be able to send with a registered sender of another customer.
- kelnos 4y ago
  Twilio does not use SMS 2FA for access to internal systems. It's all either Yubikey or TOTP apps. I believe SMS 2FA was disabled several years ago. So, really, Twilio employees should be trained that the company will never send SMSes to employees for these sorts of purposes. But it only takes a few people to get fooled when their guard is down. That's the difficult thing about defending against security-related attacks: the defender needs to be perfect 100% of the time, but the attacker only needs to get lucky once. (Disclosure: I'm a former employee who has been getting these phishing texts, the most recent of which was yesterday... not that I have access to any systems anymore. I guess they are going off leaked employee lists that are at least 5 months out of date.)
mcculley 4y ago
Organizations should definitely think very carefully about creating domains they expect others to trust. @SwiftOnSecurity used [0] a turn of phrase recently that I had not yet encountered and I think it is a great way to put it: "strong DNS governance". 0: https://twitter.com/SwiftOnSecurity/status/1553538867919261697 https://twitter.com/SwiftOnSecurity/status/15535388679192616...

lbriner 4y ago

Good idea. Seems like you could use DNS or .well-known to provide canonical domains that could be checked by devices/email clients.

MBCook 4y ago

Given Twilio is an SMS company it seems like they would/should have an “official phone number” that any company related SMSes would come from. That would make this kind of attack harder. (Maybe they already have this, the article doesn’t say) Very unfortunate incident, and rather scary if this is targeting multiple companies.

toomuchtodo 4y ago
Only trust corp comms for corp comms (Gmail/Outlook, Slack, Teams). No SMS! (Twilio also owns Authy for 2FA)
tauntz 4y ago
The sender number/name for SMS can be easily changed and should not be relied on for _anything_. Twilio even offers that as a service (as do most bulk-SMS providers): https://support.twilio.com/hc/en-us/articles/223181348-Alphanumeric-Sender-ID-for-Twilio-Programmable-SMS https://support.twilio.com/hc/en-us/articles/223181348-Alpha...
- toast0 4y ago
  That greatly depends on telco policies at the destination. In the US, alpha senders aren't allowed. Shortcode (5 or 6 digit numeric senders) spoofing is highly frowned upon to the point where you can't send from the same shortcode with multiple aggregators. Other countries vary between anything goes, aggregator takes anything in the sender field, some high profile names are checked, or all sender names need to be run through the telecoms regulator and validated by the aggregator and cell carrier. Of course, there's (usually?) no customer id transparency between the carrier and the aggregator, so if there's a misconfiguration at the aggregator, one customer may be able to send with a registered sender of another customer.
kelnos 4y ago
Twilio does not use SMS 2FA for access to internal systems. It's all either Yubikey or TOTP apps. I believe SMS 2FA was disabled several years ago. So, really, Twilio employees should be trained that the company will never send SMSes to employees for these sorts of purposes. But it only takes a few people to get fooled when their guard is down. That's the difficult thing about defending against security-related attacks: the defender needs to be perfect 100% of the time, but the attacker only needs to get lucky once. (Disclosure: I'm a former employee who has been getting these phishing texts, the most recent of which was yesterday... not that I have access to any systems anymore. I guess they are going off leaked employee lists that are at least 5 months out of date.)

mcculley 4y ago

Organizations should definitely think very carefully about creating domains they expect others to trust. @SwiftOnSecurity used [0] a turn of phrase recently that I had not yet encountered and I think it is a great way to put it: "strong DNS governance". 0: https://twitter.com/SwiftOnSecurity/status/1553538867919261697 https://twitter.com/SwiftOnSecurity/status/15535388679192616...