E’ stato scoperto un grave bug all’interno di telnetd in Solaris 10 e 11 (SunOS 5.10 e 5.11), le versione 9 o inferiori non sembrano essere affette dal problema.
Il demone telnet, al momento di un login remoto, passa degli switch direttamente al processo per il login per permettere all’utente root il login con altri account senza bisogno di password. Il bug permette, se telnetd è avviato con privilegi di root, di effettuare login senza bisogno di autenticazione.
Di seguito è riportata la parte di codice (preso dal progetto OpenSolaris) responsabile del problema:
/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c
3199 } else /* default, no auth. info available, login does it all */ {
3200 (void) execl(LOGIN_PROGRAM, “login”,
3201 “-p”, “-h”, host, “-d”, slavename,
3202 getenv(“USER”), 0);
3203 }
/usr/src/cmd/login/login.c
1399 case ‘f’:
1400 /*
1401 * Must be root to bypass authentication
1402 * otherwise we exit() as punishment for trying.
1403 */
1404 if (getuid() != 0 || geteuid() != 0) {
1405 audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407 login_exit(1); /* sigh */
1408 /*NOTREACHED*/
1409 }
1410 /* save fflag user name for future use */
1411 SCPYL(user_name, optarg);
1412 fflag = B_TRUE;
Telnetd è disabilitato di default solo sull’update 3 di Solaris. Su update 1 e 2 telnetd è attivo di default con privilegi ristretti.
Siamo nel 2007 e demoni come telnet dovrebbero essere in disuso da anni ormai, ma non sempre è così. ISC suggerisce, a chi proprio non riesce a farne a meno, alcuni modi per ridurre l’impatto del bug.
Nel 1994 la stessa vulnerabilità fu scoperta in IBM AIX.
Nella recente intervista Stefan Esser, ha annunciato che a Marzo inizierà il “Month of PHP bugs”.
Stefan Esser è un consulente di sicurezza tedesco che da anni ha a che fare con software OpenSource.
Circa 6 anni fa è entrato a far parte degli sviluppatori di PHP, grazie a questa mansione è stato a stretto contatto con i sorgenti di PHP capendo così che essi non erano scritti con la sicurezza come obiettivo. Ha così deciso di creare il security team all’interno di PHP per poter gestire in maniera ottimale il report di bug e il rilascio di patch.
Qualcosa nel frattempo è andato storto tanto da farlo ritirare dal gruppo di sviluppatori PHP.
Dal 2004, Stefan, ha iniziato un progetto personale chiamato “Hardened PHP” il quale fornisce patch per aumentare la sicurezza del codice ufficiale. “Hardened PHP” è stato recentemente rimpiazzato da Suhosin, progetto nato dall’idea di dividere “Hardened PHP” in due parti distinte. La protezione dello Zend Engine, per difendere il “core” da buffer overflow, implementata come patch ai sorgenti originali e un’estensione che integra tutti gli altri tipi di protezione.
Suhosin risulta trasparente sia all’utente sia allo sviluppatore: implementa il controllo sui parametri passati alla funzione mail() per evitare injection di header, effettua la crittografia dei dati delle sessioni e dei cookie, blocca le url nei parametri delle funzioni include e require, ecc…
Stefan Esser mentre parla del futuro “Month of PHP bugs”:
Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications.
Lo scorso 10 Gennaio è stata rilasciata la OWASP Testing Guide versione 2 RC1.
La guida (rilasciata anche in pdf e doc) si prefigge lo scopo di diventare un framework per il test della sicurezza di applicazioni e infrastrutture di rete.
Una lettura d’obbligo per application/penetration tester e sviluppatori.
This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web applications. It is intended to give a broad view of the elements required to make a comprehensive web application security program. This guide can be used as a reference and as a methodology to help determine the gap between your existing practices and industry best practices. This guide allows organizations to compare themselves against industry peers, understand the magnitude of resources required to test and remediate their software, or prepare for an audit. This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework.
Non è facile in poche righe descrivere la qualità elevata di questo documento. Tengo solo a sottolineare il fatto che persone come Matteo Meucci, Mauro Bregolin, Luca Carettoni, Stefano Di Paola, Giorgio Fedon, Andrea Lombardini, Claudio Merloni, Antonio Parata, Carlo Pelliccioni e Alberto Revelli hanno reso possibile spostare il baricentro di un progetto internazionale dagli Stati Uniti all’Italia.
Grazie ragazzi!
Matteo Meucci, coordinatore del capitolo Italiano OWASP, sta curando la OWASP Testing Guide dal 2005.
Recentemente molti blog di sicurezza informatica hanno scritto a riguardo della vulnerabilità (se così possiamo chiamarla) nell’ActiveX LunchApp.APlunch preinstallata nei laptop venduti da Acer (non si conosco con precisione tutti i laptop interessati ma sicuramente sono molti modelli).
Il LunchApp.Aplunch, come si può dedurre dal nome, serve ad Acer per aprire URL per l’aggiornamento del software presente sui propri portatili.
Conoscendo il path intero di un file esegubile residente sul sistema vittima, tramite l’ActiveX, è possibile aprirlo senza nessuna interazione dell’utente in quanto LunchApp.APlunch (clsid: D9998BD0-7957-11D2-8FED-00606730D3AA) è settato come “safe for scripting” e “safe for initializing from persistent data”.
Aggiornando Internet Explorer alla versione 7 si risolvono i problemi di sicurezza in quanto la nuova versione del browser Microsoft disabilita l’opzione “safe for scripting” degli ActiveX precedentemente installati sul sistema.
Acer ha rilasciato una patch denominata Acer Preload Security Patch for Windows XP. E’ possibile comunque risolvere ponendo il kill-bit sul CLASS-ID dell’ActiveX come spiegato nella KB 240797 di Microsoft.
Un PoC è disponibile sulla pagina dell’autore della scoperta.
