ניתוח סטטי לגילוי פגיעויות באבטחת עסקאות CICS

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

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

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

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

הבנת משטחי תקיפה של עסקאות CICS

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

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

פגיעויות נסתרות בקריאות CICS של EXEC

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

בפועל, זה עשוי להיראות כך:

EXEC CICS LINK PROGRAM(PROG-NAME) COMMAREA(COMM-AREA) LENGTH(COMM-LEN) END-EXEC

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

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

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

דפוסי הסלמה של SVC ובקרת אחסון

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

דפוס אופייני של דגל אדום כולל:

• הקצאת מזהה מסוף או מספר משימה מקלט גולמי
• שימוש EXEC CICS ADDRESS TCTUA או קריאות מקבילות ואחריהן כתיבה ישירה
• החלפת שליטה המבוססת על מצב הפעלה ללא אימות תפקיד

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

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

היקף ניתוח סטטי בסביבת CICS

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

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

ניתוח זרימת מקור COBOL-CICS עבור גבולות אמון

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

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

היבטים קריטיים לבחינה כוללים:

• נקודות כניסה בהן נתונים חיצוניים נכנסים לנתיב הביצוע
• קריאות ל-LINK או XCTL המתרחשות ללא אימות המתקשר
• אזורים שבהם הביצוע עובר מזרימה מאומתת לזרימה לא מאומתת

זיהוי אישורים מקודדים קשיחים ולוגיקת הסלמת הרשאות

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

לדוגמה, מקטע COBOL כמו:

IF USER-ID = 'SECADMIN' THEN
   MOVE 'Y' TO AUTH-FLAG
END-IF

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

מנועי ניתוח סטטי צריכים לחפש:

• ערכים רגישים לאבטחה במשפטי IF או בהקצאות
• דגלי רשות שנקבעו ישירות, ללא אימות
• שימוש ב-APPLIDs גנריים או שמות משתמש שעוקפים את לוגיקת הבקרה

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

היקף ניתוח סטטי בסביבת CICS

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

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

ניתוח זרימת מקור COBOL-CICS עבור גבולות אמון

טרנזקציית COBOL-CICS טיפוסית אינה מורכבת מבלוק מונוליטי יחיד. לעתים קרובות היא משתרעת על פני מספר תוכניות המחוברות על ידי EXEC CICS LINK, XCTL, או RETURN, תוך שימוש בבלוקים של commarea כדי לשתף נתונים ביניהן. תוכניות רבות אינן מאמתות באופן עצמאי את תוכן ה-commarea שהן מקבלות, אלא מסתמכות על ההנחה שמתקשר מהימן כבר ביצע אימות. הנחה זו היא אחד המקורות הנפוצים ביותר לסחיפה של הרשאות וגישה לא מורשית.

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

MOVE WS-USERID TO COMM-USERID  
EXEC CICS LINK PROGRAM('ACCTUPD') COMMAREA(COMMAREA-BLOCK) LENGTH(COMM-LEN)  

ואז, פנימה ACCTUPD, ייתכן שיופיעו הדברים הבאים:

IF COMM-USERID = 'ADMIN01'  
   PERFORM ADMIN-ROUTINE  

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

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

• ענפי החלטה המבוססים על שדות קומראה ללא אימות מקומי
• ביצוע לוגיקה המותנה בערכי טרמינל או APPLID
• שימוש EIBTRMID, EIBTASKN, או EIBRESP בלוגיקת בקרה ללא בדיקת מקור
• היעדר אימות מחדש של סשן משתמש בעת כניסה מחדש לשרשרת פסאודו-שיחה

זיהוי אישורים מקודדים קשיחים ולוגיקת הסלמת הרשאות

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

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

IF USER-ID = 'SYSROOT'  
   MOVE 'FULL' TO ACCESS-LEVEL  

or

IF EIBTRMID = 'TSTTERM1'  
   MOVE 'Y' TO BYPASS-SECURITY-FLAG  

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

דוגמה עדינה יותר:

IF SUBSTR(COMMAREA-DATA, 1, 5) = 'DEBUG'  
   PERFORM DIAGNOSTIC-ROUTINES  

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

בעת בניית כללים סטטיים לגילוי פגמים כאלה, התמקדו ב:

• IF or EVALUATE הצהרות המשתמשות בערכים ליטרליים מקודדים קשיחים הקשורים למשתמשים או טרמינלים
• מיפוי ישיר של אישורים מקודדים כדי לגשת לדגלים
• דגלים כגון BYPASS, OVERRIDE, או DEBUG שמפעילים לוגיקה מותנית
• מקטעי קוד מוגנים רק על ידי בדיקות שטחיות של שם משתמש או מזהה מסוף

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

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

דפוסי מבנה קוד המצביעים על סיכון אבטחה

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

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

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

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

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

דוגמא:

EXEC CICS RETRIEVE INTO(COMM-AREA)  
EVALUATE COMM-AREA-FUNCTION  
   WHEN 'UPDATE'  
      PERFORM UPDATE-ROUTINE  
   WHEN 'DELETE'  
      PERFORM DELETE-ROUTINE  
   WHEN OTHER  
      PERFORM INQUIRY-ROUTINE  
END-EVALUATE

אם האמור לעיל ממופה לעסקה כמו FINTRN01, ולעסקה זו מוקצות הרשאות מערכת מוגברות, כל שימוש לרעה COMM-AREA-FUNCTION יכול לאפשר למשתמש לעקוף מגבלות תפקידים ולהפעיל לוגיקת מחיקה או עדכון.

מדדי הסיכון כוללים:

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

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

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

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

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

דוגמא:

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

מבט פשוט על הזרימה:

* In command-level handler  
EXEC CICS LINK PROGRAM('LEGACYIO') COMMAREA(DATA-BLOCK)

* In macro-level module LEGACYIO  
L R1,=V(DATA-BLOCK)  
ST R1,=V(SYSTEM-FILE-POINTER)  

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

ניתוח סטטי צריך לשים לב במיוחד ל:

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

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

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

זיהוי סטטי של שימוש לרעה ב-API ספציפי ל-CICS

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

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

מעקב אחר שימוש לא מאובטח ב-EXEC CICS ASSIGN ו-ADDRESS

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

קח דוגמה זו:

EXEC CICS ASSIGN TERMINALID(TERM-ID)
IF TERM-ID = 'DEVBYPASS'
   PERFORM SKIP-AUTH-CHECKS

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

או לשקול וריאציה הכוללת ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

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

אינדיקטורים נפוצים לשימוש לא מאובטח ב-ASSIGN ו-ADDRESS כוללים:

• ענפי בקרה המבוססים אך ורק על מזהה מסוף, APPLID או מספר משימה
• שימוש ישיר בערכים שהוקצו לאימות גישה או עקיפת דגלים
• הפניות מצביע ללא אימות מבני לאחר פקודות ADDRESS
• ערכים מקודדים קשיחים בהשוואה למזהים שהוקצו על ידי המערכת בתנאי IF

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

שיבוש זרימת עסקאות באמצעות נתיבי ביצוע חלופיים

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

שקול מקרה זה:

IF EIBCALEN = 0
   EXEC CICS XCTL PROGRAM('RETRYTX')

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

דוגמה נוספת כוללת הסלמה שקטה:

IF AUTH-FAILS
   EXEC CICS START TRANSID('ALTID')
   EXEC CICS RETURN

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

סיכונים כאן נובעים בדרך כלל מ:

• שימוש ב-START, XCTL או LINK כדי להחליף בין תוכניות בהתבסס על מצבי שגיאה
• מזהי תוכנית הנמצאים בשימוש חוזר על פני קודי עסקה מרובים
• לוגיקת RETURN הדוחה את האימות למודולים במורד הזרם
• ערכי Comarea שמכתיבים זרימה ללא בדיקות שלמות

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

טיפול בטשטוש לוגיקת אבטחה מורכבת

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

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

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

דוגמא:

תוכנית 1:

IF USERID = 'SUPPORT1'
   MOVE 'OK' TO SESSION-AUTH
EXEC CICS RETURN TRANSID('TX02')

תוכנית 2:

IF SESSION-AUTH = 'OK'
   PERFORM PROCESS-ADMIN-DATA

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

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

• כאשר תוכנית אחת מגדירה דגל שתוכנית אחרת קוראת לצורך קבלת החלטות גישה
• כאשר לוגיקת הרשאה קיימת מחוץ ללוגיקת האימות
• כאשר ניתן להפעיל תוכניות ישירות ולעקוף אימות ערך רגיל

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

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

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

דוגמא:

IF COMM-FLAG = 'DEBUG'
   PERFORM BYPASS-AUTH-CHECK

או בצורה עדינה יותר:

IF CURRENT-TIME > '210000'  
   PERFORM EMERGENCY-ROUTINE  

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

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

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

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

שגרות שימוש חוזר עם בקרת גישה לא עקבית

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

מבנה קלאסי נראה כך:

PERFORM UPDATE-ACCT-INFO

...

UPDATE-ACCT-INFO.
   IF ROLE = 'ADMIN'
      EXEC CICS WRITE FILE('ACCTDB')

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

סריקות סטטיות צריכות לסמן:

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

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

שימוש SMART TS XL לאיתור ולמיגור פגיעויות בעסקאות CICS

טיפול בניתוח אבטחה במערכות מיינפריים מדור קודם הוא מורכב מטבעו. סביבות CICS לרוב חסרות מבנה מרכזי, בעלות תיעוד מודרני מינימלי, ומשתרעות על פני עשרות שנים של אבולוציה פרוצדורלית. SMART TS XL מטפל בבעיות אלו על ידי הצעת מנוע ניתוח סטטי שנבנה במיוחד עבור תבניות ספציפיות ל-COBOL, PL/I, JCL ותבניות CICS. בניגוד לכלים למטרות כלליות, הוא מבין את הארכיטקטורה והמוסכמות הייחודיות למערכות אקולוגיות של מיינפריים.

שחזור זרימה רב-מפלסי עבור CICS

SMART TS XL סורק תיקי יישומים שלמים ובונה מפת זרימה חוצת תוכניות. זה כולל:

• מיפויים בין עסקאות לתוכניות
• מעברים בין תוכניות באמצעות LINK, XCTL ו-RETURN
• התפשטות משתנה וקומראה
• לוגיקת בקרה מבוססת תפקידים ומעקב אחר תנאי כניסה

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

מקרה שימוש לדוגמה:

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

זיהוי דגלי בקרה נסתרים ונתיבי גישה מעורפלים

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

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

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

כללי פגיעות אוטומטיים עבור מבני CICS

בניגוד לסורקים בגובה פני השטח, SMART TS XL כולל כללים מובנים המותאמים לתוכניות COBOL-CICS. אלה מזהים פגיעויות הקשורות ל:

• שימוש לא מאובטח ב-EXEC CICS ASSIGN ו-ADDRESS
• לוגיקת גישה לא עקבית בשגרות PERFORMed
• אימות חסר לפני פקודות WRITE, DELETE או START
• זרימות פסאודו-שיחות מיושנות עם ניהול מצב חלש

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

תיקון מואץ עם מעקב אחר השפעות

לאחר שזוהתה פגיעות, ניתן להאיץ את התיקון באמצעות SMART TS XLיכולת המעקב של. עבור כל ענף לוגי או פונקציית תוכנית, הוא יכול להציג:

• כל העסקאות שהובילו לכך
• כל המודולים שהוא קורא להם
• כל המשתנים שזה תלוי בהם
• כל לוגיקת גישה שהוא עוקף

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

סיכום ושלבי סקירת האבטחה הבאים

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

במאמר זה, בחנו את סוגי הפגמים הייחודיים למערכות CICS:

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

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

להלן הפעולות המרכזיות שיש לשקול כצעדים הבאים:

• צור מפה מלאה של טרנזקציה לתוכנית, כולל כל נתיבי XCTL ו-LINK
• זהה ותקן כל לוגיקה עסקית משותפת שמבצעת פעולות מורשות
• ביקורת על כל הענפים המושפעים מדגלי commarae או מהחלטות מבוססות טרמינל
• קבע אימות אבטחה בנקודת הכניסה של כל עסקה
• סקירת לוגיקת גיבוי ונתיבי חירום לחשיפה לא מכוונת

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

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