CICS İşlem Güvenliği Açıklarını Tespit Etmek İçin Statik Analiz

CICS sistemleri, dünyanın en hassas ve yüksek hacimli işlem ortamlarından bazılarını destekler. Bankacılık ve sigortadan lojistik ve savunmaya kadar, bu platformlar güvenlik gözetimine tabi tutulamayacak iş yüklerini yönetir. Operasyonel çalışma süresi genellikle en çok dikkat çeken unsur olsa da, CICS uygulamalarının yapısı gizli riskler Rutin incelemeler sırasında gözden kaçırılması kolay olan.

Bu risklerin çoğu eski kodlardan kaynaklanmaktadır. İç içe geçmiş COBOL modülleri, işlem programı bağlamaları, dinamik program çağrıları ve yeniden kullanılan ortak alanlar, güvenlik açıkları Yüzeyden görünmeyenler. Yaygın örnekler arasında doğrulanmamış terminal erişimi, XCTL veya LINK talimatlarının kötüye kullanımı ve hatalı işlem yönlendirmesi yoluyla verilen yükseltilmiş izinler yer alır. Bu kusurlar, uyarı tetiklemeden yıllarca üretimde var olabilir.

Statik analiz Bu sorunlar istismar edilmeden önce tespit etmek için yapılandırılmış bir yol sunar. Ancak web veya API uygulamalarının aksine, CICS iş yüklerini taramak çok daha derinlemesine bir inceleme gerektirir. Analistler, birden fazla program düzeyinde kontrol akışını izlemeli, verilerin paylaşımlı bellekte nasıl hareket ettiğini anlamalı ve ana bilgisayar işlem davranışına özgü kalıpları tespit etmelidir.

Bu makale, güvenlik açıklarını ortaya çıkarmak ve azaltmak için CICS ortamlarında statik analizin nasıl uygulanacağına odaklanmaktadır. Dikkat edilmesi gereken yüksek riskli yapıları özetlemekte, COBOL kodunda işlem mantığının nasıl yorumlanacağını göstermekte ve büyük eski sistemleri doğru ve derinlemesine incelemesi gereken mühendislere rehberlik sağlamaktadır. Amaç, ekiplerin işlem katmanlarını tahmin yürütme veya kesintiye uğramadan güvence altına almalarına yardımcı olmaktır.

CICS İşlem Saldırı Yüzeylerini Anlama

CICS işlemleri yalnızca programatik iş birimleri değildir. Erişim kontrolü, kullanıcı kimliği, kaynak yetkilendirme ve oturum bütünlüğüne derinlemesine yerleşmişlerdir. Birçok ana bilgisayar sistemi, güvenlik uygulamalarının açıkça değil, ima yoluyla uygulandığı onlarca yıllık tasarım kalıplarına dayanır. Bu durum, testler veya hatta uyumluluk denetimleri sırasında genellikle gözden kaçan riskler ortaya çıkarır.

Bu düzeydeki statik analiz, kontrolün nereye aktarıldığının, girdinin nasıl işlendiğinin ve belirli yürütme bağlamlarında hangi yollara erişilebileceğinin haritalanmasıyla başlar. Penetrasyon testini geçen sistemler bile, yanlış yönlendirilmiş veya aşırı ayrıcalıklı işlem akışlarıyla ilgili güvenlik açıkları içerebilir.

EXEC CICS Çağrılarındaki Gizli Güvenlik Açıkları

Yaygın bir zayıflık, dinamik kullanımını içerir EXEC CICS LINK, XCTLya da RETURN Çağrının kökenini veya bağlamını doğrulamadan. Programlar gevşek bir şekilde zincirlendiğinde ve program adları harici olarak sağlandığında veya dinamik olarak oluşturulduğunda, kötü amaçlı girdiler yürütmeyi yükseltilmiş ayrıcalıklara sahip modüllere yönlendirebilir.

Pratikte bu şöyle görünebilir:

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

If PROG-NAME Kullanıcı tarafından sağlanan bir değerden oluşturulursa veya sıkı doğrulama yapılmadan bir tablodan eşlenirse, yetkisiz kullanıcılar ifşa edilmesi amaçlanmayan hassas programları çağırabilir.

Statik analiz, özellikle şu durumlarda bu tür yolları tespit etmelidir:

• Program adları, birleştirilmiş veya maskelenmiş değerlerden oluşturulur
• İzin verilen veya beklenen hedefler için herhangi bir geri dönüş kontrolü uygulanmadı
• Alıcı programlar daha fazla yetki doğrulaması olmadan çalışır

SVC ve Depolama Kontrol Yükseltme Modelleri

Makro düzeydeki talimatlar aracılığıyla erişilen belirli SVC tabanlı çağrılar veya dahili hizmet rutinleri, bellek manipülasyonu yoluyla yükseltmeye izin verebilir. ADDRESS, ASSIGN, veya terminal veri bloklarına doğrudan erişim, görev düzeyindeki güvenlik bağlamı düzgün bir şekilde uygulanmadığında güvenlik önlemlerini aşabilir.

Tipik bir kırmızı bayrak deseni şunları içerir:

• Ham girdiden bir terminal kimliği veya görev numarası atama
• kullanma EXEC CICS ADDRESS TCTUA veya doğrudan yazmaların ardından gelen eşdeğer çağrılar
• Rol doğrulaması olmadan oturum durumuna göre anahtarlama denetimi

Terminal yapılarına ve CICS iç işleyişine aşina olan saldırganlar, ayrıcalıkları yükseltmek veya istenmeyen komutlar enjekte etmek için bu erişim noktalarını kullanabilir.

Bu güvenlik açıklarının belirlenmesi yalnızca CICS komutlarının taranmasını değil, aynı zamanda bellek atamaları arasında veri soyunun çözümlenmesini, kontrol parametrelerinin kökeninin kontrol edilmesini ve güvenli olmayan veya kimliği doğrulanmamış bağlam değerlerinin kullanımlarının işaretlenmesini gerektirir.

CICS Ortamında Statik Analiz Kapsamı

CICS ortamlarında statik analiz, temel sözdizimi veya anahtar kelime tespitinin ötesine geçmelidir. Analistlerin yalnızca kodun yapısını değil, aynı zamanda işlem modelini, program bağlantılarını, veri akışlarını ve ayrıcalık sınırlarını da anlamaları gerekir. Kapsamlı bir değerlendirme, kullanıcıların, terminallerin ve uygulamaların paylaşımlı bellek ve zincirleme yürütme mantığı aracılığıyla nasıl etkileşim kurduğunu yansıtmalıdır.

Bu düzeyde bir denetim, özellikle onlarca yıl önce yazılmış ve zaman içinde birden fazla ekip tarafından bakımı yapılmış uygulamalarla çalışırken karmaşıktır. Programlar genellikle yapılandırılmamış kontrol akışına, dinamik alan kullanımına ve yeniden kullanılan program kimliklerine dayanır; bunların tümü, yetkinin nerede başlayıp nerede bittiğini belirsizleştirir.

COBOL-CICS Kaynak Akışının Güven Sınırları Açısından Analizi

Modern uygulama ortamlarında, güven sınırları genellikle ön uç kullanıcı arayüzü (UI) ile API arasındaki katmanlar gibi katmanlar tarafından tanımlanır. CICS'de ise güven sınırları genellikle örtüktür ve program bağlantıları içinde gömülüdür. Statik analiz, hangi programların kontrolü başkalarına devrettiğini, girdinin sisteme nereden girdiğini ve bu girdinin kaynağının güvenilir olup olmadığını izlemelidir.

Örneğin, bir oturum açma işlemiyle başlayan bir zincir, kontrolü beş veya daha fazla programa aktarabilir. Bu programlardan biri, yeni kullanıcı girdisini (örneğin, güncellenmiş bir alan segmenti aracılığıyla) yeniden doğrulamadan kabul ederse, güven sınırı bozulur. Statik analiz, bu geçiş noktalarını incelemeye tabi tutmalıdır.

İncelenmesi gereken kritik hususlar şunlardır:

• Harici verilerin yürütme yoluna girdiği giriş noktaları
• Arayanın doğrulanmadan gerçekleşen LINK veya XCTL çağrıları
• Yürütmenin kimlik doğrulamalı akıştan kimlik doğrulamasız akışa geçtiği alanlar

Sabit Kodlanmış Kimlik Bilgilerini ve Yetki Yükseltme Mantığını Algılama

Sabit kodlu güvenlik belirteçleri, kullanıcı kimlikleri veya APPLID'ler bazen hızlı geliştirme veya acil durum yamaları sırasında eklenir. Bu değerler, standart erişim kontrollerini geçersiz kılabilir veya gerçek kimlik doğrulama başarısız olduğunda yedek erişime izin verebilir.

Örneğin, şu şekilde bir COBOL segmenti:

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

yüzeyde tehlikeli görünmeyebilir, ancak eğer USER-ID dışarıdan etkilenebildiği veya başka programlarda tekrar kullanılabildiği için kalıcı bir risk oluşturur.

Statik analiz motorları şunları aramalıdır:

• IF ifadelerinde veya atamalarda güvenliğe duyarlı değerler
• Doğrulama yapılmadan doğrudan ayarlanan yetki bayrakları
• Kontrol mantığını atlatan genel APPLID'lerin veya kullanıcı adlarının kullanımı

Bu kalıplar incelikli görünse de, varlıkları genellikle güvenlik mantığının iş kurallarıyla iç içe geçtiği daha büyük tasarım sorunlarına işaret eder. Bunları statik analiz yoluyla izole etmek, ekiplerin kodu güvenli bir şekilde ve gizli ayrıcalık yolları olmadan yeniden düzenlemelerine yardımcı olur.

CICS Ortamında Statik Analiz Kapsamı

CICS sistemleri, geleneksel uygulama yığınlarından önemli ölçüde farklıdır. Modern hizmetler API'leri ve olay odaklı akışları kullanırken, CICS uygulamaları genellikle comreas, terminal girişi ve paylaşılan bellek üzerinden aktarılan verilere dayanan sıkı bir şekilde bağlı program zincirleri olarak çalışır. Bu mimari, statik analizi özellikle zorlaştırır. Analistler yalnızca bilinen güvenlik açığı çağrılarını aramakla kalmaz, aynı zamanda bazıları onlarca yıllık eski geliştirme süreçlerini kapsayan birden fazla program genelinde yürütme akışını yeniden yapılandırmalıdır.

Anlamlı bir statik inceleme, verilerin sisteme nasıl girdiğini, kontrolün bir modülden diğerine nasıl aktarıldığını ve doğrulamanın beklendiği ancak yapılmadığı durumları hesaba katmalıdır. CICS'deki güvenlik ihlalleri her zaman açıkça tehlikeli çağrılardan kaynaklanmaz. Daha sıklıkla, güven hakkındaki gözden kaçan varsayımlardan, eksik bağlam kontrollerinden veya iç içe geçmiş ya da ertelenmiş yürütme akışlarında oluşan izin uyumsuzluklarından kaynaklanırlar.

COBOL-CICS Kaynak Akışının Güven Sınırları Açısından Analizi

Tipik bir COBOL-CICS işlemi tek bir monolitik bloktan oluşmaz. Genellikle birbirine bağlı birden fazla programı kapsar. EXEC CICS LINK, XCTLya da RETURN, aralarında veri paylaşmak için commarea bloklarını kullanır. Birçok program, aldıkları commarea içeriğini bağımsız olarak doğrulamaz; bunun yerine, güvenilir bir arayanın doğrulamayı zaten gerçekleştirdiği varsayımına güvenir. Bu varsayım, ayrıcalık kaymasının ve yetkisiz erişimin en sık karşılaşılan kaynaklarından biridir.

Statik analiz, veri girişinin başlangıç ​​noktalarını belirlemeli ve bu çağrılar boyunca yayılımını izlemelidir. Örneğin:

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

Daha sonra ACCTUPD, aşağıdakiler görünebilir:

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

Bu, örtük bir güven sınırı yaratır. WS-USERID Akışın daha erken bir aşamasında üzerine yazılmış veya sahtecilik yapılmışsa, ACCTUPD körü körüne yönetici rutinlerini yürütürdü. Statik analizin korelasyonlu olması gerekir COMM-USERID'nin kökenini belirleyin ve hassas karar alma süreçlerinde kullanan tüm alt kodları yeniden doğrulamadan işaretleyin.

Statik taramalarla tespit edilebilen tipik güven sınırı ihlalleri şunlardır:

• Yerel kimlik doğrulaması olmadan ortak alanlara dayalı karar dalları
• Terminal veya APPLID değerlerine bağlı mantığın yürütülmesi
• Kullanımı EIBTRMID, EIBTASKNya da EIBRESP köken kontrolü olmadan kontrol mantığında
• Sahte konuşma zincirine yeniden girildiğinde kullanıcı oturumu yeniden doğrulamasının olmaması

Sabit Kodlanmış Kimlik Bilgilerini ve Yetki Yükseltme Mantığını Algılama

Statik incelemeler, doğrudan COBOL ifadelerine yerleştirilmiş sabit kodlu kullanıcı kimliklerini, özel kodları veya APPLID'leri sıklıkla ortaya çıkarır. Bunlar dahili testler veya operasyonel geçici çözümler için eklenmiş olsa da, genellikle üretim ortamlarında kalır ve ciddi riskler oluşturur.

İşte sıklıkla işaretlenen gerçek dünya örnek kalıpları:

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

or

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

Bunlar, yüksek erişime yönelik kontrolsüz yollar oluşturur. Bir saldırgan bir terminale erişim sağlarsa veya sabit kodlanmış bir kullanıcı kimliği keşfederse, uygulamanın geri kalanı tam kimlik doğrulaması yapılmış gibi davranabilir.

Daha incelikli bir örnek:

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

Bu mantık ayıklanmaz veya korunmazsa, hazırlanmış bir girdi, genel kullanıcılara yönelik olmayan günlükleri, dosya işaretçilerini veya bellek tanılamalarını açığa çıkaran işlevleri etkinleştirebilir.

Bu tür kusurları tespit etmek için statik kurallar oluştururken şunlara odaklanın:

• IF or EVALUATE kullanıcılara veya terminallere bağlı sabit kodlanmış değişmez değerler kullanan ifadeler
• Sabit kodlanmış kimlik bilgilerinin erişim bayraklarına doğrudan eşlenmesi
• Bayraklar gibi BYPASS, OVERRIDEya da DEBUG koşullu mantığı tetikleyen
• Kod bölümleri yalnızca kullanıcı adı veya terminal kimliği üzerindeki yüzeysel kontrollerle korunmaktadır

Çoğu durumda, bu kontroller gayri resmi olarak eklenmiş ve hiçbir zaman incelenmemiştir. Statik taramalar, bunları manuel inceleme için işaretlemeli veya tekrarlayan kötüye kullanımlarda desen tabanlı uyarılar uygulamalıdır.

Statik analiz merceğini bu sınır koşullarını ve sabit kodlu geri dönüşleri yakalayacak şekilde genişleterek, denetçiler ve güvenlik mühendisleri, sistemin geri kalanı güvenli bir şekilde çalışıyor gibi görünse bile, CICS uygulamalarının güven zincirini nerede kırabileceği konusunda daha iyi bir görünürlük elde edebilirler.

Güvenlik Riskini Gösteren Kod Yapısı Modelleri

Tek tek CICS komutları tek başlarına güvenli görünse de, program mantığının çevreleyen yapısı genellikle bir işlemin gerçekten korunup korunmadığını belirler. Statik analiz, programların nasıl etkileşim kurduğunu, izinlerin nasıl çıkarıldığını ve örtük güvenin kontrol akışına nasıl yerleştirildiğini anlamak için satır satır taramanın ötesine geçmelidir.

Eski sistemler bu kalıplara özellikle yatkındır. Zamanla, geliştirme ekipleri, endişelerin ayrımını bulanıklaştıran geçici mantık, ayrıcalık kısayolları ve çok amaçlı işlemler sunar. Bu yapısal karşı kalıpları belirlemek, işlem güvenliğini güçlendirmek için çok önemlidir.

Yükseltilmiş İzinlerle İşlem-Program Eşlemesi

Her CICS işlem kimliği genellikle belirli bir programa veya dağıtım rutinine eşlenir. Ancak birçok sistem, işlem kodlarını farklı modüller arasında yeniden kullanır veya kullanıcı girdisine göre birden fazla hassas işlevi gerçekleştirebilen geniş program işleyicileri atar.

Genel amaçlı bir işleyici, yeterli filtreleme olmadan yüksek ayrıcalıklı bir işleme bağlandığında bu durum tehlikeli hale gelir. Statik analiz, hangi işlem kimliklerinin hangi programlara eşlendiğini izlemeli ve her programın bu işlem bağlamında hangi mantığı çalıştırdığını belirlemelidir.

Örnek:

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

Yukarıdakiler aşağıdaki gibi bir işleme eşlenirse FINTRN01ve bu işleme yükseltilmiş sistem ayrıcalıkları atanırsa, herhangi bir kötüye kullanım COMM-AREA-FUNCTION Kullanıcının rol kısıtlamalarını aşmasına ve silme veya güncelleme mantığını başlatmasına izin verebilir.

Risk göstergeleri şunlardır:

• Kullanıcı tarafından sağlanan bayraklara dayalı olarak birden fazla ayrıcalıklı eylem gerçekleştiren tek programlar
• Sabit kodlu işlem-işlev kısıtlamalarının olmaması
• Ortamlar veya iş birimleri arasında paylaşılan işlem kodları
• Bir dağıtım modülü içindeki belirli şubelere bağlı erişim kontrollerinin olmaması

Statik taramalar, commarea bayraklarının akışı nerede kontrol ettiğini ve bu akışların herhangi bir kimlik doğrulama, rol doğrulama veya kaynak düzeyindeki kısıtlamalarla korunup korunmadığını belirlemelidir.

Komuta Düzeyi ve Makro Düzey Çağrı Yolu Zayıflıkları

Bir diğer risk kaynağı da komut düzeyindeki ve makro düzeydeki programlar arasındaki tutarsızlıktır. Zamanla gelişen sistemler genellikle her iki stilin bir karışımını içerir. Komut düzeyindeki kod, yapılandırılmış sözdizimi ve daha iyi okunabilirlikten faydalanırken, makro düzeydeki kod daha düşük düzeyde erişim ve daha az güvenlik önlemi sunma eğilimindedir.

Her iki tür birlikte kullanıldığında, özellikle makro düzeydeki programlar ara güvenlik uygulaması olmadan dinamik olarak birbirine bağlıysa, gizli çağrı yolu güvenlik açıklarına yol açabilirler.

Örnek:

• Komut düzeyindeki bir program, paylaşılan belleği doğrudan okuyan veya değiştiren bir makro düzeyindeki modüle BAĞLANIR.
• Makro düzey modülü, çağıran programın verileri zaten doğruladığını varsayar.
• Giriş ile uygulama arasında herhangi bir ara kontrol yapılmaz.

Akışın basitleştirilmiş bir görünümü:

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

Burada, makro düzey modülün depolama işaretçileri üzerinde doğrudan çalışacağına güveniliyor. Çağrı yapan program doğrulamayı başaramazsa DATA-BLOCK, bir saldırgan bellek bölgelerini manipüle edebilir veya yetkisiz veri kümelerine başvurabilir.

Statik analizde özellikle şunlara dikkat edilmelidir:

• Yapılandırılmış programlardan eski modüllere LINK veya XCTL çağrıları
• Komut düzeyi ve makro düzeyi kod arasında parametre geçişi
• Sınır denetimi olmadan depolama işaretçilerinin veya sistem dosya tanımlayıcılarının kullanımı
• Giriş doğrulamasının başka bir yerde gerçekleştiği varsayılan yeniden kullanılan modüller

Bunlar testlerde nadiren yakalanır, çünkü istismar koşulları genellikle terminal bağlamı, görev parametreleri ve yürütme akışı arasında tam bir uyum gerektirir. Ancak statik taramalar, bu kusurlara olanak tanıyan yapısal kurulumu tespit edebilir.

Analistler, yalnızca hatalı kod satırlarını değil, yapısal riskleri belirleyerek CICS sistemlerinin genel güvenlik duruşunu daha iyi değerlendirebilir ve etki potansiyeline göre iyileştirme önceliklerini belirleyebilir.

CICS'ye Özgü API Kötüye Kullanımının Statik Tespiti

CICS, sistem düzeyindeki kaynaklarla etkileşim kuran çok çeşitli EXEC komutları ve makroları sunar. Bunlar arasında terminal tanımlayıcıları, görev numaraları, oturum belleği ve işlem yönlendirme mantığı bulunur. Bu özellikler esneklik sunarken, yeterli güvenlik önlemleri olmadan kullanıldığında güvenlik açıkları da oluşturabilir. Bu arayüzlerin kötüye kullanımı, istemeden ayrıcalık yükselmesine, denetimlerin atlanmasına veya yetkisiz sistem alanlarına erişime neden olabilir.

Statik analiz, geliştiricilerin ve denetçilerin, bu API'lerin nasıl çağrıldığını, hangi parametreleri kullandığını ve çağrı bağlamının yeterli doğrulama sağlayıp sağlamadığını inceleyerek bu tür riskleri belirlemelerine olanak tanır. Doğru uygulama, yürütme bağlamının, erişim kalıplarının ve işlemler genelindeki veri akışı sınırlarının dikkatli bir şekilde incelenmesini gerektirir.

EXEC CICS ASSIGN ve ADDRESS'in Güvensiz Kullanımını İzleme

MKS ASSIGN hem de ADDRESS Komutlar, CICS'nin dahili yapılarına doğrudan erişim sağlar. Bu, terminal kimlikleri, uygulama tanımlayıcıları ve göreve özgü bellek konumları gibi kritik meta verileri içerir. Bu değerler, günlük kaydı veya oturum takibi için sıklıkla kullanılsa da, kontrol mantığı güvenlik kararları için bunlara bağlı olduğunda tehlikeli hale gelirler.

Bu örneği ele alalım:

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

Burada erişim kontrolü doğrudan terminal kimliğine bağlıdır. Değeri bilen veya terminal ayarlarını taklit etme yeteneğine sahip bir kullanıcı, güvenlik mekanizmalarını atlatmak için bu mantığı kullanabilir.

Veya şunu içeren bir varyasyonu düşünün: ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

Tek başına bu zararsız görünüyor. Ancak, eğer EIBTASKN Daha sonra kimlik doğrulama veya işlem yetkilendirmesi için kullanıldığında, öngörülebilirlik ve yetkisiz oturum taklitleri riski ortaya çıkar.

Güvenli olmayan ASSIGN ve ADDRESS kullanımının yaygın göstergeleri şunlardır:

• Kontrol dalları yalnızca terminal kimliğine, APPLID'e veya görev numarasına göre
• Erişim doğrulama veya atlama bayrakları için atanan değerlerin doğrudan kullanımı
• ADDRESS komutlarından sonra yapısal doğrulama yapılmayan işaretçi referansları
• IF koşullarında sistem tarafından atanan tanımlayıcılarla karşılaştırıldığında sabit kodlanmış değerler

Statik tarama araçları, özellikle atanan veriler program yönlendirmesini veya ayrıcalık mantığını etkilediğinde bu koşulları işaretleyecek şekilde yapılandırılmalıdır.

Alternatif Yürütme Yolları Aracılığıyla İşlem Akışında Kurcalama

Birçok CICS uygulamasında, hata toleransını artırmak için yedek veya alternatif işlem yönlendirmesi kullanılır. Ne yazık ki, bu alternatif yollarda uygun erişim doğrulaması olmayabilir veya beklenmedik koşullar altında erişilebilir. Bu durum, saldırganların normal işlem akışının dışından hassas mantığı tetiklemelerine olanak tanır.

Şu durumu düşünün:

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

Bu kod, virgül geçilmemişse yürütmeyi yeniden yönlendirir. Ancak RETRYTX yalnızca güvenilir dizilerde kullanılmak üzere tasarlanmış olabilir. Kendi doğrulamasını zorunlu kılmazsa, bir kullanıcı yalnızca sıfır uzunlukta bir işlemi tetikleyerek hassas işlevlere erişebilir.

Sessiz tırmanışa bir başka örnek:

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

If ALTID daha fazla ayrıcalığa veya daha geniş işlevselliğe sahip bir işleme eşlenir ve rol kontrollerinden yoksundur, bu geri dönüş istenmeyen erişime neden olur.

Buradaki riskler genellikle şu şekilde ortaya çıkar:

• Hata durumlarına göre programları değiştirmek için START, XCTL veya LINK'i kullanın
• Birden fazla işlem kodunda yeniden kullanılan program kimlikleri
• Doğrulamayı alt akış modüllerine erteleyen RETURN mantığı
• Bütünlük kontrolleri olmadan akışı dikte eden Commarea değerleri

Statik analiz, birden fazla giriş yoluna sahip programları belirlemek ve eksik doğrulama sonrasında kontrolü ele geçirenleri vurgulamak için eksiksiz bir işlem grafiği oluşturmalıdır. İşlevler izole görünse bile, gizli akışlar saldırganların beklenen kullanım dışında ayrıcalıklı işlemleri tetiklemesine olanak tanıyabilir.

Karmaşık Güvenlik Mantığı Karartmasının Ele Alınması

Eski CICS uygulamalarını güvence altına almanın en zor yanlarından biri, karmaşık veya derinlemesine yerleşmiş güvenlik mantığını çözmektir. Birçok CICS programı onlarca yıl içinde evrimleşmiş, farklı ekiplerden geçmiş ve birden fazla erişim işleme katmanı içermiştir. Sonuç olarak, önemli güvenlik kararları genellikle erişilemeyen yollarda gömülür, modüller arasında çoğaltılır veya parçalanmış rutinlere bölünür. Statik analiz, bu kalıpları yeniden yapılandırabilmeli ve varsayımların veya gözden kaçırmaların nerede risk yarattığını ortaya koyabilmelidir.

Birden Fazla Programda Bölünmüş Yetkilendirme Yollarını Belirleme

CICS geliştiricileri, birden fazla kullanıcı etkileşiminde durumu korumak için genellikle sözde konuşma programlaması uygular. Bunu yaparken, kimlik doğrulamayı yetkilendirmeden istemeden ayırabilirler. Bir program kimlik bilgilerini doğrular, diğeri oturum işaretlerini ayarlar ve üçüncüsü erişim kontrolleri gerçekleştirir. Bu zincirin herhangi bir parçasının bağlantısı kesilirse veya başka bir bağlamda yeniden kullanılırsa, bir güvenlik açığı oluşur.

Örnek:

1 Programı:

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

2 Programı:

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

Bu, amaçlandığı şekilde kullanıldığında güvenli görünüyor. Ancak başka bir işlem, Program 2'den geçmeden doğrudan Program 1'yi başlatırsa, değişken SESSION-AUTH başlatılmamış veya sahte olabilir. İkinci program, kimlik bilgilerini tekrar kontrol etmeden, yalnızca bir değişkene dayanarak oturumun geçerli olduğuna güvenir.

Statik analiz, özellikle aşağıdakiler olmak üzere program geçişleri boyunca değişken atamalarını izlemelidir:

• Bir program, başka bir programın erişim kararları için okuması gereken bir bayrağı ayarladığında
• Yetkilendirme mantığı kimlik doğrulama mantığının dışında mevcut olduğunda
• Programlar doğrudan başlatılabildiğinde ve normal giriş doğrulamasını atlatabildiğinde

Bu kalıplar eski tasarımlarda oldukça yaygındır ve manuel incelemelerde sıklıkla gözden kaçar.

Dahili Hata Ayıklama veya Test Modları aracılığıyla Akış Sapmalarını Kontrol Edin

Geliştiriciler bazen test sırasında yardımcı olması için gizli işaretler veya hata ayıklama modları ekler. Bu özellikler dağıtımdan önce kaldırılmazsa veya üretim terminallerinden erişilebilirse, uygulamanın hassas bölümlerine bir arka kapı sağlayabilirler.

Örnek:

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

Veya daha ince bir şekilde:

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

İkinci durumda, mesai saatleri dışında gerçekleşen bir rutin, toplu işler veya acil müdahale için tasarlanmış bazı normal güvenlik kontrollerini atlatabilir. Ancak etkileşimli bir oturumdan tetiklenebiliyorsa, zamanlamaya dayalı bir saldırı vektörü açar.

Karmaşık veya riskli mantık taraması yaparken statik analiz şu öncelikleri göz önünde bulundurmalıdır:

• Güvenlik mantığını kontrol eden olağandışı koşullar (saat, terminal kimliği, bölge kodu)
• DEBUG, DEV, OVERRIDE, TEST veya BACKDOOR gibi bayraklar
• Belirli çalışma zamanı koşulları altında atlanan erişim kontrolleri
• Doğrulama dalları arasında geçiş yapan GOTO veya PERFORM yolları

Amaç, doğrudan ve görünür bir yetkilendirme kontrolü olmadan yürütmenin ayrıcalıklı koda geçmesine izin veren her şeyi ortaya çıkarmaktır.

Tutarlı Olmayan Erişim Kontrolüne Sahip Yeniden Kullanılan Rutinler

Birçok büyük CICS uygulamasında, geliştiriciler veri erişimi veya iş mantığı için ortak rutinleri yeniden kullanır. Bu rutinler hem halka açık işlemler hem de dahili yönetim yardımcı programları tarafından çağrılabilir. Paylaşımlı mantık, çağıranın kullanıcının rolünü zaten doğruladığını varsayarsa ve bu varsayım her zaman geçerli olmazsa, dolaylı bir güvenlik açığı haline gelir.

Klasik bir yapı şu şekilde görünür:

PERFORM UPDATE-ACCT-INFO

...

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

Bu, yalnızca her arayan kişi güvenliyse güvenlidir UPDATE-ACCT-INFO doğru şekilde ayarlar ROLE değişken. Uygulamanın başka bir kısmı bu rutini şu şekilde çağırırsa ROLE başlatılmamışsa veya çağıran kişi zayıf bir kontrole dayanarak bunu yanlış bir şekilde ayarlarsa yetkisiz erişim meydana gelebilir.

Statik taramalar şunları işaretlemelidir:

• Güvenlik açısından hassas eylemleri gerçekleştiren paylaşılan rutinler
• Paylaşılan rutinler içinde yerel doğrulamanın olmaması
• Harici olarak tanımlanan erişim kararları için kullanılan değişkenler
• Uygulama noktasından uzakta gerçekleşen rol atamaları

Bu tür bir karartma, kasıtlı gizlemeden değil, uzun vadeli mimari sapmalardan kaynaklanır. Bileşenler modüller arasında yeniden kullanıldıkça, orijinal erişim varsayımları bozulur. Bu riskleri yalnızca derin kod izleme ve bağlam korelasyonu ortaya çıkarabilir.

kullanma SMART TS XL CICS İşlem Güvenlik Açıklarını Algılamak ve Ortadan Kaldırmak

Eski ana bilgisayar sistemlerinde güvenlik analizini yönetmek doğası gereği karmaşıktır. CICS ortamları genellikle merkezi bir yapıdan yoksundur, modern dokümantasyonu oldukça azdır ve onlarca yıllık prosedürel evrim süreci geçirmiştir. SMART TS XL COBOL, PL/I, JCL ve CICS'ye özgü desenler için özel olarak tasarlanmış bir statik analiz motoru sunarak bu sorunları ele alır. Genel amaçlı araçların aksine, ana bilgisayar ekosistemlerine özgü mimariyi ve kuralları anlar.

CICS için Çok Seviyeli Akış Yeniden Yapılandırması

SMART TS XL Tüm uygulama portföylerini tarar ve programlar arası bir akış haritası oluşturur. Bu şunları içerir:

• İşlem-program eşlemeleri
• LINK, XCTL ve RETURN kullanarak programdan programa geçişler
• Değişken ve ortak yayılım
• Rol tabanlı kontrol mantığı ve giriş koşulu izleme

Tam yürütme zincirlerini yeniden yapılandırarak, güvenilir bir bağlam varsayan bir programın, potansiyel olarak doğrulanmamış olanlar da dahil olmak üzere, birden fazla noktadan gerçekten ulaşılabilir olup olmadığını tespit edebilir.

Örnek Kullanım Durumu:

Dahili bir denetim, işlemde bir güvenlik açığı olduğunu ortaya çıkardı TX94 Başlangıçta yalnızca yönetici kullanımına yönelik tasarlanmış bir programı tetikledi. SMART TS XL Programın çağrı grafiğini izledi, kontrol bayrağının işaretlenmemiş bir virgül alanı üzerinden geçirildiğini keşfetti ve aynı program girişine erişimi olan beş işlem daha tespit etti. Manuel izleme bunu gözden kaçırdı.

Gizli Kontrol Bayraklarını ve Gizlenmiş Erişim Yollarını Algılama

Birçok eski program, gömülü geçersiz kılma koşulları veya acil durum rutinleri içerir. Derin iç içe yerleştirme, alışılmadık değişken adlandırma veya yedek mantık içine yerleştirme nedeniyle bunları manuel olarak bulmak genellikle zordur. SMART TS XL kural tabanlı ve desen eşleştirme taramalarını kullanarak şunları çıkarır:

• Nadiren kullanılan bayrak değerleri tarafından kontrol edilen koşullu dallar
• Terminal kimliğine, günün saatine veya görev meta verilerine göre tetiklenen mantık
• Ortak alan bayrakları, sabit kodlu kullanıcı kimlikleri veya makro düzeydeki rutinleri kullanarak dalları atlayın

Potansiyel olarak ayrıcalıklı karar noktalarının tüm örneklerini ortaya çıkarır ve bunları ulaşılabilirlik, işlem görünürlüğü ve ayrıcalık yükseltme potansiyeline göre sıralar.

CICS Yapıları için Otomatik Güvenlik Açığı Kuralları

Yüzey seviyesindeki tarayıcıların aksine, SMART TS XL COBOL-CICS programlarına özel olarak tasarlanmış yerleşik kurallar içerir. Bunlar, aşağıdakilerle ilgili güvenlik açıklarını belirler:

• Güvenli olmayan EXEC CICS ASSIGN ve ADDRESS kullanımı
• PERFORMED rutinlerinde tutarsız erişim mantığı
• WRITE, DELETE veya START komutlarından önce doğrulama eksik
• Zayıf devlet yönetimine sahip eski sözde konuşma akışları

Bu kurallar, ortama, işleve veya denetim kriterlerine göre özelleştirilebilir. Özellikle eski geliştirme ekiplerinin geride bıraktığı yanlış varsayımları tespit etmede faydalıdırlar.

Etki İzleme ile Hızlandırılmış İyileştirme

Bir güvenlik açığı işaretlendiğinde, düzeltme işlemi şu şekilde hızlandırılabilir: SMART TS XL'nin izleme yeteneği. Herhangi bir mantık dalı veya program fonksiyonu için şunları gösterebilir:

• Buna yol açan tüm işlemler
• Çağırdığı tüm modüller
• Tüm değişkenler buna bağlıdır
• Herhangi bir erişim mantığını atlatıyor

Bu izleme haritası, geliştiricilerin ve denetçilerin bir kusurun izole mi yoksa sistematik olarak mı açığa çıktığını anında anlamalarına yardımcı olur. Ayrıca, bağımlılıkları manuel olarak eşlemek için harcanan süreyi azaltır ve yama sırasında yeni hatalar ortaya çıkma riskini azaltır.

Sonuç ve Sonraki Güvenlik İnceleme Adımları

Eski CICS uygulamaları kritik iş mantığı barındırır, ancak yaşları ve karmaşıklıkları, standart yöntemlerin genellikle gözden kaçırdığı güvenlik kör noktaları oluşturur. Statik analiz, özellikle yalnızca sözdizimi veya kod parçacıklarını değil, aynı zamanda işlemler genelindeki daha geniş kontrol akışını ve erişim varsayımlarını da hedeflediğinde, gizli risklerin istismar edilmeden önce ortaya çıkarılması için güvenilir bir yol sağlar.

Bu yazımızda CICS sistemlerine özgü kusur türlerini inceledik:

• Yetkilendirme mantığı gevşek bir şekilde bağlı programlara dağılmış durumda
• Doğrulama yapılmadan ASSIGN ve ADDRESS gibi savunmasız komut kalıpları
• Normal kontrolleri atlayan geri dönüş işlemleri ve hata ayıklama yolları
• Arayanlardan güvenilir girdi alındığını varsayan yeniden kullanılan rutinler

Büyük CICS portföyleri işleten kuruluşlar için, güvenliğe parça parça bir yaklaşım artık geçerli değil. Modern tehditler, yüzlerce modülde gizlenmiş tek bir gözetimi istismar edebilir. Derin bağlam farkındalığıyla uygulanan statik analiz, bu sorunları daha yayına girmeden veya denetime tabi tutulmadan önce ortaya çıkarabilir.

Bir sonraki adım olarak dikkate alınması gereken temel eylemler şunlardır:

• Tüm XCTL ve LINK yollarını içeren tam bir işlem-program haritası oluşturun
• Ayrıcalıklı işlemler gerçekleştiren herhangi bir paylaşılan iş mantığını tanımlayın ve yeniden yapılandırın
• Ortak alan bayraklarından veya terminal tabanlı kararlardan etkilenen tüm şubeleri denetleyin
• Her işlemin giriş noktasında güvenlik doğrulaması oluşturun
• İstenmeyen maruziyet için yedek mantığını ve acil durum yollarını gözden geçirin

Bu süreci hızlandırmak ve manuel çabayı azaltmak isteyen ekipler için, SMART TS XL CICS mimarisine özel statik analizler sağlayarak, tam akış izlenebilirliğiyle güvenli yeniden düzenlemeye olanak tanır.

Ana bilgisayar ortamlarını korumak yalnızca dikkatli olmayı değil, aynı zamanda görünürlüğü de gerektirir. Statik analiz ise her ikisini de sunan az sayıdaki teknikten biridir.