סריקת פגיעות ופיתוח מאובטח. חלק 1

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

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

Процессы

תהליך ניהול הפגיעות מיועד לניטור רציף של אבטחת תשתית וניהול תיקונים.
תהליך Secure SDLC ("מחזור פיתוח מאובטח") נועד לשמור על אבטחת אפליקציות במהלך הפיתוח והתפעול.

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

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

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

כלי עבודה

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

קופסה שחורה

בעת סריקת Blackbox, הכלי חייב להיות מסוגל לעבוד עם השירות דרך אותם ממשקים שדרכם משתמשים עובדים איתו.

סורקי תשתית (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose וכו') מחפשים יציאות רשת פתוחות, אוספים "באנרים", קובעים גרסאות של תוכנות מותקנות ומחפשים במאגר הידע שלהם מידע על נקודות תורפה בגרסאות אלו. הם גם מנסים לזהות שגיאות תצורה כמו סיסמאות ברירת מחדל או גישה פתוחה לנתונים, צפני SSL חלשים וכו'.

סורקי יישומי אינטרנט (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP וכו') יכולים גם לזהות רכיבים ידועים וגרסאותיהם (לדוגמה, CMS, מסגרות, ספריות JS). השלבים העיקריים של הסורק הם זחילה וטשטוש.
במהלך הסריקה, הסורק אוסף מידע על ממשקי יישומים קיימים ופרמטרי HTTP. במהלך ה-fuzzing, נתונים שעברו מוטציה או שנוצרו מוכנסים לכל הפרמטרים שזוהו על מנת לעורר שגיאה ולזהות פגיעות.

סורקי יישומים כאלה שייכים למחלקות DAST ו- IAST - Dynamic and Interactive Application Security Testing, בהתאמה.

קופסה לבנה

ישנם הבדלים נוספים בסריקת Whitebox.
כחלק מתהליך ה-VM, לרוב ניתנת לסורקים (Vulners, Incsecurity Couch, Vuls, Tenable Nessus וכו') גישה למערכות על ידי ביצוע סריקה מאומתת. כך, הסורק יכול להוריד גרסאות חבילה מותקנות ופרמטרי תצורה ישירות מהמערכת, מבלי לנחש אותם מבאנרים של שירות רשת.
הסריקה מדויקת ומלאה יותר.

אם מדברים על סריקת Whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs וכו') של אפליקציות, הרי שבדרך כלל מדברים על ניתוח קוד סטטי ושימוש בכלים מתאימים ממחלקת SAST – Static Application Security Testing.

בעיות

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

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

בעיות בסריקת אפליקציות אינטרנט

1. קושי ביישום. יש לפרוס, להגדיר, להתאים סורקים לכל אפליקציה, להקצות סביבת בדיקה לסריקות ולהטמיע בתהליך ה-CI/CD כדי שזה יהיה יעיל. אחרת, זה יהיה הליך רשמי חסר תועלת שרק יפיק תוצאות חיוביות שגויות
2. משך הסריקה. אפילו בשנת 2019, סורקים עושים עבודה גרועה בביטול כפילויות של ממשקים ויכולים לבלות ימים בסריקת אלף עמודים עם 10 פרמטרים על כל אחד, תוך התחשבות בהם שונה, למרות שאותו קוד אחראי עליהם. יחד עם זאת, ההחלטה על פריסה לייצור בתוך מחזור הפיתוח חייבת להתקבל במהירות
3. המלצות גרועות. סורקים נותנים המלצות כלליות למדי, והמפתח לא תמיד יכול להבין מהם במהירות כיצד להפחית את רמת הסיכון, והכי חשוב, האם צריך לעשות את זה כבר עכשיו, או שזה עדיין לא מפחיד
4. השפעה הרסנית על היישום. סורקים עשויים בהחלט לבצע מתקפת DoS על אפליקציה, ויכולים גם ליצור מספר רב של ישויות או לשנות ישויות קיימות (לדוגמה, ליצור עשרות אלפי תגובות בבלוג), כך שלא צריך להפעיל סריקה בלי מחשבה בייצור
5. איכות נמוכה של זיהוי פגיעות. סורקים משתמשים בדרך כלל במערך קבוע של מטענים ויכולים בקלות לפספס פגיעות שאינה מתאימה לתרחיש ההתנהגות הידוע של האפליקציה.
6. הסורק אינו מבין את הפונקציות של האפליקציה. הסורקים עצמם אינם יודעים מה זה "בנקאות אינטרנטית", "תשלום", "הערה". עבורם, יש רק קישורים ופרמטרים, כך ששכבה עצומה של פגיעויות לוגיות אפשריות נשארות חשופות לחלוטין; הם לא יחשבו לבצע מחיקה כפולה, לרגל אחר נתונים של מישהו אחר לפי תעודת זהות, או להגדיל את היתרה באמצעות עיגול
7. הסורק אינו מבין את הסמנטיקה של הדפים. סורקים לא יכולים לקרוא שאלות נפוצות, לא יכולים לזהות captchas, ובעצמם הם לא יבינו איך להירשם ואז להיכנס מחדש, שאתה לא יכול ללחוץ על "יציאה" ואיך לחתום על בקשות בעת שינוי פרמטר ערכים. כתוצאה מכך, ייתכן שרוב האפליקציה לא תיסרק כלל.

בעיות בסריקת קוד מקור

1. חיובי שווא. ניתוח סטטי הוא משימה מורכבת הכוללת פשרות רבות. לעתים קרובות יש להקריב דיוק, ואפילו סורקים ארגוניים יקרים מייצרים מספר עצום של תוצאות שגויות
2. קושי ביישום. כדי להגביר את הדיוק והשלמות של ניתוח סטטי, יש צורך לחדד את כללי הסריקה, וכתיבת כללים אלה עלולה להיות אינטנסיבית מדי. לפעמים קל יותר למצוא את כל המקומות בקוד עם איזה באג ולתקן אותם מאשר לכתוב כלל לזיהוי מקרים כאלה
3. חוסר תמיכה בתלות. פרויקטים גדולים תלויים במספר רב של ספריות ומסגרות המרחיבות את היכולות של שפת התכנות. אם למאגר הידע של הסורק אין מידע על ה"כיורים" במסגרות הללו, זה יהפוך לנקודה עיוורת והסורק פשוט לא יבין את הקוד
4. משך הסריקה. מציאת נקודות תורפה בקוד היא משימה מורכבת מבחינת אלגוריתמים. לכן, התהליך עשוי לקחת זמן רב ולדרוש משאבי מחשוב משמעותיים.
5. כיסוי נמוך. למרות צריכת המשאבים וזמן הסריקה, מפתחי כלי SAST עדיין צריכים לעשות פשרות ולנתח לא את כל המצבים שבהם התוכנית עשויה להיות
6. יכולת שחזור של ממצאים. הצבעה על הקו הספציפי ועל מחסנית השיחות שמובילה לפגיעות היא נהדרת, אך במציאות, לעיתים קרובות הסורק אינו מספק מספיק מידע כדי לבדוק נוכחות של פגיעות מבחוץ. אחרי הכל, הפגם עשוי להיות גם בקוד מת, שלא ניתן להגיע אליו לתוקף

בעיות בסריקת תשתית

1. מלאי לא מספיק. בתשתיות גדולות, במיוחד אלו המופרדות גיאוגרפית, לרוב הקשה ביותר לדעת אילו מארחים לסרוק. במילים אחרות, משימת הסריקה קשורה קשר הדוק למשימת ניהול הנכסים
2. סדר עדיפויות גרוע. סורקי רשת מייצרים לרוב תוצאות רבות עם פגמים שלא ניתן לנצל בפועל, אך רשמית רמת הסיכון שלהם גבוהה. הצרכן מקבל דיווח קשה לפירוש, ולא ברור מה צריך לתקן קודם.
3. המלצות גרועות. בסיס הידע של הסורק מכיל לרוב רק מידע כללי מאוד על הפגיעות וכיצד לתקן אותה, כך שמנהלי מערכת יצטרכו להתחמש בגוגל. המצב קצת יותר טוב עם סורקי Whitebox, שיכולים להוציא פקודה ספציפית לתיקון
4. עבודת יד. לתשתיות יכולות להיות צמתים רבים, כלומר פגמים רבים, שעליהם יש לנתח ולנתח דוחות ידנית בכל איטרציה
5. כיסוי גרוע. איכות סריקת התשתית תלויה ישירות בגודל בסיס הידע לגבי נקודות תורפה וגרסאות תוכנה. שבו, מתברר, אפילו למובילי השוק אין בסיס ידע מקיף, ומאגרי הפתרונות החינמיים מכילים מידע רב שאין למובילים.
6. בעיות עם תיקון. לרוב, תיקון פרצות תשתית כולל עדכון חבילה או שינוי קובץ תצורה. הבעיה הגדולה כאן היא שמערכת, במיוחד מערכת מדור קודם, יכולה להתנהג בצורה בלתי צפויה כתוצאה מעדכון. בעיקרו של דבר, תצטרך לערוך מבחני אינטגרציה על תשתית חיה בייצור.

גישות

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

1. צבירה של כלי סריקה שונים. בשימוש נכון במספר סורקים ניתן להגיע לגידול משמעותי במאגר הידע ובאיכות הגילוי. אתה יכול למצוא אפילו יותר פגיעויות מסך כל הסורקים שהושקו בנפרד, בעוד שאתה יכול להעריך בצורה מדויקת יותר את רמת הסיכון ולהציע יותר המלצות
2. שילוב של SAST ו-DAST. אפשר להגדיל את הכיסוי של DAST ואת הדיוק של SAST על ידי החלפת מידע ביניהם. מהמקורות ניתן לקבל מידע על מסלולים קיימים, ובאמצעות DAST ניתן לבדוק האם הפגיעות נראית מבחוץ
3. Machine Learning™. בשנת 2015 אני סיפר (ו יותר) על שימוש בסטטיסטיקה כדי לתת לסורקים אינטואיציה של האקר ולהאיץ אותם. זה בהחלט מזון לפיתוח ניתוח אבטחה אוטומטי בעתיד.
4. שילוב של IAST עם בדיקות אוטומטיות ו-OpenAPI. בתוך צינור ה-CI/CD, ניתן ליצור תהליך סריקה המבוסס על כלים הפועלים כפרוקסי HTTP ובדיקות פונקציונליות הפועלות על HTTP. בדיקות וחוזים של OpenAPI/Swagger יתנו לסורק את המידע החסר על זרימות נתונים ויאפשרו לסרוק את האפליקציה במצבים שונים
5. תצורה נכונה. עבור כל יישום ותשתית, עליך ליצור פרופיל סריקה מתאים, תוך התחשבות במספר ואופי הממשקים והטכנולוגיות המשמשות
6. התאמה אישית של סורק. לעתים קרובות לא ניתן לסרוק יישום מבלי לשנות את הסורק. דוגמה לכך היא שער תשלום, בו יש לחתום על כל בקשה. בלי לכתוב מחבר לפרוטוקול השער, סורקים יפגיזו בלי דעת בבקשות עם חתימה שגויה. כמו כן, יש צורך לכתוב סורקים מיוחדים עבור סוג מסוים של פגם, כגון הפניה לאובייקט ישיר לא בטוח
7. ניהול סיכונים. שימוש בסורקים שונים ואינטגרציה עם מערכות חיצוניות כגון Asset Management ו-Threat Management יאפשרו שימוש בפרמטרים רבים להערכת רמת הסיכון, כך שההנהלה תוכל לקבל תמונה נאותה על מצב האבטחה הנוכחי של הפיתוח או התשתית.

הישארו מעודכנים ובואו נשבש את סריקת הפגיעות!

מקור: www.habr.com