CICS 트랜잭션 보안 취약점 탐지를 위한 정적 분석

CICS 시스템은 세계에서 가장 민감하고 대용량의 트랜잭션 처리 환경을 지원합니다. 은행 및 보험부터 물류 및 방위 산업에 이르기까지 이러한 플랫폼은 보안 감독이 감당하기 어려운 워크로드를 처리합니다. 운영 가동 시간이 가장 중요한 요소이지만, CICS 애플리케이션의 구조는 다음과 같은 이점을 제공합니다. 숨겨진 위험 일상적인 검토 중에 놓치기 쉬운 사항입니다.

이러한 위험의 대부분은 레거시 코드에서 발생합니다. 중첩된 COBOL 모듈, 트랜잭션 프로그램 바인딩, 동적 프로그램 호출, 그리고 재사용된 쉼표(command)는 다음과 같은 문제를 야기할 수 있습니다. 취약점 표면적으로는 보이지 않는 취약점입니다. 일반적인 예로는 검증되지 않은 터미널 접근, 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작업 수준 보안 컨텍스트가 적절하게 적용되지 않으면 터미널 데이터 블록에 대한 직접 액세스가 보호 조치를 우회할 수 있습니다.

일반적인 위험 신호 패턴은 다음과 같습니다.

• 원시 입력에서 터미널 ID 또는 작업 번호 할당
• 사용 EXEC CICS ADDRESS TCTUA 또는 직접 쓰기에 따른 동등한 호출
• 역할 검증 없이 세션 상태에 따른 제어 전환

터미널 구조와 CICS 내부에 익숙한 공격자는 이러한 액세스 포인트를 악용하여 권한을 상승시키거나 의도치 않은 명령을 삽입할 수 있습니다.

이러한 취약점을 식별하려면 CICS 명령을 스캔하는 것뿐만 아니라 메모리 할당 전체에서 데이터 계보를 확인하고, 제어 매개변수의 출처를 확인하고, 안전하지 않거나 인증되지 않은 컨텍스트 값의 사용을 플래그로 지정해야 합니다.

CICS 환경의 정적 분석 범위

CICS 환경에서 정적 분석은 기본적인 구문이나 키워드 감지를 넘어야 합니다. 분석가는 코드 구조뿐만 아니라 트랜잭션 모델, 프로그램 연결, 데이터 흐름, 권한 경계까지 이해해야 합니다. 전체 평가는 사용자, 터미널, 애플리케이션이 공유 메모리와 연쇄 실행 로직을 통해 어떻게 상호작용하는지를 반영해야 합니다.

이러한 수준의 검사는 특히 수십 년 전에 작성되어 여러 팀이 오랜 시간 동안 유지 관리하는 애플리케이션을 사용하는 경우 복잡합니다. 프로그램은 구조화되지 않은 제어 흐름, 동적인 쉼표 사용, 그리고 재사용된 프로그램 ID에 의존하는 경우가 많은데, 이러한 모든 요소는 권한의 시작과 끝을 모호하게 만듭니다.

신뢰 경계를 위한 COBOL-CICS 소스 흐름 분석

최신 애플리케이션 환경에서 신뢰 경계는 일반적으로 프런트엔드 UI와 API 사이와 같은 계층에 의해 정의됩니다. CICS에서는 신뢰 경계가 종종 암묵적이며 프로그램 연결 내부에 묻혀 있습니다. 정적 분석은 어떤 프로그램이 다른 프로그램에 제어권을 넘기는지, 입력이 시스템에 어떻게 들어오는지, 그리고 해당 입력의 출처가 신뢰할 수 있는지 여부를 추적해야 합니다.

예를 들어, 로그인 트랜잭션으로 시작하는 체인은 다섯 개 이상의 프로그램을 거쳐 제어권을 넘길 수 있습니다. 이러한 프로그램 중 하나가 새로운 사용자 입력(예: 업데이트된 콤마 세그먼트)을 재검증하지 않고 받아들이면 신뢰 경계가 무너집니다. 정적 분석은 이러한 전환 지점을 검토 대상으로 표시해야 합니다.

검토해야 할 중요한 측면은 다음과 같습니다.

• 외부 데이터가 실행 경로에 들어오는 진입점
• 호출자를 확인하지 않고 발생하는 LINK 또는 XCTL 호출
• 실행이 인증된 흐름에서 인증되지 않은 흐름으로 전환되는 영역

하드코딩된 자격 증명 및 권한 에스컬레이션 논리 감지

하드코딩된 보안 토큰, 사용자 ID 또는 APPLID는 신속한 개발이나 긴급 패치 과정에서 도입되는 경우가 있습니다. 이러한 값은 표준 액세스 제어를 재정의하거나 실제 인증 실패 시 대체 액세스를 허용할 수 있습니다.

예를 들어, 다음과 같은 COBOL 세그먼트:

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

표면적으로는 위험하지 않아 보일 수 있지만, USER-ID 외부에서 영향을 받거나 다른 프로그램에서 재사용될 수 있으므로 지속적인 위험이 발생합니다.

정적 분석 엔진은 다음을 검색해야 합니다.

• IF 문 또는 할당의 보안에 민감한 값
• 검증 없이 직접 설정된 권한 플래그
• 제어 논리를 우회하는 일반 APPLID 또는 사용자 이름 사용

이러한 패턴은 미묘하지만, 보안 로직이 비즈니스 규칙과 얽혀 있는 더 큰 설계 문제를 나타내는 경우가 많습니다. 정적 분석을 통해 이러한 패턴을 분리하면 팀이 숨겨진 권한 경로 없이 안전하게 코드를 리팩토링할 수 있습니다.

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 원점 확인이 없는 제어 논리에서
• 가상 대화형 체인에 다시 들어갈 때 사용자 세션 재검증이 없음

하드코딩된 자격 증명 및 권한 에스컬레이션 논리 감지

정적 검토를 통해 COBOL 명령문에 직접 포함된 하드코딩된 사용자 ID, 특수 코드 또는 APPLID가 자주 발견됩니다. 이러한 항목은 내부 테스트나 운영상의 임시 해결책으로 추가되었을 수 있지만, 실제 운영 환경에 그대로 남아 심각한 위험을 초래하는 경우가 많습니다.

다음은 자주 표시되는 실제 샘플 패턴입니다.

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

or

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

이러한 공격은 통제되지 않는 경로를 생성하여 높은 권한으로 접근하게 합니다. 공격자가 터미널에 접근하거나 하드코딩된 사용자 ID를 발견하면, 애플리케이션의 나머지 부분은 마치 전체 인증이 이루어진 것처럼 동작할 수 있습니다.

좀 더 미묘한 예:

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

이 논리가 제거되거나 보호되지 않으면, 조작된 입력으로 인해 일반 사용자를 대상으로 하지 않는 로그, 파일 포인터 또는 메모리 진단을 노출하는 기능이 활성화될 수 있습니다.

이러한 결함을 감지하기 위한 정적 규칙을 작성할 때 다음 사항에 중점을 두십시오.

• IF or EVALUATE 사용자 또는 터미널에 연결된 하드코딩된 리터럴 값을 사용하는 명령문
• 하드코딩된 자격 증명을 액세스 플래그에 직접 매핑
• 다음과 같은 플래그 BYPASS, OVERRIDE및 DEBUG 조건 논리를 트리거하는
• 사용자 이름이나 터미널 ID에 대한 표면적인 검사로만 보호되는 코드 섹션

많은 경우 이러한 점검은 비공식적으로 추가되었고 검토되지 않았습니다. 정적 검사를 통해 수동 점검을 위해 플래그를 지정하거나, 반복적인 오용에 대해 패턴 기반 알림을 시행해야 합니다.

정적 분석 렌즈를 확장하여 이러한 경계 조건과 하드코딩된 대체 방안을 포착함으로써 감사원과 보안 엔지니어는 CICS 애플리케이션이 신뢰 체인을 끊을 수 있는 부분을 더 잘 파악할 수 있습니다. 나머지 시스템은 안전하게 작동하는 것처럼 보이더라도 말입니다.

보안 위험을 나타내는 코드 구조 패턴

개별 CICS 명령은 단독으로는 안전해 보일 수 있지만, 프로그램 로직의 구조가 트랜잭션의 실제 보안 여부를 결정하는 경우가 많습니다. 정적 분석은 단순히 줄 단위의 스캐닝을 넘어 프로그램 간 상호 작용 방식, 권한 유추 방식, 그리고 제어 흐름에 암묵적 신뢰가 포함된 부분을 파악해야 합니다.

레거시 시스템은 특히 이러한 패턴에 취약합니다. 시간이 지남에 따라 개발팀은 임시 로직, 권한 단축, 그리고 관심사 분리를 모호하게 만드는 다목적 트랜잭션을 도입합니다. 이러한 구조적 안티패턴을 파악하는 것은 트랜잭션 보안을 강화하는 데 필수적입니다.

권한이 상승된 트랜잭션-프로그램 매핑

각 CICS 트랜잭션 ID는 일반적으로 특정 프로그램 또는 디스패치 루틴에 매핑됩니다. 그러나 많은 시스템은 여러 모듈에서 트랜잭션 코드를 재사용하거나 사용자 입력에 따라 여러 민감한 기능을 수행할 수 있는 광범위한 프로그램 핸들러를 할당합니다.

적절한 필터링 없이 범용 핸들러가 높은 권한의 트랜잭션에 연결되면 위험해집니다. 정적 분석은 어떤 트랜잭션 ID가 어떤 프로그램에 매핑되는지 추적하고, 각 프로그램이 해당 트랜잭션 컨텍스트에서 어떤 로직을 실행하는지 확인해야 합니다.

예:

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 사용자가 역할 제한을 우회하고 삭제 또는 업데이트 논리를 호출할 수 있도록 허용할 수 있습니다.

위험 지표는 다음과 같습니다.

• 사용자가 제공한 플래그를 기반으로 여러 가지 권한이 있는 작업을 수행하는 단일 프로그램
• 하드코딩된 트랜잭션-함수 제한이 부족함
• 환경 또는 사업부 간 공유 거래 코드
• 디스패치 모듈 내의 특정 지점에 연결된 액세스 검사가 없음

정적 스캔은 commarea 플래그가 흐름을 제어하는 위치와 해당 흐름이 인증, 역할 검증 또는 리소스 수준 제약 조건으로 보호되는지 여부를 식별해야 합니다.

명령 수준 대 매크로 수준 호출 경로의 약점

또 다른 위험 요소는 명령 수준 프로그램과 매크로 수준 프로그램 간의 불일치입니다. 시간이 지남에 따라 발전해 온 시스템은 종종 두 가지 스타일이 혼합되어 있습니다. 명령 수준 코드는 구조화된 구문과 더 나은 가독성의 이점을 제공하는 반면, 매크로 수준 코드는 낮은 수준의 접근 권한과 더 적은 보호 기능을 제공하는 경향이 있습니다.

두 유형을 함께 사용하면 미묘한 호출 경로 취약점이 발생할 수 있으며, 특히 매크로 수준 프로그램이 중간 보안을 적용하지 않고 동적으로 연결된 경우 더욱 그렇습니다.

예:

• 명령 수준 프로그램은 공유 메모리를 직접 읽거나 수정하는 매크로 수준 모듈에 연결됩니다.
• 매크로 수준 모듈은 호출 프로그램이 이미 데이터의 유효성을 검사했다고 가정합니다.
• 입력과 실행 사이에 중간 검사는 수행되지 않습니다.

흐름에 대한 간단한 보기:

* 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 특정 API 남용의 정적 감지

CICS는 시스템 수준 리소스와 상호 작용하는 광범위한 EXEC 명령과 매크로를 제공합니다. 여기에는 터미널 식별자, 작업 번호, 세션 메모리, 트랜잭션 라우팅 로직 등이 포함됩니다. 이러한 기능은 유연성을 제공하지만, 충분한 보안 조치 없이 사용할 경우 취약점이 발생할 수 있습니다. 이러한 인터페이스를 오용하면 의도치 않은 권한 상승, 제어 우회 또는 무단 시스템 영역 접근이 발생할 수 있습니다.

정적 분석을 통해 개발자와 감사자는 API 호출 방식, API에서 사용하는 매개변수, 그리고 호출 컨텍스트가 적절한 검증을 제공하는지 여부를 검토하여 이러한 위험을 식별할 수 있습니다. 적절한 구현을 위해서는 트랜잭션 간 실행 컨텍스트, 액세스 패턴, 데이터 흐름 경계를 면밀히 검토해야 합니다.

EXEC CICS ASSIGN 및 ADDRESS의 안전하지 않은 사용 추적

The ASSIGN ADDRESS 명령은 CICS 내부 구조에 직접 액세스할 수 있도록 합니다. 여기에는 터미널 ID, 애플리케이션 식별자, 작업별 메모리 위치와 같은 중요한 메타데이터가 포함됩니다. 이러한 값은 로깅이나 세션 추적에 자주 사용되지만, 제어 로직이 보안 결정을 위해 이러한 값에 의존할 경우 위험해질 수 있습니다.

이 예제를 보자 :

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

여기서 접근 제어는 터미널 ID에 직접 연결됩니다. 해당 값을 알고 있거나 터미널 설정을 스푸핑할 수 있는 사용자는 이 논리를 악용하여 보안 메커니즘을 우회할 수 있습니다.

또는 다음과 같은 변형을 고려하십시오. ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

고립된 상태에서는 이것이 무해해 보입니다. 그러나 EIBTASKN 나중에 인증이나 거래 승인에 사용되면 예측 가능성과 무단 세션 사칭의 위험이 있습니다.

안전하지 않은 ASSIGN 및 ADDRESS 사용의 일반적인 지표는 다음과 같습니다.

• 터미널 ID, APPLID 또는 작업 번호만을 기준으로 분기 제어
• 액세스 검증 또는 우회 플래그에 할당된 값을 직접 사용
• ADDRESS 명령 후 구조적 검증 없이 포인터 참조
• IF 조건에서 시스템이 할당한 식별자와 비교한 하드코딩된 값

정적 스캐닝 도구는 특히 할당된 데이터가 프로그램 라우팅이나 권한 논리에 영향을 미치는 경우 이러한 조건을 플래그로 표시하도록 구성해야 합니다.

대체 실행 경로를 통한 트랜잭션 흐름 변조

많은 CICS 애플리케이션에서 폴백(fallback) 또는 대체 트랜잭션 라우팅(alternate transaction routing)을 통해 장애 허용성을 향상시킵니다. 하지만 이러한 대체 경로는 적절한 접근 검증이 부족하거나 의도치 않은 상황에서 접근될 수 있습니다. 이로 인해 공격자가 정상적인 트랜잭션 흐름 외부에서 민감한 로직을 실행할 수 있는 기회가 발생합니다.

다음 사례를 고려해 보세요.

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

이 코드는 쉼표가 전달되지 않으면 실행 경로를 변경합니다. 하지만 RETRYTX 신뢰할 수 있는 시퀀스에서만 사용하도록 설계되었을 수 있습니다. 자체 검증을 시행하지 않으면 사용자는 길이가 0인 트랜잭션을 트리거하는 것만으로도 민감한 기능에 접근할 수 있습니다.

또 다른 예로는 침묵의 확대가 있습니다.

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

If ALTID 더 큰 권한이나 더 광범위한 기능이 있는 트랜잭션에 매핑되고 역할 검사가 부족하여 이러한 대체 조치로 인해 의도치 않은 액세스가 발생합니다.

일반적으로 이러한 위험은 다음과 같은 이유로 발생합니다.

• 오류 상태에 따라 프로그램을 전환하기 위해 START, XCTL 또는 LINK 사용
• 여러 거래 코드에서 재사용되는 프로그램 ID
• 다운스트림 모듈에 대한 검증을 연기하는 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

의도한 대로 사용하면 안전해 보입니다. 하지만 다른 트랜잭션이 프로그램 2을 거치지 않고 프로그램 1를 직접 시작하면 변수 SESSION-AUTH 초기화되지 않았거나 위조되었을 수 있습니다. 두 번째 프로그램은 자격 증명을 다시 확인하지 않고 변수만을 기반으로 세션이 유효하다고 신뢰합니다.

정적 분석은 특히 다음과 같은 프로그램 전환 과정에서 변수 할당을 추적해야 합니다.

• 한 프로그램이 다른 프로그램이 액세스 결정을 위해 읽는 플래그를 설정하는 경우
• 인증 논리 외부에 권한 논리가 존재하는 경우
• 프로그램을 직접 실행하고 일반 항목 검증을 우회할 수 있는 경우

이러한 패턴은 기존 디자인에서 매우 흔하게 발생하며 수동 검토에서는 종종 간과됩니다.

내부 디버그 또는 테스트 모드를 통한 제어 흐름 전환

개발자는 테스트 중에 도움을 주기 위해 숨겨진 플래그나 디버그 모드를 포함하는 경우가 있습니다. 이러한 기능이 배포 전에 제거되지 않거나 운영 터미널에서 접근할 수 있는 경우, 애플리케이션의 민감한 부분에 대한 백도어가 될 수 있습니다.

예:

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

또는 더 미묘하게:

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

두 번째 사례에서는, 근무 시간 외 루틴이 일부 정상적인 보안 검사를 우회할 수 있으며, 이는 일괄 작업이나 비상 대응을 위한 것일 수 있습니다. 그러나 대화형 세션에서 트리거될 수 있다면, 시간 기반 공격 벡터가 발생할 수 있습니다.

난독화되거나 위험한 논리를 스캔할 때 정적 분석은 다음을 우선시해야 합니다.

• 보안 논리를 제어하는 비정상적인 조건(시간, 터미널 ID, 지역 코드)
• 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 프로그램의 호출 그래프를 추적하여 제어 플래그가 확인되지 않은 commarea 필드를 통해 전달되었음을 발견했으며, 동일한 프로그램 항목에 접근하는 다른 트랜잭션 5개를 식별했습니다. 수동 추적에서는 이 부분을 놓쳤습니다.

숨겨진 제어 플래그 및 난독화된 액세스 경로 감지

많은 레거시 프로그램에는 내장된 오버라이드 조건이나 비상 루틴이 포함되어 있습니다. 이러한 조건은 중첩이 깊거나, 변수 이름이 일반적이지 않거나, 대체 로직 내부에 배치되어 있기 때문에 수동으로 찾기 어려운 경우가 많습니다. SMART TS XL 규칙 기반 및 패턴 매칭 스캔을 사용하여 다음을 추출합니다.

• 거의 사용되지 않는 플래그 값으로 제어되는 조건 분기
• 터미널 ID, 시간 또는 작업 메타데이터를 기반으로 트리거되는 로직
• 쉼표 플래그, 하드코딩된 사용자 ID 또는 매크로 수준 루틴을 사용하여 분기를 우회합니다.

잠재적으로 특권이 있는 의사결정 지점의 모든 인스턴스를 표면화하고 도달 가능성, 거래 노출, 특권 확대 가능성을 기준으로 순위를 매깁니다.

CICS 구성에 대한 자동화된 취약성 규칙

표면 수준 스캐너와 달리 SMART TS XL COBOL-CICS 프로그램에 맞춰 내장된 규칙이 포함되어 있습니다. 이 규칙은 다음과 관련된 취약점을 식별합니다.

• 안전하지 않은 EXEC CICS ASSIGN 및 ADDRESS 사용
• PERFORMed 루틴의 일관되지 않은 액세스 논리
• WRITE, DELETE 또는 START 명령 전에 검증이 누락되었습니다.
• 취약한 상태 관리가 있는 구식 의사 대화 흐름

이러한 규칙은 환경, 비즈니스 기능 또는 감사 기준에 따라 맞춤 설정할 수 있습니다. 특히 기존 개발팀이 남긴 잘못된 가정을 파악하는 데 유용합니다.

영향 추적을 통한 가속화된 교정

취약점이 플래그로 표시되면 다음을 통해 수정을 가속화할 수 있습니다. SMART TS XL의 추적 기능입니다. 모든 논리 분기 또는 프로그램 함수에 대해 다음을 표시할 수 있습니다.

• 이를 초래하는 모든 거래
• 이것이 호출하는 모든 모듈
• 모든 변수는 다음과 같습니다.
• 우회하는 모든 액세스 논리

이 추적 맵은 개발자와 감사자가 결함이 고립된 것인지 아니면 시스템적으로 노출된 것인지 즉시 파악하는 데 도움이 됩니다. 또한 종속성을 수동으로 매핑하는 데 소요되는 시간을 줄이고 패치 적용 중 새로운 버그가 발생할 위험을 줄여줍니다.

결론 및 다음 보안 검토 단계

레거시 CICS 애플리케이션은 중요한 비즈니스 로직을 보유하고 있지만, 오래되고 복잡한 구조로 인해 표준 방식으로는 종종 간과되는 보안 사각지대가 발생합니다. 정적 분석은 숨겨진 위험을 악용되기 전에 발견할 수 있는 신뢰할 수 있는 방법을 제공하며, 특히 구문이나 코드 조각뿐만 아니라 트랜잭션 전반의 더 광범위한 제어 흐름과 접근 가정을 대상으로 할 때 더욱 그렇습니다.

이 기사에서는 CICS 시스템에만 존재하는 다음과 같은 결함 유형을 살펴보았습니다.

• 느슨하게 결합된 프로그램에 분산된 권한 부여 논리
• 검증 없이 ASSIGN 및 ADDRESS와 같은 취약한 명령 패턴
• 정상적인 검사를 우회하는 폴백 트랜잭션 및 디버그 경로
• 호출자로부터 신뢰할 수 있는 입력을 가정하는 재사용된 루틴

대규모 CICS 포트폴리오를 운영하는 조직의 경우, 단편적인 보안 접근 방식은 더 이상 유효하지 않습니다. 최신 위협은 수백 개의 모듈에 숨겨진 단 하나의 실수도 악용할 수 있습니다. 정적 분석에 심층적인 상황 인식을 적용하면, 문제가 발생하거나 감사를 받기 전에 이러한 문제를 파악할 수 있습니다.

다음 단계로 고려해야 할 주요 조치는 다음과 같습니다.

• 모든 XCTL 및 LINK 경로를 포함하여 전체 트랜잭션-프로그램 맵을 만듭니다.
• 특권 작업을 수행하는 공유 비즈니스 로직을 식별하고 리팩토링합니다.
• commarea 플래그 또는 터미널 기반 결정의 영향을 받는 모든 지점을 감사합니다.
• 각 거래의 진입 지점에서 보안 검증을 설정합니다.
• 의도치 않은 노출에 대한 대체 논리 및 비상 경로를 검토합니다.

이 프로세스를 가속화하고 수동 작업을 줄이려는 팀의 경우 다음과 같은 도구가 필요합니다. SMART TS XL CICS 아키텍처에 맞춰 정적 분석을 제공하여 전체 흐름 추적을 통한 안전한 리팩토링을 가능하게 합니다.

메인프레임 환경을 보호하려면 경계뿐만 아니라 가시성도 필요합니다. 정적 분석은 이 두 가지를 모두 제공하는 몇 안 되는 기술 중 하나입니다.