Reviewing COBOL For Fun And Profit

### Overview In this presentation, a former financial sector software developer turned penetration tester and security consultant explains how to approach security code reviews for legacy COBOL applications running on mainframes. Despite modern perceptions that mainframes and COBOL are obsolete relics, they remain central to financial institutions for vital batch operations, overnight routines, and processing massive monetary transactions. The speaker highlights that COBOL is deceptively simple and readable, and that long-standing systems running untouched for decades often harbor overlooked security flaws due to historical operating assumptions.

### Key Topics - **Mainframes in Modern Finance**: Why organizations maintain mainframes—highlighting high processing power, multi-threading capabilities, and the massive financial and operational costs associated with replacing them. - **COBOL Architecture & Readability**: An introduction to COBOL's structure (Identification Division, Environment Division, Data Division, and Procedure Division) and its readable, English-like syntax designed originally to eliminate programming mistakes. - **Shift in Security Assumptions**: Historical perimeter security relied on physically locked rooms, fixed terminal input lengths, and trusted internal networks. Modern attack vectors like cleartext network interception, input manipulation, and updated frontends break these assumptions. - **Static Analysis Tooling**: Practical tips on requesting raw source files rather than mainframe terminal access, utilizing commercial tools like Checkmarx and Veracode, and using VCG (Visual Code Grepper), an open-source tool authored by the speaker that automates checking COBOL code.

### Technical Details - **Variable Type & Length Mismatches**: COBOL defines fields like alphanumeric (`PIC X`), numeric (`PIC 9`), and signed numeric (`PIC S9`). When variables of differing lengths or types are copied to one another, COBOL does not generate traditional memory overwrites or C-style overflows; it silently truncates values or coerces characters into numbers. For example, moving a longer monetary value into a shorter variable truncates digits, creating financial discrepancies. - **SQL Injection in COBOL**: Using the `ACCEPT` statement to collect user input and concatenating it directly into dynamic SQL queries executed against DB2 databases leads directly to SQL injection. DB2's support for semicolon-delimited queries and comment characters enables attackers to execute arbitrary statements. - **Buffer Overflows & Stack Handling**: Unlike C/C++, COBOL does not interleave instruction pointers on a general-purpose stack alongside data. Overflowing or truncating variables alters application data but does not permit direct execution hijack or overwriting return addresses. The speaker notes the availability of an `ON OVERFLOW` handling routine to capture mismatch conditions. - **Control Flow Quirks**: Legacy code frequently relies on nested `GO TO` statements and even self-modifying code via constructs like `ALTER PROC1 PROCEED TO PROC2`, which dynamically rewrites jump destinations and produces hard-to-trace spaghetti logic.

### Takeaways Reviewers should obtain raw code files to analyze with proper tooling rather than wrestling with mainframe terminal interfaces. Client reporting requires explaining risks that have not failed yet but will as variables outgrow legacy capacities (e.g., due to inflation) or as network-level attackers bypass terminal restrictions. Ensuring source libraries on mainframes are execute-only, properly documenting legacy gotos, and verifying that program IDs match filenames are critical remediation steps.