חזרה לכל המאמרים
    eMudhra: מפתחות זעירים, בעיית אמון גדולה
    AI SecurityTLSPKISupply ChainDeveloper Tools

    eMudhra: מפתחות זעירים, בעיית אמון גדולה

    Y

    Yoni Fraimorice

    שיתוף:

    הדפדפן שלכם יכול לדחות תעודה מסוכנת בזמן ש-Git, ‏Python או סוכן קוד מבוסס AI באותו מחשב עדיין מקבלים אותה. תקרית eMudhra מראה למה "עדכנתי את Chrome" אינה תגובה מלאה לכשל של רשות אישורים.

    ב-17 באוקטובר דיווח החוקר Wayne על שמונה מפתחות פרטיים שניתנים לשחזור, השייכים לרשויות אישורים ביניים של eMudhra. ‏Mozilla אימתה את החולשה באופן עצמאי. שש רשויות נועדו ל-TLS, שמגן על חיבורי HTTPS. שתיים נועדו לחתימת קוד.

    כעת יש התפתחויות חדשות. עדכון Apple מ-10 בנובמבר מתקן פער בכלי שורת הפקודה של macOS. ובדוח התקרית המלא שפרסמה לאחרונה, eMudhra מתארת גם את הכשל המקורי וגם בעיות נוספות בטיפול במפתחות RSA.

    מה בעצם נשבר

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

    במקרה הזה, כל שמונת המפתחות הפרטיים הפגועים מסוג P-384, המבוססים על עקומים אליפטיים, היו מספרים שלמים קטנים מ-256, לפי החקירה של Mozilla. מפתח שהיה אמור להיבחר מתוך טווח עצום הצטמצם לקבוצה זעירה של אפשרויות.

    אפשר היה לשחזר את המפתחות מתוך התעודות הציבוריות. לא היה צורך לפרוץ לשרת. זו לא הייתה שבירה של P-384 או של הצפנת TLS.

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

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

    רכיב אבטחה ייעודי לא הציל את התהליך

    מקור המפתחות בטקס יצירה מ-30 באפריל 2025. לפי הדוח המלא של eMudhra, רכיבי אבטחת החומרה שלה, HSM, יצרו את המפתחות המקוריים כראוי.

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

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

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

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

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

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

    בוטל לא תמיד אומר נדחה

    לפי אתר התקרית הקהילתי, ‏Firefox ו-Chrome חסמו את התעודות הפגועות ב-17 באוקטובר, הפלטפורמות של Microsoft ב-20 באוקטובר, ומוצרי Apple ב-22 באוקטובר.

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

    Apple היא דוגמה טובה. Safari כבר היה מוגן, בזמן ש-Git, ‏curl ו-Python שסופקו עם המערכת עדיין קיבלו את השרשראות הפגועות. העדכון מ-10 בנובמבר מציין את macOS ‏27.2.1, ‏26.7.3 ו-15.8.3 כגרסאות שמתקנות את הבעיה בכלי הפיתוח. ההנחיות של Apple קוראות כעת לעדכן את macOS.

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

    אין ניצול ידוע אינו הוכחה שלא הייתה חשיפה

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

    אתר התקרית מדווח שלא היו רשומות Certificate Transparency עבור רשויות הביניים האלה לפני החשיפה. CT דורש רישום ציבורי של תעודות. זו הגנה חשובה בדפדפנים שאוכפים את הדרישה.

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

    חשוב לשמור על ההבחנה: שחזור המפתחות אומת; המקורות האלה לא ביססו שימוש זדוני לפני החשיפה.

    למה צוותי AI צריכים להתעניין

    זו לא הייתה חולשה במודל AI. אבל סוכני AI תלויים באותו אמון ברשת כמו תוכנות אחרות.

    חשבו על סוכן קוד שמשכפל מאגר, מוריד חבילה ופונה ל-API של מודל. הפעולות האלה עשויות להשתמש ב-Git, במנהל חבילות ובסביבת הרצה של Python או Node.js, עם מסלול אימות תעודות שונה בכל אחד מהם.

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

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

    בדקו את החיבור שהאפליקציה באמת משתמשת בו

    אתר התקרית מספק כתובות בדיקה ציבוריות, כולל שרשראות ללא רישום ב-CT:

    bash
    curl --connect-timeout 10 --max-time 15 https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl --connect-timeout 10 --max-time 15 https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

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

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

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

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

    מקורות

    תמונת פתיחה: Small padlock with three keys in Holma Marina, צילום של W.carter ‏(Ann-Sophie Qvarnström), מ-15 באוגוסט 2021. ברישיון CC BY-SA 4.0. התמונה הוקטנה מ-4629 על 3086 ל-1920 על 1280 פיקסלים ונדחסה כ-JPEG; הגרסה המעובדת מופצת באותו רישיון. זהו צילום ארכיוני להמחשת מפתחות ואמון. הוא אינו מציג ציוד של eMudhra או ראיה לתקרית. אין בכך הבעת תמיכה.

    שיתוף: