ביקורת FatCats
תקציר ניהול
FatCats יצרו קשר עם Sayfer Security על מנת לבצע ביקורת חוזים חכמה בחוזה ה-NFT שלהם ברשת Ethereum
במהלך תקופת המחקר של 3 שבועות גילינו 6 נקודות תורפה בחוזה. פגיעות אחת סווגה כגבוהה, המאפשרת לתוקף לגשת למטא-נתונים של NFT לפני שנחשפו ולבצע תחזיות חכמות לגבי נפילות אוויר או עסקאות טביעה ספציפיות עבור NFTs נדירים.
רוב נקודות התורפה רלוונטיות רק בעת הטבעת NFTs חדשים, לכן אנו ממליצים בחום לתקן את נקודות התורפה שנמצאו בדוח זה לפני יצירת נקודות תורפה חדשות.
פגיעויות לפי סיכון
קריטי - חלק מיידי או מתמשך מהעסק מנוצל עם הפסדים עסקיים ישירים.
גָבוֹהַ - איום ישיר על תהליכים עסקיים מרכזיים.
בינוני – איום עקיף על תהליכים עסקיים מרכזיים או איום חלקי על תהליכים עסקיים.
נמוך - לא קיים איום ישיר. הפגיעות עשויה להיות מנוצלת באמצעות פגיעויות אחרות.
מידע - ממצא זה אינו מצביע על פגיעות, אך מציין הערה המודיעה על פגמי עיצוב ויישום לא תקין שעלול לגרום לבעיה בטווח הארוך.
גישה
מבוא
FatCats יצרה קשר עם Sayfer על מנת לבצע ביקורת אבטחה על חוזים חכמים של FatCats.
דוח זה מתעד את המחקר שביצע Sayfer המכוון למשאבים הנבחרים שהוגדרו תחת היקף המחקר. במיוחד, דוח זה מציג את סקירת תנוחת האבטחה עבור החוזים החכמים של FatCats.
מחזור החיים של פרויקט בדיקת החדירה שלנו:
סקירת היקף
סקירה טכנית
אימות היקף
מודל איומים
הערכת אבטחה
הערכת אבטחה
אימות היקף
התחלנו לוודא שההיקף שהוגדר לנו על ידי הלקוח היה הגיוני מבחינה טכנית.
ההחלטה איזה היקף מתאים למערכת נתונה היא חלק מהדיון הראשוני.
מודל איומים
הגדרנו שהאיום הגדול ביותר כיום על המערכת הוא היכולת של משתמשים זדוניים לגנוב כספים מהחוזה. הסיכון השני בגובהו לפלטפורמה הוא יכולת ההתקפה לגנוב NFT מהחוזה.
סקירת פרוטוקול
מבוא פרוטוקול
Fat Cats הוא אוסף של 5,000 NFTs ייחודיים המשמשים כאסימון חברות וחלק מכל אחזקות Fat Cats. בעלות על Fat Cats NFT נותנת לך גישה לנתח מכל אחזקות ה-DAO במחיר סביר.
כל הכספים הנזילים יוחזקו בסל של מטבעות יציבים ונכסי קריפטו אחרים כראות עיני החברים. במקרה של החלטות רגישות לזמן, המועצה רשאית להוציא עד 20% מכלל הכספים הנאמנים.
חוזה FatCats הוא חוזה אסימון NFT הכולל טביעה בשלבים - שלב 1, שלב 2 ומטבעה ציבורית. שלבי ההטבעה נקבעים על ידי הבעלים. משתמשים ברשימת ההיתרים יכולים להטביע NFT בשלב 1 ושלב 2. משתמשים ברשימת ההיתרים מאומתים על ידי הוכחה של Merkle.
חוזה FatCats יורש את MerkleProof, Ownable, Address, VRFCoordinatorV2Interface, VRFConsumerBaseV2, IERC721Receiver, Context, IERC721Metadata , Strings, ERC165, IERC721, חוזים חכמים סטנדרטיים מספריית OpenZeppelin. חוזי OpenZeppelin אלה נחשבים לביקורת קהילתית ונבחנת זמן, ולפיכך אינם חלק מהיקף הביקורת.
גרף פרוטוקול
הערכת אבטחה
מקרי הבדיקה הבאים היו הקו המנחה בעת ביקורת המערכת. רשימת בדיקה זו היא גרסה שונה של SCSVS v1.2, עם שיפור דקדוק, בהירות, תמציתיות וקריטריונים נוספים. כאשר יש פער במספור, הוסר קריטריון מקורי. קריטריונים המסומנים בכוכבית נוספו על ידינו.
אדריכלות, עיצוב ומידול איומים
| אדריכלות, עיצוב ומידול איומים | שם המבחן |
| G1.2 | כל שינוי עיצובי שהוצג קודם למודל איומים. |
| G1.3 | התיעוד מגדיר בצורה ברורה ומדויקת את כל גבולות האמון בחוזה (יחסי אמון עם חוזים אחרים ותזרימי מידע משמעותיים). |
| G1.4 | ה-SCSVS, דרישות האבטחה או המדיניות זמינים לכל המפתחים והבודקים. |
| G1.5 | מוגדרים האירועים עבור הפעולות (משנות מדינה/מכריעות לעסקים). |
| G1.6 | הפרויקט כולל מנגנון שיכול לעצור זמנית פונקציות רגישות במקרה של תקיפה. מנגנון זה לא אמור לחסום את הגישה של משתמשים לנכסים שלהם (למשל אסימונים). |
| G1.7 | כמות המטבעות הקריפטו שאינם בשימוש שנשמרו בחוזה נשלטת וברמה המינימלית המקובלת על מנת לא להפוך למטרה פוטנציאלית למתקפה. |
| G1.8 | אם כל אחד יכול לקרוא לפונקציית ה-fallback, היא כלולה במודל האיום. |
| G1.9 | ההיגיון העסקי עקבי. יש ליישם שינויים חשובים בלוגיקה בכל החוזים. |
| G1.10 | כלי ניתוח קוד אוטומטי משמשים לאיתור נקודות תורפה. |
| G1.11 | נעשה שימוש במהדורה העיקרית האחרונה של Solidity. |
| G1.12 | בעת שימוש ביישום חיצוני של חוזה, נעשה שימוש בגרסה העדכנית ביותר. |
| G1.13 | כאשר פונקציות נדחפות כדי להרחיב את הפונקציונליות, מילת המפתח העל משמשת לשמירה על פונקציונליות קודמת. |
| G1.14 | סדר הירושה מצוין בקפידה. |
| G1.15 | ישנו רכיב שמנטר את פעילות החוזה באמצעות אירועים. |
| G1.16 | מודל האיום כולל עסקאות לווייתנים. |
| G1.17 | דליפה של מפתח פרטי אחד אינה פוגעת באבטחת הפרויקט כולו. |
מדיניות ונהלים
| מדיניות ונהלים | שם המבחן |
| G2.2 | אבטחת המערכת נמצאת במעקב מתמיד (למשל רמת הכספים הצפויה). |
| G2.3 | ישנה מדיניות לעקוב אחר פרצות אבטחה חדשות ולעדכן ספריות לגרסה המאובטחת העדכנית ביותר. |
| G2.4 | ניתן ליצור קשר עם מחלקת האבטחה בפומבי וכי הנוהל לטיפול באגים מדווחים (למשל, שפע של באגים יסודי) מוגדר היטב. |
| G2.5 | תהליך הוספת רכיבים חדשים למערכת מוגדר היטב. |
| G2.6 | תהליך של שינויים גדולים במערכת כרוך במודל איומים על ידי חברה חיצונית. |
| G2.7 | תהליך הוספה ועדכון רכיבים למערכת כולל ביקורת אבטחה של חברה חיצונית. |
| G2.8 | במקרה של פריצה, ישנו הליך הפחתה ברור וידוע במקום. |
| G2.9 | הנוהל במקרה של פריצה מגדיר בבירור אילו אנשים יבצעו את הפעולות הנדרשות. |
| G2.10 | ההליך כולל אזעקת פרויקטים אחרים לגבי הפריצה דרך ערוצים מהימנים. |
| G2.11 | מוגדר הליך להפחתת דליפות מפתח פרטי. |
שדרוג
| שדרוג | שם המבחן |
| G3.2 | לפני השדרוג, מתבצעת אמולציה במזלג של הרשת הראשית והכל עובד כמצופה בעותק המקומי. |
| G3.3 | תהליך השדרוג מבוצע על ידי חוזה multisig שבו יותר מאדם אחד חייב לאשר את הפעולה. |
| G3.4 | נעילות זמן משמשות לפעולות חשובות כדי שלמשתמשים יהיה זמן לצפות בשינויים הקרובים (שימו לב שהסרת נקודות תורפה אפשריות במקרה זה עשויה להיות קשה יותר). |
| G3.5 | לְאַתחֵל() ניתן להתקשר רק פעם אחת. |
| G3.6 | לְאַתחֵל() ניתן לקרוא רק על ידי תפקיד מורשה באמצעות מתקנים מתאימים (למשל אתחול, רק בעלים). |
| G3.7 | תהליך העדכון נעשה בעסקה אחת כך שאף אחד לא יוכל להריץ אותו מראש. |
| G3.8 | חוזים שניתנים לשדרוג ישמרו פערים על משבצות כדי למנוע החלפה. |
| G3.9 | מספר המשבצות השמורה (כפער) הצטמצם כראוי אם נוספו משתנים חדשים. |
| G3.10 | אין שינויים בסדר ההכרזה על משתני מצב החוזה, ולא בסוגיהם. |
| G3.11 | ערכים חדשים המוחזרים על ידי הפונקציות זהים לאלו בגרסאות קודמות של החוזה (למשל בעל(), balanceOf(כתובת)). |
| G3.12 | היישום הוא אתחול. |
| G3.13 | אי אפשר להרוס את היישום. |
לוגיקה עסקית
| לוגיקה עסקית | שם המבחן |
| G4.2 | יישום ההיגיון והפרוטוקול של החוזה תואם את התיעוד. |
| G4.3 | ההיגיון העסקי ממשיך בסדר שלבים רציף ולא ניתן לדלג על שלבים או לעשות זאת בסדר שונה מהמתוכנן. |
| G4.4 | החוזה אכף מגבלות עסקיות בצורה נכונה. |
| G4.5 | ההיגיון העסקי אינו מסתמך על הערכים שנשלפים מחוזים לא מהימנים (במיוחד כאשר ישנן מספר קריאות לאותו חוזה בזרימה אחת). |
| G4.6 | ההיגיון העסקי אינו מסתמך על יתרת החוזה (למשל, יתרה == 0). |
| G4.7 | פעולות רגישות אינן תלויות בנתוני בלוק (למשל, חסום hash, חותמת זמן). |
| G4.8 | החוזה משתמש במנגנונים שמצמצמים התקפות של הזמנת עסקאות (פרונט-running) (למשל תוכניות קדם-התחייבות). |
| G4.9 | החוזה אינו שולח כספים באופן אוטומטי, אלא מאפשר למשתמשים למשוך כספים בעסקאות נפרדות במקום זאת. |
בקרת גישה
| בקרת גישה | שם המבחן |
| G5.2 | עקרון הזכות הקטנה נשמר. חוזים אחרים צריכים להיות מסוגלים לגשת רק לפונקציות ולנתונים שעבורם יש להם הרשאה ספציפית. |
| G5.3 | חוזים חדשים עם גישה לחוזה המבוקר מצייתים לעקרון המינימום זכויות כברירת מחדל. לחוזים צריכים להיות הרשאות מינימליות או ללא הרשאות עד שתינתן במפורש גישה לתכונות החדשות. |
| G5.4 | יוצר החוזה עומד בעקרון הזכות הקטנה ביותר וזכויותיו עולות בקפדנות על אלו המפורטות בתיעוד. |
| G5.5 | החוזה אוכף את כללי בקרת הגישה המפורטים בחוזה מהימן, במיוחד אם בקרת הגישה בצד הלקוח של dApp קיימת ואפשר לעקוף אותה. |
| G5.6 | שיחות לחוזים חיצוניים מותרות רק במידת הצורך. |
| G5.7 | קוד השינוי ברור ופשוט. ההיגיון לא אמור להכיל קריאות חיצוניות לחוזים לא מהימנים. |
| G5.8 | כל תכונות המשתמש והנתונים המשמשות את בקרות הגישה נשמרות בחוזים מהימנים ולא ניתנות למניפולציה על ידי חוזים אחרים, אלא אם כן הרשאה ספציפית. |
| G5.9 | בקרות הגישה נכשלות בצורה מאובטחת, כולל כאשר מתרחשת חזרה. |
| G5.10 | אם הקלט (פרמטרי פונקציה) מאומת, נעשה שימוש בגישת האימות החיובי (רישום לבן) במידת האפשר. |
תקשורת
| תקשורת | שם המבחן |
| G6.2 | ספריות שאינן חלק מהאפליקציה (אך החוזה החכם מסתמך על הפעולה) מזוהות. |
| G6.3 | לא נעשה שימוש בשיחת נציג עם חוזים לא מהימנים. |
| G6.4 | חוזי צד שלישי אינם מטילים צל על פונקציות מיוחדות (למשל ביטול). |
| G6.5 | החוזה אינו בודק אם הכתובת היא חוזה באמצעות opcode extcodesize. |
| G6.6 | התקפות כניסה חוזרות מופחתות על ידי חסימת שיחות רקורסיביות מחוזים אחרים וביצוע דפוס Check-Effects-Interactions. אל תשתמש בפונקציית השליחה אלא אם כן היא חובה. |
| G6.7 | התוצאה של קריאות לפונקציות ברמה נמוכה (למשל שלח, נציג התקשר, התקשר) מחוזים אחרים נבדק. |
| G6.8 | החוזה מסתמך על הנתונים שסופקו על ידי השולח הנכון ואינו מסתמך על ערך tx.origin. |
חשבון
| חשבון | שם המבחן |
| G7.2 | הערכים והפעולות המתמטיות עמידים בפני הצפת מספרים שלמים. השתמש בספריית SafeMath עבור פעולות אריתמטיות לפני מוצקות 0.8.*. |
| G7.3 | קטעי הקוד הלא מסומנים מ- Solidity ≥ 0.8.* אינם מציגים תת-מספרים שלמים. |
| G7.4 | ערכים קיצוניים (למשל ערכי מקסימום ומינימום מסוג המשתנה) נחשבים ואינם משנים את הזרימה הלוגית של החוזה |
| G7.5 | אי שוויון לא קפדני משמש לאיזון שוויון. |
| G7.6 | בחישובים נעשה שימוש בסדרי גודל נכונים. |
| G7.7 | בחישובים, הכפל מתבצע לפני החלוקה לצורך דיוק. |
| G7.8 | החוזה אינו מניח דיוק של נקודה קבועה ומשתמש במכפיל או מאחסן הן את המונה והן המכנה. |
מניעת שירות
| מניעת שירות | שם המבחן |
| G8.2 | החוזה אינו חוזר על לולאות לא קשורות. |
| G8.3 | פונקציונליות ההשמדה העצמית משמשת רק במידת הצורך. אם זה כלול בחוזה, זה צריך להיות מתואר בבירור בתיעוד. |
| G8.4 | ההיגיון העסקי לא נחסם אם שחקן (למשל חוזה, חשבון, אורקל) נעדר. |
| G8.5 | ההיגיון העסקי אינו מונע ממשתמשים להשתמש בחוזים (למשל עלות העסקה גבוהה מהרווח). |
| G8.6 | ביטויים של פונקציות טוענים או דורשים הם בעלי וריאנט עובר. |
| G8.7 | אם פונקציית החלפה אינה ניתנת להתקשרות על ידי אף אחד, היא אינה חוסמת פונקציונליות של חוזה. |
| G8.8 | אין פעולות יקרות בלולאה. |
| G8.9 | אין שיחות לחוזים לא מהימנים בלולאה. |
| G8.10 | במידה וקיימת אפשרות לעיכוב ביצוע החוזה, ניתן גם לחדשו. |
| G8.11 | אם נעשה שימוש ברשימות הלבנות וברשימות שחורות, הן אינן מפריעות לפעולה הרגילה של המערכת. |
| G8.12 | אין DoS שנגרם על ידי הצפות והצפות. |
נתוני בלוקצ'יין
| נתוני בלוקצ'יין | שם המבחן |
| G9.2 | כל מידע שנשמר בחוזים אינו נחשב מאובטח או פרטי (אפילו משתנים פרטיים). |
| G9.3 | לא מאוחסנים נתונים סודיים בבלוקצ'יין (סיסמאות, נתונים אישיים, אסימון וכו'). |
| G9.4 | חוזים אינם משתמשים במילולי מחרוזת כמפתחות למיפויים. במקום זאת נעשה שימוש בקבועים גלובליים כדי למנוע התקפת Homoglyph. |
| G9.5 | החוזה אינו יוצר באופן טריוויאלי מספרים פסאודו אקראיים על סמך המידע מהבלוקצ'יין (למשל זריעה עם מספר הבלוק). |
שימוש בגז ומגבלות
| שימוש בגז ומגבלות | שם המבחן |
| G10.1 | השימוש בגז צפוי, מוגדר ויש לו מגבלות ברורות שלא ניתן לחרוג מהן. גם מבנה הקוד וגם קלט זדוני לא אמורים לגרום לתשישות גזים. |
| G10.2 | ביצוע הפונקציה והפונקציונליות אינם תלויים בעמלות גז בקוד קשיח (הם עשויים להשתנות). |
בהירות וקריאה
| בהירות וקריאה | שם המבחן |
| G11.2 | ההיגיון ברור ומודולרי במספר חוזים ופונקציות פשוטות. |
| G11.3 | לכל חוזה יש הערה קצרה של 1-2 משפטים שמסבירה את מטרתו ואת הפונקציונליות שלו. |
| G11.4 | נעשה שימוש ביישומי מדף, זה מובהר בהערה. אם יישומים אלה שונו, השינויים יצוינו לאורך כל החוזה. |
| G11.5 | סדר הירושה נלקח בחשבון בחוזים המשתמשים בפונקציות ירושה וצל מרובות. |
| G11.6 | במידת האפשר, חוזים משתמשים בקוד נבדק קיים (למשל חוזים סמליים או מנגנונים כמו ניתן לבעלות) במקום ליישם את שלהם. |
| G11.7 | מעקב אחר דפוסי שמות עקביים לאורך הפרויקט. |
| G11.8 | למשתנים יש שמות ייחודיים. |
| G11.9 | כל משתני האחסון מאותחלים. |
| G11.10 | פונקציות עם סוג החזרה שצוין מחזירות ערך מסוג זה. |
| G11.11 | נעשה שימוש בכל הפונקציות והמשתנים. |
| G11.12 | לדרוש משמש במקום לחזור in if הצהרות. |
| G11.13 | אל האני לִטעוֹן הפונקציה משמשת לבדיקת שגיאות פנימיות ו- לדרוש הפונקציה משמשת כדי להבטיח תנאי תקף בקלט ממשתמשים וחוזים חיצוניים. |
| G11.14 | קוד הרכבה משמש רק במידת הצורך. |
כיסוי מבחן
| כיסוי מבחן | שם המבחן |
| G12.2 | נרטיבים של התעללות המפורטים במודל האיום מכוסים על ידי בדיקות יחידה |
| G12.3 | פונקציות רגישות בחוזים מאומתים מכוסות בבדיקות בשלב הפיתוח. |
| G12.4 | הטמעת חוזים מאומתים נבדקה לאיתור פרצות אבטחה באמצעות ניתוח סטטי ודינאמי כאחד. |
| G12.5 | מפרט החוזה אומת רשמית |
| G12.6 | המפרט והתוצאות של האימות הפורמלי כלולים בתיעוד. |
מימון מבוזר
| מימון מבוזר | שם המבחן |
| G13.1 | החוזה של המלווה אינו מניח שהיתרה שלו (המשמשת לאישור החזר ההלוואה) תשתנה רק עם הפונקציות שלו. |
| G13.2 | פונקציות שמשנות את יתרת המלווים ו/או משאילות מטבע קריפטוגרפי אינן נכנסות מחדש אם החוזה החכם מאפשר ללוות את המטבע הקריפטוגרפי של הפלטפורמה הראשית (למשל Ethereum). הוא חוסם את ההתקפות שמעדכנות את יתרת הלווה במהלך ביצוע ההלוואה הבזק. |
| G13.3 | פונקציות הלוואת פלאש יכולות לקרוא רק לפונקציות מוגדרות מראש בחוזה המקבל. אם זה אפשרי, הגדר קבוצת משנה מהימנה של חוזים שיש לקרוא. בדרך כלל, חוזה השליחה (השאלה) הוא זה שייקרא בחזרה. |
| G13.4 | אם הוא כולל פעולות שעלולות להיות מסוכנות (למשל שליחת ETH/אסימונים חזרה יותר ממה שהושאל), ניתן לקרוא לפונקציה של המקבל שמטפל ב-ETH או אסימונים מושאלים רק על ידי המאגר ובתוך תהליך שיזם בעל החוזה המקבל או מקור מהימן אחר (למשל multisig). |
| G13.5 | חישובים של נתח מאגר הנזילות מבוצעים בדיוק הגבוה ביותר האפשרי (למשל אם התרומה מחושבת עבור ETH היא צריכה להיעשות עם דיוק של 18 ספרות - עבור Wei, לא Ether). יש להכפיל את הדיבידנד ב-10 בחזקת מספר הספרות העשרוניות (למשל דיבידנד * 10^18 / מחלק). |
| G13.6 | לא ניתן לחשב ולחלק תגמולים בתוך אותה קריאת פונקציה שמפקידה אסימונים (יש להגדיר אותה גם כלא משתתף מחדש). זה מגן מפני תנודות רגעיות במניות. |
| G13.7 | חוזי ממשל מוגנים מפני התקפות הלוואות בזק. טכניקת הפחתה אפשרית היא לדרוש תהליך של הפקדת אסימוני ממשל והצעת שינוי לביצוע בעסקאות שונות הכלולות בבלוקים שונים. |
| G13.8 | בעת שימוש באורקל על השרשרת, חוזים מסוגלים להשהות פעולות על סמך התוצאה של האורקל (במקרה של אורקל בסיכון). |
| G13.9 | לחוזים חיצוניים (אפילו מהימנים) המורשים לשנות את התכונות של חוזה פרויקט (למשל מחיר סמלי) מיושמות המגבלות הבאות: ספים לשינוי (למשל לא יותר/פחות מ-5%) ומגבלה של עדכונים (למשל עדכון אחד ליום). |
| G13.10 | תכונות החוזה שניתן לעדכן על ידי החוזים החיצוניים (אפילו מהימנים) מנוטרות (למשל באמצעות אירועים) ונוהל תגובה לאירוע מיושם (למשל במהלך מתקפה מתמשכת). |
| G13.11 | פעולות מתמטיות מורכבות המורכבות מפעולות כפל וחילוק מבצעות תחילה כפל ולאחר מכן חילוק. |
| G13.12 | בעת חישוב מחירי החליפין (למשל ETH לאסימון או להיפך), המונה והמכנה מוכפלים ברזרבות (ראה getInputPrice פונקציה ב UniswapExchange חוֹזֶה). |
הזמינו ביקורת מסיפר
ממצאי ביקורת
URI אסימון ניתן לניחוש
| מצב | להרחיב |
| הסיכון | קריטי |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
התחלת ידע לגבי המטא נתונים של ה-NFT יכול לתת לתוקף לדעת איזה NFT עליו להטביע לפני שהציבור יחשוף. זה עשוי לאפשר לתוקף להשיג שליטה ב-NFTs היקרים ביותר בפרויקט.
הפגיעות הבאה מאפשרת לתוקף להחליט איזה NFT לקנות בהתבסס על מטא נתונים לפני החשיפה לציבור. פגיעות זו קלה יחסית לניצול עקב נקודות תורפה אחרות שמצאנו. בזמן שבין ה shuffle דגל הופך אמיתי פנימה requestRandomWords() וה-NFTs שנחשפים ב revealNFT(), תוקף יכול לנחש את ה-URI של האסימון.
בעוד revealed הדגל עדיין לא נכון tokenURI() החזרות hideUri, כלומר המשתמש הממוצע יראה רק את ה-URI הדמה/נסתר ללא המטא נתונים המלאים.
כדי לבנות באופן מלא את מחרוזת ה-URI של האסימון מתבצעת עסקה נוספת לביצוע requestRandomWords() שיטה אשר קובעת את s_randomWords באמצעות fulfillRandomWords(). זה נעשה באמצעות ה-VRF של Chianlink.
רק אז הקוד הבא מבוצע ומחזיר את מחרוזת URI האסימון המלאה:
הפגיעות היא כזו baseURI, maxSupply ו s_randomWords הם ציבוריים ותוקף יכול לחזות את URI של האסימון ללא צורך ב- revealed מִשְׁתַנֶה. ב-V1 של הפרויקט ראינו שהעסקה הראשונה שמתבצעת requestRandomWords():
ואז העסקה השנייה שחושפת את ה-NFT על ידי ביצוע ה- revealNFT():
אנו יכולים לראות שבמהלך 3 שעות, תוקף יכול היה לצפות בכל מטא נתונים של NFT לפני שהוא נחשף ולבצע תחזיות חכמות לגבי נפילות אוויר או עסקאות טביעה ספציפיות עבור NFT נדירים.
הקלות
לחשוף NFT אין מידה אחת המתאימה לכולם. זה תלוי מאוד באסטרטגיה ובחוויית המשתמש שצריכה להיות למשתמש הקצה.
לאבטחה טובה יותר אנו ממליצים לחשוף, להגדיר את ה-URI הבסיסי ולשנות את המצב של s_randomWords משתנה מצב עם הפרש הזמן הקצר ביותר ביניהם. למרות שלא מפחית את הפגיעות לחלוטין, צמצום הזמן בין הפעולות הללו יכול להפחית את הסיכון של שחקנים רעים לנצל אותה.
דרך טובה יותר היא לבצע את כל שינויי המדינה באותה עסקה תוך גילוי, הרבה פעמים זה לא אפשרי מבחינה טכנית.
לצלילה עמוקה יותר כיצד ליישם ירידה אקראית של NFT ודרכים בטוחות יותר, אנו ממליצים לקרוא אסטרטגיות אקראיות לירידות NFT.
כתובות ברשימת ההיתרים יכולות להיות חוזים
| מצב | להרחיב |
| הסיכון | גָבוֹהַ |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
בעת הטבעה של NFT, חוזה ההטבעה עלול לחסום או לאפשר טביעה להתקשר כתובות. מתן אפשרות להטמעה להתקשר או שיש לו נקודת תורפה המאפשרת טביעת חוזה עלולה לגרום למצב שבו התוקף יכול לבטל את העסקה אם יש לו ידע מוקדם לגבי איזה NFT עליו להטביע.
המשנה isAUser() משמש רק עבור publicMint().
בעד mintStep1() ו mintStep2() שיטות isWhitelisted() נעשה שימוש במשנה.
משמעות הדבר היא שהקוד אינו בודק כתובות שאינן חוזיות ברשימת ההיתרים של Merkle הוכחה.
למרות שאיננו יכולים לדעת מה היו התהליכים שמאחורי הרשימה הלבנה שנוצרה ועד כמה היא מאובטחת, הקוד עצמו חשוף להתקפה זו. בדיקה של כתובות שאינן קשורות לחוזה מחוץ לשרשרת או לא באותה עסקה מונעת מכיוון שהיא חשופה למספר רב של וקטורי תקיפה.
תוקף יכול להשיג NFT ולהחזיר את העסקה אם ה-NFT אינו נדיר מספיק. בשילוב עם ה-Guessable Token URI, תוקף יכול בקלות לקבל ידע מוקדם על המטא נתונים של ה-NFT ולהחזיר עסקאות על סמך הנדירות.
הקלות
מוסיף את isAUser משנה ל- mintStep1() ו mintStep2() שיטות.
יישום אקראי חלש לא מאובטח של VRF של Chainlink
| מצב | להרחיב |
| הסיכון | גָבוֹהַ |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
שגיאות אקראיות לא מאובטחות מתרחשות כאשר פונקציה שיכולה לייצר ערכים צפויים משמשת כמקור לאקראיות בהקשר רגיש לאבטחה.
חוזים חכמים צריכים להסתמך על פתרונות מחוץ לרשת כדי ליצור מספרים אקראיים מאובטחים. Fatcats משתמשת במערכת VRF של Chainlink כדי ליצור מספר אקראי שבהמשך משמש כמזהה אקראי עבור URI של האסימון באמצעות fulfillRandomWords שיטה:
השיטה שומרת את המספר האקראי למשתנה מצב שנקרא s_randomWords שלפי השם מרמז שזו מילה אקראית. בפועל, המספר הוא modulo with maxSupply(5000) אז זהו מספר אקראי פסאודו חלש בין 1 ל-5000. זה יכול לגרום למפתחים לחשוב שהם יכולים להסתמך על המספר הזה עבור אקראיות מאובטחת, וזה לא.
הקלות
הקצה את הערך המוחזר המגיע מ-VRF למשתנה המצב הגלובלי.
ריכוז החוזה וארנק הצוות
| מצב | להרחיב |
| הסיכון | גָבוֹהַ |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
פרויקטים המסתמכים על מפתח אחד חשופים לאובדן מפתח, התקפות פישינג, מניפולציות של שחקנים פנימיים, מוות של הבעלים ועוד.
כאשר הפרויקט תלוי רק במפתח אחד. התקפות מסוג זה הן הנפוצות ביותר מבין הפריצות הגדולות ביותר.
הפרויקט בודק את isOwner במספר מקומות. אובדן המפתחות לכתובת הפריסה הזו יסכן את הפרויקט כולו.
בנוסף, ארנק הצוות שיקבל את האת באמצעות ה withdraw הפונקציה נתונה גם לאותו וקטור התקפה
אם הארנקים לעיל משתמשים ב-multisig, ממצא זה ייפתר.
הקלות
בהתאם למקרה השימוש, רמת האבטחה וחווית המשתמש שהפרויקט רוצה ליישם, ישנן מספר דרכים לצמצם את ההתקפה הזו, למשל באמצעות ארנק multisig, ארנק חכם או החלת מספר בעלים על הפרויקט.
מתגי פונקציות openPublicBurn במקום נפתח
| מצב | להרחיב |
| הסיכון | נמוך |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
השיטה openPublicBurn לא רק פותח את הצריבה הציבורית, הוא מדליק ומכבה אותה בהתאם למצב הנוכחי של המשתנה.
זה יכול להוביל מפתח או מפעיל של הפרויקט לחשוב שהם פותחים את שלב הצריבה הציבורי אך למעשה מכבים אותו וגורם למוניטין רע לפרויקט.
הקלות
הגדר את משתנה המצב publicBurnFlag ל-true או לשנות את שם השיטה ל
switchPublicBurn.
קשה לתחזק את מנגנון הצעדים
| מצב | להרחיב |
| הסיכון | מידע |
| מקום | FatCats.sol |
| כלים | בדיקה ידנית |
תיאור
הקוד משתמש במשתנים בוליאניים עבור כל שלב, זה אומר שבכל פעם שהמפתח מוסיף שלב נוסף הוא/היא צריך להוסיף את ההיגיון כדי להחליף את איפוס הדגלים. זה עלול להוביל לבלבול ולבאגי אבטחה פוטנציאליים.
גישה טובה יותר תהיה להשתמש ב-enum כשלב הנוכחי אם, זה נותן את היתרונות של שם צעד ברור כמו EARLY_ADAPTERS, PUBLINK_MINTועוד
אם זה מפורט מדי או מבלבל, אפשר ליישם אותו באמצעות מספר שלם פשוט, יש לזה יתרון מתמטי של if step > 2 or require(newStep < oldStep, “can not go back”.
הקלות
השתמש ב-enum מובנה בסולידיות או בתחביר מספר שלם פשוט.