כללי ההתנהלות בבאג באונטי: סקופ, safe harbour וחשיפה

#מה זו תוכנית באג באונטי

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

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

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

#למה הכללים באים לפני הבדיקה

החשיפה המשפטית היא הסיבה הראשונה שאנשים נוהגים לתת, והיא אמיתית. חוקי שימוש לרעה במחשבים במדינות רבות מנוסחים באופן רחב כל כך שגישה ללא הרשאה יכולה להוביל לאישום גם כשהכוונה הייתה טובה. ה-Computer Fraud and Abuse Act (CFAA) בארצות הברית הוא הדוגמה המוכרת ביותר. במאי 2022 שינה ה-U.S. Department of Justice את האופן שבו התובעים שלו מגישים אישומים על מחקר אבטחה בתום לב לפי החוק הזה. המדיניות המעודכנת מורה לתובעים לא להאשים על מחקר שנעשה אך ורק כדי לבדוק, לחקור או לתקן ליקוי, שנמנע מגרימת נזק, ושהמידע ממנו משמש בעיקר לשיפור האבטחה. היא לא משנה את החוק. היא לא מגינה על מחקר שמטרתו סחיטה. זו מדיניות של הגשת אישומים ואינה זכות משפטית, והיא לא מחייבת תובעים במדינות ארצות הברית או גורמים פרטיים שמגישים תביעה. את הנוסח המדויק צריך לקרוא בהודעה של ה-DOJ. אין להתייחס אליה כאל היתר לבדוק כל מה שמתחשק.

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

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

#קריאת מדיניות של תוכנית, שלב אחר שלב

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

#1. נכסים בתוך הסקופ ומחוץ לו

הסקופ הוא רשימת הנכסים שהבעלים מאפשר לבדוק. נכס יכול להיות דומיין, טווח IP, אפליקציית מובייל, API, מוצר או סוג חשבון. מדיניות טובה נוקבת בכל נכס במדויק ואומרת אם wildcard כמו *.example.test מכסה כל תת־דומיין.

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

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

#2. טכניקות מותרות ואסורות

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

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

#3. מגבלות קצב ועומס

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

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

#4. חשבונות בדיקה

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

#5. טיפול בנתונים

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

הכלל של עצירה במידע אישי מפיל הרבה אנשים. אם insecure direct object reference (IDOR) חושף רשומה של מישהו אחר, ההוכחה הנכונה היא בדרך כלל המזהה ותיאור קצר, ולא dump של הטבלה. רושמים מה נראה, וכל השאר נשאר במקומו.

#6. נוסח safe harbour

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

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

#7. פרטי קשר ותנאי חשיפה

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

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

#חשיפה מתואמת של חולשות

Coordinated vulnerability disclosure (CVD) הוא התהליך שבו מי שמצא חולשה מדווח עליה לגורם שיכול לתקן אותה, הספק וגורמים מושפעים אחרים מכינים תיקון והנחיות, והמידע מתפרסם כשמי שצריך אותו יכול לפעול. לפי CISA, התוכנית שלה מקדמת הפצה בזמן ומתואמת של מידע על חולשות ושל כל מיטיגציה זמינה.

ISO/IEC 29147, בשם "Vulnerability disclosure" בסדרה Information technology, Security techniques, הוא הסטנדרט הבין־לאומי לצד החיצוני של התהליך הזה. הוא עוסק באופן שבו ספק מקבל דיווחים, מתקשר עם המדווח, מתאם עם ספקים אחרים ומפרסם הודעות אבטחה. המסמך המשלים, ISO/IEC 30111, עוסק באופן שבו הספק מטפל בחולשה בתוך הארגון. הקטלוג של ISO מציין את המסמך כמהדורה השנייה מ-2018. לפני שמצטטים אותו, צריך לבדוק ב-iso.org מה הסטטוס העדכני.

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

#למה בדיקה מחוץ לסקופ אסורה

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

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

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

#תרגול: הערות על מדיניות לדוגמה וכתיבת צ׳ק־ליסט לפני בדיקה

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

#המדיניות לדוגמה

יש לשמור את הטקסט הזה בשם sample-policy.md בתיקייה ריקה.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#תרגיל הערות

מעתיקים את המדיניות לקובץ טקסט ומתייגים כל שורה באחת מארבע תוויות: [SCOPE], [RULE], [ASK] או [GAP]. התווית ASK מיועדת למקרים שבהם צריך הבהרה מהתוכנית לפני הבדיקה. התווית GAP מיועדת למקרים שבהם המדיניות שותקת על משהו שדרוש לך.

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

1. האם api.example.test מכוסה באותם כללים כמו האתר הראשי, או שהוא צריך בדיקה נפרדת?
2. האם מגבלת הקצב חלה רק על סורקים, או גם על תעבורה ידנית?
3. מה הסטטוס של payments.example.test, ומה עושים אם בדיקה הגיעה אליו בטעות?
4. האם ה-safe harbour מכסה ממצא שחושף נתוני לקוחות?
5. איזה חלק בתנאי החשיפה הוא התחייבות של הבעלים, ואיזה הוא בקשה אליך?

לשאלה 4 אין תשובה בטקסט. מסמנים אותה GAP וכותבים את השאלה שצריך לשלוח לתוכנית.

#הצ׳ק־ליסט לפני הבדיקה

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

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

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

#בדיקת הצ׳ק־ליסט עם סקריפט

יש לשמור את הסקריפט שלמטה בשם precheck.py באותה תיקייה. הוא קורא קובץ טקסט מקומי ולא מתחבר לשום דבר.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

מריצים אותו מ-Git Bash בתיקייה שמחזיקה את שני הקבצים:

python precheck.py checklist.md
echo "exit=$?"

הסקריפט הורץ על מחשב Windows 11 עם Git Bash, עם צ׳ק־ליסט ששורת חשבון הבדיקה בו עדיין אמרה TBD. הפלט היה:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

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

#טעויות נפוצות

• התייחסות לשם התוכנית כאל הסקופ. תוכנית בשם "Example Widget" יכולה לכסות מוצר אחד, כמה חברות, או אף אחת מחברות הבת שעולות בראש. צריך לקרוא את הרשימה.
• בדיקה של נכס משוער או שהתגלגל בירושה. תת־דומיין שניחשת, או כתובת מרשומה ציבורית ישנה, נמצאים מחוץ לסקופ עד שהמדיניות מציינת אותם.
• הרצת סורק במהירות מלאה כי המדיניות לא מזכירה קצב. שתיקה על קצב אינה היתר לרוץ מהר.
• שמירת נתונים אחרי הדוח. עותקים שנשארו על מחשב נייד הם עדיין נתונים של הבעלים, והמדיניות יכולה לדרוש למחוק אותם.
• פרסום מוקדם כי הספק ענה "fixed". צריך לקרוא את תנאי החשיפה ולחכות להם.
• דוח שמוכיח יותר ממה שהיה מותר לאסוף. המזהה ושדה אחד מושחר מוכיחים את הבעיה בדרך כלל לא פחות טוב מ-dump.
• הנחה שה-safe harbour מכסה הכול. הוא מכסה את מה שכתוב בו, עבור המערכות שבהן הוא נוקב.

#איך ממשיכים מכאן

כדאי לתרגל את הרגל הקריאה על תוכניות ציבוריות שמפרסמות את הכללים שלהן. מחזיקים צ׳ק־ליסט אחד לכל תוכנית וקוראים את המדיניות שוב באותו יום של הבדיקה, כי הסקופ משתנה. כדאי לקרוא במלואם את חומרי ה-safe harbour של disclose.io ואת עמוד ה-coordinated disclosure של CISA, וללמוד את ההבדל בין vulnerability disclosure policy, שעשויה לא להציע פרס, לבין תוכנית באג באונטי, שמשלמת על ממצאים. אחר כך אפשר לקרוא איך כותבים את דוח האבטחה הראשון כדי לראות איך ממצא צריך להיראות כשיש הרשאה וגם משהו שנמצא.

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

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

#מקורות

• disclose.io, safe harbour and policy tools: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• U.S. Department of Justice, New Policy for Charging Cases Under the Computer Fraud and Abuse Act (May 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act