BlueBorne, milioni di dispositivi Bluetooth sono vulnerabili

Rivelato da Armis Lab, tale vettore di attacco può permettere ad un malintenzionato di prendere il controllo di PC, smartphone e dispositivi IoT, sfruttando vulnerabilità implementative sul protocollo Bluetooth. Di seguito la nostra analisi tecnica

Roma – I ricercatori della californiana Armis (Palo Alto) hanno rilasciato un white paper che descrive otto vulnerabilità (per i quali sono disponibili exploit) riguardanti le implementazioni dello standard Bluetooth in Linux (e Android), Windows e iOS.

Raggruppate sotto il nome di BlueBorne (da Bluetooth e Airborne, termine che identifica gli attacchi effettuati per via aerea), sono caratterizzate da una superficie di attacco molto vasta e un impatto potenziale elevato: oltre a influenzare gran parte dei sistemi operativi presenti sul mercato, gli eventuali attacchi non richiedono interazioni con la vittima ; tali vulnerabilità, inoltre, consentono la possibile esecuzione di codice arbitrario e non sono risolvibili con modifiche alle configurazioni .

Common Vulnerability Exposure CVE-2017-1000251
Si tratta di una remote code execution su Bluez , il componente del kernel Linux che fornisce le funzionalità relative alla gestione di periferiche Bluetooth. La vulnerabilità, causata da un buffer copiato senza controllarne la dimensione nell’implementazione del livello L2CAP dello stack, colpisce le versioni più recenti del kernel (dalla 3.3-rc1 in poi) .

L2CAP è il livello di rete dello stack protocollare di Bluetooth, che offre anche funzionalità avanzate generalmente collocabili nel livello di trasporto (ad esempio la possibilità di gestire la frammentazione dei pacchetti e di gestire politiche QoS).
La comunicazione avviene su più canali logici asincroni, contrassegnati da un Channel ID, l’equivalente di un numero di porta per le connessioni TCP o UDP.
Tutti gli altri servizi (RFCOMM per le comunicazioni seriali, SDP per la discovery dei servizi nell’area circostante, OBEX per il trasferimento dei file) eccetto il servizio Audio sono costruiti sopra al layer L2CAP.
Nello stabilire una connessione L2CAP i due peer possono negoziarne i parametri mediante lo scambio di pacchetti di tipologia L2CAP_ConfReq (richiesta) e L2CAP_ConfResp (risposta) o tramite la funzionalità EFS (Extended Flow Specification).
In tal caso ciascuno dei peer effettua una validazione dei parametri prima di inviare il segnale di conferma per stabilire la comunicazione; nel frattempo, lo stato del peer è PENDING.

È proprio qui che sopraggiunge la vulnerabilità: all’arrivo di una richiesta di configurazione, la funzione l2cap_parse_conf_rsp riceve in input un buffer ( void *rsp ) e la sua grandezza ( int len ); scompone quindi il contenuto del pacchetto, lo valida e ricompone il pacchetto di risposta.
La dimensione del buffer di risposta, però, non è specificata nella funzione. Il contenuto del pacchetto, inoltre, può contenere dati duplicati e concede all’attaccante di manipolare a proprio piacimento sia la dimensione del buffer che i dati contenuti.

La funzione, invocata da l2cap_config_rsp quando il dispositivo è nello stato PENDING , può essere triggerata inviando una richiesta in cui il campo stype assume il valore L2CAP_SERV_NOTRAFIC , in modo da sostituire il buffer buf allocato con dimensione 64 con uno arbitrario e portare a termine il buffer overflow.

I ricercatori fanno notare come molto spesso una vulnerabilità del genere non porti immediatamente a una remote code execution, in quanto possono essere adottate misure di sicurezza nei confronti del codice come le “variabili canarino” (che, se abilitate, vengono posizionate appena fuori della porzione di memoria da proteggere e hanno il ruolo di segnalare eventuali riscritture fuori dal buffer protetto) e la randomizzazione del kernel space (KASLR); questo, però, non viene spesso applicato soprattutto in dispositivi con quantitativi di memoria limitati.

L’impatto della vulnerabilità, inoltre, è alto poiché il codice iniettato viene eseguito direttamente in kernel-space.

Di seguito un video illustrativo dell’attacco:

CVE-2017-1000250
Tale vulnerabilità consiste in un possibile leak di informazioni su BlueZ dato da una lettura out-of-bound nell’implementazione, questa volta, del protocollo SDP.

SDP, come precedentemente anticipato, è il componente per la discovery dei servizi offerti dai dispositivi bluetooth nelle vicinanze, censiti tramite un meccanismo basato su identificatori univoci sulla base della tipologia di servizio. Anche tale meccanismo è basato su un approccio domanda-risposta; inoltre definisce un metodo di frammentazione proprietario, denominato nella specifica protocollare “SDP continuation”, che, qualora il messaggio inviato risultasse di dimensione eccedente rispetto all’MTU negoziato dal sottostante L2CAP, duplica il messaggio appendendovi un tag denominato “continuation state”, il cui valore è contenuto nel frammento di risposta ottenuto inizialmente.
Non è ben chiaro perché sia stato implementato un simile metodo di frammentazione, ulteriore alla segmentazione di L2CAP, sta di certo che la sua implementazione in BlueZ presenta qualche problema.

Nel demone bluetoothd di bluez (eseguito in userspace), è presente un errore nella validazione del campo maxByteSent del continuation state (che l’utente può tranquillamente manipolare) che può causare un buffer overflow nell’esecuzione della funzione memcpy, fornendo la possibilità all’utente di leggere dati dallo stack analogamente a quanto accade per l’exploit Heartbleed di SSL.

CVE-2017-0785
Tale vulnerabilità è analoga alla precedente – ancora una volta sull’implementazione di SDP – tuttavia il bug è di natura diversa. Nell’SDP server di Android, la CVE-2017-1000250 non è sfruttabile, a causa del fatto che la frammentazione è implementata in maniera leggermente diversa: è presente un campo cont_offset che contiene l’offset del record SDP inviato per ultimo nel pacchetto.

All’interno del codice, questo valore viene sottratto al numero di record SDP totali ( num_rsp_handles ), per determinare quelli rimanenti da trasferire, memorizzati in rem_handler , di tipo uint16 .

Il valore num_rsp_handles è ovviamente determinato per ogni ricerca, ma a differenza di cont_offset è dichiarato fuori dallo scope della funzione e rimane sempre lo stesso durante la lettura dei vari frammenti. L’implementazione ha come presupposto, quindi, che sia num_response_handles e cont_offset siano riferiti alla stessa risposta effettivamente inviata.

Un attaccante può pertanto creare una situazione di confusione effettuando una ricerca SDP su un servizio, nella risposta (la cui dimensione sarà pari all’MTU della connessione, negoziato su decisione dell’attaccante stesso) otterrà un continuation state che allegherà in una successiva scansione SDP su un servizio differente, la cui risposta sarà di dimensione inferiore.
A questo punto rem_handles , di tipo unsigned, assumerà un valore negativo e andrà in underflow assumendo un valore molto alto se considerato in complemento a due.
Il ciclo successivo, il cui compito è quello di copiare i record trovati nella risposta, avrà un numero di iterazioni molto elevato ed andrà a leggere (ed includere nella risposta stessa) porzioni di memoria fuori dal buffer.

CVE-2017-0781 e CVE-2017-0782
Trattasi entrambe di remote code execution su Android incluse nella gestione del protocollo BNEP (Bluetooth Network Encapsulation Protocol), utilizzato per costruire reti PAN (Personal Area Network) e consentire l’incapsulamento di pacchetti Ethernet in L2CAP.
BNEP supporta sia il trasporto di frame Ethernet (MTU di 1500 bytes) che il trasporto di messaggi di controllo, utili a negoziare la creazione della PAN e alla gestione dei flussi. È possibile includere più messaggi di controllo all’interno dello stesso pacchetto L2CAP, mediante l’utilizzo di “header estesi”. Entrambe le vulnerabilità in oggetto riguardano proprio questo aspetto.

La conseguenza della gestione di più header estesi in una volta sola, consiste nel fatto che la connessione può cambiare di stato tra la gestione di uno header e l’altro.
Alcuni di questi, tuttavia, possono essere trattati solo quando la connessione è in uno stato specifico; per gestire tale problematica gli sviluppatori di Android hanno deciso di tenere in memoria la parte del messaggio non ancora trattata per effettuarne il parsing nel momento opportuno, memorizzandola in p_pending_data (tipo BT_HDR , di dimensione 8 byte).
Tale campo è memorizzato nello heap, ed ha lunghezza rem_len (che contiene la dimensione dei dati rimanenti del quale non è ancora stato effettuato il parsing, ed il valore può essere controllato dall’utente agendo sulla dimensione del pacchetto inviato). Successivamente viene effettuato il memcpy della zona di memoria partendo dall’indirizzo di p_pending_data+1 , utilizzando rem_len come dimensione. Ciò dà luogo alla prima vulnerabilità: memcpy corrompe lo heap ogni volta che il codice viene eseguito. Il buffer overflow può essere scatenato inviando un pacchetto così formato:

Il campo type è composto dal bit extension_present , che assume valore 1, e dal tipo di frame segnato come BNEP_FRAME_CONTROL (01). Il campo ctrl_type è impostato a BNEP_SETUP_CONNECTION_REQUEST_MSG , per raggiungere la porzione di codice vulnerabile. len viene impostato a 0, per manipolare il campo rem_len , mentre il campo Payload conterrà i byte da iniettare nel buffer.

La seconda vulnerabilità è di nuovo un underflow che risiede nella funzione bnep_process_control_packet , il cui compito è quello di elaborare i pacchetti di controllo e gli header estesi, al fine di riconoscere eventuali sotto-messaggi del messaggio BNEP principale. L’intero rem_len è definito, ancora una volta, come unsigned short a 16 bit.

Manipolando il valore di ext_len (8 bit, unsigned), è possibile mandare in underflow rem_len sfruttando il complemento a due così da fargli assumere valori sull’ordine di 0xff00 . Il valore di tale variabile verrà poi utilizzato per assegnare la grandezza al buffer p_buf ( pbuf->size ), che verrà passato ai layer protocollari sottostanti. Questi si troveranno a gestire un buffer esageratamente grande, che non verrà più controllato e sarà passato alla funzione memcpy così com’è. Il contenuto effettivamente copiato con memcpy non è sotto il controllo dell’attaccante, ma è possibile, in tal caso, realizzare un attacco di tipo heap spray.

Per scatenare l’attacco è possibile inviare un pacchetto così formato:

Il campo type indica BNEP_FRAME_COMPRESSED_ETHERNET , con flag extension_present settato.
ext_len contiene il valore controllato dall’attaccante per causare l’underflow della variabile rem_len . control_type ha valore 0x10 per raggiungere la porzione di codice vulnerabile. Raggiungendo l’underflow, rem_len verrà copiata in pbuf->size che, passato al layer sottostante, chiamerà la callback che eseguirà la memcpy .

Entrambe le vulnerabilità possono causare l’esecuzione di codice remoto, con i privilegi del servizio Bluetooth ( com.android.bluetooth ).
Tale servizio ha privilegi di accesso al filesystem e controllo completo dello stack di rete a basso livello, può simulare input ed è gestito dal demone Zygote che, anche in caso di crash, ne ripristina l’esecuzione; questo concede all’attaccante di effettuare infiniti tentativi di intrusione.

CVE-2017-0783 e CVE-2017-8628 Bluetooth Pineapple Logical Flaw (Android e Windows)
Tali vulnerabilità consentono di effettuare attacchi man-in-the-middle . La prima, per Android, riguarda le versioni del sistema operativo compilate prima del 9 settembre: Google ha infatti rilasciato la patch per tali vulnerabilità nello scorso security bulletin. La seconda, per Windows, riguarda tutte le versioni del sistema di Redmond comprese tra Windows Vista e Windows 10. Curioso, in tal senso, è il fatto che la stessa tipologia di vulnerabilità sia presente su due sistemi operativi che non hanno nulla in comune; si tratta infatti di un difetto di design dovuto dalla complessità dello stack protocollare, che ha portato gli sviluppatori a seguire fedelmente le specifiche.

In particolare è stata rilevata un’incorretta gestione dei livelli di sicurezza richiesti dal profilo PAN, utilizzato per la costruzione di Personal Area Network così da permettere al protocollo Bluetooth di offrire alcuni servizi di rete come il tethering della connessione Internet.

#define PAN_SECURITY (BTM_SEC_IN_AUTHENTICATE | BTM_SEC_OUT_AUTHENTICATE | BTM_SEC_IN_ENCRYPT | BTM_SEC_OUT_ENCRYPT)

Il livello di sicurezza richiesto è soddisfatto anche solo con BTM_SEC_IN_AUTHENTICATE attivo, senza effettuare autorizzazioni successive.

Gli attacchi sono basati sull’assunzione che l’autenticazione Bluetooth, effettuata tramite il protocollo SMP (Security Manager Protocol) siano facilmente bypassabili. L’attaccante può quindi accedere a profili e servizi per i quali il livello di sicurezza richiede esplicitamente l’autenticazione con uno sforzo piuttosto minimo (specialmente su Android, sfruttando la funzionalità “It Just Works”).

Passando i parametri di autenticazione, l’attaccante è in grado di attivare una connessione BNEP ed avviare una connessione PAN dichiarando i ruoli di entrambi i peer. Egli assumerà il ruolo PANU, il ricevente NAP; tuttavia, nel momento in cui il dispositivo ricevente si accorgerà di non poter offrire la funzionalità di tethering, la connessione verrà interrotta. Poiché, tuttavia, i ruoli sono decisi da chi inizia la connessione, possono essere effettuati vari tentativi come illustrato nella seguente matrice:

Invertendo i ruoli, l’attaccante può assumere il ruolo NAP e il ricevente PANU, così da mandare a buon fine la connessione; la vittima sarà quindi in rete con l’attaccante, il quale potrà inviare configurazioni di rete malevole tramite il protocollo DHCP.
Tale attacco è di facile attuazione ed ha un potenziale molto elevato e, soprattutto, non richiede interazione con la vittima. Esso è assimilabile al WiFi Pineapple, perpetrabile soltanto nel caso in cui la vittima sia connessa ad una rete WiFi aperta.

Di seguito il video dell’attacco Pineapple su Windows:

CVE-2017-14315
Questa vulnerabilità riguarda il mondo Apple, coprendo le versioni di iOS precedenti alla 10 e di Apple TV OS precedenti alla 7.2.2. Il protocollo interessato è il “Low Energy Audio Protocol” (LEAP), realizzato da Apple per interconnettere gli auricolari e l’apparato Siri Remote tramite la funzionalità Low Energy introdotta con la versione 4 delle specifiche protocollari Bluetooth.
Nonostante il protocollo sia destinato al solo uso da parte di dispositivi audio di tipo low energy, è di fatto utilizzabile anche con dispositivi classici. Per funzionare, LEAP utilizza 2 specifici Channel ID: 0x2A per le operazioni di controllo della comunicazione e 0x2B per il flusso audio. Le operazioni di validazione controllano soltanto questi due parametri, inoltre i meccanismi di sicurezza di L2CAP non sono supportati, e il traffico dati non è autenticato. I pacchetti audio vengono gestiti da una callback (audio_handler_callback) nella quale è invocata la funzione memcpy senza controllare la dimensione del buffer, provocando un possibile buffer overflow.

Secondo gli esperti di Armis, tale vulnerabilità deriva dall’assunzione che i pacchetti siano sempre grandi 0x68 bytes, come da specifica protocollare; situazione che si verifica sicuramente per le connessioni BLE ma non per le connessioni classiche.
La vulnerabilità non risulta però presente per le versioni attuali dei sistemi operativi di Cupertino, pertanto rimane valida solo per i dispositivi non ancora aggiornati almeno ad iOS 10.

In conclusione
BlueBorne arriva come ennesimo set di vulnerabilità Bluetooth; prima del rilascio delle specifiche protocollari della versione 2.1, infatti, molte erano le problematiche di sicurezza di tale standard dovute a difetti di progettazione. Nessuna di queste, tuttavia, aveva mai riguardato la possibilità di eseguire codice arbitrario.

Armis ha segnalato le vulnerabilità ai principali produttori e alla comunità Linux. Microsoft, avvisata ad aprile, ha rilasciato i propri aggiornamenti lo scorso luglio; i sistemi operativi aggiornati dopo tale data, hanno pertanto già percepito la patch. Apple è stata avvisata solamente ad agosto, le vulnerabilità non sono presenti nelle versioni attuali di iOS ed Apple TV. Samsung è stata contattata diverse volte, ma non ha mai risposto alla chiamata; diverso invece il feedback da parte di Google e della comunità Linux: la patch per Android è arrivata da Mountain View nel security bulletin di settembre, per quanto riguarda il kernel Linux, invece, la segnalazione della vulnerabilità è stata ricevuta dal team di sicurezza il 5 settembre e i manutentori delle varie distribuzioni stanno rilasciando gli aggiornamenti dal 12 settembre (si veda ad esempio il bollettino di Red Hat ).

Su Android, gli utenti possono eseguire questo scanner per verificare la presenza della vulnerabilità sul proprio dispositivo.

È buona pratica, pertanto, tenere i software costantemente aggiornati ma, come noto, ciò non sempre può corrispondere alla realtà dei fatti: per ragioni di obsolescenza programmata, difficoltà di erogazione degli aggiornamenti su determinate categorie di dispositivi, device che hanno raggiunto la end-of-life , inadempienza degli utenti, rimarranno numerosi i dispositivi “in-the-wild” che non riceveranno mai una patch. Per tali dispositivi occorre rinunciare alle funzionalità Bluetooth, almeno quando non strettamente necessarie.

Patrizio Tufarolo

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

  • Non ho capito scrive:
    Ma perchè?
    Perchè la telefonia mobile è autorizzata a fatturare 28gg e la fissa no?Cioè, lo so AGCOm ha stabilito cosi o lo ha permesso....ma perchè?Motivo che il mobile si e fisso no? (compresi servizi tipo Sky, gas e luce penso)
    • Pianeta Mobile scrive:
      Re: Ma perchè?
      Perché sì. :@
    • nushuth scrive:
      Re: Ma perchè?
      la motivazione sta nelle regole per poterl attuare la tariffazione a 28 giorni.sul mobile puoi/devi essere avvertito tramite SMS dell'imminente addebito.siccome per il fisso non è possibile avvertirti, e dunque perdi il conto di quando verrà addebitata la tariffa, si è deciso di vietare la pratica per maggiore trasparenza.per lo stesso motivo se hai l'addebito del moble slla bolletta del fisso, deve prevalere l'addebto mensile per tutte e due le linee.sinceramente trovo che la pratica più scorretta la sta mettendo in pratica SKY: la publbicità (in TV, ma anche nei chioschetti dei centri commerciali) parla ancora di "prezzo mensile". peccato che da ottobre è gia deciso il passaggio a quatto settimane.... in pratica con la prima bolletta "mensile" ti arriva anche la notifica del cambio fatturazione..
  • FasoTutoMiD ioCan scrive:
    CoopVoce
    CoopVoce che ha la stessa copertura di TIM utilizzandone la rete: 1) Fattura mensile da sempre2) La sim rimane attiva 2 anni dall'ultima ricarica3) Servizi di base gratis4) Altra roba che adesso non ricordo ma a me basta e avanza questo.FanXXXX a tutti gli altri
    • user_ scrive:
      Re: CoopVoce
      - Scritto da: FasoTutoMiD ioCan
      CoopVoce che ha la stessa copertura di TIM
      utilizzandone la rete:


      1) Fattura mensile da sempre
      2) La sim rimane attiva 2 anni dall'ultima
      ricarica
      3) Servizi di base gratis
      4) Altra roba che adesso non ricordo ma a me
      basta e avanza
      questo.

      FanXXXX a tutti gli altriIo ho la sim postemobile solo per le telefonate e sms, non per internet mobile e rimane attiva 12 mesi +30 giorni dopo l'ultima ricarica. ogni anno per farla rimanere attiva, sposto 1 solo euro da poste pay a postemobile usando l'app dallo smartphone android ed è l'unica ricarica che faccio in un anno perchè lo uso poco. non conosco la tariffa per internet mobile 4g.Te usi internet mobile con quella sim Coopvoce ? Ne sei soddisfatto ?-----------------------------------------------------------Modificato dall' autore il 15 settembre 2017 17.31-----------------------------------------------------------
      • FasoTutoMiD ioCan scrive:
        Re: CoopVoce
        Si, internet funziona bene.Io uso il 3G, il 4G è disponibile ma, al momento, a me non interessa.Mio suocero, che usa il cell praticamente solo per ricevere, aveva TIM e buttava 10 euro al mese.Da quando l'ho fatto passare a CoopVoce senza nessuna opzione attiva si tiene in tasca 120 euro l'anno.Adesso anche mia suocera vuole sapere come funziona 'sta CoopVoce... (le donne arrivano sempre dopo) :DIn XXXX alla TIM
        • mica tont scrive:
          Re: CoopVoce
          In XXXX alla Tim mica tanto: guadagnano sia con il proprio "parco clienti" che con quello degli operatori virtuali.
        • Passpartout scrive:
          Re: CoopVoce
          Fastweb 100 (1,95/4 settimane per chi non ha servizi fissi Fastweb, altrimenti 0.95).Fatto per il babbo.Usa la rete di TIM.Ho dovuto sollecitare via social l'invio della SIM dopo aver fatto l'abbonamento online. Addebito su C/C o carta di credito.
  • interceptor scrive:
    Entità sanzioni?
    L'articolo non lo dice.Ma è importante in quanto se la multa è di un importo ridicolo (e ridicolo per queste entità, può essere anche qualche centinaia di migliaia di euro), il guadagno di mantenere la tariffazione a 28gg supera la multa irrogata.Un po' come la pubblicità ingannevole: fare uno spot che poi verrà sanzionato porta molti più introiti della multa stessa.PS: che bella la funzione di refresh automatica della pagina che ti cancella ciò che stai scrivendo.Ma PI ha solo utenti che scrivono 3 righe?BAH!
    • ... scrive:
      Re: Entità sanzioni?
      - Scritto da: interceptor
      PS: che bella la funzione di refresh automatica
      della pagina che ti cancella ciò che stai
      scrivendo.
      Ma PI ha solo utenti che scrivono 3 righe?
      BAH!Ecco, adesso nonostante tu sia riuscito a scriverlo ti censureranno il messaggio perché ti sei lamentato del refresh.
    • user_ scrive:
      Re: Entità sanzioni?
      prima clicca su Forum (visualizzazione classica)
    • panda rossa scrive:
      Re: Entità sanzioni?
      - Scritto da: interceptor
      PS: che bella la funzione di refresh automatica
      della pagina che ti cancella ciò che stai
      scrivendo.
      Ma PI ha solo utenti che scrivono 3 righe?
      BAH!No, PI ha solo utenti che sanno configurarsi il browser.
  • Carlo scrive:
    Io pago fastweb e fastweb paga la multa.
    Alla fine dei giochi i miei soldi per queli 2 o 3 giorni non goduti chi se li pappa?Io no di certo!Sarebbe stato più giusto dire: o restituisci i soldi o ogni 28 giorni la cifra da restituire ai tuoi clienti si raddoppia.Vedi come filavano.
    • Carletto scrive:
      Re: Io pago fastweb e fastweb paga la multa.
      - Scritto da: Carlo
      Sarebbe stato più giusto dire: o restituisci i
      soldi o ogni 28 giorni la cifra da restituire ai
      tuoi clienti si raddoppia.
      Vedi come filavano.Filare? Col cavolo... avrebbero semplicemente aspettato che l'entità della multa raggiungesse quella dei profitti derivanti dai 28 giorni, il che potrebbe anche significare anni viste le cifre in ballo.
      • Hisashi scrive:
        Re: Io pago fastweb e fastweb paga la multa.
        - Scritto da: Carletto
        Filare? Col cavolo... avrebbero semplicemente
        aspettato che l'entità della multa raggiungesse
        quella dei profitti derivanti dai 28 giorni, il
        che potrebbe anche significare anni viste le
        cifre in ballo.Poco pratico delle potenze di due, eh ? Dopo otto mesi già dovevano restituire 256 volte il rimborso iniziale...
        • Carletto scrive:
          Re: Io pago fastweb e fastweb paga la multa.
          - Scritto da: Hisashi
          Poco pratico delle potenze di due, eh?
          Dopo otto mesi già dovevano restituire
          256 volte il rimborso iniziale...E quindi? Tutto dipende sempre dall'entità della multa iniziale in rapporto ai profitti finali.Se, per esempio, i profitti sono 1.000.000.000 e la multa è 10. Poco cambia che dopo 8 raddopi sia diventata 10*256=2560. I profitti sono ancora ben lungi dall'essere intaccati.Andrebbe poi anche chiarito quale tipo di raddoppio mensile s'intendeva. Ogni mese si raddoppia a partire sempre dalla stessa multa iniziale, oppure dal risultato del raddoppio mensile precedente? Perché non sono ovviamente la stessa cosa...
          • AdessoBasta scrive:
            Re: Io pago fastweb e fastweb paga la multa.
            Stai fuori? Se consideri un introito di 1.000.000.000 questo viene realizzato partendo da un certo numero di clienti. Se consideri un media di 10 euro pagati ogni 28 giorni hai 10 euro per 13 rate ottieni un numero di clienti pari a 7.692.300 e rotti. Una multa di 10 euro raddoppiata per 8 menislità fa 1.280 euro non 2.560 ma che moltiplicate per i 7.962.300 clienti fa 10.191.744.000. Conviene ancora come dici tu?
  • Epoch scrive:
    fisso o Mobile?
    Più leggo articoli in merito e più mi convinco che non si capisce una cosa...Si parla di telefonia in genere o solo telefonia fissa, lasciando fuori il mobile?Perché a me sembrqa che il mobile, sia assodato e vada bene così...
    • e16cf6157cf scrive:
      Re: fisso o Mobile?
      - Scritto da: Epoch
      Più leggo articoli in merito e più mi convinco
      che non si capisce una
      cosa...
      Si parla di telefonia in genere o solo telefonia
      fissa, lasciando fuori il
      mobile?
      Perché a me sembrqa che il mobile, sia assodato e
      vada bene così...https://www.agcom.it/documents/10179/7141047/Delibera+121-17-CONS/4be36f4c-3198-4d27-88ef-98defed6556a?version=1.0 10. Per la telefonia fissa la cadenza di rinnovo delle offerte e della fatturazione deve essere su base mensile o suoi multipli. Per la telefonia mobile la cadenzapuò essere inferiore a quattro settimane. In caso di offerte convergenti contelefonia fissa, prevale la cadenza relativa a questultima.11. Gli operatori di telefonia mobile che adottano una cadenza di rinnovo delle offerte e della fatturazione su base diversa da quella mensile, informano prontamente lutente, tramite linvio di un SMS, dellavvenuto rinnovo dellofferta.
Chiudi i commenti