Il Bug Dell'Anno 10.000 Sui Software (Y10K)

E' vero, sicuramente noi, non saremo ancora in vita per documentarlo inoltre le tendenze tecnologiche suggeriscono che entro l'anno 10.000, è altamente improbabile che una qualsiasi delle tecnologie o software di elaborazione dati siano ancora in uso, tuttavia rimane un problema che oggi presenta delle criticità ed ha risvolti interessanti dal punto di vista informatico.

Vi siete mai chiesti, a livello di software e sistemi, cosa succederà nell'anno 10.000?
In primis va sottolineato che è molto plausibile che i calendari attualmente in uso siano sostituiti da qualcos'altro. Tuttavia, va detto che gli anni a cinque cifre sono già oggi un problema per molti programmi di analisi lungimirante (ad esempio software che esaminano la gestione a lungo termine delle scorie nucleari). Il problema dell'Anno 10.000 (noto anche come problema Y10K) riguarda bug di formattazione e archiviazione del tempo che emergerebbero allo scoccare dell'anno 10.000 (in quanto a cinque cifre). Questo problema può essere visualizzato in Microsoft Excel dalla versione di Office 2013 in poi, che memorizza le date come il numero di giorni dal 31 dicembre 1899 (il giorno 1 è il 1900-01-01). Allo stesso modo, Microsoft Access memorizza le date come il numero di giorni dal 30 dicembre 1899 (il giorno 1 è il 1899-12-31). In entrambe le applicazioni, un valore di 2958465 verrebbe formattato correttamente come "31 dicembre 9999", ma aggiungendo 1 per passare alla data prevista del "1 gennaio 10000" si causerebbe un errore di formattazione; in Excel, ad esempio, verrebbe visualizzato nella cella come una serie di #characters. Inoltre, Excel non può convertire automaticamente stringhe con formato data "12/12/2007" in date, se l'anno supera il 9999.
La Long Now Foundation si è imbattuta in questa limitazione di Excel durante la progettazione dell'orologio da 10.000 anni (la società sta tentando di promuovere l'abitudine nello scrivere anni con 5 cifre: tipo 02018. Ci sarebbe però un discreto problema con l'anno 100.000...).
Il programma open source OpenOffice Calc è in grado di visualizzare correttamente le date oltre l'anno 9999 con anni a cinque cifre, ma almeno dalla versione 2.4 cade vittima del problema dell'Anno 32.768: il "31 dicembre 32.767" è la data più alta disponibile.
Il 32767 è il numero positivo più alto che può essere rappresentato usando un intero con segno a 16 bit, aggiungendo uno a questo valore si provoca l' overflow e Calc interpreta l'anno come un numero negativo grande ovvero il "1 gennaio - 32.768" . Anche Python supporta date da 1 cifra a 4.


DIFFERENZE CON IL MILLENNIUM BUG
A differenza del problema dell'anno 2000, in cui le cifre significative sono state omesse, la risoluzione del problema dell'anno 10.000 non richiede l'aggiornamento dei vecchi record, poiché sono presenti tutte e quattro le cifre significative. Richiederebbe solo che la memorizzazione dei record in decimali sia in grado di memorizzare cinque o più cifre.
Esiste, tuttavia, un potenziale problema con i set di record che fanno uso dell'ordinamento lessicale. Ad esempio, le rappresentazioni di date nell'intervallo 10.000-19.999 apparirebbero interlacciate con le date nell'intervallo 1000-1999 anziché successive all'anno 9999.

Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Nel 1999 non si fece altro che parlare del tanto temuto Millennium Bug che sarebbe accorso allo scoccare della mezzanotte, con l'entrata quindi del nuovo millennio.
TG, film, serie TV, giornali, riviste e qualsiasi mezzo di comunicazione dedicava sempre uno spazio più o meno ampio a questo evento.
L’allarmismo era davvero ai massimi livelli.
Principalmente questo errore risiedeva nel fatto che, per rappresentare le date, diversi software utilizzavano solo due cifre decimali per memorizzare l'anno; tali cifre potevano assumere i valori compresi da "00" a "99", dando per sottinteso, come base di partenza, l'anno 1900.
Quindi al raggiungimento dell'anno 2000, i sistemi avrebbero segnato l'1 gennaio 1900.
Il problema di fondo dell’utilizzo di un numero ridotto di cifre (2 al posto di 4), rappresentava la necessità di utilizzare il numero minore di byte di memoria possibile (del resto la capacità di memoria dei sistemi operativi era molto ridotta, se rapportata a quello di oggi. E non solo perchè poi i software si sono evoluti).
In realtà alcuni problemi comparvero già 12 anni prima ovvero nel 1988, quando un lotto di carne in scatola era stato rifiutato da un supermercato perché sembrava essere scaduto da più di 80 anni.
Quattro anni dopo (nel 1992), Mary Bandar di Winona, nel Minnesota, fu invitata a frequentare una scuola materna perché, secondo il computer, aveva 4 anni.
In realtà ne aveva 104 anni quindi declinò l'invito.
Dal 1951, quando Joe Lyons introdusse i primi computer aziendali, le date come detto erano state abbreviate per risparmiare spazio ed accelerare l'elaborazione: il secolo venne omesso, quindi il gennaio 1900 era 01/00 e il dicembre 1999 era il 12/99, così come è ancora oggi sul fronte di ogni carta di credito.
In realtà quella carne in scatola aveva una data di scadenza del gennaio 2000 e Mary Bandar nacque nel luglio 1888; queste date, 01/00 e 07/88, assomigliavano al gennaio 1900 e al luglio 1988, rendendo la carne scaduta da 88 anni (del resto il fatto successe nel 1988) e la 104enne Maria ringiovanita al punta da esser invitata per frequentare l'asilo nel 1992.


QUALI PROBLEMI PROVOCO' IL MILLENNIUM BUG?
Il costo totale dell'aggiustamento software e sistemi operativi svolti in previsione dell'Y2K è stato stimato di oltre 300 miliardi di dollari (oggi circa 426 miliardi di dollari oggi, presa in considerazione l'inflazione).
IDC ha calcolato che gli Stati Uniti spesero circa 134 miliardi di dollari (190 miliardi di dollari oggi).

Non successero eventi catastrofici/apocalittici come descritti all'avvicinarsi dell'evento, anche se qualche problema accorse, vediamone i principali.

-ci furono problemi nello United States Naval Observatory che gestisce il master clock (ora ufficiale del paese), diede la data sul suo sito Web come 1 gen 1900

-problemi in un centinaio di slot machine nel Delaware, USA

-sempre negli Stati Uniti, il sistema di elaborazione dei messaggi della Guardia costiera venne interrotto

-alla base offshore delle forze aeree a sud di Omaha, nel Nebraska, non fu possibile accedere alle registrazioni delle parti di manutenzione degli aeromobili

-ci furono interruzioni di corrente alle Hawaii

-all'aeroporto nazionale di Reagan, le linee di attesa del check-in si sono allungate dopo che i programmi di smistamento bagagli sono stati colpiti

-in Giappone alcuni sistemi di raccolta di informazioni di volo ebbero diversi problemi

-a Ishikawa, in Giappone, le apparecchiature per il monitoraggio delle radiazioni smisero di funzionare a mezzanotte; tuttavia, i funzionari dichiararono che non c'era nessun rischio per gli abitanti

-la centrale nucleare di Onagawa ebbe qualche problema di raffreddamento, non a caso suonò l'allarme 2 minuti dopo mezzanotte

-ad Osaka, Giappone, una compagnia di telecomunicazioni, ha riscontrato errori nella parte di gestione delle date della rete aziendale. Il problema venne risolto alle 02:43

-NTT DoCoMo , il più grande operatore di telefonia mobile del Giappone, riferì che il 1° gennaio 2000 alcuni modelli di telefoni cellulari stavano cancellando nuovi messaggi ricevuti, anziché i vecchi messaggi, a mano a mano che la memoria si riempiva

-sempre in Giappone, circa il 5% degli erogatori di contanti dell'ufficio postale non funzionò e si ebbero problemi anche negli uffici meteorologici

-a Sheffield, Regno Unito, ci furono valutazioni errate del rischio per la sindrome di Down inviate a 154 donne gravide e sono stati effettuati due aborti come risultato diretto del bug Y2K (errore di calcolo dell'età della madre). Quattro bambini affetti da sindrome di Down sono nati da madri a cui era stato detto che si trovavano nel gruppo a basso rischio (cioè praticamente zero le possibilità che succeda una cosa del genere)

-nel Regno Unito ci furono anche problemi con le transazioni di denaro

-sempre nel Regno Unito, le macchine per le biglietterie automatiche ("Quickfare") stamparono i biglietti con la data "00 JNR 00" per 3 mesi fino a metà marzo 2000. Questi erano incompatibili con gli ATG presso la stazione ferroviaria di Reading

-il sistema missilistico antiaereo del Regno Unito Rapier presentava un errore Y2K che gli avrebbe impedito di sparare

-molti sistemi di carte di credito e bancomat andarono in crash. Alcuni clienti hanno ricevuto fatture con 100 anni di interesse

-la stazione di pompaggio dell'olio a Yumurtalik fallì, tagliando le forniture a Istanbul

-i computer del governo andarono in crash in Cina ed ad Hong Kong

-un cliente di un negozio di noleggio video dello stato di New York si trovò sul conto $ 91.250

-anche in Australia si ebbero problemi con il sistema di convalida dei biglietti dell'autobus

-tribunali in Sud Corea e Spagna che riportavano documenti datati 1900

-in Italia i principali problemi li ebbe la Telecom con alcune bollette che riportavano la data 1900

-in Francia, il servizio nazionale di previsioni meteorologiche, Météo-France, indicò che la data sulla loro pagina Web mostrava una mappa con le previsioni del tempo di sabato "01/01/1900"

-in Bulgaria, i documenti di polizia sono stati emessi con le date di scadenza del 29 febbraio 2005 e del 29 febbraio 2010 (che non sono anni bisestili)

-alcuni software non hanno riconosciuto correttamente il 2000 come anno bisestile e hanno quindi lavorato su un anno di 365 giorni. L'ultimo giorno del 2000 (giorno 366) questi sistemi hanno mostrato vari errori trovandosi sfasati (31 dicembre 2000 e 1 gennaio 2001). In particolare alcuni treni norvegesi si ritrovarono ritardati fino a quando i loro orologi non furono rimessi indietro di un mese

Il Carattere Indiano Che Fa Crashare Gli iPhone

Da qualche settimana, come tutti saprete, un carattere indiano riusciva a crashare l'iPhone.
Il bug in questione si manifestava con il carattere della lingua telugu, parlata dal 5% della popolazione in India.
Se veniva ricevuto o incollato in un campo di testo (anche app del calibro di WhatsApp, Twitter, Instagram, etc), poteva causare il crash delle applicazioni o dell'intero sistema operativo.
Nel momento in cui il carattere in questione veniva visualizzato all'interno di un'app di iOS, questa andava in crash continuando a chiudersi ad ogni riavvio (come un loop infinito).
Nel caso in cui il sistema operativo mobile di Apple avesse provato a mostrarlo attraverso una notifica, sarebbe stato l'intero software di sistema che gestisce la Home a bloccarsi.
Infatti il rischio in questo caso è che iPhone o iPad entrino in un tunnel di continui riavvii e blocchi, dovuto al fatto che il carattere non sparisce mai dalle notifiche non lette.
Dunque, come era lecito attendersi, Apple è intervenuta rapidamente sul problema.
L'azienda di Cupertino infatti, 10 giorni fa, ha rilasciato iOS 11.2.6 e macOS 10.13.3, che "fixano" il problema, poi è stata la volta anche di watchOS 4.2.3 e di tvOS 11.2.6.

La Vulnerabilità KRACK Che Colpisce Il Wi-FI

KRACK è una pericolosa vulnerabilità trovata qualche mese fa nel protocollo di sicurezza WPA2 delle comunicazioni Wi-Fi.
A scoprirla Mathy Vanhoef, principale autore della ricerca e il cui lavoro si basa su una serie di analisi già condotte in precedenza da altre parti circa i punti deboli presenti nei componenti del protocollo WPA2.
Le vulnerabilità individuate da Vanhoef sono state trasformate in codice proof of concept, che hanno permesso di comprendere che qualsiasi dispositivo contenente un modulo di comunicazione Wi-Fi è vulnerabile ad una variante degli attacchi.
Le reti Wi-Fi fanno uso di chiavi condivise basate su cifratura AES per proteggere il traffico di rete. La chiave viene condivisa raccogliendo una serie di "handshake" crittografici che verificano l'identità del client. Gli attacchi che i ricercatori hanno descritto prendono di mira proprio questi handshake crittografici, che sono di vario tipo.
In particolare: 4-way handshake, PeerKey handshake, Group Key Refresh handshake e Fast Basic Servce Set Transition handshake.
Ad esempio l'attacco al 4-way handshake è particolarmente devastante contro Android 6.0 e successive, al punto da riuscire a forzare il client ad usare una chiave di cifratura estremamente prevedibile, fatta di soli 0.
Sistemi Windows e iOS non sono vulnerabili all'attacco 4-way, ma al Group Key Refresh handshake e Fast BSS.
Visto che esistono diverse implementazioni di WPA2, l'impatto di un attacco dipende da quale di queste viene utilizzata per la trasmissione dei dati.
Per le connessioni che usano AES e il Counter con CBC-MAC Protocol, un attaccante può decifrare pacchetti di rete, rendendo possibile leggere i loro contenuti e iniettare altri elementi dannosi nei flussi di pacchetti TCP.
La chiave tuttavia non può essere violata, quindi l'attaccante non può creare ad-hoc una chiave per collegarsi alla rete ma deve usare un access point clonato che usa lo stesso MAC adrress dell'access point della rete presa di mira, usando però un differente canale Wi-Fi.
Per quelli che usano Temporal Key Integrity Protocol (TKIP), il Message Integrity Code key può essere recuperato dall'attaccante.
In questo modo è possibile riutilizzare i pacchetti catturati, oltre che forgiare e trasmettere nuovi pachetti al client preso di mira, mascherandosi da access point.
Se è presente il Galois/Counter Mode Protocol è possibile riutilizzare e decifrare pacchetti, oltre che recuperare la chiave di autenticazione che in questo caso viene usata per proteggere entrambe le direzioni di comunicazione.
Per questo motivo, a differenza del caso precedente, un attaccante può forgiare pacchetti in entrambe le direzioni, accedere quindi alla rete e fingersi client o access point a seconda del tipo di obiettivo prefissato.
Tutto il traffico Wi-Fi fra dispositivi e access point wireless è vulnerabile all'exploit, e in alcuni casi può essere sfruttato anche per manipolare le pagine web introducendo Malware e Backdoor.
Le diverse vulnerabilità scoperte su WPA2 colpiscono in maniera più estesa Android e Linux, dando la possibilità agli aggressori anche di modificare siti web per scopi fraudolenti.
Secondo quanto riportano i ricercatori di sicurezza oltre il 40% dei dispositivi Android (tutti quelli con la versione 6.0 o successive) sono attualmente vulnerabili ad una variante "devastante" dell'attacco che consente di manipolare il traffico fra client e access point.
Una volta installato l'aggiornamento sul proprio computer, smartphone o tablet si è al sicuro?
Una volta aggiornati, i vari client non potranno essere violati utilizzando il metodo KRACK anche se la rete contiene dispositivi compromessi o è lo stesso access point ad essere stato violato.
Rimane tuttavia decisamente importante mantenere al sicuro tutta la rete, quindi sarà opportuno aggiornare i firmware di tutti i router, repeater e client generici connessi via Wi-Fi anche dopo l'installazione dei fix sui sistemi di maggiore importanza.
Le prime a rilasciare patch di sicurezza sono state: Arch Linux, Aruba, Cisco Meraki, DD-WRT, Debian/Ubuntu, Fortinet, Intel, LEDE/OpenWrt, Netgear (per i modelli WAC120, WAC505/WAC510, WAC720/730, WN604, WNAP210v2, WNAP320, WNDAP350, WNDAP620, WNDAP660, WND930), Ubiquiti e Watchguard Cloud.
Se il vostro router è stato aggiornato e non è in questo elenco vi esortiamo a scriverlo nei commenti in modo da aiutare gli altri lettori a proteggersi dalle vulnerabilità. Consigliamo inoltre di consultare periodicamente la pagina dell'US CERT per mantenersi aggiornati sull'evolversi della situazione per i vari produttori.

Cos'è Zerodium? Bug e Zero Day Exploit

Apple tramite hacker di spicco cerca di migliorare la sicurezza di iOS per circa $200.000 a exploit (cioè per ogni falla trovata), Zerodium invece pare gli stia facendo concorrenza offrendo ben 1.5 milioni di dollari a chi parteciperà al rilascio del jailbreak per iOS 10.
Zerodium è una società di sicurezza informatica con sede a Washington fondata nel 2015.
Il loro principale lavoro è di "acquistare" vulnerabilità Zero Day.
Secondo stime la società americana spende dai 400mila dollari ai 600mila in un mese per comprare Exploit.
Già in passato Zerodium si rivolgeva agli hacker di talento, pagandoli svariati milioni, per un rilascio di un Jailbreak similare a quello di JailbreakMe per iOS 9.
La stessa cosa accade quest’anno ma questa volta con iOS 10.
Stando al CEO di Zerodium, Chaouki Bekrar, l’aumento del prezzo offerto agli hacker è dovuto all’aumento della sicurezza introdotta da Apple sul suo sistema operativo mobile.
Ci sono inoltre diverse opportunità per gli hacker per la vendita dei propri exploit, ad esempio il controllo remoto tramite Android 6.x & 7.x, Blackberry OS 10, Windows 10 mobile e vari altri sistemi operativi.
La sfida toccherà quindi anche Android 7.0 Nougat, anche se in questo caso parliamo di “soli” 200.000 dollari.

Le alte e in aumento cifre coinvolte fanno ben sperare circa la sicurezza dei due sistemi operativi, eppure non sono pochi i dubbi sollevati dall’utilizzo che i clienti di Zerodium fanno di tali exploit.
Anche se Zerodium non rivela la vendita dei Jailbreak una volta acquistati, è possibile credere che vengano a loro volta rivenduti a grandi aziende o governi che hanno i soldi per mettere le mani su queste falle di sicurezza.
Per esempio, i governi potrebbero usare questi tool per entrare sui dispositivi crittografati e farne quello che vogliono.

Il Bug Degli iPhone: 1 Gennaio 1970

Gli Smartphone e i Computer, per essere sincronizzati con date ed orari esatti, comunicano con server NTP.
Il riferimento sono le 00:00:00 dell'1 gennaio 1970 (Tempo Unix).
Se uno smartphone viene "impostato" dai programmatori in riferimento a questa data si ritrova a lavorare con un tempo praticamente "zero": ovvero tutte le operazioni matematiche fallirebbero rendendo di fatto il dispositivo inutilizzabile.
La causa del bug è quindi legata alla gestione del timestamp, che per alcune impostazioni dei fusi orari causerebbe una condizione di underflow in grado di mandare in crash il kernel del sistema operativo.
Un clamoroso errore di questo tipo è stato commesso dall'Apple (sino alla versione 9.3 che ha risolto il problema).
I bug riscontrati nei sistemi operativi mobile generalmente causano il blocco di un’applicazione e rallentamenti nelle performance.
Questo citato invece che affligge i dispositivi mini iPad 2, iPad Air, 5S, iPad Touch 2015, 6S e 6S Plus è ben più grave: come detto impostando la data 01/01/1970 nel sistema operativo iOS il dispositivo al successivo riavvio smette di funzionare, senza più dare segni di vita.
Pare che lo stesso bug si sia verificato anche per altre date (in un range compreso tra il primo gennaio e maggio del 1970).


ATTACCHI
Settare la data manualmente oppure in modo fraudolento potrebbe essere quindi molto pericoloso.
Stessa situazione potrebbe verificarsi tramite attacchi da remoto oppure con app opportunamente costruite.
O ancora creando, tramite Hotspot Wi-fi, falsi server NTP settati con quell'ora e data.
Gli iPhone connessi a una rete Wi-Fi del genere si troverebbero catapultati alla data infausta diventando quindi inutilizzabili al primo riavvio.
Sono stati diffusi anche messaggi palesemente falsi come questo:

Che permetterebbe di attivare funzioni retrò del Macintosh (che per inciso nasce più di 10 anni dopo e non nel 1970).

In realtà l'unica cosa che otterrete è il blocco del dispositivo sulla schermata di accensione.

Neanche la modalità di ripristino darebbe una mano.

Fatto il danno, l'unica alternativa è portare lo Smartphone in un centro Apple o aggiornare ad una versione più recente della 9.2

Cos'è Il Tempo UNIX? Date Particolari e Millennium Bug

Il tempo zero dell'Informatica non inizia con la data di nascita di Gesù Cristo o di chi per lui ma dalla mezzanotte di giovedi 1 gennaio 1970.
Non esisteva a quei tempi una data zero e quindi i programmatori la dovevano fissare per ogni file, ogni volta, nel file-system finchè non scelsero una data che potesse andare bene e che non soffrisse di overflow con sistemi a 32 bit, il 1970 sembrò una buona scelta (anche se inizialmente era stato scelto l'1 gennaio 1971).
Detto anche tempo UNIX, esso è come detto utilizzato per i timestamp dei programmi informatici.
In poche parole, esso segna il tempo trascorso in secondi da quella data.
Questo sistema di misurazione temporale è molto usato da sistemi operativi UNIX e può essere facilmente convertito, grazie a un piccolo software, nel tempo universale.
Ma perchè venne scelto il 1970? I sistemi UNIX vennero progettati nel 1969, il primo pubblicato nel 1971 quindi si suppose che nessun sistema informatico avrebbe potuto rappresentare un tempo di sistema prima di questa data.


DATE DA RICORDARE E MILLENNIUM BUG
Questo strano orologio, proprio come il calendario comunemente usato, regala date molto particolari dal punto di vista numerico.
Per esempio, il 9 settembre 2001 è stata la volta dello Unix Billenium, il momento in cui l'orologio si è fermato a 1.000.000.000 secondi.
Il 18 marzo 2005, invece, la cifra ha segnato l’1.111.111.111.
Il 13 febbraio 2009 per un istante si è fermato sulla cifra di 1234567890 secondi.
Per l'occasione sono state organizzate celebrazioni in tutto il mondo e l'evento è stato celebrato anche da Google, con un doodle dedicato.
Mentre il 26 gennaio 2011 è stato il 15.000° giorno dello Unix Time e i festeggiamenti hanno avuto luogo a Bloomington in Indiana (USA).
Il 18 maggio 2033 invece sarà il giorno del secondo Billennium: i 2.000.000.000 di secondi.
Sono molti i sistemi operativi che presentano problemi con date particolari.
A cavallo tra il 1999 e il 2000 si parlò molto del “Millennium Bug”, un problema che si verificò sui computer al cambio di data dalla mezzanotte del 31 dicembre 1999 all’1 gennaio 2000.
Temendo conseguenze catastrofiche, furono da più parti predisposte misure per correggere sistemi operativi, applicazioni, firmware e altri sistemi che lavorano con le date.


LA FINE DEL MONDO
Non sarebbe un vero calendario, tuttavia, se non ci fosse anche una fine del mondo.
Questa è segnata per le 03:14:08 UTC del 19 gennaio 2038, data prevista per il Bug Dell'Anno 2038 (bugY2038).
In questo giorno, infatti, per i sistemi operativi a 32 bit che adoperano questa rappresentazione del tempo scoccherà l'istante in cui i contatori toccheranno il loro valore massimo, l'istante rappresentabile più distante possibile dal 1 gennaio 1970: 2147483647 secondi.
Dall'istante successivo, i contatori registreranno il valore negativo -2147483648, che corrisponderà (sempre a partire dal 1 gennaio 1970) alle 20:45:52 di venerdì 13 dicembre 1901.
In poche parole il numero di secondi trascorsi dall'epoca raggiungerà il valore di 2 alla 31esima potenza, che è al di fuori dei valori rappresentabili da tale tipo di dato.
Tali calcolatori e sistemi operativi potranno quindi riscontrare malfunzionamenti, non essendo più in grado di memorizzare correttamente il valore che indica la data corrente.
Questa festività, anzi Apocalisse, è anche nota come "The Friday 13th Bug".

Scoperto Il Bug No IOS Zone: Come Difendersi

Molti utenti scelgono l'iPhone e gli iPad iOS 8 per la loro presunta sicurezza rispetto ad altri dispositivi.
Tuttavia questo è un falso mito o comunque è stato scoperto un grave bug (No iOS Zone) che affligge questi dispositivi.
Questo bug consente ad un malintenzionato di effettuare un attacco DoS sui dispositivi collegati ad una rete Wi-Fi aperta (“infetta”).
In poche parole si tratterebbe di "router fittizio" (reti/hotspot più precisamente) creati ad hoc che manderebbero in crash i dispositivi.
Funzionerebbe, sotto certi versi, come uno Jammer (inibendo l'uso dello smartphone).


COME AVVIENE L'ATTACCO?
Infatti spesso girando per le strade della città, è possibile scovare reti Wi-Fi a cui appoggiarsi per collegarsi ad internet con l’intento di risparmiare traffico dati oppure semplicemente perché ci troviamo in una zona poco coperta dal nostro operatore mobile.
Secondo quanto dichiarato da Skycure, nota società per la sicurezza mobile, in iOS 8 è stata trovata una falla che potrebbe mandare i tilt l’intero sistema.
Per non cadere nella trappola, viene consigliato di mantenersi alla larga da reti Wi-Fi aperte o, comunque, di dubbia provenienza, denominate per l’occasione “No iOS Zone“.
Se malauguratamente doveste incappare nella trappola, noterete continui riavvii e crash di sistema dovuti alla manipolazione dei certificati di sicurezza SSL, aprendo così le porta per un attacco DoS.
Nella peggiore delle ipotesi, i dispositivi sotto attacco mirato potrebbero addirittura subire danni permanenti, senza alcuna possibilità di ripristino e con la conseguente perdita dei dati, tra cui anche personali.


COME DIFENDERSI
Come proteggersi da un attacco DoS dalle reti “No iOS Zone“?
Come detto, al momento, l’unica soluzione possibile è quella di evitare gli hotspot di cui non si conosce la provenienza.
Il bug verrà sicuramente risolto tramite aggiornamento iOS.
In alternativa è possibile installare Skycure, un app che farebbe da antivirus e permetterebbe d'intercettare le reti malevole.

Corretto Il Bug Di Youtube Scoperto Da Hismatullin

Inviando una richiesta opportunamente modificata al server web di YouTube, un esperto d'informatica russo, tale Kamil Hismatullin, si è accorto di avere in mano gli strumenti giusti per cancellare potenzialmente, uno ad uno, tutti i video ospitati sul servizio di Google.
Trattasi della richiesta POST accompagnata dal parametro “action_delete_live_event” unito agli identificatori “event_id” e “session_token”, tramite ciò era possibile cancellare qualsiasi tipo di contenuto da YouTube senza esserne l’autore.
I tecnici di Google si sono affrettati a correggere questa vulnerabilità di sicurezza che avrebbe potuto portare alla cancellazione di tutti i video hostati sulla piattaforma.
L'esperto russo ha spiegato i dettagli tecnici della vulnerabilità, molto simile a quella rilevata qualche tempo fa in Facebook (Facebook corregge il bug che cancella le foto).
Hismatullin, tuttavia, ha preferito non farlo sebbene la tentazione di prendere di mira il canale di Justin Bieber, musicista che il ricercatore non apprezza per nulla, sia stata davvero grande.
Sulla base della segnalazione responsabilmente inviata ai tecnici di Google, la società californiana ha corrisposto al ricercatore un premio in denaro pari a 5.000 dollari, il massimo previsto in questi casi.
Un bug colossale, comunque, la cui scoperta avrebbe forse meritato una ricompensa maggiore.

Dopo Il Millennium Bug, Arriverà Il Bug Dell'Anno 2038

Passato indenne il Millennium Bug del 2000, c'apprestiamo (o meglio, mancano ancora un po' di anni) a vivere quello del 19 Gennaio 2038.
Però manca ancora un bel po' di tempo eh?
Ad ogni modo a causarlo sarebbero i processori a 32 bit quindi nessun problema per coloro che usano sistemi a 64 bit(per la verità tra una ventina d'anni i computer saranno drasticamente diversi da quelli di ora ed è assolutamente improbabile che si rimanga con questi processori).


BUG 2038
Il problema comunque scatterebbe a una data e un’ora specifica: 19 gennaio 2038 alle 03:14:07 (fuso orario di Greenwich).
Da quel momento in poi, i computer che utilizzeranno ancora sistemi a 32 bit non saranno in grado di stabilire la differenza tra il 2038 ed il 1970 (anno di partenza da cui sono settati gli attuali computer).
I sistemi Unix, infatti, non possono calcolare le date successive al 2038.
Questo perché tengono traccia del tempo utilizzando un intero di 4 byte che rappresenta il numero dei secondi dal primo gennaio 1970.
In pratica, un intero di 4 byte ha un valore massimo di 2.146.483.547: proprio questo tempo (conosciuto come “tempo massimo”) corrisponde al 19 gennaio 2048, ore 3.14.07.
I sistemi Unix, infatti, non erano stati toccati dal Millennium Bug(del 2000), ma ora ne vanno incontro ad un altro.
Il problema è che molte macchine che hanno come sistema operativo Unix/Linux sono quelle che controllano le principali arterie del mondo tecnologico, dall’aeronautica a internet.
Quello che accadrà sarà un semplice “reset” del tempo a 0, quindi al primo minuto del 1970.
Perché proprio 2.147.483.647? I computer misurano il tempo in secondi.
Quindi, 2.147.483.647 sono i secondi compresi nell’intervallo tra il primo gennaio 1970 (Tempo Unix) ed il 19 gennaio 2038 alle 03:14:07.
Il problema è generalizzato perché i processori, anche se di differenti dimensioni e capacità, funzionano tutti allo stesso modo, sia su device fissi sia su mobile.
Alcuni processori potrebbero continuare a funzionare bene con una data sbagliata mentre altri smetterebbero drasticamente di lavorare.


DA COSA è GENERATO IL BUG?
La maggioranza dei sistemi informatici mondiali (anche la stessa “struttura” sulla quale si appoggia internet) è basata su UNIX, il famoso sistema operativo open source dal quale sono derivati Linux e anche i prodotti della Apple.
Il sistema operativo UNIX memorizza le date in un formato definito dallo standard POSIX.
In pratica la data è memorizzata in un numero che rappresenta il numero di secondi a partire dalla mezzanotte del 1° Gennaio 1970, tale data viene anche chiamata “epoca” (The Epoch), per cui ogni secondo che passa, questo numero incrementa di una unità.
Gli orari sono in formato UTC, che corrisponde all’orario GMT (quello di Greenwich insomma).
La data viene memorizza in un numero a 32 bit e i sistemi colpiti saranno quelli che usano la variabile "signed".
Fortunatamente, non tutti i sistemi UNIX utilizzano il tipo signed e usano quindi il tipo unsigned che porta a non avere problemi su queste macchine (o meglio a spostarlo alle 06:28:15 di Domenica 7 Febbraio 2106) .
Un numero a 32 bit di tipo signed prevede che il numero positivo più grande memorizzabile sia 2147483647 che in base al sistema POSIX corrisponde  alle ore 03:14:07 di martedì 19 Gennaio 2038.
Un secondo dopo, come già spiegato, il numero verrà incrementato ancora di 1 e di conseguenza verrà posto ad 1 il bit più significativo di  tale numero(numero negativo).
Per cui facendo due calcoli col complemento a due il numero vale -2147483648 che nella fattispecie viene interpretato dal sistema POSIX come le ore 20:45:52 del giorno Venerdì 13 Dicembre 1901.
Questo fatto causerà enormi problemi in tutti gli ambiti in quanto dopo le 03:14:07 di martedì 19 Gennaio 2038 i sistemi UNIX crederanno di “essere tornati indietro nel tempo” al 1901 con conseguenze catastrofiche dal momento che oramai tutto è gestito da computer e tutto si appoggia alla rete internet.


SOLUZIONI
Detto del passaggio a sistemi a 64 bit, vanno fatte alcune considerazioni.
Cambiare il valore di time.h (che controlla appunto il tempo e come detto è un numero intero a 32 bit) per usare un sistema a 64-bit renderebbe il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo.
Cambiare time.h in un intero unsigned, permetterebbe di rimandare il problema al 7 febbraio 2106, causando comunque problemi a molti programmi.
Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per il time.h.
Il passaggio a questo tipo di architetture è in corso, e ci si aspetta che sia completo prima del 2038.
Tuttavia, ancora oggi esistono centinaia di milioni di sistemi a 32 bit sul mercato, di cui molti in sistemi integrati.
L'uso di time.h a 32 bit è anche stato inserito in vari formati di file, cosa che comporta la persistenza del problema anche oltre la vita delle macchine stesse.
L'uso di un valore di tipo signed a 64-bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni.
Sono state avanzate anche varie proposte alternative, alcune delle quali in uso, per sfruttare questo spostamento eccessivo della data massima calcolabile: tra queste, includere nel calcolo delle ore i millisecondi o i microsecondi, abbreviando la vita utile delle macchine a 300.000 anni.

Cos'è Il Millennium Bug e Come Venne Risolto Il Problema

Il Millennium Bug, conosciuto anche come Y2K bug, è il nome che venne attribuito ad un bug informatico che si sarebbe manifestato al cambio di data dalla mezzanotte del 31 dicembre 1999 al 1º gennaio 2000 nei sistemi di elaborazione dati, sia PC privati che grandi elaboratori e controllori di processo. Si trattava sostanzialmente di un errore di programmazione che, al passaggio di millennio, ha impedito in alcuni programmi di riconoscere il cambiamento di data, provocando il blocco dei sistemi informatici. L'espressione Millennium venne aggiunta con l'avvicinarsi dell'anno 2000.
I computer più vecchi, infatti, indicavano la data del sistema con due sole cifre: per esempio l'anno 1998 era segnato come '98', il 1999 con il '99' e così via. Infatti se facciamo un passo indietro e torniamo a quando furono introdotti i primi calcolatori, possiamo notare che per risparmiare preziose risorse di sistema, allora limitate a pochi byte, si decise di indicare le date con i soli due numeri finali, omettendo l'indicazione del millennio e del secolo. Il "cambiamento di millennio" poteva quindi portare a problemi inaspettati, quando le banche dati informatiche avrebbero datato i nuovi documenti del 2000 con la cifra '00', creando confusione con la data '1900' (con conseguenti errori di ordinamento dei database. Pensate inoltre ai sistemi industriali e ad altri macchinari gestiti dai computer).
Questo metodo delle due cifre era stato in effetti molto utilizzato nella "preistoria" informatica, quando la memoria era scarsa e costosa. Già nella metà degli anni 80, la comunità internazionale iniziò ad interessarsi al problema. Temendo conseguenze catastrofiche per l'economia o la salute, quali ad esempio il blocco delle centrali elettriche e nucleari, testate atomiche lanciate a caso, istituti bancari e reti di telecomunicazione in tilt, vi furono ingenti investimenti volti alla rimozione delle cause del bug.
Al cadere della data critica non fu registrato nessun evento catastrofico dagli osservatori preposti (problemi si ma non eccessivamente significativi). Per la verità i computer dell'epoca (Windows 98 ad esempio) erano ovviamente già predisposti per il cambio di data, essendo ormai imminente il nuovo millennio. Il problema, nel suo complesso (vecchi sistemi operativi, antecedenti al 1998), fu risolto spendendo una decina di milioni di dollari.


USENET E SPENCER BOLLES SUL MILLENNIUM BUG
Il primo articolo pubblicato su Usenet che menziona questo problema è apparso nel newsgroup net.bugs a firma di Spencer Bolles il 19 gennaio 1985.
"Un mio amico mi ha posto una domanda interessante: dato che i computer sono nati nel ‘900 saranno preparati a capire le date dal 2000 in poi? A me sembra un qualcosa privo di senso.
Io ho pensato che il mio amico scherzasse, ma n realtà sembrava vivamente preoccupato".


LE PRECAUZIONI DELL'EPOCA
All'avvicinarsi del fatidico capodanno che avrebbe portato tutti nel nuovo millennio, le più importanti aziende italiane, americane e tutti i paesi industrializzati aggiornarono i loro PC ed i software per evitare problemi con il cambio di data. I vecchi BIOS vennero ovviamente aggiornati tramite internet dai siti dei produttori stessi. Dal punto di vista software, Windows 95 e soprattutto 98 furono abbastanza pronti, anche se vennero messe a disposizione diverse patch per entrambi per garantire la massima compatibilità e sicurezza. Il problema più grande invece riguardava ovviamente Win 3.11 che aveva bisogno di molti aggiornamenti per non avere problemi. Per Linux invece non ci furono eccessivi problemi. Per quanto riguarda gli applicativi "Office", Microsoft Office, StarOffice, Lotus e simili, per le versioni antecedenti al 97 venne messa appunto una patch. Tutti i programmi, quali grafica 2D/3D, giochi, audio, browser, montaggio video e altri non ebbero nessun problema in quanto non gestiscono date. Vennero inoltre messi in vendita moltissimi programmi che promettevano di controllare il sistema e di "risolvere" i problemi legati all'anno 2000. Qualche problema ci fu ma la catastrofe di cui si parlava, fortunatamente, non si verificò (anche grazie all'utilizzo di PC recenti e alla correzione dei bug di quelli più vecchi).
Per saperne di più: Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Ti consiglio anche quest'articoli: Arriva Il Bug Dell'Anno 2038 e Tempo Unix

Il Bug Heartbleed Colpisce OpenSSL

Il bug del software di cifratura OpenSSL, chiamato Heartbleed, ha recentemente gettato nel panico gli utenti di tutto il mondo.
La falla, infatti, ha colpito oltre due terzi dei siti web mondiali ed ha messo in pericolo le nostre password e i nostri dati sensibili.
La falla è stata scoperta solo nel 2014 ed ha costretto milioni di utenti a cambiare le password di numerosi account


PERCHE' E' PERICOLOSA?
Heartbleed potrebbe aver consentito agli hacker di accedere a una enorme quantità di dati sensibili negli ultimi due anni.
La falla nel sistema di sicurezza è particolarmente grave perché consente agli hacker di rubare le informazioni criptate senza lasciare alcuna traccia del loro operato.
Quindi è molto difficile riuscire a valutare quanti e quali dati siano stati realmente sottratti.
Dunque Password, carte di credito e altri dati sensibili sul web sono a rischio dopo la scoperta della falla OpenSSL, il software di sicurezza usato da milioni di siti internet nelle transazioni commerciali, nelle comunicazioni criptate, nella trasmissione di dati sensibili.
In pratica è quel lucchetto (riconoscibile con la sigla 'https' all'inizio della url) usato dai siti per proteggere le comunicazioni considerate più delicate.
Circa due terzi dei siti mondiali usano o hanno usato la tecnologia "OpenSSL".


SITI VULNERABILI E NON
Tra i siti attualmente più vulnerabili ci sarebbero soprattutto Yahoo! e il suo social media Tumblr, e poi Flickr e Oculus.
Ma non si esclude che in passato siano stati affetti dal 'bug' tutti i colossi della rete: da Facebook a Google, da Wikipedia ad Instagram, passando per Apple.

Google      -     Falla risolta. Raccomandato cambio password
Facebook  -     Falla risolta. Raccomandato cambio password
Instagram  -     Falla risolta. Raccomandato cambio password
YouTube    -     Falla risolta. Raccomandato cambio password
Yahoo!      -     Falla risolta. Raccomandato cambio password
Wikipedia  -     Falla risolta. Raccomandato cambio password
Blogspot    -    Falla risolta. Raccomandato cambio password
Bing     -         Falla risolta. Raccomandato cambio password
Live     -         Falla risolta. Raccomandato cambio password
Tumblr    -     Falla risolta. Raccomandato cambio password
MSN     -       Falla risolta. Raccomandato cambio password
Microsoft    - Falla risolta. Raccomandato cambio password
Flickr    -     Falla risolta. Raccomandato cambio password
Blogger    -     Falla risolta. Raccomandato cambio password
Googleusercontent.com  -    Falla risolta. Raccomandato cambio password
Amazon    -     Non era vulnerabile
LinkedIn     -   Non era vulnerabile
eBay     -         Non era vulnerabile
PayPal    -       Non era vulnerabile
Twitter    -      Non era vulnerabile
Chase     -       Non era vulnerabile
CNET     -      Non era vulnerabile
CBSSports   -  Non era vulnerabile


In ogni caso, se vorreste testare la sicurezza di un sito per verificare se sia stato o meno vulnerabile al bug, andate qui: Mcafee(Heartbleed Test)

Zero Day Attack Su Flash Player (Exploit e Bug)

Alcune versioni Flash Player per Windows, Mac e Linux avrebbero evidenziato vulnerabilità Zero-Day (identificata da Kaspersky dal codice CVE-2014-0515) che interessano la componente Pixel Bender per la processazione di immagini e video.
Attraverso questa vulnerabilità i criminali informatici possono assumere il controllo da remoto dei dispositivi infettati con “montate” le versioni 13.0.0.182 e precedenti per Windows, 13.0.0.201 e precedenti per Mac e 11.2.202.350 e precedenti per Linux.
Al momento della sua scoperta, l’exploit zero-day era già stato usato per colpire diverse vittime in Siria attraverso una tecnica di attacco chiamata “watering hole”.
Un “water hole attack” è un tipo di attacco mirato in cui un hacker inserisce un malware in un sito web che crede che la sua vittima potrebbe visitare.
In questo modo, quando e se la vittima visita il sito web infetto, verrà infettata dal malware automaticamente.
Adobe ha già preparato una patch per il bug.


PROBLEMI ANCHE PER MICROSOFT
Anche Microsoft ha avuto alcuni problemi con un zero-day che ha interessato il suo browser, Internet Explorer.
Si tratta di un problema serio tale da spingere Microsoft a pensare alla release di una patch “out of band”, ovvero quelle patch che vengono rilasciate al di fuori dei momenti stabiliti, come per esempio il Patch Tuesday mensile.
Se un bug riceve una patch “out of band”, è abbastanza evidente che si tratta di un bug serio.

Facebook Paga Chi Riesce A Trovare Dei Bug (Bounty Bug)

Nuova partnership tra Facebook e Microsoft che sfidano gli hacker invitandoli, dietro compenso, a trovare bug nella rete.
Il social network e il gruppo informatico hanno creato un apposito fondo con cui cercano di attrarre pirati informatici, ma questa volta per cause positive.
Da sempre grandi società Internet pagano esperti di sicurezza informatica al fine di scovare vulnerabilità nei loro software.
L’intento è quello di risolvere i problemi prima che qualcuno ne tragga beneficio.
Progetti chiamati “Bounty Bug” hanno attratto attenzione nei mesi scorsi dopo che un ricercatore ha dimostrato l’imperfezione nelle barriere di sicurezza di Facebook, pubblicando senza permesso un post sul profilo dell’amministratore delegato del social network, Mark Zuckerberg.
A oggi, il gruppo ha versato 1,5 milioni di dollari ai ricercatori di bachi e in alcuni casi li ha assunti.
Il fondo voluto da Facebook e Microsoft pagherà almeno 5.000 dollari per un buco nella rete Internet che “si manifesta in un’ampia gamma di prodotti o che ha un impatto su un ampio numero di utenti” e ha “conseguenze estremamente negative per il pubblico generale”.
Di cosa si tratta? Un esempio è dato dai problemi trovati in Secure Sockets Layer, un protocollo di crittazione usato da molte società di e-commerce e siti di banche.

Cosa Sono Gli Zero-Day (Vulnerabilità)

Gli Zero-Day sono tra i peggiori pericoli del web, in quanto sono noti solo a una ristretta cerchia di persone e possono causare moltissimi danni prima di essere scoperti.
In informatica si definisce 0-day qualsiasi vulnerabilità non nota e, per estensione, indica un tipo di attacco informatico che inizia nel "giorno zero", cioè nel momento in cui viene scoperta una falla di sicurezza in un sistema informatico.
Questo tipo di attacco può mietere molte vittime proprio perché è lanciato quando ancora non è stata distribuita alcuna patch e quindi i sistemi non sono ancora protetti.
Normalmente si parla di Zero-Day(o zero-day)riferendosi ad essi come un'attività espressamente dolosa compiuta dai criminali che si adoperano per trovarle, proprio con l'intenzione di guadagnarsi un accesso abusivo ad un sistema informatico che non presenta,evidentemente, altri bug da sfruttare per l'accesso.
Ci sono hacker/cracker che si riuniscono in piccole organizzazioni(blog,mailing list,etc)in modo da scambiarsi informazioni e 0-day.
Tipologie di 0-day possono essere SQL Injection, Exlopit, Remote File Inclusion e XSS , ovvero tutti attacchi molto pericolosi per l'integrità di un sito web o per il corretto funzionamento di un nodo di internet.

Cos'è La Vulnerabilità PHF (CGI)

Il PHF era uno script CGI di esempio che implementava una rubrica telefonica basata su maschere.
Lo script veniva incluso di default in alcuni web server (soprattutto NCSA httpd 1.5 ed Apache 1.0.3) durante gli anni 90 e soffriva di una vulnerabilità che consentiva l'esecuzione di codice remoto sul sistema ospite.
Lo script utilizzava la funzione escape_shell_cmd() per verificare i dati in ingresso ma purtroppo la procedura di validazione dell’input non riusciva a rilevare il carattere di ritorno a capo (“++”, o “0x0a” in esadecimale).
Di conseguenza questo carattere particolare poteva essere utilizzato per forzare la fine dell’esecuzione dello script e fare in modo che il programma esegua, localmente sul server, tutto quello che segue il carattere incriminato.
In questo modo diventava possibile fare qualsiasi, cosa come ad esempio ottenere il file delle password.
Fu uno dei bug più semplici da sfruttare nella storia delle web application.