Starscream library version prior to 2.0.4 suffer from an SSL pinning vulnerability due to the pinning occurring too late in the stream function.
64a188b368b05fc0c83b778a896addd96b7d6adfd09af4f4173cf80627a8b788
Product: Starscream websocket library
Severity: LOW
CVE Reference: CVE-2017-5887
Type: SSL Pinning bypass
Abstract
--------
WebSocket.swift in Starscream before 2.0.4 allows an SSL Pinning
bypass because pinning occurs in the stream function (this is too
late; pinning should occur in the initStreamsWithData function).
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 information disclosure due to an
incorrect implementation of SSL pinning during the websocket
handshake.
Impact
------
An attacker can intercept the initial websocket handshake GET request,
which may potentially contain sensitive information (e.g. session
tokens, cookies). An attacker could possibly misuse this information
to attack the target application.
Cause
-----
The code of the library contains a vulnerability whereby the SSL
pinning is executed only on the websocket TCP connection itself, but
not for the initial handshake request.
Solution
--------
Upgrade to version 2.0.4.
Technical details
-----------------
The cause of the problem was in the implementation of the initial
connection (referencing initStreamsWithData version 1.1.4 where we
first discovered the issue). After configuring the streams with the
SSL context, the method proceeds to open the connection and writes the
initial upgrade connection directly to the stream as soon as
hasSpaceAvailable returns true. The actual pinning is done only after
the initial connection is established.
The fix consisted in checking the pinned certificates BEFORE any byte
is sent through the stream and closing the connection immediately if
the check fails.
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.