Hello there is a critical bug in openssl:
which also affects Cisco products, incl at least the VCS:
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:
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
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?
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:
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.
+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.
Please remember tor rate responses and to mark your question as answered if appropriate.
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 ;-)
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 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.
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 !
>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: 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.
"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 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.
"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.
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
The Cisco advisory got updated (please check that list and the PSIRT site for the latest info:
What is listed as vulnerable:
TelePresence devices listed "under investigation"
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
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.
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 :)
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
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 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.
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.
Please remember to rate responses and to mark your question as answered if appropriate.
How comes the Bug ID page says "Known Affected Releases" are 5.0.0 only?
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?
"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