דליפות סודות: צעד אחד אל הסוףsaster

מסירת מפתחות הבית לפושעים היא בהחלט לא הרעיון הטוב ביותר. אבל זה מה שקורה לעתים קרובות ברוב הארגונים שמפתחים תוכנה מודרנית.

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

אלוהים אדירים! דחפתי את מפתחות הגישה לענן שלי למאגר ציבורי

סודות מקודדים בקפידה בקוד המקור או בקבצי תצורה בכלי DevOps עלול להגיע לידיים רעות. אם הסוד הוא commitאם אתה מאוחסן במאגר מקורות ציבורי, אתה בהחלט נידון לכישלון. אבל אפילו מאגרים פרטיים אינם בטוחים, מכיוון שסודות דולפים גם דרך קבצים בינאריים של יישומים, יומני רישום או קוד מקור גנוב.

במבט לאחור, זה מטריד באיזו תדירות טעות פשוטה הובילה לפריצת אבטחה חמורה. פשוט גוגל "דליפות מפתח של AWS","דליפות של אסימון גישה של GitHub", וכן הלאה. אל תקחו את הדוגמאות הללו כהמלצות נסתרות עבור ספק זה או אחר. השתמשו בעצמכם!

לדוגמה, הידוע לשמצה (ללא שם) מתקפת קודקוב של אפריל 2021 התאפשרה מכיוון שתמונת ה-Docker של Codecov הכילה אישורי git שאפשרו לתוקף לקבל גישה למאגרי git הפרטיים של Codecov ולהוסיף שורה אחת בסקריפט מעלה ה-bash של Codecov עבור משתני סביבת האוסף וכתובות URL של מאגר git.

הזכירו שחלק מהשפע במתקפות הוא הסודות לקבלת גישה למערכות נוספות, ותקיפות רבות משקיעות רבות באישורים, מפתחות קריפטו וחילוץ אסימונים. 

הבעיה היא סודות מקודדים קשיחים הם דבר שבשגרהבמרץ 2022, דירת Lapsus$ דלפו 189 ג'יגה-בייט של קוד המקור של סמסונג וקבצים רגישים אחרים. ניתוח גילה שהוא הכיל כמה 6,600 סודות מקודדים בקפידה90% עבור מערכות פנימיות, אך 10% עבור שירותים וכלים חיצוניים כמו GitHub, AWS או Google. סודות אלה כללו מפתחות API של AWS / Twilio / Google, מחרוזות חיבור למסד נתונים ומידע רגיש אחר. זהו המצב העדכני ביותר ברוב בסיסי הקוד.

דליפות סודות הן הדרך הקלה ביותר להתקפות בשרשרת האספקה

תלויות בחבילות הן כיום המטרה הנפוצה ביותר, אם כי לא המטרה היחידה, להתקפות בשרשרת האספקה. הרעים עלולים ליצור חבילה חדשה שבסופו של דבר מותקנת בתוכנה של הקורבנות (באמצעות קלקול הקלדה וטכניקות אחרות), אך בדרך כלל הם מנסים להדביק חבילה קיימת על ידי הוספת שינויים לקוד המקור במאגרי תוכנה (SCM) כמו GitHub, GitLab או BitBucket, או על ידי הוספת גרסאות זדוניות לרישומים ציבוריים כמו NPM, PyPI, RubyGems, Maven Central.

אבל הזרקת קוד זדוני או תלות זדונית המוסתרת בגרף תלויות מורכב דורשת login פרטי גישה כמו שם משתמש/סיסמה, טוקנים או מפתחות גישה (בואו נקרא להם "מפתחות"בקיצור), עבור מאגר המקור או הרישום הציבורי של היעד, בהתאמה. 

הרעים לפעמים משיגים את המפתחות דרך הנדסה חברתית. ה התקפה אל ה- event-stream חבילת NPM פופולרית מספקת דוגמה טובה. אבל חיפוש אחר דלפים login אישורים או מפתחות גישה הם טכניקת התקיפה הנפוצה ביותר עבור מתקפות בשרשרת האספקה ​​של תוכנה.

מאגרי מקור ורישום חבילות הן שתי מערכות חיוניות בבניית תוכנה. pipelineאבל ישנם כלים רבים ב-DevOps: CI/CD מערכות, כלים להרצת בדיקות, אוטומציה של תצורה והקצאה, או פריסה ושחרור. את כל אלה ניתן לנצל לרעה להחדרת קוד זדוני לתוכנה. דליפת מפתחות תקפים עבור כלים אלה מובילה ישירות לסבל וייסורים. דמיינו דליפת מפתחות גישת root עם שליטה מלאה על משאבי הענן הציבורי שלכם...

ההמלצות הרגילות

אנחנו לא אומרים כאן שום דבר חדש, כולכם יודעים את זה. אבל פעלו! זכרו שבוטים סורקים באופן קבוע את כל המידע הציבורי. SCM מאגרים. כמה המלצות, ללא סדר מסוים.

• אם יש לך אחריות על ניהול אבטחת IT, להגדיר כיצד יש לטפל בסודות במדיניות האבטחה. אבל מדיניות טובה רק כמו אכיפה: ודאו כי הנחיה לטיפול בסודות נאכפת בארגון שלכם - כולל לא רק צוותי ה-DevOps שלכם אלא גם ספקי התוכנה שלכם, וכי תוכנית התגובה לאירועים של הארגון שלכם מכילה הוראות לאירועי דליפת סודות.
• ליישם ולאכוף אימות רב גורמים (MFA, 2FA או כל ראשי תיבות אחר). ואין קיצוצים באבטחה: מפתח אבטחה USB שווה את כמה הדולרים שהוא עולה. אתם צריכים להכניס כל אחד מאלפי פרטי הגישה שלכם (קל) ואז להשתכר ולהשאיר את המפתחות בבר עם משהו שמקשר אליכם (הסיכויים קצת יותר קטנים, במיוחד אם אתם נטולי אלכוהול).
• השתמש במנהל סיסמאות עם סיסמה חזקה ולא שמורה. לטיפול בסודות במערכות השתמש כספות סודיות. CI/CD מערכות, ספקי ענן, SCMs וכלי DevOps אחרים מספקים שירות זה, אך ניתן לבחור בפתרון כספת סודית גנרי.
• מעדיף קצר מועד אסימונים למפתחות גישה ארוכי טווח. קל יותר לבטל אותם וחושפים חלון גישה מוגבל יותר לרשע.
• הגבל שימוש חוזר באישוריםתוקפים ישתמשו שוב באישורים שנאספו עבור מטרה במערכות אחרות, נקודה נוספת לשימוש במנהל סיסמאות. מנהלי סיסמאות וכספות סודיות צריכים להפוך את השימוש החוזר באישורים לדבר מן העבר.
• הגבלת השימוש ופיקוח עליו מנהל סיסמאות. הן חזקות מספיק כדי לדרוש מעקב מיוחד.
• יישום  גיבוב והצפנה חזקיםחזרה למפתחות USB (קריפטוגרפיים), נהלים מחמירים להעברת אישורים עם שותפים ועמיתים לעבודה וכן הלאה.
• להשתמש סורק סודות, לדוגמה לרוץ בתוך pre-commit וו כדי למנוע דליפות במערכות בקרת גרסאות, כשער אבטחה. לפני הדבר חשוב כאן. לחלופין, השתמשו בסריקות פוסט-הוק כדי לזהות סודות שדלפו, למשל כבדיקה לפני pull request מיזוגים. הערה: פלטפורמת Xygeni שלנו כוללת סורק סודות המאפשר את שני מצבי הפעולה. 
• האלטרנטיבה הידנית של שימוש ביקורות קוד לחפש סודות מקודדים באופן קשיח יש עלויות גבוהות יותר ועובד לאחר מכןcommit (אבל אני מקווה שלפחות לפני שהסוד יהיה זמין לאנשים מבחוץ). אבל סקירות עשויות לזהות סודות לא קונבנציונליים שעשויים לחמוק מסורקי סודות.       
• הימנע בטעות commitיצירת סודות לקבצים נפוצים לבקרת גרסאות עם המתאים אי הכללת דפוסים (כמו תבנית `gitignore`), תוך התחשבות בקבצים כמו .env, .npmrc, .pypirc, קבצים זמניים... אכן שכבה נוספת בבצל האבטחה.
• והאחרון ברשימה הארוכה הזו: שספקי הענן יבצעו סריקות לאיתור דליפות מפתחות, כאשר הן זמינות. לפחות, זה אולי ליידע אותך על הדליפה מתי היא מתרחשת, אבל אבטחה היא חובה עבור ספקי ענן. פוסט - הוק סריקה סודית אינה שקופה במיוחד לגבי היכן ותדירות ביצוע הסריקה, ולעתים קרובות דורשת הגדרה מפורשת, אך בהחלט היא המשאב האחרון כאשר כל השאר נכשל.

אלוהים אדירים! דחפתי את מפתחות הגישה לענן שלי למאגר ציבורי, קבלו את התשובה מספר 2.

זה יכול לקרות לטובים ביותר. תפשילו שרוולים!

חידוש/ביטול/השבתה מיידית של הסוד שדלף! אם לחשבון יש MFA תקין, הסיכון נמוך בהרבה. זה יכול להיות קשה יותר, למשל, עם מפתחות פרטיים באתרי אינטרנט (צריך להוציא אישור חדש עבור מפתח פרטי חדש ולבטל את הקיים), אבל לכלים מודרניים יש דרך מהירה לחדש אישורים או לבטל טוקנים. 

בצע את השלבים המומלצים על ידי הספק כאשר הם זמינים, כמו AWS בדוגמה זו.

זהה את סיבת הדליפה. ידיעת האופן שבו היא קרתה חיונית לגילוי, ניתוח, בלימה ופעילויות הפקת לקחים.

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

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

כתיבה מחדש של היסטוריית (בקרת גרסאות) הוא מורכב. אפילו מדינות טוטליטריות מנסות זאת ללא הועיל (משחק מילים מכוון). וכנראה לא רלוונטי: ההאקרים או הבוטים במאגרים ציבוריים אולי שיבטו את המאגר או שכבר חילצו את הזהב, במיוחד אם חלון החשיפה גדול מספיק. 

אם אתם הרפתקנים ורוצים לראות בעצמכם כמה זמן לוקח לבוטים לזהות סוד שדלף, תרמיות כמו... אסימוני קנרי מאפשרים לך להתנסות. זכור, בוטים שמים את ברירת המחדל ברשימה השחורה canarytokens.org תְחוּם…