iPhone vulnerability allows attackers to spy on contacts
By Alfred Vergara on February 5, 2019
On January 28, 2019, security engineer Brandon Arvanaghi discovered a flaw in the iPhone that allowed for an attacker to receive audio and video feed from another iPhone victim when initiating a FaceTime call. This allowed malicious users to spy on contacts without their consent.
What is FaceTime?
FaceTime is a proprietary video-calling service introduced to Apple to their iPhone 4 in 2010. Much like Skype, FaceTime allows for one user to call another using both audio and video through microphones and cameras on the device. FaceTime’s use is limited to Apple users and devices, as the initiating device will
The Vulnerability
The vulnerability is easily exploitable and consists of two steps:
- FaceTime a victim
- Add your own number to the call
And instantly, you will be able to hear audio from the victim. If the victim dismisses the call with the power button, video will also be streamed to the attacker.
How I think Facetime works
FaceTime utilizes various technologies and services for its functionality. One of these services is a media delivery protocol known as Real-time Transport Protocol (RTP). RTP works on top of the User Datagram Protocol (UDP), which is part of the Internet protocol suite. UDP establishes a connection with another user without initiating a handshake, or “check” that the connection is sound. UDP is necessary for streaming services after a client requests a server for audio or video. The Transmission Control Protocol (TCP) in contrast, ensures that data in transit is not lost. This is useful for transmission of files, where losing a couple of bytes can affect the readability of the file. For streaming services, losing a couple of bytes may be indistinguishable audio distortion, or pixelation of a video feed; the availability of the stream is more important than the integrity of it, for streaming.
RTP relies on UDP to handle the transmission of packets. When a FaceTime call is initiated, the Traversal Using Relays around Network Address Translation (TURN) protocol allows for one end user to act as a server to the other user’s client. This involves resolution of public and private IP addresses. After the client and server have been established, audio is being streamed both ways through RTP, which utilizes UDP. During this step, a user will be waiting for the FaceTime call to be answered. TURN has brought one user to the doorstep of another, and the user receiving the call only has to “pick up the phone”, or open the door.
Normally, this is fine. Much like physically answering a door to visitors, you can choose to answer the door. Unfortunately, this vulnerability allows an attacker to ignore the door and act as a peeping tom–effectively drilling a hole in the door, watching and listening without your acknowledgement.
How I think it is exploited
The issue could be a logical issue in the handling of this fringe situation. Normally, audio and video is shared when a user answers the FaceTime call. Alice starts a FaceTime call with Bob. Alice, while waiting for Bob to answer the call, adds her own phone number to the FaceTime call. It is possible this situation or exception was not accounted for. If it was, the exception was handled incorrectly. Calls to oneself while in a pending call may be interpreted as the call being “answered”. By “answering” this call, FaceTime tries to establish the connection with oneself; Alice’s device tries to connect to itself. This connection may resolve in two ways, success or none.
This could be unsuccessful. The connection is tried again–with another person in the Group FaceTime. Thus, Alice is able to hear Bob’s audio without Bob answering the call. Bob does not see that the call request is completed because his iPhone does change the screen, for on his side he did not answer.
This could be successful. The call is accepted, but the criteria for establishing a connection is not defined explicitly enough. In a normal case on Alice’s side, she could be calling multiple people. Bob and Charlie receive calls from Alice. When they accept the call, the call and connection is made for “the call that has ‘Bob’”. This “has” criteria could be defined as “the call that has ‘Bob’ as the caller or receiver”. When Alice calls Bob and herself, the call to herself could be successful. The connection that is approved checks for a connection that “has ‘Alice’” and approves it. One of these connection requests is the one she made with Bob, and it allows her to finish the call.
Since TURN relies on UDP instead of TCP, malformed packets or unexpected behavior are not explicitly checked by the protocol. Unexpected events like this exploit using a TCP backbone could have revealed that certain authentications were being dropped, or changed, and then send for another request until the confirmation process appeared proper. Using a TCP based process for authentication purposes may be beneficial for FaceTime, because the protocol itself will handle the integrity of the process, and does not have to be hard-coded.
Impact
In United States law, Title 18 of the United States Code Chapter 119 Section 2511, it is a Federal offense to intentionally intercept the “contents of any wire, oral, or electronic communication” unless authorized by an investigation.This vulnerability allowed for an attacker to violate the privacy of another easily, and without the knowledge of the victim. While the rate of violent crime in the US has been dropping, the amount of cyber incidents have not, as confirmed in the Verizon Data Breach Investigations Report. The difficulty in attributing cyber crimes to an actor makes it attractive to commit the crimes, including this most recent FaceTime vulnerability. The ease of access to the vulnerability allowed it to be abused for several hours by any attacker before Apple disabled the Group FaceTime capability, which is the source of the vulnerability. The impact on an individual is potentially high in terms of loss of privacy, while on a larger scale it is unreported. Group FaceTime was first introduced to iOS 12, which was released officially on September 17, 2018. Assuming the vulnerability existed since the implementation of Group FaceTime, this would result in more than 4 months of possible, undetected spying.
There is also impact to consider on the side of Apple’s marketing. Apple markets its products with a variety of security features including: an application checking process with developers to ensure that certain security standards are met, sandboxing of applications, and full device encryption on compromise. While these implementations are admirable, it is important to recognize that there will always be vulnerabilities on a device or application. An impenetrable system does not exist, and this case with FaceTime confirms that Apple is not exempt.
Mitigation
Apple has since disabled Group FaceTime since they have been aware of the vulnerability. They are working on a patch for the issue, which will be released next week. For now, you can reassure yourself by disabling FaceTime when you are not using it.
Sources
https://appleinsider.com/articles/10/06/08/inside_iphone_4_facetime_video_calling.html
https://tools.ietf.org/html/rfc3550
https://www.ietf.org/rfc/rfc768.txt
https://www.ietf.org/rfc/rfc793.txt
https://www.statista.com/statistics/191219/reported-violent-crime-rate-in-the-usa-since-1990/
https://enterprise.verizon.com/resources/reports/dbir/
https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf
https://www.apple.com/ios/ios-12/features/
https://9to5mac.com/2019/01/28/facetime-bug-hear-audio/