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.