חיפוש
  • יניב אור

מעבדת סייבר - 1

עודכן ב: מאי 9

המטרה

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


סוג התקיפה

אדם בתווך - man in the middle (MITM)


התוקף

לפטופ Asus ROG Strix - מריץ אובונטו 18.04.


הקורבן

סמארטפון OnePlus X שברשותי - מריץ Android 6.0.1.


הכלים

- התוכנה arpspoof שמגיעה כחלק מהחבילה dsniff - אותה אני מריץ בתוך קונטיינר שהכינותי מראש. מדריך ליצירת קונטיינר dsniff.

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

- התוכנה nmap הותיקה והטובה - לסריקת רשתות ופורטים - ובמקרה שלי לגילוי מכשיר הקורבן.


הערות

- המכשירים שייכים לי, כמובן, והניסוי נערך ברשת הביתית שלי.

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

- אני יודע מראש את סוג המכשיר של הקורבן.


שלב 1 - זיהוי כתובת ה-IP של הקורבן

- אני מריץ arp-scan לממשק שמחובר לרשת האלחוטית - על הרשת המקומית:

$ sudo arp-scan --interface=wlo1 --localnet


- קיבלתי כתובות IP שמקושרות לכתובות MAC של מכשירים ברשת - ובעמודת הספק (vendor) רוב הערכים לא ידועים (unknown). אין לי מושג מי מהם זה הקורבן שלי.

- מכיוון שהמכשיר ברשותי, אני יודע את כתובת ה-IP ברשת וממשיך הלאה.

- ה-IP הוא 192.168.1.4

- [להשלים: זיהו כתובת הקורבן על פי סוג המכשיר או פרמטרים אחרים]


שלב 2 - הגדרות ל-Forwarding ו-Redirect

במחשב התוקף, אני מאפשר את ה-packet forwarding:

$ sysctl -w net.ipv4.ip_forward=1


הדבר הבא הוא להגדיר ב-iptables אפשרות של FORWARD לרכיב הרשת האלחוטית (wlo1) - איתו אני מתחבר לרשת:

$ iptables -A FORWARD --in-interface wlo1 -j ACCEPT


הגדרה נוספת ב-iptables היא ביצוע REDIRECT לכל התעבורה שמיועדת לפורט 80, לפורט 8080 - בו תשב התוכנה mitmproxy:

$ iptables -t nat -A PREROUTING -i wlo1 -p tcp --dport 80 -j REDIRECT --to-port 8080


בהמשך אגדיר פורטים נוספים - 443 ל-HTTPS ועוד.


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


שלב 3 - ARP Poisoning כך שכל תעבורת הקורבן תעבור דרכי

אני מריץ את הקונטיינר של dsniff כך שישתמש בצורה ישירה בכרטיס הרשת של ה-host:

$ docker run --rm -it --network host dsniff


אני ב-shell של הקונטיינר, מריץ שני חלונות screen. בחלון הראשון אני מריץ:

$ arpspoof -i wlo1 -t 192.168.1.4 192.168.1.1


- הפקודה אומרת ל-gateway (ראוטר) שאני - התוקף המתחזה - הוא בעל הכתובת 192.168.1.4, כך שהתעבורה תגיע אלי ולא למכשיר הקורבן.


ובחלון השני אני מריץ:

$ arpspoof -i wlo1 -t 192.168.1.1 192.168.1.4


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

אני עושה refresh בדפדפן הקורבן והתקשורת עם האתר לא קיימת יותר. זאת משום שהתעבורה עוברת דרך התוקף - אך בפורט 8080 אין שירות רץ והבקשות נזרקות ולא מועברות הלאה. בהמשך, אריץ את mitmproxy על הפורט הזה.


שלב 4 - שימוש ב-mitmproxy

אני מריץ את הקונטיינר של mitmproxy בצורה הבאה:

$ docker run --rm -it -v $PWD:/home/mitmproxy/.mitmproxy --network host mitmproxy/mitmproxy mitmproxy -m transparent


שימו לב לעובדה שאני אומר לקונטיינר שישתמש ברשת של ה-host - ודבר נוסף, שהתוכנה תעבוד ב-mode של transparent proxy. אני עושה refresh בדפדפן הקורבן והאתר שוב מופיע.


בנוסף לזה, אני רואה שהתווספה רשומה ל-mitmproxy. עכשיו יש לי אפשרות לערוך את התעבורה.

(מבטיח סרטוני וידאו)


אני חוזר לשלב 1 - זיהוי כתובת ה-IP של הקורבן.

לא ציינתי, אבל באחד מתוך כמה ניסיונות של arp-scan שעשיתי, כן הצלחתי לראות OnePlus Technology (Shenzhen) Co., Ltd - אבל זה לא יציב, לכן לא ציינתי את העניין הזה. באחד הפוסטים שקשורים להתעסקויות שלי עם RPi כבר כתבתי על כך. זה די מטריד אותי ואני ממש רוצה להבין למה זה קורה.


הדבר הבא שעשיתי זה להריץ nmap עם פרמטרים שונים וניסיתי לגלות את סוג המכשיר ופרטים נוספים. קיבלתי: android-abcxxxxxxx7b8b0a. ניסיתי לסרוק טלפון אחר (Redmi) וכן קיבלתי את סוג המכשיר והמודל. RedmiNote8-Redmi. אגב, ה-Redmi הופיע ב-arp-scan כ-unknown.


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


* עדכון: אני מזכיר שאת המעבדה שמוצגת כאן עשיתי עם אובונטו 18.04. ניסיתי לאחר מכן להריץ arp-scan עם לינוקס Kali והופיעה רשימת Vedors מלאה - מה שאומר שב-Kali יש איזשהו קובץ מעודכן (או גישה לשירות ברשת, צריך לבדוק) - שממפה בין החלק הרלוונטי של ה-MAC address ל-vendor. המסקנה היא שכדאי לערוך את הניסויים האלה עם Kali (או מערכות דומות) כפי שנהוג בתחום.


המשכתי עם ניסיון לנתב תעבורה של HTTPS דרך מהקורבן לתוקף. לצורך כך, הוספתי את הכלל הבא ל-iptables:

$ iptables -t nat -A PREROUTING -i wlo1 -p tcp --dport 443 -j REDIRECT --to-port 8080


הרצתי arp spoofing ואת mitmproxy. נכנסתי עם מכשיר הקורבן לאתר HTTPS ועל המסך של הטלפון הופיעה ההודעה הבאה:

ובתחתית החלון של mitmproxy קיבלתי:

זה צפוי. עכשיו אני צריך לבדוק איך לעבור את השלב הזה.

לפי האתר של mitmproxy יש צורך להתקין על מכשיר הקורבן את ה-CA certificates של mitmproxy כך שהדפדפן לא יציג את הודעת האזהרה.


בזמן שה-arpspoof וה-mitmproxy עובדים והתעבורה של הקורבן עוברת דרך התוקף, נכנסים עם הדפדפן של הקורבן לכתובת:

http://mitm.it/

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


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

הקלקתי על הקובץ והתקנתי ידנית.



ההתקנה עברה בהצלחה והופיע ה-notification הבא:


נכנסתי לאתר שלי


ובדקתי במקביל את mitmproxy:

יפה 👍


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


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

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

שימו לב שהקוד HTTP הוא 304 מה שאומר שהשרת לא שלח את תוכן הקובץ (שימו לב ל-no content) אלא הודיע שנשלחה בעבר בקשה זהה ושיש עותק של הקובץ, שמור ב-cache.


לקבלת התוכן המעודכן מהשרת ולא השמור ב-cache, יש אופציה ב-mitmproxy שנקראת anticache שלמעשה מוחקת מהבקשה לשרת את ה-headers הרלוונטים לעניין - if-none-match ו-if-modified-since . ניתן להפעיל את האופציה בהרצת התוכנה או בצורה אינטראקטיבית. בחרתי בצורה האינטראקטיבית. מקישים O (האות האנגלית o גדולה) במקלדת ומשנים את האפשרות של anticahce מ-false ל-true.



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


נחזור לעריכת התעבורה. לפני כן, מחקתי את השורות הקודמות בלחיצה על מקש d - לכל שורה - וניקיתי את המסך. הדבר הבא שעשיתי היה להגדיר interception (עיכוב). לוחצים על מקש i במקלדת ובתחתית המסך מופיעה שורה: set intercept שבה יש אפשרות להגדיר עיכוב של תעבורה - על-פי פרמטרים מסוימים. בהגדרה הזאת יש אפשרות להשתמש גם ב-regex. בהתאם לפרמטר על-פיו רוצים לסנן את התעבורה. כתבתי s~ שאומר ל-mitmproxy לעכב כל response מכל בקשה.


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


ב-mitmproxy בקשה מעוכבת נצבעת באדום. שימו לב לתחתית המסך: [i:~s]


לחצתי Enter כדי להיכנס לפרטי השורה שנוצרה. עברתי ללשונית של Response (שמסומנת עכשיו כ-intercepted) ולחצתי e. נפתח פופאפ לבחירת החלק אותו ארצה לערוך. בחרתי ב-b שהוא response-body.

נפתח עורך טקסט ובמקרה שלי vi. ערכתי את קוד ה-HTML ושמרתי.


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


ה-OnePlus X (הקורבן) קיבל את התוכן המעובד.

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


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


ראה גם: driftnet - תוכנה המאזינה לתעבורה ברשת ומציגה על המסך תמונות שנתגלו על-ידה במידע שעבר באותה תעבורה.


מעבדות נוספות:

מעבדות סייבר

© 2023 by DO IT YOURSELF. Proudly created with Wix.com