sr-users

sr-users@lists.kamailio.org

9 participants
37392 discussions

Kamailio Slack Channel Invite
by Peter Baines 23 Sep '20

23 Sep '20

Hi, Can someone send me an invite to the Kamailio Slack channel please. I am sure I used to be a member but I may have used a different email address. Apologies if this is not the correct place to post. Regards, Peter -- *Web:* http://pbaines.com *Email:* peter(a)pbaines.com

4 4

Kamailio vulnerable to header smuggling possible due to bypass of remove_hf
by Sandro Gauci 23 Sep '20

23 Sep '20

Dear Kamailio Users, posting our security advisory here just in case anyone who was affected has not upgraded or mitigated the header smuggling issue. Advisory follows: # Kamailio vulnerable to header smuggling possible due to bypass of remove_hf - Fixed versions: Kamailio v5.4.0 - Enable Security Advisory: <https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio…> - Tested vulnerable versions: 5.3.5 and earlier - Timeline: - Report date & issue patched by Kamailio: 2020-07-16 - Kamailio rewrite for header parser (better fix): 2020-07-16 to 2020-07-23 - Kamailio release with fix: 2020-07-29 - Enable Security advisory: 2020-09-01 ## Description Kamailio is often configured to remove certain special internal SIP headers from untrusted traffic to protect against header injection attacks by making use of the `remove_hf` function from the Kamailio `textops` module. These SIP headers were typically set through Kamailio which are then used downstream, e.g. by a media service based on Asterisk, to affect internal business logic decisions. During our tests and research, we noticed that the removal of these headers can be bypassed by injecting whitespace characters at the end of the header name. Note that this issue only affected header names that are __not__ defined in `src/core/parser/hf.h`. Further discussion and details of this vulnerability can be found at the Communication Breakdown blog: https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/. ## Impact The impact of this security bypass greatly depends on how these headers are used and processed by the affected logic. In a worst case scenarios, this vulnerability could allow toll fraud, caller-ID spoofing and authentication bypass. ## How to reproduce the issue We prepared a docker-compose environment to demonstrate a vulnerable setup which can be found at <https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio…>. The following python code could then be used to reproduce the issue: ```python #!/usr/bin/env python3 sipmsg = "INVITE sip:headerbypass@localhost SIP/2.0\r\n" sipmsg += "Via: SIP/2.0/UDP 127.0.0.1:48017;rport;branch=z9hG4bK-%s\r\n" sipmsg += "Max-Forwards: 70\r\n" sipmsg += "From: <sip:anon@localhost>;tag=%s\r\n" sipmsg += "To: sip:whatever@whatever.local\r\n" sipmsg += "Call-ID: %s\r\n" sipmsg += "CSeq: 1 INVITE\r\n" sipmsg += "Contact: <sip:1000@127.0.0.1:48017;transport=udp>\r\n" sipmsg += "X-Bypass-me : lol\r\n" sipmsg += "Content-Length: 237\r\n" sipmsg += "Content-Type: application/sdp\r\n" sipmsg += "\r\n" sipmsg += "v=0\r\n" sipmsg += "o=- 1594727878 1594727878 IN IP4 127.0.0.1\r\n" sipmsg += "s=-\r\n" sipmsg += "c=IN IP4 127.0.0.1\r\n" sipmsg += "t=0 0\r\n" sipmsg += "m=audio 58657 RTP/AVP 0 8 96 101\r\n" sipmsg += "a=rtpmap:101 telephone-event/8000/1\r\n" sipmsg += "a=rtpmap:0 PCMU/8000/1\r\n" sipmsg += "a=rtpmap:8 PCMA/8000/1\r\n" sipmsg += "a=rtpmap:96 opus/8000/2\r\n" sipmsg += "a=sendrecv\r\n" target = ("127.0.0.1",5060) import socket import time from random import randint s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM) s.bind(("0.0.0.0",5088)) r = randint(1000,9999) data = sipmsg % (r,r,r) s.sendto(data.encode("utf-8"), target) while True: data,addr=s.recvfrom(4096) print(data.decode("utf-8")) time.sleep(5) ``` In the case of a vulnerable version of Kamailio, Asterisk would respond with a 200 OK while in a fixed version, Asterisk would respond with a 603 Decline response. This is specific to the [dialplan](https://github.com/EnableSecurity/advisories/blob/master/ES2020-0… in our example, which jumps to an internal dialplan if the `X-bypass-me` header is found. ## Solutions and recommendations The official Kamailio fix has been tested and found to sufficiently address this security flaw. We recommend making use of the latest release or backporting the fixes where possible. Making use of regular expressions to cover white-space characters with `remove_hf_re` has been suggested as mitigation for this issue for cases where the code cannot be upgraded. Enable Security would like to thank Daniel-Constantin Mierla of the Kamailio Project for the very quick response and fix within minutes of our report being made available to him, as well as Torrey Searle for reporting this issue quickly to the Kamailio team. ## About Enable Security [Enable Security](https://www.enablesecurity.com) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack. ## Disclaimer The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ## Disclosure policy This report is subject to Enable Security's vulnerability disclosure policy which can be found at <https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy>.

10 33

Kamailio drop calls with Teams
by sip user 22 Sep '20

22 Sep '20

Hi, I'm connecting Teams with kamailio server. From Kamailio to teams I have no problems, but from teams to Kamailio yes. Drop the call.. With ngrep I see that: INVITE sip:1005@CLIENT_IP:55766;transport=UDP;rinstance=d47edf336726e940 SIP/2.0. Record-Route: <sip:FQND_IP;r2=on;lr>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. FROM: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. TO: <sip:+34560@FQND:5061;user=phone>. CSEQ: 1 INVITE. CALL-ID: c1364913e582553a9a9c2544c3583b0a. MAX-FORWARDS: 69. Via: SIP/2.0/UDP 92.222.217.64;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. VIA: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. RECORD-ROUTE: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. CONTACT: <sip:api-du-a-euno.pstnhub.microsoft.com:443 ;x-i=b0b53fc5-76ef-4619-9a68-13e0a4eea92d;x-c=c1364913e582553a9a9c2544c3583b0a/d/8/6c25eb3789a14bf188ce6b05b5e27891>. CONTENT-LENGTH: 1091. MIN-SE: 300. SUPPORTED: timer. USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.7.31.1 i.EUNO.0. CONTENT-TYPE: application/sdp. ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY. P-ASSERTED-IDENTITY: <tel:+324>,<sip:EMAIL>. PRIVACY: id. SESSION-EXPIRES: 3600. . v=0. o=- 165103 0 IN IP4 127.0.0.1. s=session. c=IN IP4 52.113.44.8. b=CT:10000000. t=0 0. m=audio 50452 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118. c=IN IP4 52.113.44.8. a=rtcp:50453. a=ice-ufrag:FZTb. a=ice-pwd:yD3P7nr+xNq0VYdv7xpB1F+Y. a=rtcp-mux. a=candidate:1 1 UDP 2130706431 52.113.44.8 50452 typ srflx raddr 10.0.33.240 rport 50 U CLIENT_IP:55766 -> FQND_IP:5060 #2 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP FQND_IP;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. Via: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. Record-Route: <sip:FQND_IP;lr;r2=on>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. Record-Route: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. Contact: <sip:1005@CLIENT_IP :55766;transport=UDP;rinstance=d47edf336726e940>. To: <sip:+34560@FQND:5061;user=phone>;tag=de4e6b45. From: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. Call-ID: c1364913e582553a9a9c2544c3583b0a. CSeq: 1 INVITE. User-Agent: 3CXPhone 6.0.26523.0. Content-Length: 0. U CLIENT_IP:55766 -> FQND_IP:5060 #3 SIP/2.0 200 OK. Via: SIP/2.0/UDP FQND_IP;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. Via: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. Record-Route: <sip:FQND_IP;lr;r2=on>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. Record-Route: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. Contact: <sip:1005@CLIENT_IP :55766;transport=UDP;rinstance=d47edf336726e940>. To: <sip:+34560@FQND:5061;user=phone>;tag=de4e6b45. From: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. Call-ID: c1364913e582553a9a9c2544c3583b0a. CSeq: 1 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: 3CXPhone 6.0.26523.0. Content-Length: 1067. . v=0. o=3cxVCE 324945090 117647850 IN IP4 . s=3cxVCE Audio Call. t=0 0. m=audio 0 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118. c=IN IP4 52.113.44.8. a=rtpmap:104 SILK/16000. a=rtpmap:9 G722/8000. a=rtpmap:103 SILK/8000. a=rtpmap:111 SIREN/16000. a=fmtp:111 bitrate=16000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:97 RED/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=rtpmap:118 CN/16000. a=rtcp:50453. a=ice-ufrag:FZTb. a=ice-pwd:yD3P7nr+xNq0VYdv7xpB1F+Y. a=rtcp-mux. a=candidate:1 1 UDP 213 I never received ACK.. In my configuration: Kamailio.cfg: #!KAMAILIO #!define WITH_TLS event_route[tm:local-request] { if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") { append_hf("Contact: <sip:FQND:5061;transport=tls>\r\n"); } xlog("L_INFO", "Sent out tm request: $mb\n"); } request_route{ remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { xlog("L_INFO","$fU is trying to call to $rU con valores $tu\n"); $rU="1005"; } } What I'm doing wrong? I don't understand why not received ACK.. Could anyone help me? Thanks

5 21

Kambdctl create command
by Pavithra Mohanraja 22 Sep '20

22 Sep '20

Hi, I need to use kambdctl create command but that has to create database in another vm where mysql is alone installed. How to do that? Thanks, Pavithra

2 1

Kamailio Slack Invite
by Peter Baines 22 Sep '20

22 Sep '20

Hi, Can someone send me an invite to the Kamailio Slack channel please. I am sure I used to be a member but I may have used a different email address. -- *Web:* http://pbaines.com *Email:* peter(a)pbaines.com

4 4

Info: recordings of Kamailio World 2020 sessions
by Daniel-Constantin Mierla 22 Sep '20

22 Sep '20

Hello, for those that couldn't attend the Kamailio World 2020 online event that happened a few weeks ago, or someone wants to view again a session, the recordings of the two days were split per session -- they are available on KamailioWorld youtube channel: * https://www.youtube.com/c/KamailioWorld/ For convenience, they were also grouped in a playlist for KW2020, see: * https://www.youtube.com/c/KamailioWorld/playlists No other editing than just cutting at start/stop of each session. Slides should be available at: * http://kamailio.org/events/2020-KamailioWorldOnline/ Enjoy! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Error on ACK/BYE After 200
by Neimar 21 Sep '20

21 Sep '20

Hello, I am trying to set up a Webrtc by using Kamailio, Asterisk and Rtpengine. So far, everything is working fine , I'm able to register an extension and make a call, but for some reason, when i'm trying to call a WebRTC extension from any SIP Extension from Asterisk, Kamailio is sending INVITE, WebRTC extension is sending back 200 OK, and then Kamailio is trying to send an ACK through UDP protocol, and not through wss, as it's supposed to do. In console, I see: Sep 21 20:39:06 vsphone3-sbc /usr/sbin/kamailio[9756]: WARNING: {1 102 ACK 332ee81b4eb178ac156e8d3e53a98900@172.16.11.6:5060} <core> [core/forward.c:231]: get_send_socket2(): protocol/port mismatch (forced tls:172.16.11.57:8443, to udp:187.20.56.83:27730) My scenario is: Internet -> Firewall -> Kamailio -> Asterisk Working: Softphone -> Kamailio -> Asterisk (TCP/UDP/TLS(SRTP) Asterisk -> Kamailio -> Softphone (TCP/UDP/TLS(SRTP)) Webrtc -> Kamailio -> Asterisk (WSS) Not Working: Asterisk -> Kamailio -> Webrtc After a answer from Webrtc, I can listen sound, so, RTP in theory is fine. Webrtc send 200 OK to Kamailio Kamailio Send 200 OK to Asterisk. Asterisk Send ACK to Kamailio ACK not forwarded to Webrtc. In attachment, my kamailio.cfg Every Help is welcome. Thanks Neimar.

1 0

Kamailio uses Python
by Pavithra Mohanraja 21 Sep '20

21 Sep '20

Hi, I am building kamailio as an docker image by installing kamailio using "apt-get install kamailio" in ubuntu 18.04, which installs python by default which makes my image size bigger. Does kamailio uses Python?. else what could be the alternative? Does anybody came across this situation. Kindly advise. Thanks, Pavithra

2 3

Kamailio IF Routes
by conradcordeiro＠gmail.com 21 Sep '20

21 Sep '20

Hello, Is it possible to set up Kamailio 5.4.1 to use IF to determine how calls are proxied depending on the source of the request? For example, *_if_* calls originate from /pstn.us1.twilio.com/ then _/$du = "sip01.example.com:5060"/_, wheres _*if*_ calls originate from /pstn.us2.twilio.com/ then _/$du = "sip01.example.com:5060"/_. Additionally, would this also be possible based on numbers? For example, _*if*_ calls are to number +1-800-777-8888 then /$du = "sip01.example.com:5060"/, or if calls are to number +1-800-777-9999 then /$du = "sip02.example.com:5060"/. To be clear, I don't expect both examples above to work in the same Kamailio instance but IF and AND clauses are possible, such as _*if*_ calls are to number +1-800-777-8888 AND from /pstn.us1.twilio.com/ then _/$du = "sip01.example.com:5060"/_, it'd be great to test this too. I'm not sure if I'm allowed to ask such specific questions on this mailing list and I hope I'm not asking too much. Many thanks, Conrad

3 4

SRTP/TLS BYE Problem with One of the Legs of the Call
by conradcordeiro＠gmail.com 20 Sep '20

20 Sep '20

Hello, Thank you for your reading this and for your help. I'm a Kamailio newbie and managed to set up an edge proxy, which works perfectly on UDP traffic. I'm now attempting to deploy TLS/SRTP and everything almost works perfectly. The single issue I'm having is that when either of the parties to an SRTP/TLS call disconnect, the other party's call remains active. With UDP, when one of the parties disconnects the call, the other leg of the call receives the BYE command and the call automatically disconnects. This is how I have our infrastructure set up: 1. Twilio SIP Trunk with Secure Media enabled. 2. Kamailio 5.4.1 set up with TLS module, set to listen on TLS port 5061, SSL certificates from Let's Encrypt, route set to our phone system. 3. Phone system is Asterisk. As per above, everything works almost perfectly with TLS/SRTP. The only issue is that calls will not disconnect when one of the sides hang up. If I disable TLS/SRTP and use UDP only, everything works. Audio is just fine with TLS/SRTP. Does anyone know why calls with SRTP/TLS will not disconnect automatically when one of the parties ends the call? Thank you, Conrad

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users