איך כותבים writeup ל-CTF - מדריך מעשי¶
פתרתם אתגר CTF, קפצתם מהכיסא מרוב סיפוק, ועכשיו מה. הרבה אנשים עוצרים בדיוק בנקודה הזו - הדגל נתפס, אז הסיפור נגמר. אבל זו בדיוק הנקודה שבה מתחיל החלק שבאמת בונה אתכם כאנשי סייבר: כתיבת writeup.
writeup הוא תיעוד מסודר של איך פתרתם אתגר - מה ניסיתם, מה גיליתם, ואיך בדיוק ניצלתם את החולשה. זה נשמע כמו עבודה נוספת מיותרת אחרי שכבר "סיימתם", אבל האמת היא שהכתיבה עצמה היא חלק מהלמידה, לא תוספת אליה.
למה בכלל לטרוח לכתוב¶
כשאתם רק פותרים אתגר, מספיק שמשהו "עבד". לא תמיד אתם עוצרים להבין למה זה עבד. ברגע שאתם יושבים לכתוב הסבר מסודר למישהו אחר, אתם מגלים מהר מאוד את הפערים בהבנה שלכם. פתאום אתם צריכים להסביר למה הפרמטר הזה בדיוק היה פגיע, ולא רק "שמתי פה תו מוזר וזה עבד". זו בדיקת מציאות מצוינת.
מעבר לזה, writeup הוא תיק עבודות ציבורי. גיוסים למשרות אבטחה, וגם תהליכי מיון טכניים, מתייחסים ברצינות רבה לאוסף writeups מסודר - זה מוכיח לא רק שפתרתם אתגר, אלא שאתם יודעים להסביר תהליך חשיבה בצורה ברורה, מיומנות שחסרה להרבה אנשים טכניים מוכשרים. וכמובן, יש את הצד הקהילתי: מישהו אחר שנתקע באותו אתגר בדיוק, בעוד חצי שנה, ימצא את ה-writeup שלכם ויתקדם הודות לו.
המבנה שעובד¶
אין נוסחה קדושה, אבל writeup טוב בדרך כלל כולל את המרכיבים הבאים.
תיאור קצר של האתגר - שם, קטגוריה (web, pwn, crypto, forensics וכדומה) ומספר הנקודות, כדי שהקורא ידע מיד לאיזה סוג בעיה נכנס.
תהליך הסיור וההתחקות - מה בדקתם קודם, אילו כלים הרצתם (nmap, gobuster, burp, מה שרלוונטי), ומה מצאתם. שווה להזכיר בקצרה גם דרכים שלא הובילו לשום מקום - זה מראה תהליך חשיבה אמיתי ולא רק "פתאום ידעתי".
הסבר על החולשה - מה בדיוק היה שבור, ולמה. לא מספיק לכתוב "היה SQL Injection", אלא להראות איזה קוד או קונפיגורציה יצרו את הפרצה.
שלבי הניצול - הפקודות המדויקות, קטעי קוד, ותצלומי מסך מהטרמינל שממחישים כל שלב. מישהו שקורא צריך להיות מסוגל לשחזר את מה שעשיתם בלי לנחש.
הדגל - בהתאם לכללי הפלטפורמה, לפעמים מציגים אותו במלואו ולפעמים מטשטשים חלק ממנו.
הכללים הבלתי כתובים לפני שמפרסמים¶
יש כלל אתיקה אחד שממש חשוב לפני שאתם לוחצים "פרסם": כתבו writeup רק על אתגרים שהסתיימו או נסגרו. אם מדובר במכונה פעילה בפלטפורמה כמו HackTheBox או בתחרות עם שעון רץ, פרסום פתרון באמצע מקלקל את החוויה לכולם ולעיתים מפר את תנאי השימוש של הפלטפורמה. כל פלטפורמה רצינה מפרסמת מדיניות ברורה - תקופת embargo, תאריך שממנו מותר לפרסם - ושווה לבדוק אותה במקום להניח.
מבחינת כלים, אין צורך במשהו מסובך. markdown פשוט, כמה תצלומי מסך מהטרמינל, ומקום לארח את זה - בלוג אישי או ריפוזיטורי GitHub ייעודי - מספיקים לגמרי. העיקר זה העקביות: כמה writeups שנצברים לאורך זמן שווים הרבה יותר מ-writeup מושקע אחד שנשאר בודד.
אם אתם רוצים לבנות בסיס רציני בפריצת ווב לפני שאתם ניגשים לכתוב writeups לאתגרים מהסוג הזה, תבנו את הבסיס עם קורס בדיקות החדירה שלנו - ההבנה העמוקה של החולשות היא בדיוק מה שהופך writeup מ"זה עבד" ל"הנה למה זה עבד".
לסיכום¶
writeup הוא לא תיעוד יבש שעושים כי צריך - הוא כלי הלמידה החזק ביותר אחרי הפתרון עצמו, והוא בונה לכם תיק עבודות שממשיך לעבוד בשבילכם הרבה אחרי שסיימתם את האתגר. תתחילו קטן, תהיו עקביים, ותכבדו את זמני הפרסום של כל פלטפורמה.
אם אתם כותבים writeup ראשון ולא בטוחים אם המבנה שלכם הגיוני, יש קהילה שמחה לתת פידבק.