Live data from Hacker News

Twilio’s toll fraud problem

billychasen.medium.com

131–140 of 221 posts

Re: Twilio’s toll fraud problem

#131
post #38

Earlier quoted context omitted.

> They know how much to bill the customer I don't mean to do Twilio's work of defending them, but in my experience it's possible they actually don't know how much to bill the customer. What they may know is the generalized per-minute or per-session rate they've agreed with another operator alongside a general "premium rate numbers will be settled at a later date" kind of clause. My employer got bit by this several ye…

This is the case, the telephone billing system is perhaps the most complicated pile of softwareshit you have ever seen in your LIFE - and some of it is insane. There have been people who got printed bills from their cell phone provider for every single kilobyte of data, each individually indexed and billed: https://en.wikipedia.org/wiki/300-page_iPhone_bill

When I was an intern, I was working for a big company on a project to optimize some call center management. Basically put mainframe reports on an intranet.

The company had made a change of some sort where whatever EDI connection between the telco and the company stopped working. I learned this when and angry facilities guy came up looking for my boss’s boss to sign for a delivery. I was the only person there, so I did. 15 minutes later, two pallets of bankers boxes came up - thousands of single sided pages of itemized call details.

Re: Twilio’s toll fraud problem

#132

Earlier quoted context omitted.

Apple DOES say that, when you set up FaceTime and iMessage! There is a pop up that says "Your carrier may charge for the messages used to activate iMessage and Facetime" You can choose to not activate and do it later.

That warning did not appear in the early days.

That warning actually depends on the “carrier profile”, a configuration file the phone silently fetches (or has cached in firmware builds) based on certain attributes of the SIM like the ICCID or MCC/MNC.

There’s a field in there that configured whether that warning should be shown.

Re: Twilio’s toll fraud problem

#133
post #67

We've been hit by this at work as well. We had to add CAPTCHA and a several other techniques to defend against this. How it works: 1. Attacker leases 1 or more premium rate numbers in an international country. - Attacker can lease a premium rate number for as little as $10/month - Typically, the attacker gets to keep 70% of the money generated by the premium rate number. 2. Attacker then finds companies with OTP (One…

> premium rate number costs 10 cents wut, the absolutely most ordinary (in the realm of single telecom) text costs me ~6.5 cents

You’re talking about the fee your carrier charges for normal texts. These are “premium” charges, meaning the user is charged an extra fee on their bill regardless of their SMS billing plan.

Re: Twilio’s toll fraud problem

#134
post #107

Earlier quoted context omitted.

Which seems like a super easy fix for Twilio to implement. Don't allow SMS to premium rate numbers. If they can identify the premium numbers for billing, they should be able to identify them for blocking.

I would imagine there are rules/regulations about a SMS provider blocking communications before fraudulent behavior is determined? Not saying it shouldn't/couldn't be done, but probably one of those things with a simple tech fix but a complicating social/business aspect.

surely not if the customer _explicitly requests_ that the communications are blocked? iirc in Aus it was possible to have your provider block messages to premium rate numbers back in the days when it was popular to buy ringtones.

Re: Twilio’s toll fraud problem

#135

I've read through a lot of the responses and I am still kind of confused how the fraud actually works: 1) Scammer leases a "premium phone number" from a provider. From doing some reading, premium numbers are where the caller/texter pays extra for interacting with the service at this number. So like a 1-900-phone-sex line from back in the day, where if you call, you get charged like $5.00 a minute. The provider leased…

The carrier offers the pay-per-call/sms service to a business (like your phone sex operator). The carrier charges the fee and some percentage is given to their customer.

So, rent one of their numbers with a fee attached, get a bunch of CAPTCHA texts sent to your number. Your carrier charges Twilio some amount for each call, then sends you a check for some percentage of that.

Re: Twilio’s toll fraud problem

#136
post #27

Twilio managed to convince everyone that SMS based auth was a good idea but it's always been a bad idea. Drop twilio and go back to using passwords and use a different 2fa method.

Most users forget/neglect keeping backup codes for proper 2fa, unfortunately.

Were falling through the computer literacy gap between SMS MFA and authenticator/Yubikey MFA at the moment. While an IT person can do password managers (with secure backups) authenticators, passkeys, and biometrics, all with half-decent opsec, the average user can barely do more than a couple of passwords for everything, and SMS MFA.

It's absolutely critical that the companies we support vastly improve their security, but there's no way to get there from here with their staff, lack of any established processes, and zero training infrastructure.

Re: Twilio’s toll fraud problem

#137

Earlier quoted context omitted.

I'm surprised/confused: Why is it hard to detect premium rate numbers, or at least set a flag to not allow sending to them? Like, I can't think of a time when twillo should ever be sending to a premium rate number; why is this even possible?

Honestly, I can’t think of a legitimate use case for toll SMS.

Paying for things?

Re: Twilio’s toll fraud problem

#138
post #72
post #50

Earlier quoted context omitted.

>Your only power to encourage them to fix this is to do the thing they're begging you not to: dispute the charges. I'd check their TOS to see if they offer some kind of arbitration option. As noted in other threads, triggering that process can be a surprisingly effective way to make someone from the company actually engage with the issue. Disputing the charges is always a nuclear option. They may never do business wi…

> Disputing the charges is always a nuclear option. They may never do business with you after that. This is something that I think needs to be regulated. I'm not saying that this should be the case for a company the size of Twilio, but I definitely think that a company the size of Apple/Google/Samsung should not be able to ruin your life because you had temerity to stand up to them and dispute a charge.

As I see it, the problem is that those companies are effectively monopolies in fields most of us depend on. If Apple or Google refuses service to someone previously reliant on their services, they could be locked out of accounts on a plethora of other services, have their payments to third parties disabled, lose access to major means of communication, and more.

The last generation of big tech monopoly never had that kind of power. Microsoft couldn't even do much to block someone from using its products as most of them were sold through third parties and didn't require network services to operate.

Re: Twilio’s toll fraud problem

#139
post #30

Does this Fraud Guard they offer protect against this? https://www.twilio.com/docs/verify/preventing-toll-fraud/sms...

The author says this was added after they started using Twilio and implies they were not informed of the option when it became available.

Re: Twilio’s toll fraud problem

#140
I find it particularly frustrating that they force you to upgrade to Verify to solve the problem unless you want to build out a lot of your own internal risk detection (which we ended up doing instead)

With the rise of AI APIs, I expect we'll see similar attack vectors for apps that integrate APIs from OpenAI or Stability. There won't be a colluding telecomm, but the API output (a completed task) is relatively fungible and far more valuable in itself than a SMS API response. Something to keep in mind if you're building an AI application: https://stytch.com/blog/securing-ai-against-bot-attacks/

Post reply on HN