איך Zerotistic גרם ל־Find My של אפל לעבוד על לינוקס

חוקר אבטחה המשתמש בשם Zerotistic הדגים שאפשר לגרום לשירות Find My People של אפל לעבוד ממחשב לינוקס — אף שאפל מציגה את התכונה כמיועדת למכשירי החברה בלבד. הוא עשה זאת באמצעות שחזור של חלקים מספיקים מהפרוטוקולים הפרטיים של אפל: התחברות לחשבון, רישום מכשיר, העברת הודעות וסנכרון Find My. כך השרתים של אפל קיבלו את לקוח הלינוקס כמכשיר מורשה נוסף.

הסייג החשוב: הלקוח לא פרץ להצפנה ולא עקף החלטת שיתוף של אדם אחר. הוא יכול היה לקרוא רק מיקום שכבר אושר לקבלה על ידי חשבון Apple ששימש בניסוי. הוא לא אפשר לאתר משתמשי אפל אקראיים או לשנות הרשאות שיתוף.

הממצא המרכזי: החומרה של אפל לא הייתה בהכרח גבול האבטחה

ההדגמה מראה שההגבלה ל״מכשירי אפל בלבד״ הייתה במסלול הזה בעיקר גבול של מימוש ושל מדיניות מוצר — ולא דרישה קריפטוגרפית מוחלטת לחומרה מתוצרת אפל. לאחר שלקוח הלינוקס סיפק את פרטי החשבון, זהות המכשיר, תעודות, יכולות והתנהגות רשת שהשירות ציפה להם, השרתים התייחסו אליו כמקבל מידע מהימן נוסף.

אין פירוש הדבר שכל מחשב לינוקס אנונימי יכול פשוט לשאול את Find My על מיקומם של אנשים. המחקר מראה שמערכת הפעלה שאינה של אפל יכולה לחקות את התנהגות הלקוח המתאימה — לאחר השלמת שלבי האימות והרישום של אפל.

כך שוחזר תהליך Find My בלינוקס

הפרויקט חיבר כמה שכבות שבדרך כלל נסתרות ממשתמשי אפל:

1. אימות החשבון: Zerotistic השתמש בפרוטוקול ההתחברות GrandSlam של אפל. התהליך כלל החלפת מפתחות לפי Secure Remote Password ‏(SRP) ואימות דו־שלבי, ולאחריהם התקבלו מזהי חשבון וטוקן קצר־מועד המקביל לסיסמה.

2. רישום המכשיר: הלקוח יצר בקשת חתימה על תעודה בפורמט PKCS#10, עם מפתח RSA באורך 2,048 סיביות וחתימת SHA-1. הבקשה נשלחה לנקודת הקצה הוותיקה authenticateDS, המשמשת לרישום פרופיל, וזה החזיר תעודת Apple Identity Services.

3. רישום ב־IDS: בעזרת התעודה וחומרי הזהות הנלווים, לינוקס יכלה להירשם כמכשיר התומך ב־Identity Services, להצהיר אילו סוגי הצפנה היא תומכת בהם, להירשם לשירותי המשנה הנדרשים ולקבל פרטי גישה למסירת הודעות דרך Apple Push Notification Service ‏(APNs).

4. סנכרון Find My: הלקוח שיחזר את רצף הבקשות של Find My People, כולל אתחול, פעולות רענון ובקשת SubscribeAndFetch עם

   intent: distributeKeys

   ו־

   mode: proactive

   . לאחר מכן אפל הורתה למכשיר של איש הקשר שכבר הסכים לשיתוף למסור את חומר מפתחות המיקום העדכני לזהות החדשה שנרשמה, דרך IDS ו־APNs.

5. פענוח מקומי: המטען המוצפן שנשלח דרך IDS הכיל חומר הקשור ליחסי השיתוף ולמפתחות SearchParty. ספריית הקוד הפתוח pypush טיפלה בשכבת הדחיפה וה־IDS, ואילו FindMy.py שלפה ופענחה את דוחות Find My והפיקה קואורדינטות, חותמות זמן ונתוני דיוק.

מדובר בחיקוי של הפרוטוקול — לא בזיוף של תעודת אפל. השרת עדיין הנפיק את האישורים רק לאחר שתהליך האימות ורישום המכשיר הושלם.

מה חשף המטען של IDS על חלוקת מפתחות

ההתנהגות של SubscribeAndFetch שהודגמה מרמזת שאפל יכולה להעביר חומר מפתח עדכני למכשיר חדש שאושר לאחר שכבר נוצר קשר שיתוף. זהו מנגנון מעשי לסנכרון ולהחלפת מכשירים: אחרת, משתמשים היו צריכים לבקש מכל איש קשר להפסיק את שיתוף המיקום ולהפעיל אותו מחדש בכל פעם שהיו מוסיפים מכשיר לחשבון.

לפי התיאור, המטען כלל מזהה קשר, אינדקס מפתח, מפתח פרסומות מגובב באורך 32 בתים וייצוג של מפתח פרטי באורך 85 בתים. השדות האלה מצביעים על כך שפענוח דוחות המיקום של Find My נשען על חומר מפתח הקשור ליחסי השיתוף ולגרסת המפתח, ושאפשר להפיץ מחדש את מצב המפתח דרך IDS.

הפרסום הפומבי מדגים התנהגות של סנכרון והחלפת מפתחות, אך אינו קובע מרווח אוניברסלי להחלפת מפתחות. לכן אי אפשר להסיק ממנו מפרט מלא של לוח הזמנים לניהול המפתחות של אפל.

מה הלקוח יכול היה — ומה לא יכול היה — לעשות

הלקוח שנבדק היה מצומצם בכוונה. הוא יכול היה לקרוא שיתוף מיקום שכבר אושר בחשבון Apple של החוקר ולעבד את הנתונים באופן מקומי. גם הגדרות האזורים הגיאוגרפיים — למשל התראה כשאדם מגיע למקום מסוים — בוצעו מקומית לאחר הפענוח, ולא כשירות שמנוהל בצד של אפל.

לפי הפרסום, לא היו בו יכולות ל:

• לשלוח הזמנות חדשות לשיתוף מיקום;
• לשנות הרשאות שיתוף קיימות;
• להוסיף בני משפחה;
• ליצור אזורים גיאוגרפיים המתארחים אצל אפל; או
• לשלוח פקודות למכשירים.

לכן נכון יותר לתאר את התוצאה כממצא תאימות וכממצא על גבול האמון — לא כפריצה שמאפשרת מעקב מרחוק אחרי כל אדם. הסיכון המציאותי יותר קשור להשתלטות על חשבון או על מכשיר מהימן: תוקף שישיג שליטה בחשבון Apple או ירשום לתוכו מכשיר לא מורשה עלול לחשוף שיתופים שכבר זמינים לאותו חשבון.

מה ההבדל בין ההדגמה לבין nRootTag מ־2025?

שני המחקרים עוסקים בחלקים שונים של Find My ומציגים מודלי איום שונים.

העבודה של Zerotistic עסקה ב־Find My People. היא שיחזרה את הצד המקבל של קשר שיתוף קיים ומורשה. החשבון והמכשיר היו צריכים להתקבל על ידי אפל, והמיקום היה צריך להיות משותף מראש עם אותו חשבון.

nRootTag התמקד ב־Find My Network ובאיתור לא מקוון. החוקרים דיווחו ששירות Find My קיבל סוגי כתובות Bluetooth נוספים מעבר לכתובות הסטטיות האקראיות הצפויות. חולשה זו יכלה לאפשר למחשב עם Bluetooth לפעול כמשדר מעקב דמוי AirTag, ולהשתמש במכשירי אפל סמוכים כדי להעביר את מיקומו בלי ידיעת בעל המכשיר.

בקיצור: Zerotistic קיבל מידע שחשבון כבר היה מורשה לראות; nRootTag ביקש ליצור יכולת מעקב לא מורשית. ערבוב בין הממצאים עלול לגרום להדגמת הלינוקס להישמע חזקה בהרבה ממה שהראיות תומכות בו.

המטרה המקורית וכמה זמן זה לקח

המטרה המוצהרת הייתה אוטומציה בהסכמה. חבר שכבר שיתף את מיקומו הסכים שמערכת לינוקס תנהל אזורים גיאוגרפיים מקומיים ותשלח התראות בדיסקורד כשהוא מגיע למקומות מסוימים או עוזב אותם.

בתחילת הדרך Zerotistic ציפה שמדובר בבקשת אינטרנט מאומתת ובהשקעה של בערך ערב עבודה אחד. בפועל, מלאכת ההנדסה לאחור התרחבה הרבה מעבר להערכה הראשונית. החומרים הזמינים אינם קובעים משך כולל מדויק של הפרויקט, ולכן כל מספר מדויק יותר יהיה ספקולטיבי.

כיצד אפל הגיבה?

הדיווחים המצוטטים מאשרים את ההדגמה, אך אינם כוללים הצהרה ציבורית מאומתת של אפל שמתייחסת ספציפית למימוש Find My People על לינוקס, תיקון מאושר או תוצאת תוכנית תגמול על דיווחי באגים.

המסקנה המרכזית נותרת בעינה: הגבלת תכונה לחומרה של אפל אינה הופכת אוטומטית את החומרה עצמה לגבול האבטחה. אם האמון בצד השרת מוענק בעיקר לפי פרטי התחברות, תעודות, יכולות והתנהגות פרוטוקול, לקוח תואם מספיק על מערכת הפעלה אחרת עשוי לחצות את גבול המוצר — אך עדיין יישאר מוגבל להרשאות החשבון ולמפתחות הקריפטוגרפיים שהשיג כדין.