TL; DR
@szc-ft/mcp-szcd-client הוא לקוח Model Context Protocol (MCP) שפורסם ב-npm וקובע אוטומטית תצורה של עוזרי קידוד של בינה מלאכותית - סוג חבילת הדבק שמפתח מתקין כדי שסוכן IDE יוכל לתקשר עם שירות ספריית רכיבים. יש לו היסטוריית הפצה ארוכה ונראית רגילה (גרסאות 71) ושלב התקנה שפיר. שום דבר לאחר ההתקנה לא נוגע בפרטי הגישה.
התנהגות קריאת האישורים נמצאת שכבה עמוקה יותר, במיומנות MCP משולבת הנקראת local-browser-testכאשר המיומנות הזו connect() ריצות שגרתיות, זה מפעיל _decryptCredentials() — אשר מפענח כל סיסמה שמורה בפרופיל Chrome/Edge המקומי (כל האתרים, לא היישום הבודד שבדיקת דפדפן תתמקד בו) באמצעות ממשק ה-API של Windows Data Protection API (DPAPI) ו-AES-256-GCM. הסט המפוענח נכתב בטקסט רגיל אל ~/.szcd-mcp/deps/decrypted-creds.json ומוחזר בתוך תוצאת כלי ה-MCP של המיומנות, אשר זורמת לשרת ה-MCP המרוחק המוגדר כברירת מחדל של החבילה, mcp.szcd-mcp.top.
זוהי תבנית שרשרת אספקה שכדאי לציין בשמה: היכולת הרגישה אינה נמצאת ב-install hook (היכן שרוב הסורקים והבודקים מחפשים) אבל במיומנות MCP שמופעלת רק כאשר מפעיל מכוון את הכלי לדפדפן הפועל שלו. אנחנו קוראים לזה דליפת מיומנותMEW מסווג @szc-ft/mcp-szcd-client (גרסאות 0.38.0 ו 0.39.0) כזדוני.
הערת מועד — מיומנות MCP: חבילה עצמאית של הוראות וסקריפטים של עזר ששרת MCP חושף לסוכן בינה מלאכותית כיכולת ניתנת לקריאה. הסוכן מפעיל אותו ככלי; הסקריפטים רצים על מכונת המפתח.
אנטומיה של התקפה
החבילה מציגה שני פנים שונות מאוד.
הפרצוף שהמבקר רואה קודם הוא נתיב ההתקנה. המניפסט מצהיר לאחר התקנה: סקריפטים של צומת/postinstall.js, והסקריפט הזה עושה בדיוק את מה שקובץ ה-README אומר: הוא מבצע חיווי MCP אינטגרציות לתוך IDEs והתקנת חבילת אחים, שרת szc-ft/sketch-mcpזה אף פעם לא מגיע לקוד האישור. סורק שעוצר בהתקנה hooks — המקום בעל הסימן הגבוה ביותר מבחינה היסטורית לחפש — רואה כלי פיתוח נקי ובלתי יוצא דופן. חבילה זו למעשה הוערכה כבטוחה בבדיקה קודמת.
הפנים שחשובות מושג רק באמצעות המיומנות הכלולה. השרשרת:
- מפתח מנהל את בדיקת דפדפן מקומית מיומנות כנגד מופע של Chrome/Edge הם התחילו עם פורט לניפוי שגיאות מרחוק. זוהי הדרך המתועדת להשתמש במיומנות.
- המיומנות להתחבר () (lib/browser-engine.js) שיחות _decryptCredentials() בשורה 246.
- _decryptCredentials() שיחות decryptAllPasswords({filter: '%' }). ה % המסנן הוא הפרט שהופך נוחות בדיקה לקציר: הוא תואם כל מקור מאוחסן ולא את האתר הבודד הנבדק.
- lib/decrypt-passwords.js קורא את הדפדפן os_crypt מפתח מוצפן, פועל powershell … ProtectedData::Unprotect (DPAPI) כדי לשחזר את מפתח ה-AES, לאחר מכן AES-256-GCM מפענח כל אישור שנשמר.
- הסט המלא המפוענח נכתב אל ~/.szcd-mcp/deps/decrypted-creds.json בטקסט ברור ומוחזר כ- של המיומנות כלי MCP תוֹצָאָה.
- תוצאה זו חוזרת דרך ערוץ ה-MCP לשרת ברירת המחדל של החבילה, mcp.szcd-mcp.top — אותו מארח שתועד ב-README וב- scripts/lib/common.js.
הערה קצרה מדוע שלב 4 עובד בכלל. ב-Windows, Chrome ו-Edge אינם מאחסנים סיסמאות שנשמרו בטקסט רגיל: כל אישור מוצפן עם מפתח AES-256-GCM, והמפתח עצמו אטום באמצעות DPAPI, אשר קושר אותו לחשבון המשתמש הנוכחי. לכן, שחזור סיסמה דורש שני צעדים - ראשית. ProtectedData::UnprotectedData כדי לשחזר את מפתח ה-AES (אשר מצליח מכיוון שהקוד פועל כמשתמש המחובר, בדיוק ההקשר שמספק הטרמינל של המפתח), לאחר מכן פענוח GCM של כל בלוב מאוחסן שנקרא מהדפדפן os_cryptחנות מוגנת. זה מובן היטב, לא מקוון ושקט: אין בקשת סיסמה ראשית, אין אינטראקציה עם דפדפן, אין מעבר הלוך ושוב לרשת עד להעברת התוצאות. זהו אותו פרימיטיבי שמשתמשים בו רבים מגנבי מידע על סחורות - החידוש כאן הוא רק העטיפה הנושאת אותו.
המפענח אינו מקריזה מגיע שלוש פעמים - תחת standard-מְיוּמָנוּת/, סיומת קוד פתוח/, ו סיומת qwen/ — עותק אחד לכל משטח נתמך של עוזר בינה מלאכותית, כך שהיכולת עוברת עם העוזר שהמפתח חיבר.
הניגוד לבדיקת דפדפן אוטומטית לגיטימיתlogin זה כל הסיפור. עוזר בדיקה אמיתי מפענח את האישורים עבור ה- אחד יישום זה הוא תרגולcising, משתמש בו תוך כדי תהליך, ולעולם לא שומר אותו או מעביר אותו. כאן השגרה מפענחת הכל, כותבת אותו לדיסק בצורה צלולה, ומחזירה אותו מעבר לגבול הרשת לשרת מרוחק.
ציר זמן וטריגר
שתי התנהגויות חשובות להבנת חשיפה.
הטריגר הוא על ידי הצטרפות, לא אוטומטי. התקנת החבילה אינה קוראת שום אישורים. הפענוח פועל רק כאשר מפתח מפעיל באופן פעיל את בדיקת דפדפן מקומית מיומנות מול דפדפן שהם הפעילו במצב ניפוי שגיאות מרחוק. זה מצמצם באופן משמעותי את מי שנפגע בהשוואה ל- לאחר ההתקנה מטען שיורה על כל אחד התקנת npm.
האריזה בוגרת, לא חד פעמית. המו"ל הוציא 71 גרסאות ומתחזק מגוון רחב יותר @szc-ft חבילת MCP של ספריית רכיבים. מפענח האישורים קיים בשתי הגרסאות המסומנות (0.38.0 ו-0.39.0) עם טביעת אצבע זהה, המופעלת מאותו מנוע-דפדפן.js:246 נקודת כניסה. החבילה נותרה פעילה ב-npm נכון למועד כתיבת שורות אלה.
השילוב הזה - מפרסם מבוסס, שלב התקנה שפיר ויכולת שמופעלת רק תחת תהליך עבודה ספציפי של הצטרפות - הוא בדיוק הסיבה שמסווג אוטומטי ניבא "בטוח" וסקירה קודמת אישרה. ההתנהגות נפתרת רק תחת קריאה ידנית של סקריפטי העזר של המיומנות.
אינדיקטורים לפשרה
ביקורת של הסנגורים כלי עבודה MCP צריך לטפל ב מְיוּמָנוּת הספרייה כנכללת בהיקף, לא רק בסקריפטים של המניפסט וההתקנה.
ייחוס והתנהגות נצפית
אנחנו מתארים התנהגות, לא מניע.
החבילה מתפרסמת תחת חשבון npm מבוסס עם חבילה מרובת קוהרנטית @szc-ft חבילת MCP והיסטוריית גרסאות ארוכה. אין ערוץ פקודה ובקרה סודי ייעודי: האישורים המפוענחים מוחזרים דרך שרת ה-MCP המתועד של החבילה, mcp.szcd-mcp.top, ולא לנקודת שחרור אנונימית. שלב ההתקנה הוא באמת שפיר.
מה שמעביר את זה מ"תכונת נוחות אגרסיבית" לסיווג זדוני הוא השילוב הנצפה של היקף ויעד: השגרה מפענחת את כל פרטי הגישה של הדפדפן שנשמרו במקום היישום הבודד שהבדיקה הייתה מפעילהcisכלומר, שומר אותם בדיסק בטקסט רגיל, ומשדר אותם מהמארח דרך ערוץ ה-MCP. בדיקת דפדפן אוטומטית-login תכונה שמתנהגת כך לא תהיה ניתנת להבחנה, למעשה, מאיסוף אישורים - והאפקט הוא מה שעל ההגנה להסיק לגביו.
אנו מציינים בכנות שהטריגר הוא הצטרפות (opt-in) והמפרסם נקבע; שתי העובדות מופיעות ברשומה לעיל. אף אחת מהן לא משנה את התוצאה הנצפית עבור מפתח שמפעיל את המיומנות: הסיסמאות השמורות עבור כל אתר בפרופיל הדפדפן שלו עוזבות את המחשב.
השפעה, מגמות והנחיות למגינים
SkillLeak הוא אירוע של חבילה אחת, אבל משטח המסירה שהוא משתמש בו הוא העיקר.
רפלקס שרשרת האספקה של התעשייה מכוון לביצוע בזמן ההתקנה: התקנה מוקדמת/לאחר ההתקנה hooks, משואות בלבול תלות, טיפוסקווטים עם מטען ב index.js. MCP משנה את הגיאומטריהחבילת MCP יכולה לשלוח מניפסט ושלב התקנה שהם נקיים לחלוטין תוך נשיאת ההתנהגות התוצאתית שלהם בתוך מְיוּמָנוּת — חבילה שסוכן הבינה המלאכותית מפעיל מאוחר יותר, בהוראת המפתח עצמו, כנגד משאבי המפתח עצמו. היכולת משתלבת עם שילוב העוזר ונשארת רדומה עד שתהליך עבודה שנראה רגיל ("הפעל את בדיקת הדפדפן") מפעיל אותה.
עבור צוותים המאמצים כלי MCP:
- מיומנויות ביקורת, לא רק מניפסטים. הרחב את סקירת החבילה אל מיומנויות/, *-הַרחָבָה/, וספריות מקבילות. ייתכן שהקוד הרגיש ביותר לעולם לא יופיע ב-install hook.
- שימו לב לניפוח היקף. יכולת שטוענת למטרה צרה (לבדוק אפליקציה אחת) אך פועלת באופן רחב (מסנן: '%' על פני כל המקורות המאוחסנים) מהווה דגל אדום ללא קשר לכוונה.
- התייחס לתוצאות כלי MCP כערוץ יציאה. נתונים המוחזרים מ-skill יוצאים מהמארח לכל שרת MCP שעבורו הלקוח מוגדר. שמור את היעדים הללו כפי שהיית עושה עם כל חיבור יוצא.
- סקירה מחדש של גרסאות מוגברות של חבילות MCP "מהימנות". מפיץ מבוסס והיסטוריית הפצה ארוכה אינם תחליף לקריאת הקוד שמגיע בכל גרסה - כפי שמדגים מקרה זה, אשר הופך הערכת בטיחות קודמת.
באופן קונקרטי, שלוש בדיקות בעלות נמוכה היו אמורות להופיע בחבילה זו לפני שמפתח הפעיל את המיומנות. ראשית, סריקת תוכן של ספריות מיומנויות לצורך גישה למאגר אישורים מקומי - הפניות ל os_crypt, נתונים מוגנים/DPAPI, או של דפדפן Login נתונים קובץ - מסמן את היכולת ללא קשר לאיזה וו התקנה קיים. שנית, בדיקת היקף על כל שגרת פענוח/קריאה שמקבלת בורר תווים כלליים (wildcard selector)מסנן: '%' ומקבילים) במקום מזהה כבול לוכד את אינפלציית המבחן-לקציר. שלישית, הבדל קבוצת המארחים שחבילה יכולה להגיע אליה (כאן, mcp.szcd-mcp.top) כנגד היעדים שהתיעוד שלו טוען שצריך להפוך את ערוץ תוצאות ה-MCP לנקודת יציאה ניתנת לביקורת. אף אחד מאלה לא דורש הרצת קוד.
פענוח אישורים באמצעות DPAPI ו- os_crypt זוהי טכניקה ישנה; אספקתה באמצעות מיומנות של סוכן בינה מלאכותית שמופעלת רק תחת זרימת עבודה של opt-in היא המעטפת החדשה. צפו ליותר מדפוס יכולת-במיומנות ככל שכלי MCP יתרחבו, והתאימו את היקף הסקירה בהתאם.
