{"id":6551,"date":"2015-08-31T11:03:35","date_gmt":"2015-08-31T11:03:35","guid":{"rendered":"https:\/\/kasperskydaily.com\/italy\/?p=6551"},"modified":"2019-11-22T11:28:47","modified_gmt":"2019-11-22T09:28:47","slug":"security-week-35","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/security-week-35\/6551\/","title":{"rendered":"Security Week 35: niente di personale, sono solo affari"},"content":{"rendered":"<p>L\u2019industria giornalistica specializzata nel settore della sicurezza informatica (se mai esista una cosa del genere), nonostante non sia cos\u00ec affamata come Vanity Fair, \u00e8 anch\u2019essa costantemente alla ricerca di scoop. Per esempio, una delle notizie pi\u00f9 popolari uscite lo scorso anno su Threatpost era una notizia in realt\u00e0 non tra le pi\u00f9 rilevanti, sulla <a href=\"https:\/\/threatpost.com\/png-image-metadata-leading-to-iframe-injections\/104047\" target=\"_blank\" rel=\"noopener nofollow\">vulnerabilit\u00e0 PNG<\/a>. Inoltre, non si trattava nemmeno di una vulnerabilit\u00e0 nel senso letterale del termine, ma di un metodo per nascondere il codice dannoso contenuto nelle immagini dei metadata. Perch\u00e9 \u00e8 successo? Qualcuno (non noi ovviamente!) ha deciso di dare l\u2019annuncio in un modo eclatante, descrivendo il bug come un problema che \u201csi pu\u00f2 contrarre guardando foto di gattini\u201d.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/09\/05235756\/security-week-35-burn.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-6553\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/09\/05235756\/security-week-35-burn-1024x840.jpg\" alt=\"security-week-35-burn\" width=\"1024\" height=\"840\"><\/a><\/p>\n<p>Naturalmente, non appena si scopre una falla di sicurezza che pu\u00f2 permettere agli hacker di infettare milioni di computer, sono il primo a volver scrivere un articolo sull\u2019argomento, ma \u00e8 da tanto che non si vedono casi di questo tipo. Sono passati molti anni da quando \u00e8 apparso <a href=\"https:\/\/securelist.com\/blog\/29902\/benny-ratter-questioned\/\" target=\"_blank\" rel=\"noopener\">Slammer<\/a>, un piccolo e furtivo malware capace di infettare un Windows XP in soli 30 minuti e attraverso la sola connessione a Internet. I software attuali non sono cos\u00ec facili da attaccare (non ancora). E se accadesse? Cosa succederebbe se arrivasse una minaccia cos\u00ec seria da lasciare tutti a bocca aperta, da spingere le persone a pensare al prossimo livello di sicurezza per il proprio PC\/telefono\/frigorifero, oppure una minaccia cos\u00ec seria capace di trasformare ogni dispositivo e elettrodomestico in un pezzo di plastica\/metallo? Il mondo impazzirebbe! Ritorneremo indietro nel tempo, all\u2019et\u00e0 della pietra, con a disposizione solo carta e penna per poter archiviare e condividere informazioni!<\/p>\n<p>Va detto che nel settore IT si possono verifcare errori, \u00e8 plausibile che questo avvenga (come, per esempio, nel caso dei dispositivi di Internet delle Cose) ma non avvengono cos\u00ec spesso. I bug molto seri sono in realt\u00e0 vulnerabilit\u00e0 accezionali.<\/p>\n<blockquote class=\"twitter-pullquote\"><p>#Security Week 35: le vulnerabilit\u00e0 di @Wordpress, attacco #DDoS a @GitHub, @Wyndham responsabile di un problema di sicurezza, @Target a salvo<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2FoG2z&amp;text=%23Security+Week+35%3A+le+vulnerabilit%C3%A0+di+%40Wordpress%2C+attacco+%23DDoS+a+%40GitHub%2C+%40Wyndham+responsabile+di+un+problema+di+sicurezza%2C+%40Target+a+salvo\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>Nella rassegna di oggi, tratteremo tre casi di vulnerabilit\u00e0 che sono state sfruttate massivamente e in modo molto efficace. Come ho gi\u00e0 fatto in passato, vi spiego di nuovo le \u201cregole del gioco\u201d: ogni settimana il Team di Threatpost sceglie le tre notizie pi\u00f9 importanti tra gli articoli pubblicati. Tutti i post precedenti di questa sezione li <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=security+week&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">trovate qui<\/a>.<\/p>\n<p><strong>Siti fatti con WordPress hackerati e usati per diffonde il pack exploit Neutrino<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/wordpress-compromises-behind-spike-in-neutrino-ek-traffic\/114380\" target=\"_blank\" rel=\"noopener nofollow\">La notizia<\/a>. La ricerca di <a href=\"http:\/\/research.zscaler.com\/2015\/08\/neutrino-campaign-leveraging-wordpress.html\" target=\"_blank\" rel=\"noopener nofollow\">ZScaler<\/a>.<\/p>\n<p>La notizia dovrebbe essere divisa in due parti. Prima di tutto dovremmo parlare dei migliaia di blog e siti web basati su WordPress, piattaforma altamente vulnerabile. La seconda parte dovrebbe trattare i metodi usati dagli hacker per sfuttare queste vulnerabilit\u00e0, il malware che usano per infettare i PC e, in ultima istanza, il modo in cui i criminali riescono guadagnarci su.<\/p>\n<p>Iniziamo da WordPress! WordPress \u00e8 una piattaforma di personal publishing web-based molto popolare dotata di un vasto sistema di plug-in che attirano molto l\u2019attenzione dei cybercriminali. Per farsi un\u2019idea basta dare un\u2019occhiata alle vulnerabilit\u00e0 o ai problemi di sicurezza che hanno interessato questa piattaforma quest\u2019anno (ed \u00e8 solo un riassunto!):<\/p>\n<ul>\n<li><em>Vulnerabilit\u00e0 Zero-day <\/em><a href=\"https:\/\/threatpost.com\/following-exploits-zero-day-in-wordpress-plugin-fancybox-patched\/110882\" target=\"_blank\" rel=\"noopener nofollow\">in un plug-in<\/a><em>.<\/em><\/li>\n<li><em>Una falla in un generatore di numeri random (non proprio random in fin dei conti) che in teoria <\/em><a href=\"https:\/\/threatpost.com\/lack-of-csprng-threatens-wordpress-sites\/111016\" target=\"_blank\" rel=\"noopener nofollow\"><em>permette di scoprire il token usato durante la procedura di cambio password<\/em><\/a><em>.<\/em><\/li>\n<li><a href=\"https:\/\/threatpost.com\/more-than-1-million-wordpress-sites-open-to-sql-injection-attacks\/111267\" target=\"_blank\" rel=\"noopener nofollow\"><em>Iniezione SQL<\/em> in un plug-in<\/a><em>.<\/em><\/li>\n<li><em>Ancora un\u2019altra <\/em><a href=\"https:\/\/threatpost.com\/sql-injection-bug-fixed-in-popular-wordpress-seo-plug-in\/111601\" target=\"_blank\" rel=\"noopener nofollow\"><em>iniezione SQL<\/em><\/a><em> in un plug-in.<\/em><\/li>\n<li><em>Un vulnerabilit\u00e0 di <\/em><a href=\"https:\/\/threatpost.com\/peristent-xss-vulnerability-plagues-wordpress-plugin\/112057\" target=\"_blank\" rel=\"noopener nofollow\">XSS<\/a><em> in un plug-in.<\/em><\/li>\n<li><em>Un <\/em><a href=\"https:\/\/threatpost.com\/wordpress-patches-zero-day-vulnerability\/112455\" target=\"_blank\" rel=\"noopener nofollow\">Zero-day in WordPress stesso<\/a><em>, iniezione in JavaScript. La patch \u00e8 disponibile nella versione 4.2.1.<\/em><\/li>\n<li><em>Due <\/em><a href=\"https:\/\/threatpost.com\/vulnerabilities-identified-in-two-wordpress-plugins\/112676\" target=\"_blank\" rel=\"noopener nofollow\"><em>vulnerabilit\u00e0 in un <\/em>plug-in<\/a><em>.<\/em><\/li>\n<li><em>Una vulnerabilit\u00e0 di XSS <\/em><a href=\"https:\/\/threatpost.com\/wordpress-patches-critical-xss-vulnerability-in-all-builds\/113916\" target=\"_blank\" rel=\"noopener nofollow\">in WordPress stesso<\/a><em>, patch rilasciata nella versione 4.2.3.<\/em><\/li>\n<li><em>Vulnerabilit\u00e0 in 3 <\/em><a href=\"https:\/\/threatpost.com\/vulnerabilities-identified-in-several-wordpress-plugins\/114255\" target=\"_blank\" rel=\"noopener nofollow\">plug-in<\/a><em>.<\/em><\/li>\n<\/ul>\n<p><strong><\/strong><\/p>\n<p>Questo \u00e8 pi\u00f9 o meno il quadro generale. I ricercatori di ZScaler hanno scoperto una falla enorme che esponeva i siti web fatti con WordPress (versione 4.2 e precedenti). La versione 4.2, ad ogni modo, \u00e8 <a href=\"https:\/\/wordpress.org\/news\/2015\/04\/powell\/\" target=\"_blank\" rel=\"noopener nofollow\">stata lanciata<\/a> poco tempo fa, nell\u2019aprile di quest\u2019anno. Dopo aver hackerato i siti web, i criminali avrebbero iniettato un iframe e poi installato il pack exploit Neutrino e infettato i PC con un malware. Al momento ci sono pi\u00f9 di 2.500 siti web interessati dal problema, il che non \u00e8 gran cosa se comparato con Internet, ma \u00e8 sufficiente per rovinare la vita a decine di migliaia di utenti.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">What are exploits and why they are so scary? <a href=\"https:\/\/t.co\/tulx05JN0q\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/tulx05JN0q<\/a> <a href=\"http:\/\/t.co\/Z5A4itfh7E\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/Z5A4itfh7E<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/627151591624306689?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">July 31, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Il pack exploit usa un bug presente su Adobe Flash, vittima di una <a href=\"https:\/\/threatpost.com\/apt-group-exploiting-hacking-team-flash-zero-day\/\" target=\"_blank\" rel=\"noopener nofollow\">fuga di dati<\/a> facente parte di un attaco organizzato da <a href=\"https:\/\/threatpost.com\/hackers-release-hacking-team-internal-documents-after-breach\/113612\" target=\"_blank\" rel=\"noopener nofollow\">Hacking Team<\/a>. Quindi potendo eseguire un codice all\u2019interno del computer della vittima, gli hacker hanno utilizzato il locker Cryptowall, un ransomware che si trovava <em>in the wild<\/em> da circa un anno, e hanno rischieto alle vittime a cambio delle chiavi di decrittazione il pagamento di pi\u00f9 di $500.<\/p>\n<div style=\"width: 957px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233053\/security-week-35-cryptowall.png\" alt=\"\" width=\"947\" height=\"903\"><p class=\"wp-caption-text\">Caption: Tutti i vostri dati appartengono a me! Scopri di pi\u00f9 sui ransomware <a href=\"https:\/\/www.kaspersky.it\/blog\/ransomware-protection-video\/6090\/\" target=\"_blank\" rel=\"noopener\">cliccando qui<\/a>!<\/p><\/div>\n<p>\u00a0<\/p>\n<p>Immaginate di aver aperto una piccola ditta e che un paio di anni fa avete comprato una pagina web da un fornitore terzo; detto ci\u00f2 non avete idea della tecnologia utilizzata dal vostro sito. Se paragonato con certi attacchi hacker come quelli in cui si introduce un <a href=\"http:\/\/www.pcworld.com\/article\/2956272\/security\/yahoo-tackles-large-malvertising-campaign-in-its-ad-network.html\" target=\"_blank\" rel=\"noopener nofollow\">codice dannoso attraverso un banner<\/a> come, per esempio, quello di Yahoo, \u00e8 un gioco da ragazzi, ma se si infettano in questo modo migliaia di siti ci\u00f2 pu\u00f2 far guadagnare (o perdere, dipende dal punto di vista) ai criminali milioni di dollari.<\/p>\n<p>Dal punto di vista della sicurezza, questo attacco non \u00e8 affatto straordinario. \u00c8 un insieme di piccoli incidenti: appaiono alcune vulnerabilit\u00e0 in una di queste piattaforme (come WordPress) e nei suoi plugin; qualcuno attacca questi siti e utilizza un pack exploit; qualcuno sviluppa poi questi pack exploit usando i dati ottenuti dall\u2019azienda ricavando notevoli benefici dallo scambio di vulnerabilit\u00e0.<\/p>\n<p>Qualcuno user\u00e0 un Flash non aggiornato e qualcun\u2019altro ricever\u00e0 soldi da persone disperate che non sono in grado di accedere ai propri file. Presi separatamente, ognuno di questi incidenti non \u00e8 gran cosa, ma messi insieme vengono a creare un quadro piuttosto preoccupante.<\/p>\n<p>Curiosamente i ricercatori <a href=\"https:\/\/threatpost.com\/uptick-in-neutrino-exploit-kit-traffic-doesnt-mean-angler-reign-over\/114362\" target=\"_blank\" rel=\"noopener nofollow\">avevano notato in precedenza<\/a> un aumento del traffico di Neutrino a spese della sua rivale, Angler, senza una spiegazione apparente. Sembra che oltre a guadagnarci su dei soldi, le persone a capo di queste operazioni cybercriminali cercavano di capire chi \u00e8 il capo.<\/p>\n<p><strong>GitHub, di nuovo vittima di un attacco DDoS<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/github-mitigates-ddos-attack\/114403\" target=\"_blank\" rel=\"noopener nofollow\">Notizie<\/a>. Un\u2019altra <a href=\"https:\/\/threatpost.com\/github-hit-with-ddos-attack\/111850\" target=\"_blank\" rel=\"noopener nofollow\">notizia<\/a>.<\/p>\n<p>In realt\u00e0, \u00e8 piuttossto facile ridurre il numero delle vulnerabilit\u00e0. Bisogna fare in modo che i coder non codifichino. Beh, questo \u00e8 un metodo discutibile ma qualcuno, a quanto pare, voleva procedere in questo modo, interrompendo le operazioni di GitHub eseguendo un attacco DDoS su di una delle industrie del software pi\u00f9 famose.<\/p>\n<p>L\u2019attacco \u00e8 iniziato in mattinata, \u00e8 stato scoperto e risolto tre ore, ma la persona responsabile rimane tutt\u2019ora sconosciuta. Che noia! Quindi perch\u00e9 queste news attirano tanto l\u2019attenzione delle persone? Perch\u00e9 l\u2019attacco <a href=\"https:\/\/threatpost.com\/github-hit-with-ddos-attack\/111850\" target=\"_blank\" rel=\"noopener nofollow\">DDoS ai danni di GitHub<\/a> \u00e8 durato circa una settimana (marzo 2014); ecco perch\u00e9 tale reazione.<\/p>\n<p><strong><img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233053\/security-week-35-notagain-en.jpg\" alt=\"\" width=\"616\" height=\"388\"><\/strong><\/p>\n<p>L\u2019attacco di marzo \u00e8 stato curioso. Gli esperti erano convinti che il traffico malware era in qualche modo connesso al motore di ricerca cinese Baidu. \u00c8 come un iframe apparso sulla pagina principale di Google e devia il traffico verso il sito web della vittima.<\/p>\n<p>Questo aiuta ad abbattere qualsiasi sito web, ma non sembra del tutto possibile, oppure lo \u00e8? \u00c8 poco probabile e sembra che, nell\u2019attacco di marzo, Baidu non era responsabile di nulla e che il regalino veniva inviato agli utenti cinesi via allegato da qualche altra parte e ma non si troava su Baidu.<\/p>\n<p>Dove esattamente si trovasse, rimane un quesito irrisolto. Forse era un modo comodo di infettare gli utenti e poi di spingerli a scaricare uno script corrotto quando accedevano ad un sito web popolare. O forse lo scambio avveniva da qualche altra parte.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Google have provided detailed analysis of the recent Github attack \u2013 <a href=\"http:\/\/t.co\/F75hTyzp2s\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/F75hTyzp2s<\/a> <a href=\"http:\/\/t.co\/HJPMMg0InZ\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/HJPMMg0InZ<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/592597849029943296?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">April 27, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Per esempio, questo <a href=\"http:\/\/www.netresec.com\/?page=Blog&amp;month=2015-03&amp;post=China%252527s-Man-on-the-Side-Attack-on-GitHub\" target=\"_blank\" rel=\"noopener nofollow\">pu\u00f2 succedere<\/a> in un luogo a met\u00e0 strada tra l\u2019Internet usato da tutti e l\u2019Internet cinese, dove il \u201cGrande Firewall cinese\u201d fa da padrone. In questo caso, coloro che accedono ai siti web cinesi fuori Cina potrebbero cadere nelle trappole degli hacker: la risposta data dal server potrebbe contenere uno script dannoso che potrebbe essere usato contro i progetti GitHub attraverso i PC delle vittime.<\/p>\n<p>Tuttavia, i progetti GitHub colpiti sembrano esser stati scelti manualmente: gli obiettivi erano due progetti che permettevano bypassare il Grande Firewall e accere al contenuto bandito in Cina. Questo tipo di attacco ha persino un nome proprio: \u201cMan-on-the-Side\u201d. Morale della favola: la chiave di tutto \u00e8 l\u2019HTTPS!<\/p>\n<p><strong>Catena alberghiera statunitense responsabile di una fuga di dati<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/court-rules-ftc-has-authority-to-punish-wyndham-over-breaches\/114390\" target=\"_blank\" rel=\"noopener nofollow\">La notizia<\/a><\/p>\n<p>Questa notizia ha come argomento l\u2019ordine pubblico ma \u00e8 molto importante. Sette anni fa, l\u2019infrastruttura IT della catena alberghiera statunitense Wyndham \u00e8 stata hackerata e sono stati rubati ai clienti circa 600.000 dati. Il furto dei dati relativi alle carte di credito ha permesso ai ladri di sottrarre ai proprietari delle carte di credito pi\u00f9 di 10 milioni di dollari. L\u2019attacco funzionava in questo modo: si cerca un computer manomesso in uno degli hotel, si ottiene la password di amministratore e si accede a\u2026 tutto!<\/p>\n<p>Dal punto di vista tecnico, l\u2019hackeraggio \u00e8 stato possibile per via di un \u201cepic fail\u201d del Team di Sicurezza dell\u2019hotel. Non proteggere i dati dei clienti\u2026 perch\u00e9 mai sul pianeta Terra qualcuno dovrebbe immagazzinare i numeri delle carte di credito in formato non criptato? La Federal Trade Commision (FTC) statunitense ha accusato duramente Wyndham di non aver rispettato le proprie politiche sulle privacy e aver messo in pericolo i dati dei clienti.<\/p>\n<p>Avevano promesso fornire una protezione standard di base (usare un firewall o proteggere i dati con la crittografia). Come poi si \u00e8 visto, non usavano n\u00e9 firewall, n\u00e9 la criptografia. Le password erano salvate di default nei PC, non era mai stato fatto un audit di sicurezza e non avevano un piano B. La FTC ha cercato di punire l\u2019azienda ma il caso (il primo nel suo genere), ha finito per aprire un altro dibattito su se la FTC ha il diritto di farlo o no. Le parti sono arrivate alla conclusione che FTC ha il potere di farlo.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Court Rules FTC Has Authority to Punish Wyndham Over Breaches \u2013 <a href=\"http:\/\/t.co\/pmgYUjbGEe\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/pmgYUjbGEe<\/a><\/p>\n<p>\u2014 Threatpost (@threatpost) <a href=\"https:\/\/twitter.com\/threatpost\/status\/635884703812296704?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 24, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Questo caso \u00e8 molto interessante. Un\u2019azienda \u00e8 vittima di un attacco APT, uno di quelli che presuppone l\u2019utilizzo di tecniche hacker avanzate e che aiutano a preservare l\u2019accesso non richiesto per un certo periodo di tempo. L\u2019azienda ha preso tutte le misure necesarie, ma vengono bypassate e non c\u2019\u00e8 nulla che la pu\u00f2 aiutare.<\/p>\n<p>Ma \u00e8 ben diverso quando l\u2019attacco non \u00e8 avanzato, ma persistente, perch\u00e9 in quel caso l\u2019infrastruttura \u00e8 completamente insicura e sensibile ad ogni minaccia. La sentenza della corte fa venire ancora di pi\u00f9 il mal di testa alle aziende statunitenesi rispetto alla sua applicazione. Di solito, le regole vengono applicate ai sistemi che gestiscono le carte di credito, ma ora pare che venga applicato a tutti gli aspetti che riguardano la protezione dei dati personali.<\/p>\n<p>Forse \u00e8 meglio cos\u00ec. Comunque sia le tecnologie e i metodi di protezione dovrebbero essere disegnati e realizzati da altri enti e non dalle corti. I tribunali dovrebbero occuparsi di ripulire certi concetti. Infine, i dati dovrebbero essere criptati. Pu\u00f2 sembrare una cosa ovvia, come fare frequenti back-up, ma meglio ripeterlo: i dati vanno criptati.<\/p>\n<p>Ad ogni modo, Target, i cui clienti sono <a href=\"https:\/\/threatpost.com\/target-attackers-took-11-gb-of-data-researchers-say\/103691\" target=\"_blank\" rel=\"noopener nofollow\">stati vittima di un problema di sicurezza<\/a> molto serio, non \u00e8 stato multato in base alla <a href=\"https:\/\/threatpost.com\/target-says-sec-wont-pursue-enforcement-action-as-a-result-of-data-breach\/114433\" target=\"_blank\" rel=\"noopener nofollow\">sentenza<\/a> FTC.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Target Says SEC Won\u2019t Pursue Enforcement Action as a Result of Data Breach \u2013 <a href=\"http:\/\/t.co\/OwsXc1ZBHK\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/OwsXc1ZBHK<\/a><\/p>\n<p>\u2014 Threatpost (@threatpost) <a href=\"https:\/\/twitter.com\/threatpost\/status\/636924617546928128?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 27, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p><strong>\u00a0Che altro \u00e8 successo?<\/strong><\/p>\n<p>Alcuni ricercatori statunitensi hanno <a href=\"https:\/\/threatpost.com\/scanner-finds-malicious-android-apps-at-scale\/114438\" target=\"_blank\" rel=\"noopener nofollow\">analizzato pi\u00f9 di 400.000<\/a> app di Google Play e hanno scoperto che il 7,6% era potenzialmente pericoloso. Questo non corrisponde alla <a href=\"https:\/\/static.googleusercontent.com\/media\/source.android.com\/ru\/devices\/tech\/security\/reports\/Google_Android_Security_2014_Report_Final.pdf\" target=\"_blank\" rel=\"noopener nofollow\">dichiarazione fatta da Google<\/a>: secondo Google, le possibilit\u00e0 di contrarre un\u2019infezione quando si scaricano app solo da Google Play sono solo del 0,15%. Allo stesso tempo, l\u2019approccio usato dai ricercatori \u00e8 piuttosto vago: analizzano il codice, trovano alcuni usi non standarizzati e automaticamente etichettano il codice come potenzialmente dannoso.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Scanner Finds Malicious Android Apps at Scale: <a href=\"https:\/\/t.co\/53MoLU2nRz\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/53MoLU2nRz<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@Threatpost<\/a> <a href=\"http:\/\/t.co\/7HrpJdSoz9\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/7HrpJdSoz9<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/636984446583996416?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 27, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>In Russia un ransomware si \u00e8 diffuso via email, ma non \u00e8 questa la notizia. La notizia \u00e8 che ora gli hacker usano false <a href=\"https:\/\/securelist.ru\/blog\/phishing-blog\/26651\/shifrovalshhik-v-kredit\/\" target=\"_blank\" rel=\"noopener\">notifiche di pagamento in ritardo<\/a> emesse dalle banche. Questi ragazzi sanno come usare queste situazioni a proprio vantaggio, tra cui anche crisi economiche.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">According to research, &gt;40% of CryptoLocker victims paid <a href=\"https:\/\/twitter.com\/hashtag\/ransomware?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#ransomware<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/infosec?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#infosec<\/a> <a href=\"http:\/\/t.co\/Lnb4Rq7foJ\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/Lnb4Rq7foJ<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/whitepaper?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#whitepaper<\/a> <a href=\"http:\/\/t.co\/wrxC9Rq1ZH\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/wrxC9Rq1ZH<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/635910810448056320?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 24, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Apple ha risolto la <a href=\"https:\/\/threatpost.ru\/2015\/08\/27\/patched-ins0mnia-vulnerability-keeps-malicious-ios-apps-hidden\/\" target=\"_blank\" rel=\"noopener nofollow\">vulnerabilit\u00e0<\/a> che permetteva a qualsiasi app di tracciare l\u2019attivit\u00e0 degli utenti, persino con il limite di tempo impostato nel sistema. \u00c8 curioso come un bug di questo tipo riesca ad evadere la moderazione dell\u2019App Store e quindi a infiltrarsi pi\u00f9 facilmente di una app puramente maliziosa.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Patched Ins0mnia Vulnerability Keeps Malicious <a href=\"https:\/\/twitter.com\/hashtag\/iOS?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#iOS<\/a> Apps Hidden: <a href=\"https:\/\/t.co\/LVLKMC8NcX\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/LVLKMC8NcX<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/apple?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#apple<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/jtZM9WXZYl\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/jtZM9WXZYl<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/636614141965434881?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 26, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p><strong>Oldies<\/strong><\/p>\n<p>Den-Zuk<\/p>\n<p><strong><img loading=\"lazy\" decoding=\"async\" class=\" alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/09\/05235730\/infosec-digest-32-book1.jpg\" alt=\"\" width=\"234\" height=\"300\"><\/strong><\/p>\n<p>Un virus molto pericoloso, con una longitudine di 9 settori. Infetta il settore boot dell\u2019hard disk quando viene sollecitato (int 13h, ah = 2,3,4,5). Se la seconda parte del virus viene salvato sul disco, non si realizza nessun controllo di sicurezza, motivo per cui il virus potrebbe distruggere una parte dell\u2019informazione del disco (traccia 40).<\/p>\n<p>Violazione interno 9 e 13H. Dopo un reboot \u201cpositivo\u201d, appare il nome Den Zek sullo schermo. Cambia il nome dell\u2019hard disck infetto e lo chiama \u201cYC1ERP\u201d. Non possiede funzioni distruttive molto pericolose dato che pu\u00f2 distruggere i dati in relazione alla traccia 40 del disco. Viene incluso il seguente testo: \u201cWelcome to the C l u b \u2014 The HackerS \u2014 Hackin\u2019 All The Time\u201d firmato \u201cThe HackerS\u201d.<\/p>\n<p>\u00a0<\/p>\n<p><em>Citazione da \u201cComputer viruses in MS-DOS\u201d di Eugene Kaspersky, 1992, p. 99.<\/em><\/p>\n<p><em>Dichiarazione di non responsabilit<\/em><em>\u00e0<\/em><em>: questo articolo riflette la persona opinione dell<\/em><em>\u2018<\/em><em>autore. Pu<\/em><em>\u00f2<\/em><em> coincidere o no con la posizione di Kaspersky Lab.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security Week 35: le vulnerabilit\u00e0 di Wordpress, l&#8217;attacco DDoS a GitHub, Wyndham responsabile di falla di sicurezza, mentre Target no.<\/p>\n","protected":false},"author":53,"featured_media":6554,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2641,12],"tags":[1589],"class_list":{"0":"post-6551","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-security-week-35"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-35\/6551\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-35\/5892\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-35\/6169\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-35\/6059\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-35\/6699\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-35\/8713\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-35\/9683\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-35\/6063\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-35\/8749\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-35\/8713\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-35\/9683\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-35\/9683\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/security-week-35\/","name":"security week 35"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6551","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=6551"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6551\/revisions"}],"predecessor-version":[{"id":18998,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6551\/revisions\/18998"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/6554"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=6551"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=6551"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=6551"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}