מנועי חיפוש נבנו כדי לאנדקס תוכן. עם זאת, תוקפים משתמשים בהם כדי לאנדקס את הטעויות שלך. השאילתה allintext:login סוג קובץ: יומן עשוי להיראות לא מזיק. במציאות, זוהי אחת הדרכים הפשוטות ביותר לגלות קבצי יומן חשופים המכילים זרימות אימות, אישורים, טוקנים ונתוני תשתית פנימיים.
אם גוגל יכולה לראות את הלוגים האלה, גם התוקפים יכולים. לאחר האינדוקס, החשיפה הופכת בלתי נמנעת. יתר על כן, כאשר אישורים מופיעים בקובץ נגיש לציבור, הפריצה כבר בעיצומה.
1. למה allintext:login filetype:log מסוכן יותר ממה שזה נראה
שאילתת חיפוש מסוג גוגל דורק היא שאילתת חיפוש המשתמשת באופרטורים מתקדמים כדי לאתר תוכן רגיש או תוכן שגוי שמאונדקס על ידי מנועי חיפוש. היא אינה מנצלת את גוגל. במקום זאת, היא מנצלת את החשיפה שלך.
שאילתה זו משלבת שני אופרטורים:
- allintext: מחזירה דפים שבהם כל המונחים מופיעים בגוף הטקסט
- סוג קובץ: יומן מגביל את התוצאות ל
.logקבצים
לָכֵן:
פירושו: "הראה לי קבצי יומן המכילים את המילה login".
במבט ראשון, זה נראה טריוויאלי. אולם, בפועל, זה חוזר לעתים קרובות:
- יומני שרת אינטרנט חשופים לציבור
- CI/CD יומנים שהועלו כארטיפקטים
- ניפוי באגים בטעות commitמועבר למאגרים
- יומני יישומים עם אישורי טקסט רגיל
זה לא באג של מנוע החיפוש. במקום זאת, זהו פגיעות חשיפת נתונים נגרם עקב תצורה שגויה. גוגל פשוט אינדקסה את מה שהיה נגיש לציבור.
2. מה תוקפים מוצאים בפועל בקבצי יומן חשופים
כאשר התוקפים רצים allintext:login סוג קובץ: יומןהם לא גולשים באופן אקראי. הם מחפשים עקבות אימות.
2.1 אישורים בטקסט רגיל
יומנים מכילים לעתים קרובות ערכים כגון:
or
או אפילו אישורי SMTP:
רישום מטעני אימות הוא אחת הדרכים המהירות ביותר לדליפת אישורי ייצור. כתוצאה מכך, קובץ יומן חשוף יחיד יכול לפגוע בכל מודל בקרת הגישה שלך.
2.2 אסימוני סשן ו-JWTs
אפילו כאשר סיסמאות לא נרשמות, אסימונים לעיתים קרובות כן.
לדוגמה:
קובץ cookie של JWT או session תקף בתוך .log קובץ יכול לאפשר:
- חטיפת מושבים
- הסלמת פריבילגיות
- תנועה רוחבית על פני מערכות פנימיות
במילים אחרות, אסימונים ביומני רישום הופכים את פלט ניפוי השגיאות לווקטור עוקף אימות.
2.3 CI/CD חפץ
יומני בנייה מסוכנים במיוחד. למעשה, CI/CD מערכות לעיתים קרובות מדפיסות משתני סביבה במהלך שלבי הבנייה.
תוקפים מגלים לעתים קרובות:
מכיל שורות כגון:
If CI/CD חפצים הם ציבוריים, ואז סודות הם ציבוריים. האידיוט של גוגל פשוט מאיץ את הגילוי.
2.4 נתוני ענן ותשתיות
יומני רישום חשופים חושפים לעתים קרובות:
- מפתחות גישה ל-AWS
- מחרוזות חיבור של אחסון Azure
- כתובות URL פנימיות של שירות
- אישורי מסד נתונים
- נקודות קצה של Redis
גם אם אישורים עוברים סבב מאוחר יותר, התוקף מחזיק כעת ב:
- מיפוי תשתיות
- מוסכמות מתן שמות
- מודיעין מטרות להתקפות עתידיות
לכן, יומני רישום חשופים מספקים גם גישה וגם סיור.
3. כיצד יומני רישום אלה הופכים לציבוריים מלכתחילה
יומנים לא מופיעים באופן קסום בגוגל. הם נוספו לאינדקס מכיוון שהם היו נגישים לציבור.
3.1 שרתי אינטרנט בעלי תצורה שגויה
דפוסים נפוצים כוללים:
/logs/ספריות נגישות ללא אימות- רישום ספריות מופעל
- Nginx או Apache מגישים גולמיים
.logקבצים
אם ניתן להגיע ללוג דרך HTTP, ניתן לאינדקס אותו.
3.2 CI/CD חשיפת חפצים
טעויות אופייניות:
- ממצאים ציבוריים מופעלים ב פעולות GitHub
- יומני רישום שהועלו לדליים פתוחים של S3
- Pipeline עקבות נגישות ללא אימות
A pipeline שמאחסן יומני רישום בדלי ציבורי מפרסמת למעשה את הסודות שלה.
3.3 מצב ניפוי שגיאות בסביבת ייצור
ברירות מחדל של המסגרת עלולות להיות מסוכנות:
בנוסף, רישום בקשות מוגזם עלול להדפיס:
- כותרות
- מטבעות
- גופי הבקשה המלאים
רישום ניפוי באגים בסביבת הייצור הופך את האפליקציה שלך לייצואן אישורים.
3.4 יומני Docker ו-Container
סביבות ממוכנות מציגות נתיבי חשיפה חדשים:
- יומני רישום מותקנים באמצעי אחסון משותפים
- ייצוא יומני צד לנקודות קצה לא מאובטחות
- התחבר dashboardעם גישה ציבורית
אם יומני קונטיינרים נחשפים דרך HTTP או אחסון פתוח, ניתן לחפש אותם. בסופו של דבר, הם אנדוקסים.
4. זרימת התקפה ריאליסטית: מחנונית לפריצה
שרשרת תקיפה אופיינית נראית כך:
התוקף רץ:
- ממצאים שנחשפו
.logפילה - תמציות:
- אסימון JWT
- כותרת אימות בסיסית
- מחרוזת חיבור מסד נתונים
ניסיונות אימות כנגד:
- נקודות קצה של API
- פאנלים של ניהול
- שירותים פנימיים
אם האימות יצליח, התוקף יכול:
- הרחבת הרשאות
- הזז לרוחב
- גִישָׁה CI/CD
- לפגוע בשרשרת האספקה
מה שהתחיל כשאילתת חיפוש הופך ל:
- חטיפת מושבים
- מילוי אישורים פנימי
- Pipeline השתלטות
- הרעלת חפצים
הכל מקובץ יומן שמאונדקס באופן ציבורי.
5. מדוע רישום "יותר מדי" הוא בעיה ב-AppSec
רישום קרקע אינו ניטרלי. במקום זאת, הוא יוצר מאגר נתונים משני.
אם אתם רושמים נתונים רגישים, אתם למעשה יוצרים עותק שני של הסודות שלכם.
עם זאת, יומני רישום לעיתים קרובות אינם נכללים במידול איומים. תחת STRIDE, זה ממופה בבירור ל:
מידע על גילוי נאות
לכן, מאובטח SDLC שיטות עבודה צריכות להתייחס ליומנים כ:
- חפצים רלוונטיים לאבטחה
- נכסים רגישים
- רכיבי תשתית הדורשים הגנה
אם מודל האיומים שלך מתעלם מיומני רישום, הוא אינו שלם.
6. כיצד למנוע דליפת אישורים בקבצי יומן
6.1 הפסקת רישום סודות
לעולם אל תתחבר:
- סיסמאות
- מטבעות
- מפתחות API
- מזהי הפעלה
- כותרות הרשאה
אפילו במצב ניפוי שגיאות.
במידת האפשר, יש ליישם מחיקה אוטומטית.
6.2 רישום מובנה ובטוח
השתמש ברישום מובנה עם מיסוך וסינון.
דוגמה (Node.js):
דוגמה (פייתון):
העיקרון המרכזי הוא פשוט: אסור שסודות יגיעו לעולם לכיור העץ.
6.3 נעילת אחסון יומני רישום
בקרות אבטחה צריכות לכלול:
- השבתת רישום ספריות
- להגן
/logs/נתיבים עם אימות - הגבל גישה לדלי
- החלת מדיניות שמירה
- הצפנת יומני רישום במנוחה
אסור שיומנים יהיו נגישים לציבור דרך HTTP.
6.4 CI/CD Guardrails
ביקורות ידניות אינן מספיקות. במקום זאת, יש ליישם בקרות אוטומטיות:
- סריקה סודית של יומני רישום לפני פרסום חפצים
- בניית בנייה נכשלת אם מתגלים אסימונים
- מניעת העלאות של חפצים המכילים אישורים
- אימות גיבוב עבור ארטיפקטים
CI/CD צריך לחסום חשיפה לפני שמתרחשת אינדוקס.
7. כיצד Xygeni מונע allintext:login סוג קובץ: יומן אירועים
הבעיה אינה האידיוט של גוגל. הבעיה היא החשיפה. לכן, מניעה חייבת להתרחש לפני האינדוקס.
7.1 גילוי סודות ביומנים ובממצאים
סריקות Xygeni:
- יומני יישומים
- CI/CD עקבות עבודה
- בניית חפצים
- שכבות דוקר
- יציאות סידוריות
אם מופיעים אישורים, טוקנים או ערכים רגישים ב .log קבצים, Xygeni מסמן אותם באופן מיידי.
7.2 CI/CD Guardrails החשיפה הזו לחסום
במקום להסתמך על ביקורות ידניות, Xygeni אוכפת את האבטחה ב- pipeline ליום you
זה:
- נכשל בבניית קבצים כאשר סודות מופיעים ביומנים
- חוסם פרסום של חפצים
- מונע חשיפה מקרית של הציבור
- עוצר מיזוגים לא בטוחים לפני הגעה למצב הראשי
אם משימת CI מדפיסה אסימון, ה- pipeline נכשל.
אין אינדוקס.
אין חשיפה.
אין תקרית.
7.3 הגנה באמצעות Shift-Left לפני שגוגל רואה אותה
תזמון חשוב.
במקום להגיב ל:
Xygeni עוצר את הבעיה:
- At commit זמן
- במהלך pull request אימות
- במהלך pipeline הוצאת להורג
- לפני פרסום החפץ
אם היומן לעולם לא יהפוך לציבורי, גוגל לעולם לא אנדקס אותו.
מסקנה אחרונה: אם גוגל יכולה לאנדקס את זה, התוקפים כבר עשו זאת
יומני רישום אינם מזיקים. למעשה, הם לעיתים רחוקות זמניים. כברירת מחדל, הם אינם פרטיים. לכן, יש להתייחס לכל קובץ יומן כנכס רלוונטי לאבטחה, ולא רק כנכס לניפוי שגיאות.
אם נתונים רגישים מגיעים ל- .log קובץ והופך לנגיש לציבור, זה הופך מיד למשטח התקפה. יתר על כן, ברגע שמדובר באינדקס של מנוע חיפוש, החשיפה גדלה מעבר לשליטתך.
הפתרון אינו להפסיק את הרישום. אלא, הרישום הוא באחריות ולאכוף בקרות מחמירות סביב אחסון והפצה. במילים אחרות, האבטחה חייבת להשתרע מעבר לאפליקציה עצמה, אל תוך שכבת הנצפיות.
במקום:
- הפסקת רישום סודות
- נעילת אחסון יומני רישום
- אכיפה pipeline guardrails
- אוטומציה של זיהוי ואכיפת מדיניות
בסופו של דבר, מניעה היא עניין של תזמון. כי ברגע allintext:login סוג קובץ: יומן מחזיר את הדומיין שלך, התקרית כבר החלה.
