Vai al contenuto

L'NSA (National Security Agency) e la CISA (Cybersecurity and Infrastructure Security Agency) hanno rilasciato un documento su come rendere più sicura una VPN.

Già dal cappello introduttivo al documento si capisce che nel comparto sicurezza c'è ancora tantissima strada da fare visto che le indicazioni mi paiono sostanzialmente suggerimenti di buon senso e se c'è bisogno di ricordarli vuol proprio dire che mancano le basi.

Invece che polemizzare o intristirmi riporto qui quelle indicazioni in modo che siano utili e che diventino presto la norma.

  • Usare prodotti testati e validati presenti in un elenco proprio dell'NSA: in pratica non la VPN che mi ha detto mio "cuggino" ma qualcosa di serio.
  • Usare sistemi di strong authentication come MFA Multi Factor Authentication
  • Applicare subito patch e update
  • Ridurre il perimetro dei potenziali attacchi eliminando tutto quello che in realtà non si usa

In realtà il documento è molto più articolato e presenta diversi altri suggerimenti meno "banali" quindi risulta utile anche a chi ha già predisposto i primi e basilari step di sicurezza

Via Bruce Schneier

Un ricercatore, Josep Rodriguez, ha scoperto alcune vulnerabilità nel protocollo NFC implementato sia nei POS dei negozi che negli ATM (gli sportelli bancomat per intenderci).

Sommando anche altri bug è stato in grado, per un particolare tipo di ATM, di ottenere soldi (jackpotting ATM). Fortunatamente si tratta di una persona responsabile quindi non ha divulgato i dettagli in attesa che gli interessati tappino le falle

Ricordate: aggiornate sempre tutto quello che è aggiornabile. In particolar modo questo suggerimento è valido per le banche che gestiscono gli ATM e le "macchinette" per i pagamenti POS dei negozi.

(Via Bruce Schneier)

Leggo da Bruce Schneier di un talk di Maggie Stone (Google’s Project Zero) sulle vulnerabilità zero day che sono parenti stretti di precedenti vulnerabilità molto simili.

I cattivi dopo aver visto che un loro attacco viene neutralizzato da una patch riescono in breve a scoprire una nuova falla contigua alla precedente e la sfruttano subito. Secondo la Stone questo accade perché le risorse impiegate per risolvere i problemi di sicurezza sono troppo scarse e quindi si limitano a tappare la specifica falla.

In questo modo è facile trovare un buco contiguo al precedente che la patch non copre.

Questa modalità di operare, rincorrendo e riparando i singoli casi, non funziona. Bisognerebbe aggredire la causa principale che porta ad avere tutto quel gruppo di singoli specifici problemi. Si tratta di un investimento iniziale maggiore ma poi non si sarebbe costretti ad inseguire tutti i successivi zero day.

Certo, poi non è che sparirebbero i problemi, ma almeno i cattivi dovrebbero impegnarsi per scoprire una nuova classe di vulnerabilità e i buoni una nuova soluzione per correggere il problema: insomma, la solita caccia del gatto al topo ma sicuramente la sicurezza complessivamente ne gioverebbe.

Image credit Blue Solution Blog

I prezzi che il broker di exploit Zerodium paga per gli zero-day sono in aumento: questo indica che mediamente è più difficile trovare bug gravi perché i prodotti sono scritti meglio che in passato e anche che la domanda di zero-day è in aumento.

Altra informazione interessante è che molte aziende hanno un programma di ricompense per i bug ma quello che pagano è drasticamente meno di quanto pagano i broker che poi, presumibilmente, li rivendono a chi li usa per scopi non leciti.

Via Bruce Schneier, Image credit Blue Solution Blog


Breve post a mo di appunto su come sistemare la vulnerabilità chiamata shellshock in un server Debian 7 Wheezy.
Verificate che sia vulnerabile e scaricate il pacchetto deb come indicato qui.
Inserite temporaneamente il repository di sviluppo (sid) e aggiornate la libreria libc6 come indicato qui. Come detto in un commento anche per me ha funzionato installando libc6 e non libc6-amd64.

Ricordatevi di togliere il repository sid una volta terminato.

Ora che avete il pacchetto libc6 aggiornato potete installare il deb bash scaricato prima: se cercate di installarlo senza aggiornare la libc6 vi segnala errore.

Grandstream GXV3000Qualche giorno fa mi ha colpito la notizia di un problema di sicurezza in un telefono VoIP e avevo notato che veniva spacciato come un problema del protocollo SIP che sta alla base delle comunicazioni voce via internet.

Un azienda australiana ha pubblicato il resoconto di una vulnerabilità nel telefono VoIP Grandstream GXV3000 che permette di chiamare e farsi rispondere silenziosamente attivando così il microfono. In questo modo si può ascoltare quello che succede vicino al telefono ma non solo: mentre è attiva questo tipo di chiamata silenziosa il telefono non può essere usato visto che c'è già in corso una conversazione.

Oltre a spacciare il problema come causato dal protocollo e non dalla implementazione bacata che un produttore fa del protocollo stesso, ho visto parlare di possibili attacchi Denial of Service (DoS) generalizzati. Va bene l'inglesismo ma, come ho scritto sopra, se attivi una chiamata silenziosa il telefono è occupato e quindi non va. Si tratta di una banale conseguenza e, soprattutto, possibile solo su quel particolare modello!

I ricercatori affermano che è potenzialmente possibile che altri modelli di telefoni IP abbiano questo problema e difatti pare siano stati pubblicati i dettagli di problemi simili anche su telefoni IP della Cisco.

Fare di tutta l'erba un fascio e sparare a zero contro il protocollo SIP mi sembra eccessivo. Il Grandstream GXV3000 è stato prontamente sistemato con una nuova versione del firmware e così qualsiasi altro problema simile che potrà capitare.

Nulla è esente da difetti ma mi sento di dire che la telefonia via internet non è meno sicura di quella tradizionale, anzi, se ben impostata è decisamente più sicura.