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

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

https://eliteinformatiker.de/2011/08/10/howto-hack-facebook-like-button-with-clickjacking

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

בסיפור אחר נטפליקס נתקלו בבאג שיצר פתח להנדסה חברתית מעניינת. מסתבר שגוגל לא לוקחים יותר מדי ללב את הנקודות בכתובת המייל שלכם לכן הודעות דואר לכתובת ynon@gmail.com ולכתובת yn.o.n@gmail.com יגיעו לאותה התיבה. נטפליקס דווקא כן מתיחסים לנקודות כחלק מהמייל ולכן שני המיילים שהצגתי יוכלו להירשם כשני חשבונות נטפליקס שונים.

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

https://www.theregister.co.uk/2018/04/10/gmailnetflixphishing_vector/

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

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

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

פרטים נוספים על הסיפור הזה בקישור:

https://medium.com/intigriti/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

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

ולסיום הסיפור שלדעתי מוביל בסדרי גודל מבחינת המוזרות שלו הוא היכולת של מתכנתים להשפיע על כפתור ה Back בדפדפן. רעיון טכנולוגי נחמד שנועד לאפשר למי שבונה Single Page Web Application לייצר חווית משתמש דומה ליישומים רגילים. דן פטרוביץ החליט לנסות להשתמש לרעה במנגנון ויצר אתר שכפתור "אחורה" שלו מוביל לדף פנימי בתוך האתר שנראה בדיוק כמו דף תוצאות חיפוש של גוגל. בצורה כזו משתמש חושב שהוא יצא מהאתר וחזר לגוגל אבל למעשה עדיין נמצא באתר שלו.

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

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

https://www.smartspate.com/a-way-to-monitor-visitors-to-competitors-sites/

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