SMS traffic pumping fraud
support.twilio.com
support.twilio.com
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!
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.
Rate limits and billing limits should definitely be included, even on personal numbers.
Although (fraudulent) CLI overstamping is still a mess here (Australia, and probably everywhere else) despite attempts to fix it with industry code.
You gave the operator an out. While this shouldn’t prevent remedy, in some cases it will.
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.
[1] https://www.twilio.com/docs/verify/preventing-toll-fraud/sms...
What kind of business entity should I incorporate to continue texting my friends?
How would you define my current “campaigns” and what kind of opt-out language should I give to my children who receive my texts?
Can you show me example unsubscribe language that I can give to my wife ?
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.
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.
I wanted telco infra. I got toys for children.
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 ?
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.
Instead of "just" blocking it... have you considered referring the origination for prosecution?
I'd that would work better to deter fraud.
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).
I’d say 7 years is plenty of time that folks really shouldn’t be using it.
https://www.schneier.com/blog/archives/2016/08/nist_is_no_lo...
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.
I remember a story about a university in Lithuania also opting for either SMS or a proprietary 2FA app, but not allowing TOTP either: https://fsfe.org/news/2023/news-20230418-01.html
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.
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”.
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".
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".
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.
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…)
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.
If I lose my phone I've lost all my various OTP authenticator apps - I don't think they are backed up to icloud
Note as well that you really don't want to rely on SMS if travelling internationally, which is a use case I hit reasonably frequently.
Most places do not support Yubikey... so getting SMS on my Nokia 3310 is the best option for me.
SMS is the way to go.
SMS is the way to go until you need to sign in from somewhere you don't have cellular coverage.
TOTP is superior in almost every way. Failing that, sending a login link (or code) to the user's email address is more secure than SMS.
https://github.com/kwart/totp-me
https://github.com/baumschubser/hotpants
(Couldn't find one that supports QR codes, though I don't see why that would be hard to implement)
(Yeah, the UX could be better probably, but hey.)
What's your proposed solution again?
https://en.wikipedia.org/wiki/Time-based_one-time_password
edit: here's a cli tool for doing this: https://www.nongnu.org/oath-toolkit/oathtool.1.html
You cannot install a barebones TOTP app on your Nokia 3310 because it is closed source.
Most services don't offer third party TOTP because they are pressured into pushing their shitty proprietary apps.
But TOTP not only is more secure but it's completely offline. It's close to the best solution and totally exists right now
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?
That is, if your vendors all agree on something.
> Seems you have limited experience un both subjects
Yes, also limited experience on identity theft. Care to comment on my suspicion?
There are of course examples of vendors that don't. I think Steam is one of them. And my bank.
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.
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.
There should be a better way.
That's not correct. Many password managers have TOTP authentication features built in.
There's also increasing support for security keys (e.g. yubikey) with many websites.
Passkeys are also on the rise.
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.
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).
True – but using SMS-OTP signs over your life to your phone provider.
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.
Did they then block a SIM transfer request to another phone provider?
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.
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.
Just to shame a few out there right now: Chase, Fidelity, Bank of America, American Express, United Healthcare, Signa and many more.
For 2FA apps I need to securely store backup keys, and take them with me when travelling.
In my company we set up Duo, so at least IT Admin can bypass 2FA for me. But it doesn't work with all services, regular type-in OTP are still lost.
but it is better than not having a second factor. If your only choice is a password or a password & SMS, use SMS.
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.
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.
You need to cover your ass, but you don't want to actively push back and risk losing the sale.
So you either need to support SMS or several of the major 2FA app providers including the crappier implementations like Microsoft authenticator.
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.
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.
Auth apps are better for 2FA, at least for me.
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
Does that happen with SMS? Hmm...
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?
Are you imagining that email is used in some other additional way in the authentication process, such as account recovery ?
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
So which one is the nice phone vendor shipping one on device?
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).
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.
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.
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.
Spain 0.0094 Italy 0.0159 Germany 0.0198
Most likely, your upstream providers are using SIM farms
High quality routes - either direct operator connections or 1-hop - will have these aprox pricing
Spain ~0.021-0.023 Italy ~0.026-0.030 Germany ~0.06-0.07
[1] https://dinglive.notion.site/SMS-e03051265199429cb36aed17bac...
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.
Of course, YMMV
Thanks for sharing the testing tools super helpful !
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.
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.
They used some jargon in the intro and didn’t really understand how that worked!
How the Revenue Sharing works wasn’t well explained :-)
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.
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
So the attacker creates the fake traffic for the operator, operator generates revenue and then pays the attacker.
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 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.
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.
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.
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?
Thanks for explaining!
- 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.
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.
[X] Only send to low/no settlement peers (default)
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.
1. https://www.twilio.com/docs/lookup/v2-api/sms-pumping-risk
2. https://www.twilio.com/en-us/trusted-activation/pricing/lookupAlthough 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?"
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".
Would it literally delete the SMS as you're looking at it? On any kind of cellphone?
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.
The way I've worked around this issue is by:
- Verifying the phone number before sending SMS. - Using a whitelist of supported countries. - Limit the amount Twilio can charge us
Hope that helps
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.
TOTP authenticator apps exist for J2ME, which is supported by phones as old as the Nokia 3330.