Huge problem we see at my current company, Stytch (https://stytch.com/). Toll fraud/traffic pumping can result in huge costs, mid thousands to millions per year.
One thing that surprised me a lot to learn, and is covered in the article, is that the primary bad actor is the telecom provider! I had no idea that the telecoms were sharing revenue with hackers that found unprotected SMS channels and exploited them. A really wild thing.
We have a bunch of built in protection against SMS toll fraud for our OTP product as well as more in-depth fingerprinting tools if your app ever runs into this problem. When you get that first surprise bill from Twilio, give us a shout and we can help!
The wild thing about this is that this isn't just a B2B fraud, but regular joes are hit with it as well and regular operators don't care.
My phone got stolen in Naples last year, just as I was about to board my plane. It was 11PM, so when I called my boss from my gf's phone he decided to block the number the next morning as he was in bed already. By the time the SIM was blocked, 10 hours had passed, and thieves had managed to place over 100 hours of very expensive toll calls to numbers in Algeria. It cost the company over 10k, and our operator was not willing to accept any responsibility over it. Admittedly, I turned off the PIN lock because my phone at the time would overheat and restart multiple times a day, but operators really should have lockouts on foreign payphone numbers, especially once they're being placed faster than a human can dial them.
The Prophet years ago wrote in 2600 telecom informer that there were solutions to telemarketing calls/spam but the phone network operators liked the profit and don’t want to solve this problem for their customers
Happened to us as well a while back. We tracked originating IPs to the same telco that was sending SMS to their own numbers through our platform. I couldn't believe it.
This article is a little dated, since then we’ve released Fraud Guard. Our model can detect and block 98% of pumping traffic with only .1% false positive. It’s working really well to deter these fraudsters. If you’re interested, you can learn more here [1].
Were also rolling out a version for all Programmable SMS customers with a higher false positive rate due to the wider variety of use cases supported.
Taking a wild guess – but is there a chance that people using Twilio as their personal phone provider are not their target customer group?
Sounds a bit like opening a merchant account and using credit card payments as a way to split bills and rent with friends, and then being annoyed about being treated like a business (i.e. getting tax forms, having to declare a business model etc.)
Don't get me wrong, I also use a Twilio account for my home automation setup, but I can kind of see how that's pushing the boundaries of the product a bit.
"Taking a wild guess – but is there a chance that people using Twilio as their personal phone provider are not their target customer group?"
I attended Signal 2018 and was told that (Twilio) "couldn't wait to see" what I built. I was handed IoT SIM cards and carrier SIM development kits and attended workshops and seminars exploring exactly these sort of use-cases.
I was also told by many highly placed individuals in product development that the CEO was personally enthusiastic about exactly these sort of use-cases.
So yes, I did some homework and made an attempt to align my incentives (I pay actual money for every SMS I send) with those of the company.
Now all of that has changed - in large part due to their own (bad) behavior.
"... I can kind of see how that's pushing the boundaries of the product a bit."
Agreed - that is my point and the source of my frustration.
Server alerts and (literal) fire alarms should not be a "campaign". If they are, I'm using the wrong tool.
If I need to define an opt-out message to SMS my kids, I'm using the wrong tool.
Twilio is explicitly telling us - loudly and emphatically - that they are the wrong tool.
It looks like you still have this kind of capability. You might need to adjust settings and supply KYC info as requirements change. From the Fraud Guard docs, "You can mark known phone numbers using the Safe List feature so they are never blocked."
I'm actually in this exact same boat (I ported my US number to twilio when I had a long travel stint abroad to retain access, have since built a forwarding system to keep using it).
I registered with the IRS to get an EIN for my "sole proprietorship" (i.e. me), and that seemed to satisfy twilio for the brand registration requirements. Still waiting on a final A2P review for my use case (sending messages to family and friends) so not out of the woods yet, but hopefully that's the last step.
First, a utility number that I send myself programmatic alerts[1] and do general messaging management with has broken entirely and it is certainly the result of A2P 10DLC and my "failure" to create a business entity for sending reminders to myself.
Second, the messaging - both email alerts and direct from customer support - has been crystal clear:
ALL SMS is a campaign. It is all spam. You need to register and qualify and opt-out your spam or you can't send your spam.
So yes, actual problems.
[1] Again, Jeff, what kind of (required) opt-out message should I craft for myself ? What if the third party ad-industry working group doesn't approve of my unsubscribe methods that I give to myself ?
Please use secure channels for authentication. SMS is antiquatedly insecure (Any way it's sent: SS7, SMPP, etc.).
More traffic benefits the industry (since some sucker pays for it). There's no incentive for any of the entities that profit from this to stop it (unless it's too sell you a premium protection service).
Sure, but it seems a bit short-sighted to assume that SMS brings no benefit. If a customer somehow loses access, SMS is far cheaper and more available for all involved than any other alternative. Most people don't want to carry any dongles (especially not institution-specific ones) and many don't really want to install apps or have phones that will wipe app data for infrequently-used apps.
SMS as a backup is very different to SMS as your only option. For one it can be made much more inconvenient to use SMS so as to reduce the surface area for scams. Plenty of places still have it as the primary and only 2FA mechanism. Of course SMS itself is awful which is the key problem here. What you mean is that having your phone tied to an identity is useful (what if you lose your phone? SMS is no longer at all useful) and we could do much better than SMS for that.
Indeed. I once worked on a system where we had SMS as one of the "last resorts". When someone used SMS as recovery, we'd disable withdrawals and fundings (it was some sort of wallet) as well as severely limit their daily limits. Until the account was fully restored again using normal, secure methods (Mail, KYC, etc).
We were hit by a similar "attack" where our "let us call you to start recovery" was abused by putting a toll-number there, and our system would then call this toll-number and we'd get rediculous bills. But putting in limitations helped a lot, so we did this for SMS too.
Meanwhile, there are countries whose entire banking, tax filing, CC processing and various public service systems rely on SMS as the only second factor.
I don't know about those countries, but I know of one who says it's trying to compete with the US on tech, and one of their biggest banks moved away from hardware TOTP tokens to some kind of "secure app" and now to... SMS!
To name and shame: BNP in France. My personal account stayed on the app, but for my company account, it I only get SMS now.
What's worse, all they had to do was enable a checkbox in the settings somewhere but they went on an embarrassingly long e-mail thread back and forth, not even willing to help the users.
So I think that in cases like that, it's definitely a good idea to call attention to the issue and tell more people about open technologies like that! Unfortunately, most people just won't care.
That said, TOTP is actually decent and I'm surprised that it's not supported everywhere, especially given how much shouting about SMS not being secure enough goes around.
TOTP unfortunately does not satisfy the “transaction binding” requirement of PSD2, since the token does not tell you what you’re confirming at the time you share it with a (potentially MITMing) website.
SMS-OTP, despite its many other flaws, at least offers a trusted path to say “by sharing this code, you are paying x€ to y corp”.
I think that since the issue at hand is that SMS can be intercepted, the protection afforded by this information is minimal.
Anecdotally, in the case of my bank, if I try to make a transfer, the SMS is something along the lines of "Are you trying to transfer 1234 €? If yes, enter the code 12345, or else call your representative asap".
One terrible point being that once you've entered the confirmation code, they consider the transaction as "strongly verified", so it's not that easy to roll it back. Fortunately, I've never had this happen to me so I don't know what that entails, but contesting a random unverified charge is as easy as clicking on the transaction list and then "dispute".
Yes, all in all I'm not happy with SMS-OTP still being considered just as secure as e.g. WebAuthN, and much more secure than Email-OTP (which is explicitly prohibited for PSD2/SCA purposes).
The problem isn't really interception in my view (even though SIM-jacking and porting attacks are scary enough!), but rather the high likelihood of phishing/UI confusion: With modern mobile OSes auto-filling transaction details, I'm not too sure if everybody is still reading the text accompanying the confirmation code.
It's quite possible for a fraud victim to be directed to amaz0n.com and tricked into entering an SMS-OTP confirmation code to confirm a purchase of €5.00, without noticing that the accompanying text actually says "only enter this code on BuyCryptoNoKycOrBacksies.com to confirm your purchase of €500".
My country’s administration lets people e-sign PDFs that are accepted throughout the EU as legally binding/equivalent to a paper signature using only a static password and SMS-OTP.
(The system used to be based on PCKS#11-compatible smart cards, but nobody managed to use the software, so they switched to SMS…)
That's also because these systems are large, complicated, and slow moving. Not only that, but the users are resistant to change; the older you get, the faster time moves, and a decade between one system (SMS) and the next (e.g. a two factor auth app) feels short and unnecessary.
Last I checked, even the US federal government required SMS 2FA to get into your Social Security account.
But the problem is also only allowing SMS 2FA. Why not allow both and let people choose TOTP?
I have a feeling SMS 2FA is used as a cheap way to implement a rough social credit score. If you have a stable life and follow the rules, then you have continuous access to the same phone number. And only allowing SMS 2FA allows you to only deal with this population, and ignore populations that might have higher proportions of “costly” customers.
Just want to flag that Twilio’s 2FA service, Authy, is tightly tied to SMS. For example, if you want to login to iwantmyname.com, it asks you for your Authy totp, but if you don’t remember it, they’ll settle for an SMS code instead. And that’s a ‘feature’ of the Authy integration.
SMS is the only second factor that works for people without smartphones. Having a smartphone means signing your life (your location 24/7, your messages, your contacts, your everything) over to either Google or Apple.
I understand the security aspect and realistically most people will have smartphones anyway, but forcing everyone into this surveillance duopoly, especially as Apple is overpriced and Google is ad company with stated mission of removing privacy, makes me pretty salty.
Before my bank supported smartphones, they used a smartcard reader that you'd put your debit card into (a vasco digipass). The earlier model required you to type in a numerical challenge, a later model used a digipass that can scan a QR like code (that uses colors for higher data density).
Another bank's employees used a physical RSA securid TOTP token (which was a bad idea since RSA hung onto the seeds and got hacked).
(TOTP can also be added to feature phones, it's fairly straightforward. There's open source java ME projects.)
Corporate clients with their competitor had been using MSDOS based banking software that came with a hardware token that ingested a challenge as flashes of light from the screen, which was pretty neat! It didn't read a debit card, the seed was just baked in.
Before banks started shipping physical tokens or card readers, they would send you a list of one time codes to approve transactions.
Note that Google also has the option to generate such codes (although you get 6, not 50 at a time), so you can get into your account even if your phone is stolen.
All of those worked in the age before smartphones.
Now, there's also passkey/U2F/FIDO2 based hardware keys you can provision yourself and buy from several vendors, like Yubikey or Token2.
There's plenty of reasons to be salty about the smartphone duopoly and surveillance economy, but for 2FA there's plenty of alternatives. And if you do use a smartphone, you could always use an open source authenticator app.
Ha, in Swiss biggest bank by nr of clients (PostFinance), I log into ebanking with card reader (their yellow calculator-like thingie). Reader reads the payment card, asks for key from ebanking (after entering username & password), after entering it asks for card's pin, gives back resulting code which goes to ebanking.
If I count correctly its checking 1) username/password; 2) currently holding my payment card; 3) card's pin
Even if I don't count owning reader itself as another point of security (since it can be obtained ie via social engineering and its a simple generic device) its at least 3-factor auth and its still the most secured ebanking from all banks I have. Annoying a bit to log into but this is one place I don't mind it at all. And no phone involved in any step, for which I am very glad (not having yet another thing to manage, keep updated, worry and chase cancellation when lost/stolen).
Far more trustworthy than google or apple. I've never seen reports of Vodafone or whatever blocking a number because of some nebulous reason (unlike say through a court order), but it's so common for apple and google that someone tried setting up a startup to fix the problem [0]
Eh, depends. I wouldn’t trust Vodafone to give me the time of day, personally [1].
In any case, neither Big Tech nor Big Telco are my favorite candidates to be the guardian of my digital identity.
[1] Had them for years in an apartment where they have a local monopoly; speeds of 0.3 Mbit and latencies of 15 seconds – yes, 15000 milliseconds – during the pandemic were not unusual. The upgrade of the local node is scheduled for late 2024.
> In my country there are significant consumer protections around mobile phones.
That's a good point – we urgently need those same protections for e.g. things like email addresses or Google accounts.
But, yes, I do know people that are unable to port out their phone number: Sometimes it's a line on a contract in somebody else's name (minors, spouses etc.), sometimes it's a prepaid card not properly registered (although that's getting less common with the EU mandate to verify everybody's identity before activation).
Neither a phone number nor a Gmail address/Google/Facebook/... account is a good anchor of trust for digital identities.
There is a better way. There are plenty of non-phone-based totp authenticators, and many of the password managers provide one. I’m using 1Password for example and I do not use phones for second factor.
Why would I want to buy a smartphone, just to log in to some service? Why would I want to install some crappy auth app on my computer (That most likely does not have a Flatpak for it even)?
Most places do not support Yubikey... so getting SMS on my Nokia 3310 is the best option for me.
It's the way to go for you since it is convenient for you? Doesn't really help against the security problems with SMS. Someone can for example socially engineer a phone company operator to steal your phone number.
This is the problem though. SMS was pushed early on since it was great way to identify and track users in addition to being easy for most of them to use. It was never as good of a choice as TOTP, but it was easier to get users to use. But now there is of momentum behind SMS and sporadic support of things like TOTP.
Most of the new alternatives seem focused on pushing lock-in traps and are complicated for users to understand or use. If they're going to lose user tracking of the phone number they want something even worse to replace it, not something open like TOTP.
Well I have a smartphone but I still don't want a shitty app for each service.
What's all this about SMS being insecure? I never heard of phone numbers being hijacked in my country (except in the case of physically stolen phones ofc). Is this another consequence of US making it so easy to steal an identity?
I have a bunch of vendors (e.g. Microsoft, Google, Gitlab, VPN, others) in the same OTP app in my phone, so my belief is that they seem to agree just fine.
There are of course examples of vendors that don't. I think Steam is one of them. And my bank.
This is just a new variant of an old attack. I have been working for a VOIP provider 10 years ago and the attack was similar: the attackers compromise a VOIP PBX (default passwords, extensions opened in the WAN, etc.) and then use it to call a very expensive value added service that they owned (like one special number in Tristan De Cuna or Nauru that costs 50€ at the reply and 10€ at minutes).
Here's the missing bit of advice, which you won't get, because Twilio makes money from you sending SMS messages:
Do not use SMS for 2FA.
Seriously — just don't. It is not secure, it is susceptible to fraud, it is not a good second factor.
Yes, I do realize there are other uses for SMS, but this is the prevalent one, and I'd like people to consider seriously if they really want to use it before they blindly follow what others do.
Remember that there are companies that use SMS 2FA not to make anything more secure, but to get your unique tracking identifier (your phone number) and tie it to online targeted advertising.
Need to yell this as loud as possible to the goddamn banking and healthcare industry face then. Cause those dinosaurs don't even let you have an online account without an SMS (and only SMS in most case) as a 2FA mechanism.
Just to shame a few out there right now: Chase, Fidelity, Bank of America, American Express, United Healthcare, Signa and many more.
Ally Bank used to allow 2FA through SMS or email, if I recall both were optional. But they eventually required everyone to use 2FA, and it had to be SMS -- email 2FA doesn't work anymore
I think that depends on how it's implemented and how their account recovery process is done. If they give SMS special status and use it with few or no other data to recover accounts when you're locked out, then adding SMS 2FA might actually significantly decrease your security for that account by allowing someone to gain access with just the SMS capability.
That's hopefully very rare, but of the companies that would do so, I imagine the ones that only support SMS 2FA are likely to have a higher occurrence.
> I think that depends on how it's implemented and how their account recovery process is done. If they give SMS special status and use it with few or no other data to recover accounts when you're locked out, then adding SMS 2FA might actually significantly decrease your security for that account by allowing someone to gain access with just the SMS capability.
Very true and very dangerous. Do account recovery procedures technically count as a authentication factor? I've always though about them as a separate thing. For example alterative email addresses, physically visiting a building, etc can be used to recovery an account but may never part of the actual login process.
India has been enacting regulation enshrining SMS as 2FA for their entire Digital payments infrastructure. They even require storing all biometrics (FaceID etc.) on gov servers and not on-device. We are in for a decade+ of this at minimum.
SMS also comes with no deliverability or latency guarantees, and hard to scale globally as rules and regulations are different in every country. Acquiring IDs is slow and you need multiple for backup routes and different use cases.
We all here live in a tech bubble. None of my friends and family have a 2FA app, or know what one is. They understand SMS, and it's better than no 2FA at all.
At worst it's no worse than SMS, but at best it's at least secure in transport and effectively free.
The downside to email is primarily that data is not a roaming perk for many. But if it's too access an app then a reasonable assumption of internet access even if not on the mobile is valid.
The other two downsides are: Some people may chose not to have their email account on the phone. Personally I don't want to carry around access to my main email at all times (the same goes for access to my main bank account, BTW.)
Also, email delivery sometimes takes a very long time, it can be minutes, if you rely on email forwarding to protect your main email address.
Separate from that, it is not productive for you to tell me to think about it more -- for all you know I've implemented two factor authentication in various forms for decades (from OPIE when I worked at NRL to Smartcards within DOD to Passkeys currently). What would be more productive is to get more insight into what you're thinking
If you have access to somebody's email you can just click reset password and then click the "2FA" in their email and then you have access to their account
The same situation seems to be true of SMS, if you have gained access to their account then you can use that to perform 2FA as well. In this situation, it doesn't seem to be significantly different in terms of security.
To answer your question on whether or not people access other people's SMS accounts -- yes! That's one reason it's not recommended any longer. Additionally, there's often less security possible for ones SMS account versus ones email account.
You would have to get access to their email and SMS to perform a password reset and get past 2FA. If you are saying you could do a SIM swap attack simply by having access to their email I think that is not that practical at all.
> To answer your question on whether or not people access other people's SMS accounts -- yes!
What? I never asked that? What are you even talking about?
You've never done a password reset? That goes to your email. If your 2FA is over email too then that isn't 2FA. Because you only need the email to take over an entire account
For literally years Google Authenticator had no means to move between phones. Of course people who were told to use it decided never to use OTP apps again after getting screwed.
Yubikeys (and google's keys) have had issues where the keys were extractable and needed to be replaced.
and so on.
SMS has just worked. Yes, it has reliability issues, but it's almost like people can't model even the most basic ways that the non-SMS tech is basically terrible. Even Apple doesn't work well because of the broadcast behavior of the confirmations.
I don't know about Android but Apple users can literally start adopting TOTP without changing a single thing.
Providers should simply add instructions telling people that if they have an Apple device they can just go to the keychain and add the code displayed on the screen or use the QR with the camera
"Feature phone" can often have some android installed on it. From all definitions I ever saw, it was mostly about form factor (keeping that old Nokia looks with physical buttons). Nokias now have something called KaiOS, unix-based OS where you can develop just like elsewhere.
Porting some app into another OS would be probably a showstopper due to budgets/deadlines, even though even my old Nokia in 2006 could easily run java apps like these (but ended up mostly running Snake et al).
I don't know, which people were laughed at in the industry for the last few decades because they wanted to have control over their own computers and run their own code on their own machines?
2FA is not the main target here, it’s SMS one time password flows. Where you never go through a traditional account setup, you just enter your phone number, it sends you a text with a one time password (generally embedded in a URL you can click), and you’re logged in.
With 2FA, you at least have to log into successfully without the cell phone first, it’s harder to exploit. You can pretty easily rate limit 2FA prompts per account, auto-ban malicious accounts, etc. While SMS OTP flows are extremely easy to exploit - the text is sent before any sort of association with and account occurs, making rate limiting, banning, etc. much more difficult.
We have a human in the loop as the fallback. It’s just a different attack vector. Brute force becomes a lot harder, but social engineering becomes easier.
It is still very common for business clients of all sizes, in all industries (even critical infra) to request 2FA via SMS. Good for the company you work for that they dont :)
There are a huge number of app based solutions. Enterprises are against them because they can't expect their employees to install 20 different apps for 20 different vendors + the cost of reviewing and onboarding them.
So you either need to support SMS or several of the major 2FA app providers including the crappier implementations like Microsoft authenticator.
I work at an "enterprise" company and I'm not expected to install 20 different apps. Duo is just one example, but it supports both push based 2FA and onetime tokens, and those two modalities cover every vendor integration and SSO we have. There's really no excuse to be using SMS nowadays.
I used to work on a related problem (call traffic pumping) for a large VOIP provider, for domestic & international calls. It was a very interesting problem which has two distinct patterns of abuse.
First is just basic account takeover/hijacking, where a criminal will login to your account and receive a cut for calling expensive numbers (or in this case, sending SMS's to them). This is basically the web version of the pre-existing PBX hijacking issue.
The second, more interesting version, is people abusing free quotas to send calls (or SMS), such as in the verification case. This is novel (relative to the pre-web era) because historically it would have been hard to make free calls/texts.
As an aside, PBX hijacking was how certain Fido BBS operators in the early 90s Hungary got their feed from abroad: a friendly installer left an extension in the PBX of the largest consumer bank which gave you a dial tone so very expensive calls abroad were billed to the bank. This went on for a few years.
We faced the same problem at Zenly and had to build our own anti-spam strategies to prevent it. We used multiple providers to improve our conversion rate and reduce cost. We are now building this as a service https://www.ding.live/ and are seeing huge improvements for our first customers in term of cost savings and conversion rate. Feel free to reach out if it could be any interest to you hello@ding.live.
We use a combinaison of route that are are evaluated in real-time for their cost to conversion ratio.
Our customers have the option to choose only « direct routes » if needed but those strategies are use at scale by players like Facebook, TikTok or Google we’re just making sure our customer have all the options, visibility and control on their conversion rate/price tradeoff.
Another strategy that allows to lower cost significantly is the use of alternative channel when available and competitive : Google RBM, WhatsApp, Viber, line..
Last but not least we don’t do any margin on the sms price so we bill back exactly what we pay for and negotiate with aggregated volumes.
>>> evaluated in real-time for their cost to conversion ratio
We tried that in the past, but our business (mostly OTP for banks) do not allow any margin of error at all. The thing is that we would get positive delivery reports which were fake.
We also tried some 3rd party testing tools (Testelium[1], TestMySMS[2], etc) but again, our hacky upstream providers were ahead of us and they would put those test number in white-list so that everything would look just fine when testing.
At the end, we settled for direct or 1-hop connection. Margins are tight, but this is the only way to offer a high quality service.
> We tried that in the past, but our business (mostly OTP for banks) do not allow any margin of error at all. The thing is that we would get positive delivery reports which were fake.
SMS delivery reports have a limited connection to reality (but IMHO, requesting them seems to improve delivery rates), but you can (and should) measure conversion and route based on that.
If you have no margin for error, you might prefer directs, but when the direct route stops working, you need an alternative.
I've seen this attack first hand, causing a company thousands of dollars of damage (not including dev hours to resolve).
The exploit was on a mobile app that required phone verification upon initial onboarding, way before any other authentication can be performed. That made it relatively hard to reinforce the onboarding API call that triggers SMS.
It's a nasty problem, and effectively an arms race.
to send a message (or call) to a phone number the sender of the message has to pay the company that owns the recipient number a fee. the fee varies. in the u. s. it’s very small. less than a penny. in some undeveloped countries it’s much higher. most fraud like this occurs in those countries with higher fees
let’s say i make friends with a mobile network operator in a country with high fees. i tell that mobile network i can send a lot of traffic to your network and generate you revenue in message passing fees. but i need to get a share of the money. the mobile network operator understands my methods are not legit and will not block the traffic / apply normal spam / anti fraud protections. we both make money at the expense of the message sender
I didn't fully understand it either, but my take is this:
1. Twilio (or someone else) sends a text message for OTP.
2. This message needs to pass through my carrier (MNO, in the article) for delivery, and my carrier charges Twilio and/or their carrier, for the service. This is the revenue mentioned.
3. I have an agreement with my carrier, or simply form my own, that we split revenue.
In all seriousness, I’ve always found the author’s odd rant on the contemporary wireless communication system quite interesting. In my mind, the issues with the current system are not so much technical as they are regulatory. There are many industries where artificial scarcity is captured by bribing… errr buying the right to that control from the Gov (while competition is held off using their monopoly on violence). Sending an SMS, especially these days, costs on the order of sending a single TCP packet over the Internet.
Together with the payment industry, we’ve been duped out of trillions in usage fees for tech that was invented and put into use by hobbyists for decades before the rent seekers showed up.
The zmq docs are a treasure. The section in that chapter about building service discovery from scratch on a local network is one of the best technical guides I've read
GP is likely referring not to the implementation, not the product itself.
The phone system was not built with basic modern necessities like authentication. You don't know that the number on your caller ID is actually owned by the person calling you, for example.
A better system would have an authentication scheme and encryption for sure. As we've seen from RCS and iMessage, it doesn't need to sacrifice backward compatibility, either.
In a 1975-era model, where AT&T owned all the physical plant, there was no point of interface where information would be lost. Presumably all the necessary information to monitor abuse was in the same place, because it needed to be accounted and billed for. There was no "Well, we know the calls are coming from Bob's Telecom and Shrimp Cannery, but all we can do is send them an angry letter" black hole.
I'd expect there were also fewer opportunities for arbitrage hacks-- I doubt a monopoly player needs to do any sort of kick-back scheme to get someone to generate extra fruadulent traffic.
You're assuming the operators are trying to stop the abuse in the first place. They aren't - they're making money from it. Hell, they even offer discounts to some abusers.
I think the current phone system is a legacy from another time. I dont know what the replacement should be but I think the following would be MVP requirements:
Only the owner of a phone number can present it as the calling number, so if you receive a call or message you can be guaranteed (within reason) that its from the owner of the number.
Overcharged numbers must not exist, if billing is needed it must be over another channel. Or at a minimum require specific optin pr number between the caller and their carrier (not the carrier where the number is terminated).
Personally I also think that anonymous calls should not be allowed, I think they should always be required to show the phone number that is calling you.
I think WhatsApp or Telegram check the boxes of your proposed MVP. Or Skype. Or any other VoIP service, frankly. Discord? Matrix? E-mail link to a Jitsi Meet call?
The problem with the legacy phone system is that everybody uses it and it's hard to get off of it. I think more and more people rarely ever use it though, except as “dumb pipe” for data.
Or Microsoft Windows you must pay for even if you never use it?
Not trying to say the phone system is without problems. But it's often "modern" IT people who criticize it with attitude we could do better. IMHO most modern IT ecosystems are horrible in terms of freedom and markets.
Can someone explain this attack a bit clearer please?
If my server is sending a 2FA to a mobile number, then I control the number and the content of the message, so how does the attacker send to blocks of numbers and profit from the traffic (I'm guessing they need to put a link in the message?)
Does it only happen with poorly written forms that have no validation so the attacker can control the target number and the message that gets sent?
There are a few ways one can benefit from AIT / SMS Pump:
- Exclusivity: This is where an exclusivity deal is signed with a party for a specific route. But when those parties are engaging themselves with a minimum traffic volume and fail to meet their objectives, they tend to turn to AIT to achieve their objectives.
- Range Leasing: Here we have a rogue party leasing a number range and getting a revenue share of the traffic going through that range. MNO could be aware or not of the scheme.
- Range Hosting: Same as above but hosted on MNO. MNO could be aware or not of the scheme.
- CR Tampering: More complex scheme where a party would send lots of OTP to dead numbers in the hope to drop CR and DR. This might lead to the rogue party getting that traffic afterwards if the customer is looking at switching provider.
You don't control the number. When signing up for a service or setting up SMS 2FA, you need to initiate the process by inputting a number. Attackers input numbers that are very expensive to route to, and since SMS is not a flat rate service, when this happens at volume it gets very expensive very quickly. I've seen really scummy MNO's costing around ~25 cents per SMS.
Oh I see they profit from the fact that I'm charged to send the SMS, I thought they were profiting from the end user visiting a link (and generating ad revenue)
Thought experiment: Maybe if enough of us do it, companies will stop forcing us to use SMS for 2FA and let us use a proper authentication device instead.
The fraudster creates new accounts on your service for each of these phone numbers. They don't care about verifying the 2fa code. They just care that you send a text to those numbers.
Watch very well before you get married to that man or woman why am I saying this? I have passed through hell in the hands of men before I knew people like CRYPTORECOVERYHACKER @ GMAIL COM" exit when it comes to catching of cheating spouse. Men really dealt with me but after my contact with this hacker I realised that what ever a man tells you should be properly investigated cause most men out there are bunch of lairs am happy with CRYPTORECOVERYHACKER @ GMAIL COM" I broke into so many men cell phones to really know who they are in the hidden and trust me majority of them are lairs.
They're not toll numbers. They're regular numbers. Mobile networks get paid a small amount of money for delivering SMS messages. Let's say that they get paid $0.003/message. Let's say you're a small mobile network and I bribe you or make a deal with you: I'll get lots of messages sent to mobile devices on your network and you'll pay me $0.001/message. That's good for you as the mobile network and good for me since I get money.
So I get a list of numbers on your network and start filling them into any form that will send a text to that number.
There is no "don't send messages to scammer toll numbers" option because these aren't toll numbers. They're regular numbers. I mean, Twilio could probably easily detect this behavior themselves and prevent it. As they note, they often cycle through adjacent numbers and do it in a quick fashion. However, the numbers aren't scam/toll numbers as a category. You'd need to use ML/heuristics to find these.
Yeah, but they could do it as part of their basic service because it would make customers happy. They don't though, because they also make money from it
When the service provider is liable for fraud losses they use the latest best practices. When the customer eats the loss they can just throw up their hands and say you should have used xyz security feature.
Twilio has been complicit in this problem for years, and up until very recently put 0 effort behind tooling to allow customers to block it off from the top.
Instead the world toiled away on what is surely several hundred engineer lifetimes of hours building the same fraud guard solutions in front of Twilio.
Wonderful piece of propaganda that Twilio can put out to pretend to be a thought leader in the space while turning a blind eye to the tens of thousands of dollars of fraud passing over their wires on the daily.
Not only that, but they now have an "SMS Pumping Risk" API endpoint(1) that costs 3.5c per request(2). I guess the demand is there... but feels pretty exploitative at this point.
100%, my current company had to build fraud protection specifically for our Twilio SMS OTP flow. I’m sure essentially every Twilio customer that does SMS OTP flows with them has had to do the same. Took them forever to build their own feature for this, despite it being SUCH a common issue, and now they charge extra for it.
The most innocuous explanation is someone in management asking "if someone tells us (via API request) to send an SMS to a certain number, and we don't send that message because we're 99% sure they're being defrauded, how do we communicate that to the customer, and what about that 1% chance we're wrong?"
Although the most likely explanation is someone in management going "hold on, we have to spend money to build these safeguards, and we're going to make less money after we deploy them?"
Couldn't agree more. Twilio has been profiting from these scammers for years. We had several calls with our account manager and "fraud expert", and the answer was always the same - migrate to Twilio Authy. The problem is that with Twilio Authy you are basically paying the same amount, it's just that the cut or "protection fee" is not going directly to scammers, but to Twilio.
The last time we talked to them, they bragged about how good their algorithm to detect fraud is and that we should take advantage of it by onboarding to Authy. I asked them why they just don't offer it to all customers, since their platform is enabling scammers. And the manager said, I'm paraphrasing here, "well, we are for profit company".
SMS can be withdrawn from the phone after receiving them, if they include a special ID. Is there any operators that have used this for deleting SMS if they later find that this is fraud/spam?
That's just how GSM is. Keep in mind that back in the day, your device attached to the modem might not have been very smart or interactive. The service center has the ability to CRUD everything on the modem via AT commands.
Your keyword is AT+CMGD
Things are probably more complex on modern smartphones but I had to learn all this crap for an arduino project.
Your provider should have a price list. In my experience, the price lists are usually numberprefix, cost. But sometimes cost depends on actual carrier, not original carrier, so you can't know the price until a porting lookup is made, and those cost money too (those are generally a usage tiered $/lookup, starts around 0.01USD at low usage, but can go much lower if you have volume)
This is unfortunately easier said than done. You'd expect Twilio to let you set a max spending limit in your account settings. Instead this is what they tell you to do: https://support.twilio.com/hc/en-us/articles/223132387-Prote... (notice the PHP snippet too)
Essentially, setting up a webhook to receive alerts from Twilio, and then calling a Twilio API to suspend the account. Your webhook better be up and running flawlessly if you don't want to go bankrupt. Why can't they do it themselves?
This may unnecessary discriminate people from countries which is not your main market and digital nomads using local SIMs. Better is to have per-country (or even per-operator) rate limits which are low by default but high for countries you have a lot of users from.
If any YC companies are running into this, hit me up at chris ampersand stytch.com. We have a great YC deal and can stop toll fraud eating your dollars.
One thing that surprised me a lot to learn, and is covered in the article, is that the primary bad actor is the telecom provider! I had no idea that the telecoms were sharing revenue with hackers that found unprotected SMS channels and exploited them. A really wild thing.
We have a bunch of built in protection against SMS toll fraud for our OTP product as well as more in-depth fingerprinting tools if your app ever runs into this problem. When you get that first surprise bill from Twilio, give us a shout and we can help!