<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 5, 2013 at 6:34 PM, Bryant Zimmerman <span dir="ltr"><<a href="mailto:BryantZ@zktech.com" target="_blank">BryantZ@zktech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="font-family:Tahoma,Geneva,sans-serif;font-size:10pt">When a Message request is sent to an asterisk server the server responds with a 202 before it is sent to the dial plan.<br>
This does not allow for any checks, or throttling prior to the 202 (Accept) of the message. Most sms providers bill based on the 202 response.<br> <br>This is opens major fraud/security as someone could send several thousand sms messages and the customer would be billed with little to no control. Is there a mechanism in place where the 202 is not sent until the message is read or is there some other way to control this. We have already seen abuse around this point. Compromised Google Voice accounts can become an attack platform<br>
<br></span></blockquote><div><br></div><div style>It depends.</div><div style><br></div><div style>If the MESSAGE request is received in dialog, than there's not much Asterisk can do. We've already established a valid call and the MESSAGE request is happening within its context. I doubt that's what's occurring in this case however - if an attacker has already established a valid call with Asterisk, the barbarians are already past the gates, so to speak.</div>
<div style><br></div><div style>For out of call MESSAGE requests, the most appropriate way to prevent this would be to require authentication of MESSAGE requests (in sip.conf, auth_message_requests=yes). This gives MESSAGE requests the same level of protection that INVITE requests have.</div>
<div style><br></div><div style>Currently, however, there is no way to delay the 202 response once the MESSAGE request has been authenticated. The handling of the message request is passed to the Message channel technology to process in the dialplan; this is done asynchronously. From the perspective of the SIP channel driver/XMPP message stack, the message is enqueued and ready to be processed, so they respond with success. There aren't any additional notifications that the Message channel driver passes back to the actual technology channel drivers when it processes the enqueued text message.</div>
<div style><br></div><div style>That being said, I'm not sure how deferring message acceptance/rejection to the dialplan will help if a valid authenticating account is compromised. Generally, the dialplan doesn't afford any additional information in such a case.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>