According to its SIP banner, the version of Asterisk running on the remote host is 11.x prior to 11.25.1, 13.x prior to 13.13.1, 14.x prior to 14.2.1, 11.6 prior to 11.6-cert16, or 13.8 prior to 13.8-cert4. Is it, therefore, affected by an authentication bypass vulnerability in the chan_sip channel driver when handling the content between the SIP header name and a colon character due to incorrect stripping of non-printable ASCII characters. An unauthenticated, remote attacker can exploit this issue, via a specially crafted combination of valid and invalid 'To' headers, to cause a proxy to allow an INVITE request into Asterisk without authentication. This is because, in situations where Asterisk is placed in tandem with an authenticating SIP proxy, the proxy will treats the request as an in-dialog request; however, due to this issue, the request will appear to be an out-of-dialog request to Asterisk, which will then be processed as a new call, thus allowing calls from unauthenticated sources.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14.x before     14.2.1 and Certified Asterisk 11.x before 11.6-cert16 and 13.x before 13.8-cert4. The chan_sip channel     driver has a liberal definition for whitespace when attempting to strip the content between a SIP header     name and a colon character. Rather than following RFC 3261 and stripping only spaces and horizontal tabs,     Asterisk treats any non-printable ASCII character as if it were whitespace. This means that headers such     as Contact\x01: will be seen as a valid Contact header. This mostly does not pose a problem until Asterisk     is placed in tandem with an authenticating SIP proxy. In such a case, a crafty combination of valid and     invalid To headers can cause a proxy to allow an INVITE request into Asterisk without authentication since     it believes the request is an in-dialog request. However, because of the bug described above, the request     will look like an out-of-dialog request to Asterisk. Asterisk will then process the request as a new call.
    The result is that Asterisk can process calls from unvetted sources without any authentication. If you do     not use a proxy for authentication, then this issue does not affect you. If your proxy is dialog-aware     (meaning that the proxy keeps track of what dialogs are currently valid), then this issue does not affect     you. If you use chan_pjsip instead of chan_sip, then this issue does not affect you. (CVE-2016-9938)

Note that Nessus relies on the presence of the package as reported by the vendor.

SIPバナーによると、リモートホストで実行されているAsteriskのバージョンは、11.25.1より前の11.x、13.13.1より前の13.x、14.2.1より前の14.x、11.6-cert16より前の11.6、または13.8-cert4より前の13.8です。したがって、印刷不可能なASCII文字が誤ったストリッピングされているため、SIPヘッダー名とコロン文字の間でコンテンツを処理するときに、chan_sipチャンネルドライバーで認証バイパスの脆弱性の影響を受けます。認証されていないリモートの攻撃者がこれを悪用し、有効および無効な「To」ヘッダーの特別に細工された組み合わせを介して、プロキシが認証なしでAsteriskへのINVITEリクエストを許可できるようにする可能性があります。これは、Asteriskが認証SIPプロキシと並行して配置される状況では、プロキシはそのリクエストをダイアログ内リクエストとして扱うためです。ただし、この問題のために、リクエストはAsteriskへのダイアログ外リクエストであるように見えるので新しいコールとして処理され、認証されていないソースからのコールを許可します。Nessusはこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Asterisk Open Source 11.x より前の 11.25.1、 13.x13.13.1より前の  ]、 14.x より前の 14.2.1 ]、および 11.6-cert16 より前の 、13.8- 13.x cert4より前の の Certified 11.x Asteriskで問題が発見されました。chan_sipチャネルドライバーでは、SIPヘッダー名とコロン文字の間のコンテンツを除去しようとする際の空白に関する定義が曖昧です。Asteriskは、RFC 3261に従ってスペースと水平タブのみを除去するのではなく、印刷不可能なASCII文字を空白であるかのように処理します。これは、Contact\x01: などのヘッダーが有効な Contact ヘッダーとして見なされることを意味します。Asteriskが認証SIPプロキシと連携されるまで、これはほとんど問題になりません。このような場合、リクエストがダイアログ内のリクエストであると判断するため、有効なToヘッダーと無効なToヘッダーを巧妙に組み合わせることにより、プロキシが認証なしでAsteriskへのINVITEリクエストを許可する可能性があります。ただし、上記のバグがあるため、このリクエストはAsteriskに対するダイアログ外のリクエストのように見えます。Asteriskは、新しい呼び出しとしてリクエストを処理します。
    その結果、Asteriskは認証なしで未検証のソースからの呼び出しを処理できます。認証にプロキシを使用しない場合、この問題による影響はありません。使用しているプロキシがダイアログを認識する場合（つまり、プロキシが現在有効なダイアログを追跡している場合）、この問題による影響はありません。chan_sip の代わりに chan_pjsip を使用する場合、この問題は影響を受けません。CVE-2016-9938

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

根據其 SIP 標題，遠端主機上執行的 Asterisk 版本是比 11.25.1 舊的 11.x 版，比 13.13.1 舊的 13.x 版、比 14.2.1 舊的 14.x 版，比 11.6-cert16 舊的 11.6 版，或是比 13.8-cert4 舊的 13.8 版。因此，處理 SIP 標頭名稱和冒號字元之間的內容時，會受到 chan_sip 通道驅動程式中的一個驗證繞過弱點的影響，這是因為錯誤移除非可列印 ASCII 字元所致。未經驗證的遠端攻擊者可惡意利用此問題，透過特製的有效與無效「To」標頭組合，造成 Proxy 允許 INVITE 要求在未經驗證的情況下進入 Asterisk。這是因為同時放置 Asterisk 與驗證 SIP Proxy 時，Proxy 會將要求視為對話內要求；不過，因為有此問題，要求看起來像 Asterisk 對話外要求，並會被當作新呼叫來處理，因而允許來自未經驗證來源的呼叫。請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 在 Asterisk Open Source 11.x 之前的 11.25.1、 13.x13.13.1之前的 [] 以及 [ 14.2.1 之前的 14.x 以及 Certified Asterisk 11.x 11.6-cert16 之前的 以及 13.x 13.8-cert4 之前的 中發現一個問題。嘗試去除 SIP 標頭名稱和冒號字元之間的內容時chan_sip 通道驅動程式對空格有寬鬆的定義。Asterisk 並未遵循 RFC 3261 且僅去除空格和水平索引標籤而是將任何不可列印的 ASCII 字元視為空白字元。這表示如 Contact\x01: 的標頭將被視為有效的 Contact 標頭。在將 Asterisk 與驗證 SIP Proxy 同時放置之前這通常不會造成問題。在這種情況下有效和無效 To 標頭的巧妙組合可造成 Proxy 允許 INVITE 要求在未經驗證的情況下進入 Asterisk因為它認為該要求是對話內要求。不過由於上述錯誤的緣故該要求對於 Asterisk 來說就像是超出對話範圍要求。然後Asterisk 會將此要求視為新的呼叫處理。
    結果是 Asterisk 可以在沒有任何驗證的情況下處理來自未經審查來源的呼叫。如果您不使用 Proxy 進行驗證則此問題不會對您造成影響。如果您的 Proxy 支援對話方塊 (表示 Proxy 會追踪目前有效的對話方塊)則此問題不會對您造成影響。如果您使用的是 chan_pjsip而非 chan_sip則此問題不會對您造成影響。 (CVE-2016-9938)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

根据其 SIP 标题，远程主机上运行的 Asterisk 版本是低于 11.25.1 的 11.x、低于 13.13.1 的 13.x、低于 14.2.1 的 14.x、低于 11.6-cert16 的 11.6，或低于 13.8-cert4 的 13.8。因此，处理 SIP 标头名和冒号字符之间的内容时，由于未正确剥离不可打印的 ASCII 字符，chan_sip 渠道驱动程序中存在验证绕过漏洞。未经身份验证的远程攻击者可利用此问题，通过特制的有效和无效 'To' 标头结合，造成代理允许 INVITE 请求进入 Asterisk 而无需验证。这是由于同时放置 Asterisk 与验证 SIP 代理的情况下，代理将把请求视作对话内请求；然而，由于此问题，请求看似 Asterisk 的对话外请求，随后将处理为新调用，进而允许来自未经身份验证资源的调用。请注意，Nessus 没有测试此问题，而仅依赖于应用程序自我报告的版本号。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 在低于 11.25.1的 Asterisk Open Source 11.x ]、低于 13.13.113.x 的 Asterisk Open Source  、低于 [ 14.2.1 的 14.x 以及低于 11.6-cert16 的 Certified Asterisk 11.x 和低于 13.8-cert4 的 13.x 中发现一个问题。chan_sip 通道驱动程序在尝试剥离 SIP 标头名称和冒号字符之间的内容时对空格存在宽松的定义。Asterisk 并非遵循 RFC 3261 并仅剥离空格和水平制表符而是将任何不可打印的 ASCII 字符视为空格。这意味着像 Contact\x01: 这样的标头将被视为有效的 Contact 标头。在 Asterisk 与认证 SIP 代理同时放置之前这通常不会造成问题。在这种情况下有效与无效的“To”标头的隐蔽组合可能导致代理允许在未经认证的情况下将 INVITE 请求发送到 Asterisk 中因为它认为该请求是对话框内请求。但是由于存在上述缺陷该请求在 Asterisk 中看起来像是对话框外请求。Asterisk 会将该请求作为新的调用进行处理。
    因此Asterisk 无需任何认证即可处理来自未经审查的来源的调用。如果您不使用代理进行身份验证此问题不会对您造成影响。如果您的代理支持对话框感知即代理持续跟踪哪些对话框当前有效则此问题对您没有影响。如果您使用 chan_pjsip 而非 chan_sip此问题对您没有影响。 (CVE-2016-9938)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
95927	Asterisk SIP Channel Authentication Bypass (AST-2016-009)	Nessus	Misc.	2016/12/19	2022/4/11	medium
252398	Linux Distros Unpatched Vulnerability : CVE-2016-9938	Nessus	Misc.	2025/8/20	2025/8/20	medium
95927	Asterisk SIPチャンネル認証バイパス（AST-2016-009）	Nessus	Misc.	2016/12/19	2022/4/11	medium
252398	Linux Distros のパッチ未適用の脆弱性: CVE-2016-9938	Nessus	Misc.	2025/8/20	2025/8/20	medium
95927	Asterisk SIP Channel Authentication Bypass (AST-2016-009)	Nessus	Misc.	2016/12/19	2022/4/11	medium
252398	Linux Distros 未修補的弱點：CVE-2016-9938	Nessus	Misc.	2025/8/20	2025/8/20	medium
95927	Asterisk SIP Channel Authentication Bypass (AST-2016-009)	Nessus	Misc.	2016/12/19	2022/4/11	medium
252398	Linux Distros 未修补的漏洞：CVE-2016-9938	Nessus	Misc.	2025/8/20	2025/8/20	medium

検出

プラグインの検索

medium

medium

medium

medium

medium

medium

medium

medium