אני שורש. הבנת הסלמה של Linux OS Privilege

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

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

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

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

הסלמה של הרשאות באמצעות תצורה לא מאובטחת

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

מעטפת פסאודו ופריצת כלא

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

sudo: no tty present and no askpass program specified

לאחר קבלת מעטפת, אני ממליץ ליצור טרמינל מלא, למשל עם Python.

python -c 'import pty;pty.spawn("/bin/bash")'

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

ניתן להשיג מעטפת הרשאה נמוכה באמצעות צוותים 1 и צוותים 2 (באופן מפתיע אפילו GIMP).

הצג היסטוריית פקודות

לינוקס אוספת היסטוריה של כל הפקודות המבוצעות בקובץ ~ / .bash_history. אם השרת נמצא בשימוש פעיל וההיסטוריה שלו לא מנוקה, יש סיכוי טוב שהאישורים יימצאו בקובץ זה. ניקוי ההיסטוריה אינו נוח באופן בנאלי. אם המנהל ייאלץ לבחור פקודות של עשר רמות דרך, כמובן, יהיה לו נוח יותר לקרוא לפקודה זו מההיסטוריה מאשר להזין אותה שוב. בנוסף, רבים אינם יודעים על ה"פריצה" הזו. אם יש קונכיות אלטרנטיביות כמו Zsh או Fish במערכת, יש להן היסטוריה משלהן. כדי להציג את ההיסטוריה של הפקודות בכל מעטפת, פשוט הקלד את פקודת ההיסטוריה.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

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

איתור סיסמאות במערכת הקבצים והתקפות על מערכות סמוכות

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

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

אם למארח שנפרץ יש יישום אינטרנט נגיש מהאינטרנט, עדיף לא לכלול את היומנים שלו בחיפוש אחר כתובות IP. סביר להניח שהכתובות של משתמשי משאבים מהאינטרנט יהיו שימושיות עבורנו, אבל הכתובות של הרשת הפנימית (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) ולאן הם הולכים, אם לשפוט לפי יומנים, עשויים לעניין.

סודו

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

הדבר הראשון שצריך לעשות לאחר קבלת גישה למערכת הוא להפעיל את הפקודה sudo -l. זה יציג הרשאה להשתמש בפקודה sudo. אם מתקבל משתמש ללא סיסמה (כגון apache או www-data), וקטור הסלמה של הרשאות sudo לא סביר. בעת שימוש ב-sudo, המערכת תבקש סיסמה. השימוש בפקודה passwd כדי להגדיר סיסמה גם לא יעבוד, הוא יבקש את סיסמת המשתמש הנוכחית. אבל אם sudo עדיין זמין, אז, למעשה, אתה צריך לחפש:

• כל מתורגמן, כל אחד יכול להוליד מעטפת (PHP, Python, Perl);
• כל עורכי טקסט (vim, vi, nano);
• כל הצופים (פחות, יותר);
• כל האפשרויות לעבוד עם מערכת הקבצים (cp, mv);
• כלים שיש להם פלט ב-bash, באופן אינטראקטיבי או כפקודה ניתנת להפעלה (awk, find, nmap, tcpdump, man, vi, vim, ansible).

סויד/סגיד

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

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

סקריפטים ניתנים לכתיבה המופעלים על ידי Cron או Init בהקשר Root

משימות Cron יכולות לפעול בהקשר של משתמשים שונים, כולל root. אם יש משימה ב-cron עם קישור לקובץ הפעלה, והיא זמינה עבורכם לכתיבה, תוכלו להחליף אותה בקלות באחת זדונית ולבצע הסלמה של הרשאות. יחד עם זאת, כברירת מחדל, קבצים עם משימות cron זמינים לקריאה על ידי כל משתמש.

ls -la /etc/cron.d  # show cron jobs 

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

ls -la /etc/init.d/  # show init scripts 

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

find / -perm -2 -type f 2>/dev/null # find world writable files

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

chmod +w /path 
chmod 777 /path

השגת גישת מעטפת עבור משתמשים אחרים

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

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

קוד בכתב עצמי

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

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

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

לפני ניסיון להעלות הרשאות באמצעות ניצול, חשוב להבין את העברת קבצים למארח היעד. בנוסף לכלים הרגילים כמו ssh, ftp, http (wget, curl), יש שלם "גן חיות" של אפשרויות.

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

ניצול שירותים הפועלים בהקשר של משתמש השורש

חלק משירותי לינוקס פועלים כשורש המשתמש המועדף. ניתן למצוא אותם באמצעות ה-ps aux | grep root. במקרה זה, ייתכן שהשירות לא יוכרז באינטרנט ויהיה זמין באופן מקומי. אם יש לו ניצול ציבורי, ניתן להשתמש בהם בבטחה: קריסת שירות במקרה של כשל היא הרבה פחות קריטית מאשר קריסת מערכת ההפעלה.

ps -aux | grep root # Linux

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

ניצול פגיעויות בליבת לינוקס

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

cat /proc/version
uname -a
searchsploit "Linux Kernel" 

מטאספלויט

כדי לתפוס ולטפל בחיבור, תמיד עדיף להשתמש במודול ה-exploit/multi/handler. העיקר הוא להגדיר את המטען הנכון, למשל, generic/shell/reverce_tcp או generic/shell/bind_tcp. ניתן לשדרג את המעטפת שהושגה ב-Metasploit ל-Meterpreter באמצעות מודול post/multi/manage/shell_to_meterpreter. עם Meterpreter, אתה יכול להפוך את התהליך שלאחר הניצול לאוטומטי. לדוגמה, המודול post/multi/recon/local_exploit_suggester בודק את הפלטפורמה, הארכיטקטורה והישויות הניתנות לניצול ומציע מודולי Metasploit להסלמה של הרשאות במערכת היעד. הודות ל-Meterpreter, הסלמה של הרשאות מסתכמת לפעמים בהפעלת המודול הנכון, אבל פריצה בלי להבין מה קורה מתחת למכסה המנוע אינה נכונה (עדיין צריך לכתוב דוח).

כלים

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

Linpeas

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

LinEnum

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

linux-exploit-suggester(1,2)

ניצול זה ינתח את המערכת לתנאים מתאימים לניצול. למעשה, הוא יעשה עבודה זהה למודול local_exploit_suggester של Metasploit, אך יציע קישורים לקודי מקור של Exploit-db ולא מודולים של Metasploit.

Linuxprivchecker

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

בפעם אחרת ארחיב הסלמה של הרשאות לינוקס באמצעות suid/sgid.

מקור: www.habr.com