Apple introduced a new set of features in iOS 8 and Yosemite under the name "Continuity". These features allow iPhones to work with other iDevices such as Macs and iPads in new ways. Handoff, Instant hotspot and Airdrop are some of the new services offered by Continuity. Among these new services is one named "Call Relay". Essentially, it allows one to make and receive phone calls via iDevices and route them through the iPhone. This is not your typical VOIP service but a P2P connection based on a proprietary protocol. Apple's security white-paper is short and vague on this particular topic. Only four paragraphs are dedicated to explain how Call Relay works and the only security relevant information is as follows: "The audio will be seamlessly transmitted from your iPhone using a secure peer-to-peer connection between the two devices." I reverse engineered the protocol to understand how it works. The goal was to see if Apple's design was secure and find vulnerabilities focusing on ways to eavesdrop phone calls. In this presentation, I will start by explaining all the details of this protocol and the process of reverse engineering it. Once the protocol is understood by the audience, I will discuss the thread surface and the different attack vectors possible. I will focus on what worked and demonstrate with demos. We will see how it is possible to abuse the protocol to spy on victims by leaving their mic open. We can also troll victims by dropping or preventing them from picking up phone calls. Last, I will explain how an attacker can abuse multi-party calls to impersonate other callers. Once we understand the vulnerabilities, we will discuss how it can be weaponized to build an amateur (insert 3 letters here)-spy program. This presentation covers CVE-2016-4635, CVE-2016-4721, CVE-2016-4722 and CVE-2016-7577

1. DO-IT-YOURSELF SPY PROGRAM:
ABUSING APPLE’S CALL RELAY PROTOCOL
Martin Vigo
@martin_vigo
martinvigo.com

2. 2Security Analyst Summit 2017
Martin Vigo
Senior Product Security Engineer
salesforce.com
@martin_vigo
martinvigo.com

3. 3Security Analyst Summit 2017

4. SECURITY BY OBSCURITY
4Security Analyst Summit 2017

5. UNDERSTANDING HOW CALL RELAY WORKS

6. OUTGOING CALL
6Security Analyst Summit 2017

7. 7Security Analyst Summit 2017

8. POSSIBLE TARGETS
8Security Analyst Summit 2017
• Standard protocol
• Intercept GSM traffic
• Fake cell phone tower
• Very illegal!
• Intercept APNS
traffic
• Persistent connection
• Encrypted channel
• Cert pinning
• Break TLS
• UDP is not encrypted
• UDP is connectionless
• Multiple attack vectors on LAN
• DNS spoofing
• ARP Spoofing
• etc.
• Proprietary protocol?

9. ATTACK SURFACE
9Security Analyst Summit 2017

10. REVERSING THE PROTOCOL

11. FIRST PACKET SENT DURING DIFFERENT CALLS
11Security Analyst Summit 2017
• Beginning of the payload, static
Header
• Dynamic, uncommon length (12 bytes)
Identifier of some sort? Device, user, call…
• Static, separates 2 dynamic fields, common field length (4 bytes)
Separator?
• Dynamic, 16 bits, towards the end of the payload
Checksum? Timestamp
• Static, all zeros, end of the payload
Null-terminating payload field

12. 3 DIFFERENT HEADERS
12Security Analyst Summit 2017

13. 13Security Analyst Summit 2017
• Mac -> Iphone / iPhone -> Mac
• We identify that only 1 byte changes
• Mac -> iPhone sends 0
• iPhone -> Mac sends 1
• Field 5 is static in the same call but changes between calls
FIRST TWO PACKETS FOR FIVE DIFFERENT CALLS

14. DISCOVERY PHASE
14Security Analyst Summit 2017

15. 15Security Analyst Summit 2017
• Field 1: Swaps again 0 ->1
• Field 5: Swaps 38 -> 10
• Field 7: Same value as in the first packet
• Field 9: Only sent from Mac to iPhone. Bytes have a property…
NEXT 2 PACKETS OF 5 DIFFERENT CALLS

16. IDENTIFICATION PHASE
16Security Analyst Summit 2017

17. 17Security Analyst Summit 2017
• The usual: Header, static fields, separators, etc.
• 1st and 2nd packet (Mac -> iPhone | iPhone -> Mac)
• Field 1: 4 random bytes | Field 2: 4 null-bytes
• 3rd packet (Mac -> iPhone)
• Field 1: Same 4 bytes sent in 1st packet | Field 2: The 4 bytes sent in Field 1 by iPhone + 1
• Field 3: Changes from 0 to 1
ALL PACKETS WITH HEADER 20040004

18. CALL NEGOTIATION PHASE
18Security Analyst Summit 2017

19. 19Security Analyst Summit 2017
• 2 different values that increment by 1 (decimal) consistently
• Each machine has his own counter for sync
• 2 bytes counter. Resets every ~20 minutes on same call. Important if used for crypto!
• Static value. Different per machine. Changes every call
• Encoded / encrypted audio payload
• Confirmed by flipping bytes and listen to audio quality degradation
ALL PACKETS WITH HEADER e000

20. SOUND TRANSMISSION PHASE
20Security Analyst Summit 2017

21. 21Security Analyst Summit 2017
A lot of stuff not covered because of lack of time :(
Reach out to me if you want more details!

22. 22Security Analyst Summit 2017
• Used scapy to implement the protocol
• Successfully impersonated iPhone and Mac
• Not 100% working yet.
• Still missing details of the protocol
• Timing is key which makes testing difficult
PROTOCOL IMPLEMENTATION
Check out my repo
https://www.github.com/martinvigo

23. BREAK IT!
23Security Analyst Summit 2017
#FAILS
• Eavesdrop ongoing calls
• Decode/Decompress/Decrypt voice payloads
• Replay attacks
• Redirect voice payload to attacker’s device
• Make calls on behalf of victim
• Inject voice payloads
#WINS
• DoS calls
• Spy on victims by leaving mic open
• Impersonate caller on multiparty calls

24. 24Security Analyst Summit 2017
• What would happen if I send a “Call negotiation phase” packet during a call?
• Need to be able to forge a valid one
• We want a silver bullet that works every-time without having to guess/bruteforce any bytes
• No MiTM
• Use scapy to fuzz the protocol and nullify as many bytes as possible
DoS CALLS
Magic DoS call packet payload
20040004000000000000000000b002000000000000000000000000000000000000000000000000000000000000

25. 25Security Analyst Summit 2017
• I could not eavesdrop calls
• I could not inject voice data
• I could not replay voice data
• I could not redirect voice data
• Use of encryption
SPY ON VICTIMS
Nosey Smurf
NSA tool to enable microphones on mobile devices

26. 26Security Analyst Summit 2017
“In the future, cryptography won’t be broken, it will be bypassed”
Adi Shamir at RSA Conference

27. 27Security Analyst Summit 2017
• Voice payload packets simply stop
• No apparent differences in last voice payload packets
• I must be missing something…
HANGING UP

28. SOMETIMES YOU NEED THE BIGGER PICTURE
28Security Analyst Summit 2017

29. INCLUDING APNS TRAFFIC
29Security Analyst Summit 2017

30. 30Security Analyst Summit 2017
THE “HANGUP MESSAGE” IS DELIVERED AS A PUSH
NOTIFICATION

31. EXPLOITATION
31Security Analyst Summit 2017
• Don’t let the “hang up” message be delivered!
• 1. ARP spoofing for MiTM
• 2. Call the victim
• 3. Block outgoing traffic from victim to 17.0.0.0/8
(APNS)

32. DEMO
32Security Analyst Summit 2017

33. IMPERSONATE CALLERS
33Security Analyst Summit 2017
• We can prevent hanging up
• We can prevent switching calls
• Combine both!
• 1. Call the victim while on another call
• 2. Victims puts legit caller on hold
• 3. Let victim hang up on you.
• 4. Block switch and hangup message
• UI only shows legit caller while
still talking to attacker

34. DEMO
34Security Analyst Summit 2017

35. DO-IT-YOURSELF SPY PROGRAM

36. WEAPONIZE AND DISTRIBUTE MASSIVELY
36Security Analyst Summit 2017
• We can interrupt calls
• We can impersonate callers
• We can gather calls metadata
• We can leave microphones open
• Targets
• Routers and IoT devices
• Identify apple devices
• Check ARP table
• 3 first bytes of a MAC address indicate vendor
• Block traffic to APNS during call

37. WARDIALING
37Security Analyst Summit 2017
• Collect BSSID from routers
• Use wigle.net to get physical locations
• War dialing by area code
• Detect calls by fingerprinting network traffic
• Correlate phone numbers with routers detecting
incoming calls

38. CLOSING REMARKS

39. TIMELINE
39Security Analyst Summit 2017

40. FURTHER RESEARCH
• Reverse Facetime app and daemons
• Cryptanalysis on the protocol
• Call relay support on other OS
• Infer voice patterns from encrypted traffic
• http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
• https://www.cs.jhu.edu/~cwright/voip-vbr.pdf

41. Martin Vigo
@martin_vigo
martinvigo.com
Q & A