I received a scam text purporting to come from my bank. It appeared in the same “thread” in my iPhone messages as actual text messages from my bank. This obviously makes it appear more credible and hence makes it more dangerous.
What makes the iPhone think that the fake text is from the real bank? For that matter, how does iPhone know the real texts are from the bank? There is no phone number associated with this contact in my phone.
Spoofing the originating number for a call or text is not terribly hard.
Yeah, it seems like, in the history of communications, when a new method is invented, it’s generally assumed that the sender/initiator of a message will be honest about who they are.
Schemes have been created to try to fix these, but when they are bolt-on afterthoughts, they can take a long time to get proper traction.
For example SPF and DKIM for emails are opt-in - and they are incomplete - they can absolutely determine that a fake email purporting to be from PayPal is fake (because the receiving server can check and will get a ‘that wasn’t us’ response), but for a message that claims to be from PayPaI - the last letter L is an uppercase i - so the receiving mail server would try to check with the domain paypai - if that doesn’t respond, then (because the system is opt-in and there’s no response saying ‘that wasn’t us’), it’s assumed everything is fine.
As an example, I got an email this morning purporting to come from IT@myemailaddress that there was a problem with my account, click here. At least I think that’s what it said, but I don’t speak Dutch.
As I understand it -
Email, there’s the from address and display name. It’s embedded text in the complete message. This can be anything the sender wants, since email once upon a time was designed to be stored, forwarded, relayed, whatever. In the original design of computer connections, assorted technical and university computers would dial up each other on a schedule (maybe late at night when rates were cheap) and exchange mail. The hidden details, the path the email actually took and where it originated, are in the header info. But the display information can be anything - it was intended so when you get an email from johns@there.edu the email included “John Smith” as a display name so you didn’t have to wonder who sent it.
Phones: the connection information from a phone call includes the caller ID information. For calls that originate on the internet (VoIP - Voice over IP) there are “gateways” that a VoIP service can use to connect to the POTS (Plain Old Telephone) network. The gateways usually accept the Caller ID info provided by the call originator’s computer or VoIP phone since they have no other way to create an ID. So unscrupulous callers can completely fake any ID name and number. I don’t know if there’s any process in place to control this yet, other than limiting access to gateways to certified customers.
Text: I imagine there’s the same issue as phones’ caller ID - there are gateways to allow connections between the internet and the texting portion of the cellular network - and vice versa. This is how businesses send out a plethora of texts for ad purposes, and also how your reply to a dentist office’s text message (“Press C to confirm this appointment”) can be computer processed. The ID info - originating number - is provided by the originator of the message. If the gateways are not policing this, an originator can spoof a text.
For email, yes, but there is (or certainly was) implicit trust between mail servers that the existing headers already in the message being handed over are truthful (effectively the properties and history of the message) - the receiving server would take them, append its own headers and pass the message along - so in the old days, if you had control of a mail server, and you could connect to another mail server, you could spin pretty much any story you want about who you are, who was sending the message, etc and the receiving server would just accept it.
It’s not like that now, mostly - and certainly for most sizeable organisations, the receiving server can check that the message is originating from an authorised address. It’s still a long way short of ideal though, because it started from a trust-by-default method.