דפוסי פריצה · 3 מתוך 5
פרטי גישה של ברירת מחדל: כשסיסמת ברירת מחדל היא כל מה שעומד בין תוקף לבין כל הרשומות
זה הפוסט השלישי בסדרה על דפוסי הפריצה הנפוצים ביותר. דפוסים 1 ו-2 נבעו משני מקרים של בדיקה שחסרה — בדיקת בעלות שבורה או הגבלת קצב שלא קיימת. דפוס 3 אפילו לא צריך באג: הדלת פשוט נשארה עם המנעול של המפעל, ואף אחד לא טרח להחליף אותו.
מה זה בעצם "פרטי גישה של ברירת מחדל"?
פאנלי ניהול, לוחות בקרה פנימיים, כלי גיוס עובדים, ו-API-ים של Backend כמעט תמיד מגיעים עם
חשבון כלשהו מוכן מראש, כדי שמי שמתקין את המערכת יוכל להיכנס אליה ביום הראשון:
admin / admin, admin / 123456, או בלי סיסמה בכלל. החשבון הזה אמור
להיות מוחלף בשלב ההתקנה. הבעיה היא כמה פעמים זה פשוט לא קורה — במיוחד כשכל האפליקציה, כולל
ה-Backend, נוצרה על ידי כלי AI תוך דקות, ואף אחד בצוות לא ראה בכלל שלב של "הגדירו סיסמת
מנהל" שאפשר לדלג עליו.
בשונה מדפוס 1 ודפוס 2, אין כאן באג לוגי להצביע עליו. בקרת הגישה עובדת בדיוק כמו שתוכננה. התכנון רק הניח שמישהו יחליף placeholder שבפועל נשאר בסביבת הפרודקשן, נגיש מהאינטרנט הפתוח. בגרסה הקיצונית ביותר של הדפוס הזה, אין בכלל צורך בסיסמה שניתנת לניחוש: לפאנל אין שער כניסה בכלל, וכל מי שמוצא את הכתובת כבר מנהל.
איך זה קורה בפועל
צוות מקים לוח בקרה פנימי — לצוות תמיכה, למשאבי אנוש, למי שצריך לבדוק משהו — באמצעות כלי AI לבניית אפליקציות או תבנית Backend מהירה. התבנית מגיעה עם חשבון seed לבדיקות מקומיות. זה עובד, הצוות עובר לפיצ'ר האמיתי, ולוח הבקרה עולה לכתובת ציבורית כי אף אחד לא שם אותו מאחורי VPN או רשימת IP מורשים. חשבון ה-seed נשאר בדיוק כמו שהתבנית סיפקה אותו.
החלק המטעה: מבפנים, הכול נראה תקין. יש מסך כניסה, הוא מבקש שם משתמש וסיסמה, והוא דוחה פרטים שגויים. זה נראה כמו בקרת גישה. פשוט אף פעם לא היה מאחוריה סוד אמיתי.
דוגמה מהעיתונות
קראו את הכתבה ב-CSO Online ←
וזה בדיוק הדפוס שחוזר ברוב המקרים הישראליים שסקרנו בפוסט הראשי — רק בגרסה הקיצונית עוד יותר שלו: לא סיסמת ברירת מחדל חלשה, אלא היעדר מוחלט של שער כניסה. מערכת הרווחה ש-160 רשויות מקומיות השתמשו בה, שירות ממשלתי לרישום נזקי מלחמה, ומערכות ניהול משמרות שחיילים בנו בעצמם — כולן היו זמינות לכל מי שידע לחפש בגוגל, בלי אפילו להזדקק לניחוש "admin / admin". כשאין שער בכלל, גם הגרסה הכי חלשה של סיסמה כבר מיותרת.
איך פותרים את זה
אין כפתור קסם אחד גם כאן, אבל הרשימה קצרה:
- בלי פרטי גישה משותפים של ברירת מחדל בפרודקשן, אף פעם. ייצרו סיסמה אקראית (או עוד יותר טוב, בלי חשבון שמבוסס-סיסמה בכלל) לכל התקנה, וכפו החלפה לפרטים אמיתיים לפני שכל דבר אחר עובד.
- MFA על כל דבר עם הרשאת מנהל. סיסמה שדלפה או נוחשה לבדה לא אמורה להספיק כדי להגיע לכל רשומה.
- שמרו על פאנלי ניהול ו-API-ים פנימיים מחוץ לאינטרנט הפתוח — מאחורי VPN או רשימת IP מורשים — כשכבה נוספת, לא כתחליף לפרטי גישה אמיתיים.
- סרקו לפני שמשחררים לפרודקשן. בדיקה אוטומטית קצרה לפרטי גישה ידועים של ברירת מחדל או seed ב-pipeline של הפריסה תופסת את זה לפני שהתוקף עושה זאת.
איך בודקים אם האפליקציה שלכם חשופה לדפוס הזה
הבדיקה הזו לוקחת חמש דקות ולא דורשת כלים מיוחדים:
- הכינו רשימה של כל פאנל ניהול, לוח בקרה פנימי, וקונסולת ניהול API שהאפליקציה שלכם — או הכלי שבנה אותה — יצרו.
-
לכל אחד מהם, נסו את פרטי הגישה המובנים מאליהם:
admin/admin,admin/123456,admin/password, או סיסמה ריקה. - בדקו אם הפאנל בכלל מבקש סיסמה — יש כאלה שלא, וזו אותה תופעה, רק צעד אחד קדימה.
- ודאו שכל אחד מהם נמצא מאחורי MFA, או שהוא בכלל לא נגיש מהאינטרנט הפתוח.
אם אחד מהם נתן לכם גישה, הפתרון הוא לא סיסמה חזקה יותר — הוא לוודא שברירת מחדל לא מגיעה לפרודקשן מלכתחילה.
איך secureFlows פותר את זה מלכתחילה
ב-secureFlows אין לאפליקציה שלכם פאנל ניהול נפרד שצריך לאבטח, כי ההתחברות עצמה מתארחת: אין חשבון מנהל מקומי, חשבון seed, או סיסמת מפעל ששוכנים אי שם בתשתית שלכם ומחכים שמישהו ישכח להחליף אותם. האימות עובר דרך OAuth ודרך ה-hosted login של secureFlows, באותו האופן בכל סביבה.
למנהלי ובעלי workspace עדיין יש דרך להסתכל על מידע הפעלה כשהם באמת צריכים — אבל הגישה הזו עוברת דרך API מאומת ומתועד, לא דרך טופס כניסה שנשכח בכתובת ציבורית. כל קריאה מתועדת, כך ש"מי ניגש למה" הוא דבר שאפשר לענות עליו, לא סוד שאף אחד לא יודע.
רוצים גישה מתועדת ומאומתת במקום עוד פאנל ניהול שצריך לשמור עדכני? לחצו על הכפתור למטה והתחילו לבנות עם secureFlows.
התחילו לבנות בחינם