SMS Centre + Web Gateway API - Validation
= Free Anonymous SMS Fun
You've all heard of SMS (or Message) Centres right? They're what your texts (or SMS's) go via when you text from your phone. Basically it does some cool things like deal with routing, format, etc. Anyhow, we don't really need to go into that... just as long as you understand what one is that's good enough.
Now, onto Web Gateway APIs. An API stands for application program interface. Think of it as a database of pre-defined commands that allow programmers to be able to talk to much more advanced programs... a go between if you like. For example, Microsoft's Bluetooth stack contains an API that allows programmers to develop their own programs and be able to do bespoke things with the stack. Now, a Web Gateway API is exactly like it sounds; an API accessible on the Internet that forms some kind of gateway to something... the gateway in this case - the SMS centre. It allows developers to write automated scripts and tools to carry out tasks which would otherwise have to be done manually. Now, one thing we know about software development is that you should never ever ever ever trust your inputs. Since this is now accessible on the net, we are very much fucked. Well we're not, but the people who made this internet accessible are. Anyhow...
Why am I talking about SMS Centres and Web Gateway APIs you may ask? Well, this is what all these SMS services that companies on the net use to interact with message centres. Most companies require you to open an account, top up your wallet, etc. in order to send texts. Some will not even be advertised to the public as a service - for example, they may be using the technology for themselves only; to send texts to alert of various system problems, new orders, etc. Whatever they are using it for, they are still fucked in terms of security.
I will concentrate on these companies offering online SMS services as opposed to companies who are using the Web to SMS technology for themselves as they messed up on a bigger scale.
How did they mess up?
Client side validation code.
Why the hell would any developer trust a client to execute client side code properly is beyond me. If you haven't got a clue what I'm on about, let me fill you in. When you fill in a form on a website, it has validation mostly in the form of javascript if you want to be primative. This is executed client side. The proper way of doing it is with say ASP.net and executed by the server. Anyhow... you fill in a form and up comes an error message, "No numbers are allowed in this field, please input your name in alphabetical characters only." This is data validation. The developer has put checks in on each input box so that errors are fixed before the form is actually sent off (or whatever else is going to be done with that data). This is a good thing. However, when relating to things like payment, this is a bad thing. Many online shops have fallen into this mistake by using hidden fields in forms in terms of an item's price. This is executed client side by the user. Therefore, I am able to manipulate the data (and the code) before I send it back to the server to process the request - meaning I get a new tv for 50p. This is what happens when we take advantage of SMS gateways - we change the code to exactly what we want since the server is trusting us!
What does that mean for them?
Well, for starters... let's get rid of this function... or change it slightly. I don't really want the code to be checking if I have enough money in my account if it really doesn't have to, right? ;o)
// Ensure that there's an adequate amount of money in the Wallet if sending Standard rate
walletAmount = document.frmMain.hdnWallet.value;
if ( (walletAmount*100 - costInPence) < 0) { alert("Wallet funds too low - you cannot afford to send these messages.\n\nPlease top up your SMS wallet by at least " + formatMessagesPriceFromPence( costInPence - walletAmount*100 ) + ".\n\n"); return; }
So we delete all that crap.
We don't want to be validating the sender ID, after all, I want to make up my own... that can die too.
// Validate the Sender ID
routeAndCost = document.frmMain.selUKRoute[document.frmMain.selUKRoute.selectedIndex].value.split(",");
routeNumber = routeAndCost[0];
if (document.frmMain.rdoSender[0].checked) { senderId = document.frmMain.txtSenderDefault.value; }
else { senderId = document.frmMain.txtSenderSpecific.value; }
if (!validateSenderId(routeNumber,senderId)) {
alert("The Sender ID (Text message 'From' value) is not valid. \nThis must be either:\n\n1) a shortcode (5 digits, like 60300)\n\n2) alphanumeric (a letter followed by up to 10 letters and numbers, like MyLinks365), or\n\n3) a mobile number, up to 15 digits, like 00447889111000 or 07889111000");
document.frmMain.txtSenderSpecific.focus();
return false;
Infact, let's just delete all of that function.
// this will receive a price in pence & return a string like 57p or £1.45 ...
function formatMessagesPriceFromPence( p ){
p = (Math.round(p * 100))/100; // this is to get around the inaccuracies of javascript where 2.1 * 3 = 6.30000000000001
if(p < 100){
return (p + 'p');
}
else {
if( p % 100 == 0 )
return ( ('£' + (p / 100)) + '.00');
else if( p % 10 == 0 )
return ( ('£' + (p / 100)) + '0');
else
return ( '£' + (p / 100) );
}
Ack, did they mention money?! Better delete that too.
Can you see where things are going? The end result is that I have my own custom piece of code ready to be willingly processed (and trusted) by the server. You can do the above by saving your new page locally or, by using something like Paros and grabbing HTTP requests and responses and trapping them which you can manipulate and then send back. Some SMS companies are clever and use all kinds of tricks like cookie checks, session IDs, etc. so you may have to manipulate these on the fly so that the server will actually process them and not think they are just a random rogue request.
Anyhow, without giving away too much and having every SMS gateway getting owned, I hope you get the general idea. You can spoof sender ID (name), number, etc. (it doesn't even have to be valid!) easily if you think about things mentioned in this article a little more. Anywhere that uses client side code for validation is vulnerable. The end result being free texts which you are able to set the name/number and will be valid on the GSM network. For example, whatever number you spoof, if that number is in a victim's phone book then it will appear to be sent from them. For example, we know 07870123456 exists in Jane's phonebook but we do not know who it is. If we spoof a text with the sender number as that to Jane, whoever she has it down as in her phone book will be assigned to it (i.e. "Bob"). This is not the fault of the phone, it is merely doing it's job by attaching names to defined numbers. Now the text will be completely valid and Jane can even reply, however, the reply will be sent back to the *real* Bob. I am not going to spoon feed how to do this but if you look at the article again in more detail it's pretty obvious.
Anyhow, enjoy... and as always, PROOF OF CONCEPT ONLY (do not do it).
= Free Anonymous SMS Fun
You've all heard of SMS (or Message) Centres right? They're what your texts (or SMS's) go via when you text from your phone. Basically it does some cool things like deal with routing, format, etc. Anyhow, we don't really need to go into that... just as long as you understand what one is that's good enough.
Now, onto Web Gateway APIs. An API stands for application program interface. Think of it as a database of pre-defined commands that allow programmers to be able to talk to much more advanced programs... a go between if you like. For example, Microsoft's Bluetooth stack contains an API that allows programmers to develop their own programs and be able to do bespoke things with the stack. Now, a Web Gateway API is exactly like it sounds; an API accessible on the Internet that forms some kind of gateway to something... the gateway in this case - the SMS centre. It allows developers to write automated scripts and tools to carry out tasks which would otherwise have to be done manually. Now, one thing we know about software development is that you should never ever ever ever trust your inputs. Since this is now accessible on the net, we are very much fucked. Well we're not, but the people who made this internet accessible are. Anyhow...
Why am I talking about SMS Centres and Web Gateway APIs you may ask? Well, this is what all these SMS services that companies on the net use to interact with message centres. Most companies require you to open an account, top up your wallet, etc. in order to send texts. Some will not even be advertised to the public as a service - for example, they may be using the technology for themselves only; to send texts to alert of various system problems, new orders, etc. Whatever they are using it for, they are still fucked in terms of security.
I will concentrate on these companies offering online SMS services as opposed to companies who are using the Web to SMS technology for themselves as they messed up on a bigger scale.
How did they mess up?
Client side validation code.
Why the hell would any developer trust a client to execute client side code properly is beyond me. If you haven't got a clue what I'm on about, let me fill you in. When you fill in a form on a website, it has validation mostly in the form of javascript if you want to be primative. This is executed client side. The proper way of doing it is with say ASP.net and executed by the server. Anyhow... you fill in a form and up comes an error message, "No numbers are allowed in this field, please input your name in alphabetical characters only." This is data validation. The developer has put checks in on each input box so that errors are fixed before the form is actually sent off (or whatever else is going to be done with that data). This is a good thing. However, when relating to things like payment, this is a bad thing. Many online shops have fallen into this mistake by using hidden fields in forms in terms of an item's price. This is executed client side by the user. Therefore, I am able to manipulate the data (and the code) before I send it back to the server to process the request - meaning I get a new tv for 50p. This is what happens when we take advantage of SMS gateways - we change the code to exactly what we want since the server is trusting us!
What does that mean for them?
Well, for starters... let's get rid of this function... or change it slightly. I don't really want the code to be checking if I have enough money in my account if it really doesn't have to, right? ;o)
// Ensure that there's an adequate amount of money in the Wallet if sending Standard rate
walletAmount = document.frmMain.hdnWallet.value;
if ( (walletAmount*100 - costInPence) < 0) { alert("Wallet funds too low - you cannot afford to send these messages.\n\nPlease top up your SMS wallet by at least " + formatMessagesPriceFromPence( costInPence - walletAmount*100 ) + ".\n\n"); return; }
So we delete all that crap.
We don't want to be validating the sender ID, after all, I want to make up my own... that can die too.
// Validate the Sender ID
routeAndCost = document.frmMain.selUKRoute[document.frmMain.selUKRoute.selectedIndex].value.split(",");
routeNumber = routeAndCost[0];
if (document.frmMain.rdoSender[0].checked) { senderId = document.frmMain.txtSenderDefault.value; }
else { senderId = document.frmMain.txtSenderSpecific.value; }
if (!validateSenderId(routeNumber,senderId)) {
alert("The Sender ID (Text message 'From' value) is not valid. \nThis must be either:\n\n1) a shortcode (5 digits, like 60300)\n\n2) alphanumeric (a letter followed by up to 10 letters and numbers, like MyLinks365), or\n\n3) a mobile number, up to 15 digits, like 00447889111000 or 07889111000");
document.frmMain.txtSenderSpecific.focus();
return false;
Infact, let's just delete all of that function.
// this will receive a price in pence & return a string like 57p or £1.45 ...
function formatMessagesPriceFromPence( p ){
p = (Math.round(p * 100))/100; // this is to get around the inaccuracies of javascript where 2.1 * 3 = 6.30000000000001
if(p < 100){
return (p + 'p');
}
else {
if( p % 100 == 0 )
return ( ('£' + (p / 100)) + '.00');
else if( p % 10 == 0 )
return ( ('£' + (p / 100)) + '0');
else
return ( '£' + (p / 100) );
}
Ack, did they mention money?! Better delete that too.
Can you see where things are going? The end result is that I have my own custom piece of code ready to be willingly processed (and trusted) by the server. You can do the above by saving your new page locally or, by using something like Paros and grabbing HTTP requests and responses and trapping them which you can manipulate and then send back. Some SMS companies are clever and use all kinds of tricks like cookie checks, session IDs, etc. so you may have to manipulate these on the fly so that the server will actually process them and not think they are just a random rogue request.
Anyhow, without giving away too much and having every SMS gateway getting owned, I hope you get the general idea. You can spoof sender ID (name), number, etc. (it doesn't even have to be valid!) easily if you think about things mentioned in this article a little more. Anywhere that uses client side code for validation is vulnerable. The end result being free texts which you are able to set the name/number and will be valid on the GSM network. For example, whatever number you spoof, if that number is in a victim's phone book then it will appear to be sent from them. For example, we know 07870123456 exists in Jane's phonebook but we do not know who it is. If we spoof a text with the sender number as that to Jane, whoever she has it down as in her phone book will be assigned to it (i.e. "Bob"). This is not the fault of the phone, it is merely doing it's job by attaching names to defined numbers. Now the text will be completely valid and Jane can even reply, however, the reply will be sent back to the *real* Bob. I am not going to spoon feed how to do this but if you look at the article again in more detail it's pretty obvious.
Anyhow, enjoy... and as always, PROOF OF CONCEPT ONLY (do not do it).