L'Agenzia delle Entrate fa da Babbo Natale per i pirati informatici

/ Articolo / L'Agenzia delle Entrate fa da Babbo Natale per i pirati informatici
  • Condividi
Il sito Fisconline, che l'Agenzia delle Entrate ha predisposto per compilare via internet le dichiarazioni dei redditi, utilizza certificati digitali autoprodotti che non proteggono l'utente dal furto delle proprie credenziali (e dei dati fiscali). Il tutto, suppongo perché altra ragione non conseguo immaginare, per risparmiare alle casse pubbliche una cifra dell'ordine dei 250$ all'anno. Da notare che il sito in questione è quello in cui tutti i titolari di partita IVA sono tenuti ad effettuare i versamenti. Ennesima conferma della carenza di cultura informatica della pubblica amministrazione, per usare un eufemismo.

Per rendere il mio argomento intelleggibile è necessaria una breve introduzione. Chi già conosca la tecnologia dei certificati digitali può tranquillamente saltarla.

Connessioni sicure, certificati digitali e Pharming

Mentre falsificare un sito web presentandone uno fittizio per tutta la rete è praticamente impossibile, è relativamente semplice farlo per un insieme ristretto di utenti. Spesso i pirati informatici creano siti che mediano l'accesso a servizi online per rubare i codici di accesso delle persone che tali servizi on line utilizzano. Molti lettori, credo, avran ricevuto messaggi di email che sembravano provvenire da una banca e che sollecitavano il ricevente ad andare sul sito tal dei tali per verificare che i propri dati bancari fossero esatti perché era successo questo o quello. In gergo questa attività è denominata pharming, che è una forma sofisticata di phishing.

Per questa ragione, quasi tutti i siti che trattano informazioni riservate utilizzano delle connessioni sicure, identificabili dall'indirizzo che inizia con https:// anzichè http:// (la s sta per secure). Pagine con questo tipo di indirizzi criptano i dati che vengono inviati fra browser e server. Ma questo non basta a garantire la sicurezza dei dati, perché la comunicazione potrebbe avvenire con un server fittizio, che risiede ad un indirizzo diverso da quello richiesto dall'utente. Occorre quindi che anche la provenienza della pagina visualizzata venga certificata digitalmente.

Per questo motivo, il browser richiede la certificazione digitale delle pagine ad esso inviate. Il certificato inviato dal sito viene in genere convalidato da un'autorità di certificazione riconosciuta (che fornisce una sorta di firma virtuale). Queste autorità certificano che il possessore del certificato è effettivamente quell'entità che sostiene di essere. Ciascun browser viene distribuito con alcuni files che consentono la certificazione da parte di tutte le principali autorità, così che la certificazione da parte di esse possa avvenire automaticamente sullo sfondo, senza intervento da parte dell'utente. Se la certificazione deve avvenire da parte di un'autorità sconosciuta dal browser, l'utente viene avvertito e ha l'opzione di non proseguire con lo scambio dei dati. Se invece tutti i certificati sono in regola, nel browser Firefox la barra dell'indirizzo assume uno sfondo giallo.

Il problema

È facile per un web master creare un certificato in pochi minuti

scrivendoci qualunque cosa, mentre è più complicato convincere un'autorità di certificazione a

firmarlo.

I gestori del sito Fisconline non hanno voluto farsi certificare da una autorità riconosciuta. Si sono invece creati un'autorità di certificazione propria invitando gli utenti ad aggiungerla a quelle autorizzate, cosa assolutamente censurabile per un sito accessibile al pubblico: un eventuale pirata può creare un ertificato ed un'autorità indistinguibili dagli originali (di Fisconline) in pochi minuti.

Ma c'è di peggio: il file che attesta l'autenticità del sito è scaricabile dallo stesso sito in modo non protetto. Se fosse disponibile su un sito protetto, come www.agenziaentrate.it - non cercatelo, non esiste: sto solo cercando di suggerire ai super-pagati burocrati del Ministero del Tesoro come dovrebbero fare il proprio lavoro - si tratterebbe di un peccato veniale, visto che la distribuzione sarebbe sotto il controllo dell'agenzia. Ma così non è. Doppio e gravissimo errore.

----------------------------

L' utilizzo di un certificato non sicuro e la distribuzione del certificato da un sito non protetto rendono il tutto vulnerabile al pharming.

----------------------------

Questa procedura è l'equivalente informatico di chiedere ad un sospetto truffatore di garantire per la propria onestà. Chiarisco ulteriormente come funziona la cosa con una metafora antropomorfica. La procedura normale

è questa: Tizio (Fisconline) chiede a Caio (contribuente) il suo

codice fiscale o numero di carta di credito. Tizio fornisce a Caio un codice e gli dice: se non ti

fidi di me, chiama Sempronio (autorità di certificazione

ufficialmente riconosciuta) e comunicagli questo codice. Caio conosce il numero di telefono di

Sempronio e lo chiama, dicendogli: "Un qualcuno che dice di essere Tizio mi ha chiesto la mia carta di credito. Mi ha dato anche un codice segreto che dovrebbe confermarti che di lui, Tizio, effettivamente si tratta". Sempronio controlla e

verifica con un sistema crittografico che il codice possa essere stato

prodotto proprio da Tizio e solamente da tizio. Dopo averlo verificato, conferma a Caio che

Tizio è veramente chi dice di essere.

Nel caso in questione invece, il metodo adottato dall'Agenzia delle Entrate modifica la procedura precedente nella seguente maniera. Tizio chiede a Caio di verificare con Mevio, che Caio non conosce; Tizio fornisce a Caio il numero di telefono di Mevio, una persona sconosciuta che dovrebbe certificare l'identità di Tizio. Peggio ancora,

Mevio è un dipendente di Tizio!

Insieme alla password l'Agenzia delle Entrate fornisce un ulteriore codice

personale (PIN) con l'intento di migliorare la sicurezza delle

operazioni online.La misura è sostanzialmente inutile contro il pirata

di cui sopra, che può ottenere anche quello insieme a nome utente e password

e qualunque altro dato si comunichi tramite il sito.

Non è finita. Una volta convinto l'utente/contribuente ad installare l'autorità di certificazione fasulla il pirata può falsificare qualunque sito: l'utente può accorgersene solo andando ad esaminare quale autorità di certificazione l'abbia firmato.

In questo modo la procedura mette potenzialmente a rischio anche siti realizzati correttamente, dai sistemi di pagamento alle banche online.

Avviso

Ho scoperto questa cosa solo oggi perchè ho ricevuto la password per posta e volevo dare un'occhiata a come funziona il sito di Fisconline. Quando ho notato l'avviso sul certificato non valido ho subito desistito, e consiglio a chi può di fare altrettanto, o almeno di verificare la consistenza del file scaricato col proprio PC ed uno scaricato con un'altro computer e tramite un diverso provider.

La pagina inglese di Wikipedia sul pharming

evidenzia che se utilizzato su connessioni sicure funziona solo se l'utente deliberatamente ignora gli avvisi sui certificati invalidi.

Anche i privati

Normalmente per effettuare queste transazioni mi servo della mia banca online (Fineco) come intermediario.

Anche il sito di Fineco da questo punto di vista lascia a desiderare, seppure in modo molto meno grave. Infatti, la pagina principale del sito Fineco non è sicura, ma tutti i dati rilevanti viaggiano su connessioni sicure con certificati validi.

Un pirata che volesse rubarmi i dati di accesso dovrebbe ottenere un certificato autentico per un dominio simile (es. fineco.il anzichè fineco.it) ed usare tecniche di dirottamento un po' più sofisticate, ed in ogni caso individuabili: per evitare sorprese basterebbe controllare l'indirizzo di ciascuno dei riquadri (frames) che compongono la pagina web. Inutile dire che trovo assurdo doverlo fare ogni volta che mi collego solo perchè la banca ha scelto un'architettura balorda per il suo sito. Ma è una banca privata che compete con altre per i miei soldi: se vogliono farsi del male, affari loro. Nel caso mi stancassi della loro scarsa professionalità informatica posso sempre muovere i miei soldi da un'altra parte.

Non così per il Ministero del Tesoro e l'Agenzia delle Entrate: non solo mi prendono le tasse, ma non ho alcuna "Agenzia Alternativa delle Entrate" che faccia a loro competizione ed alla quale io possa rivolgermi! Anche usare un'intermediario non risolve il problema, al più me lo nasconde.

Mi chiedo: gli alti funzionari del Ministero del Tesoro a cui la recente Finanziaria ha mantenuto ed aumentato salari che sono due o tre volte più grandi di quelli dei loro analoghi europei, sono competenti in che cosa, esattamente?

 

Indietro

Commenti

Ci sono 8 commenti

Queste follie sono tipiche delle amministrazioni pubbliche, che odiano l'idea di dover usare catene di certificazione dove i loro certificati occupano un livello gerarchico inferiore a quello di certification authorities private come p.es. Verisign; e d'altra parte sono troppo incompetenti per conquistarsi posizioni piu' elevate. Ricordiamoci che i certificati X.509 sono parte dell'architettura ISO X.500, che come la corrispondente X.400 per la posta elettronica fu concepita dal CCITT (oggi ITU) in un'era in cui gli operatori di telecomunicazioni erano monopoli nazionali, per lo piu' pubblici (l'eccezione principale era la statunitense AT&T, che era un monopolio privato). All'epoca si pensava che ogni paese avrebbe avuto la propria autorita' pubblica nazionale (con sotto-autorita' regionali etc.), e al vertice ci sarebbe stata una authority internzionale affidata all'ONU (di cui l'ITU e' appunto un'agenzia). Uno scenario da incubo burocratico, tipo il film "Brazil " di Terry Gilliam, da cui per fortuna fummo collettivamente salvati dall'arrivo di Internet: che non solo di fatto eutanasizzo' X.400 rimpiazzandola con i familiari protocolli basati su TCP/IP come SMTP, ma anche aiuto' a promuovere la liberalizzazione del mercato delle telecomunicazioni. Purtroppo, per ragioni che non ho mai capito, alcuni standard della mala genia X.500 riuscirono a trapiantare il loro tossico DNA in protocolli Internet: e il piu' nefasto e' appunto quello dei certificati X.509, usati principalmente per contenere le chiavi pubbliche del protocollo SSL. Solo che i tempi sono cambiati, e la cima della gerarchia e' oggi occupata solidamente da un manipolo di oligopolisti per lo piu' privati, di cui il piu' importante e' Verisign. Non che sia molto meglio (e che aspettarsi? architetture gerarchiche e oligopoli vanno mano nella mano), ma almeno sono piu' efficienti di monopoli pubblici.

E torniamo quindi all'incompetenza del settore pubblico, sulla quale contribuisco un istruttivo "nanetto". Nel 2000, in Hong Kong il governo decise di metter su la propria Certification Authority affidandola al Post Office locale, HKPO (il ragionamento deve essere stato: "'sta roba serve per Internet, che serve alla posta elettronica: quindi e' di competenza dell'ufficio postale, no?"). E tra squilli di fanfare (si era allora in piena bolla dot-com) fu varato il progetto "e-Cert".

Il Post Office acquisto' a caro prezzo hardware, software e servizi di consulenza da HP (chissa' perche' non potevano usare OpenSSL come i comuni mortali), e dopo svariati mesi comincio' a offrire i suoi servizi: che consistevano da un lato nel fornire server certificates per i siti pubblici (tra cui quello del fisco) e dall'altro nel produrre certificati-cliente da installare nel PC e da usare per autenticarsi al server invece della password.

Com'era facilmente prevedibile (specie da government-skeptics come il sottoscritto), entrambe le iniziative si rivelarono un fallimento completo. Per i certificati server, il P.O. non riusci' a fare includere il proprio root certificate nei principali browsers (MSIE, Mozilla Firefox, Netscape Navigator, Opera...) e quindi i siti che ne usavano i certificati si trovarono a dover chiedere ai propri utenti di scaricare e installare tale root certificate da un sito loro o dell'HKPO. Ma, proprio come nel caso citato da Marcello, quel sito era insicuro!! Peggio ancora, i certificati-cliente, oltre costare circa tre euro e mezzo all'anno, erano complicati da ottenere e installare, anche perche' l'HKPO cercava di venderli inseriti in smartcards per cui serviva un lettore esterno, con tutte le immaginabili grane di installazione, incompatibilita' dei drivers con altro software etc. In alternativa, si poteva scaricare un modulo, da riempire a penna e presentare all'ufficio postale assieme alla carta d'identita', ricevendo un floppy disk dopo diversi giorni. Ben poca gente si scomodo'.

Alla fine, dopo aver speso milioni di dollari del contribuente, il governo getto' la spugna, taglio' i sussidi al progetto e-Cert e decise di permettere, per autenticarsi sui propri siti, anche l'uso di PIN spediti ai richiedenti per posta. E consegnare le relative buste si e' rivelato un modo di partecipare alla rivoluzione informatica piu' adatto alle abilita' dell'HKPO.

 

 

Che buffoni! Italia a parte non mi sarei mai aspettato un simile livello di sciatteria da un paese evoluto.Ed il massimo biasimo va anche ad HP che ha fornito la consulenza!

La cosa più triste per me è il livello di ignoranza diffusa su questi argomenti: per me le connessioni sicure sono veramente tali solo per chi le capisce, il che è relativamente raro persino tra i miei colleghi informatici.Per non parlare del ministero delle finanze!

Per me le nozioni base esposte sopra andrebbero insegnate a chiunque abbia accesso ad un computer, o almeno a chiunque faccia commercio elettronico o simili. 

Quanto alla questione dell' oligopolio delle autorità di certificazione, non mi entusiasma ma sinceramente non vedo alternative praticabili. Quelle cooperative stile "web of trust" o affini le vedo bene per gruppi ristretti ma non per l' uso generale in rete.Forse è perchè non le conosco granchè (mi ricordo vagamente i discorsi sulle "chain of trust" ai tempi del PGP che credo siano parenti stretti) ma l' idea di migliaia di soggetti cui si possan fregare le autorizzazioni per firmare i certificati non mi entusiasma.

 

 

Sono d'accordo sui certificati cliente, ma il "metodo SSH" applicato ai server mi convince solo per utenti tecnicamente preparati, e quindi non lo ritengo praticabile in massa.Non che trovi la materia in se troppo ostica per l' uomo della strada, ma non vedo come possa diventare conoscenza comune per tutti se dopo decenni di uso comune è ignota a buona parte degli addetti ai lavori.

 

Da utente del servizio posso dire che i peccati di sicurezza (che pure ci sono) sono veniali in confronto a quelli di usabilità. 

 Il programma che ti fanno scaricare è una schifezza in java che utilizza una macchina virtuale vecchia, che devi installare apposta. Sul sito si trovano le cose solo se si ha molta pazienza.  Il sistema per recuperare le ricevute ti costringe a un numero esorbitante di click inutili. Il programma è inaffidabile (ho beccato diversi java.null.pointer.error). Il programma non è aperto (che avendolo fatto in java è già un risultato per il quale bisogna sforzarsi). Ti chiede password più volte nel corso di una sessione.

E tutto questo per un programma che dovrebbe venire installato da milioni di professionisti. 

 

Io non sono utente del servizio: delego alcune cose al commercialista ed altre alla banca.

Ho però avuto qualche contatto indiretto con alcuni software del ministero per motivi di lavoro: programmo sistemi ERP,ed ogni anno devo apportare qualche ritocco (spesso solo installando delle patch) a qualche programma che estrae dei dati in formato compatibile con quello utilizzato dai programmi del ministero, ed ho riscontrato alcuni dei difetti cui accennavi più altri più tecnici:

- non consentono di caricare file non prodotti da loro (salvo barando, ma è complicato): unica funzione che serviva a me per verificare la coerenza dei dati estratti da SAP: evidentemente al ministero si aspettano che le aziende medio/grandi assumano gente per inserire nel loro programmino dati che altri hanno già inserito altrove

- sono dei bersagli mobili: per l'elenco clienti-fornitori (prevista entro il 29 aprile e posticipata al 15 ottobre) la circolare con gli ultimi dettagli tecnici è uscita il 3 ottobre, il software definitivo il 12

- il formato dei file richiesti dal ministero, come i formati XML ed EDI etichetta tutti i dati trasmessi e consente di inviare solo quelli necessari, ma anzichè chiamare i vari campi che so RAG_SOC o P_IVA usa nomi tipo S0102, che sta per modulo S primo riquadro secondo campo.Evidentemente per il ministero il dato non ha valore intrinseco ma solo in quanto parte del modulo.Il risultato è che ogni anno viene aggiunto o tolto un riquadro e tutto il programma va riscritto o quasi, come mi era capitato l'anno scorso per le ritenute d'acconto con due campettini utilizzati solo (mi pare) da imprese di proprietà di stranieri.

Non dovrei lamentarmi per questo: alla fine sono un paio di giornate di lavoro in più ogni anno per chi fa il mio lavoro, ma credo che il totale dei costi inutili generati da questi problemi tecnici sia piuttosto rilevante.

 

 

perche non giri questo alla polizia postale di roma, o alla guardia di finanza - il famoso repetto della gdf è  dello stesso dicastero che vigila (ehm) sui soloni dell'agenzia delle entrate.

quanto ai dirigenti del tesoro è bene sapere che guadagnano molto di piu di tutti i colleghi degli altri ministeri (nello stipendio, nelle commissioni, nei cda ecc ecc, solo loro lo sanno) e che una norma sempre in vigore di una legge finanziaria di berlusconi-tremonti prevede che una percentuale dei risparmi ottenuti dalle successive  finanziarie vada a finire nelle tasche di tutti i dipendenti del ministero dell'economia (il calcolo dei risparmi ovviamente se lo fanno in house), previo accordo sindacale, chiaro.

 

Riesumo questo thread per segnalare che il nuovissimo firefox 3 ha un meccanismo di protezione contro il phishing/pharming, per cui se tentate di entrarci da il seguente errore:

 

Secure Connection Failed


telematici.agenziaentrate.gov.it uses an invalid security certificate.


The certificate is not trusted because the issuer certificate is not trusted.


(Error code: sec_error_untrusted_issuer)


* This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.


* If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.


Or you can add an exception…

 

Questo succede solo se non avete installato il certificato dell'agenzia (cosa comunque sconsigliabile: meglio registrare il sito come eccezione).

Ecco il link incriminato.