איזה תהליך VPN נוגע בממצא הפגיעות הזה?

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

הסדר חשוב: קודם הרכיב, אחר כך ההודעה, ולבסוף התיקון.

הדוח מציין פורט, לא תוכנית

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

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

מהו למעשה הבנייה הפועלת

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

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

הודעות מתארות מוצרים, גרסאות ולפעמים תנאים נדרשים, ושלושת השדות האלה לא תמיד תואמים לגרסת חבילה. הודעת Heartbleed של OpenVPN מאפריל 2014 היא דוגמה היסטורית שימושית, כי היא מפרידה בין מהדורות Access Server שנפגעו לבין שירותי האינטרנט ודמוני ה-VPN, שהיו להם חשיפה שונה. הלקח הוא לקרוא איזה רכיב הטקסט מכסה, ולא להתאים את המילה OpenSSL לפי תבנית.

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

יישוב המחלוקת ואז סגירת החשיפה

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

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

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