לדלג לתוכן

10.6 גילוי אחראי ו bug bounty הרצאה

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

גילוי מתואם של חולשות - Coordinated Vulnerability Disclosure

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

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

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

מודלים של גילוי - disclosure models

בגדול יש שלוש גישות, וכדאי להכיר את כולן כדי לבחור בתבונה:

+----------------------+-------------------------------------------+
| Model                 | What happens                               |
+----------------------+-------------------------------------------+
| Full Disclosure       | Publish everything immediately, no coordination with the vendor. |
|                       | Maximum pressure, but exposes users to a 0-day.   |
+----------------------+-------------------------------------------+
| Coordinated (CVD)    | Report to the vendor, give a time window, then     |
|                       | publish. The professional default.             |
+----------------------+-------------------------------------------+
| Non-Disclosure        | Keep it to yourself or sell it. No fix,        |
|                       | users remain exposed forever.              |
+----------------------+-------------------------------------------+

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

ציר הזמן של גילוי - timelines

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

  • הצוות Project Zero של גוגל עובד לפי מדיניות 90 יום, עם תוספת של 30 יום להפצת התיקון: אם היצרן מוציא תיקון בתוך 90 הימים, הפרטים המלאים מתפרסמים 30 יום לאחר התיקון, כדי לתת למשתמשים זמן להתקין.
  • היוזמה ZDI - Zero Day Initiative של Trend Micro נותנת ליצרנים 120 יום.
  • הארגון CERT/CC נוהג במדיניות של 45 יום כברירת מחדל, עם גמישות.
Day 0            Day 90            Day 90+
Report ---------> Deadline ----------> Publication
  |                |                  |
  | vendor         | develop fix,     | details become
  | acknowledges   | test,            | public,
  | within days    | ship             | CVE assigned

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

דוח טוב וניתן לשחזור - the report

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

מבנה דוח מומלץ לחולשת זיכרון:

Title:         one-line description - bug type + component.
              Example: "Heap buffer overflow in parse_header of libfoo 2.3.1"

Component and version:   product name, exact version number, git commit if known.
Environment:   OS, architecture, compiler and flags, glibc.
Severity:      CVSS score + vector, and a short explanation of the impact.
Description:   what the bug is, where the input comes from, what gets overwritten.
Reproduction:  exact steps + minimal attached crash input.
Root cause analysis: pointer to the code line/function, why the check is missing.
Impact:        crash only? controlled write? RCE? dependent on mitigations?
Suggested fix: patch or a description of the missing check (optional, professional).

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

# minimizing an input AFL found, while keeping the same crash
afl-tmin -i crash_input -o crash_min -- ./target @@

# minimizing source code/text input while keeping the crash condition
creduce ./is_still_crashing.sh testcase.c

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

# build the target with ASan and symbols
gcc -g -fsanitize=address -o target_asan target.c

# run with the minimal crash input
./target_asan crash_min

הפלט של ASan הוא זהב טהור לדוח - הוא נראה ככה, וממנו היצרן מבין הכל:

==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eff5
WRITE of size 16 at 0x60200000eff5 thread T0
    #0 0x4a1b2c in parse_header src/parser.c:142
    #1 0x4a0f1e in handle_input src/main.c:88
0x60200000eff5 is located 5 bytes to the right of 16-byte region
allocated by thread T0 here:
    #0 malloc
    #1 0x4a0e02 in parse_header src/parser.c:130

אם אין לכם קוד מקור (מטרה קלוזד-סורס), מצרפים במקום זאת backtrace מ-gdb או pwndbg עם bt, את מצב האוגרים בזמן הקריסה, ואת מפת הזיכרון. תמיד ציינו במפורש אילו הגנות היו פעילות - הרצתם checksec על הבינארי וצירפתם את התוצאה (NX, ASLR, PIE, canary, RELRO), כי היכולת לנצל תלויה בהן לחלוטין.

הוכחת היתכנות מול חימוש - PoC vs weaponization

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

  • הוכחת היתכנות - PoC: קלט או סקריפט שמדגים את הבאג. בדרך כלל זו קריסה מבוקרת, או הוכחה שיש שליטה ב-RIP, או leak כתובת. המסר הוא "הנה, זה אמיתי וזה חמור".
  • נשק - weaponized exploit: exploit מלא, אמין, שעוקף את כל ההגנות ומשיג RCE יציב על יעדים אמיתיים. המסר הוא "הנה כלי מוכן לתקיפה".

הכלל המקצועי: ליצרן שולחים בדיוק כמה שצריך כדי להוכיח ולתקן, לא יותר. כדי להוכיח heap overflow חמור, פלט ASan שמראה WRITE של 16 בתים מעבר לbuffer מספיק לחלוטין; אתם לא חייבים לצרף chain ROP שמפעילה execve("/bin/sh") על גרסת התפוצה. עודף פירוט לא מזרז את התיקון, ורק מגדיל את הסיכון שהכלי ידלוף.

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

ומעבר לזה יש קו אדום ברור: מכירת 0-day לברוקרים כמו Zerodium או Crowdfense. שם לא מדווחים ליצרן בכלל - החולשה נמכרת ללקוחות (לרוב ממשלתיים) ונשארת חיה. זה השוק האפור, זה חוקי בחלק מהמקומות, אבל זה מנוגד לרוח הגילוי המתואם ומשאיר משתמשים חשופים ביודעין. בקורס הזה הקו שלנו ברור: אנחנו חוקרים כדי לתקן, לא כדי לחמש.

פלטפורמות והיקף - bug bounty

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

  • הפלטפורמות HackerOne, Bugcrowd, Intigriti ו-YesWeHack מארחות תוכניות של יצרנים רבים, כולל כאלה לתוכנה נייטיב ולרכיבי מערכת.
  • החברה Trend Micro מפעילה את ZDI, שקונה חולשות ומטפלת בגילוי המתואם מולכם ומול היצרן במקומכם.
  • התחרות Pwn2Own מזמינה חוקרים להדגים שרשראות exploit מלאות על מטרות אמיתיות (דפדפנים, טלפונים, רכבים, נתבים) בזמן אמת, תמורת פרסים גדולים ותיאום מסודר עם היצרנים.
  • תוכניות של יצרנים ישירות: Apple Security Bounty (עד סכומים של מיליון דולר ומעלה על שרשרת מלאה), התוכניות של Google (למשל Chrome VRP, Android VRP ו-kernelCTF), ה-MSRC של Microsoft, וכן תוכניות של Qualcomm, Samsung ויצרני נתבים.

לפני שאתם נוגעים במשהו, קראו את ה-scope עד המילה האחרונה. ההיקף מגדיר בדיוק אילו מוצרים, גרסאות ורכיבים בתחום, ומה מחוץ לתחום - out of scope. בעולם ה-firmware זה קריטי במיוחד: לעיתים חילוץ ה-firmware עצמו מותר, אבל תקיפה של שרתי הענן של המכשיר אסורה בהחלט. פעולה מחוץ ל-scope לא רק שלא תשולם - היא עלולה להוציא אתכם מהגנת ה-safe harbor של התוכנית ולחשוף אתכם משפטית.

שימו לב גם להבדל בין תוכנית שמשלמת כסף לבין VDP - Vulnerability Disclosure Program, שהיא רק ערוץ דיווח מסודר בלי תשלום. שתיהן לגיטימיות, אבל תדעו למה אתם נכנסים.

איך מוקצה מזהה CVE - CNA

מזהה CVE - Common Vulnerabilities and Exposures הוא השם הרשמי והייחודי של חולשה, בformat CVE-2026-12345. המערכת מנוהלת על ידי הארגון MITRE וממומנת על ידי סוכנות הסייבר האמריקאית CISA. מזהה CVE הוא מה שמאפשר לכל העולם - חוקרים, יצרנים, סורקים - לדבר על אותה חולשה בדיוק.

מי מקצה את המזהים? גופים שנקראים CNA - CVE Numbering Authority. אלה יצרנים וארגונים שקיבלו הרשאה להקצות מזהי CVE בתוך תחום האחריות שלהם. למשל Microsoft, Google, Apple, Red Hat ו-GitHub הם כולם CNA, ומקצים מזהים למוצרים שלהם. אם החולשה שמצאתם היא במוצר של יצרן שהוא CNA, בקשת המזהה עוברת דרכו. אם היצרן איננו CNA, פונים ל-CNA של מוצא אחרון - כיום זו לרוב MITRE עצמה, דרך טופס באתר.

מחזור החיים של רשומת CVE:

RESERVED  ->  identifier reserved, details still confidential (during coordinated disclosure)
              |
PUBLISHED ->  the description, affected versions and references are published on cve.org
              |
ENRICHED  ->  bodies like NVD add a CVSS score and links

על החומרה מדברים בשפה של CVSS - Common Vulnerability Scoring System (גרסאות 3.1 ו-4.0 בשימוש נפוץ). הציון בין 0 ל-10 מחושב מווקטור של מדדים. חולשה שניתן להפעיל מהרשת, בלי הרשאות ובלי אינטראקציה של משתמש, שנותנת שליטה מלאה, מקבלת ציון קריטי. דוגמה לווקטור של RCE קלאסי מרחוק:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  =  9.8 (Critical)

כדאי לדעת לקרוא את הווקטור: ‏AV:N פירושו וקטור רשת, ‏AC:L מורכבות תקיפה נמוכה, ‏PR:N בלי הרשאות נדרשות, ‏UI:N בלי אינטראקציית משתמש, ו-C/I/A:H פגיעה גבוהה בסודיות, שלמות וזמינות.

מקלט משפטי ואחריות החוקר - safe harbor

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

בארצות הברית החוק המרכזי הוא CFAA - Computer Fraud and Abuse Act, שאוסר על "גישה לא מורשית" למחשב. פסק הדין Van Buren משנת 2021 צמצם את הפרשנות הרחבה שלו, ובשנת 2022 משרד המשפטים האמריקאי פרסם מדיניות שלפיה אין להעמיד לדין מחקר אבטחה בתום לב. יש גם את סעיף 1201 ל-DMCA, שאוסר על עקיפת מנגנוני הגנה; ספריית הקונגרס מעניקה כל שלוש שנים פטור מפורש למחקר אבטחה בתום לב, אבל בתנאים. השורה התחתונה: ההגנות קיימות, אבל הן מותנות ב"תום לב" - כלומר בכך שתישארו בגבולות.

מכאן נגזרת רשימת האחריות שלכם, ואלה לא המלצות - אלה התנאים שמשאירים אתכם בצד הבטוח:

  • הישארו בתוך ה-scope. אל תיגעו במערכות, בחשבונות או בנתונים שלא הוגדרו במפורש כמותרים.
  • אל תגרמו נזק. אל תמחקו נתונים, אל תפילו שירות (DoS), ואל תשנו מצב מערכת יותר ממה שנדרש להוכחה.
  • מזערו חשיפת מידע. אם נתקלתם בנתונים אישיים, עצרו מיד, אל תחלצו יותר משורה אחת להוכחה, ואל תשמרו עותק. הדבר נכפף גם לרגולציית פרטיות כמו GDPR.
  • אל תסתעפו. מציאת חולשה אחת לא נותנת רשות לנצל אותה כדי לחדור עמוק יותר לרשת.
  • דווחו מיד, ובלעדיות. אל תמכרו במקביל, אל תפרסמו לפני הזמן, ואף פעם אל תדרשו תשלום בתמורה לשתיקה - זו סחיטה, לא bug bounty.

טיפ מעשי: כשאתם ניגשים לתוכנית, חפשו נוסח safe harbor מפורש. יש תקן קהילתי לזה (הפרויקט disclose.io), ותוכנית עם safe harbor ברור מתחייבת לא לתבוע אתכם כל עוד פעלתם בגבולות ובתום לב. אם אין לחברה תוכנית ואין safe harbor, שקלו לעבוד דרך מתאם צד-שלישי כמו CERT/CC, ותמיד תעדו הכל בכתב.

בניית פורטפוליו מחקרי - portfolio

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

  • רשומות CVE על שמכם. מזהה CVE עם קרדיט אליכם הוא שורת קורות חיים שכל מגייס בתחום מבין מיד.
  • כתבות טכניות - writeups בבלוג. אחרי שהתיקון יצא, פרסמו ניתוח מעמיק: איך מצאתם, מה היה שורש הבאג, ואיך בניתם את הexploit. זה מה שבאמת מלמד את הקהילה ומוכיח עומק.
  • הרצאות בכנסים כמו DEF CON, Black Hat או כנסים מקומיים. הצגה של מחקר מקורי היא קפיצת מדרגה במוניטין.
  • קוד פתוח: כלים, patches ותרומות פומביות ב-GitHub שמראים שאתם יודעים גם לתקן, לא רק לשבור.

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

סיכום

בשיעור הזה עברנו על הצד המקצועי של מציאת חולשות אמיתיות:

  • גילוי מתואם - CVD הוא ברירת המחדל: מדווחים ליצרן, נותנים חלון זמן, ואז מפרסמים.
  • ציר הזמן נע סביב 90 יום כנורמה (עם וריאציות כמו 90+30 של Project Zero ו-120 של ZDI).
  • דוח טוב הוא ניתן לשחזור: קלט מינימלי, פלט ASan או backtrace, ניתוח שורש, ומצב ההגנות מ-checksec.
  • הוכחת היתכנות מול חימוש: שולחים ליצרן בדיוק כמה שצריך כדי להוכיח ולתקן, לא exploit מחומש למיליוני מכשירים.
  • מזהי CVE מוקצים על ידי CNA (יצרנים או MITRE), והחומרה מבוטאת בציון CVSS ובווקטור שלו.
  • מקלט משפטי - safe harbor מגן עליכם רק כל עוד אתם בתום לב: בתוך ה-scope, בלי נזק, בלי הסתעפות, בלי סחיטה.
  • פורטפוליו נבנה מ-CVE-ים, writeups, הרצאות ותרומות קוד - וכולם יחד בונים את המוניטין, שהוא ההון האמיתי במקצוע.