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

מקרה לקוח: חולשה באלגוריתם חתימה נפוץ אפשרה התחזות למשתמשים אחרים וחשיפת מידע אישי רגיש

כיצד שימוש באלגוריתם חתימה חלש ב־JWT עלול להוביל לגישה לא מורשית

במהלך מבדק חדירה לאפליקציה מבוססת JSON Web Token (JWT), זיהינו חולשה חמורה באלגוריתם החתימה של ה־JWT. החולשה אפשרה לתוקף לזייף אסימוני גישה, להתחזות למשתמשים אחרים, ולגשת למידע אישי רגיש של כלל המשתמשים במערכת.

הבנת הפגיעות: אלגוריתם חתימה חלש ב־JWT

כיצד תוקפים יכולים לנצל חתימה חלשה להשגת גישה בלתי מורשית

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

ניצול הפגיעות: התחזות למשתמשים ושאיבת מידע אישי

כיצד תוקף יכול לשנות אסימון JWT ולהיכנס לחשבון של כל משתמש

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

השפעת הפגיעות: גישה למידע אישי של כלל המשתמשים

כיצד חולשת החתימה הובילה לחשיפת מידע אישי רגיש של משתמשי המערכת

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

תובנות ממומחי סייבר בכירים של IPV Security

כדי למנוע פגיעויות דומות, אנו ממליצים לבצע את הפעולות האלה:

1. העדפת אלגוריתם חתימה א־סימטרי – מומלץ להשתמש ב־RS256 או ES256 במקום HS256,
   כדי למנוע שימוש במפתח סודי אחד לכל היישום.
2. חיזוק המפתח הסודי ב־HS256 – אם בכל זאת משתמשים ב־HS256, יש לוודא שהמפתח באורך של לפחות 256 ביטים ומיוצר באופן רנדומלי.
3. בדיקות אבטחה תקופתיות – יש לבצע בדיקות חדירה באופן קבוע כדי לוודא שמנגנון זיהוי המשתמשים מאובטח ושאי אפשר לזייף Tokenים.
4. מניעת חשיפת מידע עודף בתגובות השרת – על השרת להחזיר מידע הכרחי בלבד כדי למנוע זליגת נתונים.

לסיכום,

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

האם אתם יודעים אם המערכת שלכם משתמשת ב־JWT בצורה מאובטחת? בדיקות חדירה תקופתיות יסייעו לכם לזהות חולשות ולחזק את אבטחת המידע שלכם.

להתייעצות מקצועית ניתן לפנות אלינו לאימייל info@ipvsecurity.com או במספר הטלפון 077-4447130. IPV Security מתמחה זה 20 שנה באבטחת מידע, סייבר, סקרי סיכונים ותקנים ורגולציות הנוגעים לביטחון מידע ועוד.