WebSocket.swift in Starscream versions 2.0.3 and below allows an SSL Pinning bypass because of incorrect management of the certValidated variable (it can be set to true but cannot be set to false). An attacker can achieve traffic interception from a man-in-the-middle position, first by resetting the TCP connection between the client and server, and afterwards by injecting an SSL server certificates they control.
4a7af40db402a792926151e595919340Product: Starscream websocket library
Severity: LOW
CVE Reference: CVE-2017-7192
Type: SSL Pinning bypass / Information disclosure
Abstract
--------
WebSocket.swift in Starscream before 2.0.4 allows an SSL Pinning
bypass because of incorrect management of the certValidated variable
(it can be set to true but cannot be set to false).
Description
-----------
The open-source Starscream library provides a SWIFT implementation of
the websocket framework. It allows iOS applications to send and
receive messages via a dedicated websocket channel.
Applications using the Starscream library (up to and including version
2.0.3) were vulnerable to potential SSL pinning bypass. If an attacker
in a man-in-the-middle position is able to reset an established TCP
connection between the client and server, the subsequent re-connection
will not pin the SSL certificate, allowing traffic interception.
Impact
------
An attacker can achieve traffic interception from a man-in-the-middle
position, first by resetting the TCP connection between the client and
server, and afterwards by injecting an SSL server certificates they
control.
Cause
-----
The code of the library contains a vulnerability whereby the state of
the connection (isValidated) is not properly updated after a
re-connection.
That creates a situation whereby pinning works properly only for the
initial connection.
Solution
--------
Upgrade to version 2.0.4.
Technical details
-----------------
The cause of the problem was incorrect management of the certValidated
variable. The variable starts out with a default value of false after
the class is instantiated, and can be set to true if an HTTP/WS schema
is used OR if the check against the pinned certificates succeeds. The
problem was that the variable was never set to false after a
disconnection if a HTTPS/WS schema is used.
The fix consisted of resetting the variable to false when a connection
is initiated and a secure schema is used.
Credits
-------
Vulnerability was discovered by Lukas Futera and Giuliano Galea of
Centralway Numbrs AG.
Disclosure timeline
-------------------
28.2.2017 Vulnerability reported to vendor
07.3.2017 Vulnerability acknowledgment by vendor
14.3.2017 Vendor published initial patch
28.3.2017 New version released
21.4.2017 Advisory published
--
This message is for the attention of the intended recipient(s) only. It may
contain confidential, proprietary and/or legally privileged information.
Use, disclosure and/or retransmission of information contained in this
email may be prohibited. If you are not an intended recipient, you are
kindly asked to notify the sender immediately (by reply e-mail) and to
permanently delete this message. Thank you.