פתיחת פירצת Initia: פרצת גישה לענן בגובה $3.27M

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

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

מה מגלה אירוע ה-3.27 מיליון דולר המדווח של Initia?

לפי דיווחים עדכניים, ההפסד המדווח של Initia החל בגישה לא מורשית דרך הזרקת פקודות שכללה מפתח Google Cloud Platform שנפרץ, ולאחר מכן התרחב לגישה למשתני סביבה, GitHub, חשבונות ענן, מזהים נוספים, Anvil, ומשיכות IBC מזויפות מחמישה rollups. האירוע ממחיש כי גישת ענן חייבת להיחשב כחלק מגדר אבטחה קריטי בפרוטוקול בלוקצ’יין.

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

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

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

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

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

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

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

כיצד דווח כי גישת הענן הגיעה לנכסי האחסון של Initia?

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

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

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

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

רכיב האירוע המדווח	פרט דיווח Initia	גבול אבטחה מעורב	בקרת הגנה להערכה
גישה ראשונית	הזרקת פקודות עם מפתח GCP שנפרץ	זהות ענן והרצת יישומים	תפקידי ענן מינימליים, סיבוב מפתחות, בידוד הרצת פקודות
הרחבת מזהים	חשיפת משתני סביבה	ניהול סודות בזמן ריצה	אחסון סודות, מזהים קצרים תקופה, בקרות גישה ברמת תהליך
גישה למאגרים ולתשתית	גישה ל-GitHub וחשבון ענן	ניהול CI/CD ותשתיות	סניפים מוגנים, זהויות פריסה נפרדות, גישה מואדמת מורשית
גישה לתשתית rollup	גישה ל-Anvil	ניהול rollup וסמכות אדמיניסטרטיבית	סביבות מופרדות, תהליכי אישור לפעולות מועדפות
מנגנון שחרור נכסים	אימות משיכות IBC מזויפות מחמישה rollups	אימות חוצה-שרשרת ושחרור אחסון	אימות עצמאי, מגבלות תדירות, ממתני מעגל למשיכות
כליאה	עצירת layer-1 של Initia ביום שלישי	סמכות תגובה מיידית	נוהלי עצירה נבחנים ותיעוד החלטות שיקום

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

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

למה הפרצה השנייה המדווחת ב-Initia משנה את הערכת הסיכון?

לפי דיווחים, אירוע ה-3.27 מיליון הדולרים של Initia הגיע לאחר ניצול ב-23 באוקטובר שהוביל לשאיבת כ-2.7 מיליון דולר דרך פגיעות ב-MoveVM script cache של Initia. שני אירועים המדווחים בתוך פחות משלושה שבועות מצביעים על משטחי תקיפה שונים: אחד במטמון הסקריפטים של MoveVM והשני במזהי ענן, הזרקת פקודות וגישה תפעולית.

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

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

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

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

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

אירוע Initia המדווח	תאריך/מועד המדווח	אובדן מדווח	משטח תקיפה	משמעות אבטחתית מיידית
ניצול MoveVM script cache	23 באוקטובר	כ-2.7 מיליון דולר	מטמון סקריפטים של Initia MoveVM	סקירת קוד הפרוטוקול, התנהגות מטמון, דרכי שדרוג, הטמעת כליאה
אירוע מזהי ענן והמשיכות IBC	גישה ביום שני והפסקת layer-1 ביום שלישי	כ-3.27 מיליון דולר	מפתח GCP שנפרץ, הזרקת פקודות, משתני סביבה, GitHub, ענן, Anvil, משיכות IBC	סקירת זהויות, טיפול בסודות, הרשאות ענן, תפעול rollup וסמכות משיכות

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

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

מה מומלץ למפעיל IBC ו-rollup לבדוק לאחר הדיווח?

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

המשיכות המדווחות כללו 13,400 TIA, 8,000 USDC.inj ו-597,000 Noble USDC. בדוח צוין גם שלא נמשכו אסימוני INIT. פרטים אלה חשובים כי תהליך השיקום אינו רק התחשבות אגרגטיבית; על הצוותים להשוות בין סוגי נכסים פרטניים, דרכי העברה, התחייבויות אחסון, יתרות קפואות והתחייבויות למשתמשים או צדדים.

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

1. זהות התשתית שיכולה לגשת לשירות הרלוונטי.
2. מאגר הקוד או תהליך הפריסה שיכול לשנות את התנהגות השירות.
3. הסוד או משתנה הסביבה שיכול להעצים את סמכות הזהות.
4. רכיב האימות שמחליט אם משיכת IBC היא חוקית.
5. מנגנון האחסון שמשחרר נכסים לאחר אימות.
6. מנגנון החירום שיכול להשהות משיכות או לעצור פעילות ברשת.
7. התהליך לשחזור ערבות נכסים לאחר פעולת הכליאה.

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

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

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

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

אילו בקרות תגובה לאירועים חשובות ביותר אחרי חדירת תשתית?

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

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

עבור אירוע התואם את הרצף המדווח של Initia, צוות התגובה צריך לתת עדיפות לסדר הפעולות הבא:

1. לבודד את נתיב הגישה החשוד. לבטל או לסובב את מפתח ה-GCP שנפרץ ולהסיר נתיבי גישה הקשורים להרצת פקודות.

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

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

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

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

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

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

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

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

הסתכלו על הרצף המדווח של Initia כהזדמנות לעקוב אחרי זהות ענן אחת מכניסה ראשונית ועד כל הרשאה אליה יכולה להגיע. השלב המידי הוא לערוך סקירת מסלול סמכויות עבור מפתחות ענן, משתני סביבה, אוטומציה ב-GitHub, ניהול rollup ואימות משיכות IBC, ואז להסיר כל מסלול בו מזהה בודד שנפרץ יכול להשפיע על שחרור נכסי אחסון.