Vai al contenuto
Home » log4shell: la catastrofe informatica corre sui log

log4shell: la catastrofe informatica corre sui log

monitor showing C++

Mettere un titolo sensazionalistico e clickbait è una sensazione abbastanza
gratificante. Ok, smettiamola, torniamo seri.

Buongiorno Insicuri, a meno che voi non siate in un settore professionale
diverso dall’IT, da venerdì state prendendo confidenza con tre paroline: log4j,
RCE e CVE-2021-44228.
Non abbiamo un sito o un logo fichissimo come per shellshock o poodle o
heartbleed, ma questa promette di essere veramente la grana di sicurezza
più grossa da un po’ di tempo a questa parte.

log4j è una libreria opensource che
offre una API per implementare funzionalità di logging per applicazioni Java.
Essendo lo standard de facto, se hai un’applicazione j2ee probabilmente log4j
si sta prendendo cura di stampare messaggi di log su file, syslog o db.

La vulnerabilità può essere sfruttata se l’attaccante è in grado di controllare
cosa viene stampato nei log. Passando come parametro, ad un’applicazione web
vulnerabile, una espressione JNDI, il codice della libreria interpreterà la
stessa come codice da eseguire e non come stringa da stampare.

Al netto quindi della vulnerabilità di log4j, se la vostra applicazione web,
scrive dei log solo stringhe statiche o stringhe che vedono i parametri della
querystring (o degli header) sanitizzati, allora un attaccante potrebbe non
essere in grado di sfruttarla.

Se la versione di log4j che utilizzate è superiore o uguale alla 2.15, allora
siete salvi. Questa chiamata automatica JNDI è disabilitata per default, così
come, nelle versioni vulnerabili, potete mitigare la vulnerabilità con
questa impostazione nei settings:

log4j2.formatMsgNoLookups=true

Potete anche cambiare la linea di comando della vostra applicazione Java,
passando questa impostazione come parametro all’interprete:

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

Il consiglio comunque che raccomandano tutti e al quale mi associo è quello di
aggiornare la libreria. Questo è un consiglio che vale però sempre, a
prescindere dal problema di questi giorni.

Vi lascio un interessante
post
di Sophos che vale la pena leggere circa la spiegazione tecnica di come viene
portato l’attacco.

EDIT: invito tutti a leggere questo
thread
. Sotto certe
circostanze, anche la versione 1.x risulta vulnerabile. L’impatto è sicuramente
minore proprio per le numerose condizioni al contorno che devono essere
soddisfatte. Questa vulnerabilità è tracciata come CVE-2021-4104

Altro post molto
interessante

che vale la pena di essere letto.

Cosa possiamo imparare da log4j?

Dunque, sia che noi siamo sviluppatori, capi progetto, security manager o gente
che fa application security per campare, dobbiamo ricordarci che installare un
JAR e abbandonarlo alla sua morte lenta perché “tanto l’applicazione funziona”
è un boomerang che ci torna indietro prima o poi.

Fare application security significa andare a lavorare a stretto contatto con i
team di sviluppo, significa essere nel loro team, partecipare ai meeting,
creare una relazione di fiducia con loro, fare un censimento delle tecnologie
utilizzate ed aiutare gli sviluppatori a tenere le librerie aggiornate.

Significa che il codice noi lo dobbiamo capire e ci dobbiamo lavorare sopra,
cari lettori insicuri. Fare la “saiber” dalla nostra scrivania o dal palco di
una conferenza è troppo comodo ed anche parecchio inutile. Più siamo vicini a
quello che dobbiamo proteggere, meglio lo faremo.

Spero poi che questo esempio dia il colpo di grazia a tutti quelli che ripetono
a pappagallo “è opensource, quindi è sicuro” e magari non hanno mai fatto una
piccola code review in vita loro.

A te, fanboy della GPL, se riesci a trasformare la frase in “Essendo
opensource, ho potuto fare una code review e quindi secondo me è sicuro”,
allora finalmente dirai qualcosa di sensato e soprattutto avrai colto la vera
essenza sia della GPL che dell’opensource.

log4shell quindi è una catastrofe informatica? Bhé sì, è un vaso di Pandora che
si è scoperchiato a fronte della mancanza di governance sui processi di
sviluppo del software. Ci vorrà del tempo per correggere tutte le applicazioni,
magari quelle più interne o dimenticate.

Spero però che tutti possiamo imparare qualcosa in più su come dovremmo
proteggere il nostro fortino.

Enjoy it!

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.