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

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

ראה גם:

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

למרבה המזל, הפנייה סמויה היא לא ה-Heartbleed הבא. למעשה, ממה שאנו יכולים לברר, ה"פגם" בהפניה סמויה אינו חדש אפילו. יתרה מכך, סיווג ה-Covert Redirect כנקודת תורפה עם OAuth 2.0 ו-OpenID אינו נכון.

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

OAuth ו-OpenID 101

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

פרוטוקולים אלה הם מה שחברות משתמשות בהן כדי להקל על כניסה למספר שירותים מבלי ליצור מספר חשבונות חדשים. כשאתה נרשם ל-Flipboard באמצעות חשבון הטוויטר שלך או נכנס ל-Pinterest באמצעות חשבון הפייסבוק שלך, OAuth היא הטכנולוגיה מאחורי הקלעים שגורמת להכל לעבוד. OAuth 2.0 היא הגרסה הבאה של פרוטוקול OAuth, והיא עדיין בפיתוח.

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

זה שונה מאוד מ-OpenSSL -- שהיא קבוצה של ספריות שמפתחים יכולים להכניס לתוכנה שלהם. זה לא אומר שספריות OAuth 2.0 אינן קיימות -- הן קיימות -- אבל רוב ספקי השירותים הגדולים מבצעים שינויים ויישומים משלהם.

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

מצפה מחדש בעיה ידועה

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

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

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

אבל זו לא הבנה חדשה. נראה שהתגלית של ג'ינג דומה מאוד (או זהה) לשיטהאגור הומקובנדון במרץ 2013.

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

זה אפשרי, ככל הנראה, בגלל האופן שבו פייסבוק משתלבת עם OAuth 2.0 עם ממשקי ה-API של Graph.

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

במקרה של התקפת redirect_uri של Homakov,בילבי ציינהשהפוטנציאל לסוגים אלה של הפניות דיוג היה אפשרות המתוארת במפרט OAuth 2.0 עצמו.

למעשה, ישהקטע כולושל מפרט מודל האיומים של OAuth 2.0 שמתאר בדיוק את מה שהומקוב (וג'ינג) פירטו.

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

הפתרון הוא לדרוש מכל הלקוחות (אפליקציות) להשתמש ב-aרשימת היתרים של URIs להפניה מחדש, על מנת למנוע התקפה מ-URI דינמי.

אז למה פייסבוק לא עושה את זה עכשיו?לבילבי יש תיאוריה:

אני חושד שחלק מהסיבה שזה קרה לפייסבוק היא משום שכשהם השיקו את ממשקי ה-API של Graph בשנת 2010 הם אבטחו אותם עם טיוטה 5 של מפרט OAuth 2.0. מכיוון שהמפרט השתנה על פני 27 הטיוטות שלו כבר היו לקוחות עם קוד קשיח עם פרמטרים ספציפיים שלא ניתן היה לעדכן בקלות ולכן הם נאלצו לבחור לאפשר לפרמטרים הנ"ל ששימשו במתקפה לקבל דינמיות ולא קנון. ערכים.

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

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

זה מתיישב עם מהתגובת פייסבוק לג'ינג. ג'ינג אומר שפייסבוק אמרה לו ש"[הם] מבינים את הסיכונים הכרוכים ב-OAuth 2.0. עם זאת, חוץ מלכריח כל אפליקציה בודדת בפלטפורמה להשתמש ברשימת היתרים, [תיקון הפגיעות] זה לא משהו שניתן להשיג בקצרה מוּנָח"

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

מה הסכנה האמיתית?

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

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

זה שם סוג זה של איום ברמה שונה בהרבה ממשהו כמו Heartbleed. זה אפילו לא גרוע כמו ליקוי האבטחהמיקרוסופט רק תיקנהב-Internet Explorer.

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

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

בחודש שעבר דרשה לינקדאין את כל המפתחים שלה שמשתמשיםOAuth 2 לרישום כתובות אתרים להפניה מחדש.

אפקט דימום הלב

עבורי, ההיבט המרתק ביותר ב-Covert Redirect הוא הדרך שבה הוא מנסה לקוות את ה"הצלחה" של Heartbleed.

כעורך Mashable-at-Large וככתב ראשי, לאנס אולנוףצוין בחודש שעבר, Heartbleed באמת הוא כוכב העל הראשון של אבטחת האינטרנט.

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

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

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

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

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

בונוס: הסבר על האיום על דימום הלב