Come posso proteggere il mio dispositivo Android?

Scarica applicazioni solo dall’app store ufficiale di Google, Google Play
La maggior parte delle infezioni su dispositivi si propaga scaricando applicazioni da store non ufficiali. Il principale motivo per rivolgersi a tali store risiede nella volontà degli utenti di voler risparmiare il costo delle applicazioni. Tutto questo però potrebbe avere un prezzo ben più alto per gli utenti temerari.

Per evitare di scaricare inavvertitamente le applicazioni andate alla nella sezione Impostazioni->Sicurezza e togliete la spunta alla voce “Origini Sconosciute”, mentre abilitate la il controllo “Verifica Applicazioni.”

Abilita la cifratura dei dati sul dispositivo mobile
La cifratura delle informazioni presenti sul dispositivo è un’opzione fondamentale per proteggere i dati sia nel caso di furto/smarrimento che nel caso in cui un app malevola cerchi di accedervi per rubarli una volta infettato il terminale.

Per abilitare la cifratura dei dati sul dispositivo e presenti sulla scheda mi memoria SD abilitare le voci nel menù Impostazioni-> Sicurezza:

  • Crittografia Dispositivo
  • Crittografia SD Scheda Esterna 

Controlla i permessi assegnati a ciascuna app
Ogni volta che si installa una nuova app è buona norma verificare i permessi che essa richiede. Se un gioco vi chiede il permesso di accedere ai vostri account, agli SMS, al microfono e di accedere ad Internet fate attenzione, una frode potrebbe essere in agguato. I malware tipicamente vi richiedono permessi simili che consentono di ottenere un completo controllo del dispositivo per poi trasferire ad un server remoto i vostri dati.

Per gestire i permessi assegnati alle app accedere alla sezione Impostazioni -> “Gestione Applicazioni”. Potrete visualizzare l’elenco delle app installate ed i permessi che richiedono per l’esecuzione.
Vi suggerisco vivamente di limitare il numero di app allo stretto necessario, maggiore è tale numero e più ampia è la nostra superficie di attacco.

Gestisci con attenzione le connessioni Wi-Fi
Di default i dispositivi Android cercano di connettersi ad ogni rete wireless acceduta in passato ma questo comportamento potrebbe nascondere molte insidie nel caso di reti aperte. Tali reti potrebbero essere state messe in piedi da criminali informatici intenti a rubare le vostre informazioni.

Vi suggerisco di controllare periodicamente la lista delle reti Wi-Fi che sono memorizzate dal dispositivo e cancellare la ricerca di quelle connessioni insicure, ad esempio verso reti aperte.
Per gestire le reti Wi-Fi accedere alla sezione del menù Impostazioni->Connessioni->Wi-Fi 

Proteggi l’accesso al dispositivo con una password robusta
Può capitare di lasciare incustodito il cellulare, per evitare che qualcuno possa utilizzarlo impostare una password di sblocco robusta. Dal menù impostazioni accedere alla voce Schermata di blocco->Blocco schermo e scegliete l’opzione Password.

Abilita il doppio fattore di autenticazione per Google e le applicazioni che implementano tale meccanismo.
Abbiamo discusso a lungo dell’utilità del doppio fattore di autenticazione, abilitare questo meccanismo aumenta notevolmente la sicurezza dei nostri account. Per abilitare la modalità nel caso di Google accedere a questo link.

Configura con attenzione i servizi Google
Di recente si è molto discusso della necessità di limitare il quantitativo di informazioni che si espongono esplicitamente al gestore del servizio, in questo caso Google, per ragioni di privacy e sicurezza. La violazione di un account Google potrebbe fornire un quantitativo impressionante di dati agli hacker, dalle nostre mail sino alla nostra posizione. 

Vi consiglio di prestare attenzione alle seguenti impostazioni

  • Localizzazione:

Accedi alle impostazioni, selezion la voce accesso alla “Posizione” e togli il segno di spunta sulle voci che comprendono la localizzazione tramite GPS o reti Mobili.

  • Ricerche:

Disabilita Google Now che memorizza le tue ricerche. Apri l’app Google  dalla voce di menu Impostazioni e metti ad OFF l’opzione “Google Now”. Disattiva la cronologia delle posizioni.

  • Backup: Gestisci con attenzione le opzioni di backup automatico, per evitare sorprese. Troverete le istruzioni dettagliate a questo link.
fonte: (http://www.techeconomy.it/2014/11/18/come-posso-proteggere-mio-dispositivo-android/)

Shellshock, il ‘bash bug’ che fa tremare la rete: quanto è pericoloso?

C’è chi lo definisce peggiore di HeartBleed e chi, invece, mantiene la calma: scopriamo la natura di questa nuova vulnerabilità

L’ultima volta che il mondo dell’open source è caduto letteralmente nel panico risale ai tempi della scoperta di Heartbleed, un potente bug nel protocollo (e nelle annesse librerie) OpenSSH che ha letteralmente messo in ginocchio server da ogni dove. Oggi la storia si ripete con un secondo bug, “adulto” più o meno quanto un quarto di secolo, che riguarda la shell Bash (o Bourne Again Shell) e prende appunto il nome di bash bug – o di Shellshock, come il simpatico R. Graham l’ha ribattezzato.

Secondo alcuni importanti esponenti della sicurezza, tra cui lo stesso Graham, Shellshock sarebbe addirittura più pericoloso di Hearbleed: la causa è da ritrovarsi al diffusissimo utilizzo della shell bash – sia come applicazione attiva che come applicazione in background da parte di altri programmi – e la semplicità con cui agisce il criterio di sfruttamento della falla.

Prima di farne una pandemia, però, capiamone qualcosa in più!


Cosa è Shellshock?

Shellshock – il bash bug – altri non è che un bug insito nella shell Bash, la “console dei comandi” tipicamente inclusa in quasi tutti i sistemi operativi GNU/Linux-based (incluso Android) e Mac. Sostanzialmente il funzionamento di Shellshock coinvolge la dichiarazione e l’utilizzo di variabili d’ambiente, con un modus operandi che cercheremo di semplificare il più possibile.

In pratica, prima dell’esecuzione di Bash è possibile definire in determinati file - richiamabili anche da programmi esterni – delle variabili, che servono spesso a “semplificare” l’eventuale passaggio dei parametri al programma eseguito tramite bash.

Il problema è nella dichiarazione di tali variabili: se una variabile viene dichiarata sulla stessa riga viene specificato un particolare comando, tale comando può essere eseguito arbitrariamente da qualsiasi applicazione abbia accesso a quella variabile. In parole povere, dichiarando una o più variabili con una particolare sintassi può rendere il sistema vulnerabile.

Se masticate lo scripting bash, il tutto sarà più chiaro con un esempio. Considerate questa dichiarazione di variabile:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Shellshock fa si che Bash intepreti la parte di codice in grassetto (quindi echo vulnerable) come un vero e proprio comando da eseguire, cosa che in condizioni “normali” non dovrebbe succedere.

Infatti, eseguendo questo codice su una versione di Bash vulnerabile, l’output ottenuto è il seguente:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Se invece lo stesso codice viene eseguito su una versione di Bash non vulnerabile, il codice echo vulnerable viene riconosciuto da Bash come una potenziale dichiarazione di funzione e viene ignorato, generando un warning e lasciando la variabile non inizializzata ed il comando non eseguito (comportamento normale).

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

Shellshock è davvero pericoloso come dicono?

Diciamo che non è un gioco da ragazzi usare vulnerabilità del genere e che c’è bisogno del verificarsi di condizioni ben precise – uno script deve essere presente sul sistema con delle dichiarazioni di variabili alterate, pronte per essere usate dal programma comandato da un utente malintenzionato – ma, purtroppo, bisogna ammettere che a causa della diffusione di Bash e dell’interazione imprevista di Shellshock con i vari programmi (innumerabili) che interagiscono con essa il rischio esiste. 

Purtroppo Bash non è soltanto la “classica” shell dei sistemi operativi GNU/Linux based di conoscenza comune come Ubuntu, Debian, Gentoo, Red Hat, CentOS e via discorrendo, ma è presente in tante altre varianti di Linux presenti anche su dispositivi differenti dai PC - come router, NAS, sistemi embedded, computer di bordo, che se obsoleti potrebbero essere davvero a rischio.

Senza contare che, inoltre, Bash è presente anche su Android e su tutti i sistemi operativi Mac.


 

Chi è vulnerabile a Shellshock?

Categorizzare i dispositivi vulnerabili non è possibile, tuttavia esistono diverse linee guida per intuire se si è vulnerabili o meno. Innanzitutto bisogna specificare che le versioni di Bash vulnerabili a Shellshock vanno dalla 4.3 (inclusa) in giù, per cui la prima cosa da fare è indubbiamente aggiornare il proprio sistema operativo all’ultima versione dei pacchetti, se possibile.

Particolare attenzione va posta inoltre in ambiente server: si è comunque a rischio se la versione di Bash installata è inferiore alla 4.3 (inclusa), ma bisogna aprire gli occhi e correre ancor più rapidamente ai ripari, a causa dei danni collaterali potenziali causati da Shellshock, in caso il server esegua:

  • una configurazione di sshd che prevede attiva la clausola ForceCommand;
  • vecchie versioni di Apache che usano mod_cgi o mod_cgid, estremamente vulnerabili se gli script CGI sono scritti in bash o lanciano a loro volta shell bash (ciò non succede invece con gli script eseguiti tramite mod_php, neanche se questi lanciano shell bash a loro volta); tuttavia, i potenziali comandi indesiderati vengono eseguiti con gli stessi privilegi d’accesso del server web;
  • server DHCP che invocano script da shell per configurare il sistema; solitamente, tali script vengono eseguiti con privilegi di root, il che è estremamente pericoloso;
  • vari demoni o i programmi SUID che agiscono sul sistema con privilegi da superutente utilizzando però variabili settate da utenti non root.

In generale, il sistema può rimanere vittima di qualsiasi altra applicazione che venga eseguita da shell o esegue uno script shell che prevede l’interprete bash – solitamente, tali script iniziano con la dicitura #!/bin/bash.

Ma non finisce qui: purtroppo qualsiasi altro dispositivo obsoleto è a rischio, specie quelli per cui non è prevista la verifica della versione di Bash installata e per cui non sia possibile procedere semplicemente all’aggiornamento. Ancora una volta, ciò rappresenta un rischio ma non è detto che tali dispositivi siano effettivamente exploitabili (ad esempio, è difficile fare in modo che un computer di bordo o un NAS non collegato ad Internet eseguano codice arbitrario).

Per correttezza, è bene specificare ancora una volta che alcune versioni di Android e di Mac OS X sono vulnerabili – ad esempio, Mavericks lo è.


 

Quali dati sono a rischio e come faccio a proteggermi?

Purtroppo, anche se in precise e difficilmente coincidenti condizioni, ad essere a rischio è qualsiasi cosa sia presente sulla memoria del sistema; tenendo comunque conto dei meccanismi intrinsechi di protezione di Bash e di GNU/Linux come l’assegnazione dei permessi d’esecuzione, il margine di rischio potrebbe diventare comunque molto minore.

Prima di preoccuparsi, bisogna verificare se si è effettivamente vulnerabili a Shellshock. Ciò è possibile semplicemente verificando la versione di Bash installata sul proprio sistema: se questa non è precedente alla 4.3 - Bash 4.3.0 e inferiori sono VULNERABILI ma non le versioni successive – allora il vostro sistema non è vulnerabile. 

In caso contrario, se possibile aggiornate Bash ed i pacchetti dell’intero sistema operativo all’ultima versione disponibile, in attesa di un’eventuale patch che dovrebbe comunque essere rilasciata in maniera celere per la maggior parte dei sistemi operativi e dei pacchetti di Bash interessati, a prescindere dalla piattaforma su cui essi sono installati.

Per verificare di essere protetti, aprite una shell bash ed eseguite il test spiegato nella sezione “Cosa è Shellshock”.


 

In definitiva…

Purtroppo Shellshock è un bug che cade come un fulmine a ciel sereno e non è possibile affermare che sia innocuo poiché, come visto fino ad ora, i rischi materiali esistono.

Come vi ho detto all’inizio non bisogna comunque farne una pandemia: se si tratta di sistemi operativi casalinghi, è necessario accertarsi che il proprio OS sia ancora ufficialmente supportato ed aggiornarlo all’ultima versione disponibile, che si tratti di GNU/Linux o di Mac. Stessa cosa per i sistemi operativi server, per i quali ci si aspetta una “correzione” dei pacchetti relativi alle versioni di Bash pari o inferiori alla 4.3 quanto prima.

Discorso differente va fatto per i vari sistemi embedded, per i NAS, per i router o per tutti quei dispositivi non verificabili facilmente: accertatevi di avere installata l’ultima versione disponibile del firmware e, nel caso, contattate il produttore per ulteriori delucidazioni.

Shellshock è purtroppo un bug molto grande, reso enorme dalla diffusione di Bash, tuttavia gli eventuali danni possono essere arginati usando un po’ di prudenza ed attenzione in più.

Purtroppo, come disse il grande Spaf, la verità è soltanto una:

L’unico vero sistema sicuro è quello spento, gettato in una colata di cemento, sigillato in una stanza rivestita da piombo e protetta da guardie.
Ma anche in quel caso ho i miei dubbi.

 

fonte: (http://www.chimerarevo.com/linux/shellshock-bash-bug-terrorizza-rete-quanto-pericoloso-176876/)

Android CyanogenMod e gli SMS cifrati

La più famosa ROM alternativa incorpora la tecnologia TextSecure nelle sue beta. I suoi 10 milioni di utilizzatori potranno godere di comunicazioni riservate

Roma – Le versioni Nightly di CyanogenMod 10.2, vere e proprie beta del più noto firmware alternativo compatibile con un gran numero di device Android, incorporano ora la tecnologia TextSecure per la cifratura dei messaggi. In questo modo gli utenti che decideranno di installare questo firmware sul proprio smartphone potranno usufruire di un meccanismo anti-sorveglianza per le proprie conversazioni scritte, che offre maggiori garanzie anche in caso di furto o smarrimento del telefono.

TextSecure utilizza l’algoritmo di cifratura Open WhisperSystems per tenere al sicuro le conversazioni in locale, una tecnologia in ascesa (acquisita da Twitter tempo addietro). Può sostituire completamente la app per gli SMS sullo smartphone, e se la controparte dispone a sua volta di TextSecure può anche garantire un canale cifrato di trasmissione del testo a prova di intercettazione (manca ancora nell’attuale implementazione una segnalazione puntuale nel caso in cui la comunicazione non sia sicura). Essendo TextSecure basato su tecnologia open source, in linea teorica è anche possibile accertare la qualità della cifratura andando a controllare il codice alla ricerca di possibili backdoor.

L’idea di introdurre una funzione di questo tipo all’interno di CyanogenMod è ovviamente un tentativo di offrire tramite la ROM alternativa capacità altrimenti non disponibili di serie dentro Android: in questo modo CyanogenMod diventerebbe una sorta di firmware per gli utenti più esigenti in cerca di funzioni avanzate, a completamento di un’offerta che si è fatta sempre più raffinata dalla prima versione e più ampia di quella offerta dal “normale” Android KitKat. Lo sviluppo di quest’ultimo ha subito nelle ultime ore una insolita accelerazione, con la pubblicazione del secondo aggiornamento in poche ore: la release 4.4.2 in distribuzione serve a sistemare alcuni problemi con la segreteria telefonica e a perfezionare le rinnovate qualità fotografiche appena ottimizzate in ottica Nexus 5. (L.A.)

Luca Annunziata, Punto Informatico – http://www.punto-informatico.it

http://punto-informatico.it/3953456/PI/Brevi/cyanogenmod-sms-cifrati.aspx