[Home]

Summary:ASTERISK-24972: Transport Layer Security (TLS) Protocol BEAST Vulnerability - Investigate vulnerability of HTTP server
Reporter:Alex A. Welzl (awelzl)Labels:
Date Opened:2015-04-17 05:04:39Date Closed:2016-02-03 15:11:32.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_http_websocket
Versions:13.2.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:[Edit by Rusty - We don't appear to be vulnerable to CRIME, but should investigate vulnerability to BEAST]

According to the security scan, the built-in Webserver seems to be vulnerable.
There are no settings to enable/disable anything beside ciphers.

tlsclientmethod=tlsv1
tlscipher=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5

Only solution seems to be to put a NGIX proxy in front of the Asterisk (e.g. http://nginx.com/blog/websocket-nginx/)

Nessus and Acunetix discovered following Medium vulnerability, please investigate if SSL / TLS compression can be disabled.

Description
The remote service has one of two configurations that are known to be required for the CRIME attack :

 SSL / TLS compression is enabled.
 TLS advertises the SPDY protocol earlier than version 4.

Note that Nessus did not attempt to launch the CRIME attack against the remote service.

Solution
Disable compression and / or the SPDY service.

See Also
http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091
https://discussions.nessus.org/thread/5546
http://www.nessus.org/u?8ec18eb5
https://issues.apache.org/bugzilla/show_bug.cgi?id=53219

Output
The following configuration indicates that the remote service
may be vulnerable to the CRIME attack :
- SSL / TLS compression is enabled.
Host: X.X.X.130
Port: 8089 / tcp / www
Comments:By: Matt Jordan (mjordan) 2015-04-17 12:03:04.515-0500

Locking this issue down.

Note that by filing an issue in the project, this has now been made public. That puts all Asterisk users at risk.

In the future, please read the instructions on filing security issues. There is a dedicated mailing list to prevent disclosures such as this.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Vulnerabilities

By: Matt Jordan (mjordan) 2015-04-17 13:16:02.795-0500

I went ahead and tested this using {{TestSSLServer}} - http://www.bolet.org/TestSSLServer/ - which is a tool that checks a server for TLS versions and compression. As it turns out, we are *not* vulnerable to CRIME.

This is not surprising, since we do not enable compression anywhere in Asterisk's {{TCP/TLS}} core ({{tcptls.c}}). Because compression has to be enabled in OpenSSL (and OpenSSL must be compiled to support it), a 'stock' Asterisk installation will not be vulnerable to that attack.

Unfortunately, Asterisk's HTTP server *is* vulnerable to Beast, as there is no particular setting in {{http.conf}} to limit the offered TLS cipher suites to only 1.2. As a result, the vulnerable cipher suite of 1.0 is offered, making it vulnerable to that attack.

{code}
Supported versions: TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
 TLSv1.0
    RSA_WITH_RC4_128_MD5
    RSA_WITH_RC4_128_SHA
    RSA_WITH_DES_CBC_SHA
    RSA_WITH_3DES_EDE_CBC_SHA
    RSA_WITH_AES_128_CBC_SHA
    RSA_WITH_AES_256_CBC_SHA
    RSA_WITH_CAMELLIA_128_CBC_SHA
    RSA_WITH_CAMELLIA_256_CBC_SHA
    TLS_RSA_WITH_SEED_CBC_SHA
    TLS_ECDHE_RSA_WITH_RC4_128_SHA
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 (TLSv1.1: idem)
 TLSv1.2
    RSA_WITH_RC4_128_MD5
    RSA_WITH_RC4_128_SHA
    RSA_WITH_DES_CBC_SHA
    RSA_WITH_3DES_EDE_CBC_SHA
    RSA_WITH_AES_128_CBC_SHA
    RSA_WITH_AES_256_CBC_SHA
    RSA_WITH_AES_128_CBC_SHA256
    RSA_WITH_AES_256_CBC_SHA256
    RSA_WITH_CAMELLIA_128_CBC_SHA
    RSA_WITH_CAMELLIA_256_CBC_SHA
    TLS_RSA_WITH_SEED_CBC_SHA
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_RC4_128_SHA
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
----------------------
Server certificate(s):
 64a064967228afeeaf3b5e6af08c34199171c47a: EMAILADDRESS=mjordan@digium.com, CN=mjordan-laptop.digium.internal, O=Digium, L=Huntsville, ST=AL, C=US
----------------------
Minimal encryption strength:     medium encryption (56-bit)
Achievable encryption strength:  strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: protected
{code}

As a result, I'm going to go ahead and accept this as a valid vulnerability, but not for the one you thought we were vulnerable to.

Again, and I can't stress this enough, responsible disclosure means you should be sure that you are not releasing a vulnerability into the wild when you report it. A public issue tracker is clearly ... public. In the future, please e-mail the security mailing alias (security@asterisk.org) or - at the last - e-mail the project mailing lists stating that you believe you have found a vulnerability and would like to discuss it with a member of the core team. Failing to be responsible when disclosing security vulnerabilities puts everyone at risk, and forces the development team to respond in a fashion that injects risk into the security releases.

By: Alex A. Welzl (awelzl) 2015-04-17 13:36:08.234-0500

It was completely my fault filing that request on the issue tracker. Sorry for that and thanks for your fast reaction! The next beer is on me! ;-)

By: Matt Jordan (mjordan) 2015-04-17 15:20:56.891-0500

We may not be vulnerable to BEAST either, since {{http.conf}} has an undocumented way to specify the TLS cipher. I'm still investigating that.

By: Michael Spiceland (mspiceland) 2015-12-16 16:32:51.320-0600

Alex,  thank you very much for the help and your patience.  I'm following up on this issue to let you know that we're planning on doing the security release in January, after the Asterisk 13.7 release.  I'll be able to give a more specific date closer to the actual date.