Fortinet, sospetto di backdoor

Ricercatori identificano una nuova funzionalità nascosta all'interno di una ben nota marca di appliance telematiche, anche se il produttore si rifiuta di classificare il problema come "backdoor" e rassicura: falla chiusa da tempo

Roma – Dopo il clamore suscitato dal caso Juniper , una nuova, presunta “backdoor” è stata individuata dai ricercatori nei firewall di rete sviluppati da Fortinet e basati su FortiOS. Il sistema contiene una password codificata al suo interno sempre valida, denunciano i ricercatori con tanto di exploit , e tale password può essere utilizzata per accedere da remoto ai firewall vulnerabili.

Avendo a che fare con la giusta versione di FortiOS, la stringa contenuta all’interno del sistema (“FGTAbc11*xy+Qqz27”) può servire ad aprire una sessione di accesso remoto (SSH). Su Twitter un ricercatore ha anche postato uno screenshot auto-esplicativo per dimostrare l’efficacia dell’exploit e della password integrata.

Per i ricercatori si tratta dell’ennesima backdoor segreta scovata negli apparati di rete più popolari, ma Fortinet ha ufficialmente negato questa versione con una breve dichiarazione ufficiale : il problema che ora viene alla ribalta era stato individuato e corretto già nel luglio 2014, e nessun soggetto “esterno” all’azienda – diversamente dal caso Juniper – può essere considerato responsabile dell’accaduto.

Il codice dell’exploit funziona sulle versioni di FortiOS comprese tra la 4.3 e la 5.0.7, mentre la release 5.2.3 (o anche la più recente 5.4.0) risulterebbe immune pur continuando a includere la password codificata. Nella migliore delle ipotesi , dicono gli esperti, i firewall Fortinet sarebbero stati vulnerabili in una lunga finestra temporale compresa fra il 2013 e il 2014.

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

  • rico scrive:
    Molestie telefoniche
    Ormai ho capito come prenderli. Ogni volta che mi chiama qualcuno per proporre o minacciare, poso delicatamente la cornetta o lo smartphone a faccia in giù, e lo lascio parlare.Dopo cinque minuti, riattaccano. Feel the sound of silence, asshole!
  • panda rossa scrive:
    Pena capitale!
    Per questa gente ci vuole una punizione esemplare ed esecuzione pubblica.Dei loro soldi non ce ne frega niente: devono pagare con la loro testa!
    • bubba scrive:
      Re: Pena capitale!
      - Scritto da: panda rossa
      Per questa gente ci vuole una punizione esemplare
      ed esecuzione
      pubblica.
      Dei loro soldi non ce ne frega niente: devono
      pagare con la loro
      testa!oppure una cosa piu' sottile... con ognuno di quei $100 restituiti, gli utenti dovrebbero comprarci una seedbox e poi sventolare uno screenshot.... travaso di bile e ricovero assicurato ;)
    • Pianeta major scrive:
      Re: Pena capitale!
      - Scritto da: panda rossa
      Per questa gente ci vuole una punizione esemplare
      ed esecuzione
      pubblica.
      Dei loro soldi non ce ne frega niente: devono
      pagare con la loro
      testa!naaahhhtroppo poco prima un bel periodo di almeno un mese alla gogna... poi se una testa ce la avranno ancora.....
    • linaro inesperto scrive:
      Re: Pena capitale!
      - Scritto da: panda rossaOT, tu che sei utente Linux de sempre, che mi dici di questo?https://bugzilla.kernel.org/show_bug.cgi?id=12309A me succede se infilo un chiavetta USB, a faccio un copia/incolla, seguito da un altro copia incolla*: risultato il sistema freeza completamente finché non finiscono tutti i flush dei dati.Pensavo capitasse solo a me oppure che fosse una roba che avrebbero corretto in un attimo e invece... scopro che 8 anni che è così e non si prospettano fix.Ci sono workaround?*L'OS dice che il primo è finito, in realtà so che sta ancora flushando perché ha cachato lo stream di dati da scrivere, ma io mica posso andare a fare le analisi della cache mentre uso un PC, mi fido dell'OS, ed in ogni caso due copia/incolla contemporanei su una periferica lenta non devono produrre un freeze totale di tutti i file system (compreso quello virtuale montato su RAM che praticamente non ha limiti di velocità!)
      • panda rossa scrive:
        Re: Pena capitale!
        - Scritto da: linaro inesperto
        - Scritto da: panda rossa

        OT, tu che sei utente Linux de sempre, che mi
        dici di
        questo?
        https://bugzilla.kernel.org/show_bug.cgi?id=12309
        A me succede se infilo un chiavetta USB, a faccio
        un copia/incolla, seguito da un altro copia
        incolla*: risultato il sistema freeza
        completamente finché non finiscono tutti i flush
        dei
        dati.Non sapevo di questa cosa: devo approfondire.Ma capita con un DM in particolare o con tutti?
        Pensavo capitasse solo a me oppure che fosse una
        roba che avrebbero corretto in un attimo e
        invece... scopro che 8 anni che è così e non si
        prospettano
        fix.Strano.Devo leggere con calma tutto quell'incartamento.

        Ci sono workaround?Intanto la copia di files, soprattutto se files di grosse dimensioni, e' meglio farla con l'apposito comando e non con un copia/incolla.La questione sembra dovuta al fatto che trattandosi di un device esterno lento, e file molto grosso e il tempo di copia e' piu' lungo.E in questo tempo gli vai ad accodare un altra copia, quando invece il device e' ancora busy.
        L'OS dice che il primo è finito, No, non credo che l'OS dica che ha finito. Sara' il DM che ha messo in background la copia a dire che ha finito.Da linea di comando il cp finisce solo quando ha finito
        in realtà so che
        sta ancora flushando perché ha cachato lo stream
        di dati da scrivere, ma io mica posso andare a
        fare le analisi della cache mentre uso un PC, mi
        fido dell'OS, ed in ogni caso due copia/incolla
        contemporanei su una periferica lenta non devono
        produrre un freeze totale di tutti i file system
        (compreso quello virtuale montato su RAM che
        praticamente non ha limiti di
        velocità!)Il proXXXXX di schedulazione e' lo stesso a prescindere dai devices.Se si freeza lo schedulatore, evidentemente si freeza per tutti i FS.Potrebbe essere codice sviluppato quando le pennette USB erano al massimo di 1 GB, e adesso che ci sono pennette da 128 GB e BDRIP da copiare il problema sta emergendo.
        • linaro inesperto scrive:
          Re: Pena capitale!
          - Scritto da: panda rossa
          Non sapevo di questa cosa: devo approfondire.
          Ma capita con un DM in particolare o con tutti?dubito che capiti sui server di Silicon Valley visto che lì hanno un I/O tale che consuma un HD in poche settimane ;)A me però succede sistematicamente con tre distro live diverse che mi capita di usare. Una è Mint a 64 bit e altre due sono a 32 bit.Ho tantissima RAM, quindi non c'è problema di swap o simili.All'inizio pensavo fosse un problema del mio hardware, ma poi pian piano ho capito che era tutto legato al file system.Può essere che il fatto che booto live peggiori le cose, ma dai commenti dei tizi di cui sopra direi che succede anche a chi ha l'installazione pulita su HD.
          Intanto la copia di files, soprattutto se files
          di grosse dimensioni, e' meglio farla con
          l'apposito comando e non con un
          copia/incolla.questo posso provarlo.
          La questione sembra dovuta al fatto che
          trattandosi di un device esterno lento, e file
          molto grosso e il tempo di copia e' piu'
          lungo.
          E in questo tempo gli vai ad accodare un altra
          copia, quando invece il device e' ancora
          busy.questo è chiaro.Infatti se faccio il secondo copia/incolla dopo un tempo accettabile (quello dei flush reale dei dati, sicuramente), tutto gira senza problemi.
          No, non credo che l'OS dica che ha finito. Sara'
          il DM che ha messo in background la copia a dire
          che ha
          finito.eh certo, ma usando un desktop la finestrella è quello che mi suggerisce l'OS (ok in realtà è l'UI).Ho pensato anche che potrei monitorare la quantità di RAM che è in fase di commit, quando è vicina a zero vuol dire che il flush è finito, ma non è una cosa comoda
          Da linea di comando il cp finisce solo quando ha
          finitoquesto indubbiamente mi eviterebbe accavallamenti, ma nulla toglie che altri processi, di sistema o di applicazioni che ho lanciato, potrebbero scrivere sullo stesso stesso device in cui sto copiando, producendo lo stesso problema.
          Potrebbe essere codice sviluppato quando le
          pennette USB erano al massimo di 1 GB, e adesso
          che ci sono pennette da 128 GB e BDRIP da copiare
          il problema sta
          emergendo.Avevo anche pensato di disabilitare la cache, in questo modo vedrei l'avanzamento (lento ma realistico) di ogni copia...boh, intanto ti ringrazio per la risposta
        • aphex_twin scrive:
          Re: Pena capitale!
          - Scritto da: panda rossa
          Strano.
          Devo leggere con calma tutto quell'incartamento.A passano altri 8 anni .... (rotfl)(rotfl)
Chiudi i commenti