[asterisk-dev] Message Responding with 202? Potential Abuse!

[Matthew Jordan]

On Mon, Aug 5, 2013 at 6:34 PM, Bryant Zimmerman <BryantZ at zktech.com> wrote:

> When a Message request is sent to an asterisk server the server responds
> with a 202 before it is sent to the dial plan.
> 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.
>
> 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
>
>
It depends.

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.

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.

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.

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.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130807/18c9d7d2/attachment.htm>