Mainframes / COBOL have the reputation of being stable and secure. The well-known COBOL brain drain survey from 2009 revealed that 77% of COBOL users believed that COBOL had much better – or at least about the same – security than other languages. This presumption probably comes from a time before the internet, when these computers were only accessible from inside a closed network. Two researchers have recently found out, that software written in COBOL is actually about 5 times more vulnerable than software written in other languages. The article quotes Tony Scott (former federal CIO under President Barack Obama) saying „These systems often pose significant security risks, such as the inability to utilize current security best practices, including data encryption and multi-factor authentication, which make them particularly vulnerable to malicious cyber activity,“
Inhalt
Submitting Job-Cards via FTP
z/OS allows to upload Job-Cards (the Mainframe equivalent of scripts) via FTP (File Transfer Protocol). The Job-Cards are then automatically submitted (executed).
FTP is an un-encrypted clear-text protocol. You can capture passwords with a simple ARP-spoofing / man-in-the-middle attack. After that, you can submit own Job-Cards to your hearts content.
Particularly vulnerable to SQL-Injection Attacks
Consider this code-example by IBM for executing SQL queries. It is quite long – these are the lines I’m talking about:
DATA DIVISION. WORKING-STORAGE SECTION. 01 IOAREA. 02 TNAME PIC X(72). 02 FILLER PIC X(08).01 STMTBUF. 49 STMTLEN PIC S9(4) COMP VALUE 92. 49 STMTCHAR PIC X(92). 01 STMTBLD. 02 FILLER PIC X(20) VALUE 'SELECT * FROM'. 02 STMTTAB PIC X(72).PROCEDURE DIVISION. READ SYSIN RECORD INTO IOAREA. MOVE TNAME TO STMTTAB.MOVE STMTBLD TO STMTCHAR. EXEC SQL PREPARE SEL INTO :SQLDA FROM :STMTBUF END-EXEC.
What this does is: it takes a table-name from <user input>, adds the string literal ‚SELECT * FROM‘ to the front, copies the result to STMTCHAR and passes that to SQL. This has an obvious SQL-Injection vulnerability.
The same vulnerability is in the examples from all other sources that we have examined. Because of that, it is reasonable to assume that such vulnerabilities have been reproduced in many programs. And an SQL-Injection vulnerability is a flaw in a programs fundamental logic – it can’t be fixed automatically – there is no „silver bullet“, due to Rice’s Theorem.
Closed Networks vs. the Internet
To be fair, the security problems might be partially due to the fact that many attack-vectors weren’t known at the time these programs were written.
Early Mainframes didn’t have networking – or at least no IP-networking (they had SNA), so ARP-spoofing just didn’t exist in that context, for example.
Also – at the time, it would have been reasonable for the programmers to assume limited access: How many computers even were there in the closed network? Heck – how many computers even were there in the world? How many people even had access to them?
Security Problems aren’t that much of a problem as long as the programs are only used by your employees.
People you know.
People you can trust.
People you think you can trust.
But what if someone decides to make the programs accessible through a web-frontend (e.g. a bank might want to offer online-banking)? Then the <user input> can come from anybody in the world! Now your database is like an open barn door – any hacker in the world can do with your data whatever they want. Change it, download it completely, or even delete it. Restrictions on the HTML-Forms don’t solve the problem, because these restrictions can be lifted on the client-side via the Developer Console.
Even if you only decide to make the programs accessible through a VPN – not directly via Web – then Hackers are still only one bad password or one vulnerability in the VPN software away from exploiting such problems.
Conclusion
Part of the problem are the programmers, who couldn’t know better and who have made false (but reasonable at the time) assumptions. Julian Totzek-Hallhuber (Solution Architect at Veracode) agrees.
But a huge part of the problem are the design-goals of COBOL and Mainframes. It is just so convenient to upload Job-Cards via FTP. It is just so convenient to construct SQL queries like that in COBOL. COBOL invites you to build your SQL queries like that. IBMs own employees invite you to write SQL queries like that (by setting bad examples).
Security and simplicity are opposites – and COBOL and mainframes are taylored towards simplicity.