التحليل الثابت للكشف عن ثغرات أمان معاملات CICS

تدعم أنظمة CICS بعضًا من أكثر بيئات معالجة المعاملات حساسيةً وكثافةً في العالم. بدءًا من الخدمات المصرفية والتأمين وصولًا إلى الخدمات اللوجستية والدفاع، تتعامل هذه المنصات مع أعباء عمل لا تتحمل أي ثغرات أمنية. وبينما يحظى وقت التشغيل التشغيلي بأكبر قدر من الاهتمام، فإن بنية تطبيقات CICS تُقدم المخاطر الخفية والتي من السهل تفويتها أثناء المراجعات الروتينية.

تنشأ العديد من هذه المخاطر من الكود القديم. وحدات COBOL المتداخلة، وربطات برامج المعاملات، واستدعاءات البرامج الديناميكية، والفواصل المُعاد استخدامها، قد تُنشئ نقاط الضعف ثغرات أمنية غير مرئية من السطح. من الأمثلة الشائعة: الوصول غير المُصادق عليه إلى المحطة الطرفية، وإساءة استخدام تعليمات XCTL أو LINK، والأذونات المُرتفعة الممنوحة عبر توجيه معاملات غير صحيح. قد تستمر هذه العيوب في الإنتاج لسنوات دون إصدار أي تنبيهات.

تحليل ثابت يوفر هذا النظام طريقة منظمة لتحديد هذه المشاكل قبل استغلالها. ولكن بخلاف تطبيقات الويب أو واجهات برمجة التطبيقات (API)، يتطلب فحص أحمال عمل CICS فحصًا أعمق بكثير. يجب على المحللين تتبع تدفق التحكم عبر مستويات متعددة من البرنامج، وفهم كيفية انتقال البيانات عبر الذاكرة المشتركة، واكتشاف الأنماط الخاصة بسلوك معاملات الحاسوب المركزي.

تُركز هذه المقالة على كيفية تطبيق التحليل الثابت في بيئات CICS للكشف عن الثغرات الأمنية والحد منها. تُحدد هذه المقالة الهياكل عالية الخطورة التي يجب البحث عنها، وتُوضح كيفية تفسير منطق المعاملات في شيفرة COBOL، وتُقدم إرشادات للمهندسين الذين يحتاجون إلى مراجعة الأنظمة القديمة الكبيرة بدقة وعمق. الهدف هو مساعدة الفرق على تأمين طبقات معاملاتها دون أي تخمين أو انقطاع.

فهم أسطح هجوم معاملات CICS

معاملات CICS ليست مجرد وحدات عمل برمجية، بل هي متأصلة بعمق في التحكم في الوصول، وهوية المستخدم، وتفويض الموارد، وسلامة الجلسة. تعتمد العديد من أنظمة الحاسوب المركزي على أنماط تصميم قديمة، حيث يكون تطبيق الأمن ضمنيًا وليس صريحًا. وهذا يُدخل مخاطر غالبًا ما يتم تجاهلها أثناء الاختبار أو حتى عمليات تدقيق الامتثال.

يبدأ التحليل الثابت في هذا المستوى بتحديد أماكن تمرير التحكم، وكيفية معالجة المدخلات، والمسارات التي يمكن الوصول إليها في سياقات تنفيذ محددة. حتى الأنظمة التي اجتازت اختبار الاختراق قد تحتوي على ثغرات أمنية تتعلق بتدفقات معاملات ذات توجيه خاطئ أو امتيازات مفرطة.

الثغرات الأمنية المخفية في مكالمات EXEC CICS

أحد نقاط الضعف الشائعة هو الاستخدام الديناميكي لـ 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 مجرد بناء الجملة أو اكتشاف الكلمات المفتاحية. يحتاج المحللون إلى فهم ليس فقط بنية الكود، بل أيضًا نموذج المعاملات، وروابط البرامج، وتدفقات البيانات، وحدود الامتيازات. يجب أن يعكس التقييم الشامل كيفية تفاعل المستخدمين والمحطات والتطبيقات من خلال الذاكرة المشتركة ومنطق التنفيذ المتسلسل.

هذا المستوى من التفتيش مُعقّد، خاصةً عند العمل مع تطبيقات مُصمّمة منذ عقود، وتُصان من قِبَل فرق مُتعدّدة على مرّ الزمن. غالبًا ما تعتمد البرامج على تدفق تحكم غير مُنظّم، واستخدام ديناميكي للفواصل، وإعادة استخدام مُعرّفات البرامج، وكلّها تُخفي بداية ونهاية الصلاحية.

تحليل تدفق مصدر COBOL-CICS لحدود الثقة

في بيئات التطبيقات الحديثة، تُحدد حدود الثقة عادةً بطبقات، مثل تلك الموجودة بين واجهة المستخدم الأمامية وواجهة برمجة التطبيقات. في أنظمة CICS، غالبًا ما تكون حدود الثقة ضمنية ومُخبأة داخل روابط البرامج. يجب أن يتتبع التحليل الثابت البرامج التي تُمرر التحكم إلى برامج أخرى، ومن أين تدخل المدخلات إلى النظام، وما إذا كان مصدر هذه المدخلات موثوقًا به.

على سبيل المثال، قد تُمرر سلسلة تبدأ بمعاملة تسجيل دخول التحكم عبر خمسة برامج أو أكثر. إذا قبل أحد هذه البرامج مدخلات مستخدم جديدة (مثلاً، من خلال مقطع فاصل مُحدّث) دون إعادة التحقق منه، فسيتم كسر حدود الثقة. يجب أن يُشير التحليل الثابت إلى نقاط الانتقال هذه للمراجعة.

تشمل الجوانب الحاسمة التي يجب فحصها ما يلي:

• نقاط الدخول حيث تدخل البيانات الخارجية إلى مسار التنفيذ
• المكالمات إلى LINK أو XCTL التي تحدث دون التحقق من المتصل
• المناطق التي يتحول فيها التنفيذ من التدفق المصادق عليه إلى التدفق غير المصادق عليه

اكتشاف بيانات الاعتماد المبرمجة ومنطق تصعيد الصلاحيات

أحيانًا ما تُضاف رموز أمان مُبرمجة مسبقًا، أو مُعرّفات مستخدم، أو مُعرّفات تطبيقات (APLIDs) أثناء التطوير السريع أو التصحيحات الطارئة. يمكن لهذه القيم تجاوز ضوابط الوصول القياسية أو السماح بالوصول الاحتياطي عند فشل المصادقة الفعلية.

على سبيل المثال، مقطع COBOL مثل:

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

قد لا يبدو الأمر خطيرًا على السطح، ولكن إذا USER-ID يمكن التأثير عليها خارجيًا أو إعادة استخدامها في برامج أخرى، مما يخلق خطرًا مستمرًا.

ينبغي لمحركات التحليل الثابتة أن تبحث عن:

• القيم الحساسة للأمان في عبارات IF أو التعيينات
• علامات السلطة التي يتم تعيينها مباشرة، دون التحقق
• استخدام معرفات APPLID العامة أو أسماء المستخدمين التي تتجاوز منطق التحكم

هذه الأنماط خفية، لكن وجودها غالبًا ما يُشير إلى مشاكل تصميمية أكبر، حيث يتداخل منطق الأمان مع قواعد العمل. يساعد عزلها من خلال التحليل الثابت الفرق على إعادة تصميم الكود بأمان ودون مسارات امتيازات مخفية.

نطاق التحليل الثابت في بيئة CICS

تختلف أنظمة CICS اختلافًا كبيرًا عن حزم التطبيقات التقليدية. فبينما تكشف الخدمات الحديثة عن واجهات برمجة التطبيقات (APIs) والتدفقات القائمة على الأحداث، غالبًا ما تُنفَّذ تطبيقات CICS كسلاسل برامج مترابطة بإحكام، تعتمد على البيانات التي تمر عبر الفواصل، ومدخلات الطرفية، والذاكرة المشتركة. تُصعِّب هذه البنية التحليل الثابت بشكل كبير. لا يقتصر دور المحللين على البحث عن المكالمات الضعيفة المعروفة، بل يجب عليهم إعادة بناء تدفق التنفيذ عبر برامج متعددة، بعضها قد يمتد لعقود من التطوير القديم.

يجب أن تُراعي المراجعة الثابتة الهادفة كيفية دخول البيانات إلى النظام، وكيفية انتقال التحكم من وحدة إلى أخرى، وأين يُتوقع التحقق ولكنه غائب. لا تنشأ انتهاكات الأمان في نظام CICS دائمًا من استدعاءات خطيرة بشكل واضح. في أغلب الأحيان، تنشأ من افتراضات مُهمَلة حول الثقة، أو عدم التحقق من السياق، أو عدم تطابق الأذونات التي تحدث في تدفقات التنفيذ المتداخلة أو المؤجلة.

تحليل تدفق مصدر COBOL-CICS لحدود الثقة

لا تتكون معاملة COBOL-CICS النموذجية من كتلة واحدة متجانسة. بل غالبًا ما تمتد إلى برامج متعددة متصلة ببعضها البعض بواسطة EXEC CICS LINK, XCTL أو RETURNباستخدام كتل الفاصلة لمشاركة البيانات فيما بينها. لا تُجري العديد من البرامج عملية التحقق من صحة محتوى الفاصلة التي تتلقاها بشكل مستقل، بل تعتمد على افتراض أن متصلاً موثوقًا به قد أجرى عملية التحقق. يُعد هذا الافتراض أحد أكثر مصادر انحراف الصلاحيات والوصول غير المصرح به شيوعًا.

يجب أن يحدد التحليل الثابت نقاط بداية دخول البيانات ويتتبّع انتشارها عبر هذه المكالمات. على سبيل المثال:

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 في منطق التحكم دون التحقق من الأصل
• غياب إعادة التحقق من صحة جلسة المستخدم عند إعادة الدخول إلى سلسلة شبه محادثة

اكتشاف بيانات الاعتماد المبرمجة ومنطق تصعيد الصلاحيات

غالبًا ما تكشف المراجعات الثابتة عن مُعرِّفات مستخدم مُبرمجة مسبقًا، أو رموز خاصة، أو مُعرِّفات تطبيقات مُضمَّنة مباشرةً في عبارات 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 يمكن أن يسمح للمستخدم بتجاوز قيود الدور واستدعاء منطق الحذف أو التحديث.

تشمل مؤشرات المخاطر ما يلي:

• برامج فردية تنفذ إجراءات متعددة ذات امتيازات استنادًا إلى العلامات التي يوفرها المستخدم
• عدم وجود قيود مبرمجة مسبقًا على المعاملات والوظائف
• رموز المعاملات المشتركة عبر البيئات أو وحدات الأعمال
• غياب عمليات التحقق من الوصول المرتبطة بفروع محددة داخل وحدة الإرسال

يجب أن تحدد عمليات المسح الثابتة المكان الذي تتحكم فيه علامات الفاصلة في التدفق وما إذا كانت هذه التدفقات محمية بأي مصادقة أو تحقق من الدور أو قيود على مستوى الموارد.

نقاط ضعف مسار الاستدعاء على مستوى الأوامر مقابل مسار الاستدعاء على مستوى الماكرو

مصدر خطر آخر هو عدم الاتساق بين برامج مستوى الأوامر وبرامج مستوى الماكرو. غالبًا ما تحتوي الأنظمة التي تطورت مع مرور الوقت على مزيج من كلا الأسلوبين. بينما يستفيد كود مستوى الأوامر من بناء جملة منظم وسهولة قراءة أفضل، فإن كود مستوى الماكرو يميل إلى توفير وصول أقل مستوى وضمانات أقل.

عندما يتم استخدام كلا النوعين معًا، فقد يؤدي ذلك إلى إدخال ثغرات خفية في مسار الاستدعاء، خاصةً إذا كانت البرامج على مستوى الماكرو مرتبطة بشكل ديناميكي دون فرض أمان وسيط.

على سبيل المثال:

• يرتبط برنامج على مستوى الأوامر بوحدة نمطية على مستوى الماكرو تقوم بقراءة أو تعديل الذاكرة المشتركة بشكل مباشر.
• تفترض وحدة المستوى الكلي أن البرنامج المستدعي لديه بيانات تم التحقق من صحتها بالفعل.
• لا يتم إجراء أي فحوصات وسيطة بين الإدخال والتنفيذ.

نظرة مبسطة على التدفق:

* 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 بشكل أفضل وإعطاء الأولوية للمعالجة بناءً على إمكانات التأثير.

الكشف الثابت عن إساءة استخدام واجهة برمجة التطبيقات الخاصة بـ CICS

يكشف نظام CICS عن مجموعة واسعة من أوامر EXEC ووحدات الماكرو التي تتفاعل مع موارد النظام. وتشمل هذه معرفات الأجهزة الطرفية، وأرقام المهام، وذاكرة الجلسة، ومنطق توجيه المعاملات. ورغم مرونة هذه الميزات، إلا أنها قد تُسبب ثغرات أمنية عند استخدامها دون إجراءات حماية كافية. وقد يؤدي سوء استخدام هذه الواجهات إلى رفع مستوى الصلاحيات بشكل غير مقصود، أو تجاوز عناصر التحكم، أو الوصول إلى مناطق غير مصرح بها في النظام.

يتيح التحليل الثابت للمطورين والمدققين تحديد هذه المخاطر من خلال فحص كيفية استدعاء واجهات برمجة التطبيقات هذه، والمعلمات التي تستهلكها، وما إذا كان سياق الاستدعاء يوفر التحقق الكافي. يتطلب التنفيذ السليم فحصًا دقيقًا لسياق التنفيذ، وأنماط الوصول، وحدود تدفق البيانات عبر المعاملات.

تتبع الاستخدام غير الآمن لـ 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 الذي يؤجل التحقق إلى وحدات المصب
• قيم Commarea التي تحدد التدفق دون فحوصات السلامة

ينبغي أن يُنشئ التحليل الثابت رسمًا بيانيًا كاملًا للمعاملات لتحديد البرامج ذات مسارات الإدخال المتعددة، وإبراز البرامج التي تتلقى التحكم بعد التحقق غير الكامل. حتى عندما تبدو الوظائف معزولة، فإن التدفقات الخفية قد تسمح للمهاجمين بتشغيل عمليات ذات امتيازات خارج نطاق الاستخدام المتوقع.

التعامل مع التعتيم المنطقي الأمني ​​المعقد

من أصعب جوانب تأمين تطبيقات 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

يبدو هذا آمنًا إذا استُخدم على النحو المقصود. ولكن إذا بدأت معاملة أخرى البرنامج ٢ مباشرةً دون المرور بالبرنامج ١، فسيتغير المتغير SESSION-AUTH قد يكون غير مُهيأ أو مُزوَّرًا. يثق البرنامج الثاني بصحة الجلسة بناءً على مُتغير واحد فقط، دون الحاجة إلى إعادة التحقق من بيانات الاعتماد.

يجب أن يتتبع التحليل الثابت التعيينات المتغيرة عبر انتقالات البرنامج، وخاصةً:

• عندما يقوم أحد البرامج بتعيين علامة يقرأها برنامج آخر لاتخاذ قرارات الوصول
• عندما يوجد منطق التفويض خارج منطق المصادقة
• عندما يمكن تشغيل البرامج مباشرة وتجاوز التحقق من صحة الإدخال العادي

تعتبر هذه الأنماط شائعة للغاية في التصميمات القديمة وغالبًا ما يتم تجاهلها في المراجعات اليدوية.

تحويلات تدفق التحكم عبر أوضاع التصحيح الداخلي أو الاختبار

يُضيف المطورون أحيانًا علامات مخفية أو أوضاع تصحيح أخطاء للمساعدة أثناء الاختبار. إذا لم تُلغَ هذه الميزات قبل النشر، أو إذا كانت متاحة من محطات الإنتاج، فقد تُتيح منفذًا خلفيًا للوصول إلى أجزاء حساسة من التطبيق.

على سبيل المثال:

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

أو بشكل أكثر دقة:

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

في الحالة الثانية، قد يتجاوز روتين ما بعد ساعات العمل بعض عمليات التحقق الأمنية الاعتيادية، ربما لأغراض دفعات العمل أو الاستجابة للطوارئ. أما إذا أمكن تشغيله من جلسة تفاعلية، فسيؤدي ذلك إلى فتح مجال هجومي قائم على التوقيت.

عند البحث عن منطق غامض أو محفوف بالمخاطر، يجب أن يعطي التحليل الثابت الأولوية لما يلي:

• الظروف غير العادية التي تتحكم في منطق الأمان (الوقت من اليوم، معرف الجهاز، رمز المنطقة)
• علامات مثل DEBUG أو DEV أو OVERRIDE أو TEST أو BACKDOOR
• عمليات التحقق من الوصول التي يتم تخطيها في ظل ظروف وقت التشغيل المحددة
• مسارات 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 يستخدم عمليات المسح المستندة إلى القواعد ومطابقة الأنماط لاستخراج:

• الفروع الشرطية التي يتم التحكم فيها بواسطة قيم العلم التي نادرًا ما تُستخدم
• يتم تشغيل المنطق بناءً على معرف الجهاز أو الوقت من اليوم أو بيانات تعريف المهمة
• تجاوز الفروع باستخدام علامات الفاصلة أو معرفات المستخدم المبرمجة أو إجراءات مستوى الماكرو

إنه يسلط الضوء على جميع حالات نقاط القرار المتميزة المحتملة ويصنفها بناءً على إمكانية الوصول إليها، ومدى تعرض المعاملات، وإمكانية تصعيد الامتيازات.

قواعد الثغرات الأمنية الآلية لبناءات CICS

على عكس الماسحات الضوئية على مستوى السطح، SMART TS XL يتضمن قواعد مدمجة مصممة خصيصًا لبرامج COBOL-CICS. تحدد هذه القواعد الثغرات الأمنية المتعلقة بما يلي:

• استخدام غير آمن لتعيين EXEC CICS وعنوانه
• منطق الوصول غير المتسق في الروتينات PERFORMed
• التحقق مفقود قبل أوامر WRITE أو DELETE أو START
• تدفقات شبه محادثة عفا عليها الزمن مع إدارة دولة ضعيفة

يمكن تخصيص هذه القواعد بناءً على البيئة أو وظيفة العمل أو معايير التدقيق. وهي مفيدة بشكل خاص في تحديد الافتراضات الخاطئة التي تخلّفها فرق التطوير القديمة.

الإصلاح السريع مع تتبع الأثر

بمجرد تحديد الثغرة الأمنية، يمكن تسريع عملية الإصلاح من خلال SMART TS XLقدرة التتبع. لأي فرع منطقي أو دالة برمجية، يُمكنها إظهار:

• جميع المعاملات التي تؤدي إليها
• جميع الوحدات التي يستدعيها
• كل المتغيرات تعتمد على
• أي منطق وصول يتجاوزه

تساعد خريطة التتبع هذه المطورين والمدققين على فهم ما إذا كان الخلل معزولًا أم مُكشوفًا بشكل منهجي. كما أنها تُقلل الوقت المُستغرق في ربط التبعيات يدويًا، وتُقلل من خطر ظهور أخطاء جديدة أثناء التصحيح.

الاستنتاجات والخطوات التالية لمراجعة الأمن

تطبيقات CICS القديمة تحمل منطق عمل بالغ الأهمية، إلا أن قدمها وتعقيدها يُنشئان ثغرات أمنية غالبًا ما تغفلها الطرق القياسية. يوفر التحليل الثابت طريقة موثوقة للكشف عن المخاطر الخفية قبل استغلالها، خاصةً عندما لا يستهدف فقط قواعد اللغة أو مقتطفات التعليمات البرمجية، بل أيضًا تدفق التحكم الأوسع وافتراضات الوصول عبر المعاملات.

في هذه المقالة، قمنا بفحص أنواع العيوب الفريدة في أنظمة CICS:

• منطق التفويض متناثر عبر البرامج المرتبطة بشكل فضفاض
• أنماط الأوامر المعرضة للخطر مثل ASSIGN وADDRESS دون التحقق من الصحة
• المعاملات الاحتياطية ومسارات التصحيح التي تتجاوز عمليات الفحص العادية
• إجراءات إعادة الاستخدام بافتراض إدخال موثوق به من المتصلين

بالنسبة للمؤسسات التي تدير محافظ CICS كبيرة، لم يعد النهج الأمني ​​الجزئي مجديًا. فالتهديدات الحديثة قد تستغل ثغرة أمنية واحدة مدفونة في مئات الوحدات. ويمكن للتحليل الثابت، إذا طُبّق بوعي عميق بالسياق، أن يُبرز هذه المشكلات قبل أن تظهر أو تصل إلى مرحلة التدقيق.

وفيما يلي بعض الإجراءات الرئيسية التي ينبغي أخذها في الاعتبار كخطوات تالية:

• إنشاء خريطة كاملة للمعاملات إلى البرامج، بما في ذلك جميع مسارات XCTL وLINK
• تحديد وإعادة تصميم أي منطق أعمال مشترك يقوم بعمليات مميزة
• تدقيق جميع الفروع المتأثرة بأعلام الفاصلة أو القرارات المستندة إلى المحطة الطرفية
• إنشاء التحقق الأمني ​​عند نقطة دخول كل معاملة
• مراجعة منطق الاحتياطي ومسارات الطوارئ للتعرض غير المقصود

بالنسبة للفرق التي تتطلع إلى تسريع هذه العملية وتقليل الجهد اليدوي، فإن الأدوات مثل SMART TS XL توفير تحليل ثابت مصمم خصيصًا لهندسة CICS، مما يتيح إعادة الهيكلة الآمنة مع إمكانية تتبع التدفق الكامل.

تتطلب حماية بيئات الحواسيب المركزية ليس فقط اليقظة، بل أيضًا الرؤية الواضحة. والتحليل الثابت من التقنيات القليلة التي توفر كليهما.