{"id":6526,"date":"2015-08-24T15:24:55","date_gmt":"2015-08-24T15:24:55","guid":{"rendered":"https:\/\/kasperskydaily.com\/italy\/?p=6526"},"modified":"2017-11-13T17:06:31","modified_gmt":"2017-11-13T15:06:31","slug":"security-week-34","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/security-week-34\/6526\/","title":{"rendered":"Security Week 34: le difficolt\u00e0 delle patch"},"content":{"rendered":"<p>Settimana burrascosa per la sicurezza informatica; dopo un\u2019altra settimana di <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=blackhat&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">nuovi bug<\/a>, zero-day e <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=def-con&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">altre interessanti curiosit\u00e0,<\/a> ecco che tutto ci\u00f2 si fa reale e arrivano ai software vulnerabili. Aspetto importante ma che a volte pu\u00f2 risultare noioso se troppo frequente. Il nostro blog <a href=\"http:\/\/www.threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> ci fornisce notizie fresche fresche riguardanti la sicurezza informatica; in questo caso abbiamo tre casi interessanti sulle patch.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233052\/security-week-34-featured-1024x672.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-6666\" src=\"https:\/\/www.kaspersky.it\/blog\/files\/2015\/08\/security-week-34-featured-1024x672-1024x672.jpg\" alt=\"security-week-34-featured\" width=\"1024\" height=\"672\"><\/a>L\u2019argomento \u201cpatch\u201d \u00e8 abbastanza delicato. Dopo aver individuato una vulnerabilit\u00e0, la parte pi\u00f9 difficile arriva quando bisogna creare una patch che risolva il problema senza per\u00f2 compromettere tutto il resto. Ci sono tanti motivi per cui un bug non viene risolto immediatamente, a volte passa un bel po\u2019 di tempo o addirittura rimane tutto cos\u00ec com\u2019\u00e8! In ogni caso, bisogna pur sempre trovare una soluzione.<\/p>\n<p>Nel post di oggi abbiamo tre storie di bug rimasti irrisolti. Ricordiamo brevemente le regole di questo post: ogni settimana, il team di Threatpost seleziona le tre notizie pi\u00f9 rilevanti e che io consiglio caldamente di leggere. Tutte le precedenti edizioni della nostra rubrica si trovano a questo <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=security+week&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">link<\/a>.<\/p>\n<p><strong>Un altro bug su Android, stavolta tocca a Google Admin <\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/zero-day-in-android-admin-app-can-bypass-sandbox\/114274\" target=\"_blank\" rel=\"noopener nofollow\">La notizia su Threatpost,<\/a> <a href=\"https:\/\/labs.mwrinfosecurity.com\/advisories\/2015\/08\/13\/sandbox-bypass-through-google-admin-webview\/\" target=\"_blank\" rel=\"noopener nofollow\">Ricerca condotta<\/a> da MWR<\/p>\n<p><em>Cosa \u00e8 stato trovato?<\/em><\/p>\n<p>Avete notato che ultimamente si susseguono notizie su notizie di bug? Ad esempio, c\u2019\u00e8 <a href=\"https:\/\/www.kaspersky.it\/blog\/blackhat-jeep-cherokee-hack-explained\/6423\/\" target=\"_blank\" rel=\"noopener\">un\u2019auto hackerata<\/a>? Ecco che vengono trovati <a href=\"https:\/\/www.kaspersky.it\/blog\/tesla-s-hacked-and-patched\/6436\/\" target=\"_blank\" rel=\"noopener\">decine di nuovi bug nelle smart car<\/a>! Lo stesso sta accadendo con Android. Siamo partiti con <a href=\"https:\/\/threatpost.com\/android-stagefright-flaws-put-950-million-devices-at-risk\/\" target=\"_blank\" rel=\"noopener nofollow\">Stagefright<\/a>, poi siamo passati a un paio di bug pi\u00f9 piccoli, ora \u00e8 la volta di Google Admin e <span style=\"text-decoration: line-through\">della redenzione di Shawshank<\/span> delle maniere di raggirare la sandbox.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233051\/security-week-34-kid-1024x682.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-6667\" src=\"https:\/\/www.kaspersky.it\/blog\/files\/2015\/08\/security-week-34-kid-1024x682-1024x682.jpg\" alt=\"security-week-34-kid\" width=\"1024\" height=\"682\"><\/a>Google Admin, una delle app di Android a livello di sistema, pu\u00f2 accettare URL da altre app; sembra che qualsiasi URL possa andare bene, anche quelle che cominciano per \u201cfile: \/\/\u201d. In questo modo, anche il download di pagine web potrebbe trasformarsi in un file manager. Ma tutte le app di Android non dovrebbero essere isolate le une dalle altre? Mmm, sembrerebbe di no, Google Admin gode di grandi privilegi e, per il fatto che passano per URL anche cose che non lo sono, fa s\u00ec che alcune app possano eludere la sandbox e accedere a dati privati.<\/p>\n<p><em>In che modo si \u00e8 risolto il problema? <\/em><\/p>\n<p>Innanzitutto vediamo brevemente come alcuni ricercatori indipendenti siano riusciti a individuare questa vulnerabilit\u00e0. Dobbiamo ritornare al marzo scorso e a un report inviato a Google. Cinque mesi dopo, i ricercatori hanno verificato come si stava evolvendo la situazione e si sono resi conto che per il bug non era stata creata alcuna patch. Il 13 agosto il bug \u00e8 stato reso pubblico, costringendo Google a porvi rimedio.<\/p>\n<p>Ricordiamo che Google dispone di un team di ricerca interno che utilizza tempo e risorse per individuare i bug e non solo sui propri software. <a href=\"http:\/\/googleprojectzero.blogspot.ru\/\" target=\"_blank\" rel=\"noopener nofollow\">ProjectZero<\/a> di Google ha di solito 90 giorni di margine di anticipo prima che il bug venga reso noto all\u2019opinione pubblica, ma a questo punto ci domandiamo se Google sia in grado di creare patch adeguate in 90 giorni.<\/p>\n<p>Nel caso Google Admin \u00e8 andato tutto storto; innanzitutto, l\u2019intera situazione \u00e8 stata gestita nel modo sbagliato e, in secondo luogo, sappiamo benissimo che anche quando la patch c\u2019\u00e8, non \u00e8 detto che arrivi a tutti i dispositivi Android vulnerabili. Cosa dire degli <a href=\"https:\/\/threatpost.com\/google-plans-monthly-security-updates-for-nexus-phones\/114148\" target=\"_blank\" rel=\"noopener nofollow\">aggiornamenti di sicurezza mensili<\/a>? Perch\u00e9 a questo punto non li facciamo ogni sei mesi? Dai, andiamo\u2026<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233050\/security-week-34-kitten-1024x1024.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-6668\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233050\/security-week-34-kitten-1024x1024.jpg\" alt=\"security-week-34-kitten\" width=\"1024\" height=\"1024\"><\/a> <strong>Vulnerabilit\u00e0 aperta su SCADA di Schneider Electric<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/risky-schneider-electric-scada-vulnerabilities-remain-unpatched\/\" target=\"_blank\" rel=\"noopener nofollow\">La notizia su Threatpost,<\/a> <a href=\"https:\/\/ics-cert.us-cert.gov\/alerts\/ics-alert-15-224-02\" target=\"_blank\" rel=\"noopener nofollow\">ICS-CERT Advisory<\/a><\/p>\n<p>Benvenuti nell\u2019affascinante mondo delle infrastrutture critiche! Vi preghiamo di prendere posto, di mettervi comodi e di non toccare quel famoso pulsante rosso o quel groviglio di cavi che fuoriescono a proposito. \u00c8 tutto ok, sono l\u00ec da secoli. Se li toccate, siamo fritti.<\/p>\n<p>I sistemi SCADA fanno parte delle infrastrutture critiche che si occupano di gestire oggetti importanti, dalle caldaie nei nostri appartamenti alle centrali nucleari. Tali sistemi non possono essere spenti o resettati, non si pu\u00f2 giocare con impostazioni o parametri, meglio non toccare nulla!<\/p>\n<blockquote class=\"twitter-pullquote\"><p>#SecurityWeek34: nuove vulnerabilit\u00e0 non risolte su #Android, Mac #OSX, #SCADA di Schneider Electric e altri<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2F9qFK&amp;text=%23SecurityWeek34%3A+nuove+vulnerabilit%C3%A0+non+risolte+su+%23Android%2C+Mac+%23OSX%2C+%23SCADA+di+Schneider+Electric+e+altri\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>Nel caso aveste qualche domanda in merito, <a href=\"https:\/\/securelist.com\/analysis\/publications\/36594\/securing-critical-information-infrastructure-trusted-computing-base\/\" target=\"_blank\" rel=\"noopener\">questo articolo fa al caso vostro<\/a>. Purtroppo, per\u00f2, \u00e8 un dato di fatto che questi sistemi cos\u00ec importanti spesso siano gestiti su PC normali con il caro, vecchio Windows. A differenza di quanto accada nella maggior parte delle aziende, dove si aggiornano o sostituiscono hardware e software per lo meno ogni cinque anni, alcuni impianti industriali robotizzati che gestiscono sostanze chimiche anche pericolose, possono funzionare 24 ore al giorno tutto l\u2019anno, e per decenni, con lo stesso hardware.<\/p>\n<p><em>Cosa \u00e8 stato trovato?<\/em><\/p>\n<p>Ebbene, sono stati trovati non si sa quanti bug in uno di questi sistemi, la stazione PLC P34 CPU <a href=\"http:\/\/www.schneider-electric.com\/en\/product-range\/1468-modicon-m340\/\" target=\"_blank\" rel=\"noopener nofollow\">Modicon M340<\/a> di Scheider Electric. In sostanza, grazie a queste vulnerabilit\u00e0 si pu\u00f2 prendere il controllo praticamente di tutto ci\u00f2 che gestisce questo sistema. Una falla piuttosto diffusa (riscontrata anche in router e altri apparecchi appartenenti al mondo dell\u2019IoT) riguarda le credenziali hard-coded.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Risky Schneider Electric SCADA Vulnerabilities Remain Unpatched <a href=\"https:\/\/t.co\/2oGDTbr7qE\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/2oGDTbr7qE<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/eyPAY6Aikn\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/eyPAY6Aikn<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/633365728075378688?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 17, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Per ovvie ragioni non possiamo sapere cosa viene codificato in questo modo nel sistema SCADA, tuttavia possiamo dedurre che si tratta di alcune credenziali di accesso di default che il vendor offre per rendere pi\u00f9 agevoli alcune operazioni o semplicemente per le quali il vendor ha dimenticato di effettuare il test delle password fuori dal codice. O qualsiasi altra scusa, non lo sappiamo.<\/p>\n<p><em>In che modo si \u00e8 risolto il problema? <\/em><\/p>\n<p>Semplicemente non \u00e8 stato risolto. Sono passate ben due settimane da quando il ricercatore Aditya Sood ha presentato questa vulnerabilit\u00e0 al <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=def+con&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">DEF CON<\/a>, ma non c\u2019\u00e8 ancora nessuna patch in vista. \u00c8 abbastanza comprensibile del resto: un vendor deve gestire una situazione difficile, il compito di creare una patch per un software vulnerabile diventa ancora pi\u00f9 complicato poich\u00e9 fermare questi sistemi comporta delle gravi perdite per il cliente, semplicemente sono sistemi il cui funzionamento non pu\u00f2 essere fermato temporaneamente.<\/p>\n<p>Quanto tempo ci vuole per applicare la patch? Per quanto tempo bisogna sospendere l\u2019uso del sistema? E poi funzioner\u00e0 bene di nuovo? Sono state prese in considerazioni tutte le caratteristiche dei dispositivi endpoint? In ogni caso si tratta di scuse inutili per non creare le patch ed \u00e8 stato gi\u00e0 dimostrato che disconnettere una infrastruttura critica da Internet o proteggerla con un firewall <a href=\"https:\/\/www.kaspersky.it\/blog\/when-going-offline-doesnt-help\/6222\/\" target=\"_blank\" rel=\"noopener\">non \u00e8 assolutamente una soluzione<\/a>.<\/p>\n<div style=\"width: 650px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233048\/security-week-34-keynote.jpg\" alt=\"\" width=\"640\" height=\"480\"><p class=\"wp-caption-text\">Gli sviluppatori durante la presentazione<\/p><\/div>\n<p><strong>Bug non risolto su Mac OS X<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/inside-the-unpatched-os-x-vulnerabilities\/114344\" target=\"_blank\" rel=\"noopener nofollow\">La notizia su Threatpost<\/a><\/p>\n<p>Tocchiamo nuovamente la questione di come rendere pubblici i bug in maniera responsabile. Per quanto riguarda il bug di Google, i ricercatori hanno aspettato 5 mesi prima di renderlo pubblico, anche se Google stessa limita questo tempo a 90 giorni. Quanto si dovrebbe aspettare allora? Per quanto tempo gli sviluppatori dovrebbero chiudere un occhio?<\/p>\n<p>Dare tempo non rende pi\u00f9 pigri gli sviluppatori che continuano a rimandare il pi\u00f9 possibile la creazione della patch? La pubblicazione immediata della vulnerabilit\u00e0 potrebbe spingere gli sviluppatori a essere pi\u00f9 solerti nella creazione delle patch? Non ci sono linee guida precise in questo senso, tuttavia tutti sono d\u2019accordo sul fatto che rendere noto un bug senza prima avvisare gli sviluppatori non sia un comportamento corretto.<\/p>\n<p><em>Cosa \u00e8 stato trovato?<\/em><\/p>\n<p>Si tratta di un caso tipico in cui gli sviluppatori non sono stati avvisati o solo con breve anticipo per cui non hanno avuto il tempo di reagire\u2026 Il ricercatore 18 enne Luca Todesco ha pubblicato le info di un\u2019importante vulnerabilit\u00e0 presente in Mac OS Yosemite e Mavericks (10.9.5 \u2014 10.10.5), che consentirebbe ai cybercriminali di ottenere l\u2019accesso root ai dispositivi colpiti.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Inside the unpatched OS X vulnerabilities <a href=\"https:\/\/t.co\/4mUVYrtVwa\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/4mUVYrtVwa<\/a><\/p>\n<p>\u2014 Eugene Kaspersky (@e_kaspersky) <a href=\"https:\/\/twitter.com\/e_kaspersky\/status\/634056512868978688?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 19, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Il bug non pu\u00f2 essere sfruttato in remoto: il cybercriminale dovrebbe convincere l\u2019utente a scaricare e a eseguire un exploit (cosa comunque fattibile). \u00c8 disponibile anche un proof of concept, da prendere e usare.<\/p>\n<p><em>In che modo si \u00e8 risolto il problema? <\/em><\/p>\n<p>Bene, non \u00e8 finita qui. In base a quanto dice il ricercatore, ha provato a mettersi in contatto molte volte con Apple ma non ha ricevuto risposta. Non lo preoccupa il fatto di aver pubblicato una vulnerabilit\u00e0 cos\u00ec importante: dice di <a href=\"https:\/\/twitter.com\/qwertyoruiop\/status\/632966294804017153\" target=\"_blank\" rel=\"noopener nofollow\">aver soltanto provato<\/a> un nuovo modo di fare jailbreak, nulla dell\u2019altro mondo.<\/p>\n<p>https:\/\/twitter.com\/qwertyoruiop\/status\/632966294804017153<\/p>\n<p>Un paragone che non sta molto in piedi: il jailbreak \u00e8 un\u2019attivit\u00e0 che gli utenti, ben consapevoli di ci\u00f2 che stanno facendo, decidono di compiere. Non si pu\u00f2 eseguire il jailbrake a insaputa, \u00e8 l\u2019utente che decide. Non \u00e8 sempre il caso del bug scoperto da Todesco. Non ci meravigliamo che abbia ricevuto <a href=\"https:\/\/twitter.com\/engadget\/status\/633385331476287489\" target=\"_blank\" rel=\"noopener nofollow\">dure critiche<\/a>:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Developer reveals Mac security hole without telling Apple <a href=\"http:\/\/t.co\/siVCVIP3Ff\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/siVCVIP3Ff<\/a> <a href=\"http:\/\/t.co\/UUrECGbwJu\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/UUrECGbwJu<\/a><\/p>\n<p>\u2014 Engadget (@engadget) <a href=\"https:\/\/twitter.com\/engadget\/status\/633385331476287489?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 17, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Non \u00e8 ancora chiaro se questo bug appena scoperto riguardi anche il nuovo Mac OS X El Capitan. Non vedo l\u2019ora che esca la patch.<\/p>\n<p><strong>Cos\u2019altro?<\/strong><\/p>\n<p>Microsoft <a href=\"https:\/\/threatpost.com\/emergency-ie-patch-fixes-vulnerability-under-attack\/\" target=\"_blank\" rel=\"noopener nofollow\">ha pubblicato la patch<\/a> per un bug su Internet Explorer (per lo meno qualcuno fa qualcosa), una misura straordinaria (la seconda questo mese).<\/p>\n<p>I dati personali del sito di incontri per persone sposate Ashley Madison, <a href=\"https:\/\/www.kaspersky.it\/blog\/cheating-website-hacked\/6347\/\" target=\"_blank\" rel=\"noopener\">rubati tempo fa dagli hacker<\/a>, ora sono <a href=\"https:\/\/www.kaspersky.it\/blog\/ashley-madison-data-finally-leaked\/6471\/\" target=\"_blank\" rel=\"noopener\">online<\/a>, come preannunciato dal gruppo responsabile dell\u2019attacco.<\/p>\n<p>https:\/\/twitter.com\/kaspersky\/status\/634349398198218752<\/p>\n<p>Kaspersky Lab <a href=\"https:\/\/securelist.com\/blog\/research\/71876\/new-activity-of-the-blue-termite-apt\/\" target=\"_blank\" rel=\"noopener\">ha scoperto<\/a> Blue Termite, un\u2019importante campagna di cyberintelligence che ha colpito molti utenti in Giappone. Non \u00e8 passato inosservato che le spie informatiche, operative da oltre due anni, abbiano intensificato la propria attivit\u00e0 quest\u2019estate, quando hanno avuto tra le mani un exploit per Flash <a href=\"https:\/\/threatpost.com\/apt-group-exploiting-hacking-team-flash-zero-day\/\" target=\"_blank\" rel=\"noopener nofollow\">rubato da The Hacking Team<\/a>.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"fr\" dir=\"ltr\"><a href=\"https:\/\/twitter.com\/hashtag\/BlueTermite?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#BlueTermite<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/APT?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#APT<\/a> exploits <a href=\"https:\/\/twitter.com\/hashtag\/Flash?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Flash<\/a> CVE-2015-5119 exploit to further infection <a href=\"https:\/\/t.co\/Fj0eAJkCTH\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/Fj0eAJkCTH<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/634387066684600320?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 20, 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> <a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233049\/infosec-digest-32-book-800x1024.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright wp-image-4818 size-large\" src=\"https:\/\/www.kaspersky.it\/blog\/files\/2015\/08\/infosec-digest-32-book-800x1024-800x1024.jpg\" alt=\"infosec-digest-32-book\" width=\"800\" height=\"1024\"><\/a><\/p>\n<p>\u201cJustice\u201d<\/p>\n<p>Piuttosto pericoloso, colpisce i file .COM quando chiamati dalle funzioni DOS 43h, 4Bh, 3Dh, 56h. Il malware viene scritto alla fine del file e altera 5 byte dell\u2019inizio del codice (NOP; NOP; JMP Loc_Virus). Il metodo, che compromette COMMAND.COM, \u00e8 lo stesso usato con il virus Lehigh. Si appropria regolarmente di dati scritti sul drive e li scrive in un settore diverso. E poi contiene il testo \u201cAND JUSTICE FOR ALL\u201d. Effettua l\u2019hijack di int 13h e int 21h.<\/p>\n<p>Citazione da <em>\u201cComputer viruses in MS-DOS<\/em><em>\u201d di Eugene Kaspersky, 1992. Pag. 72<\/em><\/p>\n<p><em>Dichiarazione di non responsabilit\u00e0: questo articolo riflette la persona opinione dell\u2019autore. Pu\u00f2 coincidere o no con la posizione di Kaspersky Lab.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ci sono tanti motivi per cui un bug non viene risolto immediatamente, o forse mai. In ogni caso, bisogna pur sempre trovare una soluzione. <\/p>\n","protected":false},"author":53,"featured_media":6527,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2641,12],"tags":[70,3,622,1586,1569,33,24,538,1585,1584,45,584],"class_list":{"0":"post-6526","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-android","10":"tag-apple","11":"tag-bug","12":"tag-def-com","13":"tag-defcon23","14":"tag-google","15":"tag-os-x","16":"tag-patch","17":"tag-scada","18":"tag-schneider-electric","19":"tag-sicurezza","20":"tag-vulnerabilita"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-34\/6526\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-34\/5862\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-34\/6149\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-34\/6011\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-34\/6665\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-34\/8644\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-34\/9637\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-34\/4813\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-34\/6005\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-34\/8687\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-34\/8644\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-34\/9637\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-34\/9637\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/android\/","name":"Android"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6526","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=6526"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6526\/revisions"}],"predecessor-version":[{"id":11419,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6526\/revisions\/11419"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/6527"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=6526"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=6526"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=6526"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}