בעיות של מערכות בקרת כניסה אוטונומיות - היכן שהן לא היו צפויות

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

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

אבל מאז שהקורא ראה את זה, זה אומר שהמפתח עומד באחד מהפרוטוקולים על גבי תקן ISO 14443 (הידוע בשם Near Field Communication, 13,56 MHz). הניקיון נשכח מיד, מכיוון שראיתי הזדמנות להיפטר לחלוטין מערך המפתחות ולשמור את מפתח הכניסה בטלפון שלי (הדירה מצוידת כבר מזמן במנעול אלקטרוני). לאחר שהתחלתי ללמוד, גיליתי שמתחת לפלסטיק מסתתר תג NFC של Mifare 1k - אותו דגם כמו בתגים ארגוניים, כרטיסי הובלה וכו'. ניסיונות להיכנס לתוכן הסקטורים לא הביאו הצלחה בתחילה, וכאשר המפתח נפצח לבסוף, התברר כי נעשה שימוש רק בסקטור ה-3, וה-UID של השבב עצמו שוכפל בו. זה נראה פשוט מדי, והתברר שכן, ולא תהיה כתבה אם הכל ילך בדיוק כמתוכנן. אז קיבלתי את חלקי המפתח, ואין בעיות אם אתה צריך להעתיק את המפתח למפתח אחר מאותו סוג. אבל המשימה הייתה להעביר את המפתח למכשיר נייד, וזה מה שעשיתי. כאן התחיל הכיף - יש לנו טלפון - SE iPhone עם מבוסס iOS 13.4.5 Beta build 17F5044d וכמה רכיבים מותאמים אישית להפעלה חופשית של NFC - לא אתעכב על זה בפירוט בגלל כמה סיבות אובייקטיביות. אם תרצה, כל הנאמר להלן תקף גם למערכת אנדרואיד, אך עם כמה הפשטות.

רשימת משימות לפתרון:

• גש לתוכן המפתח.
• יישם את היכולת לחקות מפתח על ידי המכשיר.

אם עם הראשון הכל היה פשוט יחסית, אז עם השני היו בעיות. הגרסה הראשונה של האמולטור לא עבדה. הבעיה התגלתה די מהר - במכשירים ניידים (או iOS או אנדרואיד) במצב אמולציה, ה-UID הוא דינמי, וללא קשר למה שקשור לתמונה, הוא צף. הגרסה השנייה (רוץ עם זכויות משתמש-על) תיקנה בצורה נוקשה את המספר הסידורי על הגרסה שנבחרה - הדלת נפתחה. עם זאת, רציתי לעשות הכל בצורה מושלמת, ובסופו של דבר הרכבתי גרסה שלמה של האמולטור שיכולה לפתוח את ה-Mifare dumps ולחקות אותם. נכנעתי לדחף פתאומי, החלפתי את מפתחות המגזר לשרירותיים וניסיתי לפתוח את הדלת. והיא… נפתח! לאחר זמן מה הבנתי שהם נפתחים כל דלתות עם מנעול זה, גם כאלו שהמפתח המקורי לא התאים להן. בהקשר זה, יצרתי רשימה חדשה של משימות להשלמת:

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

לאחר שוחחתי עם מהנדס בחברת הניהול, למדתי שמשתמשים בבקרי Iron Logic z5r פשוטים ללא חיבור לרשת חיצונית.

קורא CP-Z2 MF ובקר IronLogic z5r
קיבלתי סט ציוד לניסויים:

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

צילום מסך של תהליך האמולציה במכשיר

... והבקר מאותת שהגישה ניתנה.

המשמעות היא שהבעיה טמונה בתוכנה של הבקר או של הקורא. בואו נבדוק את הקורא - הוא עובד במצב iButton, אז בואו נחבר את לוח האבטחה של Bolid - נוכל לראות את נתוני הפלט מהקורא.

הלוח יחובר מאוחר יותר באמצעות RS232

באמצעות השיטה של ​​בדיקות מרובות, אנו מגלים שהקורא משדר את אותו קוד עם במקרה של כשל בהרשאה: 1219191919

המצב מתחיל להתבהר, אבל כרגע לא ברור לי למה הבקר מגיב בחיוב לקוד הזה. יש הנחה שכאשר בסיס הנתונים התמלא - בטעות או בכוונה הוצג כרטיס עם מפתחות סקטור אחרים - הקורא שלח את הקוד הזה והבקר שמר אותו. לצערי, אין לי מתכנת קנייני מ-IronLogic שיבדוק את מסד הנתונים של מפתחות הבקר, אבל אני מקווה שהצלחתי למשוך את תשומת הלב לעובדה שהבעיה קיימת. הדגמת וידאו של עבודה עם פגיעות זו זמינה по ссылке.

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

מקור: www.habr.com