Protecting Third-Party Services I: SMS Gateways
Recently during an assessment, I discovered that a client had several functions within their web application that leveraged third-party services for sending SMSs and emails. These particular functions were available publicly to un-authenticated users.
Upon testing these services I had discovered that they weren’t protected by any anti-automation or throttling mechanisms. What this means is that an attacker can repeatedly send requests to the application, leveraging a tool such as Burp Suite’s Intruder.
In part one of this two-part post, we’re going to be talking about attacking and protecting SMS sending functions within applications.
So let’s talk about the SMS sending mechanism
This function was designed to provide the users with an easy method for downloading the mobile app. It worked by requesting that users enter their cell-phone number, and the system would send an SMS containing a link to the mobile app download.
Unfortunately, this application didn’t support throttling. As such, a single user could send a large number of SMS messages to a desired phone number. This is bad for a couple reasons.
Reason One: The Company Might Have to Pay
Let us pretend we are a malicious user who decided to target this particular service with the intention of causing the company to incur costs associated with the service.
Most often, companies, especially startups, leverage services such as Twilio for sending SMSs. The cost of using such a service is typically cheaper than rolling out an entire infrastructure. Each of these services has a different pricing model, but most involve some cost per message sent.
As seen below, in the case of Twilio, it costs $0.0075 per message sent.
As a malicious user with the goal of costing the target organization money, we want to find some method of sending large quantities of SMS messages automatically. Because we have identified that the specific mechanism doesn’t leverage throttling, we use Burp’s intruder to repeatedly send HTTP requests to the SMS sending endpoint. In this instance, we don’t necessarily care who receives the messages as long as we’re able to send lots of them. So we set the phone-number parameter to some arbitrary phone number and configure Intruder to use a null payload. In this case, we can set the quantity, which we have configured to 100.
So with the Intruder attack, we send 100 HTTP requests to the /sms/send method, which in turn requests the SMS gateway to send 100 pre-defined SMS messages to the number of our choice. As we can see, I now have 100 new messages in my inbox.
With this particular client, we were able to send an average of 10 requests per second, which translates into 10 SMS messages per second. If they were using the Twilio plan that charges $0.0075 per text message, we would have caused the clients to incur a cost of approximately $0.075 (7 cents)/second. This translates to approximately $6,500/day!
Reason Two: The User Might Have to Pay
If the attacker is more interested in targeting a specific user rather than the organization, we can leverage the same attack outlined in reason one but against a victim’s SMS number.
Some SMS service providers still charge users to receive text messages. For example, I was recently traveling internationally, and every time I received a text message, I was charged $0.05. In a typical situation, that’s not bad because I’m not likely to receive more than 20 messages a day while on vacation.
Unfortunately, if someone had a grudge with me, they could really cost me some money by automatically sending me SMS messages.
Given the same attack outlined above, an attacker can send approximately 10 SMS messages per second. At a rate of $0.05/SMS, that costs me $0.50/second. That breaks down to a whopping $43,200/day!
There’s no excuse for this
Now admittedly, it’s not likely that a cell-phone provider would actually stick you with a $43,000 bill, but I wouldn’t want to be the organization responsible for it! The best approach is to ensure that, as an organization, you are not responsible for incurring such costs. This can be accomplished by adequately protecting this and all other third-party integrated mechanisms.
In this particular situation, it is unlikely that a user would be leveraging this function very frequently, and as such, we can consider implementing a throttling window of one minute per request. If a user attempts to leverage this function more than once per minute they will receive an error message indicating that they must wait.
With such a window, we can recalculate the cost to the company and the cost to the user. There are 1,440 minutes in the day, and as such, a malicious user will be able to send at most, 1,440 requests per day. This would cost the organization up to $10.80 per day and some victim up to $72 per day, based on cost models identified above.
Even though you may not consider a function sensitive, an attacker may still attempt to take advantage of it. In this real-world scenario, an attacker could leverage this simple function that was designed to provide a better user experience to cost the organization and victim an obscene amount of money.
If the organization had implemented a throttling mechanism, they could have drastically reduced the cost of worst case scenario.
If you’re concerned that your organization may be vulnerable, feel free to contact us. We’d be happy to talk to you.