Analiza statyczna w celu wykrywania luk w zabezpieczeniach transakcji CICS

Systemy CICS obsługują jedne z najbardziej wrażliwych i wymagających dużej liczby transakcji środowisk na świecie. Od bankowości i ubezpieczeń, po logistykę i obronność, platformy te obsługują obciążenia, które nie mogą sobie pozwolić na nadzorowanie bezpieczeństwa. Chociaż czas sprawności operacyjnej często jest najważniejszy, struktura aplikacji CICS wprowadza… ukryte ryzyko które łatwo przeoczyć podczas rutynowych przeglądów.

Wiele z tych zagrożeń ma swoje źródło w starszym kodzie. Zagnieżdżone moduły COBOL, powiązania transakcji z programem, dynamiczne wywołania programów i ponownie wykorzystywane obszary przecinków mogą powodować luki które nie są widoczne z zewnątrz. Typowe przykłady to niezweryfikowany dostęp do terminala, niewłaściwe użycie instrukcji XCTL lub LINK oraz podwyższone uprawnienia przyznane poprzez nieprawidłowe kierowanie transakcjami. Te wady mogą występować w środowisku produkcyjnym latami bez generowania alertów.

Analiza statyczna Oferuje ustrukturyzowany sposób identyfikacji tych problemów, zanim zostaną wykorzystane. Jednak w przeciwieństwie do aplikacji internetowych lub API, skanowanie obciążeń CICS wymaga znacznie głębszej inspekcji. Analitycy muszą śledzić przepływ sterowania na wielu poziomach programu, rozumieć, jak dane przemieszczają się przez pamięć współdzieloną i wykrywać wzorce specyficzne dla zachowań transakcji na komputerach mainframe.

W tym artykule skupiono się na tym, jak stosować analizę statyczną w środowiskach CICS w celu wykrywania i łagodzenia luk w zabezpieczeniach. Przedstawiono w nim struktury wysokiego ryzyka, na które należy zwrócić uwagę, pokazano, jak interpretować logikę transakcji w kodzie COBOL, a także przedstawiono wskazówki dla inżynierów, którzy muszą dokładnie i szczegółowo analizować duże, starsze systemy. Celem jest pomoc zespołom w zabezpieczaniu warstw transakcyjnych bez zgadywania i zakłóceń.

Zrozumienie powierzchni ataków transakcyjnych CICS

Transakcje CICS to nie tylko programowe jednostki pracy. Są one głęboko osadzone w kontroli dostępu, tożsamości użytkowników, autoryzacji zasobów i integralności sesji. Wiele systemów mainframe opiera się na dekadach doświadczeń w projektowaniu, w których egzekwowanie zabezpieczeń jest dorozumiane, a nie jawne. Wiąże się to z ryzykiem, które często jest pomijane podczas testów, a nawet audytów zgodności.

Analiza statyczna na tym poziomie rozpoczyna się od mapowania, gdzie przekazywana jest kontrola, jak obsługiwane są dane wejściowe oraz które ścieżki są osiągalne w określonych kontekstach wykonania. Nawet systemy, które pomyślnie przeszły testy penetracyjne, mogą nadal zawierać luki w zabezpieczeniach związane z błędnie kierowanymi lub nadmiernie uprzywilejowanymi przepływami transakcji.

Ukryte luki w zabezpieczeniach połączeń EXEC CICS

Częstą słabością jest dynamiczne wykorzystanie EXEC CICS LINK, XCTLlub RETURN bez weryfikacji źródła ani kontekstu wywołania. Gdy programy są luźno powiązane, a nazwy programów są dostarczane zewnętrznie lub konstruowane dynamicznie, złośliwe dane wejściowe mogą kierować wykonywanie do modułów z podwyższonymi uprawnieniami.

W praktyce może to wyglądać następująco:

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

If PROG-NAME jest budowany na podstawie wartości dostarczonych przez użytkownika lub mapowany z tabeli bez ścisłej walidacji, nieautoryzowani użytkownicy mogą wywołać poufne programy, których ujawnienie nie było zamierzone.

Analiza statyczna musi wykryć takie ścieżki, szczególnie tam, gdzie:

• Nazwy programów są tworzone z wartości połączonych lub zamaskowanych
• Nie wdrożono kontroli zapasowej dla dozwolonych lub oczekiwanych celów
• Programy odbiorcze działają bez dalszej weryfikacji uprawnień

Wzory eskalacji kontroli SVC i pamięci masowej

Niektóre wywołania oparte na SVC lub wewnętrzne procedury obsługi dostępne za pośrednictwem instrukcji na poziomie makr mogą umożliwiać eskalację poprzez manipulację pamięcią. Niewłaściwe użycie ADDRESS, ASSIGNlub bezpośredni dostęp do bloków danych terminala może ominąć zabezpieczenia, gdy kontekst zabezpieczeń na poziomie zadania nie jest prawidłowo egzekwowany.

Typowy wzór czerwonej flagi obejmuje:

• Przypisywanie identyfikatora terminala lub numeru zadania z surowych danych wejściowych
• Korzystanie z EXEC CICS ADDRESS TCTUA lub równoważne wywołania, po których następują bezpośrednie zapisy
• Przełączanie kontroli na podstawie stanu sesji bez weryfikacji roli

Osoby atakujące znające strukturę terminali i mechanizmy wewnętrzne CICS mogą wykorzystać te punkty dostępu do podniesienia uprawnień lub wprowadzenia niezamierzonych poleceń.

Aby zidentyfikować te luki w zabezpieczeniach, należy nie tylko przeskanować polecenia CICS, ale także ustalić pochodzenie danych w ramach przydziałów pamięci, sprawdzić pochodzenie parametrów sterujących i oznaczyć użycie niebezpiecznych lub nieuwierzytelnionych wartości kontekstowych.

Zakres analizy statycznej w środowisku CICS

Analiza statyczna w środowiskach CICS musi wykraczać poza podstawową składnię i wykrywanie słów kluczowych. Analitycy muszą rozumieć nie tylko strukturę kodu, ale także model transakcji, powiązania programów, przepływy danych i granice uprawnień. Pełna ocena powinna odzwierciedlać interakcje użytkowników, terminali i aplikacji za pośrednictwem pamięci współdzielonej i logiki wykonywania łańcuchowego.

Ten poziom inspekcji jest złożony, zwłaszcza w przypadku aplikacji napisanych dekady temu i utrzymywanych przez wiele zespołów przez długi czas. Programy często opierają się na niestrukturyzowanym przepływie sterowania, dynamicznym wykorzystaniu obszarów komend i ponownym wykorzystywaniu identyfikatorów programów, co utrudnia określenie, gdzie zaczyna się i kończy autoryzacja.

Analiza przepływu źródłowego COBOL-CICS w celu określenia granic zaufania

W nowoczesnych środowiskach aplikacji granice zaufania są zazwyczaj definiowane warstwami, takimi jak interfejs użytkownika (UI) i interfejs API. W systemach CICS granice zaufania są często niejawne i ukryte w powiązaniach między programami. Analiza statyczna musi śledzić, które programy przekazują kontrolę innym, gdzie dane wejściowe trafiają do systemu i czy źródło tych danych jest zaufane.

Na przykład łańcuch rozpoczynający się transakcją logowania może przekazać kontrolę pięciu lub więcej programom. Jeśli jeden z tych programów zaakceptuje nowe dane wejściowe użytkownika (na przykład poprzez zaktualizowany segment obszaru comma) bez ponownej weryfikacji, granica zaufania zostanie naruszona. Analiza statyczna powinna oznaczyć te punkty przejścia do przeglądu.

Należy zbadać następujące istotne aspekty:

• Punkty wejścia, przez które dane zewnętrzne trafiają na ścieżkę wykonania
• Wywołania LINK lub XCTL wykonywane bez weryfikacji osoby wywołującej
• Obszary, w których wykonywanie przełącza się z przepływu uwierzytelnionego na nieuwierzytelniony

Wykrywanie zakodowanych na stałe danych uwierzytelniających i logiki eskalacji uprawnień

Zakodowane na stałe tokeny bezpieczeństwa, identyfikatory użytkowników lub identyfikatory APPLID są czasami wprowadzane podczas szybkiego rozwoju lub awaryjnego wdrażania poprawek. Wartości te mogą zastąpić standardowe mechanizmy kontroli dostępu lub umożliwić dostęp awaryjny w przypadku niepowodzenia rzeczywistego uwierzytelnienia.

Na przykład segment COBOL-a taki jak:

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

na pierwszy rzut oka może nie wydawać się niebezpieczne, ale jeśli USER-ID może podlegać wpływom zewnętrznym lub być ponownie wykorzystana w innych programach, stwarza jednak trwałe ryzyko.

Silniki analizy statycznej powinny szukać:

• Wartości wrażliwe pod kątem bezpieczeństwa w instrukcjach IF lub przypisaniach
• Flagi autorytetu ustawiane bezpośrednio, bez weryfikacji
• Stosowanie ogólnych identyfikatorów aplikacji lub nazw użytkowników, które omijają logikę sterowania

Te wzorce są subtelne, ale ich obecność często sygnalizuje poważniejsze problemy projektowe, gdzie logika bezpieczeństwa przeplata się z regułami biznesowymi. Wyizolowanie ich poprzez analizę statyczną pomaga zespołom bezpiecznie refaktoryzować kod, unikając ukrytych ścieżek uprawnień.

Zakres analizy statycznej w środowisku CICS

Systemy CICS znacząco różnią się od tradycyjnych stosów aplikacji. Podczas gdy nowoczesne usługi udostępniają interfejsy API i przepływy sterowane zdarzeniami, aplikacje CICS często działają jako ściśle powiązane łańcuchy programów, które opierają się na danych przekazywanych przez obszary przecinków, dane wejściowe terminala i pamięć współdzieloną. Taka architektura sprawia, że ​​analiza statyczna jest szczególnie trudna. Analitycy nie szukają jedynie znanych, podatnych na ataki wywołań, ale muszą zrekonstruować przepływ wykonywania w wielu programach, z których niektóre mogą obejmować dekady rozwoju starszych wersji.

Rzetelna analiza statyczna musi uwzględniać sposób, w jaki dane trafiają do systemu, sposób przekazywania kontroli z jednego modułu do drugiego oraz miejsca, w których walidacja jest oczekiwana, ale nie występuje. Naruszenia bezpieczeństwa w systemie CICS nie zawsze wynikają z ewidentnie niebezpiecznych wywołań. Częściej wynikają one z pominiętych założeń dotyczących zaufania, brakujących kontroli kontekstu lub niezgodności uprawnień, które występują w zagnieżdżonych lub odroczonych przepływach wykonania.

Analiza przepływu źródłowego COBOL-CICS w celu określenia granic zaufania

Typowa transakcja COBOL-CICS nie składa się z pojedynczego monolitycznego bloku. Często obejmuje wiele programów połączonych EXEC CICS LINK, XCTLlub RETURN, wykorzystując bloki obszaru commarea do współdzielenia danych. Wiele programów nie weryfikuje niezależnie odbieranej zawartości obszaru commarea, opierając się zamiast tego na założeniu, że zaufany użytkownik przeprowadził już walidację. To założenie jest jednym z najczęstszych źródeł utraty uprawnień i nieautoryzowanego dostępu.

Analiza statyczna musi identyfikować punkty początkowe wejścia danych i śledzić ich propagację w tych połączeniach. Na przykład:

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

Następnie w ACCTUPD, może pojawić się następujący komunikat:

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

Tworzy to dorozumianą granicę zaufania. Jeśli WS-USERID czy został nadpisany lub sfałszowany wcześniej w trakcie przepływu, ACCTUPD wykonywałby bezmyślnie procedury administracyjne. Analiza statyczna musi korelować COMM-USERIDpochodzenie i oznacz cały kod źródłowy, który go wykorzystuje do podejmowania wrażliwych decyzji bez ponownej walidacji.

Typowe naruszenia granic zaufania wykrywalne za pomocą skanów statycznych obejmują:

• Gałęzie decyzyjne oparte na polach obszaru commarea bez uwierzytelniania lokalnego
• Wykonywanie logiki uzależnionej od wartości terminalnych lub APPLID
• w korzystaniu EIBTRMID, EIBTASKNlub EIBRESP w logice sterowania bez sprawdzania pochodzenia
• Brak ponownej walidacji sesji użytkownika przy ponownym wejściu do pseudo-łańcucha konwersacyjnego

Wykrywanie zakodowanych na stałe danych uwierzytelniających i logiki eskalacji uprawnień

Przeglądy statyczne często ujawniają zakodowane na stałe identyfikatory użytkowników, kody specjalne lub identyfikatory APPLID osadzone bezpośrednio w poleceniach COBOL. Chociaż mogły one zostać dodane na potrzeby testów wewnętrznych lub obejść operacyjnych, często pozostają w środowiskach produkcyjnych i stanowią poważne zagrożenie.

Poniżej przedstawiono często sygnalizowane wzorce z rzeczywistych przykładów:

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

or

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

Tworzą one niekontrolowane ścieżki dostępu z podwyższonym poziomem uprawnień. Jeśli atakujący uzyska dostęp do terminala lub odkryje zakodowany na stałe identyfikator użytkownika, reszta aplikacji może zachowywać się tak, jakby nastąpiło pełne uwierzytelnienie.

Bardziej subtelny przykład:

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

Jeśli ta logika nie zostanie usunięta lub zabezpieczona, zmodyfikowane dane wejściowe mogą aktywować funkcje ujawniające logi, wskaźniki plików lub diagnostykę pamięci nieprzeznaczone dla zwykłych użytkowników.

Tworząc statyczne reguły służące wykrywaniu takich wad, należy zwrócić uwagę na:

• IF or EVALUATE instrukcje wykorzystujące zakodowane na stałe wartości literałowe powiązane z użytkownikami lub terminalami
• Bezpośrednie mapowanie zakodowanych na stałe danych uwierzytelniających na flagi dostępu
• Flagi takie jak BYPASS, OVERRIDElub DEBUG które wyzwalają logikę warunkową
• Sekcje kodu chronione jedynie przez powierzchowne kontrole nazwy użytkownika lub identyfikatora terminala

W wielu przypadkach te kontrole zostały dodane nieformalnie i nigdy nie zostały zweryfikowane. Skanowanie statyczne powinno oznaczać je do ręcznej inspekcji lub egzekwować alerty oparte na wzorcach w przypadku powtarzających się nadużyć.

Rozszerzając zakres analizy statycznej o te warunki brzegowe i zakodowane na stałe zabezpieczenia, audytorzy i inżynierowie ds. bezpieczeństwa mogą uzyskać lepszy wgląd w miejsca, w których aplikacje CICS mogą przerwać łańcuch zaufania — nawet jeśli reszta systemu wydaje się działać bezpiecznie.

Wzory struktury kodu wskazujące na ryzyko bezpieczeństwa

Chociaż poszczególne polecenia CICS mogą wydawać się bezpieczne w izolacji, otaczająca je struktura logiki programu często decyduje o tym, czy transakcja jest rzeczywiście chroniona. Analiza statyczna musi wykraczać poza skanowanie wiersz po wierszu, aby zrozumieć interakcje programów, sposób wnioskowania uprawnień oraz miejsca, w których w przepływie sterowania wbudowano niejawne zaufanie.

Starsze systemy są szczególnie podatne na te wzorce. Z czasem zespoły programistyczne wprowadzają tymczasową logikę, skróty uprawnień i transakcje wielozadaniowe, które zacierają granicę między zadaniami. Identyfikacja tych strukturalnych antywzorców jest kluczowa dla wzmocnienia bezpieczeństwa transakcji.

Mapowanie transakcji do programu z podwyższonymi uprawnieniami

Każdy identyfikator transakcji CICS jest zazwyczaj przypisany do konkretnego programu lub procedury dyspozytorskiej. Jednak wiele systemów wykorzystuje kody transakcji w różnych modułach lub przypisuje obszerne procedury obsługi programów, które mogą wykonywać wiele wrażliwych funkcji na podstawie danych wprowadzonych przez użytkownika.

Staje się to niebezpieczne, gdy uniwersalny program obsługi transakcji jest powiązany z transakcją o wysokich uprawnieniach bez odpowiedniego filtrowania. Analiza statyczna musi śledzić, które identyfikatory transakcji są przypisane do poszczególnych programów i określić, jaką logikę każdy program wykonuje w kontekście danej transakcji.

Przykład:

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

Jeżeli powyższe jest mapowane na transakcję taką jak FINTRN01i że transakcja ma przypisane podwyższone uprawnienia systemowe, każde niewłaściwe użycie COMM-AREA-FUNCTION może pozwolić użytkownikowi na ominięcie ograniczeń roli i wywołanie logiki usuwania lub aktualizacji.

Wskaźniki ryzyka obejmują:

• Pojedyncze programy wykonujące wiele uprzywilejowanych akcji na podstawie flag dostarczonych przez użytkownika
• Brak zakodowanych na stałe ograniczeń transakcji i funkcji
• Współdzielone kody transakcji w różnych środowiskach lub jednostkach biznesowych
• Brak kontroli dostępu powiązanych z konkretnymi oddziałami w module wysyłkowym

Skanowanie statyczne powinno identyfikować, gdzie flagi obszaru commarea kontrolują przepływ i czy przepływy te są chronione przez jakiekolwiek uwierzytelnianie, walidację roli lub ograniczenia na poziomie zasobów.

Słabości ścieżki wywołań na poziomie poleceń i na poziomie makr

Innym źródłem ryzyka jest niespójność między programami na poziomie poleceń i na poziomie makro. Systemy, które ewoluowały z czasem, często zawierają mieszankę obu stylów. Podczas gdy kod na poziomie poleceń korzysta ze strukturalnej składni i lepszej czytelności, kod na poziomie makro oferuje zazwyczaj dostęp niższego poziomu i mniej zabezpieczeń.

Gdy oba typy są stosowane razem, mogą wprowadzać subtelne luki w zabezpieczeniach ścieżki wywołania, szczególnie jeśli programy na poziomie makro są łączone dynamicznie bez pośredniego egzekwowania zabezpieczeń.

Przykład:

• Program na poziomie poleceń nawiązuje połączenie z modułem na poziomie makr, który bezpośrednio odczytuje lub modyfikuje pamięć współdzieloną.
• Moduł makro zakłada, że ​​program wywołujący już zweryfikował dane.
• Pomiędzy wprowadzeniem a wykonaniem nie są wykonywane żadne kontrole pośrednie.

Uproszczony widok przepływu:

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

W tym przypadku modułowi na poziomie makr ufa się, że będzie działał bezpośrednio na wskaźnikach pamięci masowej. Jeśli program wywołujący nie zweryfikuje DATA-BLOCK, atakujący może manipulować obszarami pamięci lub odwoływać się do nieautoryzowanych zestawów danych.

Analiza statyczna powinna zwracać szczególną uwagę na:

• Wywołania LINK lub XCTL z programów strukturalnych do starszych modułów
• Przekazywanie parametrów pomiędzy kodem na poziomie poleceń i kodem na poziomie makr
• Korzystanie ze wskaźników pamięci masowej lub identyfikatorów plików systemowych bez sprawdzania ograniczeń
• Ponownie wykorzystane moduły, w przypadku których zakłada się, że walidacja danych wejściowych została przeprowadzona gdzie indziej

Rzadko są one wykrywane podczas testów, ponieważ warunki eksploatacji często wymagają dokładnego dopasowania między kontekstem terminala, parametrami zadania i przepływem wykonania. Jednak skanowanie statyczne może wykryć konfigurację strukturalną, która umożliwia te luki.

Dzięki identyfikowaniu zagrożeń strukturalnych — a nie tylko wadliwych linii kodu — analitycy mogą lepiej ocenić ogólny stan bezpieczeństwa systemów CICS i ustalić priorytety działań naprawczych na podstawie potencjalnego wpływu.

Statyczne wykrywanie nadużyć API specyficznych dla CICS

CICS udostępnia szeroką gamę poleceń i makr EXEC, które oddziałują z zasobami na poziomie systemu. Należą do nich identyfikatory terminali, numery zadań, pamięć sesji i logika routingu transakcji. Chociaż funkcje te oferują elastyczność, mogą one również stwarzać luki w zabezpieczeniach, gdy są używane bez odpowiednich zabezpieczeń. Niewłaściwe użycie tych interfejsów może skutkować niezamierzonym podniesieniem uprawnień, ominięciem kontroli lub dostępem do nieautoryzowanych obszarów systemu.

Analiza statyczna pozwala programistom i audytorom identyfikować takie zagrożenia, badając sposób wywoływania tych interfejsów API, pobierane przez nie parametry oraz to, czy kontekst wywołania zapewnia odpowiednią walidację. Prawidłowa implementacja wymaga starannej analizy kontekstu wykonania, wzorców dostępu i granic przepływu danych między transakcjami.

Śledzenie niebezpiecznego użycia EXEC CICS ASSIGN i ADDRESS

ASSIGN oraz ADDRESS Polecenia zapewniają bezpośredni dostęp do wewnętrznych struktur CICS. Obejmuje to krytyczne metadane, takie jak identyfikatory terminali, identyfikatory aplikacji i lokalizacje pamięci specyficzne dla zadań. Chociaż wartości te są często wykorzystywane do rejestrowania zdarzeń lub śledzenia sesji, stają się niebezpieczne, gdy logika sterowania opiera się na nich w decyzjach dotyczących bezpieczeństwa.

Weźmy ten przykład:

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

W tym przypadku kontrola dostępu jest bezpośrednio powiązana z identyfikatorem terminala. Użytkownik znający wartość lub mający możliwość podszywania się pod ustawienia terminala może wykorzystać tę logikę do ominięcia mechanizmów bezpieczeństwa.

Albo rozważ wariant obejmujący ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

W odosobnieniu wydaje się to nieszkodliwe. Jednakże, jeśli EIBTASKN jest później wykorzystywany do uwierzytelniania lub autoryzacji transakcji, wprowadza ryzyko przewidywalności i nieautoryzowanego podszywania się pod sesję.

Do typowych wskaźników niebezpiecznego użycia ASSIGN i ADDRESS należą:

• Kontroluj gałęzie wyłącznie na podstawie identyfikatora terminala, APPLID lub numeru zadania
• Bezpośrednie wykorzystanie przypisanych wartości do walidacji dostępu lub flag obejścia
• Odwołania do wskaźników bez walidacji strukturalnej po poleceniach ADDRESS
• Porównanie wartości zakodowanych na stałe z identyfikatorami przypisanymi przez system w warunkach IF

Narzędzia do skanowania statycznego powinny być skonfigurowane tak, aby sygnalizować takie warunki, zwłaszcza gdy przypisane dane wpływają na routing programu lub logikę uprawnień.

Manipulowanie przepływem transakcji poprzez alternatywne ścieżki realizacji

W wielu aplikacjach CICS, w celu zwiększenia odporności na błędy, stosuje się awaryjny lub alternatywny routing transakcji. Niestety, te alternatywne ścieżki mogą nie posiadać odpowiedniej walidacji dostępu lub mogą zostać wykorzystane w nieprzewidzianych okolicznościach. Stwarza to atakującym możliwość uruchomienia wrażliwej logiki spoza normalnego przepływu transakcji.

Rozważmy ten przypadek:

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

Ten kod przekierowuje wykonanie, jeśli nie przekazano obszaru przecinka. Ale RETRYTX może być zaprojektowany do użytku wyłącznie w zaufanych sekwencjach. Jeśli nie wymusza własnej walidacji, użytkownik może uzyskać dostęp do wrażliwej funkcjonalności, po prostu inicjując transakcję o zerowej długości.

Innym przykładem jest cicha eskalacja:

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

If ALTID mapuje się na transakcję z większymi uprawnieniami lub szerszą funkcjonalnością i brakuje w niej kontroli ról, to rozwiązanie awaryjne wprowadza niezamierzony dostęp.

Ryzyko w tym przypadku wynika zazwyczaj z:

• Użycie START, XCTL lub LINK do przełączania programów na podstawie stanów błędów
• Identyfikatory programów, które są ponownie wykorzystywane w wielu kodach transakcji
• Logika RETURN, która przekazuje walidację do modułów podrzędnych
• Wartości Commarea, które dyktują przepływ bez kontroli integralności

Analiza statyczna powinna utworzyć pełny graf transakcji, aby zidentyfikować programy z wieloma ścieżkami wejścia i wyróżnić te, które przejmują kontrolę po niepełnej walidacji. Nawet gdy funkcje wydają się odizolowane, ukryte przepływy mogą umożliwić atakującym uruchomienie operacji uprzywilejowanych poza oczekiwanym zakresem użycia.

Radzenie sobie ze złożonym zaciemnianiem logiki bezpieczeństwa

Jednym z najtrudniejszych aspektów zabezpieczania starszych aplikacji CICS jest rozwikłanie zaciemnionej lub głęboko zagnieżdżonej logiki bezpieczeństwa. Wiele programów CICS ewoluowało przez dekady, przechodziło przez różne zespoły i zawierało wiele warstw obsługi dostępu. W rezultacie kluczowe decyzje dotyczące bezpieczeństwa są często ukryte w niedostępnych ścieżkach, replikowane w różnych modułach lub podzielone na fragmentaryczne procedury. Analiza statyczna musi być w stanie zrekonstruować te wzorce i ujawnić, gdzie założenia lub przeoczenia wprowadziły ryzyko.

Identyfikacja ścieżek autoryzacji rozdzielonych w wielu programach

Twórcy systemów CICS często implementują pseudokonwersacyjne programy, aby zachować stan podczas wielu interakcji użytkowników. W ten sposób mogą nieumyślnie oddzielić uwierzytelnianie od autoryzacji. Jeden program weryfikuje dane uwierzytelniające, inny ustawia flagi sesji, a trzeci przeprowadza kontrolę dostępu. Jeśli jakikolwiek element tego łańcucha zostanie odłączony lub ponownie użyty w innym kontekście, powstaje luka w zabezpieczeniach.

Przykład:

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

Wydaje się to bezpieczne, jeśli jest używane zgodnie z przeznaczeniem. Ale jeśli inna transakcja uruchomi Program 2 bezpośrednio, bez przechodzenia przez Program 1, zmienna SESSION-AUTH może być niezainicjowany lub sfałszowany. Drugi program ufa, że ​​sesja jest prawidłowa na podstawie samej zmiennej, bez ponownego sprawdzania danych uwierzytelniających.

Analiza statyczna musi śledzić przypisania zmiennych podczas przejść między programami, zwłaszcza:

• Gdy jeden program ustawia flagę, którą inny program odczytuje w celu podjęcia decyzji o dostępie
• Gdy logika autoryzacji istnieje poza logiką uwierzytelniania
• Kiedy programy można uruchomić bezpośrednio i ominąć normalną walidację wpisów

Tego typu wzorce są niezwykle powszechne w starszych projektach i często pomijane podczas przeglądów ręcznych.

Przekierowania przepływu sterowania za pośrednictwem wewnętrznych trybów debugowania lub testowania

Programiści czasami dodają ukryte flagi lub tryby debugowania, aby ułatwić testowanie. Jeśli te funkcje nie zostaną usunięte przed wdrożeniem lub jeśli są dostępne z poziomu terminali produkcyjnych, mogą stanowić furtkę do wrażliwych części aplikacji.

Przykład:

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

Albo bardziej subtelnie:

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

W drugim przypadku procedura wykonywana po godzinach pracy może ominąć niektóre standardowe kontrole bezpieczeństwa, być może przeznaczone do zadań wsadowych lub reagowania w sytuacjach awaryjnych. Jeśli jednak można ją uruchomić z sesji interaktywnej, otwiera ona wektor ataku oparty na czasie.

Podczas skanowania w celu wykrycia zaciemnionej lub ryzykownej logiki analiza statyczna powinna priorytetowo traktować:

• Nietypowe warunki sterujące logiką bezpieczeństwa (pora dnia, identyfikator terminala, kod regionu)
• Flagi takie jak DEBUG, DEV, OVERRIDE, TEST lub BACKDOOR
• Sprawdzanie dostępu pomijane w określonych warunkach wykonania
• Ścieżki GOTO lub PERFORM, które omijają gałęzie walidacji

Celem jest ujawnienie wszystkiego, co pozwala na przejście wykonania do kodu uprzywilejowanego bez bezpośredniego, widocznego sprawdzenia autoryzacji.

Ponownie wykorzystane procedury z niespójną kontrolą dostępu

W wielu dużych aplikacjach CICS programiści wykorzystują wspólne procedury dostępu do danych lub logikę biznesową. Procedury te mogą być wywoływane zarówno przez transakcje publiczne, jak i wewnętrzne narzędzia administracyjne. Jeśli współdzielona logika zakłada, że ​​osoba wywołująca już zweryfikowała rolę użytkownika, a to założenie nie zawsze jest spełnione, staje się to pośrednią podatnością.

Klasyczna struktura wygląda następująco:

PERFORM UPDATE-ACCT-INFO

...

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

To jest bezpieczne tylko wtedy, gdy każdy dzwoniący UPDATE-ACCT-INFO poprawnie ustawia ROLE zmienna. Jeśli inna część aplikacji wywoła tę procedurę z ROLE jeśli nie zostanie zainicjowany lub jeśli osoba wywołująca ustawi go nieprawidłowo na podstawie słabego sprawdzenia, może nastąpić nieautoryzowany dostęp.

Skanowanie statyczne powinno sygnalizować:

• Wspólne procedury wykonujące działania wrażliwe na bezpieczeństwo
• Brak lokalnej walidacji w ramach wspólnych procedur
• Zmienne używane do podejmowania decyzji o dostępie, które są definiowane zewnętrznie
• Przypisywanie ról odbywa się daleko od miejsca egzekwowania

Ta forma zaciemniania wynika nie z celowego ukrywania, ale z długoterminowego dryfu architektonicznego. W miarę ponownego wykorzystywania komponentów w różnych modułach, pierwotne założenia dotyczące dostępu ulegają degradacji. Tylko dogłębne śledzenie kodu i korelacja kontekstowa mogą ujawnić te zagrożenia.

Korzystanie z SMART TS XL do wykrywania i eliminowania luk w zabezpieczeniach transakcji CICS

Przetwarzanie analizy bezpieczeństwa w starszych systemach mainframe jest z natury skomplikowane. Środowiska CICS często nie mają scentralizowanej struktury, mają minimalną nowoczesną dokumentację i obejmują dekady ewolucji procedur. SMART TS XL rozwiązuje te problemy, oferując statyczny silnik analityczny stworzony specjalnie dla wzorców specyficznych dla języków COBOL, PL/I, JCL i CICS. W przeciwieństwie do narzędzi ogólnego przeznaczenia, rozumie on architekturę i konwencje charakterystyczne dla ekosystemów mainframe.

Rekonstrukcja przepływu wielopoziomowego dla CICS

SMART TS XL Skanuje całe portfolio aplikacji i buduje mapę przepływu międzyprogramowego. Obejmuje to:

• Mapowania transakcji na program
• Przejścia między programami z wykorzystaniem LINK, XCTL i RETURN
• Propagacja zmienna i obszarowa
• Logika sterowania oparta na rolach i śledzenie warunków wejścia

Dzięki rekonstrukcji całych łańcuchów wykonawczych możliwe jest wykrycie, kiedy program przyjmujący zaufany kontekst jest rzeczywiście osiągalny z wielu punktów, w tym potencjalnie niezweryfikowanych.

Przykładowy przypadek użycia:

Wewnętrzny audyt ujawnił lukę w zabezpieczeniach, która uniemożliwiała transakcję TX94 uruchomił program, który pierwotnie był przeznaczony wyłącznie do użytku administratora. SMART TS XL Prześledziłem graf wywołań programu, odkryłem, że flaga kontrolna była przekazywana przez niezaznaczone pole obszaru comma i zidentyfikowałem pięć innych transakcji z dostępem do tego samego wpisu programu. Ręczne śledzenie tego przeoczyło.

Wykrywanie ukrytych flag kontrolnych i ukrytych ścieżek dostępu

Wiele starszych programów zawiera osadzone warunki nadpisywania lub procedury awaryjne. Często trudno je zlokalizować ręcznie ze względu na głębokie zagnieżdżenie, nietypowe nazewnictwo zmiennych lub umieszczenie w logice awaryjnej. SMART TS XL wykorzystuje skanowanie oparte na regułach i dopasowywanie wzorców w celu wyodrębnienia:

• Gałęzie warunkowe kontrolowane przez rzadko używane wartości flag
• Logika uruchamiana na podstawie identyfikatora terminala, pory dnia lub metadanych zadania
• Omijaj gałęzie, używając flag obszaru commarea, zakodowanych na stałe identyfikatorów użytkowników lub procedur na poziomie makr

Wyświetla wszystkie wystąpienia potencjalnie uprzywilejowanych punktów decyzyjnych i klasyfikuje je na podstawie dostępności, narażenia transakcji i potencjalnego zwiększenia uprawnień.

Zautomatyzowane reguły podatności dla konstrukcji CICS

W przeciwieństwie do skanerów powierzchniowych, SMART TS XL Zawiera wbudowane reguły dostosowane do programów COBOL-CICS. Identyfikują one luki w zabezpieczeniach związane z:

• Niebezpieczne użycie EXEC CICS ASSIGN i ADDRESS
• Niespójna logika dostępu w procedurach PERFORMed
• Brak walidacji przed poleceniami WRITE, DELETE lub START
• Przestarzałe pseudo-konwersacyjne przepływy ze słabym zarządzaniem stanem

Reguły te można dostosować do środowiska, funkcji biznesowej lub kryteriów audytu. Są one szczególnie przydatne w identyfikowaniu błędnych założeń pozostawionych przez starsze zespoły programistyczne.

Przyspieszona naprawa z śledzeniem wpływu

Po zgłoszeniu luki w zabezpieczeniach można przyspieszyć jej naprawę SMART TS XLMożliwość śledzenia. Dla dowolnej gałęzi logiki lub funkcji programu może pokazać:

• Wszystkie transakcje, które do tego prowadzą
• Wszystkie moduły, które wywołuje
• Zależy to od wszystkich zmiennych
• Jakakolwiek logika dostępu, którą omija

Ta mapa śledzenia pomaga programistom i audytorom natychmiast zrozumieć, czy błąd jest odizolowany, czy też występuje systemowo. Skraca również czas poświęcany na ręczne mapowanie zależności i zmniejsza ryzyko wprowadzenia nowych błędów podczas łatania.

Wnioski i kolejne kroki przeglądu bezpieczeństwa

Starsze aplikacje CICS zawierają krytyczną logikę biznesową, ale ich wiek i złożoność tworzą martwe punkty w zabezpieczeniach, które często są pomijane przez standardowe metody. Analiza statyczna zapewnia niezawodny sposób na wykrycie ukrytych zagrożeń, zanim zostaną one wykorzystane, zwłaszcza gdy dotyczy nie tylko składni lub fragmentów kodu, ale także szerszego przepływu sterowania i założeń dotyczących dostępu w transakcjach.

W tym artykule przyjrzeliśmy się rodzajom wad charakterystycznych dla systemów CICS:

• Logika autoryzacji rozproszona w luźno powiązanych programach
• Wrażliwe wzorce poleceń, takie jak ASSIGN i ADDRESS, bez walidacji
• Transakcje zapasowe i ścieżki debugowania, które omijają normalne kontrole
• Ponownie wykorzystane procedury zakładające zaufane dane wejściowe od osób wywołujących

W organizacjach zarządzających dużymi portfelami CICS fragmentaryczne podejście do bezpieczeństwa nie jest już wykonalne. Współczesne zagrożenia potrafią wykorzystać pojedynczy błąd ukryty w setkach modułów. Analiza statyczna, stosowana z uwzględnieniem głębokiej świadomości kontekstu, może wykryć te problemy, zanim staną się rzeczywiste lub zostaną poddane audytowi.

Oto kluczowe działania, które należy rozważyć jako kolejne kroki:

• Utwórz pełną mapę transakcji do programu, obejmującą wszystkie ścieżki XCTL i LINK
• Zidentyfikuj i przebuduj dowolną wspólną logikę biznesową, która wykonuje operacje uprzywilejowane
• Przeprowadź audyt wszystkich gałęzi objętych flagami obszaru commarea lub decyzjami opartymi na terminalu
• Wprowadź weryfikację bezpieczeństwa na wejściu każdej transakcji
• Przejrzyj logikę zapasową i ścieżki awaryjne na wypadek niezamierzonego narażenia

Zespoły chcące przyspieszyć ten proces i ograniczyć ręczną pracę mogą skorzystać z narzędzi takich jak SMART TS XL zapewniają analizę statyczną dostosowaną do architektury CICS, umożliwiającą bezpieczne refaktoryzowanie z pełną możliwością śledzenia przepływu.

Ochrona środowisk mainframe wymaga nie tylko czujności, ale i widoczności. A analiza statyczna to jedna z niewielu technik, która oferuje jedno i drugie.