הטרנדים האחרונים בהתקפות האקרים וכיצד להתמודד איתן

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

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

לדוגמה, האקרים פגעו ושדדו את Wormhole, גנבו יותר מ-300 מיליון דולר, Qubit Finance (80 מיליון דולר), Meter (4.4 מיליון דולר), Deus (3 מיליון דולר), TreasureDAO (מעל 100 NFTs), ולבסוף, Agave and Hundred Finance אשר ביחד , הפסיד 11 מיליון דולר בסך הכל. כל ההתקפות הללו הביאו לגניבה של סכומי כסף משמעותיים למדי, תוך גרימת נזק גדול לפרויקטים.

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

אילו סוגי ניצול התרחשו במהלך ההתקפות?

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

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

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

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

מה יכולים פרויקטי DeFi לעשות כדי להגן על עצמם?

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

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

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

עד כמה הביקורות באמת יכולות לעזור?

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

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

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

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

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

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

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