I linguaggi informatici: sono proprio “sicuri” o manca qualcosa? L'avvento del  GDPR operativo del 25/05/2018 ci porta un principio fondamentale nello sviluppo software: il legacy by design Significa che il software deve essere progettato tenendo conto della inviolabilità dei dati personali, come si ottiene questo ?:

  1. i file che contengono dati personali devono essere crittografati
  2. i canali di comunicazione devono essere crittografati
  3. i programmi devo essere perfetti:
    • un bug
    • un errore di progettazione
    • potrebbero causare una fuga di informazioni
  4. a questo si aggiunge la consueta sicurezza

Quando vengono sviluppate o si fa manutenzione sulle applicazioni importanti all’interno dell’azienda, soprattutto per quanto riguarda quelle di “back-end” all’interno dell’infrastruttura, la sicurezza dei software diventa una caratteristica essenziale, che non viene gestita in modo corretto in molte aziende. Molti team di sviluppatori sono consapevoli dei problemi di sicurezza nelle applicazioni front-end (sviluppate in Java, .Net e altri linguaggi “moderni” simili). Queste applicazioni trattano molte informazioni e i team spesso seguono “pratiche sicure per la programmazione” e usano sistemi che consentono di rilevare precocemente o prevenire eventuali problemi (come le revisioni, i test di sicurezza, i controlli di codice o gli strumenti di analisi statica e dinamica). Ma quando gli esperti guardano in modo più approfondito i codici in COBOL, RPG, ABAP e altri linguaggi simili, diventa evidente che i software hanno molti elementi di criticità. Le ragioni di questo sono molteplici:

  • molte aziende NON hanno una policy ufficiale per la “programmazione sicura” delle applicazioni di back-end.
  • Gli sviluppatori non comprendono come in certi tipi di tecnologia si possano prevedere dei sistemi di sicurezza.
  • Test specifici sulla sicurezza delle applicazioni non sono comuni.
  • E gli specialisti della sicurezza dei software sono oggigiorno specializzati, nella maggior parte dei casi, sul web e mobile, per loro i mainframe sono qualcosa di sconosciuto.

Nei sistemi “legacy” i problemi di sicurezza sono sempre in agguato come il virus dell’influenza. Il problema è che oggi le applicazioni sviluppate negli anni ‘80 si trovano probabilmente (indirettamente magari) di fronte a Internet e il livello di minaccia si è alzato. Per ricapitolare, possono essere sicure anche le applicazioni “legacy”, ma in un modo diverso rispetto a quello tipico basate su linguaggi moderni. Ricordate che i sistemi di analisi statica (come Kiuwan) non comprendono niente di codice sorgente. L’analisi statica trova solamente schemi definiti (flussi di dati, chiamate proibite o sequenze improprie di operazioni). Quello che è evidente per noi umani non è evidente per un tool. COBOL: il più diffuso linguaggio orientato alle imprese Iniziamo la nostra discussione con il venerando COBOL, nato nel 1959. Perché COBOL è ancora in campo? Probabilmente per il suo aspetto. Se hai sviluppato, tempo fa, un'applicazione importante in COBOL, non puoi permetterti di riscriverla da zero con un linguaggio moderno. Alcuni nuovi sistemi di back-end sono in COBOL; ma trovare qualcuno che non si limiti solo a della manutenzione è raro (“finché funziona”); molti di coloro che ancora utilizzano COBOL sono dei devoti. Nuovo codice in COBOL è comunque scritto ogni giorno, probabilmente questo linguaggio sopravvivrà a tutti noi. Con confondiamoci con l’industria high – tech: non troverete COBOL a Google o Facebook, ma lo troverete in molte applicazioni di back-end, in istituti finanziari, compagnie di assicurazioni… Potremmo dire che COBOL è il lato oscuro dei linguaggi di programmazione. Cobol è un linguaggio “sicuro”? Quali pericoli ci sono di un attacco informatico per le applicazioni scritte in COBOL? Il linguaggio stesso espone ad pochi rischi di attacco:

  • pochi I/O statements (ACCEPT, DISPLAY),
  • DB access (EXEC SQL e altri),
  • data file operations e program calls.
  • L’esecuzione di codice dinamico,
  • la remote file inclusion, HTTP protocols
  • tutti quelli elementi che rendono un’applicazione moderna, web – oriented il paradiso degli hacker, non esistono in COBOL.
  • Esistono supporti per i puntatori, ma questa funzionalità viene raramente utilizzata (quindi i problemi di buffer comuni nelle lingue C-simili non sono frequenti).

Cominciamo a discutere alcuni difetti tecnici in COBOL, con la ben nota SQL Injection. Un precompilato (ad esempio, con database DB2) produce codice sorgente modificato e un modulo di richiesta di database, che è associato a un pacchetto di database / piano di applicazione. In breve, le variabili host sono considerate dati, non parte del codice SQL (aka "istruzione parametrizzata"), e questo lo rende sicuro contro gli attacchi SQL injection. Ma non va dimenticato che SQL dinamico (PREPARE o EXECUTE IMMEDIATE) è consentito e il binding non impedisce che il codice seguente possa essere iniettato in SQL se le variabili host X, Y o Z provengono da ingressi non attendibili.

* Potential SQL injection if X, Y or Z host variables come from untrusted input
STRING "INSERT INTO TBL (a,b,c) VALUES (" X "," Y "," Z ")" INTO MY-SQL.
EXEC SQL PREPARE STMT FROM :MY-SQL END-EXEC.
EXEC SQL EXECUTE STMT END-EXEC.

In COBOL, i file di dati sono tipicamente attendibili, ma sono possibili attacchi di injection, come il traversal path. Ad esempio, MicroFocus COBOL consente di immettere dati di tipo ASSIGN TO DYNAMIC di un file logico SELECT, che potrebbe consentire la manipolazione del percorso se l'ingresso di dati è parzialmente controllato da un input non attendibile. I comandi di file CICS, le funzioni di sistema come CLB_CREATE_DIR e altre routine sono vulnerabili agli attacchi di manipolazione del percorso. WORKING-STORAGE SECTION.    01 prefix   PIC X(10) VALUE "ls -l "    01 filename PIC X(250).    01 null-terminated-command.      05 command      PIC X(256).      05 FILLER       PIC X VALUE x"00".  PROCEDURE DIVISION.      PERFORM get-user-input      PERFORM UNTIL done        STRING prefix filename DELIMITED BY SIZE INTO command * FLAW: system() call with user-controlled argument        CALL "SYSTEM" USING null-terminated-command                      RETURNING return-code-ws        PERFORM get-user-input      END-PERFORM. COBOL non si muove da solo- I programmi COBOL vengono chiamati da lavori in batch e da middlewares online. Spesso le chiamate di sistema e l'esecuzione di comandi CICS (tramite EXEC CICS) sono visibili nel codice COBOL. Librerie crittografiche, come IBM ICSF o iSeries Cryptographic Services API, potrebbero essere utilizzate in modo improprio. Chiamare la libreria C da COBOL può far ereditare i problemi conosciuti con C e le sue librerie, come il buffer overflow. Fortunatamente, questo è insolito. CALL 'gets' USING in-line RETURNING in-line. COBOL è conosciuto come un linguaggio sicuro. Certamente la maggior parte delle istruzioni ("verbi") sono relativamente sicure, in quanto il compilatore COBOL aggiunge controlli di runtime che controllano la validità delle operazioni. Ad esempio, l'indice di tabella o gli intervalli di tabella degli array di caratteri stringati vengono controllati dal compilatore o almeno producono un errore di runtime fuori campo, ma non è possibile sovrascrivere le aree di memoria non intenzionate (nota: tali controlli potrebbero essere disattivati, comunque). Ma ci sono dei modi per evitare questi runtime checks e le compilazioni pre-processor sicure. Per esempio le versioni recenti di COBOL, consentono l'allocazione della memoria dinamica ("heap") e pointer arithmetic. La pointer arithmetic apre gli stessi problemi di buffer overflow trovati nel linguaggio C. La memoria dinamica potrebbe essere abusata (le routine CEEFTST / CEEFRST in IBM System p / iSeries, CBL_ALLOC_MEM / CBL_FREE_MEM sotto MicroFocus Cobol o comandi CICS GETMAIN / FREEMAIN) DATA DIVISION. WORKING-STORAGE SECTION. 77 AREA-POINTER USAGE IS POINTER. LINKAGE SECTION. 01 WORKAREA PIC X(100). PROCEDURE DIVISION. ... * FLAW, no FREEMAIN for the reserved main storage area workarea EXEC CICS GETMAIN SET(AREA-POINTER) LENGTH(100) END-EXEC. SET ADDRESS OF WORKAREA TO AREA-POINTER. ... In COBOL, information flows leaking sensitive or private information could be more relevant than technical issues. A violation of a privacy regulation could have a large impact. The following example shows how sensitive information may be exposed to unintended users; the problem is how to discriminate which is sensitive information and unintended access: Con COBOL, i flussi informativi che fanno perdere informazioni sensibili o private potrebbero essere più rilevanti di quelle tecniche. Una violazione di una regolamentazione sulla privacy potrebbe costituire un grosso problema per l’azienda. Una parola finale sulla disponibilità delle informazioni. Se digiti su google "codifica sicura COBOL", ti sembrerà di essere in una landa desolata. Non per tutti linguaggi di programmazione vale lo stesso. WORKING-STORAGE SECTION. * This record probably holds private information 01 M001O. 05 M001O-SSN PIC X(10). 05 M001O-PERSONAL PIC X(10). 07 M001O-PERSONAL-SALARY PIC X(6). PROCEDURE DIVISION. ... EXEC CICS SEND MAP ('M001') FROM(M001O) ERASE CURSOR FREEKB END-EXEC. Parlando sempre di linguaggi legacy: l’RPG RPG è un altro linguaggio di programmazione “legacy”, nato sempre negli anni ’60, evoluto più tardi da IBM nella sua versione moderna (RPG IV). L’RPG è oggi un linguaggio utilizzato sulla piattaforma IBM, in mainframe o su sistemi mid-range (iSeries, AS/400). Le problematiche sulla sicurezza sono simili a COBOL. Select; When UpdByDept; WhereClause = 'Dept = ' + %EditC(DeptID:'X'); When UpdByJob; WhereClause = 'Job = ' + %EditC(Pos:'X'); When UpdByDate; WhereClause = 'HireDt < ' + %EditC(StartDate:'X'); EndSl; * FLAW, potential SQL injection Stmt = 'UPDATE EmplTable SET Sal = Sal + (Sal * ' + %Char(RaisePct) + ') WHERE ' + WhereClause; Exec SQL PREPARE DynUpdate from :Stmt; Exec SQL EXECUTE DynUpdate; Per quanto riguarda i difetti tecnici, RPG utilizza EXEC SQL per il codice embedded, che è sicuro a meno che non si utilizzi SQL dinamico. F* Externally described DSPF under user control. F BATCHFILE CF P DISK F* D PROGREC DS D PROGNAME 99A I* I INTERPDSPF C OPEN INTERPDSPF C READ(E) INTERPDSPF PROGREC C* FLAW PROGNAME from external input C CALL PROGNAME Problemi di flusso, come con il COBOL, potrebbero verificarsi se lo sviluppatore non segue una corretta politica di sicurezza per prevenirli. RPG e COBOL sono simili per quanto riguarda i difetti. F* Externally described DSPF under user control. FINTERPDSPFCF E WORKSTN USROPN F* D* Standalone field specifying the length of the command passed to QCMDEXC DCOMMANDLEN S 15P 5 INZ(80) D* C OPEN INTERPDSPF C* C* Do until the user presses <F3> C DOU *IN93 = *ON C* C* Prompt user for a CL command and read response C EXFMT COMMANDREC C* C* FLAW: Execute an OS command, potentially controlled by attacker C CALL 'QCMDEXC' C PARM COMMANDFLD C PARM COMMANDLEN D Var1 S 12A D Ptr S * D Var2 S 12A BASED(Ptr) c* FLAW: Pointer arithmetic, not allowed by rule c EVAL Ptr = %ADDR(Var1) + 8192 c EVAL Var1 = 'Hello World!' c* potential bad memory deref issue c DSPLY Var2 tratto e tradotto tradotto da https://www.kiuwan.com/blog/security-business-oriented-languages-cobol-rpg/ iscriviti alle nostra Newsletter