סיכום
בורסת קריפטו המזוהה כ-NCX השאירה לכאורה מופע MongoDB פנימי חשוף באינטרנט הציבורי ללא אימות. ניתן היה לגשת למסד הנתונים במשך חודשים, והוא הכיל כ-1GB של נתונים ויותר מ-5 מיליון רשומות, כולל שמות, כתובות דוא"ל, תאריכי לידה, קישורים למסמכי KYC, סיסמאות מוצפנות, זרעי/כתובות URL של 2FA, מפתחות API פנימיים, היסטוריית IP, כתובות ארנקים של חשבונות ויומני עסקאות.סקירת אבטחה יומית) זה לא רק "דליפת מידע אישי". זהו פגיעה מקיפה בכל הרמות: גניבת זהות, הונאת KYC, השתלטות על חשבונות, מיקוד ברשת, חשיפה רגולטורית וחובות תגובה לאירועים במסגרת משטרי הגנת נתונים מודרניים המחייבים גילוי תוך 72 שעות.GDPR)

מאמר זה בוחן את הפרת אבטחת המידע בסגנון NCX משתי זוויות:

1. בדיקות התקפיות / המציאות של צוות אדום — כיצד תצורה שגויה זו הופכת לניצול פעיל.
2. תאימות ותגובה — מה עליכם לעשות ברגע שאתם מגלים שאיבדתם שליטה על נתוני הזהות של הלקוחות ועל סודות רב-גורמיים.

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

סקירת האירוע: מה דלף ומדוע זה חשוב

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

סוגי נתונים חשופים

על פי הגילוי, מאגר הנתונים NCX הכיל (לכל רשומה, מעל מיליוני שורות):

• שם מלא / דוא"ל / תאריך לידה
• קישורים לתמונות או מסמכים של KYC (דרכון, סריקות תעודת זהות)
• ערכי זרע 2FA וכתובות URL להרשמה
• סיסמאות מוצפנות
• היסטוריית כתובות IP ומטא-נתוני כניסה
• מפתחות API פנימיים / אסימוני שירות
• כתובות ארנק, היסטוריית הפקדות/משיכות, פעילות ברשת
• דגלי מצב חשבון (הרחקה / הקפאה / סיכון)
• יומני כרטיסי תמיכה

זה גרוע במיוחד משלוש סיבות:

1. השתלטות על זהות בקנה מידה גדול
   אם לתוקף יש את שמך הרשמי + תאריך לידה + תמונת דרכון, הוא יכול לפתוח חשבונות במקומות אחרים, לבצע "שחזור חשבון" באמצעות הנדסה חברתית, או לעבור את תהליך KYC במקומות פחות מאובטחים. זהו שימוש קלאסי בגניבת זהות.סקירת אבטחה יומית)
2. עקיפת MFA באמצעות חשיפת זרע 2FA
   אם זרעי סיסמאות חד-פעמיות מבוססות זמן (TOTP) מאוחסנים ודלפו, תוקף יכול ליצור קודי 2FA תקפים לפי דרישה ולהתחבר כמותך — גם אם מעולם לא שיתפת את הסיסמה שלך. זרעי 2FA שנחשפו הם למעשה "אסימוני הפעלה מוכנים מראש".סקירת אבטחה יומית)
3. אחסון + מיקוד על הבלוקצ'יין
   כתובות ארנק והיסטוריית העסקאות מאפשרות ליריב למפות אילו משתמשים באמת מעבירים סכומים גדולים. לאחר מכן, ניתן לבצע פישינג ("ההפקדה שלך נחסמה, אנא חתום כאן") או החלפת SIM למטרות ערך גבוהות אלה. ראינו פלטפורמות קריפטו מזהירות משתמשים שנפרצו לצפות לפישינג מותאם אישית המשתמש בדיוק באסטרטגיה זו.סקירת אבטחה יומית)

בעיית חוסר תגובה

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

שרשרת תקיפות: כיצד צוות אדום הופך "MongoDB פתוח" לפריצה מלאה לחשבון

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

שלב 1: ספירת MongoDB החשופים

• סריקת יציאות של שטחים נרחבים של כתובות ענן עבור יציאות MongoDB קלאסיות (27017/27018).
• השתמש בבאנר/סטטוס השרת כדי לאשר גישה לא מאומתת.
• רשימת מאגרי מידע ואוספים (db.getCollectionNames() וכו').
• זרוק אוספים בעלי ערך גבוה: משתמשים, auth, kyc, ארנק, עסקאות, apiKeys, כרטיסים.

במילים אחרות, זה לא "0-day". זו תצורה שגויה ברמה של שנות ה-90: מסד נתונים באינטרנט, ללא אימות, ללא חומת אש. CISA ו-NIST מזהירים שוב ושוב כי מאגרי נתונים החשופים לאינטרנט ללא אימות נותרים אחת מנקודות הכניסה הנפוצות ביותר לפריצות.הנציבות האירופית)

להלן דוגמה לפרוטוקול פשוט שתוקף עשוי להריץ מתוך תיבת בדיקה (אין להריץ פרוטוקול זה על מערכות שאינן בבעלותך או שאין לך הרשאה לבדוק; ביצוע גישה לא מורשית הוא בלתי חוקי):

# גלה מארחים פתוחים של MongoDB (דוגמה ללוגיקה בלבד) nmap -p 27017 --open  -oG mongo_hosts.txt # התחבר למארח שהתגלה ללא אישורים mongosh --host :27017 --eval "db.adminCommand('listDatabases')"

# ספירת אוספים בבסיס נתונים יעד mongosh --host :27017 --eval "use ncx_users; db.getCollectionNames()"

# לשפוך מסמכים הקשורים למשתמש mongosh --host :27017 --eval "use ncx_users; db.users.find().limit(5).pretty()"

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

שלב 2: אסוף סודות וחומר אימות

ברגע שנכנס פנימה, התוקף מושך:

• password_hash או שווה ערך
• totp_seed / 2fa_secret
• api_key / api_secret
• כתובות URL של קבצי KYC

זהו הזכייה הגדולה. ניתן לפצח חשיפות סיסמאות במצב לא מקוון; זרעי TOTP מאפשרים לך ליצור קודי MFA תקפים; מפתחות API עשויים לתקשר עם מנהל פנימי או עם מערכות מסחר אחוריות.

חוקרי אבטחה וצוותי DFIR ציינו שוב ושוב כי זרעי 2FA שהודלפו ופרטי הזדהות API "הניתנים לשימוש חוזר" הם שלל בעל ערך רב, מכיוון שהם מאפשרים השתלטות ישירה על חשבונות ותנועה רוחבית.סקירת אבטחה יומית)

שלב 3: השתלטות מדומה על חשבון

בעזרת שם משתמש/דוא"ל + סיסמה (או hash שפרץ במצב לא מקוון) + זרע TOTP גנוב, תוקף יכול ליצור קודים תקפים בני 6 ספרות באופן מקומי. משמעות הדבר היא כניסה מלאה ללא צורך לגעת בטלפון של הקורבן.

אם הבורסה תומכת באיפוס סיסמה באמצעות דוא"ל ו-2FA, ושניהם נפגעו, התוקף יכול לנעול את המשתמש לחלוטין. תרחיש זה — עקיפת MFA באמצעות TOTP גנוב או נתוני איפוס — הוא בדיוק הסיבה שמדריכי התגובה לפריצות קריפטוגרפיות מורים למשתמשים שנפגעו להחליף מיד את פרטי הזיהוי, להירשם מחדש ל-MFA ולפקח על משיכות.CCN.com)

שלב 4: KYC ושימוש לרעה בזהות

מכיוון שקישורי תמונות KYC וסריקות תעודות זהות היו, על פי הדיווחים, גלויים (או מאחורי כתובות URL שניתן לנחש או בעלות תוקף ארוך), תוקפים יכולים להשתמש בהם:

• לפתוח חשבונות בורסה חדשים במקום אחר בשם אדם אחר;
• לנצל את שירות הלקוחות של שירותים אחרים ("אני אשלח לך את הדרכון שלי עכשיו, אנא בטל את הנעילה");
• לדוג משתמשים בעלי ערך גבוה עם פרטים אישיים רגישים ("שלום, בהתאם לתקנות AML הקפאנו את משיכת הכספים שלך...").

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

שלב 5: מיקוד ברשת

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

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

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

רשימת בדיקה הגנתית ותיקון (טכנית)

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

בסיס אבטחת מסד נתונים

• הפסיקו את החשיפה הציבורית עכשיו: הסר את המופע מהניתוב הציבורי או נעל אותו מאחורי כללי חומת האש / גישה ל-VPC בלבד.
• נדרשת אימות: הפעל אימות MongoDB וגישה מבוססת תפקידים; לעולם אל תאפשר קריאה אנונימית מהאינטרנט.
• TLS בכל מקום: כפה העברה מוצפנת, לא טקסט רגיל.
• עקרון הפריווילגיה המינימלית: שירותי מיקרו הפונים למשתמשים צריכים לראות רק את האוספים שהם בהחלט זקוקים להם.
• רישום והתראות: לחבר יומני ביקורת רציפים על ניסיונות גישה ושאלות חריגות. הרגולטורים של NIST והאיחוד האירופי מצפים לקבל רישומים המראים מי ניגש למה, מתי, במהלך ואחרי הפרה.הנציבות האירופית)

ממשל סודי ומפתח

• סובב מפתחות API שנמצאו במזבלה, הנח שהם נפגעו.
• ביטול "כתובות URL פרטיות" ארוכות טווח לתמונות KYC; העבר נכסים אלה לכתובות URL חתומות קצרות מועד עם ACL קפדני (לדוגמה, כתובות URL S3 חתומות מראש עם תוקף של דקות ספורות, מגבלות IP וביקורת).
• הקשחת ממשקי API פנימיים של מנהל המערכת שהמפתחות שהודלפו עלולים לפגוע: לדוגמה, דרישה ל-TLS הדדי, רשימות אישור IP, תצורת מכשירים.

איפוס 2FA / MFA בקנה מידה גדול

• התייחס לכל זרעי TOTP החשופים כאל זרעים שנשרפו. כפה רישום מחדש עבור חשבונות מושפעים.
• נדרשת הגדרה חדשה של 2FA עם זרעים חדשים שאינם מאוחסנים בטקסט רגיל.
• עבור חשבונות בסיכון גבוה (למשל, יתרות גדולות), הוסף באופן זמני אימות משודרג למשיכות כספים ושינויי סיסמאות. צוותי אבטחה ואפילו רגולטורים מעודדים "חיכוך אדפטיבי" לאחר פריצה בפעולות בעלות ערך גבוה.CCN.com)

טיפול בנתוני KYC

• העבר מסמכי KYC לאחסון מוצפן עם בקרת גישה קפדנית ואסימוני אחזור קצרי טווח, ולא לקישורים ציבוריים קבועים.
• הוסף רישום גישה בשכבת האובייקטים (מי צפה בדרכון X בזמן Y).
• צמצם את שמירת הנתונים — תקנת ה-GDPR מחייבת צמצום נתונים והגבלת מטרה. אם אינך זקוק לסריקה ברזולוציה מלאה של דרכון לנצח, אל תשמור אותה לנצח.GDPR)

זיהוי פלילי + תגובה לאירועים

• צלם את מסד הנתונים החשוף כראיה.
• לכידת יומני גישה לפני/אחרי ההסרה לשחזור ציר הזמן.
• התחל את תהליך העבודה של דיווח על הפרה:
  • להודיע לרשות להגנת נתונים תוך 72 שעות מרגע שנודע לך על כך, אלא אם כן אתה יכול להוכיח שהסיכון נמוך;
  • להודיע למשתמשים המושפעים "ללא דיחוי" אם קיים סיכון גבוה עבורם (גניבת זהות, השתלטות על חשבון בהחלט נכללים בקטגוריה זו).GDPR)
• תעד את כל שרשרת האחריות. הן ה-GDPR והן מרבית חברות הביטוח הסייבר מצפות ממך לשמור את הראיות ואת צעדי התיקון.פרקינס קוי)

להלן לוח זמנים פשוט לתיקון, שצפוי להתבצע ב-48 השעות הראשונות לאחר הגילוי:

רגולטורים כמו ה-DPA של האיחוד האירופי וה-ICO של בריטניה מציינים במפורש כי דיווח על הפרות לרשויות חייב להתבצע בדרך כלל תוך 72 שעות מרגע הידיעה, וכי עליכם להיות מוכנים להודיע לאנשים שנפגעו אם קיים "סיכון גבוה" עבורם.GDPR)

מיפוי תאימות: GDPR, SOC 2 / SOC 3 וציפיות ספציפיות בתחום הקריפטוגרפיה

GDPR / הגנה על נתונים בסגנון האיחוד האירופי

על פי סעיפים 33 ו-34 לתקנות ה-GDPR, אם אתה סובל מהפרת נתונים אישיים המסכנת את זכויותיהם וחירותם של אנשים, עליך:

1. להודיע לרשות הפיקוח תוך 72 שעות מרגע שנודע הדבר, ו
2. הודיעו למשתמשים המושפעים "ללא דיחוי", ותארו מה נחשף ומה אתם עושים בעניין.GDPR)

במקרה של מטבעות קריפטוגרפיים, הדלפת מסמכי KYC + מסמכי זיהוי + מטא-נתוני כניסה + זרעי 2FA מהווה "סיכון גבוה" מובהק עבור אנשים פרטיים. הדבר מאפשר הונאת זהות, הפסדים כספיים והנדסה חברתית — הרגולטורים לא יקבלו שתיקה בנושא.

בקרות בסגנון SOC 2 / SOC 3

במונחי SOC 2 / SOC 3 (אבטחה, זמינות, סודיות), מסד נתונים פתוח ולא מאומת מהווה הפרה בוטה של בקרת הגישה, אבטחת הרשת וציפיות ניהול השינויים. לא ניתן לעבור ביקורת SOC בוגרת אם "מידע אישי קריטי של לקוחות וסודות נמצאים ב-IP ציבורי ללא אימות".

הודעה על הפרה ואמון בקריפטוגרפיה

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

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

כיצד לאתר תקלות מסוג "NCX" לפני שהאינטרנט עושה זאת (Penligent View)

בואו נהיה כנים: "MongoDB ציבורי ללא אימות החושף יותר מ-5 מיליון רשומות" הוא מסוג הדברים שצריך לתפוס במסגרת בדיקות תקיפה נאותות הרבה לפני שעיתונאים עושים זאת.סקירת אבטחה יומית)

Penligent (https://penligent.ai/) ניגשת לנושא זה כאל בדיקות יריבות רציפות ואוטומטיות — בעיקרון, צוות אדום הפועל באופן רציף. כך זה מתבטא:

מיפוי נכסים וניטור חשיפה

סוכני Penligent ממפים באופן רציף את משטח ההתקפה החיצוני (טווחי IP בענן, תת-דומיינים, שירותים שהודלפו) ומסמנים מאגרי נתונים הפונים לאינטרנט, כגון MongoDB, Redis, Elasticsearch, דלי אחסון אובייקטים וכו' שאינם מאומתים. זהו בדיוק סוג התצורה השגויה שהובילה לחשיפת NCX.סקירת אבטחה יומית)

סימולציית גילוי נתונים רגישים/מפתחות

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

• זרעי 2FA/TOTP
• מפתחות API ואסימוני שירות
• קישורים או סלים של מסמכי KYC
• מטא-נתונים של ארנק / משיכה

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

MFA ובדיקת נתיב הנסיגה

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

דיווח על תאימות

לבסוף, Penligent ממפה את הממצאים לחובות ה-GDPR בנוגע לפרצות תוך 72 שעות, כשלים בבקרת SOC 2 / SOC 3 וסיכוני שמירת הצפנה. זה חשוב כי לא רק צריך לתקן את הבאג — צריך להוכיח שהיה תהליך, שנקטתם בפעולה ושתוכלו לדווח על כך לרשויות הפיקוח.GDPR)

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

שאלות נפוצות (לנושאי אבטחה, GRC והנדסה)

שאלת מס' 1: מהי הטעות הנפוצה ביותר בהגדרת MongoDB המובילה לפריצות כמו NCX?

MongoDB הניתן לניתוב ציבורי ללא אימות וללא ACL ברשת. לעתים קרובות, מופעים של פיתוח/בדיקה מקודמים ל"ייצור זמני" ולעולם לא ננעלים. CISA/NIST מזהירים מזה שנים כי מאגרי נתונים חשופים ללא אימות הם גורם חוזר ונשנה לדליפות בקנה מידה גדול.הנציבות האירופית)

ש 2. אם זרע 2FA/TOTP דולף, האם תוקף יכול להתחבר בשמי?

כן, אם לתוקף יש גם את שם המשתמש/כתובת הדוא"ל שלך ואת הסיסמה שלך או את ה-hash הפרוץ. בעזרת ה-seed, הם יכולים ליצור אינסוף קודים תקפים בני 6 ספרות. לכן ההנחיות לאחר פריצה תמיד אומרות: אפסו את ה-MFA, לא רק את הסיסמה.סקירת אבטחה יומית)

ש3. כיצד יש לאחסן תמונות KYC וסריקות תעודות זהות?

הם צריכים להיות מוצפנים, עם בקרת גישה, וניתנים לאחזור רק באמצעות כתובות URL חתומות וקצרות מועד הקשורות למפגש מאושר — ולא קישורים סטטיים הנשארים לנצח. כל גישה צריכה להיות מתועדת. ה-GDPR מצפה גם ל"מינימום נתונים": אל תאגרו יותר נתונים אישיים ממה שאתם צריכים.GDPR)

ש 4. תוך כמה זמן עלינו להודיע על כך לרשויות הפיקוח ולמשתמשים על פי החוק?

במסגרת משטרי GDPR, עליך בדרך כלל להודיע לרשות הרלוונטית תוך 72 שעות מרגע שנודע לך על הפרה המסכנת אנשים, ועליך ליידע את המשתמשים המושפעים "ללא דיחוי" אם הסיכון להם גבוה.GDPR)

בשורה התחתונה

"MongoDB שהוגדר באופן שגוי" נשמע כמו טעות של טירון. בתחום הקריפטו, זו טעות קיומית.
כשאתה מדליף יותר מ-5 מיליון רשומות משתמשים עם תעודות KYC, סיסמאות מוצפנות, יומני IP, ארנקים ואפילו זרעי TOTP, אתה לא רק מדליף כתובות דוא"ל — אתה מדליף זהות, נזילות ואמון.סקירת אבטחה יומית)

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

זו הסיבה שבדיקות התקפיות רציפות, אוטומטיות ומבוססות ראיות (גילוי נכסים → סימולציית ניצול → מיפוי תאימות) הופכות במהירות לחובה עבור כל פלטפורמת קריפטו המאחסנת KYC ומחזיקה בכספי משתמשים. ואם אתה משתמש בבורסה שחוותה פריצה כזו? שנה סיסמאות, החלף 2FA, הנח שדיוג ממוקד עומד להגיע, ושקול ברצינות לעזוב.CCN.com)