Apple Find My Recurring Notification Consent Bypass

Introduction⌗

A while back, I set up a jailbroken iPhone to intercept HTTP(S) traffic for a different project I was working on. This involved using the wonderful SSL Kill Switch 3 tweak from NyaMisty, which can globally disable SSL certificate validation on jailbroken iOS devices. While working on that other project, I noticed that the Find My app on iOS 16.2 was sending location update events over HTTPS to Apple’s servers.

This piqued my interest, I was not expecting Find My to be communicating over HTTPS through a JSON API. I decided to poke around with the functionality of the Find My app and see if I could find any interesting behavior.

Recurring Tracking Notifications⌗

In case you haven’t used the Find My app before, it allows users to share their location with friends, family, enemies, or anyone else with an Apple ID. When you share your location with someone, they can see your location on a map and even set up notifications for when you arrive at or leave a specific location. These notifications are called “Recurring Notifications” and can be easily set up in the Find My app’s UI.

Recurring notifications are only able to be created with the consent of the person being tracked. Apple states on their page above “Your friend must approve the notification before it’s set. They get an alert asking for approval on the time and day the notifications start.”

The HTTP API for the app is quite small in scope, so I looked at each and every request I could find. The request responsible for setting up recurring notifications was a POST request to https://p39-fmfmobile.icloud.com/fmipservice/friends/fmfd/{DSID}/{DEVICE_UDID}/updateGeoFence.

The Vulnerability⌗

The request to /updateGeoFence is a POST request with a JSON body containing a whole lot of data:

{
    "radius": null,
    "isOn": "true", // enable this notification
    "longitude": -180,
    "clientContext": {
        ...
    },
    "onetimeonly": "false", // recurring (!)
    "latitude": -180,
    "type": "NotifyMe", // notification recipient
    "trigger": "exit", // on leave
    "ckRecordName": "[REDACTED]",
    "emails": [
        "{recipient_email}"
    ],
    "ckRecordZoneOwnerName": "[REDACTED]",
    "friendId": "{find_my_friend_id}",
    "locationType": 0,
    "serverContext": {
        ...
    },
    "acceptanceStatus": "Hidden", // (!?)
    "dataContext": {
        ...
    }
}

The acceptanceStatus field stuck out like a sore thumb. In the response, this field was reflected and carried the same Hidden value. Immediately, this seemed like a value the client should not be able to set. To find out what a confirmed request looked like, I had a friend confirm my request the next time they left their place. The acceptanceStatus field was then changed to Accepted.

I intercepted a new request to set up a recurring notification and changed the acceptanceStatus field to Accepted in transit. The request was successful, and the value was reflected in the response! Checking the Find My app on my iPhone, I saw that a new notification was set up on my friend, no longer bearing the “Pending Request” string.

This simple vulnerability in the /updateGeoFence endpoint is a really basic oversight during the design of the Find My API. The acceptanceStatus field should only be stored server-side and the client should not be able to specify the value for this field.

Remediation⌗

I reported this vulnerability to Apple through their Apple Security Research portal. My report was resolved and a patch was deployed. The acceptanceStatus field is now ignored in the request body and is controlled server-side.

Disclosure Timeline⌗

• Initial report submitted: 2024-01-16
• First response received: 2024-03-19
• Patch deployed: 2024-07-29
• $10,000 Apple Security Bounty awarded: 2024-08-27
• Advisory published (August 2024): 2024-09-22

I’d like to thank Apple for their actions in patching this vulnerability to protect their users, and also for selecting my report for an Apple Security Bounty. I’m looking forward to working with them again.

Closing Remarks⌗

Thanks for making it this far! This is my first blog post over here, and I’m excited to share a whole bunch of other fun stuff that I’ve been working on. If you felt that this was a little simplistic, I certainly agree with you. I intend to ramp up the complexity of my posts as I get more comfortable with my technical writing.

The most heavily scrutinized platforms have the least fruit to bear. When attacking a platform, consider diversifying your approach and looking into the less obvious parts of the system. You never know what you might find.