תוכן העניינים
כיצד חוסר התאמה בין חשבון היעד לזהות המקבל אפשר לזייף הוכחת תשלום אמינה
במהלך מבדק חדירה לשירות Wallet גילינו שניתן לגרום לאפליקציה של הקורבן להציג תשלום נכנס שהושלם בהצלחה, בזמן שהכסף הועבר בפועל לחשבון אחר שבשליטת התוקף.
התקיפה לא דרשה גניבת חשבון או עקיפת מנגנון התשלום. בקשת ההעברה כללה שתי שדות שתיארו לכאורה את אותו מקבל, אך השרת לא וידא שהם אכן שייכים לאותו אדם. את אחת מהן לקח עבור שליחת הכספים, והשנייה – עבור רשומת ההעברה. כך נוצר פער מסוכן: תנועת הכסף הייתה תקינה, אך הרשומה שהוצגה לקורבן הייתה מזויפת.
שני שדות – שני מקבלים שונים
כיצד בקשת העברה אחת הפרידה בין הכסף לבין הרשומה המוצגת
בקשת ההעברה כללה חשבון יעד שקבע לאן הכסף יועבר בפועל, ולצדו מזהה מקבל, ששימש להצגת זהות האדם שקיבל את התשלום. השרת בדק שכל אחד מהשדות תקין, אך לא וידא שחשבון היעד שייך למשתמש שצוין כמקבל. כתוצאה מכך, ניתן היה להפנות את הכסף לחשבון של התוקף ובמקביל לרשום את הקורבן כמקבל. היסטוריית ההעברות וההתראה באפליקציה נבנו מתוך מזהה המקבל שנשלח בבקשה ולא מתוך החשבון שזוכה בפועל.
שרשור פגיעויות הוביל להוכחת תשלום מזויפת ב-Wallet – איך זה קרה בפועל
כיצד העברה קטנה יצרה אצל הקורבן מסך "התקבל" אמין לחלוטין
במהלך הבדיקה השתמשנו בשני חשבונות Wallet שבשליטתנו ובמספר הטלפון של הקורבן. נתיב נוסף במערכת אפשר לקבל את המזהה הפנימי של המשתמש לפי מספר הטלפון שלו.
שלחנו העברה בסכום קטן, כאשר חשבון היעד היה חשבון שבשליטתנו, אך מזהה המקבל היה של הקורבן. השרת קיבל את הנתונים הסותרים וביצע את ההעברה. הכסף נכנס לחשבון שלנו, בעוד האפליקציה של הקורבן הציגה תשלום נכנס שהושלם בהצלחה, בצבע ירוק ובכיתוב "התקבל" ללא הבדל נראה לעין מתשלום אמיתי. היתרה בחשבון הקורבן לא השתנתה, אך משתמש שמסתמך על ההתראה או על היסטוריית ההעברות עלול למסור סחורה, לאשר עסקה או למחוק חוב כנגד כסף שמעולם לא התקבל.
כשהרשומה אמינה יותר מהיתרה
מדוע החולשה מסוכנת גם בלי גניבת כסף ישירה
מבחינת מנגנון התשלום, לא נגנב כסף מחשבון של צד שלישי: התוקף העביר את כספו לחשבון שבשליטתו. הנזק נוצר מכך שהמערכת הציגה לקורבן רשומה כוזבת שנראתה רשמית ואמינה.
חולשות כאלה עלולות לחמוק מבדיקות המתמקדות רק בשאלה אם כסף נגנב. כדי לזהות אותן צריך לבדוק האם כל הנתונים המתארים את העסקה נגזרים מאותו מקור אמת בצד השרת.
תובנות ממומחי הסייבר של IPV Security
כדי למנוע חולשות מסוג זה כבר בשלב התכנון, מומחי הסייבר של IPV Security ממליצים:
- לגזור את זהות המקבל מתוך הבעלים של חשבון היעד בצד השרת, ולהתעלם ממזהה מקבל שנשלח מהלקוח.
- לדחות כל בקשה שבה מזהי המקבל וחשבון היעד אינם שייכים לאותה ישות.
- לבנות את היסטוריית ההעברות וההתראות מתוך החשבון שחויב או זוכה בפועל.
- להתייחס לכל מזהה משתמש או משאב שנשלח מהלקוח כנתון בלתי מהימן ולבצע אימות קשרים בצד שרת.
- להשתמש במקור אמת יחיד עבור תנועת הכסף ועבור הרשומה המוצגת למשתמשים.
לסיכום
הממצא ממחיש שגם כאשר תנועת הכסף עצמה מבוצעת כראוי, חוסר התאמה בין השדות המתארים את העסקה יכול להפוך את האפליקציה לכלי ליצירת הוכחות תשלום מזויפות.
האם המסכים שהלקוחות שלכם סומכים עליהם נגזרים מהפעולה שבוצעה בפועל, או מנתונים שהמשתמש שלח בבקשה? מבדק חדירה לאפליקציות של IPV Security חושף את הפערים הללו לפני שתוקף מנצל אותם.
להתייעצות מקצועית עם מומחי הסייבר של t.077-4447130 IPV Securityשנים של ניסיון בהגנת סייבר, מבדקים וסקרי סיכונים וציות לרגולציות.
שאלות נפוצות
מה היה הכשל המרכזי במנגנון האבטחה?
השרת בדק שכל אחד מהנתונים בבקשה תקין בפני עצמו, אך לא בדק שהם מתייחסים לאותה ישות. כלומר, הוא וידא שהחשבון קיים ושהמזהה שייך למשתמש קיים, אך לא אימת שהחשבון אכן נמצא בבעלות אותו משתמש. זהו כשל בבדיקת הקשר בין נתונים ולא רק באימות הנתונים עצמם.
מדוע חולשה כזו עלולה להיות מסוכנת גם ללא גניבת כסף?
משום שהרשומה הכוזבת יכולה לשמש כ"הוכחת תשלום" מול משתמש אחר. אדם שרואה באפליקציה תשלום שהתקבל עשוי למסור מוצר, לאשר עסקה או לסגור חוב, למרות שבפועל לא קיבל את הכסף. הנזק נוצר מהפער בין מה שהמערכת מציגה לבין מה שהתרחש בפועל.
מהו מקור האמת שצריך לשמש להצגת תשלום?
המערכת צריכה לגזור את זהות המקבל מתוך חשבון היעד שאושר וזוכה בפועל בצד השרת. גם היסטוריית ההעברות, ההתראות ואישור התשלום צריכים להיבנות מאותו מקור, ולא להסתמך על מזהי משתמש שהתקבלו מהלקוח.
איך מבדק חדירה יכול לזהות חולשה כזו?
מעבר לבדיקת הרשאות ואימות קלטים, יש לבחון את הקשרים בין הנתונים השונים שמרכיבים עסקה. במקרה כזה, תרחיש בדיקה שבו משנים בנפרד את חשבון היעד ואת מזהה המקבל יכול לחשוף האם המערכת מוודאת שהם שייכים לאותה ישות, והאם המידע שמוצג למשתמש משקף את הפעולה שבוצעה בפועל.