ניצול מודל האמון של iOS דרך Configuration Profiles
איך מנגנונים לגיטימיים של Apple יכולים להפוך לנשק מבלי לגעת בגבול אבטחה אחד
TL;DR
- לא תמיד צריך חולשה כדי להשפיע על iPhone. בתרחישים רבים, הנדסה חברתית בשילוב מאפיינים לגיטימיים של iOS מספיקה.
- Configuration Profiles יכולים להרחיב את אמון המכשיר עם אישור מפורש של המשתמש, בזמן שהמכשיר עדיין נראה “מאובטח” ולא פרוץ.
- תרחישי פרופיל זדוניים כוללים שינויי אמון מאולצים (Wi-Fi, אישורים, הגדרות VPN/proxy/MDM) שמשנים את הנראות לתעבורה ואת רמת החשיפה.
- הסיכון המרכזי הוא לא גבול אבטחה שבור, אלא הגדרה מחדש של אמון שאושרה על ידי המשתמש.
- הגנה צריכה להתמקד בממשל פרופילים, מודעות משתמשים, וניטור רציף לשינויים לא מורשים בפרופילים/אישורים/MDM.
תקציר
iOS נחשבת לאחת ממערכות ההפעלה למובייל הכי מאובטחות בעולם. במהלך השנים, Apple בנתה שכבות הגנה רבות, כמו Code Signing, Sandbox, מנגנוני אבטחה מבוססי חומרה, ומודל הפצת אפליקציות סגור יחסית. כתוצאה מכך, כשמדברים על “פריצה לאייפון”, הדיון בדרך כלל סובב סביב חולשות 0-Day, שרשראות ניצול מורכבות, Jailbreaks, או רוגלות מתקדמות מהסוג שמקושר בדרך כלל לגורמים מדינתיים או חברות מסחריות עם משאבים משמעותיים.
אבל מה אם לא צריך לפרוץ בכלל?
בהרבה מקרים, תוקף לא צריך לעקוף מנגנוני אבטחה, לנצל חולשה, או להריץ קוד זדוני. מספיק לגרום למשתמש לתת למכשיר הוראה לעשות בדיוק מה שהוא תוכנן לעשות.
מאמר זה מתמקד באחד המנגנונים המעניינים ביותר בהקשר הזה - Configuration Profiles, אישורים דיגיטליים, רכיבי MDM, והגדרות מערכת נוספות - שיכולים לשנות באופן משמעותי את מודל האמון של המכשיר ואת רמת החשיפה שלו, מבלי שהמכשיר נחשב “פרוץ” במובן המקובל של המילה, ובזמן שהוא עדיין פועל לחלוטין בתוך המנגנונים הלגיטימיים של מערכת ההפעלה.
לאורך המאמר, נבחן איך Configuration Profiles יכולים להיות משולבים עם טכניקות הנדסה חברתית, מה ההשפעות האפשריות על המשתמש, איך ניתן לזהות תרחישים כאלה, ומה אפשר לעשות כדי להגן מפניהם.
בסופו של דבר, הטענה המרכזית של המאמר די פשוטה. לפעמים הדרך הקלה ביותר להשפיע על iPhone היא לא לעקוף את מנגנוני האבטחה שלו - אלא להשתמש בהם בדיוק כפי שApple התכוונה. מה שידוע בשפה המקצועית כ: “it’s not a bug, it’s a feature”.
רקע ומוטיבציה
הסמארטפון כבר מזמן הפסיק להיות רק מכשיר תקשורת. הוא מכיל הודעות, תמונות, אימייל, מידע פיננסי, גורמי אימות (MFA), היסטוריית מיקומים, ולפעמים אפילו גישה ישירה למערכות ארגוניות. עבור תוקפים, גישה למכשיר נייד יכולה להיות אפוא בעלת ערך מיוחד. בהרבה מקרים, הטלפון הוא לא המטרה הסופית אלא נקודת הכניסה (Initial Access) - לפחות במידה מסוימת.
כשמדברים על “פריצה לאייפון”, השיחה בדרך כלל מתמקדת בניצול ברמת 0-day ורוגלות מתקדמות. לא במקרה - iOS נחשבת לאחת ממערכות ההפעלה הכי מאובטחות בעולם, ו-Apple משקיעה משאבים עצומים בהקשחתה. כתוצאה מכך, חלק גדול מהמחקר והדיון הציבורי מתמקד בשאלה איך לעקוף את מנגנוני ההגנה שלה בדרך זו או אחרת.
אבל… מה אם לא צריך לנצל חולשה בכלל?
מטרת המאמר הזה היא לא לעסוק בחולשות זיכרון, עקיפות, או exploits מתוחכמים. במקום זאת, נבחן שאלה הרבה יותר פשוטה - האם ניתן להשיג השפעה משמעותית על iPhone ללא ניצול חולשה, ללא עקיפת מנגנון אבטחה, וללא פגיעה במערכת ההפעלה?
כפי שנראה, התשובה קשורה פחות לשורות קוד ויותר ליחסים בין המשתמש למכשיר. אחרי הכול, iOS בנוי על מודל אמון מחמיר.
אבל יש גורם אחד שפועל מחוץ למנגנוני ההקשחה האלה.
גורם שכמעט תמיד מקבל את ההחלטה הסופית.
המשתמש.
הערת מחבר: במהלך כתיבת מאמר זה, לא נפגע אף מנגנון אבטחה של Apple. עם זאת, מספר משתמשים היפותטיים אכן לחצו על כפתור ההתקנה מבלי לקרוא אפילו אחת מהאזהרות שהוצגו להם.
מודל האמון של iOS
לפני שנדבר על Configuration Profiles, MDM, או מה אישורים דיגיטליים בעצם הם, צריך להבין מושג בסיסי אחד - רוב מנגנוני האבטחה ב-iOS מתוכננים למנוע מאפליקציות, קבצים, או תוקפים חיצוניים לבצע פעולות שלא אושרו על ידי מערכת ההפעלה. אבל מה קורה כשהפעולה אושרה על ידי המשתמש עצמו?
אם הייתי צריך לתאר “דיאגרמה” קונספטואלית יחסית של מודל האמון הכללי שמערכת ההפעלה של האייפון מסתמכת עליו, הייתי מתאר אותו בערך כך:
שלוש השכבות (מהבסיס למעלה)
השכבה הסגולה - שורש האמון: שכבה זו מייצגת את שורש האמון החומרתי של המכשיר. מנגנונים כמו Secure Enclave, Secure Boot, וניהול מפתחות קריפטוגרפיים מתוכננים להבטיח שהמכשיר מאתחל ממצב מהימן ידוע ולא משונה.
השכבה הירוקה - אכיפת אמון: כאן נמצאים מנגנונים כמו Code Signing, Sandbox, Trust Store, ומודל הרשאות גישה מלא. תפקידם להבטיח שאפליקציות וקוד לא יכולים לבצע פעולות שהמערכת לא אישרה מראש, ושקוד לא מורשה לא יכול לרוץ או לקבל גישה למשאבי מערכת.
השכבה הכתומה - חריגה, אבל מבוקרת: כאן מתחיל הסיפור של המאמר הזה. המודל של iOS הוא Default Deny, אבל במקרים מסוימים Apple מאפשרת למשתמש להרחיב את מעגל האמון של המכשיר. הרחבה זו לא שוברת את מנגנוני האבטחה ולא עוקפת אותם - היא פועלת דרכם, עם אישור מפורש של המשתמש. הרחבה זו מתבצעת באמצעות Configuration Profiles. כלומר, רוב מנגנוני האבטחה של iOS מתוכננים להגביל מה קוד יכול לעשות. Configuration Profiles מעניינים מסיבה אחרת - הם מאפשרים למשתמש להוסיף רכיבים, הגדרות, וזהויות שהמערכת לא הייתה סומכת עליהם כברירת מחדל.
אז מה הם Configuration Profiles, בעצם?
עבור רוב משתמשי ה-iPhone, זהו אחד המאפיינים הכי פחות מוכרים במערכת ההפעלה. משתמשים רבים לעולם לא ייתקלו בו במהלך חיי המכשיר שלהם. אלו שכן, בדרך כלל שייכים לאחת משתי קבוצות:
- עובדים בארגונים שמשתמשים במערכות MDM.
- אנשים שלחצו על קישור שבדיעבד הם לא היו לגמרי בטוחים שהיו צריכים ללחוץ עליו.
Configuration Profiles אינם מנגנון אבטחה - מבחינה מעשית, הם נולדו מתוך צורך תפעולי. כשארגונים התחילו לאמץ אייפונים בקנה מידה רחב, צצה בעיה: איך מגדירים מאות או אלפי מכשירים בלי לעבור על כל אחד מהם ידנית?
ארגון טיפוסי צריך להגדיר לעובדיו:
- חשבונות אימייל ארגוניים
- אישורים דיגיטליים
- חיבורי VPN
- רשתות Wi-Fi
- הגבלות אבטחה
- מדיניות סיסמאות
- הגדרות ארגוניות נוספות
לבצע את כל זה ידנית לאלפי עובדים זה לא מעשי. כדי לפתור את הבעיה הזו, Apple הציגה מנגנון שנקרא Configuration Profiles. במקום לבקש מהמשתמש להגדיר כל רכיב בנפרד, ניתן לשלוח למכשיר היעד קובץ שאומר למערכת ההפעלה בדיוק אילו הגדרות להחיל.
טכנית, Configuration Profile הוא קובץ טקסט חתום (או לא חתום) עם סיומת .mobileconfig. הוא Apple Property List בפורמט XML שמייצג Payloads שונים - כאשר כל Payload יכול להיחשב כ”יחידת הגדרה” בודדת.
לדוגמה:
- הגדרות Wi-Fi
- הגדרות VPN
- הגדרות אישורים
- הקשחה
- ועוד רבים...
כל הגדרה אחראית על רכיב שונה של המערכת. מאחורי הקלעים, מנקודת המבט של מערכת ההפעלה, Configuration Profile הוא בעצם רשימת הוראות לביצוע. לדוגמה:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>AutoJoin</key>
<true/>
<key>EncryptionType</key>
<string>WPA2</string>
<key>HIDDEN_NETWORK</key>
<false/>
<key>Password</key>
<string>[WIFI PASSWORD TRUNCATED]</string>
<key>PayloadDisplayName</key>
<string>Wi-Fi</string>
<key>PayloadIdentifier</key>
<string>com.example.profile.wifi.0</string>
<key>PayloadType</key>
<string>com.apple.wifi.managed</string>
<key>PayloadUUID</key>
<string>B1E2F89C-C8BF-4F4E-8B05-4F19E618A368</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>SSID_STR</key>
<string>[SSID NAME TRUNCATED]</string>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Configuration Profile</string>
<key>PayloadIdentifier</key>
<string>com.example.profile</string>
<key>PayloadOrganization</key>
<string>OrgName</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>8DA0EF1E-6AD4-4B68-A2BB-EDA3E55067E2</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
פירוט טכני של מה שאנו רואים כאן:
מה שמוצג למעלה הוא Configuration Profile בפורמט .mobileconfig - בפועל, Apple Property List בפורמט XML שמגדיר פרופיל הגדרות למכשיר iOS. ההגדרות כתובות בפורמט Key-Value.
במקרה הזה, הפרופיל מכיל Payload בודד - הגדרת Wi-Fi מנוהלת.
החלק החשוב ביותר הוא:
<key>PayloadType</key>
<string>com.apple.wifi.managed</string>
זה אומר ל-iOS שזו הגדרת Wi-Fi שהמערכת צריכה להוסיף למכשיר. לאחר התקנת הפרופיל, המכשיר יזהה רשת Wi-Fi ספציפית - כולל השם שלה, סוג ההצפנה, והסיסמה.
מבחינה מבנית, יש שתי שכבות:
- Payload Content
- Wi-Fi Payload
השכבה החיצונית היא הפרופיל עצמו (PayloadType: Configuration) - מעטפת כללית שמציינת שזהו פרופיל הגדרות. בתוכו נמצא PayloadContent, מערך של Payloads. במקרה הזה יש רק אחד, אבל תיאורטית אותו פרופיל יכול להכיל מספר Payloads יחד.
בתוך ה-Wi-Fi Payload:
SSID_STR- שם הרשת שהמכשיר יתחבר אליהPassword- סיסמת הרשת. בפרופיל אמיתי, הסיסמה מופיעה כחלק מהקובץ בטקסט גלוי, מה שהופך אותו למידע רגיש מאוד. כל מי שמחזיק את קובץ ה-.mobileconfigעשוי לראות את הסיסמה אם הפרופיל אינו מוגן או מוצפן כראויEncryptionType: WPA2- סוג האבטחה של הרשתAutoJoin: true- המכשיר ינסה באופן אוטומטי להתחבר לרשת כשהיא זמינהHIDDEN_NETWORK: false- הרשת אינה מוסתרת, כלומר ה-SSID משודר באופן רגילPayloadIdentifier/PayloadUUID/PayloadVersion- מטא-נתונים של Apple המשמשים לזיהוי וניהול ה-Payload
בשלב הזה, זו עדיין דוגמה שפירה יחסית. כל מה שעשינו זה לבקש ממערכת ההפעלה לשמור רשת ולהתחבר אליה אוטומטית. אבל ברגע שמבינים שהמשתמש יכול לגרום למכשיר לקבל הגדרות חיבור רשת חדשות, מעניין לשאול מה ההחלטה הזו אומרת בעולם האמיתי.
מסקנה מפתח: המשתמש לא מקליד סיסמת Wi-Fi. הוא מתקין פרופיל שאומר למכשיר איך להתנהג כלפי רשת ספציפית. וזה ההבדל המעניין:
- בתרחיש לגיטימי - ארגון מפיץ הגדרות Wi-Fi לעובדים.
- בתרחיש שמנוצל על ידי תוקף - הוא יכול לגרום למשתמש להתקין פרופיל שנראה כמו “Wi-Fi של הכנס” או “גישה מאובטחת לרשת”, ובפועל לגרום למכשירים להתחבר ל-Rogue AP. משם, מגוון סוגי תקיפה נהיה אפשרי:
נראות - המכשיר מתחבר לרשת שנשלטת על ידי מישהו אחר. שקלו את ערך המודיעין של לדעת:
- מתי המשתמש הגיע
- כמה זמן הוא נשאר
- כמה מכשירים התחברו
- אילו שירותים המכשיר מנסה להגיע אליהם
גילוי משטח תקיפה - כשמכשיר נמצא ברשת נתונה, הוא עשוי לחשוף שירותים שנגישים רק דרך Wi-Fi (בהתאם להגדרות הארגון):
- שמות מכשירים
- Service Discovery
- בקשות DNS
- דומיינים פנימיים
- רמזים לטופולוגיית רשת
הזדמנויות לקצירת אישורים - ניתן להפעיל תקיפות נוספות כדי לחלץ מידע מהקורבן:
- Captive Portals
- דפי כניסה מזויפים
שילוב מסוכן עם Payloads נוספים - Wi-Fi הוא Payload ספציפי אחד, אבל ניתן לשלב אותו עם סוגי Payload אחרים ליצירת שרשרת תקיפה מורכבת יותר:
חשוב לזכור שמאחורי כפתור Install תמים מסתתרת הוראה ישירה למערכת ההפעלה: “הוסף את הרשת הזו, שמור את הסיסמה, והתחבר אליה אוטומטית כשאתה רואה אותה”. כשלעצמם, Wi-Fi Payloads לא מעניקים לתוקף גישה למכשיר ולא מהווים פריצה למערכת ההפעלה. עם זאת, שילובם עם Payloads נוספים מאפשר לתוקף להשפיע הן על סביבת התקשורת של המכשיר והן על מעגל האמון שלו. במצב כזה, ניתן ליצור סביבה שנראית לחלוטין לגיטימית למשתמש - כולל פורטלים ארגוניים, שירותי אימות, וממשקי גישה שונים - מבלי להפעיל את מנגנוני האזהרה המוכרים שהמשתמש מצפה לראות כשניגש לאתר לא מהימן.
במובן הזה, האישור הדיגיטלי הוא לא המטרה - הוא הכלי שגורם לשאר השרשרת להיראות אמינה. לא שליטה על המכשיר, אלא היכולת לגרום למשתמש להפסיק לפקפק במה שהוא רואה. זו כבר השפעה הרבה יותר משמעותית מסתם עוד חיבור Wi-Fi.
חתום או לא חתום? זו השאלה
אחת השאלות הראשונות שעולות היא האם Configuration Profile חייב להיות חתום.
התשובה הקצרה: לא.
iOS מאפשרת התקנה של פרופילים לא חתומים גם כן. בזמן שפרופיל חתום מאפשר למערכת ההפעלה לאמת את מקורו ושלמותו, פרופיל לא חתום רק יציג אזהרה מתאימה למשתמש במהלך תהליך ההתקנה.
חשוב להבין - האזהרה לא מונעת התקנה, היא רק מודיעה למשתמש על הסיכון באופן כללי ומופשט. כפי שנראה, אפילו את זה אפשר לנצל.
בנקודה הזו אני רוצה להבהיר הבחנה חשובה: פרופיל הוא לא Malware, הוא לא ShellCode, לא RootKit, ולא Exploit. הוא פשוט דרך אוטומטית יחסית לבצע פעולות דרך מנגנונים רשמיים ומתועדים של מערכת ההפעלה. זו גם הסיבה שהשימוש בו כל כך מעניין - הוא לא מנסה לעקוף את מודל האבטחה של iOS, אלא פועל בתוכו.
אז איפה הבעיה?
מנקודת המבט של מערכת ההפעלה, התהליך פשוט:
- המשתמש קיבל פרופיל.
- המשתמש בחר להתקין אותו.
- המשתמש קרא את האזהרות.
- המשתמש אישר את הפעולה.
- הפרופיל הותקן.
מנקודת המבט של התוקף, התהליך נראה מעט אחרת:
- לגרום למשתמש לקבל פרופיל.
- לגרום למשתמש להתקין אותו.
- הכיף מתחיל.
השאר מטופל על ידי מערכת ההפעלה.
האנטומיה של Configuration Profile
לפני שננסה לשכנע משתמש להתקין פרופיל, כדאי להבין בדיוק מה אנחנו מתקינים. מאחורי מסך “התקן פרופיל” מסתתר, בסוף היום, קובץ XML די משעמם. וכמו בהרבה סיפורים בעולם הסייבר, הדברים המשעממים הם בדרך כלל הכי מעניינים.
לא כל ה-Payloads מעניינים באותה מידה. חלקם מתוכננים לנוחות, חלקם לניהול, וחלקם יכולים לשנות באופן משמעותי את מודל האמון של המכשיר.
הטבלה הבאה מפרטת את סוגי ה-Payload הזמינים, נכון למועד הכתיבה, דרך Apple. היא לא מיועדת ללימוד כל Payload בנפרד - מטרתה להמחיש את רוחב מנגנון ה-Configuration Profiles ואת מגוון רכיבי המערכת שניתן להגדיר דרכו.
| Payload | מטרה כללית | סוג Payload | למה משתמשים בזה | למה זה מעניין (תוקף / Red Team) |
|---|---|---|---|---|
| Wi-Fi | הגדרת רשתות אלחוטיות (SSID, EAP, WPA2/3, Hotspot 2.0) | com.apple.wifi.managed | חיבור אוטומטי לרשתות ארגוניות/ידועות ללא הגדרה ידנית | דחיפת SSID זדוני/אוטומטי; טעינת שרת EAP של תוקף לקצירת אישורי 802.1X; אילוץ חיבור ל-AP מבוקר |
| Ethernet | הגדרת רשת קווית | com.apple.*ethernet* | נקודות קצה קוויות מנוהלות | אותה לוגיקת MITM כמו Wi-Fi על מתאמים קוויים |
| VPN | VPN ברמת מכשיר (IKEv2/IPsec/L2TP) | com.apple.vpn.managed | ניתוב תעבורה לרשת ארגונית | On-Demand VPN = persistence + הפניית כל התעבורה דרך תשתית תוקף |
| App-Layer VPN | VPN לאפליקציה | com.apple.vpn.managed.applayer | הגבלת VPN לאפליקציות מנוהלות ספציפיות | יירוט סלקטיבי של תעבורת אפליקציה ממוקדת, קשה יותר לשים לב |
| Global HTTP Proxy ★ supervised | אילוץ כל HTTP(S) דרך proxy | com.apple.proxy.http.global | בקרת תוכן ברמת ארגון | MITM קלאסי: מנתב כל תעבורת אינטרנט דרך proxy של תוקף |
| DNS Settings / DNS Proxy | הגדרת DNS resolver / DoH/DoT | com.apple.dnsSettings.managed / com.apple.dnsProxy.managed | DNS ארגוני, סינון | הפניית name resolution, MITM שקט, ערוץ הוצאת מידע סמוי דרך DNS |
| Relay | ניתוב תעבורה דרך relay רשת | com.apple.relay.managed | גישה לרשת zero-trust | הכנסת relay של תוקף לנתיב התעבורה |
| Web Content Filter | סינון/בדיקת תעבורת אינטרנט | com.apple.webcontent-filter | סינון הורים/ארגוני | בדיקה או הפניית גלישה; בסיס למעקב |
| Domains / Associated Domains | הצהרת דומיינים מנוהלים/משויכים | com.apple.domains / com.apple.associated-domains | Universal links, מילוי אוטומטי של סיסמאות | חטיפת ניתוב universal-link או שיוך autofill לדומיין של תוקף |
| Certificates (incl. Root) | התקנת אישורי CA/זהות | com.apple.security.root / .pkcs12 / .pem / .pkcs1 | אמון ב-PKI פנימי, אימות לקוח | התקנת Root CA של תוקף → יירוט TLS מלא אם המשתמש מעניק אמון מלא; הליבה של סיכון "עקיפת הסכמת משתמש" |
| SCEP | רישום אוטומטי של אישור מכשיר דרך SCEP | com.apple.security.scep | הנפקת אישורים בקנה מידה | רישום זהות מכשיר ב-PKI של תוקף; עוגן ל-mutual-TLS |
| ACME | רישום אישורים אוטומטי מודרני | com.apple.security.acme | החלפה ל-SCEP, מפתחות מאומתים | אותו משטח ניצול רישום כמו SCEP |
| Certificate Revocation / Transparency | כוונון מדיניות OCSP/CRL ו-CT | com.apple.security.certificaterevocation / .certificatetransparency | שליטה בהתנהגות אימות אישורים | החלשת בדיקת ביטול כדי לשמור אישור זדוני בחיים |
| Passcode | אכיפת מדיניות סיסמה | com.apple.mobiledevice.passwordpolicy | קו בסיס אבטחה | החלשת מדיניות, או אילוץ נעילה (DoS); קריאת מצב להתאמת מטרה |
| Restrictions | מערכת גדולה של מתגי מאפיינים | com.apple.applicationaccess | השבתת מצלמה, התקנת אפליקציות, iCloud, Safari, וכו' | הורדת מצב אבטחה או נעילת המכשיר באופן זדוני |
| Single Sign-On / Extensible SSO ★ supervised | הגדרת ספקי SSO | com.apple.sso / com.apple.extensiblesso | אימות חלק לאפליקציות פנימיות | הכנסת IdP/extension של תוקף לנתיב האימות - יירוט אישורים/טוקנים |
| הגדרת חשבונות דואר | com.apple.mail.managed | הקצאת דואר ארגוני | הפניית דואר לשרת תוקף; קצירה/העברת הודעות | |
| Exchange ActiveSync | הגדרת חשבון Exchange | com.apple.eas.account | אימייל/לוח שנה ארגוני | אותו משטח הפניית דואר/אישורים |
| Google Accounts | חשבון Google OAuth | com.apple.google-oauth | הקצאת Workspace | מסגור פישינג OAuth / תפיסת טוקנים |
| Calendar / Contacts / LDAP | חשבונות PIM וספרייה | com.apple.caldav.account / .carddav.account / .ldap.account | הקצאת ספרייה ו-PIM | הוצאת מידע, סריקת מבנה ארגוני, ספרייה שנשלטת על ידי תוקף |
| Web Clips | הוספת קיצור דרך אינטרנטי למסך הבית | com.apple.webClip.managed | הפעלה מהירה של web apps | שתילת אייקון "אפליקציה" מזויף - משגר פישינג שנראה מקורי |
| App Lock ★ supervised | נעילת מכשיר לאפליקציה אחת | com.apple.app.lock | מצב קיוסק | קיוסק מאולץ = DoS ממוקד / נעילה |
| Home Screen Layout ★ supervised | אילוץ פריסת אייקונים | com.apple.homescreenlayout | סטנדרטיזציה של מכשירים | הסתרה/העברת אייקונים להנדסה חברתית |
| Lock Screen Message ★ supervised | הגדרת טקסט מסך נעילה | com.apple.shareddeviceconfiguration | תיוג נכסים | זיוף הודעות "רשמיות" / הוראות שחזור מזויפות |
| Setup Assistant | דילוג/שליטה במסכי הגדרה | com.apple.SetupAssistant.managed | ייעול תהליך onboarding | דילוג על הנחיות אבטחה/פרטיות במהלך הקצאה |
| Notifications ★ supervised | מדיניות התראות לאפליקציה | com.apple.notificationsettings | ניהול התראות | השתקת התראות אפליקציות אבטחה להסתרת פעילות |
| AirPlay / AirPrint / Fonts | שירותי מכשיר שונים | com.apple.airplay / .airprint / .font | הגדרות נוחות | AirPlay/AirPrint יכולים להוסיף נקודות קצה של תוקף; font payload הוא וקטור מסירת קבצים מינורי |
דבר אחד ששווה לציין: לא כל ה-Payloads בטבלה זמינים בכל תרחיש. חלקם דורשים Supervision - מצב מיוחד שמופעל דרך Automated Device Enrollment (ADE) או Apple Configurator עם חיבור פיזי למכשיר. ★ supervised מסמן אותם בטבלה למעלה.
ההשלכה המעשית היא שתוקף שמפיץ Configuration Profile למכשיר אישי לא מקבל באופן אוטומטי גישה ליכולות האלה. במובן הזה, דרישת ה-Supervision משמשת כשכבת הגנה נוספת ומגבילה באופן משמעותי את היקף הפעולות שניתן לבצע דרך פרופיל שמותקן ידנית.
דרישת ה-Supervision לא הופכת Payload מסוים ללא רלוונטי מנקודת מבט התקפית. עם זאת, תרחישים כאלה דורשים תנאי התחלה שונים משמעותית ואינם בפוקוס של מאמר זה.
אז איך בעצם יוצרים Configuration Profile?
במהלך המחקר, אחת השאלות הראשונות שעלו הייתה איך בעצם יוצרים פרופיל כזה. רשמית, Apple סיפקה במהלך השנים כלים כמו iPhone Configuration Utility ומאוחר יותר Apple Configurator, שמיועדים לסייע בניהול והגדרת מכשירים. הכלים האלה עובדים היטב, אבל תלויים בשימוש במוצרים של Apple עצמה.
כיום, רוב הארגונים יוצרים ומפיצים פרופילים דרך מערכות MDM שונות. אבל כשניסיתי למצוא כלי פשוט שיאפשר בנייה וניתוח של Configuration Profiles למטרות מחקר, לא מצאתי פתרון שהתאים בדיוק למה שחיפשתי.
אבל כפי שצוין, בפועל קובץ .mobileconfig הוא בסופו של דבר Apple Property List בפורמט XML. כלומר, אין כאן קסם. אם אתם יכולים לייצר XML (כלומר, לכתוב טקסט), אתם יכולים לייצר Configuration Profile.
מתוך הבנה זו, במהלך המחקר נבנה כלי קוד פתוח בשם ios-profile-builder, שמאפשר ליצור ולנתח Configuration Profiles למטרות לימוד, מחקר, ובדיקות אבטחה.
github.com/danieloz147/ios-profile-builder
הפנים הרבות של "Trust Me Bro"
אז הגענו לחלק הממש מעניין - לראות את ההשפעה בזמן אמת ולחקור כמה רחוק אפשר לקחת כל הגדרה. לאורך הסעיף הזה אבחן כמה סוגים שונים של פרופילים ואת ההשפעה הפוטנציאלית שלהם.
אבל, לפני שנתחיל לדבר על Web Clips, אישורים דיגיטליים, VPNs, או MDMs, יש עוד שאלה יסודית אחת שצריך לענות עליה. בסוף היום, אף אחת מהטכניקות שמוצגות להלן לא שווה הרבה אם המשתמש לא מתקין את הפרופיל מלכתחילה.
וזו הבעיה המרכזית שמעסיקה כל תוקף שמעוניין לנצל Configuration Profiles - איך לגרום למשתמש להגיע למסך ההתקנה וללחוץ Install?
כאן נכנסת לתמונה אחת מהטכניקות המעניינות והפופולריות ביותר של השנים האחרונות - ClickFix.
ClickFix: לא לגרום למערכת לבצע פעולה, אלא לגרום למשתמש לבצע אותה.
מאחורי ClickFix עומד רעיון די פשוט - במקום לעקוף מנגנוני אבטחה, אפשר לגרום למשתמש לבצע פעולה לגיטימית שהמערכת תוכננה לאפשר.
בקמפיינים שונים, משתמשים התבקשו להריץ פקודות PowerShell, להדביק פקודות בטרמינל, להתקין הרחבות דפדפן, לאשר הרשאות מערכת, או לבצע פעולות אחרות שבנסיבות רגילות היו מעלות חשד. המשותף לכל המקרים האלה הוא שהמערכת לא נפרצת. היא פשוט מקבלת הוראה חוקית ממשתמש שהשתכנע לבצע אותה.
אפשר להסתכל על ClickFix כהעברת מנגנון הביצוע מהתוקף למשתמש. במקום להריץ קוד מרחוק, התוקף מספק הוראות. המשתמש מבצע אותן. מערכת ההפעלה משלימה את השאר.
בנקודה הזו, החיבור לעולם ה-Configuration Profiles כמעט מציג את עצמו. אם iOS לא סומכת על אפליקציות אלא סומכת על החלטות המשתמש, ואם Configuration Profile הוא מנגנון לגיטימי לחלוטין של מערכת ההפעלה, אז המשימה היא לא לעקוף את מנגנוני האבטחה של iOS. המשימה היא פשוט לגרום למשתמש להשתמש בהם.
ClickFix היא לא הטכניקה היחידה, ולא בהכרח הנפוצה ביותר להפצת Configuration Profiles. למעשה, ברוב התרחישים שנבחנים בהמשך, אנחנו לא עוסקים ב-ClickFix במובנה הקלאסי.
הערך האמיתי של ClickFix בהקשר הזה הוא לא בטכניקה עצמה אלא בדרך החשיבה שהיא מייצגת. במקום להתמקד באיך לעקוף מנגנון אבטחה, היא מכוונת את תשומת הלב לאיך לגרום למשתמש לבצע פעולה לגיטימית שהמערכת כבר יודעת לבצע.
במובן הזה, ClickFix שימשה בעיקר כהשראה קונספטואלית למחקר. היא מספקת דרך נוחה להסתכל על אותה בעיה יסודית - איך לגרום למשתמש להרחיב מרצון את מעגל האמון של המכשיר.
למטרות המחקר הזה, נבנה תבנית ClickFix בסיסית שמדגימה את תהליך ההפניה להתקנת Configuration Profile. בתרחיש אמיתי, התוכן, המיתוג וההודעות היו מותאמים לקהל היעד ולמטרת הקמפיין.
github.com/danieloz147/ios-clickfix-templates
אז איך הפרופיל הזדוני מגיע למשתמש?
אם ClickFix עונה על השאלה “למה המשתמש לחץ Install?”, שאלה נוספת עולה כמעט מיידית - איך הפרופיל הגיע אליו מלכתחילה?
Configuration Profile אינו שונה מכל קובץ אחר. לפני שניתן להתקין אותו, המשתמש צריך לקבל אותו, לפתוח אותו, ולהתחיל את תהליך ההתקנה. כאן נכנס לתמונה שלב ה-Delivery.
בעולם הפישינג וההנדסה החברתית, Delivery הוא הערוץ שדרכו התוכן מגיע לקורבן. הודעת SMS, אימייל, קישור באתר, קוד QR, או אפילו מערכת ארגונית פנימית לגיטימית - כולם בסופו של דבר רק אמצעים למסירת אותו תוכן למשתמש. בהקשר של Configuration Profiles, שלב ה-Delivery לא קובע מה הפרופיל יעשה אחרי ההתקנה. הוא רק קובע איך המשתמש ייחשף אליו מלכתחילה.
הניצולים המוצגים בהמשך לא תלויים בערוץ הפצה ספציפי. אותו פרופיל יכול להגיע למשתמש דרך מגוון רחב של מנגנונים, והדוגמאות שבהמשך הן דוגמאות בלבד. בפועל, כמעט כל ערוץ שמסוגל לגרום למשתמש לפתוח קישור או להוריד קובץ יכול פוטנציאלית גם לשמש להפצת פרופיל.
Trust Me Bro, זו האפליקציה שלנו
מה זה עושה?
Web Clip הוא Payload שמוסיף אייקון למסך הבית כקיצור דרך לאתר - לא יותר. למרות המראה, זו לא אפליקציה, לא מותקן קוד על המכשיר, ולא ניתנות הרשאות מערכת נוספות.
היתרון העיקרי של Web Clip הוא שהוא מוגדר להיפתח במצב מסך מלא - האתר נטען ללא אלמנטי ממשק הדפדפן המוכרים שהמשתמש רגיל לראות. החוויה המתקבלת דומה מאוד לאפליקציה ייעודית, במיוחד כשהאתר עצמו תוכנן בהתאם.
מקרה ניצול
במבט ראשון, Web Clip לא נראה מעניין במיוחד מנקודת מבט התקפית. אחרי הכול, אפשר לשלוח למשתמש קישור דרך SMS, אימייל, או WhatsApp באותה קלות. ההבדל המרכזי הוא ש-Web Clip נותן לאתר נוכחות קבועה במסך הבית של המכשיר. עם הבחירה הנכונה של שם, אייקון, וממשק, ניתן לגרום לו להיראות כמו אפליקציה ארגונית לגיטימית שהותקנה על ידי מחלקת ה-IT.
מנקודת המבט של iOS, כמובן, לא הותקנה אפליקציה בכלל. מנקודת המבט של המשתמש, לעומת זאת, ההבדל לא תמיד ברור.
וכאן זה מתחיל להיות מעניין.
לאתרים מודרניים יש כעת גישה למגוון רחב של Web APIs שמאפשרים להם לבצע פעולות שפעם היו שמורות כמעט בלעדית לאפליקציות ייעודיות. בהתאם לאישור המשתמש ויכולות נתמכות של הדפדפן, אתר עשוי לקבל גישה ל:
- Geolocation API - קבלת מיקום גיאוגרפי
- Camera API - גישה למצלמה
- Microphone API - גישה למיקרופון
- Notifications API - הצגת התראות Push (במקרים נתמכים)
- Clipboard API - קריאה וכתיבה ל-clipboard
- File Upload APIs - גישה לקבצים שהמשתמש בוחר לשתף
- Device Orientation / Motion APIs - נתונים מחיישני תנועה וכיוון
- WebRTC - תקשורת אודיו, וידאו, ו-Data Channels בזמן אמת
חשוב להדגיש שכל אחת מהיכולות האלה כפופה למנגנוני ההרשאות וההגבלות של Safari. Web Clip לא עוקף את מודל האבטחה של מערכת ההפעלה ולא מספק גישה בלתי מוגבלת למכשיר. עם זאת, כל עוד ה-Web Clip נשאר פתוח ולא נסגר לחלוטין, האתר יכול להמשיך להשתמש בהרשאות שאושרו מבלי להציג בקשות נוספות - יתרון משמעותי עבור תוקף.
שיטת ההפצה שנבחרה כאן (באופן שרירותי)
הודעת SMS המכילה את התוכן הרלוונטי, מעוצבת כך שתיראה כחלק משיחה קיימת עם שולח ידוע.
מחברים הכול - הדגמת תקיפה מלאה:
במהלך המחקר, מצאתי שהחלק הכי מעניין הוא לא בהכרח ה-Web Clip עצמו, אלא הסיפור שנבנה סביבו. טכנית, Web Clip הוא רק קיצור דרך מתקדם לדף אינטרנט. אבל כשמוצג כחלק מקמפיין אמין - עם מיתוג בסגנון ממשלתי, הודעות עקביות, ועדכונים שוטפים - הוא הופך לכלי בעל עוצמה משמעותית.
זה בעצם העיקרון של “Trust Me, It’s Our App”. המשתמש לא מתקין את ה-Web Clip כי הוא מבין מה Web Clip הוא, אלא כי הוא מאמין בסיפור שמוצג לו. ברגע שהאמון הראשוני נוצר, התוקף יכול לשמר את האמון הזה לאורך זמן על ידי עדכון התוכן, שינוי ההודעות, והתאמתם לאירועים אקטואליים.
למטרות המחקר הזה פיתחתי שרת C2 ייעודי שמאפשר ניהול ועדכון Web Clips באופן ריכוזי. במהלך העבודה מצאתי גם שיטות שמאפשרות להפוך את תהליך ההתקנה לחלק לחלוטין עבור המשתמש דרך גישה ספציפית להתקנת Configuration Profile - אבל מכיוון שהידע הזה יכול להיות מנוצל לרעה באופן מוגזם, בחרתי לא לפרט אותו במאמר הזה.
המסקנה העיקרית היא שהסיכון לא נובע רק מיכולת טכנית ספציפית, אלא מהשילוב של יכולות ניהול שוטפות עם סיפור אמין שמצליח לגרום לקורבן לראות את ה-Web Clip כאפליקציה לגיטימית לחלוטין.
פירוט טכני של ההדגמה
הסרטון מציג את WebClip C2 - פלטפורמת Command & Control שפותחה למטרות מחקר, המדגימה כיצד ניתן לנהל Web Clips באופן ריכוזי, בדומה לניהול Agents במערכות C2 קלאסיות.
מימין iPhone עם Web Clip מותקן שמתחזה לאפליקציה לגיטימית - במקרה הזה “SafeAlert”, המדמה שירות התראות חירום ועדכונים ציבוריים. משמאל ממשק הניהול.
רישום וזיהוי קורבן
עם פתיחת ה-Web Clip, הדפדפן מתקשר עם שרת ה-C2 ונרשם כמכשיר חדש. מאותו רגע הוא נראה בלוח הבקרה עם פרטים טכניים ומעקב פעילות. המערכת אוספת:
- מזהה התקנה ייחודי
- פרטי מערכת הפעלה ודפדפן
- הרשאות שניתנו
- זמני חיבור ויומן פעילות
- נתוני Fingerprinting לזיהוי קורבן עקבי
- מיקום גיאוגרפי
לשונית Intelligence מציגה נתוני מיקום בזמן אמת שמתקבלים מהמכשיר לאחר אישור המשתמש - ממחישה כיצד Web Clip שנראה כמו אפליקציה תמימה יכול לאסוף נתוני מיקום בדיוק גבוה.
סריקת רשת מקומית
המערכת מבצעת סריקה מתוך סביבת הדפדפן לזיהוי:
- כתובת Default Gateway
- כתובות IP פעילות
- פורטים נגישים
- שירותים פנימיים שניתן לזהות
זה נותן לתוקף תמונה ראשונית של סביבת הרשת שבה הקורבן נמצא.
מודול Harvest
מודול ה-Harvest מרכז פעולות איסוף מידע שונות, כולל:
- איסוף מיקום
- מיפוי הרשאות
- בדיקת גישה למצלמה ומיקרופון
- אינטראקציה עם clipboard
- Push Notifications
- מסכי הנדסה חברתית
מטרת המודולים האלה היא לא לנצל חולשת אבטחה - אלא לנצל את אמון המשתמש ואת מודל ההרשאות הקיים של הדפדפן.
מסך לכידת PIN
לקראת סוף הסרטון, מודגם PIN Capture. המפעיל דוחף מסך ייעודי למכשיר הקורבן, שמציג ממשק שמדמה בקשת אימות לגיטימית. מכיוון שמפעיל ה-C2 שולט בתוכן הדף, הודעות, עיצוב, ותרחישי הנדסה חברתית יכולים להתעדכן בזמן אמת.
זו אחת הנקודות החשובות ביותר במחקר: הכוח האמיתי לא מגיע מיכולת טכנית ספציפית אחת, אלא מהיכולת לשמר מערכת יחסים אמינה עם הקורבן לאורך זמן. התוקף יכול לעדכן את התוכן בכל רגע, להתאים אותו לאירועים אקטואליים, ולשמר את האשליה של אפליקציה לגיטימית ומתוחזקת פעילה.
קוד המקור המלא זמין בפומבי:
github.com/danieloz147/webclip-c2
הערת צד: בדרך כלל, כשמשתמש סוגר Web Clip או מעביר אותו לרקע, סביבת ה-JavaScript שלו מושעית והגישה להרשאות נפסקת איתה. במהלך המחקר מצאתי כמה מנגנונים שמאפשרים להאריך את חיי הסשן ולשמר לוגיקה מסוימת גם כשה-Web Clip אינו בחזית. שיטה אחת שניסיתי השתמשה בנגן מדיה פעיל שמשדר אות אודיו בלתי נתפס, מה שגרם למערכת ההפעלה להמשיך להתייחס לאפליקציה כפעילה. פיתחתי גם מנגנון שני מבוסס Notifications, שלא מוצג בסרטון. ההשראה הגיעה מהאופן שבו שירותים כמו YouTube ממשיכים להריץ לוגיקה אחרי שהמשתמש עובר לאפליקציה אחרת או ממזער את חלון הדפדפן.
Trust Me Bro, זה ה-Wi-Fi של החברה
מה זה עושה?
Wi-Fi Payload מאפשר להגדיר מראש רשת אלחוטית על המכשיר דרך Configuration Profile. מנקודת המבט של המשתמש, זו דרך נוחה להתחבר אוטומטית לרשת ארגונית ללא הזנת סיסמה או הגדרה ידנית.
בארגונים רבים זהו תהליך לגיטימי לחלוטין - מחלקת ה-IT שולחת לעובדים Configuration Profile, המשתמש מאשר את ההתקנה, והמכשיר מתחבר אוטומטית לרשת הארגונית. מנקודת המבט של מערכת ההפעלה, זהו מנגנון ניהול רגיל ומוכר. מנקודת המבט של תוקף, זהו מנגנון שנבנה כמעט כולו על אמון וניתן לניצול.
מקרה ניצול
לרוב המשתמשים אין מושג מה Wi-Fi Profile בעצם מכיל. כשמוצגת להם הודעה כמו “התקן את פרופיל הרשת הארגונית החדש” או “התחבר לרשת החירום של החברה”, רובם יניחו שמדובר בפעולה שגרתית שמגיעה ממחלקת ה-IT.
המשתמש הממוצע רואה שם רשת מוכר, לוגו ארגוני, והוראות שנראות לגיטימיות. הוא לא בוחן את פרטי ההגדרה ולא בודק אילו הגדרות נוספות נכללו בפרופיל. וכאן זה הופך למעניין.
עבור רוב האנשים, Wi-Fi זו תשתית - משהו ש”צריך פשוט לעבוד”. דווקא בגלל זה, בקשות שקשורות לקישוריות רשת נתפסות כפחות חשודות מהתקנת אפליקציה, הזנת סיסמה, או פתיחת קובץ לא מוכר. התוקף מנצל את האמון המובנה שיש למשתמשים בתהליכי חיבור לרשת.
שיטת ההפצה שנבחרה כאן (באופן שרירותי)
להדגמה זו, נבחר תרחיש פשוט יחסית: התוקף מפיץ פלייר שנראה כאילו נשלח או שותף על ידי החברה. הפלייר מכיל QR Code שמפנה לאתר ההתקנה.
המשתמש סורק את הקוד, עובר תהליך התקנה שנראה לגיטימי לחלוטין, ומאשר את התקנת ה-Configuration Profile. לאחר סיום התהליך, המכשיר מתחבר אוטומטית לרשת ה-Wi-Fi שהוגדרה על ידי התוקף.
מרגע החיבור, ניתן להציג למשתמש Captive Portal או מסך “אימות משתמש” שמתחזה למנגנון אימות ארגוני לגיטימי. מנקודת המבט של המשתמש, זהו תהליך מוכר של חיבור לרשת הארגונית. מנקודת המבט של התוקף, זו הזדמנות לקצירת אישורים או מידע רגיש אחר.
בניגוד לפשוט לספק SSID וסיסמה, Wi-Fi Profile מאפשר לתוקף להגדיר מראש את כל פרטי החיבור, לבחור במדויק לאילו רשתות המכשיר יצטרף, וליצור חוויית onboarding שנראית כמו תהליך IT רשמי ומנוהל.
מחברים הכול - הדגמת תקיפה מלאה:
בדומה לתרחיש ה-Web Clip, הכוח של התקיפה הזו לא מגיע ממנגנון טכני מורכב במיוחד, אלא מהאמון שהמשתמש שם בתהליך. המשתמש מתחבר לרשת לא כי הוא בדק את פרטי ההגדרה, אלא כי הוא מאמין שזו הרשת הארגונית הלגיטימית. בדיוק בנקודה הזו מנגנון ניהול לגיטימי הופך לכלי יעיל בשרשרת תקיפה מבוססת הנדסה חברתית.
פירוט טכני של ההדגמה
הסרטון מציג תרחיש מלא שבו משתמש מתבקש להתחבר לרשת האלחוטית של ארגון בדוי בשם Aurora Energy Group. התהליך מתחיל בדף נחיתה ייעודי שמציג את תהליך ההתחברות כפרוצדורת IT שגרתית, ומספק למשתמש הוראות ברורות להתקנת ה-Configuration Profile. לאחר אישור הפרופיל באייפון, המערכת מגדירה אוטומטית רשת Wi-Fi חדשה בשם Aurora-Employee, והמכשיר מתחבר אליה ללא צורך בהזנת סיסמה או פעולת משתמש נוספת.
מיד לאחר ההתחברות, מופיע Captive Portal - שמעוצב כהמשך חלק של המיתוג והחוויה שהוצגו בשלבים הקודמים. הפורטל מציג מסך אימות ארגוני ומבקש מהמשתמש להזין את פרטי הכניסה שלו כדי “להשלים את ההתחברות”. מנקודת המבט של המשתמש, זהו תהליך אחיד ורציף של חיבור לרשת הארגונית. מנקודת המבט של התוקף, זו שרשרת של רכיבים לגיטימיים לחלוטין שמובילה לקצירת אישורים.
ההדגמה ממחישה כיצד ניתן למנף מנגנוני Wi-Fi ו-Captive Portal סטנדרטיים ליצירת חוויית משתמש אמינה ומשכנעת, ללא הסתמכות על חולשות אבטחה או עקיפת הגנות מערכת ההפעלה.
Trust Me Bro, תנתב הכול דרכי
מה זה עושה?
VPN Payload מאפשר להגדיר חיבור VPN על המכשיר דרך Configuration Profile. לאחר ההתקנה, המכשיר יכול לנתב את תעבורת הרשת שלו דרך שרת VPN שהוגדר מראש, ללא צורך בהגדרה ידנית כלשהי מצד המשתמש.
ארגונים משתמשים בהרחבה ב-VPN כחלק אינטגרלי מתשתית הגישה לרשת שלהם, במיוחד עבור עובדים מרוחקים או מכשירים ניידים.
בניגוד להגדרות מבוססות Proxy, פתרון VPN מציע בדרך כלל כיסוי רחב יותר של תעבורת רשת. מכיוון שהניתוב מתרחש ברמת מערכת ההפעלה, רוב האפליקציות לא יכולות לעקוף אותו בקלות - מה שמוביל לשליטה עקבית יותר על נתיבי התקשורת של המכשיר.
עם זאת, יש גם הבדל משמעותי מבחינת נראות למשתמש (OPSEC). מערכות הפעלה מודרניות בדרך כלל מציגות אינדיקציה ברורה כשחיבור VPN פעיל - בין אם דרך אייקון ייעודי או הודעה בשורת הסטטוס. בפועל, משתמשים רבים נוטים להתעלם מהאינדיקציה הזו או לא להבין את משמעותה, אבל זה עדיין רמז חזותי שלא תמיד קיים עם מנגנונים אחרים.
למרות שניתן להשיג תוצאות דומות באמצעות Global HTTP Proxy Payload, בחרתי להתמקד ב-VPN מכיוון שהוא אינו תלוי בדרישות ניהול Supervised Device. עבור תרחיש המחקר הזה, VPN מספק שרשרת תקיפה פשוטה, מעשית, ומציאותית יותר.
התקנת VPN לבדה לא מעניקה אוטומטית את היכולת לבדוק או לפענח תעבורת HTTPS. לשם כך, יש לפרוס גם אישור Root CA מהימן למכשירי היעד. טכנית, האישור יכול להיכלל כחלק מאותו Configuration Profile, אבל למערכות הפעלה מודרניות יש מנגנוני הגנה נוספים שדורשים מהמשתמש לאשר במפורש אמון באישור.
זה יוצר נקודת חיכוך נוספת בתהליך הפריסה. מניסיוני, משתמשים לא מקבלים החלטות כאלה על בסיס הבנה טכנית של מה Root CA אומר, אלא על בסיס רמת האמון שלהם בגורם שמבקש את ההתקנה. לכן, כמו עם מנגנוני ניהול אחרים שנדונו במאמר זה, הגורם המשמעותי ביותר כאן אינו טכני גרידא - הוא אנושי. היכולת לשכנע את המשתמש שזהו רכיב לגיטימי שנדרש לשיפור אבטחה, תיקון תקלות, או גישה לשירותים ארגוניים.
מקרה ניצול
רוב המשתמשים לא מבינים את ההשלכות המעשיות של התקנת VPN Profile או את היקף ההשפעה שלו על תקשורת המכשיר. כשמוצגת להם הודעה כמו “נדרש עדכון אבטחה לגישה לשירותי החברה” או “התקינו Secure Access Gateway לשיפור אבטחת הגלישה”, הם בדרך כלל יתייחסו לזה כעוד צעד טכני בתהליך ה-onboarding הארגוני.
מנקודת המבט של המשתמש, שום דבר לא משתנה באופן מהותי. אפליקציות ממשיכות לעבוד, אתרים ממשיכים להיטען, ועבודה יומיומית ממשיכה כרגיל.
מנקודת המבט של התוקף, לעומת זאת, המכשיר עשוי להתחיל לנתב חלק משמעותי - או את כל - תעבורת הרשת שלו דרך תשתית שנשלטת על ידו.
שיטת ההפצה שנבחרה כאן (באופן שרירותי)
להדגמה זו, נבחר תרחיש שבו התוקף שולח אימייל שמתחזה לתקשורת רשמית ממחלקת ה-IT. ההודעה מציגה יוזמת אבטחה או שדרוג תשתית וכוללת QR Code שמפנה לדף התקנה ייעודי.
מנקודת המבט של המשתמש, זהו עוד תהליך ארגוני שגרתי שמיועד לשיפור אבטחת הגלישה או גישה לשירותים פנימיים.
לאחר השלמת ההתקנה, הגדרות הרשת החדשות מוחלות על המכשיר, והמשתמש ממשיך להשתמש בו בצורה לגמרי רגילה - מבלי שנדרשת ממנו פעולה נוספת כלשהי. עבור המשתמש, זהו תהליך onboarding סטנדרטי. עבור התוקף, זו נקודת שליטה חדשה שהושגה דרך הנדסה חברתית בלבד.
מחברים הכול - הדגמת תקיפה מלאה:
פירוט טכני של ההדגמה
הסרטון מציג תרחיש שבו משתמש מקבל הודעה שמתחזה לתקשורת רשמית ממחלקת ה-IT של הארגון. ההודעה מתארת בעיות קישוריות שהתגלו לאחרונה ומזמינה את המשתמש להתקין עדכון הגדרות רשת חדש על ידי סריקת QR Code שמצורף לאימייל.
לאחר סריקת הקוד, המשתמש מופנה לאתר התקנה ייעודי ומתקין Configuration Profile שמכיל הגדרות VPN. תהליך ההתקנה מוצג כחלק משדרוג תשתית לגיטימי שמיועד לשיפור יציבות החיבור והגישה לשירותים ארגוניים.
עם השלמת ההתקנה, המכשיר יוצר חיבור VPN ומתחיל לנתב תעבורת רשת דרך התשתית שהוגדרה בפרופיל. בצד התוקף, המכשיר החדש מופיע בזמן אמת בממשק הניהול - כולל כתובת ה-IP שהוקצתה לו, סטטוס החיבור, ומידע פעילות נוסף.
הסרטון לאחר מכן מדגים מספר מודולים לניתוח תעבורה שעוברת דרך התשתית, כולל סיווג שירותים ואתרים, מידע דומיינים שנצפו בתעבורה, סטטיסטיקות שימוש, ונתונים נוספים שנאספו כחלק מפעילות ניטור.
אחד ההיבטים המעניינים של תרחיש זה הוא שהוא יכול לשמש כשלב ראשון בשרשרת תקיפה רחבה יותר. במקום להסתמך על exploit או הרצת קוד, התוקף משיג עוגן ראשוני דרך מנגנוני ניהול לגיטימיים והאמון שהמשתמש שם בהם.
Trust Me Bro, אני IT
מה זה עושה?
MDM Enrollment Payload מאפשר לרשום מכשיר במערכת Mobile Device Management. לאחר ההרשמה, שרת הניהול יכול לנהל היבטים שונים של המכשיר המנוהל בהתאם להרשאות שניתנו, לפרופילים שהותקנו, ולמדיניות הארגונית שהוגדרה.
MDM הוא אחד ממנגנוני הניהול המרכזיים של Apple, בשימוש על ידי ארגונים ברחבי העולם לניהול נקודות קצה, הפצת הגדרות, התקנת פרופילים, אכיפת מדיניות אבטחה, פריסת אישורים דיגיטליים, הגדרת VPN, Wi-Fi, דואר ארגוני, ועוד.
בניגוד ל-Payloads האחרים שנסקרו במאמר, MDM מעניין לא בגלל פעולה ספציפית אחת שהוא יכול לבצע. הוא מעניין כי הוא משנה את מערכת היחסים בין המכשיר לשרת. במקום להתקין רכיב בודד, המשתמש מעניק לשרת מעמד של סמכות ניהולית. מנקודה זו ואילך, רבות מהפעולות שהוצגו בסעיפים קודמים יכולות להתבצע כחלק ממנגנון הניהול הלגיטימי של המערכת. במובן מסוים, זהו ה-Final Boss של סדרת ה-Trust Me Bro.
מקרה ניצול
רוב המשתמשים לא מבינים במלואו מה המשמעות של רישום מכשיר במערכת MDM. כשמוצגת להם הודעה כמו “המכשיר שלך צריך להיות רשום בשירותי החברה” או “התקן רכיב ניהול לגישה למשאבים ארגוניים”, רובם יתייחסו לזה כחלק טבעי מתהליך ה-IT.
מצד המשתמש:
- הוא רואה מסכי מערכת רשמיים של iOS
- הוא רואה את המונח Remote Management
- הוא רואה את שם הארגון
- הוא רואה שהמערכת עצמה מבקשת אישור
דווקא כי כל האלמנטים האלה מגיעים ממערכת ההפעלה, הם מחזקים את תחושת הלגיטימיות ומפחיתים את רמת החשד של המשתמש. בפועל, המשתמש לא מאשר את ההרשמה כי הוא מבין מה מערכת MDM היא או אילו הרשאות הוא מעניק. הוא מאשר כי הוא סומך שהגורם שמולו הוא מחלקת ה-IT.
וזו בדיוק הנקודה שהופכת את ה-Payload הזה לייחודי.
אם כל אחד מהסעיפים הקודמים עסק בניצול מנגנון ניהול בודד - Web Clip, Wi-Fi, VPN, או אישורים - MDM יושב מעל כולם. הוא לא רק עוד Payload; הוא מנגנון שמסוגל לפרוס ולנהל רבים מאותם רכיבים כחלק מתהליך ניהול לגיטימי.
שיטת ההפצה שנבחרה כאן (באופן שרירותי)
להדגמה זו, נבחר תרחיש שבו המשתמש מחבר את האייפון שלו למחשב שנשלט על ידי מישהו שמתחזה ל-IT. המשתמש מתבקש לאשר את הנחיית “Trust This Computer” כחלק מתהליך תמיכה, אבחון, או רישום מכשיר.
לאחר אישור ה-Trust, נוצר Pairing Record בין המחשב למכשיר. מנקודה זו, ניתן להשתמש בכלים לגיטימיים כמו pymobiledevice3 כדי לתקשר עם שירותי ניהול של iOS דרך ממשקי Lockdown ו-usbmux. בתרחיש ההדגמה, הכלי משמש להתקנת Configuration Profile שמתחיל MDM Enrollment - באמצעות מנגנונים נתמכים של Apple וללא ניצול חולשה כלשהי במערכת ההפעלה.
נקודת המחקר המרכזית היא שהמשתמש לא תופס את פעולת ה-Trust כהענקת גישה ניהולית משמעותית. מנקודת המבט שלו, זהו אישור טכני רגעי שנדרש כדי ש”המחשב יזהה את האייפון”. בפועל, זוהי העברת אמון חשובה - ברגע שהמכשיר מזווג, המחשב מקבל את היכולת לבצע אינטראקציות ניהול מסוימות עם המכשיר כל עוד הגבלות iOS, מצב נעילה, והרשאות משתמש מאפשרים זאת.
הערה חשובה: בניגוד למה שלפעמים מניחים, רישום מכשיר במערכת MDM לא הופך את שרת ה-MDM ל-C2 ולא מעניק שליטה בלתי מוגבלת על המכשיר. גם לאחר ההרשמה, שרת ה-MDM כפוף למודל ההרשאות ויכולות הניהול של Apple, ואינו יכול לבצע פעולות שרירותיות או להריץ קוד בחופשיות.
עם זאת, דווקא כי זהו מנגנון ניהול לגיטימי עם אמון גבוה, הוא יכול לשמש כנקודת מוצא יעילה לשרשרת תקיפה רחבה יותר. לאחר שהמשתמש משלים את תהליך ההרשמה, ניתן לפרוס רכיבי ניהול נוספים שנתמכים על ידי הפלטפורמה, להחיל מדיניות ארגונית נוספת, ולבצע פעולות ניהול נוספות כחלק ממערכת היחסים שנוצרה בין המכשיר לשרת. יש אפשרות לקחת את התרחיש רחוק יותר - אבל מכיוון שהמאמר הזה כבר ארוך, זה יידון במאמר נפרד.
מחברים הכול - הדגמת תקיפה מלאה:
פירוט טכני של ההדגמה
להדגמה, נבנה שרת MDM אישי במיוחד למחקר הזה. הסיבה לבחירה בשרת MDM אישי הייתה להמחיש שמנגנון ההרשמה והאמון שמציג iOS זהה לזה שמשמש ארגונים בסביבות ייצור.
בסוף ההדגמה, המכשיר נרשם בהצלחה בשרת ה-MDM ומופיע בקונסולת הניהול כמכשיר מנוהל. כאן מסתיים התרחיש שמוצג במאמר זה. בניגוד לסעיפים הקודמים, שבהם המיקוד היה ביכולות של Payload בודד, הדגש כאן הוא על יצירת מערכת יחסים מתמשכת בין המכשיר לשרת הניהול - מערכת יחסים שממנה ניתן להמשיך לבצע פעולות ניהול נוספות בתוך היקף היכולות הלגיטימיות של Apple.
לשחזור סביבת המחקר, פותחה תשתית מלאה מבוססת pymobiledevice3 ושרת MDM, כולל כל רכיבי ההתקנה, הסקריפטים וההוראות הנדרשות לבניית סביבת מחקר זהה. קוד המקור המלא, הוראות ההתקנה, ותיעוד הפרויקט זמינים כאן:
github.com/danieloz147/nanohub-and-mdm
טיפ חשוב: לחיזוק תחושת הלגיטימיות, ניתן להשתמש בשירות MDM ציבורי שמציע תקופת ניסיון חינמית. כתוצאה מכך, תהליך ההרשמה מתרחש מול שרת MDM אמיתי, והפרופיל שמוצג למשתמש חתום ומזוהה על ידי iOS בדיוק כפי שהיה נראה ברישום ארגוני לגיטימי. מנקודת המבט של המשתמש, אין אינדיקציה שהסביבה שייכת לתוקף.
שירותים כאלה זמינים ב:
- SimpleMDM - מציע תקופת ניסיון חינמית לאחר רישום - simpleMDM.com
- Jamf Pro - מציע תקופת ניסיון חינמית לאחר רישום - jamf.com/products/jamf-now
- Mosyle - מציע תכנית חינמית לארגונים קטנים (עד מספר מוגבל של מכשירי Apple), וכן תקופות ניסיון מורחבות לתכניות מתקדמות - mosyle.com
מה בא אחר כך
למרות שהמאמר הזה כיסה מגוון רחב של Payloads שנתמכים על ידי Apple Configuration Profiles, הוא רחוק ממיצוי כל האפשרויות שהפלטפורמה מציעה. מטרתו הייתה להציג את נקודות החיכוך המרכזיות בין מנגנוני ניהול לגיטימיים לבין האמון שמשתמשים שמים בהם - לא לשמש כמפה מלאה של כל יכולות iOS.
לאורך העבודה, התמקדתי בעיקר בתרחישים שבהם המשתמש הוא החוליה המרכזית והחלשה ביותר בשרשרת.
נושא אחד שלא נסקר במאמר זה - אבל שיהיה המוקד של המחקר הבא - הוא בחינת הגבול בין מנגנוני הניהול הלגיטימיים של Apple ובין היכולת להפוך אותם לפלטפורמת ניהול מתמשכת. המאמר הבא יבחן מה ניתן לעשות אחרי שהאמון כבר ניתן. הוא יציג תרחישים כולל פריסת אפליקציות מנוהלות, הקמת ערוץ תקשורת מתמשך (C2) מבוסס מנגנוני פלטפורמה לגיטימיים, ושילוב יכולות ניהול נוספות כדי להבין כמה רחוק ניתן למתוח את גבולות ה-MDM מבלי לחרוג ממודל האבטחה של Apple. כלומר, אם המאמר הזה היה על יצירת מערכת היחסים - הבא יהיה על כמה רחוק אפשר לקחת אותה.
לבסוף, אני מאמין שהחלק הכי מעניין הוא בכלל לא טכני. בסופו של דבר, כל תרחיש שהוצג במאמר הזה נשען על אותה הנחה פשוטה: משתמשים לא שמים את אמונם בטכנולוגיה - הם שמים את אמונם בסיפור שמספרים להם. הבנת מערכת היחסים בין מנגנוני הניהול של Apple לבין תפיסת האמון של המשתמשים היא, לדעתי, אחד מכיווני המחקר המעניינים ביותר באבטחה התקפית.