[asterisk-dev] Dialstring injection - security advisory release?

Tue Feb 23 02:47:41 CST 2010

Summary:
README-SERIOUSLY.txt  might need a bit of adjusting - doesn't seem to work
as expected the suggestion.  Who tested it?
exten = _X.,n,Dial(SIP/${FILTER(0-9,${EXTEN})}) - will stop the calls (all
of them)
exten = _X.,n,Dial(SIP/${FILTER(${EXTEN})}) - turns ${EXTEN} to an empty
string
exten = _X.,n,Dial(SIP/${EXTEN}) - exploit is executed as expected when
${EXTEN}

Rant:
G'day list,

It's late, and my better half rang about an hour ago to come home.  I said
20 minutes, she said 10.  So either way, I've gotta do some sweet-talking
(luckily I've eaten, otherwise it's cooking as too)

Here is my test dialplan code:

[test-exploit2]
exten = _X.,1,NoOp(################ TEST THAT THREAT)
exten = _X.,n,NoOp(################ TEST THAT THREAT)
exten = _X.,n,NoOp(################ TEST THAT THREAT)
exten = _X.,n,NoOp(################ TEST THAT THREAT)
exten = _X.,n,NoOp(################ EXTEN: ${EXTEN})
exten = _X.,n,Dial(SIP/${FILTER(0-9,${EXTEN})})
exten = _X.,n,Hangup

Here is the asterisk CLI output.  My dialstring was
7878&SIP/MYPROVIDER/0433998648 which got filtered down to 78780433998648 -
so at least there's no toll fraud.

I've got to say, for my first test - this appears to be a really hard thing
to crack into.
1.  You have to know the outbound trunk you want to target - Zap/g0 would be
the easiest.  SIP/IAX2 you'd have to guess the trunk name.
2.  _X. has to be in the dialplan.
3.  _1123X.  is not subject to this expoit.  Only _X.
4.  Anonymous calling or a pretty insecure box would have to be available.
Weak passwords would probably have to be the shortest route to getting entry
into a box to have a shot at running this exploit.

ASTERISK CLI:
    -- Executing [7878&SIP/ENGIN/0433998648 at test-exploit2:1]
NoOp("SIP/7801-00000047", "################ TEST THAT THREAT") in new stack
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:2]
NoOp("SIP/7801-00000047", "################ TEST THAT THREAT") in new stack
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:3]
NoOp("SIP/7801-00000047", "################ TEST THAT THREAT") in new stack
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:4]
NoOp("SIP/7801-00000047", "################ TEST THAT THREAT") in new stack
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:5]
NoOp("SIP/7801-00000047", "################ EXTEN:
7878&SIP/MYPROVIDER/0433998648")
in new stack
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:6]
Dial("SIP/7801-00000047", "SIP/78780433998648") in new stack
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [7878&SIP/MYPROVIDER/0433998648 at test-exploit2:7]
Hangup("SIP/7801-00000047", "") in new stack

I'd prepare something a little more nicely laid out - but I wanna GTFO :)

All the talk of "safe" equivalents makes me think of my safe word -
blueberry muffins!

Don't hate on me for trying to be funny ;)

Cheers
Chris

On Tue, Feb 23, 2010 at 6:29 PM, Pavel Troller <patrol at sinus.cz> wrote:

> >
> >
> > Am 22.02.2010 20:01, schrieb Atis Lezdins:
> > > On Mon, Feb 22, 2010 at 4:38 PM, Nick Lewis<Nick.Lewis at atltelecom.com>
>  wrote:
> > ..
> > >> I accept that such a change may add work for those dialplan
> programmers
> > >> that use 'strange' characters in their extensions but I suspect that
> it
> > >> may reduce the work of most dialplan programmers who do not use
> > >> 'strange' characters in their extensions and are just wanting to make
> > >> their dialplans secure
> > >>
> > >
> > > Isn't the problem solved by using exact dialplan patterns only
> > > allowing numbers or alpha-numeric characters? I have all calls going
> > > through strict mask pattern, for example:
> > >
> > > _XXXXX =>  internal calls
> > > _18XXXXXXXXX =>  toll free calls
> > >
> > > etc.
> > >
> > > The problem is only when somebody uses mask "_X." everywhere. As for
> > > security "." could change meaning to "any alpha-numeric character"
> > > (with setting to reverse functionality for those who really want weird
> > > extensions), plus introduce a new symbol (let's assume question mark
> > > "?") to match zero or more digits only. So, samples and everything
> > > else could use _X? which is safe at very beginning. Additionally if
> > > necessary backward compatible any-character could be allowed by new
> > > symbol.
> > >
> > > So:
> > >
> > > _X? =>  Dial(SIP/${EXTEN}) ; - safe, accepts only digits
> > > _X. =>   Dial(SIP/${EXTEN}) ; - safe, accepts only [0-9a-zA-Z#*]
> > > _X* =>   Dial(SIP/${FILTER(${EXTEN})}) ; - also safe, bad characters
> > > are filtered out
> > > _X* =>   Dial(SIP/${EXTEN}) ; - not safe. Documentation should issue
> > > warning next to this, asking to re-consider and use only in
> > > combination with FILTER()
> >
> > This was already suggested by several other people, but not yet
> > implemented :-(
> >
> > regards
> > klaus
> >
> Hi!
>  Please also don't forget, that now we have two pattern matchers, i.e.
> ".", which collects digits, and "!", which triggers as soon as the match is
> complete, so we need TWO new symbols for their "safe" equivalents.
>
> With regards, Pavel.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100223/8d8796be/attachment.htm 