הסוף למתקפות ה-Drive-By?

[במקור: https://www.curlcandy.com/images/Stop.png] 
חוקר האבטחה Didier Stevens (שאני כל כך אוהב) פרסם אתמול בערב פוסט מעניין מאוד וכלי חדש. 
סטיבנס מציג בפוסט מאפיין מעניין במערכת Windows שנכנס כתצורת טעינה של תהליכים במערכת. המאפיין שמציג סטיבנס
הוא "ActiveProcessLimit" (מתוך JOBOBJECT_BASIC_LIMIT_INFORMATION) וטעינת "Job" (מספר תהליכים המנוהלים
יחדיו במערכת ההפעלה) בציון המאפיין הנ"ל מאפשר למערכת ההפעלה לקבוע ולהגביל את כמות התהליכים אשר יכלול אותו
ה-Job.

סטיבנס מראה איך בעזרת המאפיין הנ"ל ניתן למנוע מתהליכים ליצור תהליכים חדשים. כך לדוגמה, במידה ונריץ את התהליך
iexplorer.exe בתוך Job חדש עם ActiveProcessLimit=1, נוכל למנוע ממנו להריץ תהליכים חדשים, כך במידה ונכנס
לאתר נגוע בוירוס שמנסה לנצל חולשה בדפדפן שלנו בכדי להריץ פקודות על מערכת ההפעלה דרך ה-Cmd.exe - הפעולה
תמנע. אותו הדבר יקרה אם נפתח Job חדש עם ActiveProcessLimit=1 ובו נפתח את קורא ה-PDF שלנו, במידה ומדובר
בקובץ PDF שנגוע בוירוס שמנסה להריץ עלינו פקודות זדוניות דרך תהליך חדש- הפעולה תמנע!

סטיבנס כתב כלי חדש בשם "RunInsideLimitedJob" שמאפשר למשתמש להריץ תהליך בתוך Job מוגבל, לדוגמה, אם
נריץ את cmd.exe באופן הבא:
RunInsideLimitedJob.exe cmd.exe

נקבל חלון cmd.exe, אם ננסה להריץ דרכו את Notepad.exe באופן הבא:
start notepad.exe

מערכת ההפעלה תמנע את הפעולה ואנו נקבל את הודעת השגיאה הבאה:
Not enough quota is available to process this command.

בהפעלה של cmd.exe זה קצת בעייתי, כי כמעט כל פקודה שמריצים דרכו יוצרת child, אך בהרצה של אפליקציית דפדפן
מדובר בפתרון מאוד יצירתי ואלגנטי.
  
 
לצורך הבדיקה, יצרתי PoC בתוך קובץ PDF שמנצל את אחת החולשות האחרונות שנמצאו במוצרים של Adobe ומריץ את
"cmd.exe" בזמן פתיחת המסמך, הרצתי אותו באופן הבא:
 
 
 
לאחר ההרצה קיבלתי את החלון הבא:
 
 
לחיצה על "Open" אמורה לגרום להרצה של ה-"cmd.exe", אך במקום זאת אנו נקבל את השגיאה הבאה:
 
 
בהחלט עבודה נפלאה של סטיבנס.
 
בקשר לשאלה ששאלתי בכותרת, כמו שזה נראה, מדובר בפתרון מאוד נחמד, אבל אני מאמין שאם הרעיון הנ"ל יתפוס- ימצאו
דרך לעקוף אותו, אני כבר חשבתי על דרך, ברגע שיהיה לי הזמן, אנסה אותה, אם יהיו ממצאים אעדכן.


תגובות על 'הסוף למתקפות ה-Drive-By?':



#1 

 sdimant:
אהבתי!!!
תודה רבה על העדכון.
14.09.2010 15:40:59

#2 

 Oink (אורח):
מה זה פייסבוק?!
וכן- בהחלט פתרון חביב, תודה רבה על המידע!
14.09.2010 16:31:09

#3 

 sdimant:
מה קשור פייסבוק?
14.09.2010 16:36:44

#4 

 Oink (אורח):
ה-"אהבתי" שלך..
14.09.2010 16:43:39

#5 

 cp77fk4r:
אגב, במידה ואתם מעוניינים לפתוח את IExplorer.exe, שימו לב שאתם חייבים לפתוח אותו עם לפחות ActiveProcessLimit=2 (בעזרת הסוויצ' "n"), כי שלא כמו ב-Chrome או Firefox, שם הטאב הראשון הוא כבר תהליך נפרד. (ב-Chrome וב-Firefox הטאב הראשון הוא עדיין אותו תהליך).
14.09.2010 16:55:11

#6 

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

AppArmor (לינוקס) מציעה פתרון עדיף, רשימה לבנה של אפלקציות שמותר לתוכנה X לקרוא ויש אפשרות שהם ירשו (או לא) את ההרשאות של התוכנית הקוראת להם. משמע אין סיבה ש-IE תקרא ל-CMD, לכן פעולה זאת תחסם. אבל בוא נגיד וכן מותר לה לקרוא ל-AcrobatReader וההתקפה היא מבוססת PDF, אך בגלל שהתוכנית ירשה את ההרשאות, גם היא לא תוכל לקרוא ל-CMD.

בחלונות הייתי מעדיף לעבוד עם ארגזי חול...

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

#7 

 sdimant:
Oink - לייק+ :)
14.09.2010 18:13:26

#8 

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

#9 

 Dw4rf (אורח):
אז זה יכול למנוע ניצול של כל מני Buffer overflows?

ITK98- תגובה מרשימה, למדתי ממנה הרבה! תודה!
14.09.2010 18:54:49

#10 

 cp77fk4r:
Dw4rf- לאו דווקא, כשאתה מנצל BoF אתה משכתב קוד שקיים בתהליך ולאחר מכן דואג שהמערכת הפעלה תריץ אותו (לדוגמה- ע״י שימוש בקריאת call או בעזרת ביצוע jmp לאותו מיקום), כך שהקוד שלך ה-("shellcode") מורץ מאותו תהליך במערכת הפעלה ולכן לא נוצר שום תהליך ב-job, אבל שוב, זה תלוי במה ה-shellcode שלך תוכנן לבצע.
14.09.2010 19:17:55

#11 

 Dw4rf (אורח):
הבנתי, תודה רבה!
14.09.2010 19:51:53

#12 

 מתניה (אורח):
האם הרעיון הנ"ל פועל בכל מערכת קבצים חלונאית? או רק מntfs והלאה? כל הרעיון של quota הגיע רק בntfs, אין אותו במשפחת fat כלל.
15.09.2010 07:45:13

#13 

 cp77fk4r:
מתניה- אין הבדל, אני מאמין שאין קשר למערכת הקבצים אלא במימוש ה-Job במערכת ההפעלה, כך שהכלי עובד גם על מחיצות שונות מ-NTFS כגון Fat.
15.09.2010 11:19:51

#14 

 cp77fk4r:
אכן, דיברתי עם Didier והוא אישר את דברי.
15.09.2010 15:26:10

#15 

 sdimant:
מתניה- אני חושב שאתה מתבלבל עם הQuota של המחיצות, הQuota הזה הוא באמת רק מNTFS.
15.09.2010 15:46:54

#16 

 שלומי (אורח):
נחמד ביותר, אבל בסופו של דבר זה לא מגן על המשתמש הרגיל שאינו מודע לדברים האלו ובטח שלא ירצה להתחיל להריץ קבצים דרך תוכנה כלשהי ושעוד צריך מראש לדעת כמה JOBS היא דורשת.
אחלה סיקור CP מחכה לכתבות שלך תמיד.
15.09.2010 18:07:44

#17 

 sdimant:
בהמשך להודעה הקודמת שלי: הquota במחיצות מאפשרות לתת לכל משתמש לאחסן קבצים במחיצה בכמות מוגדרת (דבר שקשול לFileSystem ובשביל זה צריך NTFS). אבל הquota שאפיק דיבר עליה בכלל לא קשורה לFS ולכן לא הFS לא משנה.
15.09.2010 19:00:57

#18 

 sdimant:
סליחה על הדאבל, אבל אפיק גם אני כל הזמן מחכה לכתבות שלך :)
15.09.2010 19:01:48

#19 

 cp77fk4r:
תודה על המחמאות.
אז ככה: כרגע הדבר אינו מגן על המשתמש, אך מיקרוסופט יכולה להשתמש בזה בתור מנגנון בעתיד- לדוגמה, לפתח מנגנון במערכת ההפעלה שמקפיץ למשתמש הודעה עם בקשת אישור בכל פעם שתהליך מסויים מנסה לפתוח תהליך נוסף באופן כזה. כך אם מישהו יפתח קובץ PDF שמכיל JS שמנסה לפתוח תהליך שני- תקפוץ למשתמש הודעה ברמת מערכת ההפעלה.
אותו דבר עם מתקפות Drive By על הדפדפן...
15.09.2010 19:26:57

#20 

 Dw4rf (אורח):
CP- אתה מתכוון שהם ישלבו אותו באופן כזה שכל תהליך שיפתח במערכת הפעלה יפתח בג׳וב נפרד עם ההגבלה למינימום תהליכים שהוא דורש ויהיה מנגנון שיודיע למשתמש על כל חריגה ויאפשר לו לאשר אותה? משהו כזה?
15.09.2010 19:35:53

#21 

 cp77fk4r:
יאפ', משהו בסיגנון הזה.
15.09.2010 21:15:33

#22 

 m1ch43l1014 (אורח):
אחלה סיקור תודה !
15.09.2010 21:55:29

#23 

 Dw4rf (אורח):
אוקיי, אז הבנתי איך אנחנו יכולים למנוע מתוקף לנצל פירצה בדפדפן שלנו ולפתוח בעזרתה תוכנה זדונית, אבל איך אנחנו יכולים למנוע ממנו לנצל פירצה כמו Buffer Overflow ובעזרתה לשכתב קוד קיים מתוכנת הדפדפן שלנו ולהריץ אותו באותו התהליך?
15.09.2010 23:08:17

#24 

 cp77fk4r:
שאלת פה שאלה שהרבה חוקרי אבטחת מידע מחפשים לה תשובה, יש הרבה מנגנונים שאמורים לעזור, כמו למשל DEP:
https://en.m.wikipedia.org/wiki/Data_Execution_Prevention

שפשוט מסמן חלקים בזכרון עם הדגל NX/XD (דגלי Execute Disabled) ובמידה שקוד מנסה לרוץ מהם- למנוע זאת.

או מנגנונים כמו ASLR:
https://en.wikipedia.org/wiki/ASLR

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

דוגמה נוספת היא ה-Stack Canaries:
https://en.m.wikipedia.org/wiki/Stack_protection

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

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

#25 

 turbo (אורח):
למה קוראים למתקפות האלה Drive-By?
16.09.2010 08:54:36

#26 

 cp77fk4r:
מדובר במתקפות כגון "Drive-By Download" או -"Drive-By installation", בגלל שבתחילתם של המתקפות האלה תוקפים היו מנצלים אותם בעיקר בכדי להוריד ולהתקין ActiveX וכו'
16.09.2010 10:01:51

#27 

 Dw4rf (אורח):
@cP - תודה רבה על התגובה המושקעת! עכשיו הרבה יותר מובן לי הכל.
16.09.2010 17:26:46

#28 

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

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

משתמשי לינוקס (או כל מערכת POSIX) יגידו לכם:
Been there, Done that.

אם אתם מחפשים דרך לאבטח מחשב, תחשבו על ACL ויותר מכך תחשבו על-MAC - שם טמון העתיד של אבטחה. (עוד מידע וויקי).
17.09.2010 22:12:58

#29 

 Oink (אורח):
עברתי על רב הסעיפים ב-POSIX (מה שהיה נראה רלוונטי), דבר ראשון - תודה רבה. דבר שני- לא ראיתי איפה זה מופיע שם, תוכל להפנות אותי לסעיף ספציפי?
תודה רבה!
21.09.2010 20:34:42

#30 

 iTK98se (אורח):
חפש עוד מידע על pthread וספציפית על הפונקציה PTHREAD_THREADS_MAX. נראה לי שהגירסה האחרונה של POSIX שינתה כמה דברים בקשר לספריה הזאת, אבל המידע עדיין זמין ברשת.

שוב, מיקרוסופט לא חידשו כלום, ומשעשע לראות את ה"גורו-ים" של חלונות מתלהבים מספריה כל כך פשוטה שקיימת יותר מעשור.
21.09.2010 22:44:53

#31 

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

man pthreads
(אם אין לך לינוקס, אתה יכול לחפש בגוגל)

[מצטער על התגובה הכפולה]
21.09.2010 22:52:32

#32 

 Oink (אורח):
א'- תודה רבה, ואני כרגע משתמש כפול- גם חלונות וגם לינוקס (אובונטו)- עזרת לי מאוד!

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

שוב, תודה רבה, בהחלט חומר מעניין :)
22.09.2010 20:30:02

#33 

 iTK98se (אורח):
זה לא תוסף אבטחה, אל תגיד זאת, זה צורם לי. ועוד יותר קשה לי עם כך שמההתחלה אני מתעקש שאין לראות באמצעי כדרך ליישם אבטחה אך עדיין הרעיון לא שוקע.
23.09.2010 19:01:58

#34 

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

אגב תודה על המאמר

ובשבילך turbo, זה נקרא drive by כמו המקור Drive-by shooting
ירי [בד"כ כנופיות] מתוך כלי רכב
רק שכאן מדובר במתקפת סייבר
31.10.2010 01:42:04

#35 

 שמיל (אורח):
אני גם נגד, אך כן, יש מקרים בהם ברור לך שאתה לא צריך עוד פרוסס- לדוגמא, כשאתה פותח calc.exe
31.10.2010 05:46:42


הוסף את תגובתך:
כינוי:
תגובה:
קוד אבטחה:
העתק לכאן את הקוד:
 
Digital Whisper © 2009 - 2025 - כל הזכויות שמורות ל-אפיק קסטיאל ול-ניר אדר.