Critical OpenSSL bug in VCS (and others) CVE-2014-0160

[Martin Koch]

Hello there is a critical bug in openssl:

https://www.openssl.org/news/secadv_20140407.txt

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160

which also affects Cisco products, incl at least the VCS:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

I further used a test tool and also got positive hits of that error on the conductor as well as on the web interface of TC7.1

(though a second test tool was not sure about the TC).

What I recommend:

* inform your local IT / security team

* check which components in your network use affected versions of openssl, there are also tools which you can use to connect to your

devices to see if they are affected. *1)

* regenerate the key and the cert so possibly old sniffed communication could not be decoded (if the attacker does not have the old key now anyhow)

* upgrade the affected components as fast as possible. You might need to contact your vendor to get an upgrade for your product

* regenerate keys and reissue certificates

* revoke old certificates

* change passwords

I also noticed that there are many VCS out which use the standard TANDBERG certificate.  Thats bad anyhow.

Please generate your own certs and best, get them signed by a proper CA.

This document will help you about that:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-1.pdf

*1)

Perl: https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl

Metasploit: https://github.com/rapid7/metasploit-framework/pull/3206

NMAP: http://nmap.org/nsedoc/scripts/ssl-heartbleed.html

OpenVaS: https://gist.github.com/RealRancor/10140249

Nessus: http://www.tenable.com/plugins/index.php?view=single&id=73412

xkcd: http://xkcd.com/1353/

As this is a critical security issue, just a short disclaimer, this is an unofficial warning, please contact

your local IT / security advisors. The information here is collected from Internet postings and is best effort.

All information, links and procedures are handled on your own risk. ;-)

The official Cisco site for this is the PSIRT (Product Security Incident Response Team) http://www.cisco.com/go/psirt

[Justin Ferello]

Martin,

You do realize that one cannot just upgrade OpenSSL on the VCS, endpoints or Conductor, right?  We would need Cisco to update the version an issue a whole new package....

The security document was not very helpful.  Anyone have any idea what versions of software are affected in the VCS and if and when there will be a fix?

Thanks,

Justin

[Martin Koch]

I did not say upgrade openssl or compile it yourself ;-)

I said upgrade components as fast as possible, on appliances the vendor is in general the

one to provide the upgrades. I ll try to fix my text ;-)

If you google for openssl bug heartbeat you will find a lot more info about the issue and how to test your components.

There are some test tools like:

https://github.com/FiloSottile/Heartbleed

https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl

I am not so sure if I would use the online tests as they would not work towards you internal systems

and you do not know what these sites will do with the information which they gather, ...

For now I would say it does not matter if there is a stone age old VCS which does not have

this bug as they have other issues.

I had tested it at least towards X7.2.2 and X8.1 and they are affected.

With the X8.1 incompatibility for the traversal zone I really want to see that there is a fix for the X7 tree as well. And like you said, Cisco (and all other vendors) shall react quick.

[Nick Halbert-Lillyman]

Or, even better, release a new version of 8.1.x with OpenSSL fix and backward compatibility option :)

[Wayne DeNardi]

+5 to that!

PS - There's now a security advisory for this: cisco-sa-20140409-heartbleed

Edit: I missed the security advisory in Martin's initial post, it's noted there too.

Wayne
--
Please remember tor rate responses and to mark your question as answered if appropriate.

[Martin Koch]

I said this before, it has to be both. But these security bugs needs to be fixed in X7 as well.

If not it would be quite limited to have the backwards compatilibty ;-)

[Steve Kapinos]

You also need to revoke old certificates from your CA - your keys are compromised and hence you can be impersonated.  

There isn't much value in changing your certificates until AFTER you have upgraded as long as your device is exposed on the net.. that's just creating more certificates that will be suspected of being compromised.

The Cisco PSIRT advistory is your clearing house for all official information.

[Martin Koch]

The question would be forward security.

Not getting "bad people" access to a key which had been used for some time can also be beneficial.

If traffic was captured before it might be possible to decrypt it with a key later gathered.

So there can be a value of changing a key.

[krolinski]

Hello,

can anyone (maybe Martin) tell me a little bit more about the vulnerabilities of the VCS ?

First of all I assume that the vulnerability only exists for devices that are reachable from the Internet. So from our VCS Control and VCS Expressway that would exclude the VCS Control and we can concentrate on the VCS Expressway only?

The second thing is under which conditions does this vulnerability apply ? Is it affecting only the login to the webinterface via Https ? If you disable the webinterface access (by Firewall ruleset) from the Internet would that be enough to prevent the vulnerability (until a fix is released by Cisco) ?

If a vulnerability scan also identifies communication on Port 5061 with the VCS Expressway what does this mean ? I believe this is encrypted SIP communication with the VCS Expressway. So does this mean the user name and password that a SIP client sends to the VCS Expressway for authentication purposes could be read out ?

Maybe somebody can help me (and maybe others) to understand the details of this vulnerability a little bit better since the Cisco page is lacking (at least at the moment) more information for each affected device.

Many thanks in advance !

Markus

[Steve Kapinos]

>can anyone (maybe Martin) tell me a little bit more about the vulnerabilities of the VCS ?

The vunerability is with the SSL software library the product uses - OpenSSL

The heartbleed vulnerability is a problem where an attacker through simply setting up a SSL session to the device can access portions of the memory of the process.. and in turn obtain access to information that normally is protected in the SSL session... and information in the SSL service itself, including the private key for the x509 certificate the device is using.  This is so significant because once an attacker has the private key used by the service... they can decode data sent to the service by others and impersonate the service itself.  PKI x509 certificate security is predicated on the notion that your private key is kept secure and no one but you knows it -- this exploit can leak that key effectively compromising the SSL security layer and the certificates themselves. 

>First of all I assume that the vulnerability only exists for devices that are reachable from the Internet.

Depends on where your attacker is... if they have access to a port using SSL.. then there is an issue. You can block the internet users, but that won't prevent someone behind your firewall doing the same.

>If a vulnerability scan also identifies communication on Port 5061 with the VCS Expressway what does this mean ?

Port 5061 is TLS (SSL) encrypted SIP port.  It uses SSL as well.. so in theory the service interface is vulnerable there as well.  Any payload entrusted to that port and the certificates/keys used by that service are at risk of exposure.  

What you need to know is, your certificates can no longer be trusted, they should be revoked and new certificates used.  Until you are upgraded and new certificates are in use, SSL traffic should not be assumed to be secure and there are risks of man-in-the-middle and impersonation attacks as long as your old certificates are still marked as valid in the wild.

[Tom Leinos]

Does this exploit expose media encryption or only sip signaling and management traffic like SSH,HTTPS?

-Tom

[Martin Koch]

Tom: from how I see it it ssh uses openssl as well but not the heartbeat functionality, so it does not seem to be affected in general.

HTTPS and SIPS are affected here, you can use the above listed tools to see that both 443 and 5061 give positive results (to get the key)

The result of this bug is that the attacker can read out the private encryption key.

By that all SIPS and HTTPS traffic have to be seen as compromised. In addition the existing key has to be seen as compromised as well.

Most VCS installs I have seen do not verify the certificates which opens man in the middle

attacks anyhow, but with this it can risk where that is enabled a man in the middle could be active.

The worst case I see is:

* current media traffic can be decrypted (man in the middle)

* captured (historical) media traffic can be decrypted a well

As you asked yourself, it would be good to know the impact for the VCS.

How about h323 calls, signaling in general, media/srtp, management (http/https),

passwords in SIPS and https, ...

I would also like to see an answer by Cisco on that.

[Steve Kapinos]

"I would also like to see an answer by Cisco on that."

We have to defer people to Cisco PSIRT on topics like this...

But speaking generally, one would scrutinize anything that uses SSL/TLS sessions.  H323 doesn't use SSL, SIP can, SRTP is payload encryption, not transport, HTTPS does..

What is exposed or not really is more about 'the potential' vs 'handed on a silver patter'.  The notion that the encryption keys are at risk is what makes the wide open risks.  I found this article from Wired interesting in they spoke towards the difficultly in exploiting the memory leak itself.  http://www.wired.com/2014/04/nsa-heartbleed  

I personally am more worried about the encryption being compromised than I am about real-time leaking of other payload through the exploit.

[Martin Koch]

Sadly the PSIRT page is not very verbose, I did not even see a bug number for the VCS issue, nor detailed information.

For example, if you decode the SIPS messages with the session setup for the SRTP, can you decode the media because you have the SSL key and you get the SRTP negotiation?

The signaling of h323 does not use encryption at all, which is not good anyhow.

It is not about using SSL itself, or is the key which is revealed by the bug also used for example for encrypting the h323 media?

What services is this key used for, sips, https, ssh, srtp, ...?

Can you "only" do a Man in the middle attack or also decrypt captured / historical information, ...

So many unanswered questions.
 

[Steve Kapinos]

"Sadly the PSIRT page is not very verbose, I did not even see a bug number for the VCS issue, nor detailed information."

You can always try calling them or emailing them :)

"For example, if you decode the SIPS messages with the session setup for the SRTP..."

Not speaking directly towards the vunerability..  it would depend on the key negotiation being done for the SRTP session if that's decodable.  That's a topic of 'is TLS required to make SRTP secure?'

"It is not about using SSL itself, or is the key which is revealed by the bug also used for example for encrypting the h323 media?"

All the media encryption stuff uses dynamically generated keys... the point of the certificates and their private keys in SSL is to authenticate and securely exchange those dynamic keys (your private key is not what the AES encryption uses, etc).  H.323 media encryption doesn't use a secure exchange like that at the start..  and its why the only way you validate h323 encryption is by comparing the hashes.