Copy Link
Add to Bookmark
Report
BFi numero 10 anno 4 file 02 di 18
==============================================================================
-----------[ BFi numero 10, anno 4 - 20/09/2001 - file 2 di 18 ]--------------
==============================================================================
-[ C0LUMNS ]------------------------------------------------------------------
---[ iL PR0BLEMA E LA S0LUZi0NE
-----[ Raistlin
IL PROBLEMA E LA SOLUZIONE
Una tragica storia di Boria, Sicurezza, Orgoglio e Pregiudizio.
------------------------------------------------------------------------------
di Raistlin
PROLOGO:
Quanto segue si basa sull'advisory di sicurezza UMBRA Advisory RFP2K02; i
contenuti tecnici di questo articolo, per quanto cammuffati e relativamente
secondari rispetto al suo vero significato, sono validi e non assolutamente
inventati (anche se a volte stupefacenti per la loro stupidita`). Non
lasciatevi stupire dalla forma e cercate di capire la critica fondamentale a
un modo di agire e di essere che si va diffondendo come una piaga all'interno
delle grandi societa` di software. Sorridete e ridete dove e` il caso... ma
come molte commedie, anche questa si porta dentro una morale che non vorrei
sottovalutaste.
AVVERTENZA:
Fatti e persone qui rappresentati sono puramente reali. Non sperate che
quello che ho scritto sia solo una barzelletta. E` la tragica dimostrazione
che la realta` supera anche la peggiore delle fantasie.
PERSONAGGI ED INTERPRETI:
I crediti per l'exploiting di questa curiosa backdoor vanno tutti ai due
mitici Alf Serer ( alf@at.clientlogic.com ) e Rain Forest Puppy
( rfp@wiretrip.net ). Vorrei approfittare per ringraziare quest'ultimo per la
sua amicizia e disponibilita`.
Sempre nel ruolo degli intrepidi cercatori di perle, Gerardo e Ivan Arce
( iarce@core-sdi.com ) della CORE (scopritori del SECONDO bug, come vedremo).
Tra gli interpreti (involontari) della commedia che andremo a mettere in
scena, vi sono anche numerosi man-in-black del Microsoft Security Team. Li
chiameremo tutti Smith, in onore a uno dei piu` grandi film della storia (se
non beccate la citazione potete anche iniziare a frustarvi). Tanto non hanno
una identita`, avvolti nel blobboso nulla della casella anonima
"secure@microsoft.com".
La figura dell'imbecille la fa, dando prova di sapersi calare perfettamente
nella parte, il signor Russ Cooper, gestore di NTBugTraq.
Infine, in tutte le commedie si ringraziano le persone che non sono comparse
sul palco, ma senza il cui contributo, aiuto e incoraggiamento l'opera non si
sarebbe potuta scrivere. Non faccio eccezione. Un ringraziamento a tutti i
fratelli dell'Orda delle Badlands e di S0ftpj. Grazie di esistere cosi` come
siete (cioe`, bastardi dentro ;)
------------------------------------------------------------------------------
ATTO PRIMO - L'INIZIO DELLE OSTILITA`
(qualcuno direbbe "let mortal kombat begin, ma io sono piu` serio - ciauz pho
:)
SCENA I - L'INCRESCIOSO ANTEFATTO
Accadde un di` in quel di Redmond che l'agente Smith, sorridendo, osasse
deridere uno dei frequentatori di Bugtraq (la pericolosa lista di sovversivi
che osava mettere in cattiva luce il Software di Casa Microsoft); si trattava
del povero signor Cuartango, che aveva individuato una vera e propria backdoor
nell'autenticazione dei pacchetti di installazione Microsoft.
Riassumendo concisamente la questione, Cuartango aveva fatto notare quanto
fosse inquietante il fatto che, visitando il sito Microsoft, alcuni controlli
venissero installati automaticamente senza chiedere l'autorizzazione
dell'utente, in forza di "chiavi" privilegiate di autenticazione della stessa
Microsoft. Ora, chiunque si rende conto che questo corrisponde ne` piu` ne`
meno che a una backdoor. Fatto sta che l'Agente Smith, ritenendosi blandamente
offeso dal sospetto (una BACKDOOR? Ma quelle sono cose da hacker! Loro -
secure@microsoft.com - sono i BUONI!) ebbe l'ardire di scrivere (io me lo
immagino con un sorrisino accennato sulle labbra) che l'accettazione
automatica dell'installazione era stata creata:
"to improve our customers' experience while downloading software from
Microsoft web sites."
"per migliorare l'esperienza dei nostri clienti durante il download di
software dai siti Microsoft"
Inoltre, imprudentemente, aggiunse, a ulteriore derisione:
"...we love a good conspiracy theory as much as the next person..."
"...sappiamo apprezzare come chiunque altro una buona teoria di
cospirazione..."
Sottintendendo con questo che fosse assolutamente ridicolo pensare che una
societa` che domina il 75% del mercato dei sistemi operativi potesse,
colpevolmente, inserire delle "backdoor" nei propri applicativi per cercare di
"dominare il mondo".
In effetti e` ridicolo: Microsoft riesce perfettamente a dominare il mondo
anche senza l'uso di backdoor...
"Cos'e` Microsoft?"
"Microsoft e` ovunque, e` intorno a noi, anche adesso, nella stanza in cui
siamo. E` quello che vedi quando ti affacci alla finestra, quando accendi il
televisore. Lo avverti quando vai al lavoro, quando vai in chiesa, quando
paghi le tasse. E` il mondo che ti e` stato messo davanti agli occhi per
nasconderti la verita`"
"Quale verita`?"
"Che tu sei uno schiavo, Neo. Come tutti gli altri sei nato in catene, sei
nato in una prigione senza sbarre, che non ha mura, che non ha odore. Una
prigione per la tua mente"
Ok, ok, mi sono lasciato trasportare... (e` inquietante pero` che questa frase
si adatti cosi` bene alla realta`... e` molto inquietante...). Ma torniamo
all'agente Smith e alla sua spensierata risposta. Alla sua benevola presa in
giro di chi IPOTIZZAVA simili comportamenti SLEALI da parte di una Rinomata
Rispettabile Societa' di Software come Microsoft... torniamo alla solita idea,
che questi agenti del Buonismo di Mamma Software House pensano di poter
spandere impunemente attorno. L'idea per cui e' solo una certa invidia, un
odio preconcetto e congenito, a muovere coloro che fanno critiche
*mode LADY INGLESE INDIGNATA ON*
cosi` INGIUSTE E IRRESPONSABILI! Cielo!
*mode LADY INGLESE INDIGNATA OFF*
SCENA II - IL PECCATO...
Come si sa, orgoglio e menzogna sono peccati capitali. E per una volta la
punizione non si e` fatta attendere...
... E LA PUNIZIONE
Di fronte a tanta dignita` ferita, infatti, nessuno si e` lasciato
impietosire. Ed ecco che come una mazzata sulle gengive e` uscito l'advisory
di sicurezza di cui vi voglio parlare, ovvero:
"Netscape engineers are weenies!"
"Gli ingegneri Netscape sono dei cagasotto!"
Dopo averci fatto sgranare gli occhi con questo titolo quantomeno INSOLITO,
Rain Forest Puppy (per coloro che non lo conoscessero, e` uno dei piu` attivi
contributors di BugTraq, e non e` nuovo a scoperte esplosive come questa...)
ci chiarifica per bene la portata del problema di sicurezza:
"A back door in Microsoft FrontPage extensions/authoring components"
Che mi sembra una frase del tutto esplicativa, anche se lascia qualche
difficolta` a comprendere cosa c'entri il titolo...
Il problema di sicurezza rilevato da RFP e` abbastanza semplice, e al
contempo abbastanza scioccante [qui ed altrove, sono mie le traduzioni dai
post originali, il piu` fedelmente possibile]:
<< con l'option pack di NT4 viene distribuita una ISAPI .dll particolare nella
directory /_vti_bin/_vti_aut/, denominata dvwssr.dll [...] Questa particolare
.dll consente di leggere i file .asp (e .asa) nella root web, posto di
conoscere la 'password' (codificata solo per offuscamento) da utilizzare. E,
come implica il titolo di questo advisory, la chiave costante usata nella
codifica e` "Netscape engineers are weenies!".>>
Ora. Vi siete mai trovati nella condizione di chiedere a qualcuno quale fosse
la sua password e osservare il suo imbarazzo mentre vi rispondeva qualcosa
come "c*zzo123" o altre scempiaggini simili, e si vergognava profondamente
della sua stupidita` nello scegliere le proprie chiavi d'accesso?
Ecco, provate a immaginarvi la faccia di Smith mentre leggeva una advisory di
sicurezza (e vabbe`) riguardante NT (ce ne sono tre al giorno), in particolare
IIS (due al giorno), in cui e` stata scoperta una backdoor INTENZIONALE (e
gia` la situazione si fa piu` tesa), la cui password chiama gli ingegneri
della concorrenza "cagasotto", rivelando solo una duplice, stupida boria,
ovvero quella di insultare dei colleghi e di farlo con la sicurezza di non
essere mai colti in flagrante.
C'e` di che rovinare la giornata anche al nostro impassibile Agente Smith.
RFP riesce a mantenersi serio ancora per qualche istante, il tempo di dare
tutti i limiti della backdoor trovata: infatti <>. Vi prego di fare attenzione a questo particolare, che
nel seguito della nostra tragicommedia avra` molta importanza... In questo
post i limiti e i privilegi della backdoor sono _perfettamente chiari_ ed
enunciati in modo molto professionale, anche se il quadro della situazione
e` abbastanza comico.
Insomma, in qualche modo, l'efficacia "effettiva" di questa backdoor e`
alquanto limitata. Lo stesso RFP lo ammette; ma come potete capire, il piu`
grave danno proviene non tanto dalla effettiva utilizzabilita` della backdoor
quanto dalla sua chiave di crittazione. Trattenendosi a stento dallo scoppiare
a ridere apertamente in faccia a Smith, RFP commenta sarcastico (riferendosi
alla compita letterina dello stesso): << lasciatemi dunque descrivere come
Microsoft abbia anche incluso una ISAPI .dll come parte del pacchetto di
estensioni FrontPage, dell'option pack e di Visual InterDev, "per migliorare
l'esperienza di UN HACKER durante il download di software dal VOSTRO sito." >>
SKLANK! (colpo di mazza chiodata che piove sulla testa di Smith - ma
tranquilli, questi signori sono fatti di pongo come un cartone animato e
possono sopportare questo ed altro, probabilmente continuando a sorridere).
SCENA III - QUALCHE DETTAGLIO TECNICO
Con un certo divertimento malcelato, RFP completa l'advisory descrivendo come
sia stata rinvenuta la famigerata stringa "Netscape engineers are weenies!"
(niente di complicato... era addirittura contenuta IN CHIARO all'interno del
file, anche se inserita all'indietro...). Incuriosito da questa scoperta
(fatta da Alf Serer), il nostro eroe si e` messo a cercare DOVE quella .dll
fosse richiesta da FP o dalle extensions. Un'occhiata al sito Microsoft
(esplicativo, chiaro e completo come al solito) rivelava solo un generico "la
DLL e` usata per verificare gli URL". Strano che a fronte di questo essa non
venisse MAI invocata (anche se viene esplicitamente richiesta da
InterDev 1.0).
Altro piccolo particolare sospetto della DLL medesima: dove tutte le altre
ISAPI .dll delle FrontPage extensions sono alla versione 3.0.2.1105,
dvwssr.dll e` ferma al 1.00.00.2503A. Il che offre solo due possibilita`,
entrambe sconcertanti:
a) Microsoft ha introdotto solo di recente in Front Page tale .dll, oppure
b) Essa e` un residuo dei giorni in cui FP veniva sviluppato dalla Vemeer
Technologies Inc. (... se vi eravate chiesti, come il sottoscritto, il
perche` del prefisso _vti_ eccovi la spiegazione...)
Nel caso a) la responsabilita` di Microsoft e` evidente. Nel caso b), e`
inquietante che dopo l'acquisizione di un prodotto esso non venga auditato, o
quanto meno verificato. In ogni caso il punto e` che Microsoft ha codato, o
consentito, l'inserimento di una .dll con una key statica tanto imbecille
quanto quella citata.
Per coloro che fossero interessati ai dettagli tecnici, l'algoritmo di
encripting simpaticamente ribattezzato "weenie" e` un algoritmo a slittamento
di carattere a 62 posizioni (non includo il codice perl, che puo` essere
comodamente reperito sul sito di SecurityFocus - anche se questo codice
avra` un'importanza non secondaria nel resto di questa vera e propria
telenovela della sicurezza informatica). Sappiate anche che la versione Unix
delle FP Extensions (AHAHAHAHAHAHAHAH, ma ci sara` qualcuno che la usa?) non
include tale codice, e che se non usate InterDev 1.0 potete comodamente
cancellare la .dll per sicurezza.
CORO DELL'ATTO PRIMO
Canta le sagge parole del mai abbastanza lodato RFP:
Regardless if Netscape engineers are weenies,
Microsoft engineers are definately pompous
[ Che gli ingegneri di Netscape siano dei cagasotto o no, ]
[ e` invece certo che gli ingegneri di Microsoft siano parecchio pomposi ]
------------------------------------------------------------------------------
ATTO SECONDO - OVVERO, SI TENTA L'INSABBIAMENTO
SCENA I - PANICO!
Siete nei panni del nostro agente Smith, e vi siete doverosamente presi la
palata sui denti. A mezzogiorno avete saltato il pranzo mentre cercavate di
capire chi avesse combinato questo casino enorme (io penso che chi ha inserito
quel codice non lavori piu` per Microsoft... o che sia stato trasferito nella
stessa filiale del tecnico che attacco` il famoso scanner USB durante la
presentazione di Windows 98...)
Ora, il punto dolente e`: che dichiarazione ufficiale rilasciare? Non si
puo` non commentare una cosa del genere... e del resto e` ovvio che anche
dietro la blobbosa anonimita` della casella secure@microsoft.com non ci si
puo` difendere dalle risate del mondo intero... Pertanto ecco che esce il
compito post della Microsoft (scritto da uno Smith in lacrime che si frusta
col suo cilicio):
Advisory MS00-025, 14 Aprile:
<<
Issue
=====
Dvwssr.dll is a server-side component used to support the Link View
feature in Visual Interdev 1.0. By design, it provides .asp files to
clients who have web authoring privileges on the server. However, it
does not properly restrict the files that a web author can request,
with the result that a user who has web authoring privileges on one
web site could request .asp files from anywhere on the server,
including other web sites hosted on it. However, even with this
vulnerability, the component would only comply with the request if
the specific file granted read access to the user.
>>
I lettori anglofobi (poi mi spiegate come fate ad occuparvi di informatica
senza parlare inglese, eh...) mi scuseranno se mi risparmio di tradurre e mi
limito a commentare... Microsoft non fa altro che riconoscere il danno, anche
se evita accuratamente lo spinoso argomento di chi sia un cagasotto e chi
no...
Tra l'altro hanno anche il coraggio di cercare qualche scusa...
<<
There are some significant restrictions to this vulnerability:
- Only servers hosting multiple web sites could be affected by it
>>
(nel senso che sugli altri server l'author non avrebbe nessun vantaggio a
usare la backdoor...)
<<
- Only a user who has web authoring privileges for a site on the
server could request a file. He would need to know the name and
location of the file on the server.
>>
(si`, mi pare che questo l'avessimo gia` detto... inoltre la seconda
condizione e` abbastanza idiota... se uno ha accesso web author E accesso in
lettura a tali file...)
<<
- The files would only be sent if their permissions granted read
access to the particular user who requested them. In most cases,
this would mean that the files granted read access to the
Everyone group
>>
(Non mi pare poi COSI' INCREDIBILE come condizione... specie considerando il
livello medio di sicurezza dei server web NT...)
<<
- Only .asp files (and global.asa, which is a special-case .asp
file) could be retrieved.
>>
E stikazzi! Nei file .asp ci puo` essere anche del sorgente di un certo
valore (di solito un programmatore ASP non viene pagato poco per creare i
meccanismi di gestione di un sito... figuriamoci se mi va di mettere quei
sorgenti a disposizione della concorrenza...) e sopratutto visto che ASP
accede ai database, possono esserci (in chiaro) delle password di accesso. Ma
stiamo scherzando?
SCENA II - I MEDIA
Affamati di notizie riguardanti gli "acher", molti giornalisti si sono tuffati
a pesce su questa notizia, capendone ovviamente circa un decimo (e sono
buono...), e con ogni trasmissione televisiva questo bug e` cresciuto di
importanza: "un piccolo bug.." "un rilevante problema" "il disastro totale per
i siti di e-commerce" "attenzione: vi potrebbero rubare la carta di credito"
(perche` tanto poi finiscono sempre per parare li`... pare che credano che i
black-hats non abbiano obiettivi piu` goduriosi di queste stramaledette carte
di credito... mah...)
Fatto sta che, anche grazie alle esagerazioni dei media, i nostri cari agenti
Smith si trovano, finalmente, nella condizione di poter dire "no, beh, e` meno
grave di quel che pensassimo" (avete mai notato quanto sia producente questa
strategia? Far si` che gli altri ingigantiscano i vostri errori, fino a
quando li sopravvalutano tanto da passare dalla parte del torto...
impariamola, questa lezione!).
Ed e` cosi` che il signor Russ Cooper, gestore di NTBugTraq e stimato esperto
delle problematiche di sicurezza di NT, riesce a dichiarare, nello stesso
maledetto 14 aprile, che: "Le ultime notizie sono che non vi e` alcuna
vulnerabilita` in DVWSSR.DLL". Sostanzialmente sostenendo che la stringa
(visibile a chiunque: basta disassemblare la .dll) non esiste.
Lascio a commento le parole di Yarmond su Slashdot: "Don't try to fix the bug,
for that is impossible. You must realize the truth: there is no bug." Ogni
riferimento al solito film che pare caratterizzare tutta questa storia e`
puramente secondario.
Sempre Russ Cooper riesce, nello stesso post, a darci una commovente
descrizione degli uomini di Microsoft che "si sono messi al lavoro su questo
come pazzi, cercando di verificare il problema ed analizzando tutti i
possibili pezzi di codice che potessero essere affetti."
Non e` commovente questa storia con gli omini di Microsoft sudati e impaludati
in mezzo a mucchi di righe di codice, cercando disperatamente questa backdoor
cosi` ben nascosta da ESSERE VISIBILE DALL'ESTERNO A QUALCUNO PRIVO DEL CODICE
SORGENTE?
Davvero, a volte uno si chiede se SONO fessi, oppure se si credono tanto furbi
e ci credono tanto idioti da permettersi di sparare impunemente cazzate
simili. Ad ogni modo, Cooper conclude con un rimprovero: "Se gli (agli omini
di microsoft, NdT) fosse stato dato un ragionevole quantitativo di tempo per
rispondere nessuno si sarebbe preoccupato di nulla (i.e. la stampa non si
sarebbe preoccupata di questa storia)."
E cavolo! Pensateci, prima di rendere pubbliche le vostre osservazioni!
Comunicatecelo in privato: "Cara Microsoft, guarda che abbiamo trovato la
BackDoor che hai piazzato in questa .dll: rimuovila, eh! Ora va', e non
peccare piu`!": in questo modo potremo patchare il tutto in silenzio, magari
senza neanche specificare chiaramente la CAUSA del problema. Sarebbe uscito
soltanto il compito post in cui si parla di "vulnerabilita`" e "inappropriata
restrizione d'accesso", e ci saremmo evitati la figura di merda di aver
chiamato i nostri diretti concorrenti "cagasotto". Ma per favore!
SCENA III - IL COLPO DI SCENA (o "L'Incredibile Faccia di Bronzo di Cooper")
Mentre Microsoft esibiva la sua dignita` ferita da queste ingiuste illazioni
della stampa, facendo si` che qualcuno arrivasse a escludere QUALSIASI
problema nella .dll in questione, il signor Gerardo (di CORE), con un po' di
voglia di curiosare (quella che a noialtri non manca mai, vero?) ha dato
un'occhiata piu` approfondita a questo gioiellino di casa Microsoft. E...
sorpreeeeeeeeesa!
"C'era la backdoor!" diranno tutti i miei quarantatre` lettori. No cari,
avete sbagliato: sorpresa, _OLTRE_ alla backdoor (alle volte il destino si
accanisce contro i colpevoli) c'era _anche_ un simpatico buffer overflow, in
grado di consentire l'esecuzione di comandi arbitrari sul server (incluso un
CMD.EXE da remoto). Tanto per cambiare sono bastardo, e per i dettagli
exploitatorii vi rimando al solito SecurityFocus.
Immaginatevi Smith che legge l'advisory, e lo commenta con la stessa frase
che usa l'omonimo coprotagonista di "The Matrix" di fronte al cannoncino
Vulcan del B-212.
"NO!"
E invece si`, cari. E gia` che ci siamo, vogliamo parlare del fatto che
nemmeno Microsoft sia in grado di dirci con QUALI PRIVILEGI questo codice
venga eseguito? Sembra incredibile, dal mio punto di vista di persona abituata
alla sicurezza UNIX, in cui e` sempre abbastanza chiaro con quali privilegi
venga eseguito un certo brandello di codice, ma e` vero! Infatti, in uno
stesso post (MS00-025 update , April 17th) i segugi di Redmond riescono ad
affermare due cose completamente contraddittorie:
> Dvwssr.dll is a server-side component used to support the Link View
> feature in Visual Interdev 1.0. However, it contains an unchecked
> buffer. If overrun with random data, it could be used to cause an
> affected server to crash, or could allow arbitrary code to run on the
> server in a System context.
E quindi, ci pare di capire, il codice si esegue con privilegi di sistema.
Alla faccia del buffer overflow. Ma:
> By default, the affected component, Dvwssr.dll, resides in a folder
> whose permissions only allow web authors to execute it. Under these
> conditions, only a person with web author privileges could exploit the
> vulnerability - but a web author already has the ability to upload
> and execute code of his choice, so this case represents little
> additional threat.
Quindi il codice gira coi privilegi da Web Author? (E DICI POCO?)
Oppure ci state dicendo che il codice eseguito da Web Author ha gli stessi
privilegi di SYSTEM?
Credo restera` un mistero fino a quando qualcuno (esterno alla Microsoft, che
e` evidentemente INCAPACE di dirimere la questione) fara` funzionare un
exploit su questo overflow, dimostrando al di la` di ogni dubbio la sua
portata... certo che pero` e` triste dover fare da balia a una societa`
cosi` seria e professionale...
Ma ecco che, colto in contropiede nella sua opera di Difesa di Microsoft, il
Simpatico e Ridente Russ Cooper perde l'occasione di starsene schiscio
(traduco dal dialetto milanese: zitto, muto e con le orecchie basse) e
contrattacca osservando che "La vulnerability scoperta da CORE sembra
completamente scollegata dal problema "weenie", a parte per il fatto che
risiede nella stessa DLL."
Come se questo risolvesse in qualche modo il problema!
Dopodiche` si ridicolizza ulteriormente precisando che se "CORE desidera nomi
di DLL da controllare... posso inviargliene una
lista-delle-DLL-da-controllare-di-oggi" e che gli sembra ridicolo pensare che
"se in una DLL c'e` un potenziale problema ci saranno probabilmente degli
exploit".
A questo punto uno si chiede: e allora chiudiamo tutte le liste di sicurezza
e piantiamola di analizzare i programmi forniti dalle Grandi e Rispettabili
Software House. Probabilmente il Ridente Cooper intende proprio questo (ma
come? Non gestisce lui stesso la piu` importante lista di sicurezza-NT al
mondo?). E insiste nella linea secondo cui "...se fosse stato dato piu` tempo
a Microsoft prima che il tutto fosse reso pubblico...", provocando una
reazione piccata e pienamente comprensibile di Ivan Arce' (presidente di
CORE, l'azienda di Gerardo, scopritore del secondo baco). Ivan si chiede (e
chiede un po' a tutti noi che ci occupiamo di queste cose) come ci si possa
aspettare che la comunita` della sicurezza si faccia dei problemi relativi
alle possibili travisazioni che dei nostri messaggi faranno i giornalisti.
Purtroppo non c'e` modo di ovviare all'ignoranza con cui vengono trattati
certi temi, e allo stesso tempo non si puo` per questo ricondurre l'analisi
di sicurezza all'underground (dove gia` e` rimasta fin troppo a lungo...).
In sostanza Cooper (con una faccia di bronzo incredibile, sopratutto visto e
considerato che DIRIGE una delle piu` importanti liste di full-disclosure al
mondo) sostiene che se non si fosse fatto casino, il secondo "baco" non
sarebbe nemmeno saltato fuori, quasi a dire: avete trovato questo baco solo
perche` vi scocciava che non ci fosse un reale problema di sicurezza con la
backdoor di prima, state giocando sporco, ci sara` sempre un baco, state
facendo disinformazione.
CORO DELL'ATTO SECONDO
Entra e canta le parole di fuoco di Arce' contro Cooper ed il metodo di
insabbiamento Microsoft:
"I do consider misinformation in terms of information security issues a
serious threat. If someone yells 'FIRE' and that appears to be reasonable,
i'd be very careful ... before yelling "NOT TRUE! NOT TRUE! EVERYTHING IS
FINE!".
...
The problem is that there are bugs out there and people is not taking
appropriate measures to confirm or deny their existence. Excuse me if i'm
being rude, but i'm shocked by the fact that our company is being questioned
because we found a bug."
["Considero la disinformazione nel campo di problemi di sicurezza informatica
una minaccia seria. Se qualcuno urla "AL FUOCO" e pare ragionevole cio` che
dice, io sarei molto cauto ... prima di sostenere: "NON E` VERO! NON E` VERO!
VA TUTTO BENE!".
...
Il problema e` che ci sono dei bug li` fuori, e c'e` gente che non sta
prendendo misure atte a confermarne o negarne l'esistenza. Scusatemi se sono
maleducato, ma sono shockato dal fatto che la nostra compagnia venga messa in
discussione perche` abbiamo TROVATO un bug."]
------------------------------------------------------------------------------
ATTO TERZO - RFP STRIKES BACK
Estratti da "Contemplations on dvwssr.dll and how it affects life" - di
Rain Forest Puppy
SCENA I - UN UOMO INDOMITO
Dopo una lunga pausa di riflessione, RFP decide di riprendere in mano il suo
post e di aggiungere le sue considerazioni all'indegno carosello cui abbiamo
assistito principalmente da parte di Microsoft e di vari "servi sciocchi" del
padrone.
E come d'uso, non lo fa in termini normali. Lo cito senza traduzione,
perche` sono certo che perderei la freschezza dei suoi passaggi in inglese.
"So there I was sitting. An individual injecting permanent black dye into my
arm with a small electrical needle device, forming a tribal pattern that will
forever be on my arm. Half way through I started to wonder 'why'? And trust
me, half way through a tattoo session is not a good time to start wondering
such things.
Why? Why do such things at all? What would others reactions be to it? Why
do I care what others think? Who else is there really?
Deep breath. A flood of Descartes enters my mind. What is there beyond
myself? How can I be assure of anything beyond me?
Quite simply, I can't. I can't tell anyone what it's like to be in
Microsoft's place, because I haven't been there. I don't know what it's like
to be a Netscape engineer and be called a weenie, because I'm not (a Netscape
engineer that is; the other is debatable).
I can not positively state for certain anything other than my own perceptions,
since I only know what, well, I have personally experienced. So I can only
talk of matters concerning me, as when I involve anything beyond myself, I am
making assumptions on its form, state, and the
perception it offers to me.
So I have observed the results of RFP2K02. Every nuance, every publically
spoken word on the subject I could find, I have considered, contemplated. What
does each contemplation involve? I review them to myself..."
Invito tutti coloro che hanno riso fin qui leggendo questo teatrino in cinque
atti a leggersi per intero questo post (lo trovate nell'archivio di bugtraq
all'indirizzo URL:
http://www.securityfocus.com/templates/advisory.html?id=2236)
Io mi limitero` a citarne i brani che mi preme commentare, perche` sono il
climax e la degna conclusione di questa vicenda da operetta della sicurezza
informatica
SCENA II - PER QUEL CHE RIGUARDA LA STAMPA...
Dapprima il Nostro, in una crisi mistica introspettiva e in un lungo e
appassionato monologo degno di una tragedia shakespeariana, si chiede: "Sono
forse io la causa del problema?". In alternativa, tutto il casino che e`
saltato fuori dai media, e` davvero colpa mia?
Per rispondersi, RFP risale al primo articolo sulla vicenda, scritto da Ted
Birdis sul Wall Street Journal. E pensa: "Se io fossi stato Ted, cosa avrei
fatto leggendo la MIA advisory? L'advisory di una persona non nota e che
quindi, per me (Ted) puo` anche sbagliare? Ma e` semplice, mi basta
consultare Microsoft".
E qui e` la sorpresa. Il manager del security-response center di Microsoft,
Steve Lipner (uno dei MIB! Ha un nome! INCREDIBBBBOLE!) CONFERMA a Ted Birdis
un rischio elevato di sicurezza derivante da questa backdoor, che viene
descritta da lui come "assolutamente contraria alle nostre policy" e come
sicura causa di licenziamento per gli eventuali responsabili ancora non
identificati.
Questo per quanto riguarda l'opinione del produttore. Per quanto riguarda
invece l'opinione di Russ Cooper (la PRIMA opinione di Russ Cooper, almeno),
egli dichiara a Ted che il problema minaccia "quasi ogni provider che offra
servizi di hosting... e` un difetto grave..."
Mi ricordo che un detto cinese dice "Three men make a tiger". Perche` se una
persona ti dice che ha visto una tigre in citta`, puoi pensare che sia un
pazzo. Se sono in due, che siano d'accordo. Ma se TRE persone indipendenti ti
confermano la stessa cosa, c'e` da iniziare a pensare che non sia poi del
tutto falsa.
Il "casino" di cui si lamenta Cooper durante la sua arringa difensiva di
Mamma Microsoft Minacciata dai Bimbi Cattivi nasce da qui. Da tre conferme
indipendenti di un problema di sicurezza. E, per colmo di ironia, e` proprio
Russ Cooper (esperto - lo ricordiamo - di sicurezza NT e amministratore - lo
ricordiamo - di NTBugTraq) il primo ad aver detto che si trattava di un
problema "diffuso" e "pericoloso", mentre in effetti l'advisory di RFP diceva
l'esatto contrario, minimizzando.
Tutto sommato, facendo il paragone con la media dei colleghi giornalisti, Ted
Birdis si e` comportato in maniera dignitosissima, cercando addirittura un
secondo e un terzo parere... Puo` essere colpa sua, o colpa di RFP, se le
altre due fonti hanno cambiato idea SUCCESSIVAMENTE (e ci sono le MAIL a
dimostrarlo, in questo teatrino dell'assurdo)?
No, non puo` essere colpa loro.
E quindi, ci si puo` chiedere, dov'e` che Ted Birdis ha sbagliato?
La risposta e` necessaria e stringente: non ha sbagliato in nulla.
SCENA III - LE MIRABILI TRASFORMAZIONI DI RUSS COOPER
"A monk asked Yun Men, 'What are the teachings of a whole
lifetime?' Yun Men said, 'An appropriate statement.'"
- The Blue Cliff Record
RFP e` micidiale nel delineare le tappe della conversione di Cooper.
* Venerdi`, 14 Apr 2000, ora imprecisata
Intervista con Ted Birdis. Il problema e` diffuso, grave, praticamente
presente in ogni internet provider.
* Venerdi`, 14 Apr 2000 11:27:09 -0400
Mail su NTBugtraq: e` un problema di sicurezza che puo` consentire ad altre
persone (che pero` devono avere gia` i permessi di web authoring) di scoprire
dati a cui non dovrebbero avere accesso.
* Venerdi`, 14 Apr 2000 15:32:52 -0400
Mail su NTBugtraq, quella famosa contro cui tuonera` Ivan D'Arce: Non c'e`
assolutamente nessuna vulnerabilita` su DVWSSR.DLL
* Domenica, 16 Apr 2000 10:02:41 -0400
Mail su NTBugtraq: Cooper si autocita e si autocorregge: ho detto che non
c'era la vulnerability perche` allora pensavo cosi`, adesso pero` sappiamo
che non e` vero [non e` vero che non c'era, quindi e` vero che c'era]
Chiarito che in effetti Cooper ha cambiato idea ALMENO due volte, c'e` da
capire il motivo... ma ecco che e` Russ Cooper a spiegarsi, sempre in una
delle mail sopra citate: "I commenti che ho fatto a Ted Birdis riguardo al
problema li ho fatti con poche informazioni a disposizione, e quindi ho
evidentemente sopravvalutato il tutto."
Eh gia`, adesso e` tutto chiaro.
Tranne un piccolo particolare. Perche` un consulente di sicurezza si mette a
pontificare a un giornalista che SICURAMENTE scrivera` un articolo di
rilevanza nazionale su un problema di cui non ha "esattamente presenti" i
confini?
E Russ Cooper, che ha tuonato contro questa "sovraesposizione mediatica", non
si considera in qualche modo uno dei principali responsabili di essa? No,
come ci declama RFP nel:
CORO DELL'ATTO III
(Anche noto come "le autorita` non sbagliano mai, al limite fraintendono")
"I wonder if that [comportarsi come ha fatto Cooper] would be considered
contributing to the 'hype'?
No, I concluded. If *I* had said such a thing, then yes, it would be directly
contributing to the hype. But since an authority said such, well, I would
hope that it would help clear the waters, rather than muddy them.
Yes, muddy. Indeed."
------------------------------------------------------------------------------
ATTO QUARTO - L'EXPLOIT FANTASMA
SCENA I - DEL GIALLO DELL'EXPLOIT
"Even when I do things for the sake of others
No sense of amazement or conceit arises.
It is just like feeding myself;
I hope for nothing in return."
- Shantideva
Ma il macello delle pseudoragioni di Russ Cooper non si ferma qui. Infatti,
il Difensore dei Diritti di Microsoft, come ricorderete, aveva lamentato di
non riuscire a riprodurre l'attacco su una installazione-tipo di Front Page
(come a dire: non e` che RFP ci ha preso in giro?).
Come, "non riproducibile"? Si chiede RFP. Non e` che per caso il buon Russ
non si e` reso conto che dal momento che quel codice era DIMOSTRATIVO e non
un exploit sarebbe stato necessario FORNIRGLI LE CREDENZIALI di Web Authoring
per provarlo? Non che non si possa scrivere in modo diverso per creare un
vero exploit che funzioni anche senza tali credenziali... ma non era questo
lo scopo. Ed era scritto in modo ben evidente in quell'advisory: "Also, the
default permissions don't allow for anonymous users to use the .dll--however,
anyone with web authoring can, and I've seen few sites that have allowed
permission (which is more due to a misconfiguration on their part)."
Peraltro, un evidente, piccolo errore di programmazione (del tutto normale in
codice inserito in un advisory... strano che Cooper non lo abbia notato come
hanno fatto molti altri: forse non comprende il PERL?) lo rendeva
inutilizzabile su alcuni casi critici... ma davvero questo e` sufficiente per
giudicare negativamente il lavoro di una persona? Non lo credo, visto che il
punto era tutt'altro che quello di produrre un exploit funzionante.
Quindi, chiarito che lo script aveva uno scopo preciso (e lo assolveva) e
sotto quali condizioni fosse utilizzabile, la domanda rimane: come mai Russ
Cooper non se ne e` reso conto? Restera` senza risposta, perche` noi qui
stiamo facendo del teatro, e l'arte del narrare e` questa: di far sorgere
domande senza poi pretendere di fornirne le risposte, ma con il solo scopo di
lasciarle alla riflessione del lettore o dello spettatore. Se non vi e` chiaro
cio` che voglio dire, cercatevi la videocassetta di "I-TIGI canto per Ustica"
di Roberto Paolini.
Detto in altre parole: questo articolo non vuole trovare un colpevole, e se
lo troverete lo avrete indicato voi, con il vostro cervello e il vostro cuore.
Non io. Allo stesso modo, tutti hanno visto nel post di RFP la stessa cosa, e
cioe` una non velata presa per i fondelli ai danni dell'imbecille che, in
Microsoft, ha creato questa backdoor infantile. Ma non e` stato RFP a deridere
Microsoft. Ha solo mostrato una piccola verita` (arma terribile, la verita`!
Lo aveva capito perfino Caterina Caselli...). L'impressione che il
comportamento della casa di Redmond fosse degno di un bambino dell'asilo ce
la siamo creata da soli, con il ragionare e giudicare che e` proprio della
nostra condizione di uomini liberi. E lo stesso si puo` dire delle altre
impressioni che, prima della fine di questa storia, inevitabilmente avrete.
SCENA II - PASSWORD, O NON PASSWORD? QUESTO E` IL DILEMMA!
Degno davvero dell'"Amleto" questo passaggio del battibecco Cooper - RFP:
RFP: "This particular .dll allows you to read .asp (and .asa) files under the
web root, providing you know the 'password' (obfuscated encoding scheme) of
which to ask it."
Russ Cooper: "THIS IS NOT A PASSWORD..."
Password, o non password ? Questo e` il problema! Apriamo dunque la bibbia
della crittografia, nientepopodimeno che "Applied Cryptography" di Bruce
Schneier (1996 - seconda edizione):
Capitolo 1, pagina 1: "Il processo con cui si maschera un messaggio in modo
tale da nascondere la sua sostanza si chiama crittazione (encryption)".
Ora, come funziona la richiesta alla DLL? Il nome del file richiesto viene
OFFUSCATO UTILIZZANDO LA STRINGA "Netscape engineers are weenies". Quindi la
richiesta sta, per definizione, venendo "crittata". Anche se normalmente a un
processo del genere si da` il nome piu` "limitato" di "encoding".
Pagina successiva dello Schneier: "Il "plaintext" ... puo` essere un flusso
di bit, un file di testo, una bitmap, uno stream di voce digitalizzata,
un'immagine digitale... qualsiaasi cosa." Questa definizione parrebbe
includere anche i "nomi di file". Forse in una prossima edizione...
Ora, la funzione di encryption (E) e` qualcosa che opera sul plaintext (P) e
lo trasforma in cyphertext (C) , e viceversa per la decryption (D). In
matematica scriveremmo:
E(P) = C D(C) = P ----> D(E(P)) = P, per ogni P [invariante]
Quindi, per stabilire se "Netscape engineers are weenies!", oltre che un
clamoroso autogol pubblicitario, sia una password, ci dobbiamo chiedere se
viene utilizzata nel modo che abbiamo appena detto. Dal momento che lo script
in PERL di RFP trasforma il nome di file (P), usando "matematicamente" quella
stringa (E), in qualcos'altro (C), che poi la DLL di FrontPage ritrasforma,
usando all'indietro quella stringa (D) ancora nel nome di file P, in modo
infallibilmente esatto, direi che si`, si tratta di una stramaledetta
encryption. Questo sarebbe chiaro anche a un bambino, credo, e vi avra`
annoiato che io vi abbia "mostrato" una cosa cosi` ovvia.
Ma allora chiediamoci... perche` una persona intelligente, o stimata tale,
puo` NEGARE l'evidenza? Quali sono i motivi? Chiediamocelo, perche` e`
questo, non altro, il fondamento della morale di questa storia. Della DLL
incriminata si son dimenticati tutti, non serve a nulla... della stringa si
son dimenticati quasi tutti (sicuramente non se ne sono dimenticati gli
ingegneri di Netscape, e nemmeno io che ho scritto questa papagna di
articolo). Ma di questa doppiezza incredibile e di questa capacita` di dire
"che il si` e` no, e che il no, se lo guardi bene, diventa si`" (non e` mia
questa frase, e` di Manzoni), alla facciaccia dell'algebra di Boole, di
questa non dobbiamo dimenticarci mai.
Ma continuiamo a giocare con le parole... sempre secondo Lord Dark Schneier
(scusatemi la concessione al mio essere Otaku... ), capitolo 1 pagina 3:
"Un algoritmo la cui sicurezza si basa sul mantenere segreto il suo
meccanismo di funzionamento si chiama "algoritmo ristretto"".
Dal momento che nessun altro conosceva o aveva pubblicato l'algoritmo
"weenie", esso si puo` giustamente considerare in questa categoria...
perche` cio` e` interessante?
Perche` gli algoritmi ristretti "non consentono di applicare Controllo di
Qualita` e Standardizzazione ai prodotti". Ecco perche` quella DLL e`
scivolata tra le reti di controllo di mamma Microsoft... e infine l'ultima
bordata: questi algoritmi sono utili per "applicazioni a bassa sicurezza" i
cui utenti "non comprendano o non si interessino dei problemi di sicurezza
nel loro sistema". Se questa e` l'immagine che Microsoft ha del suo cliente
business modello nel campo del web authoring e hosting, possiamo anche
andarcene tutti a ramengo, in futuro la sicurezza informatica sara` una
battaglia persa in partenza... E peraltro ci si puo` chiedere, se questa e`
la filosofia di fondo, quanto credibile possa essere l'ISASERVER, il
nuovissimo "enterprise class firewall" di Microsoft. Domande, domande,
domande...
Ma non abbiamo ancora trovato una risposta. Una volta compreso che questo e`
un algoritmo di crittazione ristretto, e che la sua scelta indica una bassa
stima di Microsoft delle nostre capacita` intellettive, "Netscape engineers
are weenies!" ne puo` essere la password?
Ricorriamo sempre alla Bibbia: la password e` una cosa "che puo` assumere un
ampio numero di valori" e che viene utilizzata sia dall'algoritmo di
crittazione che da quello di decrittazione in modo da rendere tali funzioni
dipendenti dalla password, e inutili senza la password corretta. Considerando
che il weenie algorithm calcola la differenza tra le lettere del nome di file
e quelle della famosa stringa, direi che questa e` a tutti gli effetti una
password.
Ne volete una prova? RFP, umoristicamente, cambia: "Netscape engineers are
weenies!" con "Microsoft engineers are weenies!", e nota, sorpreso, che il
risultato non funziona piu`. Straaaano. Probabilmente deve essere perche` la
frase sta antipatica alla DLL... o piu` facilmente, perche` effettivamente
tale frase E` la chiave di crittazione. Considerando che in tutti gli
algoritmi "effettivi" usati nell'universo tale chiave viene chiamata
"password", potremmo QUASI concludere che lo sia... ma un momento, siamo
abituati a pensare che una password sia qualcosa di scelto da noi, definibile
da noi e modificabile. La stringa "Netscape engineers are weenies!" non lo
e`. Possiamo allora chiamarla "hard-coded password", magari. O forse solo
"chiave". Oppure "pass phrase", come nel PGP.
Le password sono tutte chiavi? O viceversa tutte le chiavi sono password? O
forse entrambe? La vita e` un sogno, o i sogni aiutano a vivere? Quanto siamo
piccoli di fronte a questi grandi problemi marzulliani del cosmo e della vita!
Russ, bonta` sua, ci evita di partecipare tutti a "Mezzanotte e Dintorni" e
acconsente: "... utilizzare il termine password per designare quella stringa
non e` al di la` del regno del comprensibile. Infatti client e server devono
entrambi conoscere questo valore, e usarlo correttamente, per comunicare."
Bonta` sua! Quindi, di una password si tratta, alla facciaccia di Amleto, di
Guildenstern, Rosekrantz e del teschio di Yorick. E di chi e` disposto a
corrompere il dizionario e a fare il sofista, pur di non ammettere
l'evidenza: che in una DLL di SISTEMA creata da MICROSOFT esiste una BACKDOOR
dotata di una PASSWORD che avrebbe consigliato a qualsiasi essere umano
dotato di dignita` di fare harakiri per la vergogna.
Sic transit gloria Redmundi.
SCENA III - ADESTE FI(DE)LES
(o "E' un problema cosi` grave che i file .asp si aprano?")
Che, in definitiva, ottenere accesso ad informazioni che ACL e sistemi di
sicurezza tengono occultate sia il modo di procedere di chiunque voglia
violare un sistema, direi che non ci sono dubbi. Che uno dei principali
meccanismi di sicurezza di un server (e in special modo di uno con accessi
FTP e web) sia il controllo d'accesso ai file, e in particolare la "gabbia"
che riserva alla lettura via web solo i file posti sotto la cosiddetta
"web root" direi che non c'e` dubbio.
Internet Information Server e FrontPage hanno una (dis)onorata tradizione per
essere infarciti di bug che consentono in modo piu` o meno illecito di
"traversare" le directory del server, uscendo dalla gabbia della web root e
andando a curiosare piu` o meno ovunque.
Per la precisione, il baco del .asp sembra essere "notevolmente limitato" dal
fatto che per essere utilizzato l'utente deve gia` avere web authoring
permissions su almeno una parte dei file ospitati dal server. Vero. Ma in
ogni caso, questa backdoor consente (almeno in teoria) di leggere file che
NON DOVREMMO poter leggere. E (cosa ancora piu` grave) di attraversare le
directory verso l'alto, leggendo file fuori dalla web root (per esempio:
sorgenti .asp ancora in corso di sviluppo su una directory separata).
Insomma, consente di violare almeno alcune delle restrizioni fondamentali di
sicurezza di un server.
Ma quanto e` grave davvero questo problema?
CORO DELL'ATTO IV
"I do not know. I just know it works. How dangerous this prospect is, is
not for me to judge, because I do not have this problem. I do not use
FrontPage. I do not mourn. I leave the judging to Russ Cooper, and judge he
did do, indeed."
------------------------------------------------------------------------------
ATTO QUINTO - IL PROBLEMA E LA SOLUZIONE
" There are moments where time can stand still...where a second in my mind is
an hour in time. I can not control the passing of minutes; I am only aware
that what was now, is not any more."
Rain Forest Puppy
SCENA I - QUESTO E` UN PROBLEMA? REPRISE
Esiste dunque un problema? Ormai anche il cuore piu` coraggioso inizierebbe a
dubitarne.
Applichiamo dunque il metodo cartesiano e dubitiamo di tutto. Dubitiamo di
Arce' e di Gerardo. Eliminiamo anzi del tutto dal campo quel "secondo exploit"
con buffer overflow. Dubitiamo di RFP e di Cooper. Dubitiamo dei loro post e
delle loro discussioni. Torniamo alla sorgente, al primo post di Microsoft:
"To eliminate this vulnerability, customers who are hosting web sites using
any of the affected products should delete all copies of the file Dvwssr.dll
from their servers." Parola di Redmond, rendiamo grazie a Bill. Cosa ci hanno
detto gli omini in nero?
Beh, capperi, mi stanno raccomandando di eliminare un file. Qualcosa che,
normalmente, appartiene ai "don'ts" dell'informatica (quante volte avete
cancellato una DLL e il vostro delitto e` rimasto impunito? A me di solito
salta fuori una simpatica schermata "collegamento mancante all'esportazione...
reinstallare Windows").
Cancellare una DLL e` un rischio. Cancellare una DLL che "analizza gli url"
passati a un WEBSERVER dovrebbe essere doppiamente, triplamente rischioso,
anzi, del tutto distruttivo. Dire che cancellare questa DLL potrebbe non avere
effetti negativi e` ammettere che essa in realta` non serve a questo, e anzi
non serve a quasi nulla se non viene in qualche modo chiamata. E dire che
cancellarla e` IL modo per fixare un problema, significa ammettere due cose:
1) che effettivamente un problema da correggere esiste
2) che questa DLL non ha altre "funzioni" importanti a parte quella di essere
causa del problema in questione.
In sostanza, questa DLL non "contiene una backdoor". _E`_ una backdoor, e
questa e` la sua _unica_ funzione. Vi pare paglia?
Ammesso dunque (ammesso perche` non possiamo dubitare delle parole di casa
Microsoft quando LORO STESSI consigliano di CANCELLARE una loro DLL) che un
problema con questo file esiste, ovviamente permane una obiezione
fondamentale di Russ Cooper: "Without proper and full permissions applied
across virtual servers on a given box, site leakage or manipulation by others
will always be possible in myriad ways."
Ma questo in qualche modo sminuisce le scoperte di CORE e di RFP? Solo
perche` non si tratta di un nuovo e mistico modo di infrangere le leggi che
regolano un sistema informatico, ma di un modo addizionale di sfruttare le
debolezze che possono sorgere se vengono impostati male i controlli d'accesso
alle informazioni? Se cosi` fosse, dovremmo buttare nel cestino il 99% delle
scoperte in questo campo, in quanto davvero sono pochi, a memoria d'uomo, gli
exploit davvero innovativi nel loro meccanismo.
E se anche questo fosse il dodicesimo modo conosciuto per entrare in possesso
di informazioni abusando della web authoring permission, sarebbe in qualche
modo intrinsecamente piu` grave degli altri. Perche` VOLONTARIO, capperi. Non
dimentichiamocelo. Non si tratta di una sovrapposizione di condizioni tali
per cui, se tutte sono verificate, come effetto "secondario" di una serie di
piccoli errori di progettazione la sicurezza del sistema viene compromessa.
Si tratta di una vera e propria back door inserita volontariamente da una
piu` o meno rispettabile (e qui ci scappa da ridere, lo so...) societa`
dell'era digitale, ed e` QUESTO, non altro, il punto fondamentale (anche se
un notevole punto secondario e`: con che coraggio hanno scelto la password?).
Non lasciamoci sviare dalla discussione se questo problema sia piu` o meno
grave, se esistano altri modi di approfittare di simili condizioni, se
esistano buffer overflow piu` gravi di esso all'interno della stessa DLL.
Questo problema e` ETICAMENTE grave, se intenzionalmente inserito.
TECNICAMENTE gravissimo, se non rimosso per errore. In ogni caso l'immagine di
un produttore di software che si lascia SFUGGIRE una cosa del genere, o la
inserisce INTENZIONALMENTE, dovrebbe risultarne incrinata per sempre.
Perche` questo non succede?
Perche` finiamo per discutere di faccende collaterali, dallo "hype" mediatico
scatenatosi, alle procedure corrette per informare le societa`, alla
gravita` tecnica del bug?
Perche` il cuore del problema, e cioe` la COLPEVOLEZZA ASSURDA di Microsoft,
non viene piu` nemmeno menzionato?
SCENA II - APPRENDERE E INSEGNARE.
"I have heard of the bird trying to teach a fish to fly, but I have never
witnessed a fish coaching a bird on flight. That is, until now."
Rain Forest Puppy
Dopo aver visto in azione il Security Response Team di Microsoft che,
disponendo (suppongo) dei sorgenti di quella DLL non trova qualcosa che un
esterno ha trovato esaminando il compilato; dopo aver visto l'amministratore
di una lista dedicata alla sicurezza sbraitare contro coloro che inviano
advisory nelle liste dedicate alla sicurezza; dopo aver udito giornalisti
parlare di informatica (con ovvia ignoranza) e informatici parlare di
giornalisti (con altrettanto ovvia ignoranza), pensavamo di aver visto tutto.
Non e` cosi`.
Non avevamo ancora visto la serieta` con cui molti prendono l'analisi della
sicurezza. Prendiamo ad esempio il laboratorio di Computer's Reseller News (un
sito commerciale dedicato ai canali di distribuzione del materiale
informatico). Riporta la notizia del "possibile" bug/exploit/security hole
(diamine, nessuno che lo chiami col suo nome: BACK - DOOR) nelle Front Page
extensions. Sentite come lo riporta:
"The CRN Test Center is currently examining a security hole in Microsoft's
FrontPage 98 Server Extensions that allows a hacker to cause a web server to
crash via denial of service attacks."
E gia` fa inarcare un sopracciglio l'idea che il personale del laboratorio di
test di un sito dedicato alla vendita di materiale informatico (gente che di
lavoro, per capirci, monta un pc, ne esamina i benchmark, e modifica le
configurazioni fino a trovare quelle che sembrano piu` performanti salvo
smettere di funzionare appena gli aggiorni i driver delle DirectX...)
"The Test Center is currently seeking the assistance of Microsoft and anyone
that can successfully demonstrate how the security hole can be exploited."
Ma... e tutte le discussioni fatte su bugtraq? Ce le siamo dimenticate di
bazza? Ma questa gente da dove ha recuperato le sue informazioni? Ecco la
risposta:
"The Test Center found a Perl script on the Web that appears to have been
authored by the same individual who originally reported the flaw to Microsoft.
However in attempting to execute the Perl script, Test Center Engineers ran
into syntax errors in the script as well as un-resolved external references."
Beh, normale, chiunque di noi (noi = persone che qualche volta si sono
occupate di sicurezza informatica) si e` scontrato con qualche script che non
funziona... anzi, la stragrande maggioranza degli script e dei .c di exploit
non funzionano, vuoi per sfortuna o perche` sono stati appositamente
disabilitati per evitarne l'uso da parte del primo imbecille che capita per
strada, del cosiddetto "script kiddy", o dell'addetto di un laboratorio di
testing per le performance dei calcolatori a cui sembra cosi` semplice tutta
questa storia dell'hacking che decide, per il fatto di aver imparato due
giorni fa a installare la sua prima distribuzione linux (magari Corel Linux,
cosi` non ha fatto troppa fatica), di essere anche lui un espertissimo di
sicurezza informatica.
Facciamo un giochino come quello della settimana enigmistica. Cosa c'e` di
sbagliato nel seguente piccolo inizio di script?
#!/usr/bin/perl# dvwssr.pl by LordRaYden :)) (neh, bij Rain Forrest Puppy)#
# Usage: dvwssr.pl target_host /file/to/retrieve/source
#use Socket;$ip=$ARGV[0];
$file=$ARGV[1];
Io (NON conoscendo il perl) ci ho messo circa 4 secondi a fare "EH?". Voi
quanto ci mettete a rendervi conto che uno script con la linea "use Socket"
commentata DIFFICILMENTE funzionera`?
Eppure qualcuno che si illudeva di condurre test di sicurezza non se ne e`
accorto.
Eppure questo qualcuno riporta a gran voce che "l'exploit non funziona".
Quanti ne ho conosciuti negli ultimi mesi? Ad alcuni di loro sono stati
affidati (da persone evidentemente ancora piu` ignoranti e disperate) i test
di sicurezza su reti di importanza anche rilevante (commerciale e finanche
militare... giuro e parlo per esperienza personale... ahi, povero stato
italiano, come mi auguro che non ci capiti mai di essere coinvolti in una
guerra dai risvolti informatici...).
Tu gli passi qualche dritta, e loro, regolarmente, ti rispondo "eh ma non ha
funzionato". Cosa fai? Gli spieghi che cosa sia un offset, che per utilizzare
un hack a volte bisogna capire qualcosa dell'effetto, che bisognerebbe
studiarsi il TCP/IP e magari qualcuno dei protocolli dei servizi che stai
tentando di exploitare?
Certe volte la tentazione di limitarsi a dire "Ragazzino, lasciaci lavorare"
e` forte... l'idea che certe informazioni andrebbero riservate a un'elite di
tecnici in grado di capirci qualcosa compare nella mente, strisciante e
seducente... del resto, con una analogia ben calzante, i tecnici e gli
esperti sono i nuovi stregoni dell'era digitale...
Poi pero` mi rendo conto che il paragone non calza. Nel caso degli stregoni,
la conoscenza era volutamente "nascosta", iniziatica. Nel caso
dell'informatica ben poco c'e` di nascosto, o che rimane nascosto in eterno
(questa storia lo dimostra bene...): tutto si riduce a una semplice
necessita`.
Per capire, bisogna imparare. Per saper fare le equazioni differenziali
bisogna prima imparare a fare le moltiplicazioni. Per studiare le reazioni
dei polimeri bisogna prima imparare a leggere una tavola periodica. Per
dipingere bisogna prima imparare come si maneggia un pennello. Ci vuole
tempo, fatica, studio, convinzione, voglia, per tutte queste cose. Dalle
fondamenta al tetto, dal semplice al complesso.
Perche` la gente e` convinta che l'informatica sia differente e si possa
"usare" un computer senza capire nulla di come funziona, come viene
programmato, su quali basi poggia il suo comportamento? Perche` e` convinta
che si possa usare la rete senza non dico conoscere i protocolli, ma sapere
COSA sia un protocollo, e cosa diavolo succeda in quel fumoso insieme "rete"
che persino i libri di informatica dell'universita` rappresentano sempre come
una maledetta, non ben definita "nuvoletta" senza alcun tipo di informazione?
Non si tratta di essere maghi, o iniziati. Si tratta di avere l'umilta` di
imparare cio` che e` necessario, e di ammettere cio` che non si sa, prima di
buttarsi a capofitto in imprese che sono impossibili per chi non sa e non
capisce. L'umilta` e` una grande lezione che l'informatica moderna tende a
far dimenticare. L'umilta` e` la condizione base per apprendere e per
imparare.
Ma sull'umilta`, e sulla sincerita` nei confronti degli altri, l'informatica
moderna offre solo cattivi esempi. Di chi e` la colpa (perche` dal mio punto
di vista di una colpa si tratta) di aver trasformato il computer in qualcosa
di cosi` "intuitivo" da usare, da renderlo assolutamente impenetrabile, non
riparabile, non smanettabile? Da rendere l'utente non qualcuno che "deve e
puo` imparare". Ma qualcuno che ha sempre diritto alla pappa pronta, e non si
rende conto che assieme a questo diritto assume anche un obbligo. Quello di
essere schiavo di chi decide COSA puo` fare. Di essere nato in catene. In una
prigione mentale per cui le cose che gli devono essere chiare e quelle che gli
devono essere oscure sono selezionate da qualcun altro.
Se fossimo in campo politico, chiameremmo tutto questo "censura".
Se fossimo dentro un film, chiameremmo tutto questo "Matrix".
Se fossimo persone coraggiose e libere, chiameremmo tutto questo "Microsoft".
E in ognuno dei tre casi ci sarebbe una sola reazione possibile.
La ribellione.
SCENA III - IL PROBLEMA E LA SOLUZIONE
Come nella migliore delle tradizioni, l'ultima scena dell'ultimo atto si
intitola come l'atto stesso, e come la tragedia. Dice il solito Russ Cooper:
"If we're going to yell "Fire", then there should at least be a real fire to
point at."
E alla fine il fuoco su cui puntare il dito lo abbiamo trovato. Un fuoco
nascosto, eppure devastantemente largo. E per questo bisognerebbe
ringraziare doppiamente episodi come questo che ci consentono di vederlo e di
iniziare quanto meno a portare qualche secchio d'acqua.
Ovviamente il problema non e` la lettura dei file .asp (che, pero`, nonostante
tutta questa manfrina, E` un problema: quell'exploit funziona, eccome).
Il problema non e` nemmeno il buffer overflow (che, nonostante tutte le
stupidaggini dette in proposito da Cooper, c'e`, si sente, ed e` pericoloso).
Il problema non e` nemmeno il fatto che tutto questo succeda in una DLL
inserita come backdoor all'interno di un prodotto che e` uno standard
industriale indiscusso nel mondo non UNIX.
Dice RFP: "It is not the vehicle that concerns me; it is not even the
destination...it is the journey itself."
In altre parole, l'aspetto preoccupante della vicenda non e` tanto il problema
(o i problemi) in se`, quanto la reazione di Microsoft, che dimostra che la
societa` di Redmond ha il CORAGGIO, la CAPACITA` e I MEZZI per creare una
situazione del genere, per ammetterla (erroneamente?) in un certo istante e
per poi riuscire ad OCCULTARLA successivamente.
Chi ha sbagliato nell'ammettere questo problema? Chi ha deciso che esso
doveva venir negato a tutti i livelli da un certo istante in poi? (mamma mia,
"Deny Everything"... sembra X-Files...)
Sbalordisce la crudezza del contrattacco. Sbalordisce la facilita` con cui
Microsoft ha girato la frittata, finendo per far esclamare a Ivan Arce', nel
coro dell'atto II: "Excuse me if i'm being rude, but i'm shocked by the fact
that our company is being questioned because we found a bug."
Perche` se il nostro lavoro e`, ed e` sempre stato, garantire la sicurezza
dell'informazione, non v'e` dubbio che questo lavoro passi anche per
(e SOPRATUTTO per) l'esame minuzioso del software, l'analisi della qualita`
dei prodotti, e la certificazione indipendente della loro sicurezza.
Non si tratta di mettere "sotto accusa" il creatore del software, ma piuttosto
di aiutarlo a migliorare e correggere il suo prodotto. Ma se proprio si deve
parlare di responsabilita`, direi che un bug di sicurezza e` in generale
responsabilita` di chi ha creato il prodotto, non di chi lo ha esaminato
(quando trovo uno yoghurt scaduto al supermercato, mi lamento con il
supermercato, non e` il supermercato che si lamenta con me perche` ho trovato
un prodotto scaduto...).
Che un produttore di software si senta OFFESO da questo, e` un fatto di per
se` abbastanza nuovo (di solito programmatori con meno considerazione di se`
si limitano a ringraziare lo scopritore e a fixare il baco). Che un
produttore accusi o faccia mettere sotto accusa chi ha trovato il baco, e`
ancor piu` raro. Direi che il numero di volte che e` sorto un casino di
proporzioni epiche come questo si conta pero` sulla punta di un dito.
Chiediamoci allora il MOTIVO di tutto cio`. Di questa reazione SCOMPOSTA
della compagnia. Ed il motivo e` semplice. Un bug di sicurezza capita tutti i
giorni, ma questa, agli occhi di chiunque, e` una cosa ben diversa. Tra un bug
e una backdoor c'e` la stessa distanza che tra omicidio colposo e omicidio
premeditato. Un bug e` una tragica fatalita`. Una backdoor e` una spaventosa
e subdola violenza. Una backdoor con una password del genere e` quanto di
piu` imbecille, insensato, e ridicolo sulla scena dell'informatica si sia
visto da un bel pezzo.
In questa tragicommedia abbiamo visto molte cose che avremmo preferito non
vedere. Abbiamo visto insulti piu` o meno velati piovere per distogliere
l'attenzione da cose serie. Abbiamo visto degli squallidi giochi di parole
nati solo per confondere le idee e le acque. Abbiamo visto un balletto di
dichiarazioni contrastanti indegno non dico di una software house e del suo
dipartimento di sicurezza informatica, ma indegno persino del peggior politico
democristiano della storia della nostra sconquassata democrazia parlamentare.
Abbiamo anche visto dove puo` portare l'impreparazione o la preparazione
approssimativa. Abbiamo visto quale livello di conoscenza un certo modo di
fare informatica ambisce a distribuire al volgo. E invero, fino a quando la
cosa che la gente notera` di piu` in un sistema informatico sono i menu` che
compaiono in trasparenza con l'alpha channel (la caratteristica invero piu`
notevole di Windows 2000), questo tipo di politica industriale avra` campo
libero e partita sostanzialmente vinta.
Ma abbiamo anche visto un'altra cosa. Che per mettere in crisi tutti gli
agenti Smith di questo mondo esiste un'arma piu` pericolosa di un fucile,
piu` dannosa di una testata atomica. La conoscenza. La nostra capacita` di
discernere, di analizzare e di criticare (che e` l'unica cosa che ci
distingue, per ora, dagli elaboratori elettronici di cui ci occupiamo) e`
l'unica arma che abbiamo, e l'esempio di RFP ci dimostra chiaramente quanto
pericolosa possa essere. Quante risorse possa mobilitare per fermarci.
La conoscenza e` potere. Anche i soldi sono potere. Noi abbiamo la conoscenza.
Loro hanno i soldi. E` uno scontro impari? Sicuramente.
I soldi si accumulano in poche ore. La conoscenza si accumula in lunghi e
faticosi anni.
I soldi sono transitori. La conoscenza e` eterna.
Non c'e` nulla che non possiamo conoscere (basta che qualcuno abbia la
pazienza di insegnarcelo). Ci sono cose che non si possono comprare (per
quanti soldi possano mettere sul piatto).
Ad esempio noi stessi. Keep fighting.
==============================================================================
--------------------------------[ EOF 2/18 ]---------------------------------
==============================================================================
