Vulnerability disclosure – Cisco Meeting Server (CMS) arbitrary TCP relaying
Vulnerability Summary
- Cisco Meeting Server (CMS) is bundled with the coturn open source TURN server, which implements RFC 6062. This RFC adds TCP proxying capabilities to the TURN protocol, which results in the possibility to use CMS to reach internal IPs and ports.
- The coturn server bundled with CMS seems to be configured with a default password. This password could in fact be universal for all instances of CMS.
Vendor Response
Cisco « does not disagree that there is a better way to address the TURN server capabilities and does have a roadmap to modify the functionality of TURN with Cisco Meeting Server » and is « looking for a way to better secure the product in the future ». However, Cisco did not consider our findings as a vulnerability.
No patch has been scheduled at this time.
Technical details
Default password / Password disclosure
Upon connection to the Cisco Meeting Server web application, a user must submit a valid Call ID and its associated passcode to authenticate as a participant. Following authentication, an HTTP POST request is sent to cometListener (https://cms.example.com/cometListener.sf). The participant receives the credentials for the TURN server as a response. The credentials are also sent by the server in the form of a WebSocket incoming message.
Figure 1 – Disclosure of the TURN password
In the instance of CMS we audited, the TURN server had a generic 1337-speak and Cisco-related password, which was not set by our client.
CMS might therefore be universally bundled with hardcoded credentials for the TURN server. Cisco did not confirm or refute this information.
If this were to be the case, the vulnerability described below would be “unauthenticated”.
Otherwise, CMS participants can still obtain valid TURN credentials through the normal workflow of the application.
Arbitrary TCP Connection Relaying
The TURN protocol (RFC 5766) is an extension of the STUN protocol (RFC 5389). This protocol is typically used in VOIP as it is designed to help clients traverse NATs to initiate connections.
Cisco Meeting Server is bundled with an open-source TURN server named coturn.
During an assessment, we have determined that the coturn server implemented RFC 6062, which describes the implementation of TCP relaying capabilities within the TURN protocol.
Notably, it specifies that an authenticated TURN client, following a preliminary Allocation phase, has the possibility to query the TURN server to have it initiate a TCP connection to the IP address of an arbitrary peer, as stated in paragraph 5.2 of the RFC. This is referred to as a Connect request:
When the server receives a Connect request, it processes the request as follows.[…] (Error cases)Otherwise, the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. The remote endpoint is the one indicated by the XOR-PEER-ADDRESS attribute. If the connection attempt fails or times out, the server MUST return a 447 (Connection Timeout or Failure) error.
This connection is called the peer data connection.
The client is then able to initiate a new TCP connection (called the client data connection) to the TURN server and issue a ConnectionBind request. Upon reception of this request, the TURN server will bind the client data connection and peer data connection together, effectively creating a bidirectional TCP Proxy between the client and an arbitrary peer. This is explained in the Overview section of the RFC (paragraph 3) :
In order to actually send data on the new connection or otherwise utilize it in any way, the client establishes a new TCP connection to its TURN server. Once established, it issues a ConnectionBind request to the server over this new connection. That request echoes back the connection identifier to the TURN server. The TURN server uses it to correlate the two connections. As a consequence, the TCP connection to the peer is associated with a TCP connection to the client one-to-one. The two connections are now data connections. At this point, if the server receives data from the peer, it forwards that data towards the client, without any kind of encapsulation. Any data received by the TURN server from the client over the client data connection is forwarded to the peer, again without encapsulation or framing of any kind. Once a connection has been bound using the ConnectionBind request, TURN messaging is no longer permitted on the connection.
Thus, this functionality could allow an attacker with credentials to connect to otherwise unreachable services and hosts in an internal network.
To demonstrate the impact of the disclosure of TURN credentials, we were able to connect to a SSH server and grab its banner, as could be done with a classical telnet connection if we had direct access.
Figure 2 – Wireshark capture: Connection to a SSH server, banner grabbing
In the Wireshark capture above, we can see the successful Connect request to XXX.XXX.XXX.XXX:22 in red, the successful ConnectionBind request in green, and a message from the TURN server (YYY.YYY.YYY.YYY:YYYYY) which outputs the SSH banner of the peer (SSH-2.0-X) in blue.
On the contrary, a connection to a firewalled or closed port can be identified thanks to an error message from the TURN server
Figure 3 – “Connection Timeout or Failure” error message for a Connect Request to a closed port
This allows us to differentiate open and closed TCP ports, and thus conduct port scanning activities to identify hosts in the internal network. It may also be possible to relay UDP datagrams to arbitrary IPs in the same fashion, although this has not been attempted.
The behavior we describe in this vulnerability was reproduced against the latest version available from the coturn github repository, which is therefore “vulnerable” by default (and by feature) to authenticated attacks.
Affected versions
This vulnerability could be present on all versions of the product, as long as coturn has been implemented. We do not know if there exists a CMS version that gives the option not to disclose the TURN server credentials. We are also unsure if the TURN password is universal, as Cisco did not address this specific point.
This vulnerability was tested on Cisco CMS 2.2.8.
Timeline
- 13/4/2018 : First contact with Cisco PSIRT
- 26/4/2018 : Full details sent to Cisco PSIRT
- 09/5/2018 : Cisco flags the bug as « working as designed »
- 17/5/2018 : Cisco acknowledges CMS needs additional hardware firewalling to mitigate the issue, allows us to publish
- 01/6/2018 : Full disclosure
Author
Raphaël Arrouas
Les commentaires sont fermés.