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

את המחקר פרסם קוונטין קייזר ב-16 באוקטובר, במקביל להרצאה שנתן באותו יום בכנס Hexacon בפריז. החולשה יושבת ביישום הפרטי של Broadcom לתקן 802.11, ברכיב שמטפל בהתחברות WPS, ולפי קייזר היא שם לפחות מאז 2010. ברודקום הוציאה ב-2018 תיקון חלקי בשקט, המליצה ללקוחותיה לעבור לרכיב אחר, וסירבה להקצות לחולשה מספר CVE. בהמשך נראה מה בדיוק שבור באותו מפרסר, מה קייזר הצליח לעשות איתו על ציוד של ספקי אינטרנט אמיתיים, ולמה היעדר ה-CVE הוא דווקא החלק שמסביר למה כל כך הרבה יצרנים לא תיקנו.

אז למה המפרסר הזה מקשיב עוד לפני שיש סיסמה?

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

ברודקום לא מוכרת נתבים. היא מוכרת שבבים וערכת פיתוח, והיצרנים (OEM) מהדרים את הקוד שלה לתוך הקושחה של המוצרים שלהם, שספקי האינטרנט מחלקים אחר כך למנויים. בגלל השרשרת הזאת באג אחד אצל ברודקום מתפזר על עשרות מותגים. קייזר מחלק את המכשירים לשתי משפחות: שבבים שמריצים את מערכת ההפעלה eCos (BCM3380, BCM3383, BCM33834), ושבבים שמריצים לינוקס (BCM3390, BCM63xx, BCM65xx, BCM68xx). ההבדל בין השתיים הוא שיקבע בסוף מי יכול לקבל תיקון בכלל.

השדה שהתוקף ממלא בעצמו

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

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

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

מה הוא הדגים על הציוד של ספקים בבלגיה

קייזר בדק את החולשה על ציוד של שלושה מתוך ארבעת ספקי האינטרנט בבלגיה, והראה שהיא קיימת ונצילה בכולם: Proximus (BBOX 3V+), VOO (Netgear CG3100 ו-CG3700, Technicolor 7210 ו-CGA4233) ו-Orange (Askey TCG3000). את Telenet הוא לא הצליח לבדוק כי לא השיג מכשיר, אז לגביו הוא נמנע מלקבוע.

שתי ההדגמות שפרסם נבדלות זו מזו במה שקורה אחרי שהקוד רץ. בראשונה, על ה-Askey של Orange, המטען ניגש ל-NVRAM (הזיכרון הקבוע שבו הנתב שומר את ההגדרות שלו, כולל מפתח הרשת) ומשדר את המפתח בחזרה לתוקף דרך 802.11. בשנייה, על ה-BBOX3V+ של Proximus מתוצרת Sagemcom, הוא פתח reverse shell שרץ כולו על מסגרות Wi-Fi. למי שאמור להגן על הרשת זה החלק הלא נוח: אין חיבור יוצא לאינטרנט, אין שרת שליטה ובקרה (C2, השרת שדרכו תוקף שולח פקודות לקוד שהשתיל) בענן, ולכן אין גם תעבורה חשודה שתופיע בלוג של חומת האש.

עד כאן מה שאפשר לעשות עם החולשה. החלק שמסביר למה היא עוד חיה ב-2026 הוא אחר לגמרי.

16 שנה, תיקון חלקי אחד, ואפס CVE

את הדיווח הראשון שלח קייזר ל-PSIRT של ברודקום ב-18 ביולי 2026, על שבבי ה-eCos, ודיווח שני ב-27 בחודש על שבבי הלינוקס. ב-28 ביולי ברודקום ענתה שקיים תיקון, ושאם הוא מוצא מכשירים פרוצים הוא מוזמן לפנות ליצרן שלהם ולבקש ממנו ליצור קשר איתה. למחרת היא סירבה לרשום CVE, וסירבה גם להעביר לו עותק של ההודעה שלטענתה נשלחה ליצרנים דרך פורטל הלקוחות שלה. ב-4 באוגוסט הוא פתח תיק ב-CERT/CC, והתיק נסגר באותו יום עצמו. (ברודקום היא עצמה CNA, גוף שמוסמך להקצות מספרי CVE למוצרים שלו, כך שההחלטה לא להקצות מזהה הייתה שלה בלבד, ול-CERT/CC לא נשאר מה לעשות.)

לפי קייזר, ברודקום השיבה שהיא מכירה את הבאג מאז 2018 ושקיבלה עליו מידע גם מגורמים חיצוניים אחרים, אבל לא פרסמה עליו דבר. "וזו כנראה הסיבה שכל כך הרבה יצרנים לא תיקנו", הוא כותב. התיקון שכן יצא ב-2018 היה חלקי, והפתרון שברודקום המליצה עליו הוא מעבר ל-hostapd, יישום קוד פתוח של אותו שלב בהתחברות. למכשירים על בסיס eCos אין מסלול מעבר כזה, ולכן קייזר מגדיר אותם forever day, חולשה שלא תתוקן לעולם. בשבבי הלינוקס ההחלפה אפשרית, אבל רק אם היצרן בוחר לעשות אותה.

קייזר עבד לפי מדיניות גילוי של 90 יום, והשעון התחיל לרוץ ב-18 ביולי. ב-15 באוקטובר, יום לפני הפרסום, אף אחד מהמכשירים הבלגיים שבדק עוד לא קיבל תיקון. חשבון אורך החיים של הבאג יוצא יבש: קוד מ-2010, תיקון חלקי מ-2018, ומכשירים שעדיין נמכרים ומופעלים ב-2026. 16 שנה על המדף.

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

כמה מכשירים, איך בודקים, ולמי זה שווה משהו

"מיליונים" הוא המספר שקייזר נוקב, והוא לא מתיימר לדייק. את ההערכה לבלגיה הוא בנה בחשבון מפית, לפי נתונים של הרגולטור הבלגי IBPT והודעות של הספקים על דגמים שיצאו לאורך השנים, ומייחס לה בעצמו רמת ביטחון בינונית: כ-850 אלף נתבים חשופים אצל Proximus מתוך 2.3 מיליון מנויים, כחצי מיליון בציוד הישן של VOO, וכ-210 אלף אצל Orange Belgium. מול Telenet, עם 1.75 מיליון מנויים, הוא רשם סימן שאלה. את המספרים האמיתיים, הוא כותב, רק הספקים יכולים לפרסם.

רשימת הדגמים שכן זוהו רחבה בהרבה מבלגיה. היא כוללת את קו המוצרים לעסקים קטנים של Cisco (הנתבים RV110W, RV130W, RV215W ו-RV340W, וסדרת נקודות הגישה WAP), את סדרת G-240W של Nokia שפרוסה אצל עשרות מפעילים בעולם, ציוד TP-Link, ZTE F680, Zyxel, Huawei, Sagemcom, Technicolor, Arcadyan, ו-NetComm שמותקן אצל ספקים אוסטרליים. קייזר מדגיש שהרשימה לא ממצה, ושלהערכתו המלאי האמיתי כולל אלפי דגמים. ספק אינטרנט ישראלי לא מופיע בה, אבל חלק ממשפחות הציוד שבה נמכרות גם בישראל.

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

אז למי חולשה כזאת שווה משהו? לא לקמפיין המוני. היא דורשת קרבה פיזית, ובדיוק בגלל זה היא מתאימה לתוקפים ממוקדים. Volexity תיארה ב-2024 את מתקפת השכן הקרוב, שבה קבוצה רוסית נכנסה לארגון דרך רשת ה-Wi-Fi של ארגון אחר שישב בסמוך אליו. מיקרוסופט פרסמה ביולי 2026 את CaptiveCrunch, קמפיין שהיא מייחסת לתת-קבוצה של Midnight Blizzard, שבו נפגעו רשתות Wi-Fi של עסקים בתחום האירוח כדי להגיע לאנשים בנסיעות עבודה. נתב שאפשר להשתלט עליו מהמדרכה, בלי להשאיר אחריו חיבור יוצא, הוא בדיוק החוליה שמתקפה כזאת צריכה.

מה זה אומר בפועל

אם הנתב שלכם הגיע מספק האינטרנט, אין לכם מה לתקן לבד, ומה שכן אפשר זה לשאול את הספק אם הדגם שלכם ברשימה ואם יצאה לו קושחה מעודכנת. מי שמנהל רשת קטנה עם ציוד Cisco מסדרות WAP ו-RV, עם TP-Link או עם Zyxel, יכול להצליב את הדגמים מול הרשימה של קייזר ולהריץ את הסקריפט מול נקודות הגישה בפועל. את מתג ה-WPS בממשק הניהול אל תסמנו כפתרון, כי לפי עמוד השאלות והתשובות של המחקר כיבוי ההגדרה לא בהכרח מוציא את המפרסר מהתמונה. ולמכשירים שרצים על eCos, שאין להם מסלול מעבר ל-hostapd, ההמלצה המעשית היחידה היא להחליף אותם.