Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

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

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

Please remember to rate helpful responses and identify

58 REPLIES

Martin,You do realize that

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

Thank you, Justin Ferello Technical Support Specialist KBZ, a Cisco Authorized Distributor http://www.kbz.com e/v: justin.ferello@kbz.com

I did not say upgrade openssl

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.

Please remember to rate helpful responses and identify

Or, even better, release a

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

VIP Green

+5 to that!

+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.

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

I said this before, it has to

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 ;-)

Please remember to rate helpful responses and identify

Cisco Employee

You also need to revoke old

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.

The question would be forward

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.

Please remember to rate helpful responses and identify

New Member

Hello,can anyone (maybe

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

Cisco Employee

>can anyone (maybe Martin)

>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.

New Member

Does this exploit expose

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

 

-Tom

 

Tom: from how I see it it ssh

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.

 

Please remember to rate helpful responses and identify

Cisco Employee

"I would also like to see an

"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.

Sadly the PSIRT page is not

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.
 

Please remember to rate helpful responses and identify

Cisco Employee

"Sadly the PSIRT page is not

"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.

New Member

Thanks Steve !!

Thanks Steve !!

New Member

thanks, just need to

thanks, just need to understand a bit more about worst case here please.

obviously will depend to a large degree on how deployed but in general terms how concerned should I be that an attacker could 

- gain control of a vcs expressway in dmz and alter CPL script for ISDN GW toll call access

- gain access to info on vcs control inside network via traversal zone (on same lan port via separate fw ports) where all endpoint/ infra registrations, addressing and AD sync occurs

x7.2 on both. 8.1.1 may not be possible for a while

Many thanks

The Cisco advisory got

The Cisco advisory got updated (please check that list and the PSIRT site for the latest info:

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

 

What is listed as vulnerable:

  • Cisco AnyConnect Secure Mobility Client for iOS
  • Cisco Desktop Collaboration Experience DX650
  • Cisco Unified 7800 series IP Phones
  • Cisco Unified 8961 IP Phone
  • Cisco Unified 9951 IP Phone
  • Cisco Unified 9971 IP Phone
  • Cisco TelePresence Video Communication Server (VCS)
  • Cisco IOS XE
  • Cisco UCS B-Series (Blade) Servers
  • Cisco UCS C-Series (Stand alone Rack) Servers
  • Cisco Unified Communication Manager (UCM) 10.0

 

TelePresence devices listed "under investigation"

  • Cisco TelePresence MX Series
  • Cisco TelePresence Profile Series
  • Cisco TelePresence System 1100
  • Cisco TelePresence Recording Server

 

 

What I noticed, whats not listed (they showed positive results using the perl test tool, I reported that to Cisco):

* TelePresence Conductor

* ISDN GW

* TelePresence Server (8710)

 

Inconclusive results I (two test tools reported differently) I got on an endpoint running TC7.1

 

Please remember to rate helpful responses and identify

VIP Purple

Cisco - What's the status of

Cisco - What's the status of the additional TelePresence products Martin has mentioned above? Our university IT has detected the same thing at least on C-Series codecs. I'd assume the Conductor is exactly in the same situation as the VCS since they run the same OS etc. 

Cisco Employee

I encourage you to contact

I encourage you to contact Cisco PSIRT and push them hard on the topic for your answers.

 

You have to understand there are policies that we employees must follow when it comes to disclosures, etc.  Cisco PSIRT is your avenue.. and if they can't answer... you're the customer push them harder :)

Hi Patrick I had contacted

Hi Patrick

 

I had contacted PSIRT and they will put them under "investigation" as well.

 

I asked fo:

•         Cisco TelePresence ISDN GW 3241
•         TelePresence Server
•         EX / C / SX / MXG2 endpoints, short all what runs TC
•         Tandberg E20 (there is no SW end date mentioned in the EOL, so not sure)
•         Tandberg MXP (does not seem to be affected if I see it right)

*          other telepresence products

 

Please remember to rate helpful responses and identify

VIP Purple

Just checked the advisory

Just checked the advisory again, all TelePresence servers are affected, Supervisor MSE 8050, Conductor and other TelePresence devices have been added to the affected list.  Waiting on new software now, and for Cisco to finish the rest of the other TelePresence products that are pending testing.

Thanks Martin and Patrick for

Thanks Martin and Patrick for this. Interested to know with the MXP are affected as I would have through the still used OpenSSL (but maybe not)?

I was away last week but am just about to contact out partner to ensure we have the correct info.

Cheers

 

Chris

VIP Green

The advisory is now saying

The advisory is now saying that the MXPs are not affected (they're based on a eCos Operating System rather than a Linux one).

I've also sent a request clarification on both TMS and the TelePresence Content Server.  Both these (TMS and TCS) run on Windows, which isn't vulnerable, but requesting confirmation on the apps themselves as they're not mentioned in the Security Advisory as either affected or not.  I'm expecting that they're not affected, but for consitence and completeness, would like them to be mentioned as so in the advisory.

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

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

Endpoints running TC software

Endpoints running TC software have been confirmed vulnerable as we expected.

Silver

this is fixed in TC 7.1.1

this is fixed in TC 7.1.1 version. this is also mentioned in release notes.

 

Regards,

 

Amit

New Member

Hi Amit, How comes the Bug ID

Hi Amit,

 

How comes the Bug ID page says "Known Affected Releases" are 5.0.0 only?

https://tools.cisco.com/bugsearch/bug/CSCuo26378

 

Regards

Pinkesh

 

Silver

Hi Pinkesh, not sure about it

Hi Pinkesh,

 

not sure about it but from TC 5 version, Cisco OpenSSL version was from 1.0.1 which also fall under vulnerable Open SSL version.

VIP Purple

Hello Amit -Any idea when TC7

Hello Amit -

Any idea when TC7.1.1 will be released to address this issue?

As well as Conductor, and other TelePresence products confirmed vulnerable?

Cisco Employee

"Any idea when TC7.1.1 will

"Any idea when TC7.1.1 will be released to address this issue?"

It's already on the web (posted today).

They released fixed versions for TC7.1.1 and TC6.3.1

 

23
Views
80
Helpful
58
Replies