פרצת Binance: השפעה מוערכת של $6.3 מיליארד ונכסים מוקפאים

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

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

מה מדווח כעת על אירוע ביינאנס?

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

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

אלמנט מדווח	פרטים קונקרטיים	פרשנות אבטחה
השפעה מוערכת	ביינאנס דיווחה על השפעה כוללת מוערכת של 6.3 מיליארד דולר	המספר המדווח משקף את ההיקף הכולל שהוערך באירוע, לא בהכרח סך ההפסד הסופי
נכסים מוקפאים	ביינאנס הודיעה ש-3 מיליארד דולר אומתו כנכסים מוקפאים	הקפאה היא תוצאה של חבישה ודורשת אימות ברמת הנכסים
גישה ראשונית חשודה	מחשב נייד של מהנדס DevOps שנפרץ ייתכן ואיפשר גישה למכולת שירות	פגיעה בנקודת קצה עלולה להוביל לפגיעה בתפעול כאשר גבולות התפעול חלשים
נתיב עסקה חשוד	התוקף ככל הנראה הגיש עסקאות משיכה בלתי מורשות	תהליכי משיכה דורשים בקרות מעבר לאחזקת מפתחות הארנק
מפתחות ארנק	ביינאנס דיווחה שלא נמצאה ראיה לדליפת מפתח פרטי לארנק	אירוע משיכה יכול להתרחש גם ללא גניבת מפתחות חתימה לטווח ארוך
המשכיות שירות	המשיכות הוקפאו, ההפקדות נמשכו כרגיל ותחילת החזרה לפעילות הצפויה תוך 48 שעות	הפרדת פעילות נכנסת ויוצאת עשויה לשמר שירותים נבחרים במהלך חבישה
פעולה מצד Arbitrum	מועצת אבטחת Arbitrum דיווחה על הקפאה של 30.5 מיליון דולר שכוללת 74.6 מיליון ARB ו-8,425 ETH	תיאום בין מערכות אקוסיסטמיות מגביל תנועת נכסים מושפעים
פעולה מצד Aave	Aave הקפיאה שווקים בפריסות V3 ו-V4 כאמצעי זהירות	פרוטוקולים תלויים עשויים להזדקק להפחתת חשיפה טרם זיהוי שורש הטעות הטכנית במלואה

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

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

איך מחשב נייד שנפרץ יכול להוביל למשיכות בלתי מורשות?

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

סביבות חילופים ואחסון מודרניות פועלות לעיתים דרך כמה רמות אמון מחוברות:

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

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

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

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

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

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

מדוע היעדר דליפת מפתח פרטי מדווחת אינו מסיים את החקירה?

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

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

ההבחנה הזאת יוצרת שתי שאלות אבטחה נפרדות:

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

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

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

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

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

מה מראים תגובות Arbitrum ו-Aave?

הפעולות המדווחות של מועצת אבטחת Arbitrum ושל Aave מראות כי ההחבשה יכולה להתרחב מעבר לחילוף שנפגע ישירות כאשר נכסים ונזילות מתקשרים עם מערכות שרשרת רחבות יותר. מועצת אבטחת Arbitrum דיווחה על הקפאה של 30.5 מיליון דולר הכוללת 74.6 מיליון ARB ו-8,425 ETH, בעוד Aave דיווחה על הקפאת שווקים בפריסות V3 ו-V4 כאמצעי זהירות.

פעולות אלו משקפות שני מודלים תגובתיים שונים אך משלימים.

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

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

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

גישת תגובה	שחקן מדווח	פעולה ממוקדת מדווחת	מטרה מגן ראשית
הגבלה ספציפית לנכסים	מועצת אבטחת Arbitrum	הקפיא 30.5 מיליון דולר הכוללים 74.6 מיליון ARB ו-8,425 ETH	למנוע תנועה נוספת של נכסים מזוהים
אמצעי זהירות ברמת שוק	Aave	הקפיא שווקים בפריסות V3 ו-V4	להגביל הדבקה דרך חשיפת שווקי הלוואות
השהיית שירות מרכזי	Binance	השהה משיכות תוך כדי שדרוג אבטחה	לעצור העברות נוספות כלפי חוץ תוך שמירת הפקדות

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

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

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

מה על הצוותים לשנות לאחר דפוס התקיפה המדווח?

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

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

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

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

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

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

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

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

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

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

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

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

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