CICS-tehingute turvalisuse haavatavuste tuvastamise staatiline analüüs

CICS-süsteemid toetavad maailma kõige tundlikumaid ja suuremahulisemaid tehingute töötlemise keskkondi. Pangandusest ja kindlustusest kuni logistika ja kaitseni – need platvormid käsitlevad töökoormust, mis ei võimalda turvakontrolli. Kuigi tööajale pööratakse sageli kõige rohkem tähelepanu, tutvustab CICS-rakenduste struktuur järgmist: varjatud riskid mida on tavapäraste ülevaadete käigus lihtne kahe silma vahele jätta.

Paljud neist riskidest pärinevad pärandkoodist. Pesastatud COBOL-moodulid, tehinguprogrammi seosed, dünaamilised programmikutsed ja korduvkasutatud koma-alad võivad tekitada turvaaukude mis pole pinnalt nähtavad. Levinud näideteks on valideerimata terminali ligipääs, XCTL- või LINK-käskude väärkasutamine ja vale tehingute marsruutimise kaudu antud kõrgendatud õigused. Need vead võivad tootmises esineda aastaid ilma hoiatusi käivitamata.

Staatiline analüüs pakub struktureeritud viisi nende probleemide tuvastamiseks enne nende ärakasutamist. Kuid erinevalt veebi- või API-rakendustest nõuab CICS-i töökoormuste skannimine palju põhjalikumat kontrolli. Analüütikud peavad jälgima juhtimisvoogu mitmel programmi tasandil, mõistma, kuidas andmed jagatud mälus liiguvad, ja tuvastama mustreid, mis on omased suurarvuti tehingute käitumisele.

See artikkel keskendub sellele, kuidas rakendada staatilist analüüsi CICS-keskkondades turvanõrkuste avastamiseks ja leevendamiseks. See kirjeldab kõrge riskiga struktuure, mida otsida, näitab, kuidas tõlgendada tehinguloogikat COBOL-koodis, ja annab juhiseid inseneridele, kes peavad suuri pärandsüsteeme täpselt ja põhjalikult üle vaatama. Eesmärk on aidata meeskondadel oma tehingukihte turvata ilma oletuste ja häireteta.

CICS-i tehingurünnakute pindade mõistmine

CICS-tehingud ei ole pelgalt programmilised tööüksused. Need on sügavalt juurdunud juurdepääsu kontrolli, kasutaja identiteedi, ressursside autoriseerimise ja seansi terviklikkuse süsteemidesse. Paljud suurarvutisüsteemid tuginevad aastakümneid vanadele disainimustritele, kus turvalisuse jõustamine on pigem kaudne kui otsene. See toob kaasa riske, mida testimise või isegi vastavusauditite käigus sageli tähelepanuta jäetakse.

Sellel tasemel staatiline analüüs algab kaardistamisega, kus kontroll edastatakse, kuidas sisendit töödeldakse ja millised teed on teatud teostuskontekstides kättesaadavad. Isegi süsteemid, mis on läbitungimistestid läbinud, võivad siiski sisaldada haavatavusi, mis on seotud valesti suunatud või liiga privilegeeritud tehinguvoogudega.

Varjatud haavatavused EXEC CICS-kõnedes

Levinud nõrkus on dünaamiline kasutamine EXEC CICS LINK, XCTLvõi RETURN ilma kutse päritolu või konteksti kontrollimata. Kui programmid on lõdvalt aheldatud ja programminimed antakse väljastpoolt või konstrueeritakse dünaamiliselt, võib pahatahtlik sisend suunata täitmise kõrgemate õigustega moodulite poole.

Praktikas võib see välja näha järgmine:

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

If PROG-NAME on loodud kasutaja sisestatud väärtusest või kaardistatud tabelist ilma range valideerimiseta, võivad volitamata kasutajad käivitada tundlikke programme, mis ei olnud mõeldud avalikustamiseks.

Staatiline analüüs peab tuvastama sellised teed, eriti kui:

• Programminimed moodustatakse liidetud või maskeeritud väärtustest
• Lubatud või eeldatavate sihtmärkide jaoks ei rakendata varukontrolli
• Vastuvõtvad programmid töötavad ilma volituste täiendava kontrollimiseta

SVC ja salvestuskontrolli eskalatsioonimustrid

Teatud SVC-põhised kõned või sisemised teenindusrutiinid, millele pääseb ligi makrotasandi käskude kaudu, võivad mälu manipuleerimise kaudu eskaleerumist lubada. ADDRESS, ASSIGNvõi otsejuurdepääs terminali andmeplokkidele võib kaitsemeetmetest mööda hiilida, kui ülesandetaseme turbekonteksti ei rakendata korralikult.

Tüüpiline punase lipu muster sisaldab:

• Terminali ID või ülesande numbri määramine toores sisendandmete põhjal
• Kasutamine EXEC CICS ADDRESS TCTUA või samaväärsed kõned, millele järgneb otsekirjutamine
• Seansi oleku põhjal juhtimise vahetamine ilma rolli kinnitamiseta

Terminalistruktuuride ja CICS-i sisemustega tuttavad ründajad saavad neid pääsupunkte ära kasutada õiguste tõstmiseks või soovimatute käskude sisestamiseks.

Nende haavatavuste tuvastamine nõuab lisaks CICS-käskude skannimisele ka andmeliini lahendamist mälu määramiste vahel, juhtparameetrite päritolu kontrollimist ja ohtlike või autentimata kontekstiväärtuste kasutamise märgistamist.

Staatilise analüüsi ulatus CICS-keskkonnas

CICS-keskkondade staatiline analüüs peab minema kaugemale lihtsast süntaksist või märksõnade tuvastamisest. Analüütikud peavad mõistma lisaks koodi struktuurile ka tehingumudelit, programmi seoseid, andmevooge ja privileegide piire. Täielik hindamine peaks kajastama, kuidas kasutajad, terminalid ja rakendused suhtlevad jagatud mälu ja aheldatud täitmisloogika kaudu.

Selline kontrollitase on keerukas, eriti kui töötatakse aastakümneid tagasi kirjutatud ja mitme meeskonna poolt aja jooksul hooldatud rakendustega. Programmid tuginevad sageli struktureerimata juhtimisvoogudele, dünaamilisele komamärkide kasutamisele ja taaskasutatud programmi ID-dele, mis kõik varjavad volituste algust ja lõppu.

COBOL-CICS-i allikavoo analüüsimine usalduspiiride osas

Kaasaegsetes rakenduskeskkondades määratletakse usalduspiirid tavaliselt kihtide kaupa, näiteks esiotsa kasutajaliidese ja API vahel. CICS-is on usalduspiirid sageli kaudsed ja peidetud programmi seostesse. Staatiline analüüs peab jälgima, millised programmid annavad juhtimise teistele üle, kust sisend süsteemi siseneb ja kas selle sisendi päritolu on usaldusväärne.

Näiteks võib ahel, mis algab sisselogimistoiminguga, juhtimise läbida viie või enama programmi kaudu. Kui üks neist programmidest aktsepteerib uut kasutaja sisendit (näiteks uuendatud komaga segmendi kaudu) seda uuesti valideerimata, siis usalduspiir puruneb. Staatiline analüüs peaks need üleminekupunktid ülevaatamiseks märgistama.

Kriitiliste aspektide hulka, mida uurida, kuuluvad:

• Sisenemispunktid, kus välised andmed sisenevad täitmisteele
• LINK-i või XCTL-i kõned, mis toimuvad helistaja tuvastamata
• Piirkonnad, kus teostus lülitub autentitud voolt autentimata voogu

Kõvakodeeritud volituste tuvastamine ja volituste eskaleerimise loogika

Kiire arenduse või hädaolukorras värskenduste ajal lisatakse mõnikord kõvakodeeritud turvatokeneid, kasutajatunnuseid või APPLID-sid. Need väärtused võivad tühistada standardsed juurdepääsukontrollid või lubada varujuurdepääsu, kui tegelik autentimine ebaõnnestub.

Näiteks COBOL-segment, näiteks:

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

ei pruugi pealtnäha ohtlik tunduda, aga kui USER-ID saab mõjutada väljastpoolt või taaskasutada teistes programmides, tekitab see püsiva riski.

Staatilise analüüsi mootorid peaksid otsima:

• Turvalisuse seisukohast tundlikud väärtused IF-lausetes või -omistustes
• Otse, ilma kinnituseta määratud volituslipud
• Üldiste APPLID-ide või kasutajanimede kasutamine, mis mööduvad juhtimisloogikast

Need mustrid on peened, kuid nende olemasolu viitab sageli suurematele disainiprobleemidele, kus turvaloogika on ärireeglitega põimunud. Nende isoleerimine staatilise analüüsi abil aitab meeskondadel koodi turvaliselt ja varjatud privileegiteedeta ümber kujundada.

Staatilise analüüsi ulatus CICS-keskkonnas

CICS-süsteemid erinevad oluliselt traditsioonilistest rakenduste pinudest. Kuigi tänapäevased teenused pakuvad API-sid ja sündmustepõhiseid vooge, täidavad CICS-rakendused sageli tihedalt seotud programmikettidena, mis tuginevad koma-alade, terminalisisendi ja jagatud mälu kaudu edastatud andmetele. See arhitektuur muudab staatilise analüüsi eriti keeruliseks. Analüütikud ei otsi mitte ainult teadaolevaid haavatavaid kõnesid, vaid peavad rekonstrueerima täitmisvoo mitme programmi vahel, millest mõned võivad hõlmata aastakümneid pärandi arendust.

Mõistlik staatiline ülevaade peab arvestama, kuidas andmed süsteemi sisenevad, kuidas kontroll ühelt moodulilt teisele edastatakse ja kus valideerimist oodatakse, kuid kus seda ei toimu. CICS-i turvarikkumised ei tulene alati ilmselgelt ohtlikest kõnedest. Sagedamini tulenevad need tähelepanuta jäetud eeldustest usalduse, puuduvate kontekstikontrollide või lubade mittevastavuse kohta, mis esinevad pesastatud või edasilükatud täitmisvoogudes.

COBOL-CICS-i allikavoo analüüsimine usalduspiiride osas

Tüüpiline COBOL-CICS tehing ei koosne ühest monoliitsest plokist. See hõlmab sageli mitut programmi, mis on omavahel ühendatud EXEC CICS LINK, XCTLvõi RETURN, kasutades andmete jagamiseks komablokke. Paljud programmid ei valideeri iseseisvalt vastuvõetud komablokkide sisu, vaid eeldavad, et usaldusväärne helistaja on valideerimise juba teinud. See eeldus on üks sagedasemaid õiguste nihkumise ja volitamata juurdepääsu allikaid.

Staatiline analüüs peab tuvastama andmete sisenemise alguspunktid ja jälgima nende levikut kõnede vahel. Näiteks:

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

Siis, sisse ACCTUPD, võib ilmuda järgmine:

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

See loob kaudse usalduspiiri. Kui WS-USERID on voos varem kunagi üle kirjutatud või võltsitud, ACCTUPD täidaks pimesi administraatorirutiine. Staatiline analüüs peab olema seotud COMM-USERIDpäritolu ja märgistab kogu allavoolu koodi, mis seda tundlike otsuste tegemiseks kasutab, ilma uuesti valideerimiseta.

Staatiliste skaneeringute abil tuvastatavad tüüpilised usalduspiiride rikkumised on järgmised:

• Otsustusharud, mis põhinevad komaväljadel ilma kohaliku autentimiseta
• Terminali või APPLID väärtustest sõltuvate loogika täitmine
• Kasutamine EIBTRMID, EIBTASKNvõi EIBRESP juhtimisloogikas ilma päritolu kontrollimiseta
• Kasutaja seansi uuesti valideerimise puudumine pseudovestlusahelasse uuesti sisenemisel

Kõvakodeeritud volituste tuvastamine ja volituste eskaleerimise loogika

Staatiliste ülevaadete käigus avastatakse sageli COBOL-lausetes otse manustatud kõvakodeeritud kasutajatunnuseid, erikoode või APPLID-e. Kuigi need võivad olla lisatud sisemise testimise või operatiivsete lahenduste jaoks, jäävad need sageli tootmiskeskkondadesse ja kujutavad endast tõsiseid riske.

Siin on reaalse maailma näidismustrid, mida sageli märgistatakse:

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

or

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

Need loovad kontrollimatud teed kõrgendatud juurdepääsule. Kui ründaja saab juurdepääsu terminalile või avastab kõvakodeeritud kasutajatunnuse, võib ülejäänud rakendus käituda nii, nagu oleks täielik autentimine toimunud.

Veel peenem näide:

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

Kui seda loogikat ei eemaldata ega kaitsta, võib loodud sisend aktiveerida funktsioone, mis paljastavad logisid, failiviiteid või mäludiagnostikat, mis pole mõeldud tavakasutajatele.

Selliste vigade tuvastamiseks staatiliste reeglite loomisel keskenduge järgmisele:

• IF or EVALUATE laused, mis kasutavad kasutajate või terminalidega seotud kõvakodeeritud literaalväärtusi
• Kõvakodeeritud volituste otsene kaardistamine juurdepääsulippudega
• Lipud, näiteks BYPASS, OVERRIDEvõi DEBUG mis käivitavad tingimusliku loogika
• Koodilõike kaitsevad vaid pealiskaudsed kontrollid kasutajanime või terminali ID osas

Paljudel juhtudel lisati need kontrollid mitteametlikult ja neid ei vaadatud kunagi üle. Staatilised skaneeringud peaksid need käsitsi kontrollimiseks märgistama või korduva väärkasutuse korral mustripõhise hoiatuse kehtestama.

Laiendades staatilise analüüsi objektiivi, et jäädvustada neid piirtingimusi ja kõvakodeeritud varuvariante, saavad audiitorid ja turvainsenerid parema ülevaate sellest, kus CICS-rakendused võivad usaldusahelat rikkuda – isegi kui ülejäänud süsteem näib toimivat turvaliselt.

Koodistruktuuri mustrid, mis viitavad turvariskile

Kuigi üksikud CICS-käsud võivad eraldiseisvalt tunduda turvalised, määrab programmi loogika ümbritsev struktuur sageli, kas tehing on tegelikult kaitstud. Staatiline analüüs peab minema rida-realt skaneerimisest kaugemale, et mõista, kuidas programmid omavahel suhtlevad, kuidas õigusi tuletatakse ja kus on juhtimisvoogu sisse põimitud kaudne usaldus.

Pärandsüsteemid on sellistele mustritele eriti vastuvõtlikud. Aja jooksul võtavad arendusmeeskonnad kasutusele ajutise loogika, privileegide otseteed ja mitmeotstarbelised tehingud, mis hägustavad murede eraldatust. Nende struktuuriliste antimustrite tuvastamine on tehingute turvalisuse tugevdamiseks hädavajalik.

Tehingute ja programmide vaheline kaardistamine kõrgendatud õigustega

Iga CICS-i tehingu ID on tavaliselt seotud kindla programmi või lähetusrutiiniga. Paljud süsteemid aga kasutavad tehingukoode erinevates moodulites uuesti või määravad laiaulatuslikke programmikäitlejaid, mis saavad kasutaja sisendi põhjal täita mitmeid tundlikke funktsioone.

See muutub ohtlikuks, kui üldotstarbeline käitleja on seotud kõrge privileegiga tehinguga ilma piisava filtreerimiseta. Staatiline analüüs peab jälgima, millised tehingu ID-d vastavad millistele programmidele, ja määrama kindlaks, millist loogikat iga programm selles tehingu kontekstis täidab.

Näide:

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

Kui ülaltoodu on seotud tehinguga, näiteks FINTRN01ja sellele tehingule on määratud kõrgendatud süsteemiõigused, siis igasugune väärkasutamine COMM-AREA-FUNCTION võib lubada kasutajal rollipiirangutest mööda hiilida ja käivitada kustutamis- või värskendamisloogika.

Riskinäitajate hulka kuuluvad:

• Üksikud programmid, mis täidavad kasutaja antud lippude põhjal mitut privilegeeritud toimingut
• Kõvakodeeritud tehingute ja funktsioonide vaheliste piirangute puudumine
• Jagatud tehingukoodid keskkondade või äriüksuste vahel
• Lähetusmooduli konkreetsete harudega seotud juurdepääsukontrollide puudumine

Staatilised skaneeringud peaksid tuvastama, kus komamärgised kontrollivad voogu ja kas neid vooge kaitsevad autentimise, rolli valideerimise või ressursitaseme piirangud.

Käsutaseme ja makrotaseme kõnetee nõrkused

Teine riskiallikas on vastuolu käsutaseme ja makrotaseme programmide vahel. Aja jooksul arenenud süsteemid sisaldavad sageli mõlema stiili segu. Kuigi käsutaseme koodil on struktureeritud süntaks ja parem loetavus, pakub makrotaseme kood tavaliselt madalama taseme juurdepääsu ja vähem turvameetmeid.

Mõlema tüübi koos kasutamisel võivad need tekitada peeneid kõnetee haavatavusi, eriti kui makrotasandi programmid on dünaamiliselt lingitud ilma vahepealse turvameetmeteta.

Näide:

• Käsktaseme programm lingib makrotaseme mooduliga, mis loeb või muudab jagatud mälu otse.
• Makrotaseme moodul eeldab, et kutsuval programmil on andmed juba valideeritud.
• Sisestamise ja täitmise vahel ei tehta mingeid vahekontrolle.

Lihtsustatud vaade voolust:

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

Siin usaldatakse makrotasandi moodulit otse salvestusvihjete abil töötama. Kui kutsuv programm ei suutnud valideerida DATA-BLOCK, saab ründaja manipuleerida mälupiirkondadega või viidata volitamata andmekogumitele.

Staatilises analüüsis tuleks erilist tähelepanu pöörata järgmisele:

• LINK- või XCTL-kõned struktureeritud programmidest pärandmoodulitesse
• Parameetrite edastamine käsu- ja makrotaseme koodi vahel
• Salvestusviidete või süsteemifailide identifikaatorite kasutamine ilma piiride kontrollimiseta
• Taaskasutatud moodulid, mille puhul eeldatakse, et sisendi valideerimine toimus mujal

Neid tabatakse testimisel harva, kuna ärakasutamise tingimused nõuavad sageli terminali konteksti, ülesande parameetrite ja täitmisvoo täpset vastavust. Kuid staatiliste skaneeringute abil saab tuvastada struktuurilise ülesehituse, mis neid vigu võimaldab.

Struktuuriliste riskide – mitte ainult vigaste koodiridade – tuvastamise abil saavad analüütikud paremini hinnata CICS-süsteemide üldist turvaseisundit ja seada tähtsuse järjekorda parandusmeetmeid potentsiaalse mõju põhjal.

CICS-spetsiifilise API kuritarvitamise staatiline tuvastamine

CICS pakub laia valikut EXEC-käske ja makrosid, mis suhtlevad süsteemitaseme ressurssidega. Nende hulka kuuluvad terminali identifikaatorid, ülesannete numbrid, seansi mälu ja tehingute marsruutimise loogika. Kuigi need funktsioonid pakuvad paindlikkust, võivad need piisavate kaitsemeetmeteta kasutamisel tekitada ka haavatavusi. Nende liideste väärkasutamine võib kaasa tuua tahtmatu õiguste tõstmise, juhtelementide möödahiilimise või juurdepääsu volitamata süsteemipiirkondadele.

Staatiline analüüs võimaldab arendajatel ja audiitoritel selliseid riske tuvastada, uurides, kuidas neid API-sid kutsutakse, milliseid parameetreid nad kasutavad ja kas kutsumiskontekst pakub piisavat valideerimist. Nõuetekohane rakendamine nõuab tehingute täitmiskonteksti, juurdepääsumustrite ja andmevoo piiride hoolikat kontrollimist.

EXEC CICS ASSIGN ja ADDRESS ebaturvalise kasutamise jälgimine

. ASSIGN ja ADDRESS Käsklused pakuvad otsest juurdepääsu CICS-i sisemistele struktuuridele. See hõlmab kriitilisi metaandmeid, nagu terminali ID-d, rakenduste identifikaatorid ja ülesandepõhised mälupesad. Kuigi neid väärtusi kasutatakse sageli logimiseks või seansi jälgimiseks, muutuvad need ohtlikuks, kui juhtimisloogika sõltub neist turvaotsuste tegemisel.

Võtke see näide:

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

Siin on ligipääsu kontroll otse seotud terminali ID-ga. Kasutaja, kes teab selle väärtust või oskab terminali sätteid võltsida, saab seda loogikat ära kasutada turvamehhanismide möödahiilimiseks.

Või kaaluge variatsiooni, mis hõlmab ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

Eraldi võttes tundub see kahjutu. Kui aga EIBTASKN Kui seda hiljem autentimiseks või tehingute autoriseerimiseks kasutatakse, tekitab see etteaimatavuse ja volitamata seansi jäljendamise riski.

Ebaturvalise ASSIGN ja ADDRESS kasutamise levinumad näitajad on järgmised:

• Harude juhtimine ainult terminali ID, APPLID või ülesande numbri põhjal
• Juurdepääsu valideerimiseks või möödaviigulippude jaoks määratud väärtuste otsene kasutamine
• Struktuurilise valideerimiseta kursori viited pärast ADDRESS käske
• Kõvakodeeritud väärtused võrreldes süsteemi poolt määratud identifikaatoritega IF-tingimustes

Staatilise skaneerimise tööriistad tuleks konfigureerida neid tingimusi märgistama, eriti kui määratud andmed mõjutavad programmi marsruutimist või privileegide loogikat.

Tehinguvoo manipuleerimine alternatiivsete täitmisradade kaudu

Paljudes CICS-rakendustes kasutatakse rikketaluvuse parandamiseks varu- või alternatiivset tehingute marsruutimist. Kahjuks ei pruugi need alternatiivsed teed korralikult ligipääsu valideerida või neile pääseb ligi ettenägematutes tingimustes. See loob ründajatele võimalusi tundliku loogika käivitamiseks väljaspool tavapärast tehinguvoogu.

Mõelge sellele juhtumile:

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

See kood suunab täitmise ümber, kui koma ei edastatud. Aga RETRYTX võib olla loodud kasutamiseks ainult usaldusväärsetes järjestustes. Kui see ei jõusta oma valideerimist, võib kasutaja tundlikke funktsioone kasutada lihtsalt nullpikkusega tehingu käivitamisega.

Teine näide hõlmab vaikset eskalatsiooni:

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

If ALTID seostub suuremate õigustega või laiema funktsionaalsusega tehinguga ning rollikontrollid puuduvad, toob see varuvõimalus kaasa tahtmatu juurdepääsu.

Tavaliselt tulenevad riskid siin järgmisest:

• START, XCTL või LINK kasutamine programmide vahetamiseks veaolekute põhjal
• Programmi ID-d, mida kasutatakse korduvalt mitme tehingukoodi puhul
• RETURN-loogika, mis lükkab valideerimise edasi allavoolu moodulitele
• Commarea väärtused, mis dikteerivad voolu ilma terviklikkuse kontrollideta

Staatiline analüüs peaks looma täieliku tehingugraafiku, et tuvastada programme, millel on mitu sisenemisteed, ja tõsta esile need, mis saavad kontrolli pärast mittetäielikku valideerimist. Isegi kui funktsioonid näivad olevat isoleeritud, võivad peidetud vood lubada ründajatel käivitada privilegeeritud toiminguid väljaspool eeldatavat kasutust.

Keerulise turvaloogika hägustamise käsitlemine

Üks keerulisemaid aspekte pärand-CICS-rakenduste turvamisel on hägustatud või sügavalt pesastatud turvaloogika lahtiharutamine. Paljud CICS-programmid arenesid aastakümnete jooksul, läbisid erinevaid meeskondi ja hõlmasid mitut juurdepääsu haldamise kihti. Seetõttu on olulised turvaotsused sageli maetud kättesaamatutesse radadesse, kopeeritud moodulite vahel või jagatud killustatud rutiinideks. Staatiline analüüs peab suutma neid mustreid rekonstrueerida ja paljastada, kus eeldused või möödalaskmised on riske tekitanud.

Jagatud autoriseerimisteede tuvastamine mitme programmi vahel

CICS-i arendajad rakendavad tavaliselt pseudovestlusprogrammeerimist, et säilitada olekut mitme kasutaja interaktsiooni ajal. Seda tehes võivad nad tahtmatult autentimise autoriseerimisest eraldada. Üks programm kontrollib volitusi, teine ​​määrab seansilipud ja kolmas teostab juurdepääsukontrolle. Kui selle ahela mõni osa lahtiühendatakse või taaskasutatakse teises kontekstis, loob see turvaaugu.

Näide:

Programm 1:

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

Programm 2:

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

See tundub turvalisena, kui seda kasutatakse ettenähtud viisil. Aga kui mõni teine tehing käivitab programmi 2 otse ilma programmi 1 läbimata, siis muutuja SESSION-AUTH võib olla initsialiseerimata või võltsitud. Teine programm loodab seansi kehtivusele ainuüksi muutuja põhjal, ilma volitusi uuesti kontrollimata.

Staatiline analüüs peab jälgima muutujate määramisi programmiüleminekute vahel, eriti järgmistel juhtudel:

• Kui üks programm seab lipu, mida teine programm juurdepääsuotsuste tegemiseks loeb
• Kui autoriseerimisloogika eksisteerib väljaspool autentimisloogikat
• Millal saab programme otse käivitada ja tavapärast sisenemisvalideerimist mööda hiilida

Need mustrid on vananenud disainides äärmiselt levinud ja käsitsi tehtud ülevaadetes sageli kahe silma vahele jäävad.

Voolu ümbersuunamiste juhtimine sisemise silumis- või testimisrežiimi kaudu

Arendajad lisavad testimise hõlbustamiseks mõnikord peidetud lippe või silumisrežiime. Kui neid funktsioone enne juurutamist ei eemaldata või kui need on tootmisterminalidest ligipääsetavad, võivad need pakkuda tagaukse rakenduse tundlikesse osadesse.

Näide:

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

Või peenemalt öeldes:

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

Teisel juhul võib tööajaväline rutiin mööda hiilida mõnest tavapärasest turvakontrollist, mis on mõeldud näiteks partiitöödeks või hädaolukordadele reageerimiseks. Kui seda saab aga interaktiivsest seansist käivitada, avab see ajastuspõhise rünnakuvektori.

Segase või riskantse loogika otsimisel peaks staatiline analüüs seadma prioriteediks:

• Turvaloogikat juhtivad ebatavalised tingimused (kellaaeg, terminali ID, piirkonnakood)
• Lipud nagu DEBUG, DEV, OVERRIDE, TEST või BACKDOOR
• Juurdepääsukontrollid, mis teatud käitusaja tingimustes vahele jäetakse
• GOTO või PERFORM teed, mis hüppavad valideerimisharude vahel

Eesmärk on tuua esile kõik, mis võimaldab käivitamist edastada privilegeeritud koodi ilma otsese, nähtava autoriseerimiskontrollita.

Taaskasutatud rutiinid ebajärjekindla juurdepääsukontrolliga

Paljudes suurtes CICS-rakendustes taaskasutavad arendajad andmetele juurdepääsuks või äriloogika jaoks tavalisi rutiine. Neid rutiine võivad käivitada nii avalikud tehingud kui ka sisemised administreerimisutiliidid. Kui jagatud loogika eeldab, et kutsuja on kasutaja rolli juba valideerinud ja see eeldus ei pea alati paika, muutub see kaudseks haavatavuseks.

Klassikaline struktuur näeb välja selline:

PERFORM UPDATE-ACCT-INFO

...

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

See on turvaline ainult siis, kui iga helistaja UPDATE-ACCT-INFO määrab õigesti ROLE muutuja. Kui rakenduse mõni muu osa kutsub seda rutiini välja ROLE initsialiseerimata või kui helistaja määrab selle nõrga kontrolli põhjal valesti, võib tekkida volitamata juurdepääs.

Staatilised skaneeringud peaksid märgistama:

• Jagatud rutiinid, mis täidavad turvalisuse seisukohast tundlikke toiminguid
• Kohaliku valideerimise puudumine jagatud rutiinides
• Juurdepääsuotsuste tegemiseks kasutatavad muutujad, mis on määratletud väliselt
• Rollide määramine, mis toimub jõustamiskohast kaugel

Selline hägustamise vorm ei tulene tahtlikust varjamisest, vaid pikaajalisest arhitektuurilisest nihkest. Kuna komponente kasutatakse moodulite vahel uuesti, siis algsed juurdepääsueelduste väärtused halvenevad. Ainult sügav koodi jälgimine ja konteksti korrelatsioon saavad neid riske paljastada.

Kasutamine SMART TS XL CICS-tehingute haavatavuste tuvastamiseks ja kõrvaldamiseks

Turvaanalüüsi käsitlemine pärandarvutisüsteemides on oma olemuselt keeruline. CICS-keskkondades puudub sageli tsentraliseeritud struktuur, neil on minimaalne kaasaegne dokumentatsioon ja need hõlmavad aastakümneid kestnud protseduurilist evolutsiooni. SMART TS XL lahendab need probleemid, pakkudes staatilise analüüsi mootorit, mis on spetsiaalselt loodud COBOL-, PL/I-, JCL- ja CICS-spetsiifiliste mustrite jaoks. Erinevalt üldotstarbelistest tööriistadest mõistab see suurarvutite ökosüsteemidele ainuomast arhitektuuri ja konventsioone.

Mitmetasandiline voolu rekonstrueerimine CICS-i jaoks

SMART TS XL skannib kogu rakenduste portfelli ja loob programmideülese vooskeemi. See hõlmab järgmist:

• Tehingute ja programmide vahelised vastendused
• Programmidevahelised üleminekud LINK, XCTL ja RETURN abil
• Muutuja ja komaarvuline paljundamine
• Rollipõhine juhtimisloogika ja sisenemistingimuste jälgimine

Täielike täitmisahelate rekonstrueerimise abil saab see tuvastada, millal usaldusväärset konteksti eeldav programm on tegelikult kättesaadav mitmest punktist, sealhulgas potentsiaalselt kontrollimata punktidest.

Kasutusjuhtumi näide:

Siseaudit avastas turvavea tehingute puhul TX94 käivitas programmi, mis oli algselt mõeldud ainult administraatori kasutamiseks. SMART TS XL jälgis programmi kõnegraafikut, avastas, et juhtlipp edastati kontrollimata komavälja kaudu ja tuvastas viis muud tehingut, millel oli juurdepääs samale programmikirjele. Manuaalne jälgimine seda ei teinud.

Varjatud juhtlippude ja hägustatud juurdepääsuteede tuvastamine

Paljud pärandprogrammid sisaldavad manustatud tühistamistingimusi või hädaolukorra rutiine. Neid on sageli raske käsitsi leida sügava pesastamise, ebatavaliste muutujate nimetamise või varuloogikasse paigutamise tõttu. SMART TS XL kasutab reeglipõhiseid ja mustrite sobitamise skaneeringuid järgmise eraldamiseks:

• Tingimuslikud harud, mida kontrollivad harva kasutatavad lipuväärtused
• Loogika käivitub terminali ID, kellaaja või ülesande metaandmete põhjal
• Harude möödahiilimine komamärkide, kõvakodeeritud kasutajatunnuste või makrotasandi rutiinide abil

See toob esile kõik potentsiaalselt privilegeeritud otsustuspunktide juhtumid ja järjestab need kättesaadavuse, tehingute riski ja privileegide eskaleerimise potentsiaali alusel.

CICS-konstruktsioonide automatiseeritud haavatavuse reeglid

Erinevalt pinnataseme skanneritest, SMART TS XL sisaldab COBOL-CICS programmidele kohandatud sisseehitatud reegleid. Need tuvastavad haavatavusi, mis on seotud järgmisega:

• Ebaturvaline EXEC CICS ASSIGN ja ADDRESS kasutamine
• Ebajärjekindel juurdepääsuloogika PERFORMED-rutiinis
• Puudub valideerimine enne WRITE, DELETE või START käske
• Vananenud pseudovestlusvood nõrga olekuhaldusega

Neid reegleid saab kohandada vastavalt keskkonnale, ärifunktsioonile või auditeerimiskriteeriumidele. Need on eriti kasulikud vanemate arendusmeeskondade jäetud valede eelduste tuvastamisel.

Kiirendatud parandusmeetmed koos mõjujälgimisega

Kui haavatavus on märgistatud, saab parandamist kiirendada järgmiselt: SMART TS XLjälgimisvõimalus. See saab kuvada mis tahes loogikaharu või programmifunktsiooni puhul järgmist:

• Kõik tehingud, mis selleni viivad
• Kõik moodulid, mida see kutsub
• Kõik muutujad, millest see sõltub
• Igasugune juurdepääsuloogika, millest see mööda läheb

See jälgimiskaart aitab arendajatel ja audiitoritel kohe aru saada, kas tegemist on isoleeritud või süsteemselt esineva veaga. See vähendab ka sõltuvuste käsitsi kaardistamisele kuluvat aega ja vähendab uute vigade tekkimise ohtu paranduste ajal.

Kokkuvõte ja järgmised turvaülevaatuse sammud

Vananenud CICS-rakendused sisaldavad olulist äriloogikat, kuid nende vanus ja keerukus loovad turvaauke, mida standardmeetodid sageli ei märka. Staatiline analüüs pakub usaldusväärset viisi varjatud riskide avastamiseks enne, kui neid saab ära kasutada, eriti kui see ei ole suunatud ainult süntaksile või koodijuppidele, vaid laiemale juhtimisvoole ja juurdepääsueeldustele tehingute lõikes.

Selles artiklis uurisime CICS-süsteemidele ainuomaseid vigu:

• Autoriseerimisloogika on hajutatud lõdvalt seotud programmide vahel
• Haavatavad käsklusmustrid nagu ASSIGN ja ADDRESS ilma valideerimiseta
• Varutehingud ja silumisteed, mis mööduvad tavapärastest kontrollidest
• Taaskasutatud rutiinid, mis eeldavad helistajate usaldusväärset sisendit

Suuri CICS-portfelle haldavate organisatsioonide jaoks ei ole killustatud lähenemine turvalisusele enam teostatav. Kaasaegsed ohud võivad ära kasutada ühteainsaid sadu mooduleid hõlmavat möödalaskmisi. Staatiline analüüs, kui seda rakendada koos sügava kontekstiteadlikkusega, suudab need probleemid enne nende avalikustamist või auditisse jõudmist esile tõsta.

Siin on peamised sammud, mida järgmiste sammudena kaaluda:

• Loo täielik tehingute ja programmide vaheline kaart, mis sisaldab kõiki XCTL- ja LINK-teid
• Tuvastage ja ümber faktoriseerige kõik jagatud äriloogikad, mis teostavad privilegeeritud toiminguid
• Auditeeri kõiki harusid, mida mõjutavad komamärgid või terminalipõhised otsused
• Turvalisuse valideerimine iga tehingu sisenemispunktis
• Vaadake üle tahtmatu kokkupuute korral varuloogika ja hädaolukorra lahendused

Meeskondadele, kes soovivad seda protsessi kiirendada ja käsitsi tööd vähendada, sobivad sellised tööriistad nagu SMART TS XL pakkuda CICS-arhitektuurile kohandatud staatilist analüüsi, võimaldades turvalist refaktoreerimist täieliku voo jälgitavusega.

Suurarvutite keskkondade kaitsmine nõuab lisaks valvsusele ka nähtavust. Ja staatiline analüüs on üks väheseid tehnikaid, mis pakub mõlemat.