I sistemi AS/400 (oggi IBM i su Power Systems) sono da tempo un obiettivo degli hacker, anche se in modo meno evidente rispetto a Windows o Linux.
Molte aziende li utilizzano ancora in settori critici come banche, assicurazioni, logistica e pubblica amministrazione. Questo significa che ospitano dati sensibili e transazioni finanziarie.
Spesso vengono considerati “sicuri per natura” e non sempre ricevono patch, hardening o controlli di sicurezza aggiornati. Inoltre, molti sono connessi a reti moderne e applicazioni web: se non segmentati correttamente, diventano un punto di accesso verso dati strategici.
Tipi di attacchi osservati
- Brute force / password deboli
Molti ambienti hanno ancora account di default (es. QSECOFR, equivalente dell’admin) con credenziali non robuste.
- Privilege escalation
Errori di configurazione possono consentire a un utente interno di ottenere privilegi amministrativi.
- Accesso remoto non sicuro
Se l’AS/400 espone servizi come Telnet o FTP non cifrati, gli attaccanti possono sniffare credenziali o forzare l’accesso.
- Malware e script di automazione
Anche se gli IBM i non sono colpiti dai classici ransomware Windows, esistono tool malevoli che sfruttano script CL e SQL per esfiltrare dati.
- Attacchi indiretti
Spesso non si attacca direttamente l’AS/400, ma applicazioni web o API collegate a esso, per poi accedere ai database DB2 integrati.
Scenario di attacco diretto: Telnet e credenziali deboli
- Ricognizione
L’attaccante scansiona la rete aziendale e trova la porta 23/Telnet aperta verso l’AS/400.
Con un banner grabber scopre che si tratta di un sistema IBM i. Risultato: ha identificato un target critico.
- Accesso iniziale
L’attaccante prova un dizionario di credenziali note (es. QSECOFR/QSECOFR, QSECOFR/ADMIN123, QSECOFR/PASSWORD).
Trova una password valida e ottiene accesso con i massimi privilegi. Risultato: ora controlla l’AS/400 come amministratore.
- Movimento laterale
L’attaccante esplora le librerie DB2 e trova tabelle con dati bancari (IBAN, anagrafiche clienti, transazioni).
Con comandi CL o SQL può esportare i dati verso un server esterno via FTP. Risultato: esfiltrazione di dati sensibili senza che nessuno se ne accorga.
- Persistenza
L’attaccante crea un nuovo utente con privilegi speciali ma un nome “innocuo” (es. USR001).
Anche se l’azienda cambia la password di QSECOFR, lui può rientrare. Risultato: compromissione di lungo termine.
Impatto diretto
- Furto di dati critici.
- Potenziale manipolazione delle transazioni (es. modificare beneficiari nei pagamenti).
- Rischio di blocco dell’operatività se l’attaccante decidesse di cancellare o criptare librerie.
Scenario di attacco indiretto: applicazioni web collegate al DB2
- Ricognizione
L’attaccante analizza un’applicazione web di un tour operator collegata all’AS/400.
Individua un form di login che invia richieste SQL al backend.
Notando errori anomali, sospetta una vulnerabilità SQL Injection. Risultato: scopre un potenziale punto di ingresso.
- Exploitation
Inserisce nel campo username un payload: ' OR '1'='1 --
Il backend non filtra l’input e l’AS/400 esegue la query senza controlli.
L’attaccante ottiene accesso al database DB2 senza credenziali valide. Risultato: accesso non autorizzato ai dati dei clienti.
- Accesso ai dati
Con ulteriori query ottiene:- Tabelle clienti con IBAN e dati anagrafici
- Storico delle transazioni
- Credenziali interne salvate in chiaro (se presenti)
Risultato: furto massivo di dati sensibili.
- Movimento laterale
Grazie alle credenziali di servizio, si collega direttamente al sistema AS/400 tramite ODBC/JDBC. Risultato: compromissione completa anche del mainframe.
Impatto finale
- Esfiltrazione di dati bancari.
- Possibilità di alterare movimenti finanziari.
- Rischio di sanzioni GDPR e gravi danni reputazionali.
Contromisure principali
- Gestione account e password
- Disabilita o rinomina gli account di default (QSECOFR, QUSER, QPGMR).
- Proteggili con MFA e password complesse (min. 12 caratteri, scadenza periodica).
- Disabilita utenti inattivi.
- Applica il principio del least privilege.
- Accessi remoti e protocolli
- Disabilita Telnet (porta 23) e FTP (porta 21).
- Usa SSH/SFTP con cifratura forte.
- Limita ODBC/JDBC solo a server autorizzati.
- Attiva TLS 1.2 o superiore.
- Sicurezza del sistema operativo
- Applica regolarmente le PTF di sicurezza IBM.
- Imposta Security Level (QSECURITY) almeno a livello 40 o 50.
- Implementa exit programs per controllare l’uso di FTP, ODBC, SQL.
- Logging e monitoraggio
- Abilita QAUDJRN (Audit Journal) per tracciare logon, comandi e accessi.
- Invia i log a un SIEM centralizzato.
- Configura alert per login falliti, creazione/modifica utenti admin, accessi fuori orario.
- Segmentazione di rete
- Metti l’AS/400 in una VLAN dedicata.
- Isola i servizi critici con firewall interni.
- Non esporre mai l’AS/400 direttamente a Internet.
- Consenti l’accesso solo da jump server sicuri e monitorati.
- Database DB2
- Usa autenticazione a livello di libreria/tabella.
- Evita che le applicazioni web abbiano privilegi admin.
- Cifra i dati sensibili a riposo e in transito.
- Monitora query anomale.
- Controlli operativi
- Esegui penetration test specifici IBM i.
- Monitora utenti di servizio e privilegi.
- Esegui backup regolari e test di disaster recovery.
- Prepara un incident response plan dedicato all’AS/400.
