In my free time, I was looking at some Android applications and noticed that I was able to intercept SSL traffic for Webex Meetings app. When explored it further, I found that Webex Meetings mobile app accepts self-signed certificates. Also there is no certificate pinning enabled.
This makes Webex meet app vulnerable to Man in the middle attack.
Users of this app, if connected to a public Wi-Fi spot, can be targeted by any person on the same network. If connected to a rogue Wi-Fi hotspot, Wi-Fi provider may have access to the data passed from the app to the server. Malwares on the device can also exploit this vulnerability to intercept any sensitive data while it is traveling across the wire.
A proper SSL ensures confidentiality and integrity of the information passed from point A to point B and is very important.
OWASP also puts ‘Insecure Communication’ on 3rd position in their top 10 list for mobile application vulnerabilities.
In simpler terms, if you love connecting to free Wi-Fi hotspots for your Webex meetings, in your gym or coffeeshops, then your meetings may not be not secret anymore.
I tested Webex Meetings Android app, version 10.6.0.21060208 Samsung S8 (on Android version 8.0).
As per vendor’s response, it seems all Webex mobile clients have similar behavior.
Vendor Response :
Hi Pankaj, after discussing with our development team, I’ve learned that the Webex mobile client accepts self-signed certificates because the Webex meetings component also allows for deployments using self-signed certificates. Similarly, because the Webex mobile client has to be used with so many different sites, certificate pinning is also not enabled.
Page 219 of administrator guide instructs how to import self-signed certificate on mobile device to join meetings. There are also instructions for iOS there as well.
Page 256 of administrator guide instructs certificate management on the meetings server itself, including self-signed certificates.
The guide also mentions that the client warns on accepting the self-signed certificate, and users should make sure the application is genuine before accepting Connect.
These choices are consciously made by the business and documented for customers. As such, we do not consider them vulnerabilities. Although, you are correct, these configurations leave open the possibility of some attacks intended to defeat some SSL protections from attackers with privileged network positions. However, OCSP stapling is enabled as a hardening measure to verify SSL certificates.
Due to requirements of supporting applications using self-signed certificates, the Webex business unit will not make any changes to address your findings. You are of course free to make public your findings. If you do so, please include references to the above documentation.
Thank you again for your reports.
03/10/2018 – Issue reported to Cisco PSIRT
03/10/2018 – Report acknowledged by the incident manager and I was asked for more information
03/10/2018 – Shared the required details. Shared some screenshots from Packet Capture app.
03/27/2018 – I was asked if I could gather more information.
04/10/2018 – I shared some information again.
10/05/2018 – Reached out to the case manager and PSIRT DL for an update. 10/17/2018 – Reached out to PSIRT DL again for an update.
03/13/2019 – Reached out to PSIRT DL again for an update and asking permission for a public disclosure.
03/15/2019 – Got a response that previous case managed had moved on to a different position and also dev team was not able to confirm my report and because of that, there were no fixes.
03/20/2019 – Got the response confirming that Webex mobile clients accept self-signed cert and it is an intended behavior.
04/30/2019 – Requested for a public disclosure as even though Webex suggested they have it in the ‘admin’ documentation, I didn’t think Webex users were aware about the inherent risks.
06/20/2019 – Shared a draft write up with the PSIRT team
06/24/2019 – Released the advisory for the public.
No CVE or bounty was awarded as vendor does not consider it a security issue. Vendor credited me for reporting this bug in their public bug release notes.
Someone pointed out that this issue was previously reported for the iOS app in 2012. CVE for that issue is CVE-2012-6399.