חזרה לכל המאמרים
    גם קישור שאי אפשר לנחש אפשר למצוא
    AI SecurityPrivacyDNSMeta AIAccess Control

    גם קישור שאי אפשר לנחש אפשר למצוא

    Y

    Yoni Fraimorice

    שיתוף:

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

    אולי קשה לנחש את הקישור. זה לא אומר שקשה למצוא אותו.

    מחקר GhostShares של Claroc מתאר את הפער הזה במנגנון השיתוף של Meta Muse. הפרט החשוב הוא איפה הופיעו כותרת השיחה והמזהה האקראי: בתוך שם שרת שתשתית ה-DNS יכולה לראות.

    עמודים ששותפו, לא גישה לצ׳אטים פרטיים

    לפי Claroc, המשתמשים ביקשו מ-Muse ליצור את השיתופים האלה. העמודים שנוצרו נפתחו בדרך כלל בלי התחברות לכל מי שהחזיק בקישור.

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

    Claroc לא פנתה לאנשים המעורבים, ולכן אינה יכולה לקבוע למי הם התכוונו לתת גישה.

    אחרי סינון רעש מסריקות, החוקרים ספרו יותר מ-6,800 שמות שרת של שיתופים במאגר passive DNS מסחרי אחד. הם פתחו כמה מאות עמודים, מצאו בעיקר תוכן רגיל, ובמיעוט מהם מידע אישי או עסקי רגיש.

    זה לא אומר שנמצאו 6,800 שיחות רגישות או משתמשים שנפגעו. זו ספירה של שמות שרת מתוך ערוץ גילוי אחד. גם הדיווח של Quartz מתאר את אותו מחקר, לא חקירה פורנזית נפרדת.

    יש גם עדכון חשוב. לפי Claroc, ב-20 באוקטובר מסרה Meta ל-Ars Technica שהיא משהה את התכונה. Claroc בדקה שוב באותו יום 40 שיתופים שהיו נגישים קודם. אף אחד מהם לא נפתח, ושמות השרת ששימשו לתוכן החזירו שגיאות. לדברי החוקרים, שמות השרת, כולל הכותרות, נשארו בהיסטוריית ה-DNS.

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

    איך קישור מגיע ל-DNS

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

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

    הנה דוגמה מומצאת שמשתמשת בדומיינים השמורים להדגמה תחת .example:

    טקסט
    Share link:
https://assistant.example/s/project-plan-RANDOM_ID

Content hostname:
project-plan-RANDOM_ID.content.example

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

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

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

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

    למה ההגנות המוכרות לא פותרות את זה

    HTTPS מצפין את בקשת ה-HTTP, כולל הנתיב, בזמן ההעברה. הוא לא מונע משרת ה-DNS שנבחר לראות את השם שהוא צריך לפתור.

    DNS מוצפן, כמו DNS over HTTPS, מגן על החיבור לאותו שרת. הוא לא מסתיר מהשרת עצמו את השם שנשאל.

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

    הנחיות לסורקים פועלות בשכבה אחרת. לפי Claroc, ‏Muse השתמשה ב-robots.txt כדי להרתיע סריקה, אבל שיטת הגילוי שלה לא נזקקה למנוע חיפוש.

    התיעוד של Google על noindex מסביר איך להוציא עמודים מתוצאות של מנועי חיפוש שתומכים בהנחיה. לא noindex ולא robots.txt מאמתים מבקר או מוחקים רשומות passive DNS. חסימת סורק יכולה גם למנוע ממנו לראות את הוראת ה-noindex בעמוד.

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

    כתובת בטוחה יותר חושפת פחות מידע

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

    בשירות שיתוף רגיל, מבנה שחושף פחות מידע יהיה:

    טקסט
    https://share.example/s/OPAQUE_TOKEN

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

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

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

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

    כותרות HTTP עוזרות, אבל הן לא המנעול

    בתשובות שמגישות שיתופים רגישים, אפשר להוסיף בין היתר:

    http
    Referrer-Policy: no-referrer
Cache-Control: no-store
X-Robots-Tag: noindex

    Referrer-Policy קובע מה הדפדפן שולח בכותרת Referer. ברירות מחדל מודרניות בדרך כלל מצמצמות מידע שנשלח בין origins ל-origin בלבד. אבל ה-origin כבר כולל את שם השרת. לכן כותרת שהוטמעה בו עלולה לדלוף גם בלי שהנתיב המלא נשלח.

    no-referrer מצמצם את הערוץ הזה, אבל לא משנה את DNS. ‏no-store מנחה מטמונים שמכבדים אותו לא לשמור את התשובה, אבל לא מחזיר צילומי מסך או עותקים שכבר נלקחו. noindex נשאר בקשה לסורקים שתומכים בו, ולא בקרת גישה.

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

    בדקו את קהל היעד, לא רק את הכפתור

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

    אחר כך בדקו בלי התחברות, מחשבון שלא אמור לקבל גישה, ואחרי פקיעת התוקף או ביטול השיתוף. בדקו גם קבצים מצורפים ו-endpoints של API. ודאו שהשרת חוסם גישה ולא רק מסתיר את התוכן בממשק.

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

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

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

    מקורות

    צילום ראשי: PO boxes at the historic Chico Post Office (2024)-L1005460, צילום של Frank Schulenburg מ-13 במאי 2024. רישיון CC BY-SA 4.0. הוקטן מ-8312 x 5937 ל-1920 x 1371 פיקסלים ונדחס כ-JPEG; התמונה המעובדת מופצת באותו רישיון. צילום להמחשה של תיבות דואר פיזיות, לא תשתית של Meta או ראיה מהמחקר. אין בו הבעת תמיכה.

    שיתוף: