A basic guide to COBOL security

see let's introduce our next speaker um i believe his name is andy dennis and he's going to be speaking on a basic guide to global cobalt security so if you're on the ctf right now and your you're struggling with that with those cobalt challenges you might want to check this out and learn some new stuff about an ancient language all right so without further ado andy thank you let's get started all right thanks i'm just going to pop these slides i think i can find them

oh oh okay roman any idea why the air why i can't share slides yeah you should be able to hover your video and click on the uh share screen option yeah it doesn't seem to be working are you running cobalt right now because that could be the problem

okay that's kind of odd does it give you the option

all right but yeah it's not it's not letting me share them i'm not sure if there's a any reason why that would be the browser are you on i'm on firefox let me uh let me try reconnecting quickly with um chrome and see if that makes a difference all right yeah chrome seems to work better the technical difficulties here

there we go right can you all hear me okay you good tom

yep i can hear you okay great you can see the slides okay yep all right let's get started then so perfect so the talk today is on cobol security it's also a capture the flag in its own right so keep your eyes peeled um there is a mechanism in the ctf platform to enter secrets you find in things outside of the obvious challenges that are in the ctf platform and then finally there's also going to be some hints in here for the cobol challengers which you can find on the ctf platform so i'll just do a little introduction to myself so my name is andy dennis i'm the director of security at motors create they're based in uh rest in virginia and

we do consultancy right across full stack architecture design cloud migrations and then going and also reviewing people's cloud infrastructure for security issues and providing lists of ways of remediating it using better engineering practices and devops practices um i'm an organizer a b-side ct uh and actually studied cobol at school way back in the 90s and then promptly forgot it because i had absolutely no reason to use it after that we had to write a vhs rental system if you don't know what vhs is uh go look it up it involves tapes um modus create uh sponsored the ctf challenge um and they're also my employer so i just want to give a shameless plug so moving on then um we'll start off

with just doing a little background on cobol and then we'll start to go into um some of the security issues that you may face so what's cobol cobalt stands for common business orientated language it's an old language it was developed in 1959 it was based upon grace harper's work with a previous language called flomatic became very popular in the banking financial services industries across the 60s and 70s and 80s and then it stuck around in the 90s and then into the 2000s and it's still with us today um it took the approach of making the language more english-like um so we'll see some of the syntax shortly and you can see what i mean um it's an imperative imperative and

procedural language and then in the early 2000s support for object orientated programming was introduced many of you have probably heard of it because of y2k so around 1984 i think it was folks realized that perhaps using uh you know two digits for the year was going to be a problem once we turned uh into the 2000s so throughout really the 90s late 80s into the 90s there was a lot of work done to patch systems to support dates that looked like the one on the left which is 2 one zero one and not zero zero zero one zero one um that might be a hint for the uh cobol challenge to keep that in mind

um the language is divided into what called divisions and sections so if you look for a cobol program you're going to see things like the identification division at the top which contains the program name or program id the data division which is a section that's used to store the data within the program itself um and then within that you'll see sections so one section is called the working storage section which is where you have variables uh something else called the screen section which is where you can do your ui and screen layout and then display that to the user and then the procedure division is kind of where all of your execution of your logic and your code

uh takes place there's many other uh parts of this which is far too extensive to cover in this talk but if anyone's interested um i will point you towards some documentation especially in the channel on discord after if you want to start digging in so um i mentioned that you know the language is still around with us today and there was continuous additions made to it so in 2002 we had cobalt 2002 which was a bit of a flop um they added recursion to it lots of new reserve words it's been sort of picked apart in a conference paper called the good bad and the ugly by folks from ibm so if you're interested in reading about that

i'll provide the link and then in the later half of the well really the last decade um i ieee 754 data types are supported and then things like method overloading so the language has progressed over the years it's just been slow but because it's still around obviously people have requested new features and and they gradually get incorporated into the language so it isn't obsolete um if any of you've been following the news this year you'll have seen that new jersey and connecticut amongst other states had a lot of problems because there was a huge number of folks applying for unemployment and the systems just couldn't keep up so i believe it was the governor of jersey

was on tv asking for cobalt programmers because even he wasn't aware what the language was because it's quite old uh and there was a shortage and they needed folks to come in and help uh upgrade the systems um in order to keep the demand but it's not just state systems there are banks and lenders and all sorts of financial institutions in new york and elsewhere that are still relying on cobalt and and the tri-state area is probably absolutely riddled with it um because we have the insurance industry in connecticut and then obviously banking and finance in in northern jersey in new york city so it's all over the place um apparently there's lots of jobs

in cobol in hartford connecticut if you're looking i i took a look i think it was last night and zip recruit i had 280 plus jobs uh listed on it i'm sure some of them are duplicates but it should give you an idea that there is some demand up in hartford still in the insurance industry for folks who have cobalt shops it so it really isn't obsolete uh uh selling accenture ibm and some other folks published a report uh three years ago which was picked up by reuters which really sort of dug into some of the uh the numbers behind how cobalt's being used so currently it's estimated about three trillion dollars worth of daily

transactions are handled by cobol systems um eighty percent of in person so branch transactions rely on cobalt in some fashion and 43 of the banking system so banking loans finance has some sort of cobalt system somewhere in the mix um i've seen the number that there's 220 billion lines of cobalt still in use this this was also reported back in 1997 as two billion lines and they were estimating about five billion lines a year were being added well obviously in the last uh you know 20 years we haven't added five billion a year so it's difficult to know whether some of that code is being deprecated and replaced with more cobol or whether that's slowed down

but either way it's a lot um as i mentioned i'm not not too sure about the two billion plus lines but uh we do know there's somewhere in the region of about three million atms in the world um and a good chunk of uh that cobalt code is probably interacting with them i don't even know maybe it's even running on some of the old ones i'm not an expert on how they program atm but they do estimate that cobalt handles around 95 of all atm card swipes so that's uh uh that's a substantial amount of um transactions that cobol code is is responsible for um and there's plenty of other older systems out there that are running it uh

if you're interested check out this report federal agencies need to address aging legacy systems some of these systems in this list go back to the 1970s i believe there's one even in there uh the department of defense that might even be from the 1960s so it's it's pretty crazy you know we've got these embedded legacy systems all across different uh industries where it's finance insurance and then into the government and they all need to be maintained and patched um so the big one is the ibm mainframe i see someone in the chat mention that they're still running ibm membranes um if you check out the job listings you're gonna see zos is listed and ibm

mainframe so mainframes aren't just these big cool computers from war games and 80s movies they're still in use today uh ibm enterprise cobalt played deployed on z os is a common approach and it supports interlanguage interoperability so it can talk to java so basically you can have a bunch of java microservices talk to the cobol backhand so and then in turn allow newer technologies to communicate with all that data that's uh that's sitting there and algorithms and whatever that's involved in i would imagine insurance calculations and credit scores and so on um so that brings its own pros and cons you can have a web interface that can pass data eventually back to the cobol

backend via java but it also introduces its own risks as now the system is in theory exposed via these intermediate tiers um that is going to impact all the engineers on a project because if you're working on a web front end whether it's you know node.js ruby python any of those languages and at some point you have to collect data it has to get passed back through the system um you know the cobalt system goes down then that's going to impact what you do but also uh you know they're kind of relying on you so um there's definitely some security concerns at these various parts of the ecosystem that's been built out so what do you want to do if you want to

experiment at home and you don't have an ibm system so let's say you kind of fancy learning some cobol because some other folks in your company are doing it or you just want to you know learn it because you figure hey i might want to get a job doing this at some point um you don't have to have an ibm system uh you can use something called gnu cobol um and gnu cobalt used to be called open cobalt um it's uh it's open source uh it's built on c and you can write deploy cobalt programs locally um or you can put them in docker containers if you like and then on top of it you can call other c programs from

inside your cobol so if for example you write a cap to the flag a challenge and you want to call another c program you've written you can quite easily do that and um here's a little example for you uh you can see here on the left hand side we're calling this function uh we're calling this program actually called decrypt users and then the c program here's a snippet of the code on the on the right hand side that's being called so you can see that we can do some interaction with files on the file system and then pass that data actually back into the to the cobol program from the ce program um and if you want to run it in docker

it's actually relatively simple you just pull in an ubuntu image um install the open cobalt notice it is called open cobalt and not gnu cobol um and then you can copy your file over into the container run cob c against it and output the binary file and that's actually how we built the ctf challenges for b-sides 2020 was they're all done locally in docker containers and then are now deployed in the aws environment using i think it was ecs so if you do want to do some development locally uh you can also use uh the vs code plugin this allows you to do editing viewing compiling um you can see on the right hand side as

well it will do uh syntax highlighting and it will give you a breakdown on the left-hand side of the uh the ide the various sections i was telling you about so identification division environment division data division procedure division um so it just helps you to develop in a in a clean easy fashion um i used vim from a lot of the development because we weren't doing anything super complex for the challenges but uh something like this is great if you're developing locally um apparently you can deploy cobol now in azure uh micro focus visual cobol um if you take a look at this link uh you can you can deploy in the azure environment that's something i'd quite

like to try and perhaps next year if we do another cobol ctf challenge um we can can give that a crack um so what are some of the issues that an engineer might face who has to work with a cobalt back-end perhaps someone's deployed it in um you know in azure or they've got uh the ibm system running in a data center somewhere so let's move on and take a look at some of the security issues um so high profile breaches involving cobalt have allegedly happened um the office of personnel management in 2015 uh had four million records leaked um opm was facing a huge problem with legacy systems at the time that required modernization and cobalt was cited as a

contributing problem to this or contributing factor i don't like to necessarily blame the programming language i think it's probably more uh just mismanagement and a huge mess over the years people not maintaining systems and migrating them when they should have done um but if you're interested in reading more about the uh the hack you can read it here um so i guess we should probably worry about security right and the answer to that is sure but in the same way as you would any system especially any system that has the infamous cloud sitting in front of it or is exposed to the public internet um so if you if you have to support some complex web of systems and cobalas in

the mix um you know you can advocate uh for deploying some static analysis tools making sure there's unit tests documentation and ci cd processors and and that's something i'll touch on a little bit there are c i c d tools that support cobol so let's let's delve into some of these uh options um we can use universal security practices so hiring and training staff and making sure they're aware of things like the owasp top ten uh we had some of the overwatch folks in the discord channel so feel free to reach out to them if you'd like to learn more um we can follow just general good engineering practices i mentioned documentation unit tests integration

tests uh source control all of those tools you know they're not specific just to modern languages they can certainly help us with um with legacy uh languages like cobol or fortran or any of the others that you may come across um we can do threat modelling uh which we'll cover a little bit um in this talk and we also can buy tooling to help us out so there are modern tools um which allow us to do uh static analysis and similar on cobol code to highlight some of the problems that may have been introduced in the past or that neural engineers are introducing so um one thing i saw when i was doing some research was that some of these systems

are so old and complex that they lack documentation and this actually contributes to making the migration and maintenance really difficult and costly um it also results in some of these migrations partly failing and costing hundreds of millions of dollars uh one story that was in the press a few years ago was uh tsb which was a uk bank and i believe they merged for the spanish bank and they had to bring the two systems together and the whole thing just fell over um it was a it was complete mess so lack of documentation can really make these uh modernization projects and and security patching very difficult um so as a result of that it just throws

more fuel on the fire about uh having to maintain these systems so i think we're probably going to see cobalt around for a while yeah um and especially you know if there's a cost impact of migrating it um banks obviously are quite concerned around risk so they're not going to want to go shutting systems off um that essentially uh contributes their um bottom line someone described it as like trying to replace parts on a plane while you're flying so one area i guess we can start with is is going back and documenting that code having people sit and read the source code and document it so we actually know what those legacy systems are doing uh and they're not just

sitting there churning away and everyone's crossing their fingers that they don't break um you also can't fix bugs if you don't have stuff uh engineers are retiring so as i mentioned this language came about in 1959 a lot of the folks that were sort of in its heyday you know the cream of the crop engineers are retiring or have retired um so the number of available folks who are skilled in cobol programmers are shrinking and this is a huge risk you can't plug security gaps if you don't have folks who are cognizant of security issues but also well-versed in the language in order to be able to to patch them and stay on top of

you know modern techniques for ensuring that the code and the systems themselves are secure um so it does look like we're probably going to need more cobalt engineers uh that certainly seemed to be the case with what happened in jersey where they just had a shortage so in the interim cross-training staff might actually help if you have folks who are responsible for writing that java code that interacts with the cobol back end um making sure that cross training there uh can at least mean that you have backup resources and people that understand how that data flow is going through the systems and then ending up in in that in that back-end system on the ibm mainframe or wherever you have a

house um so the next thing i want to talk about is throughout modeling um and this is really figuring out what interacts with cobalt um if you're running mainframes and you have cloud systems in front of them you need to understand those data flows i mentioned you need to understand all the various components in the system um and the touch points um you know are you sending data to java and then onto cobalt systems does it contain pii or does it contain any kind of financial data atms of course have their own risks uh i'm not sure how many of us are working on legacy atms um i wouldn't even know where to start to know what the issues

are that that's uh it's a complete area of mystery to me so i'm sure that like threat modeling around atms and how they interact with the other systems is probably quite a fascinating area if you can get into it um and as i mentioned you know cobol engineers are retiring uh this isn't the 90s or the y2k area where we had lots of folks who were constantly working on this and had a lot of experience um individuals are retiring um that in itself is a is a a threat and a risk um we can use some threat modeling methodologies to take the existing cobol systems and the various things that talk to them and map out the threat models

um there's pasta stride vast i'm sure some of you have heard of these various methodologies um and there's tooling that supports them and i'm going to touch on that in a moment actually because i think that that can be quite helpful um so uh there's tools like threat modeler and iris risk and then owasp has its open source threat dragon tool um i was poking around a threat modeler and you can actually uh if you're not familiar with the tool you diagram out systems and it will generate a list of potential threats based upon the components in the system um you can actually add in the cpu ids for z os and for cobol servers such as

the hitachi cobalt 2002 net server suite zero one hyphen three so if there are known issues associated with that when you attach the cpe id to the component in your model it should give you a list of potential vulnerabilities and threats associated with it so diagramming out the system can actually help you to visualize where hey okay now we've got these other components and potentially human interactions with it where where are those issues likely to come from and how can we then get ahead of it and patch it and fix it in advance um martin fowler who i'm sure many of you are familiar with um he has actually a great post on threat modeling uh which came out this

year um so if you're interested definitely check this out it's totally applicable to languages beyond cobol um so that you know there really is no reason not to throw your cohort system into the mix when you're threat modeling solutions going forwards if um if you have comore systems of course uh the next thing i wanted to touch on was testing in qa of course we all know engineers love writing unit tests um so you should be adding unit tests to your uh cobol programs um just like anything else uh the open mainframe project um has some material on my github page it still looks like it's under um development uh they've got three uh section training

sections on there the first portion is it looks like it's complete um the second and third portions are still in development but i would keep an eye on that um there's an ibm labs link you can go check out and play around with um and then there's also something it's old but worth looking at is um this neo pragma github repository which has a cobol unit test examples in there so you might get some ideas from there to go um figure out how you might want to write tests for older code that perhaps you've been given to maintain or have to interact with so um functional and integrated tests i mean i think we're all

probably familiar with them if you're not really this is about uh when you introduce new features making sure all the new components talk to each other that there's no regressions introduced and that the you know the new functionality that you included um you know what um so this can also include integrating with other systems so perhaps you change the cobalt back end and you have to make sure it still works the java system so that's all really kind of important not just winging it it's it's you know same with any engineering projects really ensuring that you have solid qa and unit tests and integration tests and functional tests can make life a lot easier and help to

pick up problems before they hit you in production so i did mention ci cd microfocus they have some tools for doing this uh the main open mainframe project book um discusses it too and i actually poached this uh diagram from their uh github repo and it looks like they're building out more information around that so um you know here we can basically integrate our code into a pipeline that builds tests and deploys the cobol um and also we can include static analysis in there ibm has a product called urban code deploy i mean you can see it within this uh ci cd diagram you've got a lot of modern tools in there you're probably familiar

with like github and jenkins and art factory um and then you can deploy it onto um those ibm based systems which you can see up here at the top of the here at the top so i mentioned static analysis so that can be a really great and important part of this um sort of devsecops pipeline um so there is support for cable and enviro products uh my microfocus does sonar cube um has support for uh cobol um if you didn't get the chance to check out john williams talk who was on a little a little while before me um because he has he has a good talk on sona cube as much as there may be flaws with it

it does support cobalt so i'm going to give it a a friendly shout out here and of course the nice thing is if you if you uh invest in static analysis as part of a ci cd devsecops pipeline you can analyze not just um you know your legacy code but you can analyze modern code as well many of the uh sort of server install versions of these as opposed to the cloud versions allow you to construct your own rules as well for um for scanning for vulnerabilities so if you start to discover things yourself over time uh you can build them into the pipeline and then scan for them and then ensure things don't get moved

into production where there's potentially um you know secrets included in in the cobol code or somewhere um so things to be concerned about so some of the stuff that the static analysis tools actually look for um uh you know things that are similar to what we find in other languages so avoid adding uh sql directly into all the cobol code all over the place um because it makes maintenance a real pain if someone goes and changes a table name or similar um it's going to basically break all of those pieces of cobol that have this embedded sequel um you know we tell people not to do some php in other languages so don't do it in

cobol either you know use a um a data layer instead and also um yeah sql injection attacks can be a problem with and sometimes inputs so don't fall into trap of using dynamic sql that's same as php right uh you know in those languages we perhaps use no ram or similar um so the static analysis tools like sonar cube are gonna flag that uh the sonos source rules specifically are gonna flag for dynamic clauses and they're going to highlight potentially insecure usage of like select statements where they're lacking aware cause another thing to avoid using is the accept statement um acceptable his name implies accept any input and doesn't sanitize it um we can display data to a user we can accept a

response and it will just load the data straight into that working storage section i showed you earlier uh and i'm going to show you a quick demo of this um just to emphasize that so remember we mentioned the divisions so this is part of this of the screen section um in one of those divisions and here we can see all we're asking for is press the q key to exit and that gets dumped straight into uh this response input um pickaxe is basically expecting one character and then it moves it straight into the response in settings section of the working uh storage and there's no sanitation there obviously with longer strings you can imagine um sort of problems you might

might encounter and in this uh case you can see below what we've done is we've displayed this um obviously this is just a subsection of the of the screen but we've displayed the stat screen and then we're just accepting that input so i mean that's that's it's a very very simple way of displaying and accepting data but it's also quite risky and as i mentioned don't use just display either uh it's recommended to avoid doing that if possible to the risk of displaying sensitive data so basically combining display and accept and not sanitizing data is risky behaving cobol and uh your static analysis tool will likely like that another thing to do is uh use

the debugging mode um switching it on in production so like other frameworks and languages don't need to debug statements in as they can expose information about the system to attackers so this example here is a bad idea um because we've got debugging mode on i've seen this done in other languages and you know then someone comes along and hits the website and and causes it to do a stack dump and they find all sorts of goodies hidden in there so keep that in mind when you're working with cobol don't don't make the same mistakes um don't programmatically insert subprogram names into at runtime so here we've got an example of we're moving the the subprogram name uh

to my subprog which is a variable and then we're calling it so that's a bad idea make sure that you define the program name not as a variable and then call it uh directly um because otherwise this can just be misused by attackers and you can dynamically insert a different program in and you just don't know uh before runtime what's going to get executed um there's a bunch of other bad practices too and there's there's tons of ways to break your code um which aren't necessarily just security issues but could be leveraged you know uh just by a bad actor to bring your system down to denial of service services there's likely uh lots of cobol

applications running which don't involve any kind of disk encryption uh or the databases that they're talking to aren't encrypted um there's a few uh examples in this link here if anyone's interested and i will share all these at the end so you can go do some reading if you want to follow up so i mentioned training so let's uh let's go on to that section next the open mainframe project um has a whole bunch of resources uh on their website so i'd say i know we've got a whole bunch of students signed up from unh and southern and some of the other universities in connecticut and probably ferrero field if you're a student and you've got spare

time which i think a lot of us have ended up with thanks to covert um you might want to go and have a go at learning some cobol and getting it on your resume the worst that happens is you learn something um the best that happens is your combination of cobol skills plus something else uh helps to land you a good job out of college um or you know uh if you already have a job helps you to move into a slightly better position or something like that as i mentioned there seems to be a lot of jobs around at the moment in the area not a lot of people apparently are uh you know going into the field so

that could be an area to help you um grow your career as much as it's not as exciting as go or rust or any of the other languages and flavor at the moment uh the open mainframe project which i just mentioned as well um you can go to their github account uh it's here at the bottom i'll share that and you can clone stuff from there and go off and have a read of it so um there's plenty of information in there which is super useful so our ctf challenge um so this year we added a ctf challenge that was built on cobol we can't promise you it will have all the security flaws in here

although with our poor cobra programming skills who knows we might use accept in there um the open mainframe project also has pro bowl challenges if anyone's interested in doing uh you know semester almost kind of ctf style things after this um take a look at these links and go have a play around because they're kind of good fun right and that was i think i'm within my 30 minutes 40 minute uh window so that's a basic guide to cobol security um i hope you found it interesting uh and gave you a little bit of insight into cobol usage now and some of the basic security considerations to keep in mind hopefully this has been useful if um you

are doing the cobol challenges just some areas i will highlight keep in mind what we mentioned about being able to call c programs so you've done the get press challenge that may be a hint um keep in mind what i mentioned about dates at the start that's another hint um and uh also there was a flag hidden in there and if you spotted it um remember you can go to the ctf platform and enter it in there and if you have any questions uh head over to the discord channel um and i will be more than happy to answer them there share links resources and um thanks the b-side ct team uh for putting this on this yeah

and that's it so back to you roman or tom or whoever's handling it is the emcee all right thank you so much andy sounds good right awesome talk about an ancient language but obviously still widely used so definitely all right i will see you at the ctf yeah everybody hop on the ctf and try out those cobalt challenges uh i'm 100 certain you'll learn something new on there i always do