Code injection: analisi dell’attacco

In ambito cybersecurity, un attacco di tipo Code injection sfrutta i difetti di convalida degli input presenti nel codice sorgente di un applicativo al fine di iniettarvi script di codice malevolo.

Quello a cui si sta assistendo nell’ultimo anno è un vero e proprio revival della minaccia, largamente sfruttata già a inizio anni duemila.

Ma come funziona esattamente la minaccia code injection?
Quali sono le implicazioni per le vittime di attacchi code injection?

In questo articolo cercheremo di far luce su caratteristiche, conseguenze e metodi d’intervento e prevenzione di una Code injection.

Indice degli argomenti

1. Code injection: cos’è

2. Metodologia d’attacco

3. Tipologie di Code injection

4. Differenza tra Code injection e Command injection

5. Conseguenze di un attacco Code injection

6. Best practice per prevenire l’attacco

7. Conclusioni

Noto anche come Remote Code Execution o Remote Code Evaluation, l’attacco di tipo Code injection è annoverato al numero tre della classifica OWASP Top 10, assieme alle altre injection vulnerabilities.

Questo punteggio così alto è dovuto essenzialmente all’indice di rilevabilità, che passa da semplice a molto complesso a seconda del singolo caso d’attacco.

La traduzione letterale dall’inglese del termine Code injection corrisponde a “iniezione di codice”. Già da qui, dunque, si può evincere il meccanismo di fondo dell’attacco.

In sostanza, si tratta di inserire del codice infetto all’interno di un applicativo web al fine di modificarne il comportamento atteso e garantire l’esecuzione di funzionalità anomale.

È una pratica che, in linea di principio, non va a modificare il codice preesistente, il che costituisce il suo massimo punto di forza.

Così facendo, infatti, le aggiunte apportate dall’attaccante verranno interpretate ed eseguite come parte integrate del programma, garantendo così l’invisibilità dell’attacco.

Come accennato nell’introduzione, le vulnerabilità su cui vanno ad agire gli hacker sono proprio le sezioni con difetti di convalida degli input inseriti dagli utenti.

Tra questi in particolare:

• formato dei dati
• caratteri consentiti
• e la quantità di dati previsti

La tipologia di campi d’immissione di input presi di mira, invece, è quantomai varia.
Si va:

• dalla sezione di upload di file
• ai campi di inserimento dati dei form
• passando per altre sezioni di origine dati come cookie o le query string, ovvero quelle concatenazioni che si vanno ad aggiungere all’URL a seguito dell’inserimento di alcuni parametri da parte dell’utente (come l’utilizzo di un filtro o la traduzione di una pagina).

Partendo dall’identificazione di questi campi in grado di accettare dati non attendibili, i pirati informatici sono così in grado di immettere vari script, come la funzione PHP eval() – o un’equivalente in un altro linguaggio – che permettono di:

• accedere all’interprete lato server dell’applicazione
• e utilizzare le chiamate di sistema per eseguire comandi direttamente dal server.

Come per altre tipologie di attacco informatico, anche nel caso delle Code injection  si possono distinguere specifiche sottocategorie.

Analizziamo brevemente le più diffuse.

SQL Injection

In questo caso l’hacker tenta di comunicare direttamente con il database del software sotto attacco sfruttando appunto il linguaggio SQL.

In sostanza, anziché utilizzare script generici, vengono compromesse le string queries, ovvero le richieste eseguite all’interno dei campi di input.

Gli obiettivi sono essenzialmente:

• la modifica, o la completa eliminazione, di alcune sezioni database stesso
• o l’immissione di stringhe apparentemente innocue (come ad esempio ‘1’=’1′ in corrispondenza della password) che risulteranno sempre vere, permettendo al malintenzionato di figurare come utente registrato senza aver realmente immesso alcuna credenziale.

Cross-site scripting

Noto anche come XSS, il Cross site scripting  si differenzia in due sottoclassi specifiche:

• Stored XSS (o persistente)
• e Reflected XSS ( o non-persistente)

Il fine di un attacco di tipo XSS, indipendentemente dalla specifica sottoclasse, è essenzialmente:

• la raccolta
• manipolazione
• e il reindirizzamento

di dati sensibili e informazioni riservate, nonché l’alterazione del comportamento dinamico delle pagine web.

Nelle XSS injection, tutte le volte che il browser richiede al server determinate pagine, il client viene reindirizzato a documenti (pagine web) compromessi, che vengono spacciati come facenti parte del portale originale, ma che in realtà sono state create ad hoc dall’attaccante.

Il tutto si basa, ovviamente, sulla mancata convalida dei dati di input, che possono così essere sfruttati per reindirizzare l’utente verso portali fraudolenti.

Nel caso del Reflected XSS, le si definisce anche non-persistenti  poiché i dati forniti dall’utente (solitamente attraverso form HTML o nell’immissione dell’URL della pagina) sono sfruttati immediatamente per costruire le pagine risultanti. Senza un’adeguata convalida dei dati immessi, infatti, si rende possibile l’immissione di codice di markup, responsabile poi del reindirizzamento.

Per quanto riguarda le Stored XSS, invece, le si denomina persistenti proprio in virtù del fatto che i dati immessi dall’hacker vengono salvati sul database dal server, e quindi mostrati normalmente durante la navigazione dell’utente.

Questa tipologia di XSS, è molto più pericolosa poiché inietta lo script fraudolento automaticamente e quindi viene meno la necessità di indurre l’utente a  cliccare su un apposito link di reindirizzamento.

Un importante aspetto da chiarire in merito alle injections, è la differenza tra

• code injection
• e command injection

Nel primo caso, infatti, si tratta di una serie di tecniche fraudolente che permettono ad un attaccante di inserire del codice arbitrario (lo script) all’interno del codice sorgente dell’applicativo, cosicché le sezioni maliziose vengano eseguite come parte integrante del programma.

Trattandosi di azioni compiute a livello di codice di programmazione, ne consegue che la code injection è condizionata dalle funzionalità del linguaggio utilizzato.

La Command injection, invece, consiste nello sfruttare le vulnerabilità dell’applicazione per estenderne le funzionalità in modo da poter eseguire comandi arbitrari. In breve,  gli aggressori forniscono input non sicuri alla shell di sistema per far sì che l’applicativo esegua i task anomali.

Uno dei primi aspetti da considerare nell’esaminare le ripercussioni di un attacco di tipo code injection è che queste investono

• tanto le funzionalità dell’applicativo preso di mira, causando all’azienda un ingente danno di reputazione, nonché immancabili ripercussioni economiche

• che i dati degli utenti che si trovino ad utilizzarlo, poiché vengono estorti illegalmente senza che questi ne siano consapevoli.

Difatti, tra le conseguenze più rilevanti che un attacco di questo genere si porta dietro, si riscontrano:

• modifica dell’interfaccia del software, come nel caso della contraffazione dei form 
• perdita della confidenzialità dei dati, che anziché essere rilasciati all’ente sul cui portale crede di star navigando, vengono immessi su pagine facenti capo all’attaccante
• indirizzamento non autorizzato verso siti web terzi, ovviamente all’insaputa dell’utente
• modifica, o completa eliminazione, dei dati presenti nel database.

Ad oggi, per prevenire gli attacchi di tipo injection sono state implementate delle misure di security-by.design il cui principio cardine è il paradigma zero-trust.

In sostanza, poiché il tutto si gioca sullo sfruttamento delle falle nell’immissione degli input, basterà considerare qualsiasi carattere o file immesso da un utente come non sicuro.

Seguendo tale principio, lo schema di prevenzione delle code injection si basa su due fasi principali:

• scrupolosa verifica degli input
• e sanificazione, ovvero correzione di eventuali errori riscontrati.

In particolare, questo secondo passaggio può essere articolato in molteplici procedimenti. Di seguito ne elenchiamo le principali.

1. Verifica degli aggiornamenti dei plug-in di terze parti

   Il sistema di installazione dei plug-in è largamente utilizzato sia sui browser, come ad esempio le estensioni di Chrome, che su applicativi come WordPress. Data la loro ampia diffusione, sarà bene effettuare sempre un check sulla loro attendibilità prima di scaricarli, nonché sottoporli periodicamente ad aggiornamento.

2. Destrutturazione dei tag HTML

   si tratta di funzioni preimpostate dei linguaggi di script, che permettono di sostituire i tag HTML con le rispettive codifiche ASCII, cosicché non vegano eseguiti in automatico dal browser.

3. Validazione degli input

   Come riportato in apertura, ciò su cui gli hacker fanno leva è la mancata validazione dei dati in input. Se ad ogni immissione si passa verifica che il dato rispetti: il formato, la lunghezza, la formattazione e i caratteri consentiti, si potrà fornire una prima, ma imprescindibile base di prevenzione dalle vulnerabilità di tipo injection.