Statická analýza pro detekci zranitelností transakcí CICS

Systémy CICS podporují některá z nejcitlivějších prostředí pro zpracování transakcí s vysokým objemem na světě. Od bankovnictví a pojišťovnictví až po logistiku a obranu, tyto platformy zvládají pracovní zátěže, které si nemohou dovolit bezpečnostní přehlédnutí. Zatímco provozní dostupnost často získává největší pozornost, struktura aplikací CICS zavádí... skrytá rizika které lze při běžných kontrolách snadno přehlédnout.

Mnoho z těchto rizik pochází ze staršího kódu. Vnořené moduly COBOL, vazby transakčních programů, dynamická volání programů a opakovaně použité čárkové oblasti mohou vytvářet zranitelností které nejsou viditelné na povrchu. Mezi běžné příklady patří neověřený přístup k terminálu, zneužití instrukcí XCTL nebo LINK a zvýšená oprávnění udělená nesprávným směrováním transakcí. Tyto chyby mohou v produkčním prostředí existovat roky, aniž by spouštěly výstrahy.

Statická analýza nabízí strukturovaný způsob, jak tyto problémy identifikovat dříve, než budou zneužity. Na rozdíl od webových aplikací nebo API však skenování úloh CICS vyžaduje mnohem hlubší kontrolu. Analytici musí sledovat tok řízení napříč více úrovněmi programu, pochopit, jak se data pohybují sdílenou pamětí, a detekovat vzorce specifické pro chování transakcí na mainframech.

Tento článek se zaměřuje na to, jak aplikovat statickou analýzu v prostředích CICS k odhalení a zmírnění bezpečnostních nedostatků. Popisuje vysoce rizikové struktury, které je třeba hledat, ukazuje, jak interpretovat transakční logiku v kódu COBOL, a poskytuje pokyny pro inženýry, kteří potřebují přesně a do hloubky prověřit rozsáhlé starší systémy. Cílem je pomoci týmům zabezpečit jejich transakční vrstvy bez dohadů a narušení.

Pochopení povrchů pro útoky na transakce CICS

Transakce CICS nejsou jen programové jednotky práce. Jsou hluboce zakořeněny v řízení přístupu, identitě uživatelů, autorizaci zdrojů a integritě relací. Mnoho mainframových systémů se spoléhá na desítky let staré návrhové vzory, kde je vynucování zabezpečení implicitní, nikoli explicitní. To s sebou nese rizika, která jsou během testování nebo dokonce auditů shody často přehlížena.

Statická analýza na této úrovni začíná mapováním, kudy je předáváno řízení, jak je zpracováván vstup a které cesty jsou dosažitelné v konkrétních kontextech provádění. I systémy, které prošly penetračním testováním, mohou stále obsahovat zranitelnosti související s nesprávně směrovanými nebo příliš privilegovanými toky transakcí.

Skryté zranitelnosti ve voláních EXEC CICS

Častou slabinou je dynamické využívání EXEC CICS LINK, XCTLnebo RETURN bez ověření původu nebo kontextu volání. Pokud jsou programy volně zřetězeny a názvy programů jsou zadávány externě nebo konstruovány dynamicky, může škodlivý vstup nasměrovat provádění k modulům se zvýšenými oprávněními.

V praxi by to mohlo vypadat takto:

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

If PROG-NAME je sestaven z hodnoty zadané uživatelem nebo namapován z tabulky bez striktní validace, neoprávnění uživatelé mohou spustit citlivé programy, které nebyly určeny k odhalení.

Statická analýza musí detekovat takové cesty, zejména tam, kde:

• Názvy programů se sestavují ze zřetězených nebo maskovaných hodnot.
• Pro povolené nebo očekávané cíle není implementována žádná záložní kontrola.
• Přijímací programy fungují bez dalšího ověřování autorizace

Vzory eskalace SVC a řízení úložiště

Některá volání založená na SVC nebo interní servisní rutiny, ke kterým se přistupuje prostřednictvím instrukcí na makroúrovni, mohou umožnit eskalaci manipulací s pamětí. Nesprávné použití ADDRESS, ASSIGNnebo přímý přístup k datovým blokům terminálu může obejít ochranná opatření, pokud není správně vynucen kontext zabezpečení na úrovni úloh.

Typický vzor červené vlajky zahrnuje:

• Přiřazení ID terminálu nebo čísla úlohy ze surového vstupu
• Použití EXEC CICS ADDRESS TCTUA nebo ekvivalentní volání následovaná přímým zápisem
• Přepínání řízení na základě stavu relace bez ověření role

Útočníci obeznámení se strukturami terminálů a interními funkcemi CICS mohou tyto přístupové body zneužít ke zvýšení oprávnění nebo k vložení nechtěných příkazů.

Identifikace těchto zranitelností vyžaduje nejen skenování příkazů CICS, ale také vyřešení datové linie napříč přiřazeními paměti, kontrolu původu řídicích parametrů a označení použití nebezpečných nebo neověřených kontextových hodnot.

Rozsah statické analýzy v prostředí CICS

Statická analýza v prostředích CICS musí jít nad rámec základní syntaxe nebo detekce klíčových slov. Analytici potřebují rozumět nejen struktuře kódu, ale také transakčnímu modelu, propojení programů, datovým tokům a hranicím oprávnění. Úplné posouzení by mělo odrážet, jak uživatelé, terminály a aplikace interagují prostřednictvím sdílené paměti a logiky řetězeného provádění.

Tato úroveň inspekce je složitá, zejména při práci s aplikacemi napsanými před desítkami let a udržovanými více týmy v průběhu času. Programy se často spoléhají na nestrukturovaný tok řízení, dynamické používání čárkových oblastí a opakovaně používaná ID programů, což vše zakrývá, kde začíná a končí autorita.

Analýza toku zdrojů COBOL-CICS pro hranice důvěryhodnosti

V moderních aplikačních prostředích jsou hranice důvěryhodnosti obvykle definovány vrstvami, například mezi uživatelským rozhraním front-endu a API. V CICS jsou hranice důvěryhodnosti často implicitní a skryté uvnitř propojení programů. Statická analýza musí sledovat, které programy předávají řízení ostatním, kde vstup vstupuje do systému a zda je původ tohoto vstupu důvěryhodný.

Například řetězec, který začíná přihlašovací transakcí, může předat řízení pěti nebo více programům. Pokud jeden z těchto programů přijme nový uživatelský vstup (například prostřednictvím aktualizovaného segmentu commarrea) bez jeho opětovného ověření, hranice důvěryhodnosti je narušena. Statická analýza by měla tyto přechodové body označit k přezkoumání.

Mezi kritické aspekty, které je třeba prozkoumat, patří:

• Vstupní body, kde externí data vstupují do cesty provádění
• Volání funkcí LINK nebo XCTL, ke kterým dochází bez ověření volajícího
• Oblasti, kde se provádění přepíná z ověřeného na neověřený tok

Detekce pevně zakódovaných přihlašovacích údajů a logika eskalace autorizace

Pevně zakódované bezpečnostní tokeny, uživatelská ID nebo APPLID se někdy zavádějí během rychlého vývoje nebo nouzových oprav. Tyto hodnoty mohou přepsat standardní řízení přístupu nebo povolit záložní přístup, když selže skutečné ověření.

Například segment COBOLu jako:

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

na povrchu se nemusí jevit nebezpečné, ale pokud USER-ID lze ovlivnit externě nebo znovu použít v jiných programech, vytváří trvalé riziko.

Statické analytické nástroje by měly hledat:

• Hodnoty citlivé na zabezpečení v příkazech IF nebo přiřazeních
• Příznaky autority, které jsou nastaveny přímo, bez ověřování
• Použití generických APPLID nebo uživatelských jmen, které obcházejí řídicí logiku

Tyto vzorce jsou nenápadné, ale jejich přítomnost často signalizuje větší problémy s návrhem, kde je bezpečnostní logika prokládána obchodními pravidly. Jejich izolace pomocí statické analýzy pomáhá týmům bezpečně refaktorovat kód bez skrytých cest oprávnění.

Rozsah statické analýzy v prostředí CICS

Systémy CICS se výrazně liší od tradičních aplikačních stacků. Zatímco moderní služby využívají API a událostmi řízené toky, aplikace CICS se často provádějí jako úzce propojené programové řetězce, které se spoléhají na data procházející čárkovými oblastmi, terminálovým vstupem a sdílenou pamětí. Tato architektura činí statickou analýzu obzvláště náročnou. Analytici nejen hledají známá zranitelná volání, ale musí rekonstruovat tok provádění napříč více programy, z nichž některé mohou trvat i desetiletí staršího vývoje.

Smysluplná statická kontrola musí zohledňovat, jak data vstupují do systému, jak je řízení předáváno z jednoho modulu do druhého a kde se očekává validace, ale chybí. Narušení bezpečnosti v CICS ne vždy vznikají ze zjevně nebezpečných volání. Častěji vznikají z přehlédnutých předpokladů o důvěře, chybějících kontrol kontextu nebo neshod oprávnění, ke kterým dochází ve vnořených nebo odložených tocích provádění.

Analýza toku zdrojů COBOL-CICS pro hranice důvěryhodnosti

Typická transakce v COBOL-CICS se neskládá z jednoho monolitického bloku. Často zahrnuje více programů propojených pomocí... EXEC CICS LINK, XCTLnebo RETURNpomocí bloků commaréa ke sdílení dat mezi nimi. Mnoho programů nezávisle neověřuje obsah commaréa, který přijímají, a místo toho se spoléhá na předpoklad, že důvěryhodný volající již ověření provedl. Tento předpoklad je jedním z nejčastějších zdrojů posunu oprávnění a neoprávněného přístupu.

Statická analýza musí identifikovat počáteční body přítoku dat a sledovat jejich šíření napříč těmito voláními. Například:

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

Pak, v ACCTUPD, může se zobrazit následující:

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

Tím se vytvoří implicitní hranice důvěryhodnosti. Pokud WS-USERID byl kdy dříve v toku přepsán nebo zfalšován, ACCTUPD by slepě prováděl administrátorské rutiny. Statická analýza musí korelovat COMM-USERIDpůvod a označit veškerý následný kód, který jej používá pro citlivé rozhodování bez opětovného ověření.

Mezi typická narušení hranic důvěryhodnosti, která lze zjistit pomocí statických kontrol, patří:

• Rozhodovací větve založené na polích comarea bez lokálního ověřování
• Provádění logiky podmíněné hodnotami terminálu nebo APPLID
• Použití EIBTRMID, EIBTASKNnebo EIBRESP v řídicí logice bez kontroly původu
• Absence opětovného ověření relace uživatele při opětovném vstupu do pseudokonverzačního řetězce

Detekce pevně zakódovaných přihlašovacích údajů a logika eskalace autorizace

Statické kontroly často odhalují pevně zakódovaná uživatelská ID, speciální kódy nebo APPLID vložené přímo do příkazů COBOL. I když tyto mohly být přidány pro interní testování nebo provozní řešení, často zůstávají v produkčním prostředí a představují vážná rizika.

Zde jsou ukázkové vzorce z reálného světa, které jsou často označovány:

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

or

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

Tyto cesty vytvářejí nekontrolované cesty k přístupu se zvýšenými oprávněními. Pokud útočník získá přístup k terminálu nebo objeví pevně zakódované ID uživatele, zbytek aplikace se může chovat, jako by proběhlo úplné ověření.

Jemnější příklad:

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

Pokud tato logika není odstraněna nebo chráněna, mohl by vytvořený vstup aktivovat funkce, které zpřístupňují protokoly, ukazatele souborů nebo diagnostiku paměti, které nejsou určeny pro běžné uživatele.

Při vytváření statických pravidel pro detekci takových nedostatků se zaměřte na:

• IF or EVALUATE příkazy používající pevně zakódované literální hodnoty vázané na uživatele nebo terminály
• Přímé mapování pevně zakódovaných přihlašovacích údajů na přístupové příznaky
• Vlajky jako například BYPASS, OVERRIDEnebo DEBUG které spouštějí podmíněnou logiku
• Sekce kódu chráněné pouze povrchními kontrolami uživatelského jména nebo ID terminálu

V mnoha případech byly tyto kontroly přidány neformálně a nikdy nebyly zkontrolovány. Statické skenování by je mělo označit pro ruční kontrolu nebo vynutit upozornění na základě vzorců při opakovaném zneužití.

Rozšířením perspektivy statické analýzy o zachycení těchto okrajových podmínek a pevně zakódovaných záložních řešení mohou auditoři a bezpečnostní inženýři získat lepší přehled o tom, kde aplikace CICS mohou narušit řetězec důvěry – i když se zdánlivě zbytek systému funguje bezpečně.

Vzory struktury kódu, které indikují bezpečnostní riziko

I když se jednotlivé příkazy CICS mohou jevit jako bezpečné samy o sobě, okolní struktura programové logiky často určuje, zda je transakce skutečně chráněna. Statická analýza musí jít nad rámec skenování řádek po řádku, aby pochopila, jak programy interagují, jak se odvozují oprávnění a kde byla do řídicího toku vložena implicitní důvěra.

Zastaralé systémy jsou k těmto vzorcům obzvláště náchylné. Vývojové týmy postupem času zavádějí dočasnou logiku, zkratky oprávnění a víceúčelové transakce, které stírají oddělení odpovědností. Identifikace těchto strukturálních anti-vzorců je nezbytná pro posílení zabezpečení transakcí.

Mapování transakcí na program se zvýšenými oprávněními

Každé ID transakce CICS je obvykle namapováno na konkrétní program nebo odesílací rutinu. Mnoho systémů však opakovaně používá transakční kódy v různých modulech nebo přiřazuje široké programové obslužné rutiny, které mohou provádět více citlivých funkcí na základě vstupu uživatele.

To se stává nebezpečným, když je univerzální obslužný program vázán na transakci s vysokými oprávněními bez adekvátního filtrování. Statická analýza musí sledovat, která ID transakcí se mapují na které programy, a určit, jakou logiku každý program v daném kontextu transakce provádí.

Příklad:

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

Pokud je výše uvedené namapováno na transakci jako FINTRN01a že transakci jsou přiřazena zvýšená systémová oprávnění, jakékoli zneužití COMM-AREA-FUNCTION může uživateli umožnit obejít omezení rolí a vyvolat logiku mazání nebo aktualizace.

Mezi ukazatele rizika patří:

• Jednotlivé programy provádějící více privilegovaných akcí na základě uživatelem zadaných příznaků
• Absence pevně zakódovaných omezení pro přechod mezi transakcemi a funkcemi
• Sdílené kódy transakcí napříč prostředími nebo obchodními jednotkami
• Absence kontrol přístupu vázaných na konkrétní pobočky v rámci dispečerského modulu

Statické skenování by mělo identifikovat, kde příznaky commarrea řídí tok a zda jsou tyto toky chráněny nějakým ověřováním, ověřováním rolí nebo omezeními na úrovni zdrojů.

Slabé stránky cesty volání na úrovni příkazů vs. na úrovni maker

Dalším zdrojem rizika je nekonzistence mezi programy na úrovni příkazů a na makroúrovni. Systémy, které se v průběhu času vyvíjely, často obsahují kombinaci obou stylů. Zatímco kód na úrovni příkazů těží ze strukturované syntaxe a lepší čitelnosti, kód na makroúrovni obvykle nabízí přístup na nižší úrovni a méně ochranných opatření.

Pokud se oba typy používají společně, mohou zavést jemné zranitelnosti v cestě volání, zejména pokud jsou programy na makroúrovni dynamicky propojeny bez zprostředkovaného vynucování zabezpečení.

Příklad:

• Program na úrovni příkazů se propojuje s modulem na úrovni makro, který přímo čte nebo upravuje sdílenou paměť.
• Modul na makroúrovni předpokládá, že volající program již ověřil data.
• Mezi zadáním a provedením se neprovádějí žádné mezilehlé kontroly.

Zjednodušený pohled na tok:

* 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)  

Zde je modul na makroúrovni důvěryhodný pro práci přímo s ukazateli úložiště. Pokud volající program neověřil platnost DATA-BLOCK, útočník by mohl manipulovat s oblastmi paměti nebo odkazovat na neoprávněné datové sady.

Statická analýza by měla věnovat zvláštní pozornost:

• Volání LINK nebo XCTL ze strukturovaných programů do starších modulů
• Předávání parametrů mezi kódem na úrovni příkazů a kódem na úrovni maker
• Použití ukazatelů úložiště nebo identifikátorů systémových souborů bez kontroly hranic
• Znovu použité moduly, u kterých se předpokládá, že validace vstupu proběhla jinde

Tyto chyby jsou při testování odhaleny jen zřídka, protože podmínky pro zneužití často vyžadují přesné sladění mezi kontextem terminálu, parametry úlohy a průběhem provádění. Statické skenování však dokáže odhalit strukturální nastavení, které tyto chyby umožňuje.

Identifikací strukturálních rizik – nejen chybných řádků kódu – mohou analytici lépe posoudit celkové bezpečnostní nastavení systémů CICS a upřednostnit nápravná opatření na základě potenciálního dopadu.

Statická detekce zneužití API specifického pro CICS

CICS zpřístupňuje širokou škálu příkazů EXEC a maker, které interagují s prostředky na úrovni systému. Patří mezi ně identifikátory terminálů, čísla úloh, paměť relací a logika směrování transakcí. Tyto funkce sice nabízejí flexibilitu, ale při použití bez dostatečných ochranných opatření mohou také představovat zranitelnosti. Zneužití těchto rozhraní může vést k neúmyslnému zvýšení oprávnění, obcházení ovládacích prvků nebo přístupu k neoprávněným oblastem systému.

Statická analýza umožňuje vývojářům a auditorům identifikovat taková rizika zkoumáním, jak jsou tato API volána, jaké parametry spotřebovávají a zda volající kontext poskytuje dostatečné ověření. Správná implementace vyžaduje pečlivou kontrolu kontextu provádění, vzorců přístupu a hranic datového toku napříč transakcemi.

Sledování nezabezpečeného použití příkazů EXEC CICS ASSIGN a ADDRESS

Jedno ASSIGN a ADDRESS Příkazy poskytují přímý přístup k interním strukturám CICS. Patří sem kritická metadata, jako jsou ID terminálů, identifikátory aplikací a paměťové adresy specifické pro dané úlohy. I když se tyto hodnoty často používají pro protokolování nebo sledování relací, stávají se nebezpečnými, když na nich závisí řídicí logika pro bezpečnostní rozhodnutí.

Vezměte si tento příklad:

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

Zde je řízení přístupu přímo vázáno na ID terminálu. Uživatel se znalostí hodnoty nebo schopností falšovat nastavení terminálu může tuto logiku zneužít k obejití bezpečnostních mechanismů.

Nebo zvažte variantu zahrnující ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

Samostatně se to zdá neškodné. Pokud však EIBTASKN se později použije pro autentizaci nebo autorizaci transakcí, představuje to riziko předvídatelnosti a neoprávněné zosobnění relace.

Mezi běžné indikátory nezabezpečeného použití funkcí ASSIGN a ADDRESS patří:

• Řízení větví pouze na základě ID terminálu, APPLID nebo čísla úlohy
• Přímé použití přiřazených hodnot pro ověření přístupu nebo příznaky obejití
• Odkazy na ukazatele bez strukturálního ověření po příkazech ADDRESS
• Pevně zakódované hodnoty v porovnání s identifikátory přiřazenými systémem v podmínkách IF

Nástroje pro statické skenování by měly být nakonfigurovány tak, aby tyto podmínky označovaly, zejména pokud přiřazená data ovlivňují směrování programu nebo logiku oprávnění.

Manipulace s transakčním tokom prostřednictvím alternativních cest provádění

V mnoha aplikacích CICS se pro zlepšení odolnosti proti chybám používá záložní nebo alternativní směrování transakcí. Těmto alternativním cestám bohužel nemusí být poskytnuto řádné ověření přístupu nebo se k nim lze dostat za nezamýšlených podmínek. To útočníkům vytváří příležitosti ke spuštění citlivé logiky mimo běžný tok transakcí.

Zvažte tento případ:

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

Tento kód přesměruje provedení, pokud nebyla předána žádná čárka. Ale RETRYTX může být navrženo pro použití pouze v důvěryhodných sekvencích. Pokud nevynucuje vlastní ověření, uživatel by se mohl dostat k citlivým funkcím pouhým spuštěním transakce s nulovou délkou.

Dalším příkladem je tichá eskalace:

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

If ALTID mapuje na transakci s většími oprávněními nebo širší funkcionalitou a postrádá kontroly rolí, tato záložní metoda zavádí nezamýšlený přístup.

Rizika zde obvykle vyplývají z:

• Použití příkazů START, XCTL nebo LINK k přepínání programů na základě chybových stavů
• ID programů, která se opakovaně používají napříč více kódy transakcí
• Logika RETURN, která odkládá validaci na následné moduly
• Hodnoty Comarea, které určují tok bez kontrol integrity

Statická analýza by měla vytvořit kompletní graf transakcí, aby identifikovala programy s více vstupními cestami a zvýraznila ty, které získají kontrolu po neúplném ověření. I když se funkce zdají být izolované, skryté toky mohou útočníkům umožnit spouštět privilegované operace mimo očekávané použití.

Zvládání komplexního zamlžování bezpečnostní logiky

Jedním z nejobtížnějších aspektů zabezpečení starších aplikací CICS je rozmotání zamotané nebo hluboce vnořené bezpečnostní logiky. Mnoho programů CICS se vyvíjelo po celá desetiletí, prošlo různými týmy a zahrnovalo více vrstev zpracování přístupu. V důsledku toho jsou klíčová bezpečnostní rozhodnutí často skryta v nedosažitelných cestách, replikována napříč moduly nebo rozdělena do fragmentovaných rutin. Statická analýza musí být schopna tyto vzorce rekonstruovat a odhalit, kde předpoklady nebo přehlédnutí přinesly riziko.

Identifikace rozdělených autorizačních cest napříč více programy

Vývojáři CICS běžně implementují pseudokonverzační programování, aby udrželi stav napříč interakcemi více uživatelů. Tímto způsobem mohou neúmyslně oddělit autentizaci od autorizace. Jeden program ověřuje přihlašovací údaje, jiný nastavuje příznaky relace a třetí provádí kontroly přístupu. Pokud se jakákoli část tohoto řetězce odpojí nebo znovu použije v jiném kontextu, vytvoří se bezpečnostní díra.

Příklad:

Program 1:

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

Program 2:

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

Toto se zdá být bezpečné, pokud se používá dle plánu. Pokud ale jiná transakce spustí Program 2 přímo bez nutnosti projít Programem 1, proměnná SESSION-AUTH může být neinicializovaná nebo padělaná. Druhý program důvěřuje, že relace je platná pouze na základě proměnné, bez opětovné kontroly přihlašovacích údajů.

Statická analýza musí sledovat přiřazení proměnných napříč přechody programu, zejména:

• Když jeden program nastaví příznak, který jiný program čte pro rozhodnutí o přístupu
• Pokud existuje autorizační logika mimo logiku ověřování
• Kdy lze programy spustit přímo a obejít tak běžné ověřování vstupů

Tyto vzory jsou u starších návrhů extrémně běžné a při manuálních kontrolách jsou často přehlíženy.

Ovládání odklonění toku pomocí interního ladění nebo testovacích režimů

Vývojáři někdy zahrnují skryté příznaky nebo ladicí režimy, které pomáhají během testování. Pokud tyto funkce nejsou před nasazením odstraněny nebo pokud jsou přístupné z produkčních terminálů, mohou poskytnout zadní vrátka do citlivých částí aplikace.

Příklad:

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

Nebo jemněji:

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

V druhém případě může rutina spouštěná po pracovní době obejít některé běžné bezpečnostní kontroly, například určené pro dávkové úlohy nebo reakci na mimořádné události. Pokud ji však lze spustit z interaktivní relace, otevírá se tím vektor útoku založený na načasování.

Při hledání nejasné nebo riskantní logiky by statická analýza měla upřednostnit:

• Neobvyklé podmínky ovládající bezpečnostní logiku (denní doba, ID terminálu, regionální kód)
• Příznaky jako DEBUG, DEV, OVERRIDE, TEST nebo BACKDOOR
• Kontroly přístupu, které jsou za určitých podmínek běhu přeskočeny
• Cesty GOTO nebo PERFORM, které přeskakují větve validace

Cílem je odhalit cokoli, co umožňuje spuštění přivilegovaného kódu bez přímé a viditelné kontroly autorizace.

Znovu používané rutiny s nekonzistentním řízením přístupu

V mnoha rozsáhlých aplikacích CICS vývojáři opakovaně používají běžné rutiny pro přístup k datům nebo obchodní logiku. Tyto rutiny mohou být vyvolány jak veřejně přístupnými transakcemi, tak interními administrátorskými nástroji. Pokud sdílená logika předpokládá, že volající již ověřil roli uživatele, a tento předpoklad ne vždy platí, stává se to nepřímou zranitelností.

Klasická struktura vypadá takto:

PERFORM UPDATE-ACCT-INFO

...

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

Toto je bezpečné pouze tehdy, pokud každý volající UPDATE-ACCT-INFO správně nastaví ROLE proměnné. Pokud jiná část aplikace volá tuto rutinu s ROLE neinicializovaný, nebo pokud jej volající nesprávně nastaví na základě slabé kontroly, může dojít k neoprávněnému přístupu.

Statické skenování by mělo označit:

• Sdílené rutiny, které provádějí akce citlivé na zabezpečení
• Absence lokální validace v rámci sdílených rutin
• Proměnné používané pro rozhodnutí o přístupu, které jsou definovány externě
• Přiřazení rolí, ke kterým dochází daleko od místa vynucování

Tato forma obfuskace není výsledkem úmyslného zatajování, ale dlouhodobého architektonického posunu. Jak se komponenty opakovaně používají napříč moduly, původní předpoklady přístupu se zhoršují. Pouze hloubkové trasování kódu a korelace kontextu mohou tato rizika odhalit.

Použití SMART TS XL detekce a odstranění zranitelností transakcí CICS

Zpracování bezpečnostní analýzy ve starších mainframe systémech je ze své podstaty složité. Prostředí CICS často postrádá centralizovanou strukturu, má minimální moderní dokumentaci a prochází desítkami let procedurálního vývoje. SMART TS XL řeší tyto problémy tím, že nabízí engine pro statickou analýzu, který je speciálně navržen pro vzory specifické pro COBOL, PL/I, JCL a CICS. Na rozdíl od univerzálních nástrojů rozumí architektuře a konvencím specifickým pro ekosystémy mainframe.

Víceúrovňová rekonstrukce proudění pro CICS

SMART TS XL prohledává celá portfolia aplikací a vytváří mapu toku napříč programy. To zahrnuje:

• Mapování transakcí na program
• Přechody mezi programy pomocí LINK, XCTL a RETURN
• Šíření proměnných a čárkovaných oblastí
• Logika řízení založená na rolích a sledování vstupních podmínek

Rekonstrukcí kompletních řetězců provádění dokáže detekovat, kdy je program, který předpokládá důvěryhodný kontext, skutečně dosažitelný z více bodů, včetně potenciálně neověřených.

Příklad použití:

Interní audit odhalil bezpečnostní chybu v transakci. TX94 spustil program, který byl původně určen pouze pro administrátorské použití. SMART TS XL sledoval graf volání programu, zjistil, že řídicí příznak byl předán přes nekontrolované pole commarrea, a identifikoval pět dalších transakcí s přístupem ke stejnému záznamu programu. Ruční trasování toto přehlédlo.

Detekce skrytých kontrolních příznaků a zahalených přístupových cest

Mnoho starších programů obsahuje vložené podmínky přepsání nebo nouzové rutiny. Ty je často obtížné ručně najít kvůli hlubokému vnoření, neobvyklému pojmenování proměnných nebo umístění uvnitř záložní logiky. SMART TS XL používá skenování založené na pravidlech a vzorech k extrakci:

• Podmíněné větve řízené zřídka používanými hodnotami příznaků
• Logika spouštěná na základě ID terminálu, denní doby nebo metadat úlohy
• Obcházení větví pomocí příznaků commarrea, pevně zakódovaných uživatelských ID nebo rutin na úrovni maker

Zobrazuje všechny instance potenciálně privilegovaných rozhodovacích bodů a seřazuje je na základě dosažitelnosti, transakční expozice a potenciálu eskalace privilegií.

Automatizovaná pravidla pro zranitelnosti pro konstrukce CICS

Na rozdíl od povrchových skenerů, SMART TS XL obsahuje vestavěná pravidla přizpůsobená programům COBOL-CICS. Tato pravidla identifikují zranitelnosti související s:

• Nezabezpečené použití příkazů EXEC CICS ASSIGN a ADDRESS
• Nekonzistentní přístupová logika v rutinách PERFORMed
• Chybí ověření před příkazy WRITE, DELETE nebo START.
• Zastaralé pseudokonverzační toky se slabou správou stavu

Tato pravidla lze přizpůsobit na základě prostředí, obchodní funkce nebo auditních kritérií. Jsou obzvláště užitečná při identifikaci chybných předpokladů zanechaných staršími vývojovými týmy.

Zrychlená náprava s využitím zpětného sledování dopadů

Jakmile je zranitelnost označena, lze nápravu urychlit prostřednictvím SMART TS XLmožnost trasování. Pro jakoukoli logickou větev nebo programovou funkci může zobrazit:

• Všechny transakce, které k tomu vedou
• Všechny moduly, které volá
• Všechny proměnné, na kterých záleží
• Jakákoli přístupová logika, kterou obchází

Tato mapa trasování pomáhá vývojářům a auditorům okamžitě pochopit, zda je chyba izolovaná nebo systémově odhalená. Také zkracuje čas strávený ručním mapováním závislostí a snižuje riziko zavedení nových chyb během oprav.

Závěr a další kroky bezpečnostní kontroly

Zastaralé aplikace CICS obsahují kritickou obchodní logiku, ale jejich stáří a složitost vytvářejí bezpečnostní slepá místa, která standardní metody často přehlížejí. Statická analýza poskytuje spolehlivý způsob, jak odhalit skrytá rizika dříve, než je lze zneužít, zejména pokud se zaměřuje nejen na syntaxi nebo úryvky kódu, ale na širší tok řízení a předpoklady přístupu napříč transakcemi.

V tomto článku jsme zkoumali druhy nedostatků specifické pro systémy CICS:

• Autorizační logika rozptýlená napříč volně propojenými programy
• Zranitelné vzory příkazů jako ASSIGN a ADDRESS bez ověření
• Záložní transakce a ladicí cesty, které obcházejí běžné kontroly
• Znovu použité rutiny předpokládající důvěryhodný vstup od volajících

Pro organizace provozující rozsáhlá portfolia CICS již není dílčí přístup k zabezpečení proveditelný. Moderní hrozby mohou zneužít jediný přehlédnutí skryté ve stovkách modulů. Statická analýza, pokud je aplikována s hlubokým povědomím o kontextu, může tyto problémy odhalit dříve, než budou spuštěny nebo se dostanou k auditu.

Zde jsou klíčové kroky, které je třeba zvážit jako další:

• Vytvořte kompletní mapu transakcí a programů, včetně všech cest XCTL a LINK
• Identifikujte a refaktorujte veškerou sdílenou obchodní logiku, která provádí privilegované operace.
• Auditovat všechny větve ovlivněné příznaky commarea nebo rozhodnutími založenými na terminálu
• Zaveďte bezpečnostní ověření v vstupním bodě každé transakce
• Zkontrolujte záložní logiku a nouzové cesty pro případ neúmyslné expozice

Pro týmy, které chtějí tento proces urychlit a snížit manuální úsilí, jsou k dispozici nástroje jako SMART TS XL poskytují statickou analýzu přizpůsobenou architektuře CICS, což umožňuje bezpečný refaktoring s plnou sledovatelností toku.

Ochrana prostředí mainframe vyžaduje nejen bdělost, ale i přehled. A statická analýza je jednou z mála technik, které nabízejí obojí.