Starscream 2.0.3 SSL Pinning Bypass

2017-04-21 / 2017-04-22
Risk: Medium
Local: No
Remote: Yes
CWE: N/A


Ogólna skala CVSS: 5/10
Znaczenie: 2.9/10
Łatwość wykorzystania: 10/10
Wymagany dostęp: Zdalny
Złożoność ataku: Niska
Autoryzacja: Nie wymagana
Wpływ na poufność: Brak
Wpływ na integralność: Częściowy
Wpływ na dostępność: Brak

Product: 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.


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top