[asterisk-bugs] [JIRA] (ASTERISK-26433) chan_sip: Allows To-tag checks to be bypassed, setting up new calls
George Joseph (JIRA)
noreply at issues.asterisk.org
Mon Feb 6 10:34:24 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
George Joseph updated ASTERISK-26433:
-------------------------------------
Target Release Version/s: 13.14.0
> chan_sip: Allows To-tag checks to be bypassed, setting up new calls
> -------------------------------------------------------------------
>
> Key: ASTERISK-26433
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26433
> Project: Asterisk
> Issue Type: Bug
> Components: Channels/chan_sip/Interoperability
> Reporter: Walter Doekes
> Labels: Security
> Target Release: 11.25.1, 13.13.1, 13.14.0, 14.2.1
>
> Attachments: ASTERISK-26433_hcolon_skip_only_sp_htab-master.patch, ASTERISK-26433_hcolon_skip_only_sp_htab-v11.patch, ASTERISK-26433_hcolon_skip_only_sp_htab-v13.patch, ASTERISK-26433_hcolon_skip_only_sp_htab-v14.patch
>
>
> (Sorry for yet another chan_sip issue. Along with a pesky retransmit issue
> it's probably time to start moving some stuff towards pjsip. This is
> basically a rerun of ASTERISK-4991 and a good reason why pedantic
> was switched to yes by default in 2787a1400.)
> h2. Issue
> chan_sip treats some control characters as blanks, while many proxies
> treat non-space control characters as regular tokens.
> In certain setups with an authenticating proxy in front of Asterisk,
> this discrepancy can allow an attacker to bypass the authentication.
> Requirements:
> * A dialog unaware authenticating proxy in front of Asterisk.
> * Trust between the proxy and Asterisk that the proxy has handled the
> authentication.
> * Inside information of IP-addresses and valid account names; can be
> obtained by looking at a single authenticated call.
> h2. Steps to reproduce
> *Step #1:*
> * Install Kamailio or any other proxy.
> * kamailio.cfg -- this is a minimal script which conveys the general idea:
> authenticate new dialogs, pass in-dialog requests along without auth.
> {noformat}
> mpath="/usr/local/lib/kamailio/modules_k/:/usr/lib/x86_64-linux-gnu/kamailio/modules/"
> loadmodule "tm.so" # must be loaded first
> loadmodule "auth.so"
> loadmodule "pv.so"
> loadmodule "rr.so"
> loadmodule "siputils.so"
> loadmodule "sl.so"
> loadmodule "xlog.so"
> # Main route block
> route {
> route(WITHINDLG);
> route(NEWDLG);
> }
> # Handle new SIP dialogs
> route[NEWDLG] {
> # username must be: myuser or myser2
> if ($fU == "myuser" || $fU == "myuser2") {
> # password must be: mypassword
> $avp(password) = "mypassword";
> if (!pv_proxy_authenticate("$fd", "$avp(password)", "0")) {
> proxy_challenge("$fd", "1");
> exit;
> }
> consume_credentials();
> # pass it along
> $du = "sip:127.0.0.1:5070";
> record_route();
> route(RELAY);
> }
> # or deny
> sl_send_reply("403", "Nope");
> }
> # Handle requests within SIP dialogs
> route[WITHINDLG] {
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> route(RELAY);
> } else if ($rm == "ACK") {
> if (t_check_trans()) {
> route(RELAY);
> }
> exit;
> } else {
> sl_send_reply("404", "Not here");
> }
> exit;
> }
> }
> # Pass it along
> route[RELAY] {
> xlog("$rm $fU -> $du/$ru\n");
> t_relay();
> exit;
> }
> {noformat}
> * Two users are defined in the script (myuser and myuser2) and a
> password (mypassword).
> *Step #2:*
> * Install Asterisk
> * sip.conf
> {noformat}
> [general]
> udpbindaddr=127.0.0.1:5070
> [proxyuser](!)
> host=127.0.0.1
> port=5070
> type=user
> [myuser](proxyuser)
> callerid=Alice
> [myuser2](proxyuser)
> callerid=Bob
> {noformat}
> * extensions.conf
> {noformat}
> [default]
> exten => 123,1,NoOp(Call from ${CHANNEL(peername)} (${CALLERID(name)}) to ${EXTEN})
> same => n,Answer()
> same => n,Wait(1)
> same => n,Hangup()
> {noformat}
> *Step #3:*
> * Test that our calls are authenticated, for example using
> https://github.com/ossobv/sipp-scenarios/blob/master/out-in/oinv-i200-ibye.xml
> and this SIPp command:
> {{sipp -sf oinv-i200-ibye.xml -m 1 -s myuser2 -ap mypassword localhost -key tel 123}}
> {noformat}
> -- Executing [123 at default:1] NoOp("SIP/myuser2-00000003", "Call from myuser2 (Bob) to 123") in new stack
> -- Executing [123 at default:2] Answer("SIP/myuser2-00000003", "") in new stack
> -- Executing [123 at default:3] Wait("SIP/myuser2-00000003", "1") in new stack
> -- Executing [123 at default:4] Hangup("SIP/myuser2-00000003", "") in new stack
> {noformat}
> _Sounds safe, right?_
> * The proxy does the authentication so that Asterisk does not have to.
> * For new dialogs (no to-tag) the proxy authenticates.
> * For existing dialogs (a to-tag and Route headers) the proxy passes
> all SIP along to Asterisk.
> * For a new dialog, if you send a to-tag and the right Route headers,
> the proxy would pass it along, but Asterisk will return a 481 because
> it is an unknown dialog *with* a to-tag.
> However, if you abuse the different treatment of "blanks" between the
> proxy and Asterisk, you can let a To-header without a to-tag slip
> through, causing the proxy to think that it's an existing
> (authenticated) call while Asterisk thinks it's a new call -- which now
> has bypassed authentication.
> Something like this:
> {noformat}
> INVITE sip:[tel]@[ua_ip] SIP/2.0
> Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
> Route: <sip:[remote_ip];lr;ftag=4035SIPpTag001>
> Record-Route: <sip:[remote_ip];lr;ftag=4035SIPpTag001>
> ...
> To\x01: sip:[tel]@[remote_ip]:[remote_port]
> To: sip:[tel]@[remote_ip]:[remote_port];tag=TAG_SO_WE_ARE_FORWARDED
> {noformat}
> The proxies will happily pass it along as an in-dialog transaction, because
> the To-header has a tag.
> chan_sip will see the first broken {{To\x01:}} (in pedantic mode) as {{To:}}
> and now it's suddenly an out-of-dialog transaction and sets up a new call.
> h2. Suggested fix:
> Replace the {{ast_skip_blanks()}} in {{__get_header()}} with something
> that only skips SP/HTAB.
> Cheers,
> Walter Doekes
> OSSO B.V.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list