פישינג בתוך Phishing Toolkit

כותרת משנה: הגונב מגנב פטור?

בכדי לגנוב (מידע) צריך לעבוד קשה. או שאולי כבר לא.

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

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

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

פריצה לבסיס נתונים: קשה או קל?

מומחי אבטחת מידע רבים טוענים שקל לפרוץ לבסיסי נתונים (בין אם ישירות ע"י גישה ל – DB ובין אם דרך אתרים). התקפות שונות כגון SQL Injection (הזרקת קוד SQL עוין) או Cross Site Scripting (התקפה המכונה XSS בה שותלים סקריפטים עוינים באתרים) מאפשרות התקפות על אתרים ובסיסי נתונים. ובאמת, ישנם הרבה מומחים ואתרים המוכיחים כמה קל לבצע התקפות כאלה ואחרות.

אינני מנסה לטעון שזה לא נכון וגם אינני יכול לטעון שמהערכות שלנו מאובטחות ב – 100%. אבל הנה חומר למחשבה:

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

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

שיקולים בבחירת פתרונות Database Security

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

הצפנה

• מצריכה שימוש בתוכנה – עלות לא קטנה.
• ניהול מפתחות הצפנה, גיבוי, ואבטחת המפתחות – לא טריוויאלי.
• דורשת תכנון קפדני מה לא להצפין (האם אפשר להצפין אינדקסים? Primary Key?).
• כיצד אפליקציות יידעו לפענח הצפנות?
• אבחנה בין משתמש שמגיע למידע דרך אפליקציה (שאמור לראות מידע רגיש) לבין אותו משתמש שמגיע ב – SQL (לא דרך אפליקציה ובמקרה כזה לא אמור לראות מידע רגיש).
• אפשרות להפריד בין ניהול התוכנה  (ברמת Administrator) לבין ניהול ההצפנה/מפתחות (למשל, כדי ש – DBA לא יוכל לראות מידע רגיש). 

הגבלת הרשאות

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

פתרון ברמת/שכבת בסיסי הנתונים

• עלול להיות מוגבל ביכולות (לא Granular).
• עלול לצרוך משאבי CPU רבים.
• האם מצריך התקנות רבות?

פתרון רשתי

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

אתם מוזמנים להוסיף שיקולים משלכם. 

לתפוס או למנוע?

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

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

• להגדיר Audit על מחיקת קבצים מספריה (NTFS) מסוימת ואז אם הוא מחק קובץ יש תיעוד על כך

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

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

איזה גישה יעילה יותר?