אז מה זה ויישינג (vishing) בתחום אבטחת הסייבר, ולמה זה צריך להיות אכפת למפתחים? פישינג, קיצור של דיוג קולי, היא טכניקת הנדסה חברתית שבה תוקפים משתמשים בשיחות טלפון או בהודעות קוליות כדי להערים על מטרות ולגרום להן לחשוף אישורים, לאפס אסימונים או לעקוף בקרות אבטחה. בעוד שבעבר התקפות "ויישינג" כוונו כלפי עובדים כלליים, התוקפים עברו לכיוון מפתחים, מהנדסי DevOps ומנהלי מערכות, מכיוון שתפקידים אלה מחזיקים בגישה ישירה לקוד, pipelineותשתית ענן.
דוגמה: אתוקף מתקשר ומתחזה לצוות ה-IT הפנימי שלך, "אנו מסובבים את פרטי הגישה של GitHub עקב תקרית אבטחה; אצטרך לאמת את..." קוד MFA".
צעד אחד שגוי, וקוד המקור שלך או pipeline האישורים נחשפים. בסביבות מפתחים, מתקפת וישינג מוצלחת יכולה:
- הוביל ל CI/CD איפוס אסימונים ופריסות לא מורשות
- חשיפת מפתחות API או אישורי SSH המאוחסנים באופן מקומי
- רישומי ענן ומכולות שנפגעו, בהם משתמשת מערכת הבנייה
זו הסיבה שהבנת מהו ויישינג אינה אופציונלית; זה חלק מאבטחת המשלוח שלך. pipeline.
התקפות וישינג בעולם האמיתי המשפיעות על מפתחים CI/CD סביבות
בואו נבחן כיצד התקפות וישינג אמיתיות השפיעו על סביבות טכניות.
התרחישים הלא מאובטחים המפורטים להלן מיועדים למטרות חינוכיות בלבד; אין לשכפל אותם בייצור או בבדיקות פנימיות ללא אישור.
- פריצת טוויטר 2020: תוקפים התקשרו לעובדים, התחזו למערכות מידע פנימיות. הם שכנעו את הצוות לשתף קודי MFA, וקיבלו גישה למערכת האחורית שאפשרה השתלטות על חשבונות.
- תקרית גיטהאב (2022): מפתחים ספגו פניות שטענו שהן מתמיכת האבטחה, והובילו אותם "לאפס" אישורים, וכתוצאה מכך לא ניתן היה לגשת למאגר באופן מורשה.
- תרחישי ניהול AWS: תוקפים השתמשו בהנדסה חברתית מבוססת טלפון כדי להפעיל איפוס סיסמאות ולקבל גישה לחשבונות מפתחים המקושרים לתפקידי IAM בייצור.
עבור מפתחים, אלה אינם סיכונים מופשטים. במבחן פנימי מדומה של צוות אדום, מהנדס "אישר" זיוף pipeline בעיה בטלפון, מה שהוביל לביטול CI/CD אסימון מונפק מחדש לדוא"ל הנשלט על ידי תוקף. זוהי המהות של מתקפת וישינג: שימוש בדחיפות, אמון והקשר טכני כדי לתמרן מומחים שחושבים שהם טכניים מדי מכדי שיוכלו להטעות אותם.
שרשרת ההתקפה: מקריאה לגישה מלאה למאגר
כך מתפתחת התקפת וישינג שלב אחר שלב, במיוחד ב... DevOps או סביבת פיתוח.
- קשר ראשוני: tהתוקף מתקשר, מתחזה לתמיכת IT, ספק או אפילו ספק ענן.
סקריפט לדוגמה:
"שלום, זיהינו משהו חשוד" login פעילות בחשבון GitHub שלך. האם אוכל לאמת את קוד ה-MFA שלך כדי שנוכל לאבטח אותו באופן מיידי?"
- קציר תעודות: התוקף מרמה את הקורבן לחשוף אישורים, קודי OTP או להעניק הרשאות לאפליקציית OAuth.
- הסלמת פריבילגיות: ברגע שהוא בפנים, התוקף מאפס את פרטי ההרשאה או מאחזר CI/CD סודות.
- Pipeline פשרה: הם דוחפים בנייה זדונית, מתערבים בסקריפט פריסה או מחלצים קוד מקור.
⚠️ דוגמה לא מאובטחת, למטרות חינוכיות בלבד. אין להשתמש בסביבת ייצור.
גרסה מאובטחת:
⚠️ אַזהָרָה: הימנעו מהדפסה או רישום של משתנים רגישים (טוקנים, אישורים או סודות) ביומני בנייה. יומנים נגישים לעתים קרובות למשתמשים ומערכות מרובים, מה שעלול להוביל לחשיפה לא מכוונת של אישורים.
מדוע מודעות ביטחונית מסורתית אינה מספיקה
מפתחים מניחים לעתים קרובות ש"הכשרת מודעות" תגן עליהם. אבל לדעת מהו ויישינג (vishing) זה לא מספיק כאשר חסרים שלבי אימות טכניים. תוקפים מנצלים חולשות פרוצדורליות, לא רק בורות:
- תהליכי תמיכה שמאפסים גישה על סמך בקשות טלפוניות
- חוסר אימות זהות תמיכה
- הסתמכות יתר על MFA ללא אימות הקשר
מיני רשימת בדיקה: מניעת ויישינג של מפתחים
- לעולם אל תשתפו קודי MFA או טוקנים בשיחות קוליות
- אימות זהות המתקשר באמצעות מדריך פנימי או אישור צ'אט
- הטמעת נהלי התקשרות חוזרת (התקשרות חוזרת דרך מספר פנימי מאומת)
- ביקורת על מרכז התמיכה ואיפוס זרימות עבודה לאימות זהות
- השתמש בערוצים מאובטחים (SSO, ספק זהויות) לאיפוס סיסמה או טוקנים
נוהל אימות איפוס מאובטח
- לעולם אל תשתפו MFA או טוקנים באמצעות שיחה קולית
- נתק והתקשר בחזרה באמצעות מספר שאומת באופן פנימי
- אשר את הבקשה דרך מוקד התמיכה הרשמי או פורטל ה-SSO
- המשך רק לאחר אימות זהות המבקש
בניית הגנות מפני Vishing בתהליכי עבודה של DevOps
כדי להתגונן מפני התקפות וישינג ב CI/CD וסביבות מפתחים, המודעות חייבת להיות בשילוב עם אכיפה טכנית. אמצעים מעשיים כוללים:
- אימות רב-גורמי (MFA) עם אישור מחוץ לטווח: לעולם אל תסתמך על MFA מבוסס טלפון עבור משימות ניהול.
- מדיניות גישה בדיוק בזמן (JIT): הגבלת חלונות גישה לפעולות בעלות הרשאות גבוהות.
- אימות אוטומטי: הפעלת התראות כאשר אישורים מאופסים או הרשאות משתנות באופן בלתי צפוי.
- ניטור התנהגותי: זיהוי דפוסי קול או גישה חריגים המקושרים לאינטראקציות תמיכה.
לדוגמה:
סוג זה של אוטומציה מאמת האם הפעולה שיזמה האדם היא לגיטימית לפני יישוםה.
אימות מתמשך ואכיפת מדיניות עבור פעולות ביוזמת אדם
אפילו המפתח המיומן ביותר יכול לעשות טעות תחת לחץ. אימות מתמשך מבטיח ששיחת וישינג בודדת לא תוכל לעקוף בקרות אבטחה אוטומטיות.
באמצעות בקרת גישה מבוססת תכונות (ABAC) או מדיניות מודעת הקשר, pipelines יכול לאמת באופן אוטומטי:
- מקור הבקשה (IP פנימי, מכשיר ידוע או סשן).
- זמן הפעולה (במהלך שעות העבודה או חריגה לאחר שעות העבודה).
- מאפייני זהות (התאמת תפקידי משתמש והתנהגות קודמת).
משמעות הדבר היא שבקשת איפוס סיסמה שתוגש לאחר שעות הפעילות ממספר חדש לא תאושר אוטומטית, גם אם המשתמש עבר מניפולציה. בקרות טכניות אלה הופכות את התקפות וישינג לקשות יותר לביצוע ומהירות יותר לגילוי.
מודעות + אוטומציה = הגנה אמיתית
מפתחים נמצאים כעת במרכזן של מתקפות מונעות זהות. הבנת מהו ויישינג באבטחת סייבר אינה רק נושא של מודעות; זוהי דאגה של DevSecOps הקשורה לקוד, pipelineותשתיות.
שלבו מודעות עם אוטומציה:
- אימות כל בקשת גישה
- החל אישור מחוץ לטווח עבור איפוס אישורים
- ניטור רציף אחר חריגות pipeline פעולות
פלטפורמות כמו קסיגני לסייע לצוותי פיתוח ואבטחה לזהות פעילות הקשורה לוויזינג, לאכוף אימות גישה הקשרית, ו להגן CI/CD pipelines מאיומים מבוססי הנדסה חברתית. מתקפת ויישינג אינה זקוקה לתוכנה זדונית; היא זקוקה רק לקול אחד מהימן. ודאו שהמערכות שלכם אינן סומכות עליהן באופן עיוור.
