אילוצים:

• התקנת האמולטור והקבצים הנחוצים להרצת האפליקציות בלבד. כלומר, ללא Android Studio, שמאפשר לבצע כל זה עם GUI, אבל חוץ מזה לא נדרש וסתם שוקל הרבה.
• סביבת העבודה – Linux. אבל התהליך דיי דומה ל-Windows.

הורדה והתקנת האמולטור של אנדרואיד

בעמוד https://developer.android.com/studio/#downloads מופיעים הקישורים להורדת כלים ל- SDK (בחלק של Command line tools only). לאחר ההורדה, כדאי לחלץ את ה- zip (תיקיית tools שבפנים) לתיקיה ייעודית, מכיוון שיהיו הורדות נוספות. לצורך הדגמה יצרתי תיקיה ‎~/android-sdk .

לאחר מכן, צריך להתקין חבילות נוספות – adb, system images, ועוד. נעבור לתיקיית bin, שבה נמצא sdkmanager:

cd ~/android-sdk/tools/bin

רשימת חבילות זמינות להתקנה:

‎ sdkmanager --list

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

sdkmanager "platform-tools"‎

לאחר מכן, התקנת ה- system image לגרסת אנדרואיד הנדרשת. אפשר לחשוב על זה כעל מכונות וירטואליות שהאמולטור מריץ. ישנם גם גרסאות של Android Wear ו- Android TV. בהדגמה זו אני מתקין API בגרסה 26 (אנדרואיד 8.0) ללא Play Store. אני חושב שהדגמה זו תהיה הכי שימושית, מכיוון שלא כל הגרסאות של system image מכילות Play Store. לפעמים הבדיקה דורשת גרסת אנדרואיד מסוימת, ולכן יהיה שימושי לדעת איך להתקין Play Store בצורה ידנית, אם יהיה צורך להוריד אפליקציות דרכו.

sdkmanager "system-images;android-26;google_apis;x86_64"‎

והשלב האחרון – יצירת המכונה (AVD – Android Virtual Device) להרצה באמולטור. נקרא למכונה test1 לצורך הדגמה.

avdmanager create avd -n test1 -k "system-images;android-26;google_apis;x86_64"‎

שווה לערוך קובץ ההגדרות של AVD שיצרנו:

‎~/.android/avd/test1.avd/config.ini

הדבר הראשון שאני תמיד מוסיף, זה אפשרות לבצע שיתוף clipboard בין המכונה ל- host:

hw.keyboard=yes

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

hw.ramSize=1024

רשימת כל ה- AVD המותקנים:

avdmanager list avd

הרצת האמולטור של אנדרואיד

מעבר לתיקיה של האמולטור: cd ~/android-sdk/emulator

הפעלת AVD לפי שם: emulator -avd test1

במידה והאמולטור קורס ומקלל משהו לגבי libGL, אפשר לנסות להריץ האמולטור עם דגל ‎-use-system-libs. זה יגרום לאמולטור להשתמש בספריה libstdc++‎ של המערכת הפעלה ולא אחת שמגיעה עם האמולטור.

דגל שימושי נוסף (בהמשך) הנו ‎-writable-system, המאפשר לערוך את המחיצת ה- system של AVD.

התקנת Play Store

Android Debug Bridge (או בקיצור ADB) מאפשר לתקשר עם AVD מה- host. לדוגמה, להתקין אפליקציות, להעביר קבצים, לראות לוגים, לקבל shell, ועוד. במכונה שיצרנו לא קיים Play Store; נתקין אותו (ללא Google services נוספים) ידנית באמצעות ADB.

קודם צריך להוריד את קבצי האפליקציה מהאתר https://opengapps.org. שם צריך לבחור את החבילה שמתאימה לגרסת האנדרואיד והפלטפורמה. בדוגמה זו הפלטפורמה הנה x64 ואנדרואיד גרסה 8.0. כמו כן, החבילה להורדה תהיה pico, מכיוון שצריך רק את Play Store.

לאחר מכן, צריך לחלץ את הקובץ Phonesky.apk שנמצא בנתיב הבא בתוך ה- zip שירד:

Core/vending-x86_64.tar.lz/vending-x86_64/240-320-480/priv-app/Phonesky/Phonesky.apk

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

emulator -avd test1 -writable-system

התקנת Phonesky.apk

cd ~/android-sdk/platform-tools/‎
החלפה למשתמש root:
adb root
טיעינת המחיצה מחדש כדי לקבל הרשאות כתיבה:
adb remount
כניסה לשורת פקודה באנדרואיד:
adb shell
יצירת תיקיה ל- Play Store:
mkdir /system/priv-app/Phonesky
יציאה משורת פקודה:
exit
העתקת קובץ האפליקציה:
adb push ~/Phonesky.apk /system/priv-app/Phonesky/‎

לאחר מכן צריך להפעיל את Android Shell מחדש:
adb shell stop
adb shell start

עכשיו יש Play Store מותקן:

חשוב להדגיש, שזו לא הדרך הנכונה כדי להתקין אפליקציות רגילות, אלא רק מה שנמצא במחיצת system. אפליקציות רגילות אפשק להתקין בקלות עם הפקודה adb install test.apk.

במידה ומשהו השתבש, אפשר לצפות בלוגים עם הפקודה adb logcat.

הגדרת HTTP proxy ו- GPS

את כתובת הפרוקסי אפשר להגדיר ב- GUI של האמולטור (מסך Settings, לשונית Proxy), או להפעיל את האמולטור עם הדגל ‎-http-proxy <host:port>‎.

השלב הבא הוא התקנת תעודת CA של הפרוקסי. ללא התעודה לא יעבדו שירותים של גוגל, חיבור מייל ועוד. לדוגמה, לא תהיה אפשרות להתקין אפליקציות מ- Play Store.

הזהרה: לא ניתן להשתמש בשלב זה ב- OWASP ZAP בגלל האופן שבו עובד האמולטור של אנדרואיד עם הגדרת פרוקסי. בניסיון התחברות לשרת, האמולטור מציב את כתובת ה- IP של השרת בפקודת HTTP CONNECT, במקום להציב שם את ה- hostname. בתורו ZAP מג'נרט את תעודת SSL עם כתובת IP בשדה Issued to של התעודה. וזה כמובן גורם לתעודה להיות לא תקינה, מכיוון שכתובת ה- IP שונה מה- hostname. זו תקלה בצד האמולטור, ולא של ZAP, שעובד כצפוי. הנה דוגמה לניסיונות התחברות כושלים לשרתים של גוגל, מכיוון שהתעודה לא תקנית. שימו לב שבפקודת CONNECT רשומה כתובת IP ולא hostname.

כשנתקלתי בתקלה זו בפעם הראשונה, קודם כל בדקתי מה יקרה בעבודה דרך burp. הופתעתי לגלות ש- burp יודע להתמודד עם המצב ומייצר תעודה דיגיטלית תקנית גם עם בפקודת HTTP CONNECT רשומה כתובת IP. הנחתי שהוא לוקח את ה- hostname ממקום אחר. הלכתי לערוץ של burp ב- IRC כדי לקבל ייעוץ. מסתבר שהמפתחים של burp כבר מכירים את הבעיה וטיפלו בה:

<pajswigger> We fixed this a few versions back, now if Burp sees an IP address in the CONNECT header, it sniffs the SNI to determine the domain name

נעבוד עם burp אם כך. שלב ראשון – ייצוא תעודת CA של burp:

שלב שני – העתקת התעודה לאמולטור:

cd android-sdk/platform-tools/‎
adb push burp.cer /sdcard

שלב שלישי – ייבוא התעודה. אנדרואיד יבקש להגדיר PIN לפני התקנת תעודה דיגיטלית, ויבדוק אותו במידה ונרצה להתקין תעודות נוספות.

עכשיו הפרוקסי מייצר תעודות תקינות

והאמולטור מעביר תעבורה דרך פרוקסי באופן תקני:

את הקואורדינטות GPS ניתן לשנות בהגדרות האמולטור. זה מאוד שימושי לבדיקת אפליקציות הקשורות למיקום.

מחיקת AVD

avdmanager delete avd -n test1

The post עבודה עם אנדרואיד – התקנת אמולטור first appeared on גיבוב ממולח.

מה זה timing attack

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

$token = get_user_token_from_db();
return ($token === $_SESSION["token"]);

עם שימוש בקוד זה, זמן תגובת השרת ישתנה בהתאם לכמות התווים הנכונים שהמשתמש שלך בערך ה- token (אורך המחרוזת ידוע מראש). זה מכיוון שהשוואת מחרוזות מתבצעת תו מול תו, או יותר נכון בית מול בית, מכיוון שב- PHP השוואת המחרוזות בפועל עובדת עם memcmp. לכן, ההשוואה צריכה להתבצע בצורה הבאה:

$token = get_user_token_from_db();
$len = strlen($token);

if ($len !== strlen($_SESSION["token"])) {
    return false;
}

$result = 0;

for ($i = 0; $i < $len; $i++) {
    // ord returns ASCII value of a char
    $result |= (ord($token[$i]) ^ ord($_SESSION["token"][$i]));
}

return 0 === $result;

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

מתכנת אבטחה

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

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

The post חשיבה מאובטחת first appeared on גיבוב ממולח.

קרדיט: דמיטרי פרץ.

The post אבטחה בסגנון ישראלי first appeared on גיבוב ממולח.

אתם יודעים למה אני לא אוהב את Windows? האמת שבעצמי לא ידעתי לתת תשובה מעמיקה תקופה דיי ארוכה, אבל תמיד ידעתי את זה מאז שעשיתי פירמוט בפעם השלישים בשנה (עוד בתקופת Win98). רק לאחר שיצא לי לעבוד עם המבנה הפנימי של Windows בתחום האבטחה, הבנתי מה הפריע לי כל השנים האלה! הסיבוכיות של המערכת! זה נשמע מוזר, אבל ואני לא מדבר על הידידותיות למשתמש, אלא הארכיטקטורה הפנימית וה- Feature creep. מערכת זו היא דוגמה טובה לעקרון TIMTOWTDI המוכר מ- Perl. לכל חלק במערכת אפשר לגשת במספר דרכים שונות ולפעמים משונות. זה יוצר חוסר אחידות, ולפי דעתי אחת הסיבות למה Windows כ"כ פרוצה – כי כשיש עשר דרכים לעשות אותו הדבר, קשה להגן על כולן.
הנה דוגמה. בשלושת השיטות במאמר זה אשתמש בגישה לקבצים באמצעות ה- UNC. ב- Windows אפשר לגשת לקבצים בשיטה מימי ה- DOS, כלומר הדרך הסטנדרטית (c:\temp\somefile) ואפשר באמצעות נתיב מיוחד שמתחיל ב- \\. חלק מהפקודות ב- Windows יודעות לעבוד עם ה- UNC, חלק לא, וחלק רק עם נתיבים מסוימים ב- UNC. בקיצור, חוסר אחידות ובלאגן.

1. Alternate Data Stream

נתחיל מחימום קל. ADS הוא פיצ'ר של NTFS, שאמור להיות מוכר לכל מי שעסק בסיסטם, התעניין במערכות קבצים והמבנה הפנימי של Windows, או אבטחת מידע באופן כללי. הפיצ'ר מאפשר לשייך יותר מ- data stream אחד לרשומה במערכת קבצים. כלומר, לשם קובץ מסוים ניתן לקשר יותר מאוסף מידע אחד.

נניח שקיים קובץ תמונה: c:\temp\hello.jpg

ניתן לקשר אליו תוכן נוסף, כך שיהיה זמין בנתיב מיוחד הבא, לדוגמה: c:\temp\hello.jpg:world

זה data stream בשם "world" בתוך הקובץ "hello.jpg". כעת אפשר לכתוב ולקרוא מה- data stream הזה. בעצם, בפתיחת הקובץ ב- NTFS, תמיד פונים ל- data stream הראשון (הדיפולטי), אלא אם כן מצוין אחרת. במקרה זה, הראשון הוא התמונה עצמה.

ניואנס אחד – רק תוכנות שמימשו טיפול ב- ADS יכולות לגשת ל- ADS. אם ננסה לקרוא קובץ בשם "hello.jpg:world" בתוכנה שאינה תומכת ב- ADS, זה ייכשל, מכיוון שהיא תנסה למצוא אותו על הדיסק, וקובץ בשם זה לא קיים. כלומר, העבודה עם ADS אפשרית או באמצעות כלים שתומכים בו, או באמצעות שימוש ב- Win32 API בקוד שלכם.

notepad יודע לטפל ב- ADS

mspaint אינו יודע לטפל ב- ADS

היופי ש- Windows Explorer אינו מודע לקיומו של ADS ואינו מציג אותו כלל. אם ניצור מספר data streams בקובץ מסוים עם מידע בגודל כלשהו, הסייר של וינדוס יתייחס רק ל- stream הדיפולטי (הראשון), יציג את הגודל שלו כגודל של הקובץ, ויפתח רק אותו בפתיחת הקובץ. רק תאריך שינוי הקובץ יתעדכן, אבל מי בודק תאריך שינוי באמת?

מוצג רק הגודל של ה- data stream הראשון

אדגים כיצד להסתיר ולהריץ קובץ הרצה בתוך ADS של קובץ JPG. השלבים הם:

1. יצירת ADS חדש עם התוכן של קובץ malware.exe בתוך קובץ hello.jpg;
2. הרצת הקובץ עם הפקודה wmic process call create.

הדגל R בפקודה dir מציג ADS.

שתילת קובץ הרצה כ- ADS של קובץ תמונה.

הבטחתי להסביר על WMIC, או Windows Management Instrumentation. כדי להריץ קובץ, בד"כ אפשר להשתמש בפקודה start. אבל מכיוון שהפקודה הזו לא יודעת לעבוד עם ADS, היא פשוט לא תמצא את הקובץ. לעומת זאת, wmic כן יודע לטפל ב- ADS, ולכן נשתמש בו.

start נכשלת בהרצת קובץ מתוך ADS

יתרונות:

• מוסתר מפני המשתמש;
• קל מאוד למימוש ואינו דורש הרשאות מיוחדות.

חסרונות:

• מי שמחפש – ימצא, במיוחד האנטיוירוסים.

מסקנות:

• משעשע, אך כבר אינו יעיל בהסתרת פוגענים, כי האנטיוירוסים סורקים data streams. יכול להיות שימושי בהסתרת ספריית סרטים אישית.

2. Device files

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

לדוגמה, CON מייצג את console, בדומה ל- dev/tty/ במשפחת יוניקס. אפשר לקרוא ולכתוב לקובץ זה דרך STDIN ו- STDOUT. שליחת מחרוזת תגרום להדפסתה על המסך.

עוד קבצים מיוחדים מהסוג הזה: AUX, NUL, COMx, LPTx.

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

כפי שכתבתי קודם, שמות של קבצים וירטואליים אלה שמורים. אי אפשר ליצור קובץ על הדיסק עם שם כזה. תנסו עכשיו ליצור קובץ בשם CON (שימו לב – ללא extension)… השיטה ליצירת קבצים אלה היא דרך UNC, וזו גם הדרך למחוק אותם.

העתקת סוס טרויאני לקובץ בשם CON:

אי אפשר למחוק קובץ CON בנתיב רגיל

הרצת הקובץ זדוני:

למחוק את הקובץ המיוחד אפשר באותה הדרך כפי שיצרנו, דרך UNC:

del \\.\c:\temp\CON

הפעם שוב היה צורך ב- WMIC, למרות שלא מדובר ב- ADS. וזו הסיבה:

הפקודה start לא מזהה את סוג הקובץ, וזה לא אמור להיות לפי extension, מכיוון שב- ADS ה- extension בכלל לא רלוונטי.

יתרונות:

• אי אפשר למחוק דרך Windows Explorer או שורת פקודה ללא שימוש ב- UNC;
• קל מאוד למימוש ואינו דורש הרשאות מיוחדות.

חסרונות:

• נראה חשוד;
• האנטיוירוסים יודעים לטפל בזה.

מסקנות:

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

3. Volume Shadow Copy

נסיים בתרגילי כוח. VSS, או Volume Shadow Service, הנו שירות ב- Windows המבצע שמירה של בלוקים על הדיסק להעתק שנקרא VSC, או Volume Shadow Copy. זה אותו ההעתק שמופיע באשף שחזור המערכת למצב קודם, או בחירת גרסה קודמת של הקובץ. ה- VSC נמצא במקום שמור על הדיסק, שלא ניתן לראות אותו ב- Windows Explorer ללא יצירת קיצור דרך, אבל אפשר לגשת אליו – ניחשתם נכון – דרך UNC.

הנתיב ל- VSC

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

איך אפשר ליצור Volume Shadow Copy? במידה ומדובר בגרסת Windows למחשב אישי ולא לשרתים, אין דרך מהקופסה ליצור VSC משורת הפקודה, אלא רק דרך GUI (אמנם אפשר להציג VSC קיימים עם הפקודה vssadmin). אל דאגה, מרק באגט וטים טומס כבר חשבו על זה וכתבו כלי שנקרא vssown. הכלי סה"כ משתמש ב- API של Windows כדי לשלוט על VSS.

כעת, ניצור VSC חדש על כל הכונן C, כך שיכיל גם את הקובץ שנמצא בתיקיה c:\temp.

יצירת VSC עם קובץ זדוני

כעת אפשר למחוק את הקובץ המקורי ולהריץ את ההעתק שלו ישירות מה- VSC.

הרצת קובץ מתוך VSC

הגיוני שהאנטיוירוס היה אמור לזהות את הקובץ עם real time protection כשהוא מופעל מה- VSC, אבל בבדיקה עם וירוס eicar, אנטיוירוס Avira לא זיהה שום דבר.
וכן, גם פה יש צורך להשתמש ב- WMIC, כי הוא יודע לעבוד עם UNC.

יתרונות:

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

חסרונות:

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

מסקנות:

• מאוד יעיל בהסתרת הקבצים. שימוש נוסף – הוצאת קבצים מוגנים לקריאה בזמן ריצת המערכת, כמו NTDS.DIT (הבסיס נתונים של Active Directory).

לסיכום

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

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

The post שלוש דרכים מתקדמות להסתיר קבצים ב- Windows first appeared on גיבוב ממולח.

מערכות ההפעלה של גוגל ואפל, אנדרואיד ו- iOS, שתיהן ממשפחת מערכות UNIX (יותר נכון UNIX-like), שהיא בעלת מערכת הרשאות שנחשבת לבטוחה יותר מזו של Windows. למרות המקורות הדומים, בחרו אפל וגוגל בשתי גישות מנוגדות בפיתוח מערכות ההפעלה שלהן: אפל בחרה עבור ה iPhone במערכת הפעלה סגורה ומקודדת, שמאפשרת הורדת אפליקציות אך ורק מה Appstore, חנות האפליקציות הרשמית של אפל, שם כל אחת מהן נבדקת בקפדנות לפני שהיא מקבלת את האישור הסופי. גוגל בחרה במערכת הפעלה בעלת קוד פתוח, שמשמש לא רק את יצרניות הסמארטפונים, אלא גם אנשים פרטיים בפיתוח של גרסאות שונות שלה.

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

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

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

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

התקפות כנגד מערכת ההפעלה אנדרואיד

ראשית יש להזכיר שאת הקובץ הזדוני אפשר לשלוח לקורבן דרך וואטסאפ, SMS וכדומה, ולא בהכרח להעלות לחנות האפליקציות. לא לחינם הזכרתי SMS – חשבתם לשלוח לקורבן את הקובץ מהפאלפון שלכם? טעות… למה לקחת סיכון אם יש היום אתרים שייתנו לכם לשלוח SMS דרך האינטרנט, ולהיות קצת יותר אנונימי (בין אם זה ע"י TOR או שיטות אחרות לזיוף ה- IP וכתובת ה-MAC).

אתר לדוגמא לשליחת SMS חינם לכל העולם: http://www.afreesms.com/freesms

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

AndroRAT

כדוגמת "DarkComet" ו- "CyberGate" שהן מערכות RAT למחשב, יצאה גם גרסת קוד פתוח לאנדרואיד. הרעיון הוא אותו הרעיון: שולחים לקורבן את הקובץ (ניתן לשים את הסוס טרויאני כחלק מאפליקציה מסוימת, או כל משחק, ללא מאמץ מרובה ע"י ממשק נוח שנבנה – ראו תמונה). אז מה יכול לעשות התוקף ברגע שפתחתם את הקובץ? כמעט הכול. להפעיל את המצלמה ואת המיקרופון; לגשת לכל המידע על המכשיר, כמו אנשי קשר, תמונות והגדרות; הוא יכול לראות את ה- IEMI (מסוכן מאוד, מכיוון שכך ניתן לחסום את המכשיר).

פאנל ניהול לשרת С&C

RazStealer

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

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

1. http://www.apkprotect.com
2. http://www.decompilingandroid.com/secure-your-android-app

עבדכם הנאמן בנה וירוס והצפין אותו והנה התוצאות:

לפני ההצפנה:

https://www.virustotal.com/he/file/9d123a4d84827a60c8b7920aac9d8bfdd0ffec841743544eaf8b9813fcd2c47d/analysis/

תוצאה: 4/47

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

אחרי ההצפנה:

https://www.virustotal.com/he/file/c7f7c8bb716fea224decdfc286dc70880ae84554507658ffa623a92b5209c8da/analysis/1382045699/

תוצאה: 2/47

רק 2 אנטי וירוסים (Avast ו- Sophos) זיהו את הקובץ כוירוס. זה אומר, שאם יש לכם אנטי וירוס על הפאלפון הוא לא שווה הרבה ומספיק שהייתה הצפנה נוספת על הקובץ, ספק אם אחד מהאנטי וירוסים היה מתריע.

דרכי התגוננות באנדרויד

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

ההתגוננות היא לא לפתוחSMS מאנשים שאתם לא מכירים. ואם כבר נכנסתם וכתוב שזה אפליקציה חדשה של mako ובאתם להתקין את האפליקצייה, אז קורה הדבר הבא: הדף שאתם תמיד מאשרים הרשאות ולא קוראים צץ. תקראו מה הוא דורש – לא הגיוני ש- mako (לדוגמה) מבקשים הרשאות של גישה למצלמה ול- SMS.

להלן דוגמא של מספר הרשאות בלתי מבוטל:

התקפות כנגד מערכת ההפעלה iOS

גם מכשירי iPhone שמריצים את מערכת ההפעלה iOS אינם חסינים מפגיעה. רבים מהמשתמשים ב- iPhone "פורצים" את ההגנה שלו (Jailbreak) באמצעות כלים אוטומטיים על מנת לאפשר הורדת אפליקציות שלא מה- AppStore. הפריצה מאפשרת גישה מלאה למכשיר, בדומה לגישה הקיימת במרבית הסמאטפונים מבוססי אנדרואיד.

כאשר המערכת iOS לא נפרצת ע"י המשתמש, מעטים הרוגלות שאפשר להריץ עליה.

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

איך זה מתבצע? אם פרצתם את המכשיר, חשוב מאוד לשנות את סיסמת ברירת המחדל של משתמש root. במהלך הפריצה הסיסמה מאופסת לסיסמת ברירת מחדל "alpine", והאקרים יכולים להשתלט על מכשיר פרוץ כזה בקלות במהלך שימוש ברשת ציבורית. ע"י קבלת ה- IP של המכשיר שלכם (ניתן לבצע ע"י תוכנה פשוטה Wireless Network Watcher) וע"י השמת השם משתמש והסיסמא של הבירית מחדל ההאקר מבצע את זממו.

הקשחת משתמש root באייפון

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

http://www.iphoneil.net/?p=61859

לסיכום

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

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

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

The post סוס טרויאני אצלכם בסמארטפון first appeared on גיבוב ממולח.

"A horse, a horse, my password for a horse!"

שכתוב שייקספיר

הרשת מלאה בתוכנות פריצה לפייסבוק. הבטחות ל- 100% פריצה ופיצוח הקוד או הסיסמה לפרופיל מושמעות בכל פורום, למזלנו ישנם תוכנות בודדות (מאוד!) שבאמת עובדות. מעבר לזה, רובם מכילות וירוסים כדי להפיל "פורצים" חובבניים. רוב התוכנות, גם במידה והן עובדות, מוצאות את דרכם לג'אנק האינטרנט מהר מאוד, הפייסבוק עולה על חור האבטחה ומנטרל אותו תוך מספר ימים מזמן הגילוי שלו.

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

ישנן מספר שיטות לקבל גישה לחשבון משתמש:

1. Brute force

הדרך הישנה והלא מתוחכמת – ניחוש הסיסמה ע"י נסיונות חוזרים ונשנים. איך זה מתבצע?

את התוכנה לסריקת הסיסמאות מזינים ע"י:

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

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

תוכנת brute force בפעולה (Hydra)

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

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

• אותיות גדולות וקטנות
• ספרות שונות
• סימנים שונים
• שפה שונה
• סדר רנדומלי

ככל שתשלבו יותר מהפרמטרים הללו כך הסיסמה תהייה יותר קשה לפיצוח (ברמה של בלתי אפשרית). דוגמא לסיסמה חזקה מאוד ולא מוגזמת היא "Udont4ME!0".

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

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

2. Phishing

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

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

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

• בניית אתר המדמה את האמיתי, שכוללת הפנייה פנימית של לינקים ומעבר לדף באתר המקורי לאחר הזנת הפרטים כדי לשפר את האמינות.
• מעבר לכך, לאחר הזנת הפרטים שלכם לא יופיע שלט "אה אה אה עבדתי עליכם, אני פורץ!", אלא אתם תועברו לאתר המקורי בדיוק לדף הספציפי שהייתם אמורים להגיע. הדף המזויף שימש באמת להזנת הפרטים, לאימות עם השרת של פייסבוק ולהעברת הגולש לדף הרלוונטי, רק שבדרך, לפני שליחת הפרטים שהבאתם לאתר המקורי לאימות, הפורץ נותן פקודה לרשום אותם אצלו בצד.
• עיצב האתר שיהיה זהה ככל הניתן ונאמן למקור. זהו החלק הפשוט יחסית. אין צורך ליצור שום דבר חדש, פשוט לקחת ולהעתיק את כל המלל, מבנה והגרפיקה מהאתר המקורי ולהעתיק אותם באופן זהה לאתר הדמה של הפורץ.
• היבט אחרון הוא קניית דומיין הדומה ויזואלית ככל הניתן למקור כדי שהקורבן לא יבדיל. לדוגמא – facehook.com ,face.book.com, או faceb00k.com. שימו לב ששום דומיין כאן הוא לא המקורי, הם כתובים בצורה מאוד זהה למקור מבחינת העין שקוראת את המילה. הדוגמאות שהבאתי מאוד אטראקטיביות, מכיוון שהן מאוד דומות לדומיין המקורי. לרוב, הפורצים לא ישקיעו כל כך בזיוף הכתובת ולא יקנו כתובת תקנית, מכיוון שכתובת תקנית צריכה להיות רשומה על שם של מישהו. ומכיוון שזה דבר שכרוך בתשלום (מסנן אוטומטית ילדים בני 16 שרוצים לפרוץ לשם ההנאה) לרוב הכתובות יהיו על דומיינים חינמיים או סאב דומיין.

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

אחד הכלים השימושיים ליצירת אתר כפיל – SET

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

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

בהזדמנות זו ארצה להזכיר שבזמן האחרון לפייסבוק יש מערכת שלא תאפשר לפורצים לשלוח לינק לדף פישינג בצ'אט. יותר מזאת, היא מעדכנת את הדפדפן גוגל כרום בדף הזדוני והוא מוגדר כמסוכן, אבל כמו שאתם יודעים, רוב ההאקרים מצאו דרך מקורית מאוד לעקוף את זה. ע"י קידוד והסתרה של דף הפישינג, מנגנון האבטחה של פייסבוק לא מזהה את הדף הזדוני. בין האתרים שמקודדים ומצפינים את הכתובת לאתרכם: http://link-safe.net.

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

http://link-safe.net/out/0e70a473-0a4a/269671

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

3. פריצה לאימייל

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

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

אילו פרטים מזהים הוא דורש ואיך אני מסתיר אותם מפני פורצים?

1. שם משתמש לדואר;
2. תאריך לידה;
3. פרט זיהוי – יכול להיות אחד מהבאים: שם אמא, אבא, חבר הכי טוב, שם סרט אהוב, פתגם אהוב, ספר אהוב, דמות אהובה מסרט וכו'.

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

1. את שם המשתמש לדואר שלכם אפשר לאתר בקלות ע"י ידיעת כתובת הדואר (ב- Gmail זה לא חייב להיות כך). את שם המשתמש אפשר לאתר בקלות: שם משתמש כאן – example@walla.co.il, יהיה כאמור example.
2. את תאריך הלידה שלכם אפשר למצוא ע"י תוכנה שמופצת ברשת בשם "רישומון" – תוכנה שכוללת את כל מרשם האוכלוסין של מדינת ישראל, שם תמצאו ת"ז של אנשים, תאריכי לידה ועוד פרטים מועילים. כמובן שאפשרי להשיג את המידע ע"י שיחה טלפון אליכם. או קחו לדוגמא מצב שנגש אליכם בחור/ה מהמין השני שטוענת שמתעניינת באסטרולוגיה, או שאומרת לכם שהיא בדיוק גם מזל שור ושואלת לגבי מה התאריך המדויק שלכם – אני אספר לכם משהו? אתם תתנו את התאריך ובלי מחשבה אפילו. הנורמה החברתית אומרת שזה פרט שולי שאין בעיה לספר אותו ואתם תספרו ואפילו תשמחו לספר כדי שידעו מתי יום ההולדת שלכם (במיוחד אם זה בחור/ה אטרקטיבית).
3. פרט הזיהוי הוא עקב אכילס פה – מצד אחד זה אמור להיות פרט שאתם תמיד תזכרו, כדי שתוכלו להחזיר לעצמכם את הסיסמה, מצד שני הפרט שאתם תמיד תזכרו צריך להיות כזה שאם שואלים אתכם עליו ישר תדלק לכם נורה אדומה. אם שמתם פרט זיהוי שהוא שם אבא/אמא או דברים שכן הגיוני שישאלו אתכם, לדוגמא "יוו אני חושב שאני מכיר אותך, לאמא שלך קוראים שרה? – לא, קוראים לה בכלל לאה." הופ, חשפתם את מנגנון האבטחה האחרון (והפשוט יש לומר) שלכם. לכן, כדאי לבחור שאלת זיהוי לא פשוטה, שאין שום סיבה הגיונית שבעולם שתגידו אותה ללא תמרור אזהרה ברור שיהיה לכם מול הפנים. ככל שתהיו חשאיים יותר, כך הפורץ יהיה צריך להיות מחוכם יותר. כך שאם כבר יפרצו לחשבון שלכם, לפחות זה יהיה אחרי מאבק מתיש. חשבו על פרט זיהוי שלא תשכחו מצד אחד, אבל שלא תספרו לאחרים מצב שני.

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

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

הערת העורך: רגע, ומה אם בשיטה זהה השיגו את הגישה למייל האישי שאיתו קיבלו גישה למייל של וואלה שדרכו אני נכנס לפייסבוק? התבלבלתי… ס_ם

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

בתמונה מרשם האוכלוסין של מדינת ישראל ובו מידע יקר ערך על רוב הישראלים
מקור: http://up353.siz.co.il/up1/fynqkm5j5t2y.png

4. רשתות ציבוריות

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

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

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

תוכנה ידועה בשם Wireshark להאזנה לתעבורת הרשת

היום מצויות תוכנות פשוטות כגניבת ה- cookies (בהם נשמרים פרטי הזדהות). ביניהן תוכנות כדוגמת FaceNiff או Firesheep.

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

הערת העורך: אם כבר גולשים לאתר הדורש פרטי הזדהות שאכפת לנו מהם, אז לפחות רק אם האתר הזה עובד ב- HTTPS. שגם את זה אפשר לעקוף, דא"ג, כמו ע"י SSL null-prefix attack (יש וידאו בסוף הפוסט על הנושא הזה), או קניית דומיין (כפי שנכתב בחלק על פישינג קודם) ויצירת תעודת SSL מתאימה, כך שיראה לגיטמי.

5. תוכנות ריגול

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

לסיכום

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

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

http://www.breaksec.com/?tag=facebook

פינת השכלה כללית

בפרק 4 הזכרתי מתקפה מסוג SSL null-prefix. זו שיטה מאוד מעניינת שהוצגה ע"י מוקסי מארלנספייק בדפקון 17. מומלץ בחום:

The post גניבת חשבונות for dummies first appeared on גיבוב ממולח.

לא מדובר על הפרעת קשב וריכוז, אלא על Active Defense Harbinger Distribution. זה לא ממש "חדשות", אבל לא כולם שמעו כבר על הפצת לינוקס זו. מטרתה היא לאגד כלים שונים להגנה אקטיבית. לדוגמה, יכולת לסבך כלי סריקות ע"י יצירת עמודים אקראיים על קישורים מחזוריים (Spidertrap); למידה על התוקף באמצעות הזרקת applet שסורק רשתות WiFi בקרבת מחשבו של התוקף (Honeybadger); סינון אוטומטי של כתובות IP המתחברות לפורט "מלכודת" (Bear Trap) ועוד. הפרויקט מומן ע"י DARPA.

האתר הרשמי והורדה.

ראיון עם היוצרים של ADHD בפודקאסט PaulDotCom:

Nmap – גרסה 6.40

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

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

• http-fileupload-exploiter, המממש טכניקות שונות כדי לרמות את מגבלות העלאת הקבצים באפליקציות ווב;
• http-phpmyadmin-dir-traversal, המנצל חולשה ב- phpMyAdmin גרסה 2.6.4pl1 כדי להוריד קבצים פנימיים מהשרת;
• http-stored-xss, המחפש חולשת Stored XSS באתר.

רשימה מלאה של עדכונים והורדה.

Burp Suite – גרסה 1.5.15

עדכון לאחד הכלים הנפוצים מסוג HTTP proxy, המכיל גם פיצ'רים רבים לביצוע vulnerability assessment.

בגרסה החדשה נוספו יכולות מעניינות, כגון:

• אפשרות להעביר חיבורי SSL לשרת יעד ללא ביצוע intercept (היכולת שימושית עבור אפליקציות שלא עובדות טוב עם תעודת SSL של burp);
• חוקי interception חדשים;
• תמיכה בתוסף Plug-n-Hack שיאפשר אינטגרציה נוחה יותר בין כלי proxy לבין הדפדפן.

העדכונים בינתיים רק עבור גרסת professional.

נלקח מהאתר הרשמי של Burp Suite

רשימה מלאה של העדכונים והורדה.

The post מבזק עדכונים 25-09-2013: ADHD, Nmap, Burp Suite first appeared on גיבוב ממולח.

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

הנסיון לוויתור על הסיסמה (או: אבולוציית ההזדהות)

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

בהתאם, שידור מלא או חלקי של הסוד איננו מוגן גם אם הוא מתבצע על גבי תווך מאובטח כגון TLS או IPSec, אשר הוא לכאורה השלב הטבעי הבא בחיזוק ההגנה על ההזדהות. תווך מוצפן איננו פותר בעיה עקרונית בפרוטוקול ההזדהות. קודם כל, מאחר וההנחה הבסיסית היא שתווך מוצפן ניתן לעקוף. למשל, כי ניתן לקלוט את השידור בקצוות (אולי קשה, אבל אפשרי), לתקוע טריז באמצע (Man In The Middle) או תיאורטית (ומעשית?) לפרוץ אותו. אך יש בעיות המטרידות אותנו יותר בפרוטוקול כגון TLS. בשימוש בפרוטוקול כזה, אנחנו מניחים שלאחר שיצרנו קשר מוצלח עם השרת מהצד השני, ניתן לסמוך עליו, אבל לא בטוח שוידאנו את הזהות שלו כמו שצריך ויתכן שהוא מתחזה. למשל, במידה ואנחנו סומכים על תעודה אשר נחתמה ע"י גורם אשר לא התכוונו לסמוך עליו תמיד. זה יכול לקרות אם גורם זדוני הצליח "להזריק" תעודה זדונית למאגר התעודות שלנו (Trusted Certificate Store), או אם גורם זדוני פרץ את שרשרת התעודות ומסוגל לחתום על תעודות חדשות אשר לכאורה כשרות לכל דבר ועניין – ראו בעיית זיוף חתימה דיגיטלית (אינספור קישורים באיטרנט, למשל כאן, כאן וכאן) והמלצת NIST עוד מ- 2010 להפסיק להשתמש ב- SHA1 מספר שנים אחרי שהפסקנו להשתמש ב- MD5 מסיבה דומה. יש כאן שורה של הנחות נסתרות אשר ניתן עקרונית לפרוץ ולעקוף, גם אם במאמץ מורכב. נכון, לא כיסיתי כאן את כל האפשרי והפריצות שנתתי כדוגמה אינן טריוויאליות. אבל למי שמבין את קשת האפשרויות, הרעיון צריך להיות ברור.

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

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

ארגון DARPA ממליץ עקרונית על הפסקת שימוש בסיסמאות לטובת הזדהות ביומטרית ולמעשה איננו "מחזיק" משימוש בסיסמאות, גם כפקטור נוסף. אבל באופן דומה למתואר לעיל, גם שיטת הזיהוי הביומטרי איננה נטולת בעיות. חישבו על כך שמדובר, עקרונית, בהזדהות באמצעות "סוד" אשר אדם נושא עימו. למשל, טביעת אצבע. אם האדם משדר את הסוד במלואו לגורם מולו הוא מזדהה, הרי שהוא חושף את הסוד כך שניתן עקרונית להקליט אותו ולשדר שוב (Replay Attack) לצורך התחזות. אם הגורם המזדהה איננו משדר את הסוד במלואו, הרי שצריך לפתור את הבעיה בדרך אחרת, כגון כך שסומכים על החומרה בנקודת הקצה שתהיה אמינה, אך גם את פתרון זה ניתן לעקוף. מאמינים שטכנולוגיית הזדהות ביומטרית מתוחכמת מספיק? פוסט משעשע זה מסביר בעקיפין שממש לא. פתרון עדיף ברמה התפישתית לבעיות הנ"ל עשוי להיות בדמות שימוש בפרוטוקול מבוסס הוכחת אפס מידע. הרעיון הוא שניתן מתמטית להוכיח ידיעת סוד מבלי להציג אותו, ובדרך טובה יותר מאשר הסתרה חלקית של הסוד כגון Digest. שילוב פוטנציאלי בין הזדהות ביומטרית לבין פרוטוקול מבוסס הוכחת אפס מידע נראה כמו רעיון מבטיח, אבל ייקח כנראה עוד זמן מה עד שנראה פרוטוקולים כאלו בפעולה בשימוש רחב.

דילמות ההזדהות כיום

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

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

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

הזדהות אקטיבית

לפני כחצי שנה בלבד יצאה גוגל בהצהרה שהכתה גלים בחדשות וברשתות החברתיות על הכוונה לבטל לאורך זמן את השימוש בהזדהות מבוססת סיסמה לטובת הזדהות באמצעות מכשיר נייד. נדמה שהן מומחים והן הדיוטות הגיבו בתמיהה על הידיעה: הזדהות כפי זו שגוגל רוצה לקדם, כך נראה, תהיה ממש הזזת הבעיה למקום אחר של הגנה על מכשיר נייד (something you have) במקום על סיסמה. חברות נוספות, כגון SlickLogin, מתעתדות להציע פתרון דומה. ארגון DARPA, לעומת זאת, יצא לפני שנה וחצי עם מכרז לבניית הזדהות אקטיבית: זיהוי משתמש בהסתמך על דפוסי התנהגותו בשימוש במחשב. אחד מאנשי הארגון פישט את הרעיון כך: גם אם נכנסתם לבית בעזרת מפתח גנוב, זה לא ישכנע את כלב הבית, חיית המחמד של הדיירים, שאתם הבעלים של המקום. נראה כי חברה אחת עמדה בדרישות המכרז של DARPA ופתחה בתהליך נסיון הפיתוח של טכנולוגיה כזו, אך נחכה עוד זמן מה כדי להיווכח האם הנסיון מוצלח. לבינתיים, אפשר להשתעשע במחשבות כיצד יראה המימוש של כלב ששומר לנו על הבית לצורך הזדהות. אולי ככה?

מידע נוסף אודות הזדהות אקטיבית

נציג DARPA מדבר על הזדהות אקטיבית:

מצגת מכנס RSA שבו הציגו את התכנית:

https://www.rsaconference.com/writable/presentations/file_upload/sec-t05_final.pdf

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

The post הזדהות אקטיבית (או: מדוע הזדהות בטוחה עדיין כל כך מסובכת) first appeared on גיבוב ממולח.

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

יום כיף בירושלים

היינו ביום כיף בירושלים. אני. גידי ויגו. בירה. ישבנו כמו תמיד בפסטה בסטה, בתוך השוק. אינני שתיין מוצלח במיוחד וכבר באמצע הבירה הראשונה הייתי חייב ללכת לשירותים. לשירותים היה מנעול עם קוד אבטחה. בפעם האחרונה שראיתי מנעול כזה היו עליו 8 ספרות. המנעול הזה כלל 10 ספרות וגם כמה אותיות! ביקשתי מהמלצרית את הסיסמא והיא הביאה לי פתק קטן שאותו לקחתי איתי כדי להקיש את הקוד. בעודי משיב את אוצרותיי לטבע החלטתי לשנן את הקוד בעל פה. התחלה של חמצן – CO, עשר שנים פחות משנת הלידה שלי – 72, כפול חמש אבל הפוך – 5X. יצאתי והחזרתי למלצרית את הפתק עם הסיסמא: CO725X.

גידי נכנס לעניין

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

ססמאות בירושלים. בתמונה (מימין לשמאל): גלעד תעסה, ניר ימיני, גידי ויגו.

למה מצפים מאיתנו לזכור כל כך הרבה סיסמאות?

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

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

כשל אבטחתי אינסופי

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

כנראה שלעולם לא אדע את התשובות לשאלות הללו.

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

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

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

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

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

The post מחשבות על אבטחה מנקודת מבטו של המשתמש הפשוט first appeared on גיבוב ממולח.

במהלך כתיבת פוסט זה נתקפתי מספר פעמים ע"י תחושת déjà vu. אולי בגלל שאני מרגיש שעם שיטות ההגנה כיום אנחנו עדיין מפדלים במקום, אולי בגלל חולשות מיושנות (אך עדיין נפוצות) שקיימות לחלק מהבוטנטים בממשק ניהול, ואולי פשוט כי יש לי bad sectors בזכרון לטווח ארוך.

איך מגלים סוסים טרויאנים?

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

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

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

שיטות אקטיביות לבדיקה האם המחשב שייך לבוטנט

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

• רוב הבוטנטים מדווחים לשרת ווב רגיל (שרט השליטה) בעל תצורה של PHP + MySQL;
• תוכן המסר המועבר מהבוט לשרת מוצפן ברוב המקרים על ידי מפתח שהופץ עם הבוט עצמו (pre-shared key), אך התעבורה היא HTTP רגיל;
• כול רכיבי הבוטנט, גם השרת וגם הבוט עצמו, נכתבים לרוב על ידי תכניתן אחד.

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

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

1. Cross-site scripting

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

פאנל ניהול של מערכת לגניבת סיסמאות

מכירים XSS? מגניב! אז למה לא להשתמש בווקטור התקיפה הנהדר הזה כדי ששרת הבוטנט ידווח לנו האם במחשב הודבק? המטרה היא לשנות אחד מנתונים הנאספים ע"י הבוט לקוד שירוץ בעת ההתחברות של מנהל הבוטנט לפאנל ניהול. במילים פשוטות – Stored XSS.

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

S'il vous plaît!

לצורך הדגמה, שמרתי ב- Firefox פרטי הזדהות, כאשר שם המשתמש הינו ה- Hello World של עולם ה- XSS:

admin<script>alert(1)</script>

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

מה?! שם המשתמש שלי הוא באמת admin<script>alert(1)</script>

Voilà

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

<script src="http://www.saltedhash.co.il/trap.php"></script>

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

חושי העכביש אומרים לי שנדבקתי

מפה ניתן להבין שמישבו פתח פאנל ניהול של הבוטנט בכתובת 10.0.1.2 ואז רץ הסקריפט ששתלתי במאגר סיסמאות של Firefox.

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

אך שיטה זו אינה מספיקה ואף דורשת השקעת זמן וכוח. לא כול פאנל ניהול פגיע ל- XSS; לא כול פאנל ניהול הוא אתר – יש כאלה שהם אפליקציה על מחשב (למרות שגם במקרה זה אפשר לחשוב על קלט זדוני, אך זה יהיה יותר קשה); בסופו של דבר, לא כול בוטנט בכלל אוסף מידע – יש כאלה שרק ממתינים לפקודות של ה- bot master לביצוע פעולה מסוימת, כמו תקיפת DoS.

אל דאגה, חשבתי על עוד דרך גילוי פשוטה יחסית!

2. ניטור תעבורת הרשת

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

fHGASMMz yourself!

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

את ניתוח התעבורה אני ממליץ לעשות עם שני כלים – Wireshark שבעל יכולת סינון מתקדמת, אך אינו מודע לתהליך שיוצר את התעבורה, והכלי של SysInternals בשם Process Monitor שיכול לסנן לפי תהליך. מידע על כלים אלו וקישורים להורדה ניתן למצוא בעמוד רשימת כלי אבטחת מידע.

מזל שאני לא על מודם סלולרי

לא זוכר שהתחברתי לאתר 10.0.1.1 מתישהו

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

עכשיו אפשר לחסום את הכתובת של שרת השליטה (C&C) ב- Firewall ולמנוע דלף מידע נוסף.

מניעת הדבקות

עכשיו שגילינו ששויכנו לבוטנט כזה או אחר, או אפילו כמה, ופירמטנו את המחשב (It's the only way to be sure. © Ripley), איך נמנע הדבקות חוזרת? בפסקה הראשונה כתבתי שלרוב אנטיוירוס לא יצליח לזהות סוס טרויאני מתקדם (בין אם הוא פולימורפי או משתמש ב- 0day).

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

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

אילו תוכנות נבדקות? לרוב זה IDA ו- Wireshark. אז אפילו אם אתם לא עוסקים בתקשורת או רברסינג, כדאי להתקין תוכנות אלו (או ליצור את התיקיות והרשומות ב- registry) כדי לצמצם את סיכויי ההדבקות.

a la guerre comme a la guerre

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

1. השטלתות על פאנל ניהול

אם גילינו את כתובת שרת השליטה באמצעות תקיפת XSS, למה לא להתחבר אליו? הרי בדרך כלל שרת השליטה והפאנל ניהול הם אותו אתר. אפשר לנסות פרטי הזדהות admin // admin ויש לזה סיכוי להצליח אם מדובר על ילדים שלא יודעים מה הם עושים. דרך יותר בטוחה, וצריך לחשוב עליה מראש, זה ליצור קוד XSS שלא רק ידווח לנו שהודבקנו ומה כתובת שרת השליטה, אלא גם תשלח לנו את ה- cookie של מי שהתחבר לשרת. ובמקרה שמשעמם לכם, אפשר לחפש את הקוד של פאנל ניהול ברשת ולנסות למצוא חולשות בבדיקת פרטי הזדהות.

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

2. SQL Injection

זוכרים את השם משתמש שלי? כן, זה:

admin<script>alert(1)</script>

אז יש לי עוד אחד:

admin'; DROP ALL TABLES;--

מה, אחלה שם משתמש! והשאר אני משאיר לדמיון שליכם.

לסיכום

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

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

אפילו יש בוט אחד מישראל

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

נ.ב. למי שהתעניין בנושא, הנה מקור נחמד לסקירת בוטנטים חדשים שיוצאים: http://malware.dontneedcoffee.com.

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

The post האנטומיה של בוט, פרק 2: ההגנה הכי טובה היא התקפה first appeared on גיבוב ממולח.