איך עוקפים אימות דו-שלבי - 2FA Bypass מוסבר¶
כולנו אמורים לדעת עד עכשיו ש-2FA זה טוב. סיסמה לבד לא מספיקה, וקוד נוסף מהטלפון או מהמייל מוסיף שכבת הגנה אמיתית. הבעיה היא שבשטח, המימוש של 2FA הוא לפעמים חלש בצורה מביכה, ותוקף שמבין איך זה נשבר יכול לעקוף את כל השכבה הזאת בלי לגעת בקוד עצמו. אני רוצה לפרק כאן את החולשות הנפוצות ביותר, כדי שתדעו לזהות אותן כבודקים, ולסגור אותן כמפתחים.
אז איך 2FA בכלל נשבר?¶
חשוב להבין נקודה אחת מראש - כמעט אף פעם לא מדובר בפריצה של האלגוריתם שמייצר את הקוד. מדובר בפגמים ביישום שסביב הקוד - איך השרת בודק אותו, מתי הוא נבדק, ומה קורה בתרחישים חריגים. זה בדיוק מה שהופך את זה למעניין מבחינת מחקר, כי הקוד עצמו יכול להיות חזק לגמרי בזמן שכל המנגנון סביבו רעוע.
מניפולציה על תשובת השרת¶
הדרך הכי בסיסית, ולפעמים הכי מטרידה, היא כשהקליינט הוא זה שקובע אם האימות הצליח. אפליקציה שמחזירה {"success": false} ומצפה מהדפדפן לא להמשיך הלאה, בעצם סומכת על הקליינט לשמור על החוק. עם פרוקסי כמו Burp Suite, שינוי התשובה מ-false ל-true, או שינוי קוד סטטוס מ-401 ל-200, יכול לגרום לאפליקציה להמשיך כאילו הקוד אומת בהצלחה. זו לא חולשה בקוד ה-OTP, זו חולשה בזה שהחלטה קריטית התקבלה בצד הלא נכון של החיבור.
חוסר הגבלת קצב על אימות הקוד¶
קוד OTP סטנדרטי הוא בדרך כלל שש ספרות, כלומר מיליון אפשרויות. זה נשמע הרבה, אבל בלי הגבלת קצב אמיתית על נקודת הקצה שבודקת את הקוד, מיליון ניסיונות זה בכלל לא מכשול לכלי אוטומטי. אם השרת מאפשר לנסות שוב ושוב בלי נעילה, בלי עיכוב הולך וגדל, ובלי הגבלה על כמות הבקשות מאותה כתובת, אפשר תיאורטית לעבור על כל טווח הקודים עד שאחד מהם מתאים. הגבלת קצב על נקודת הקצה הזאת היא לא פרט טכני שוליים - היא חלק אינטגרלי מהאבטחה של כל המנגנון.
מסלולי שחזור שמדלגים על הכל¶
זו אחת הנקודות שהכי קל לפספס בבדיקת אבטחה, כי כולם בודקים את מסך ההתחברות הראשי ושוכחים את השאר. מסלול "שכחתי סיסמה", מסלול איפוס דרך מייל, אינטגרציה עם ספק זהות חיצוני, או ממשק תמיכה פנימי - כל אחד מהם עלול להיות דרך צדדית שמאפסת סיסמה או מתחברת למשתמש בלי לדרוש בכלל את השלב השני. אם דלת הכניסה הראשית נעולה היטב אבל יש דלת אחורית שאף אחד לא בדק, כל האבטחה של הדלת הראשית לא שווה הרבה.
סשן שלא באמת בודק שוב¶
יש מקרים שבהם המשתמש כן עובר אימות דו-שלבי בהצלחה, אבל השרת לא באמת מייצר סשן שתלוי בזה. לפעמים אפשר לגשת ישירות ל-endpoint שמייצר את הטוקן או העוגייה אחרי שלב הסיסמה, בלי לחכות בכלל לשלב השני, כי השרת לא בודק אם המשתמש באמת סיים את כל התהליך. זה כמו לשים שומר בכניסה, אבל להשאיר חלון פתוח בצד.
פישינג בזמן אמת - Adversary-in-the-Middle¶
זו כבר לא חולשה ביישום, אלא התקפה שמבטלת את הערך של 2FA כמעט לגמרי - תוקף מפעיל אתר פישינג שמעביר בזמן אמת כל מה שהמשתמש מקליד, כולל קוד ה-OTP, ישירות אל האתר האמיתי. המשתמש חושב שהוא התחבר כרגיל, אבל בפועל התוקף חטף את הסשן שנוצר, כולל העוגייה שמעידה על אימות מוצלח. כלים שמבצעים את זה בזמן אמת הפכו את הפישינג המתקדם לאחת הדרכים היעילות ביותר לעקוף גם 2FA מבוססת אפליקציה.
אז 2FA לא שווה כלום?¶
בדיוק ההפך. כל החולשות שתיארתי כאן הן פגמי יישום, לא פגם במושג עצמו. 2FA שמומש נכון - עם הגבלת קצב אמיתית, בדיקה בצד השרת, מסלולי שחזור מוגנים באותה רמה, וסשן שבאמת תלוי בשלב השני - עדיין חוסם את רוב התוקפים בעולם. הבעיה היא שרוב הצוותים משקיעים בהוספת השלב השני, ושוכחים לבדוק שהוא באמת אטום מכל צד.
זה בדיוק סוג המחשבה שאנחנו מפתחים בקורס פריצת אתרים מתקדם - לא רק להכיר את שם החולשה, אלא לדעת בדיוק איפה לחפש אותה ולמה היא קורית.
ואם אתם באמצע לימוד ונתקעים עם משהו - יש לנו קהילה שלמה שעוברת בדיוק את החומר הזה.
לסיכום¶
עקיפת 2FA כמעט אף פעם לא קשורה לשבירת ההצפנה או האלגוריתם מאחורי הקוד. היא קשורה לפרטים הקטנים סביב - איפה מתקבלת ההחלטה, כמה ניסיונות מותרים, ומה קורה בדרכים הצדדיות שאף אחד לא חשב עליהן. מי שלומד לחפש שם, מוצא הרבה יותר ממי שמנסה לתקוף את הקוד עצמו.