בלינוקס, חשבון שאסור להתחבר אליו בסיסמה מסומן בכוכבית בודדת במקום הסיסמה המוצפנת שלו. זה עובד מפני שאין סיסמה בעולם שההצפנה שלה מחזירה כוכבית. Özgün Kültekin, חוקר מחברת Wakefield, מצא שיש בכל זאת דרך אחת להגיע לכוכבית: לשלוח סיסמה ארוכה מ-256 תווים. בחלק מהפצות הלינוקס הפונקציה שמצפינה את הסיסמה לא מתמודדת עם קלט כזה, נכשלת, ומחזירה בעצמה כוכבית. השרת משווה את התוצאה לערך השמור, רואה שתי כוכביות זהות, ומכניס את מי שהתחבר.

מה קרה

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

התנאים צרים. צריך הפצה שמבוססת על ספריית musl, כמו Alpine Linux, OpenWrt, Buildroot ו-Yocto, צריך ש-PAM יהיה מנוטרל (ברירת המחדל בחבילת openssh-server של Alpine), צריך שהתחברות בסיסמה תהיה מופעלת, וצריך שבמערכת יהיה גם חשבון חסום וגם חשבון אחר עם סיסמה תקינה. Kültekin, שהריץ כ-17,600 בדיקות אימות מול תצורות שונות, מצביע על נקודה לא נוחה: בדימויי הענן הרשמיים של Alpine ל-AWS ול-Azure יש חשבון בשם alpine שמורשה להריץ פקודות בהרשאות root בלי סיסמה.

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

למה זה חשוב לכם

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

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

מה עושים?

עדכנו את OpenSSH לגרסה 10.6p2. ב-Alpine החבילות המתוקנות יצאו לגרסאות 3.21.10, 3.22.8, 3.23.8 ו-3.24.4, והפקודה היא apk upgrade openssh.

אם אתם לא יכולים לעדכן עכשיו, כבו התחברות בסיסמה: הוסיפו PasswordAuthentication no להגדרות שרת ה-SSH והפעילו אותו מחדש. התחברות במפתח תמשיך לעבוד.

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

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

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