הגנה על iPHONE מפני וירוסים: מדריך שלם לזיהוי והסרה של תוכנות זדוניות

2024-11-23T00:25:34+03:00

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

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

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

פגיעות אייפון לוירוסים: הסתכלות על העובדות

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

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

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

סימן שהאייפון שלך נגוע בתוכנה זדונית

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

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

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

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

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

שיטות לאבחון של iPhone עבור תוכנות זדוניות

אם אתה חושד שהאייפון שלך נגוע בתוכנה זדונית, בצע את שלבי האבחון שלהלן.

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

אבחון נוכחות פריצת כלא

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

בעת רכישת אייפון משומש, חשוב לבדוק את מכשיר הפריצה. לא משנה מי ביצע את פריצת הכלא, נוכחותו מפחיתה משמעותית את אבטחת המכשיר. בדיקת Jailbreak היא שלב חשוב באבחון אבטחת אייפון.

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

ניטור צריכת תעבורה ניידת

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

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

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

ניתוח של שטח אחסון פנוי

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

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

הפעלה מחדש של המכשיר

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

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

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

הסרת יישומים חשודים

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

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

ניקוי היסטוריית הדפדפן

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

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

התקנת תוכנת אבטחה

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

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

החלפת המכשיר במקרים קריטיים

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

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

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

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

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

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

אמצעי הגנה מונעים לאייפון

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

עדכון iOS בזמן

אפל משחררת באופן קבוע עדכוני אבטחה למערכת ההפעלה iOS. שמירה על עדכון המערכת שלך היא קריטית להגנה על המכשיר שלך. אתה יכול לבדוק אם יש עדכונים דרך הגדרות > כללי > עדכון תוכנה.

סירוב פריצת כלא

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

בקרת מקור יישומים

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

שימוש בטוח ב-Wi-Fi

הימנע מחיבור לרשתות Wi-Fi ציבוריות לא מאומתות. אם אתה צריך להשתמש ברשתות ציבוריות, אנו ממליצים להשתמש בפתרון VPN אמין להגנה נוספת על נתונים.

אימות מחוזק

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

תפיסות מוטעות נפוצות לגבי אבטחת אייפון

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

אבטחה מוחלטת של אייפון

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

הצורך בתוכנת אנטי וירוס

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

הודעות קופצות כאינדיקטור לזיהום

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

פנייה למומחים

אם מיצית שיטות עצמאיות לפתרון הבעיה, עליך לשקול את האפשרות של עזרה מקצועית:

תמיכה טכנית של אפל

למומחי התמיכה של Apple יש את הכלים לאבחן לעומק את המכשיר שלך והם יכולים להציע פתרונות יעילים לבעיות שזוהו.

פנייה לחנות אפל

מומחי Genius Bar מוסמכים ב-Apple Store מסוגלים לבצע אבחון מקיף של המכשיר ולספק סיוע מוסמך.

מרכזי שירות עצמאיים

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

מַסְקָנָה

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

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

 

מחבר – אלכסיי דרוזד, ראש מחלקת האבטחה ב-SearchInform

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

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

המפתח לאינטגרציה מוצלחת או מה DLP אמור להיות מסוגל לעשות בהתחלה

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

1. השתלב בתשתית – ברמת התאימות למערכת ההפעלה, ה-DBMS, התוכנה ושאר המערכות המשמשות בחברה.

DLP « SearchInform KIB » עובד עם Windows, Linux ו-Mac, מרכז הנתונים של המערכת עובד עם DBMS שרירותיים: מ-MS SQL ועד Jatoba, Pangolin, PostgreSQL ו- Russian PostgreSQL Pro. המערכת יכולה לפעול הן מקומית והן בענן, כולל ניטור תחנות עבודה וירטואליות. כלומר, הוא "יעמוד" בכל מקום.

1. לספק שליטה רחבה: תמיכה במקסימום ערוצים דרכם ניתן לשלוח נתונים ארגוניים.
   מחוץ לקופסה, SearchInform CIB הוא אחד ה-DLPs המקיפים ביותר בשוק מבחינת מספר השירותים הארגוניים המבוקרים. בנוסף, המערכת יכולה לנטר שירותים מחוץ לתחום הפועלים בצד הספק ואינם "קשורים" ישירות למחשב העובד. ואם השירות אינו נתמך באופן מיידי, ניתן לחבר אותו בקלות באופן ידני באמצעות כלים מובנים פשוטים.
2. ניתוח ומבנה איכותני של הנתונים שהתקבלו לאיתור אירוע אמין.
   אנליטיקה ב-DLP פועלת על סמך סוגי החיפושים בהם תומך המנוע. ל-SearchInform CIB יש פיתוח משלו: יש לו אלגוריתמי חיפוש רבים, בנוסף מנותחים אודיו, טקסט, ארכיונים, אובייקטים מוסתרים ושכבות נסתרות. כתוצאה מכך, כל התעבורה המתקבלת על ידי המערכת מתווספת לאינדקס, כלומר. מונח "על המדפים" בצורה יחידה נוחה לעיבוד.
3. תמיכה בטכנולוגיות חילופי נתונים אוניברסליות, כלומר, להיות פתוח ל"חיבור" של מערכות חיצוניות.
   ככלל, הסט הבא מספיק: REST API, SYSLOG/CEF, SMTPs, ICAP, ODBC. אבל ייתכן שיידרשו מנגנונים ספציפיים. יש יותר מתריסר טכנולוגיות אינטגרציה זמינות ב-CIB, כולן פועלות מחוץ לקופסה ממש בממשק: ניתן "ללחוץ" על החיבור למערכת חיצונית, אין צורך לתכנת דבר.

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

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

מה ואיך לשלב DLP

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

DLP שימושי לאיסוף נתונים מ:

1. מערכות אבטחה פיזיות
   אלו יכולות להיות מערכות בקרת כניסה, מעקב וידאו ומערכות אזעקה. מידע מהם שימושי ב-DLP, בעיקר להשוואה לנתונים על פעילות עובדים במחשב. לדוגמה, זה עוזר לזהות מקרים של הונאה, כאשר עמיתים לא מורשים או חסרי מצפון פועלים תחת אישורים ומפתחות גישה של עובדים. ל-KIB תבניות מוכנות לאינטגרציה עם מערכות פופולריות מקטגוריה זו לחיבורים דרך API וישירות למסד הנתונים.
2. מערכות DCAP/DAG

המידע נחוץ כדי להאיץ את החיפוש ולחסום את העברת התוכן הרגיש. אם DLP מזהה את התוויות שהוקצו לקובץ ב-DCAP, הוא לא יבזבז זמן בקריאה חוזרת שלו כדי להחיל מדיניות אבטחת מידע. לפיכך, KIB מזהה תגיות MS Information Protection ועובדת עם משנה EveryTag. ועם DCAP, SearchInform FileAuditor משולב בצורה חלקה ועובד על בסיס סוכן משותף.

1. מערכות הצפנת קבצים והגנה

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

1. מסדי נתונים שרירותיים, כולל תוכנות שירות ותוכנות עסקיות

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

DLP יכול לשלוח נתונים אל:

• אנטי וירוסים ו-EDR/XDR
  ראשית, יש צורך שהמערכות "יראו" אחת את השנייה ולא יתפסו זו את זו כאיום. שנית, נתונים מ-DLP יעשירו נתונים על תפעול תקין של התשתית כך שמערכות הגנת סייבר יוכלו לחדד את זיהוי התקפות. CIB תואם לכל הפתרונות הפופולריים של מחלקה זו – אינטגרציה עם אנטי וירוסים "מחוברת" למערכת כברירת מחדל. בנוסף, DLP יכול להעביר אליהם יומנים או מידע נבחר ממסד הנתונים שלה.
• SIEM/SOC
  מה-CIB אתה יכול להעביר את רוב המדדים, הדוחות והתקריות לכל SIEM או SOC. זה נעשה דרך ה-SYSLOG/CEF הרגיל, אבל ל-SearchInform SIEM שלנו, למשל, ה-CIB שולח את הנתונים ישירות. מאחר שסוכן ה-DLP מיושם "מתחת" למערכת ההפעלה, זכויותיו אינן מוגבלות על ידי המסגרת שלה. ואפילו ברקע הוא מקבל מידע מעמיק על פעולת התשתית: פעילות תהליכים, אתרים, מכשירים מחוברים וכו'. ב-SOC וב-SIEM, ניתן לתאם את הנתונים הללו עם מידע ממקורות אחרים כדי לזהות אירועי אבטחת מידע מורכבים.
• מערכת הפעלה ותוכנות צד שלישי
  DLP יכול להנפיק פקודות לתהליכים ומערכות אחרות באמצעות סקריפטים של RPC/MMC או (Power)Shell/SSH. לדוגמה, אתה יכול לסיים את ההפעלה ולחסום את חשבון המשתמש אם DLP מודיע שהמחשב הוא "זר". באותו אופן, ה-CIB יכול לספק מידע על עבודתו ועל תקריות שזוהו למערכות שרירותיות.
• IRP
  תגובה לאירועים נפתרת בצורה מוצלחת יותר באמצעות אמצעים מיוחדים, וזו הסיבה ל-CIB יש ממשק מיוחד לאינטראקציה עם R-Vision. DLP מעביר מידע על תקריות ומידע נוסף לשם, IRP עוזר להשיק תגובה. אותו ממשק מאפשר לייצא נתונים ל-GosSOPKA: דיווחים על תקריות והתקדמות חקירתם.

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

מה יקרה בסוף

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

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

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

נסה" SearchInform KIB » ביחד או בנפרד: המערכת תשתלב בתשתית אבטחת המידע שלכם ותחזק אותה, ותוסיף יכולות חדשות. זה בחינם למשך 30 יום.

פִּרסוּם. מפרסם SearchInform LLC, TIN 7704306397 erid:2SDnjecSC27

חוקר Akamai, סטיב קופצ'יק, גילה פגיעות חדשה של Elevation of Privilege (EoP) בלקוח הרישום המרוחק של מיקרוסופט CVE-2024-43532
(ציון CVSS: 8.8). הבאג מנצל את מנגנון ה-fallback בלקוח WinReg, אשר משתמש בצורה לא מאובטחת בפרוטוקולי תעבורה מדור קודם אם SMB אינו זמין.

על ידי ניצול הפגיעות, תוקף יכול להעביר את אישורי ה-NTLM של הלקוח לשירותי Active Directory Certificate Services (ADCS) ולבקש אישור משתמש, אשר לאחר מכן יוכל לשמש לאימות נוסף לתחום. אקמאי הציג הוכחה לקונספט ב מאגרים
ב-GitHub.

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

מָבוֹא

MS-RPC הוא היישום של מיקרוסופט של פרוטוקול Remote Procedure Call (RPC). RPC הוא מנגנון תקשורת בין-תהליכים המאפשר לתהליכים לחשוף פונקציונליות שניתן לגשת אליה על ידי תהליכים אחרים. RPC הוא מרכיב ליבה של Windows ושירותים רבים תלויים בו, כולל מנהל השירות ופונקציות הכיבוי ב-wininit.

Akamai ערכה מחקר רב על MS-RPC, הן בהתקפה, שגילתה וקטור התקפה גדול בצורה של התקפות מטמון, והן מבחינה הגנתית, שניתחה מנגנוני אבטחה.

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

RPC, אימות ונקודות ביניים

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

תהליך קריאת RPC בסיסי

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

מה חסר באינטראקציה? אימות! כיצד יכול השרת לברר את זהות הלקוח ולאמת את זכותו לבצע את הפעולה המבוקשת? התשובה היא שהוא לא יוכל לעשות זאת אלא אם הלקוח יוסיף הקשר אבטחה (אימות) לבקשה המחייבת. כברירת מחדל, כל חיבורי ה-RPC אינם מאומתים, ולא כל שרתי ה-RPC דורשים אימות.

כדי לבצע אימות (או, כפי שזה נקרא ב-RPC, "הוספת הקשר אבטחה"), על הלקוח להוסיף נתונים נוספים לבקשה המחייבת, לנהל משא ומתן על פרוטוקול אימות (כגון NTLM או Kerberos), ולהכניס מטא נתונים נוספים הנדרשים על ידי האימות פרוטוקול (כגון שם משתמש, דומיין וכו').

מטא-נתונים של אימות נוספו לבקשת מחייב RPC

מציאת יעדי מחקר

הצעד הראשון הוא להבין איך אימות צריך להיראות מנקודת מבט של API. הדבר מושג על ידי קריאה לאחת מהפונקציות RpcBindingSetAuthInfo* מהלקוח לאחר יצירת אחיזת הקישור. בתיעוד של פונקציות אלו, תבחין בשדה AuthenticationLevel, המציין את רמת האבטחה של האימות.

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

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

הפעל את סקריפט IDAPython בתיקיית system32 של שרת Windows כדי לחפש מקרים של אימות RPC לא מאובטח (את הסקריפט ניתן למצוא ב מאגרים לִכאוֹב)

WinReg הוא מועמד מבטיח

כצפוי, רשימת היעדים הפוטנציאליים כללה פחות מ-5% מהמספר הכולל של שרתי RPC ולקוחות; רובם כבר לא משתמשים באימות לא מאובטח. עם זאת, מצאנו מועמד מעניין בספריית advapi32.dll.

advapi32.dll הוא מרכיב ליבה של Windows API המיישם תכונות רבות כגון רישום אירועים, הצפנה, WMI ואחרות.

מצאנו שהפונקציה BaseBindToMachine קוראת לפעמים ל-RpcBindingSetAuthInfoA עם רמת האימות RPC_C_AUTHN_LEVEL_CONNECT, וזה מה שאנחנו צריכים. BaseBindToMachine נקרא על ידי הפונקציה RegConnectRegistryExW אם נתיב UNC מועבר כשם המכונה.

תיעוד חלודה עבור RegConnectRegistryExW מכיוון שהוא אינו מתועד ב-MSDN

בהסתכלות על BaseBindToMachine, תבחין שהיא משתמשת הן ב-RpcBindingSetAuthInfoW (רמה בטוחה RPC_C_AUTHN_LEVEL_PKT_PRIVACY) והן ב-RpcBindingSetAuthInfoA (עם רמה RPC_C_AUTHN_LEVEL_CONNECT, אשר אינה מאפשרת בדיקת החיבור וההעברה של תקינות).

שתי שיחות להגדרת מידע אימות

אנחנו רק צריכים להבין למה יש שתי קריאות סותרות. כשבדקנו את הלוגיקה של הפונקציה, גילינו שהיא משתמשת במשתנה מצביע פונקציה ובמערך של פונקציות. פונקציות אלו מציינות מידע מחייב RPC לשימוש בהעברת RPC ספציפית; ברירת המחדל היא SMB ו-named pipes, אבל אם זה נכשל, הוא מנסה להתחבר באמצעות SPX, TCP/IP ואחרים.

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

מצביעי פונקציות ומערך פונקציות בתוך BaseBindToMachine

חזרה ל-TCP/IP – מציאת מזל

החזרה ל-TCP/IP נראית מבטיחה מכיוון שהיא מאפשרת להשתמש בשיטת אימות לא מאובטחת להעברת תעבורה דרך התקפת אדם באמצע מבלי להודיע ​​ללקוח. למרות שזה אפשרי עם פרוטוקולי תחבורה אחרים, הם די מיושנים והשימוש בהם ברשת מודרנית יכול להיות חשוד. TCP/IP משמש הרבה יותר כהעברת RPC וניתן להשתמש בו בבטחה אפילו בסביבת צוות אדום.

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

תהליך ממסר

ממסר NTLM הוא טכניקה נפוצה, וההיגיון הבסיסי כבר מיושם ב-ntlmrelayx של Impacket, וזה מה שנשתמש בעיקר.

יצירת שרת ממסר RPC

ntlmrelayx אינו כולל שרת RPC עבור TCP/IP, רק שרת SMB. לכן, נצטרך ליצור שרת ממסר משלנו שידחה את חיבור ה-winreg בשם pipe כדי לאלץ חיבור TCP/IP fallback.

לשם כך, יש ליישם שלוש נקודות מפתח:

1. מיפוי נקודות קצה של RPC
2. בקשת RPC Binding עם NTLM
3. שיחת NTLM

ממפה נקודות הקצה של RPC אחראי על תרגום ה-UUID של ממשקי RPC לנקודות קצה מתאימות, שבמקרה של תעבורת TCP/IP הם מספרי יציאות. בניגוד ל-SMB, שבו נקודות הקצה נקראות צינורות עם שמות צפויים, נקודות קצה TCP/IP משתמשות ביציאות ארעיות ולכן דורשות שכבת תרגום נוספת.

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

אימות NTLM באמצעות כריכת RPC

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

המחשבה הראשונה תהיה להעביר את הנתונים לשרת RPC אחר במחשב אחר, כגון מנהל שירות או מתזמן משימות, כדי להפעיל את הקוד המרוחק. עם זאת, שני השירותים הללו דורשים את רמת האימות RPC_C_AUTHN_LEVEL_PKT_PRIVACY, אשר מצפינה את כל התעבורה באמצעות ה-hash NTLMv2 של הלקוח, שאין לנו גישה אליו אפילו עם ממסר.

מעביר RPC ל-ADCS

ממסר NTLM ל-ADCS מיושם כברירת מחדל ב-Impacket, כך שכל מה שאנחנו יכולים לעשות הוא להעביר את ההפעלה המאומתת שלנו למודול HTTPAttack ולאפשר לתהליך להשלים אוטומטית את המתקפה.

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

בקשה וקבלת אישור מ-ADCS לאחר התקפת ממסר NTLM

באמצעות אישור זה, עשינו אימות לשירות LDAP בבקר התחום ויצרנו חשבון מנהל דומיין קבוע בדומיין שנפרץ.

יצירת מנהל דומיין חדש באמצעות מעטפת LDAP

פונקציה ב-advapi בפני עצמה אינה מעניינת אלא אם כן משהו אחר משתמש בה. חיפוש מהיר של יבוא RegConnectRegistryExW או RegConnectRegistryExA לא הראה דבר על בקר התחום בפועל, אך חיפוש של RegConnectRegistryW גילה מספר מועמדים אפשריים, כגון certutil ו-certsrv (AD CS), EFS, DFS ואחרים.

איתור

הרישום המרוחק אינו מופעל כברירת מחדל בכל מכשירי Windows. ניתן לקבוע את מצב הפעילות שלו באמצעות השאילתה הבאה:

SELECT display_name, status, start_type, pid FROM services WHERE name="RemoteRegistry"

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

אתה יכול להשתמש בכלל YARA הבא כדי לזהות לקוחות המשתמשים בפונקציות WinAPI פגיעות:

יבוא "על"

 

 כלל winreg_client_import {

     מטא:

         description = "זהה קבצים בינאריים המסתמכים על RegConnectRegistry"

         מחבר = "סטיב קופצ'יק מ-Akamai Technologies"

 

     מַצָב:

         pe.is_pe ו-(

             pe.imports(pe.IMPORT_ANY, "advapi32.dll", "RegConnectRegistryA")

             או pe.imports(pe.IMPORT_ANY, "advapi32.dll", "RegConnectRegistryW")

             או pe.imports(pe.IMPORT_ANY, "advapi32.dll", "RegConnectRegistryExA")

             או pe.imports(pe.IMPORT_ANY, "advapi32.dll", "RegConnectRegistryExW")

         )

 }

משתמשי Akamai Guardicore Segmentation יכולים גם ליצור כללי מדיניות עבור תעבורה המופנית לשירות RemoteRegistry.

כלל מדיניות פילוח להודיע ​​על תעבורה לשירות RemoteRegistry

אתה יכול גם להשתמש במעקב אחר אירועים עבור Windows (ETW) כדי לנטר תעבורת RPC בצד הלקוח והשרת.

מַסְקָנָה

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

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

[newsletter_plugin_form]