Dan Kaminsky: N00ter contro gli ISP truffaldini

Il ricercatore noto per aver scoperto la vulnerabilità del sistema DNS svela il suo ultimo lavoro: un tool pensato per smascherare i casi di violazione dei principi della net neutrality

Roma – Dan Kaminsky, il tecnologo entrato negli annali delle cronache informatiche per il suo lavoro sulla vulnerabilità del sistema DNS nota come DNS poisoning , è tornato alla ricerca presentando i suoi ultimi lavori alla conferenza Black Hat di Las Vegas: ce n’è per tutti ma soprattutto per gli ISP impegnati in pratiche contrarie ai principi della net neutrality.

Dopo i DNS, Kaminsky ha rivolto la sua attenzione a BitCoin, al protocollo UPnP, l’anonimato in rete e la neutralità della rete. In quest’ultimo caso il ricercatore ha presentato un nuovo strumento di analisi dei dati telematici chiamato N00ter , pensato appunto per smascherare eventuali pratiche di “traffic shaping” messe in atto dagli Internet provider.

“Sono qui come ingegnere” per scoprire come riconoscere le violazioni alla neutrality della rete, ha detto Kaminsky alla conferenza, scovando i provider truffaldini “in maniera incontrovertibile”. N00ter funziona come un proxy , camuffando la destinazione e l’origine dei pacchetti di dati scambiati in rete e poi confrontando la velocità degli scambi con il traffico normale per individuare le differenze.

In questo modo “tutte le altre fonti di alterazione scompaiono e ci resta l’unica causa” di eventuali rallentamenti, dice Kaminsky, vale a dire “l’ISP”. Il ricercatore non invoca una net neutrality “dura e pura” da far rispettare a tutti i costi, ma spera che l’aumento di trasparenza sulle pratiche di traffic shaping indotto da N00ter dia ai politici di Washington la possibilità di prendere decisioni sulle regolamentazioni delle cose della rete.

Alfonso Maruccia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Michele Brami scrive:
    Stuxnet è un'arma
    http://goo.gl/G8zkX
  • andy61 scrive:
    uso improprio
    Se nella mia azienda prendo un esperto nella gestione dei contratti il quale parla solo italiano, e poi lo metto a gestire contratti colossali in lingua cinese con la Cina, non posso pretendere che costui non mi porti a casa contratti assurdi che mi mettono in crisi l'azienda.Il colabrodo nella sicurezza non è pertanto negli SCADA, ma nel fatto che qualche volpe li ha collegati ad Internet senza porsi i semplici quesiti:1) potrebbero ricevere dati dall'esterno?2) potrebbero inviare all'esterno dei dati?
    • Sky scrive:
      Re: uso improprio
      Molto buona anche la seconda domanda!Credo che si sottovaluti molto il fatto che non sia poi così necessario "intrudere" un PC/sistema (cioè fuori -
      dentro) quando un qualsiasi XXXXXno può agevolmente "chiamare casa" per ricevere poi, come <b
      reply </b
      , i comandi da eseguire. Lo stesso dicasi per la consegna dei risultati.Teniamo conto che anche un firewall buono come pf o iptables non può nulla contro una sessione "established" (ovvero: i dati che riceve dall'esterno sono delle <b
      risposte </b
      a sessioni iniziate dall'interno).Meccanismi come il port-forwarding dei router funzionano molto bene nel ridirigere il traffico verso porte note, <u
      quando quel traffico viene dall'esterno </u
      , ma se sono risposte non vengono gestite dal port-forwarding quanto piuttosto dal NAT... il quale dice semplicemente: la domanda veniva dall'IP interno Tale ed allora la risposta la consegno a Tale, anche se le regole di port-forward non hanno traccia di Tale.(sì, in questo periodo mi occupo di egress filtering ;))
  • Michele Brami scrive:
    Scusate se mi permetto...
    Il mio lavoro è quello di progettare sistemi PLC/SCADA, centralizzati o distribuiti... e assicuro tutti che il PLC a logica cablata (con la programmazione a contatti per capirsi) è oggi un lontano ricordo. Adesso esistono linguaggi orientati agli oggetti anche sui PLC: non tutto è Siemens per fortuna! Ci sono anche nicchie molto evolute nel mondo industriale, che non abbandonando il PLC come oggetto (per motivi di affidabilità, robustezza, compattezza, ridondabilità nativa, deterministicità, economicità, caratteristiche realtime, etc...), hanno sofisticato di molto le architetture. Qualunque progettista, e come me spero anche altri, non correrebbe mai il rischio di progettare un network di campo aperto senza inserire delle sicurezze: le stesse degli altri sistemi di più comune diffusione. Chi non lo fa, significa che ha pensato a un sistema "scollegato".Personalmente punterei il dito verso le aziende/organizzazioni che utilizzano questi strumenti in maniera impropria: in un articolo ho letto che le famose prigioni che possono essere aperte anche da remoto, lo sono in virtù del fatto che le guardie usano internet sui PC destinati ai sistemi di controllo... direi che la prima falla della sicurezza è l'aver conXXXXX alle guardie di utilizzare internet su una postazione che dovrebbe invece essere BLINDATA.Tranquillizzatevi: far funzionare un sistema di automazione e controllo alla perfezione che si conosce bene è un lavoro lungo, difficile, pieno di problemi e complicazioni: chi lo vuole sabotare non può avere in nessun caso vita facile!!!
    • Thr scrive:
      Re: Scusate se mi permetto...
      PAROLE SAGGIE!- Scritto da: Michele Brami
      Il mio lavoro è quello di progettare sistemi
      PLC/SCADA, centralizzati o distribuiti... e
      assicuro tutti che il PLC a logica cablata (con
      la programmazione a contatti per capirsi) è oggi
      un lontano ricordo. Adesso esistono linguaggi
      orientati agli oggetti anche sui PLC: non tutto è
      Siemens per fortuna! Ci sono anche nicchie molto
      evolute nel mondo industriale, che non
      abbandonando il PLC come oggetto (per motivi di
      affidabilità, robustezza, compattezza,
      ridondabilità nativa, deterministicità,
      economicità, caratteristiche realtime, etc...),
      hanno sofisticato di molto le architetture.
      Qualunque progettista, e come me spero anche
      altri, non correrebbe mai il rischio di
      progettare un network di campo aperto senza
      inserire delle sicurezze: le stesse degli altri
      sistemi di più comune diffusione. Chi non lo fa,
      significa che ha pensato a un sistema
      "scollegato".
      Personalmente punterei il dito verso le
      aziende/organizzazioni che utilizzano questi
      strumenti in maniera impropria: in un articolo ho
      letto che le famose prigioni che possono essere
      aperte anche da remoto, lo sono in virtù del
      fatto che le guardie usano internet sui PC
      destinati ai sistemi di controllo... direi che la
      prima falla della sicurezza è l'aver conXXXXX
      alle guardie di utilizzare internet su una
      postazione che dovrebbe invece essere
      BLINDATA.
      Tranquillizzatevi: far funzionare un sistema di
      automazione e controllo alla perfezione che si
      conosce bene è un lavoro lungo, difficile, pieno
      di problemi e complicazioni: chi lo vuole
      sabotare non può avere in nessun caso vita
      facile!!!
    • the_speck scrive:
      Re: Scusate se mi permetto...
      - Scritto da: Michele Brami
      Il mio lavoro è quello di progettare sistemi
      PLC/SCADA, centralizzati o distribuiti... e
      assicuro tutti che il PLC a logica cablata (con
      la programmazione a contatti per capirsi) è oggi
      un lontano ricordo. Mah, la mia esperienza e' diametralmente opposta. Io do le specifiche per l'automazione e poi controllo cosa e' stato fatto e come. Nel 100% dei casi, se l'hardware e' un PLC, il linguaggio usato e' il ladder, solo quando proprio non se ne puo' fare a meno ho visto usare l'ST, tipo quando si devono costruire dei messaggi da mandare con una scheda seriale.
      • Michele Brami scrive:
        Re: Scusate se mi permetto...
        Nella mia Azienda invece il ladder è bandito. Non è portabile, non è riusabile, non è documentabile, non è flessibile... Devo continuare?
        • the_speck scrive:
          Re: Scusate se mi permetto...
          - Scritto da: Michele Brami
          Nella mia Azienda invece il ladder è bandito. Non
          è portabile, non è riusabile, non è
          documentabile, non è flessibile... Devo
          continuare?Infatti. Ma se vuoi il codice scritto in ST, ti sparano preventivi piu' alti, dal 20% al 50% in piu'. Prova tu a convincere il mio ufficio acquisti che sono soldi ben spesi. ;)
          • Michele Brami scrive:
            Re: Scusate se mi permetto...
            Magari! Se mi dai un riferimento... Noi non differenziamo in base al linguaggio!
  • Jacopo Monegato scrive:
    ok non sono un esperto
    ma per quanto ho visto normalmente nei piccoli/medi impianti i plc non sono collegati ad internet, al massimo in rete tra di loro... si richiede insomma che ci sia acXXXXX fisico alla macchina, anche solo per mandare il segnale di stop e reset (FISICI, lo stop e reset via remoto si può fare, che io sappia, solo in modalità run_p, ed il relativo switch deve essere in posizione) della macchina dato che il programma in esecuzione è caricato in un'area di memoria poi protetta da scrittura o.Oqualcuno di più esperto in plc siemens mi corregga se sbaglio... sono sicuro che qua non si parla al vento ma ciò non va pari passo con quello che mi han insegnato
    • Lemon scrive:
      Re: ok non sono un esperto
      - Scritto da: Jacopo Monegato
      ma per quanto ho visto normalmente nei
      piccoli/medi impianti i plc non sono collegati ad
      internet, al massimo in rete tra di loro... si
      richiede insomma che ci sia acXXXXX fisico alla
      macchina, anche solo per mandare il segnale di
      stop e reset (FISICI, lo stop e reset via remoto
      si può fare, che io sappia, solo in modalità
      run_p, ed il relativo switch deve essere in
      posizione) della macchina dato che il programma
      in esecuzione è caricato in un'area di memoria
      poi protetta da scrittura
      o.O

      qualcuno di più esperto in plc siemens mi
      corregga se sbaglio... sono sicuro che qua non si
      parla al vento ma ciò non va pari passo con
      quello che mi han
      insegnatoIo di PLC non so nulla, però una azienda che vende i loro impianti in tutto il mondo mi ha chiesto tempo fa di studiare un qualche sistema per farli accedere da remoto ai loro sistemi, via TCP/IP controllavano e potevano riprogrammare i loro impianti con il linguaggio PLC. Loro mi hanno parlato di acXXXXX direttamente all'impianto, non ad un PC con qualche software collegato tramite interfacce dedicate.Il loro problema è che non volevano chiedere alle aziende di riconfigurare i loro firewall, aprire porte ecc, volevano capire se c'era un'alternativa.
    • collione scrive:
      Re: ok non sono un esperto
      una volta era così, ma oggi c'è sempre più la necessità di accedere a quei sistemi da remotoed è a questo punto che avviene il patatrac
    • GIGI scrive:
      Re: ok non sono un esperto
      Tutti gli impianti che ho avviato di recente sono collegati in internet, anni fà invece era più comune il modem 56k o isdn.Normalmente si accede tramite vpn ai plc, molte volte anche senza vpn, comunque la sicurezza è sempre a carico dell IT dell'azienda. Le password sul plc Siemens di base non ci sono, bisogna impostarla e non è obbligatoria, solo i plc failsafe la richiedono obligatoriamente, e normalmente chi la imposta non lo fà per la sicurezza informatica, ma solo per protegersi contro eventuali clienti non paganti. Per gli scada... ne ho visti programmati con i piedi, venduti a costi altissimi.. ma girano comunque su windows o linux quindi direi che più che il scada vulnerabile è sempre un problema dell'aministratore di rete che non ha protetto la macchina esposta su internet.
    • Funz scrive:
      Re: ok non sono un esperto
      - Scritto da: Jacopo Monegato
      ma per quanto ho visto normalmente nei
      piccoli/medi impianti i plc non sono collegati ad
      internet, al massimo in rete tra di loro... si
      richiede insomma che ci sia acXXXXX fisico alla
      macchina, anche solo per mandare il segnale di
      stop e reset (FISICI, lo stop e reset via remoto
      si può fare, che io sappia, solo in modalità
      run_p, ed il relativo switch deve essere in
      posizione) della macchina dato che il programma
      in esecuzione è caricato in un'area di memoria
      poi protetta da scrittura
      o.OIn aggiunta a quello che è stato già detto, ovvero che sempre più queste macchine sono collegate alla rete (teleservice), non c'è solo l'aspetto di sicurezza contro il sabotaggio, ma anche la possibile fuga di dati aziendali assai importanti tipo cicli di lavoro, dati di produttività, eccetera... finora a nessuno era venuto in mente di fare spionaggio industriale in questa maniera, ma dopo Stuxnet...A proposito di Stuxnet: letture per le vacanze, meglio di un romanzo :Dhttps://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.htmlhttp://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1
      • Pigro scrive:
        Re: ok non sono un esperto
        - Scritto da: Funz
        A proposito di Stuxnet: letture per le vacanze,
        meglio di un romanzo
        :D

        https://www.nytimes.com/2011/01/16/world/middleeas
        http://www.wired.com/threatlevel/2011/07/how-digitHo letto anche io la storia su Stuxnet (wired), una cosa a dir poco fantastica!!!
    • Sky scrive:
      Re: ok non sono un esperto
      Non credo di essere OT se dico che, in rete come "newbie", non ci sono solo i PLC: anni fa amministravo una centrale telefonica Siemens Hicom-390 il cui modem era perennemente connesso alla rete telefonica e la cui utenza era un default a livello nazionale. :/Quando ho visto 'sta cosa son rimasto attonito: chiunque (con un minimo di conoscenza della materia) poteva aprirci la centrale come uno sgombro semplicemente... telefonandoci. :OAl che ho inserito sull'alimentazione del modem in questione uno di quegli aggeggi che si usano per spegnere/riaccendere gli ATM da remoto, comandato da un paio di comandi ad hoc direttamente dal nostro Host: i tecnici Siemens s'XXXXXXXvano da morire (ma i miei referenti diretti sapevano che <b
      dovevano </b
      telefonare prima a ME, perchè abbassassi il ponte levatoio ;)) ma almeno la centrale era salva. :D(trattasi di sicurezza fisica: modem <b
      spento </b
      ;))Però se penso che queste centrali, dato che funzionano molto bene, sono piuttosto diffuse (ospedali, comuni, banche, assicurazioni...) e che nel 99% dei casi hanno il modem online (ed entri direttamente in consolle, come "root")... beh... non so a voi ma a me torna in mente il film degli anni '80 WarGames.
      • bubba scrive:
        Re: ok non sono un esperto
        - Scritto da: Skycito"e la cui utenza era un default a livello nazionale. :/"mhh ossia era un numero noto all'universo mondo italiano? :) dacci qualche indizio in piu :)... sul wardialing ci ho passato svariati anni :P)Cmq bello violento il tuo hack hardware, ben fatto :)
        • Sky scrive:
          Re: ok non sono un esperto
          - Scritto da: bubba
          - Scritto da: Sky
          cito
          "e la cui utenza era un default a livello
          nazionale.
          :/"
          mhh ossia era un numero noto all'universo mondo
          italiano? :) dacci qualche indizio in piu :)...
          sul wardialing ci ho passato svariati anni
          :P)Ma guarda, gli indizi sono anche facili:1) il numero del modem, ovviamente, faceva parte della selezione (interna) della centrale: non è che si comprava (e pagava) una linea telefonica "per i comodi di Siemens".2) una volta che avevi il prompt della centrale, user e password erano "noti (e, presumo, univoci) a livello nazionale".Comprensibilmente (a) non posso scendere in ulteriori particolari e (b) ti lascio il divertimento di scoprire gli uni e gli altri. ;)Posso solo dire che, secondo me, qualsiasi <b
          ex </b
          tecnico di centrali telefoniche Siemens (ed anche altri non-Siemens) potrebbe scatenare una "stuxnet"... altro che.Per dirla tutta: quando presi in mano io la gestione, il mio collega mi consegnò anche un corposissimo faldone dicendomi "sono le modifiche apportate nell'ultimo mese"... o___O <- mia facciaTradotto: se la centrare va GIU' GIU' (nel senso che entrambi i proXXXXXri s'impallano e tocca ricaricare)... poi bisogna riapplicare <b
          A MANO </b
          circa un mese di modifiche... che erano davvero tante (v. la voce "enorme faldone").Ci ponzai un attimo e l'attimo dopo decisi che non esisteva: con le mie (limitate) conoscenze del C, un fantastico 386 (correva l'Anno del Signore 1893...) ed un preziosissimo (e legale) TurboC 1.0, in 2 giorni (tra sviluppo e debug) misi in piedi un "log extractor": di fatto il "coso" leggeva i log (formato testo) della centrale, prodotti dal terminale d'interfaccia su PC, ed estraeva i comandi dati dall'ultimo backup in poi (scartava perfino quelli inutili, tipo i display :D)... oh... 5 MB di testo scannerati in meno di un minuto, su un 386 eh (con la produzione di un reapply-log).A quel punto avevo sotto mano TUTTI i comandi da riapplicare e mi bastava un comando per farlo in batch... perchè non so se è noto ai più ma, quando in un CED va giù l'host operativo hai tutti i sistemisti, programmatori ed utenti degli uffici centrali ed agenzie alle costole (che non è poco) MA quando va giù la centrale telefonica hai tutti i direttori generali alle costole (visto che non possono telefonare vengono direttamente da TE)... che è decisamente peggio! :DIn quei casi è <b
          molto meglio </b
          far vedere che "ci stai lavorando", tranquillo e fiducioso con il terminale che macina comandi, piuttosto che vederti lì, tutto sudato marcio che navighi impazzito in mezzo ad un metrocubo di foglietti. :D
          Cmq bello violento il tuo hack hardware, ben
          fatto
          :)Grazie, mi sembrava l'unica. :D(e creare i comandi ad host, in NCL, alla fine è stata un pò una banalità)
  • Lemon scrive:
    Purtroppo è normale
    Tutti i sistemi "poco" usati hanno gravi falle di sicurezza, principalmente procedurale, in secondo luogo di natura tecnica. L'idea di base è "chi vuoi che faccia un sabotaggio di questo sistema?".Ma scusate, ma quanti di voi hanno fornitori che mettono le stesse password a tutti i clienti? e NON vogliono che i cambi...tanto per dirne una
    • collione scrive:
      Re: Purtroppo è normale
      parliamo di sistemi critici, non possono avere falle del generee l'auditing? paghiamo Accenture, Deloitte, Engineering per cosa? la situazione dei sistemi scada è semplicemente vergognosa
      • Lemon scrive:
        Re: Purtroppo è normale

        la situazione dei sistemi scada è semplicemente
        vergognosaNon li sto giustificando, ho detto solo che è normale. E' altrettanto normale che una qualsiasi soluzione tecnologica nasca per dare delle risposte a problemi reali, solo successivamente ci si preoccupa della sicurezza.Se ci pensi qualsiasi cosa è fatta così, pensa le case di 50 anni fa con quelle di adesso, le automobili senza ABS, airbag ecc ecc di 30 anni fa e quelle di adesso, il TCP/IP come è nato e come si è evoluto (ad esempio IPv6 che supporta nativamente ipsec).Insomma, si inizia a nuotare quando l'acqua arriva al c..o. Se si sa nuotare.
        • HappyCactus scrive:
          Re: Purtroppo è normale
          - Scritto da: Lemon

          la situazione dei sistemi scada è
          semplicemente

          vergognosa

          Non li sto giustificando, ho detto solo che è
          normale. E' altrettanto normale che una qualsiasiAnche perché stiamo parlando di sistemi utilizzati in azienducole anche microscopiche; si pensi che la stragrande maggioranza dei programmatori PLC utilizza un linguaggio derivato da quello CABLATO, in cui AND e OR sono espressi come serie e paralleli di interruttori.Figurarsi capire TCP/IP!Il settore industriale ha una dinamica lentissima, prima che una tecnologia venga sostituita deve passare tanto, ma tanto tempo.
          Insomma, si inizia a nuotare quando l'acqua
          arriva al c..o. Se si sa
          nuotare.E purtroppo la maggioranza non sa farlo.
          • Sky scrive:
            Re: Purtroppo è normale
            E' anche vero che se il problema inizia a sorgere adesso un motivo c'è: fino a qualche anno fa <b
            nessun </b
            controller industriale era "connesso in rete", tantomeno via WiFi: adesso, con l'avvento della rete (LAN, intranet ed internet) anche nel mondo industriale, si hanno le stesse problematiche che ritroviamo nel resto della rete... con la differenza che, ad esempio, un dev team come quello di Apache è abituato a pensare in termini di falle e compromissioni, mentre un ingegnere che progetta un PLC il 99% lo vede come "stand alone": quando sei a posto con la sicurezza <b
            fisica </b
            (e da questo lato mi sa che le aziende sono abbastanza a posto, non fosse altro che non vogliono pagare enormità in assicurazioni e/o danni, usando macchine industriali) il resto conta poco... tranne ora.-----------------------------------------------------------Modificato dall' autore il 05 agosto 2011 18.05-----------------------------------------------------------
          • HappyCactus scrive:
            Re: Purtroppo è normale
            - Scritto da: Sky
            con la
            differenza che, ad esempio, un dev team come
            quello di Apache è abituato a pensare in termini
            di falle e compromissioni, mentre un ingegnere
            che progetta un PLC il 99% lo vede come "stand
            alone": Vero, ma ad un certo punto hanno connesso il prodotto PLC in rete, e lì avrebbero dovuto formare il team. Non è stato fatto, e questo è male.Poi c'è il problema al contorno, quello cioè delle aziende per cui se compri un oggetto (un motore, una camma o un PLC connesso in rete) quello deve funzionare, una volta "messo giù". Ma con la rete ed il software non è mai così.Due sorgenti di problema, insomma!
            quando sei a posto con la sicurezza
            <b
            fisica </b
            (e da questo lato mi
            sa che le aziende sono abbastanza a posto, non
            fosse altro che non vogliono pagare enormità in
            assicurazioni e/o danni, usando macchine
            industriali) il resto conta poco... tranne
            ora.Beh... insomma, non sono molto d'accordo sulla "sicurezza fisica". Non del tutto, almeno.Ma sono sostanzialmente d'accordo con te.
        • collione scrive:
          Re: Purtroppo è normale
          - Scritto da: Lemon
          Non li sto giustificando, ho detto solo che è
          normale. E' altrettanto normale che una qualsiasie su questo ti dò ragione ma come dici tu stesso:"soluzione tecnologica nasca per dare dellerisposte a problemi reali, solo successivamenteci si preoccupa dellasicurezza."questi invece sono coscienti del problema da almeno 15 anni e non fanno un tubola cosa per certi versi ridicola è che parliamo di quei sistemi che più di altri dovrebbero essere protetti
      • Nome e cognome scrive:
        Re: Purtroppo è normale
        Perchè vogliamo parlare della certificazione dei sw in ambito farmaceutico? Una pagliacciata in stile "facciamo una stampa di 3000 pagine di listati e così certifichiamo che il programma non è stato modificato".... oppure gli screenshot per certificare il comportamento dei sistemi... ma per favore.. e si fanno pagare oro. Puoi fargli certificare quello che ti pare se solo sei un po' sgamato.
Chiudi i commenti