מאת: חיים מיטרני, חוקר PT

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

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

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

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

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

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

ניהול הרשאות על תיקיות

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

דוגמה 1: דפדוף בקבצי json בשרת

המלצה:

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

דוגמה 2: פרטי גישה לשרת הsql

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

המלצה:

• שמירת פרטי חיבור, שמות משתמשים, Connection strings צריכה להיעשות על ידי משתני סביבה ייעודיים בשרת האינטרנט או במשתני סביבה של מערכת ההפעלה
• אין לשמור פרטים אלה כ-clear text

דוגמה 3: חשיפת רשימת סטונדטים וציונים

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

המלצה:

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

הרשאות גישה לשרותי ענן

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

שמות משתמשים והורים כולל כתובת מגורים חשופים לכל

מידע בשרת firebase  שהיה חשוף לעולם בגלל טעות, ניתן רק לשער מה היה קורה אם לא היה נבדק…

המלצות:

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

ניקוי הקוד בסוף הפיתוח

דוגמה 1: פרטים אישיים של מתכנתים נשארו בקוד

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

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

טעות של מתכנת – רווח של האקר. 

שמירת סיסמאות

דוגמה 1: אי הקפדה על היררכית ומורכבות של סיסמאות

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

אם סיסמאות האדמין פשוטות מידי גם הצפנה לא תמנע פיצוח.

סיסמאות גלויות ולא מוצפנות:

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

המלצה:

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

דוגמה 2: יוזרים ב- SQL מוגדרים כ-   DB admin

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

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

לסיכום

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

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

---

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

צרו קשר לקבלת ייעוץ והסבר על השירותים שלנו >>