{"id":6495,"date":"2015-08-18T14:52:49","date_gmt":"2015-08-18T14:52:49","guid":{"rendered":"https:\/\/kasperskydaily.com\/italy\/?p=6495"},"modified":"2017-11-13T17:06:32","modified_gmt":"2017-11-13T15:06:32","slug":"security-week-digest-33","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/security-week-digest-33\/6495\/","title":{"rendered":"Security Week 33: porte senza serrature, Microsoft invulnerabile, disassembler e tanto dolore"},"content":{"rendered":"<p>Benvenuti alla edizione di Security Week di questa settimana. Nel precedetene articolo abbiamo parlato di auto che si bloccano sole, di Stagefright di Android e di come evitare che ci spiino su Internet (ma di fatto continuano a farlo).<\/p>\n<p><strong><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/09\/05235818\/security-week-33-FB.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-6497\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/09\/05235818\/security-week-33-FB-1024x1024.jpg\" alt=\"security-week-33\" width=\"1024\" height=\"1024\"><\/a>\u00a0<\/strong><\/p>\n<p>In questo post tratteremo prima di tutto due notizie che non sembrano avere nulla in comune (ma come vedremo non \u00e8 cos\u00ec): le vulnerabilit\u00e0 spesso scaturiscono dalla negligenza delle persone e dal non voler adottare le misure di sicurezza disponibili. La terza notizia non ha molto a che vedere con la sicurezza, ma tratta piuttosto di alcune relazioni che si stringono all\u2019interno del mondo dell\u2019industria. Tutte e tre le notizie non sono quello che sembrano.<\/p>\n<p>Permettetemi di ricordavi le regole di Security Week: gli editor di <a href=\"https:\/\/threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> selezionano tre notizie tra le principali della settimana a cui io aggiungo alcuni paragrafi e commenti. Potete trovare tutti gli articoli <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=security+week&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">cliccando qui<\/a>.<\/p>\n<p><strong>Hackerando le porte degli hotel<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/blekey-device-breaks-rfid-physical-access-controls\/\" target=\"_blank\" rel=\"noopener nofollow\">Qui la notizia di Threatpost<\/a><\/p>\n<p>Si dice che esiste una dicotomia tra il mondo della scienza e quello delle arti e che gli esperti di queste due discipline difficilmente si capiscono a vicenda. Si \u00e8 soliti pensare che un intellettuale o umanista non possa trasformarsi in un uomo di scienza o in un ingegnere.<\/p>\n<p>Questo luogo comune viene smentito dal musicista John Wiegand. Noto e prestigioso musicista, si dedica alla musica lavorando come <a href=\"http:\/\/machinedesign.com\/engineering-essentials\/brushing-wiegand-man-effect-and-wire-changed-engineering\" target=\"_blank\" rel=\"noopener nofollow\">pianista<\/a> e direttore d\u2019orchestra (anni trenta), fino a quando non inizia a interessarsi al disegno degli amplificatori d\u2019auto. Negli anni quaranta inizia a lavorare su di una delle novit\u00e0 del momento: la registrazione su cassetta. Il 1974 (all\u2019et\u00e0 di 62 anni) \u00e8 poi l\u2019anno in cui realizza la sua pi\u00f9 grande scoperta.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233044\/security-week-33-wiegand-220x300.jpg\" alt=\"\" width=\"220\" height=\"300\"><\/p>\n<p>Quello che \u00e8 noto come interfaccia Wiegand consiste in una serie di cavi magnetici metallici di cobalto in lega di vanadi trattato in modo da formare un tessuto esterno duro attorno ad un nucleo interno morbido. I campi esterni magnetizzano facilmente il guscio, che anch\u2019esso resiste alla smagnetizzazione, persino quando i campi esterno vengono rimossi, una caratteristica chiamata <em>alta coercivit\u00e0. <\/em>All\u2019interno del cavo ha un comportamento diverso, non si magnetizza fino a quando il guscio raggiunge a pieno la magnetizzazione.<\/p>\n<p>Nel momento in cui la parte esterna del cavo si magnetizza completamente e il nucleo centrale riesce ad ottenere la sua porzione di magnetizzazione, sia il nucleo che il guscio scambiano polarit\u00e0. Lo scambio genera un voltaggio significativo che pu\u00f2 essere sfruttato da applicazioni di rilevamento e movimento; \u00e8 utile, per esempio, nel caso di certi sistemi di apertura delle porte degli hotel.<\/p>\n<p>A differenza delle moderne schede, gli \u201czeri e gli uno\u201d non vengono registrati nel chip ma nella sequenza del cablaggio speciale stabilito. \u00c8 impossibile riprogrammare questo tipo di codici e lo schema generale non \u00e8 come quello delle moderne schede per il trasporto pubblico o per i pagamenti bancari entrambe di tipo contactless; il sistema \u00e8 simile alle tessere con banda magnetica, solo pi\u00f9 affidabili.<\/p>\n<p>Dobbiamo quindi scartare card contactless? Non ancora! Wiegand non ha dato solo il nome all\u2019effetto, conosciuto come \u201ceffetto Wiegand\u201d, ma anche al protocollo di scambio dati \u2013 piuttosto vecchio. Tutto quello che riguarda questo protocollo \u00e8 piuttosto negativo. In primo luogo non \u00e8 mai stata standardizzato adeguatamente e esistono numerose implementazione dello stesso.<\/p>\n<blockquote class=\"twitter-pullquote\"><p>Security Week 33: porte senza serrature, Microsoft invulnerabile, disassembler e tanto dolore<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2F6WMn&amp;text=+Security+Week+33%3A+porte+senza+serrature%2C+Microsoft+invulnerabile%2C+disassembler+e+tanto+dolore\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>In secondo luogo, l\u2019ID della scheda pu\u00f2 immagazzinare 16 bit, offrendo poche combinazioni possibili. In terza istanza, il design di queste schede contactless con cablaggio, che erano state invetate prima che imparassimo a inserire un sistema computerizzano in una carta di credito, restringe la lunghezza della chiave a soli 37bit, motivo per credere che il sistema non accetter\u00e0 chiavi pi\u00f9 lunghe.<\/p>\n<p>Di recente, durante la conferenza Black Hat, i ricercatori <a href=\"https:\/\/twitter.com\/ericevenchick\" target=\"_blank\" rel=\"noopener nofollow\">Eric Evenchick<\/a> e <a href=\"https:\/\/twitter.com\/markbaseggio\" target=\"_blank\" rel=\"noopener nofollow\">Mark Baseggio<\/a> hanno mostrato al pubblico i loro dispositivi per l\u2019intercettazione delle sequenze di chiavi (non criptate) in fase di autenticazione. Il dato pi\u00f9 interessante in questo caso \u00e8 che le card non avevano nulla da fare dato che l\u2019informazione viene rubata durante la trasmissione dei dati dal lettore delle schede al sistema di controllo delle porte, dove si utilizza storicamente il protocollo di Wiegand.<\/p>\n<p>Il nome del dispositivo \u00e8 BLEkey, un piccolo hardware che ha bisogno di essere inserito in un lettore di schede, per esempio, come quello usato nelle porte degli hotel. I ricercatori hanno mostrato che l\u2019intera operazione dura pochi secondi. \u00c8 semplice: leggiamo la chiave, aspettiamo che il vero proprietario esca e apra la porta; oppure non aspettiamo o non apriamo mai la porta. Senza entrare troppo in dettagli tecnici, il dialogo tra la porta e il lettore\/wireless si trasforma in una cosa del genere:<\/p>\n<p><em>\u201cChi \u00e8?\u201d<\/em><\/p>\n<p>\u201c<em>Sono io.\u201d<\/em><\/p>\n<p>\u201c<em>A sei tu? Entra!\u201d<\/em><\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Final talk run through! <a href=\"http:\/\/t.co\/TQB472izkO\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/TQB472izkO<\/a><\/p>\n<p>\u2014 Eric Evenchick (@ericevenchick@mastodon.social) (@ericevenchick) <a href=\"https:\/\/twitter.com\/ericevenchick\/status\/629324182459940864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 6, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Sembra facile. Per\u00f2, come sempre, non tutti i sistemi di controllo di accesso sono vulnerabili a questo genere di attacco. E persino quelli che lo sono, possono essere protetti senza essere totalmente rimpiazzati. Secondo i ricercatori, i lettori hanno alcune misure di sicurezza contro gli hackeraggi ma queste funzionalit\u00e0 sono spesso (ehm\u2026) disabilitate.<\/p>\n<p>Queste sistema supporta persino l\u2019<a href=\"http:\/\/www.siaonline.org\/Pages\/Standards\/OSDP.aspx\" target=\"_blank\" rel=\"noopener nofollow\">Open Supervised Device Protocol<\/a> che permette di criptare la sequenza di chiave trasmessa. Ma, ripeto, queste \u201cfunzionalit\u00e0\u201d non vengono usate; non smetter\u00f2 mai dirlo ma sembra proprio che non adottare le misure di sicurezza sia facile e conveniente.<\/p>\n<p>Infine, c\u2019\u00e8 un altro <a href=\"https:\/\/www.defcon.org\/images\/defcon-17\/dc-17-presentations\/defcon-17-mike_davis_who_invented_the_proximity_card.pdf\" target=\"_blank\" rel=\"noopener nofollow\">studio interessante<\/a> del 2009 su questo argomento, con molti dettagli tecnici. Apparentemente, le vulnerabilit\u00e0 delle schede (e non dei lettori) siano state scoperte nel 1992, ma poi si suggeriva che la scheda dovesse essere disassemblata e passata ai raggi X. Per farlo dovevano toglierle ai proprietari. Ora la soluzione si trova in un piccolo dispositivo della dimensione di una moneta. Questo \u00e8 quello che chiamo progresso!<\/p>\n<p><strong>Immunit\u00e0 di Microsoft: gli \u201caltarini aziendali\u201d di Windows Server Update Services<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/manipulating-wsus-to-own-enterprises\/\" target=\"_blank\" rel=\"noopener nofollow\">Qui la notizia di Threatpost<\/a>. La ricerca originale <a href=\"https:\/\/www.blackhat.com\/docs\/us-15\/materials\/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update-wp.pdf\" target=\"_blank\" rel=\"noopener nofollow\">cliccando qui<\/a>.<\/p>\n<p>Windows Server Update Service permette alle grandi aziende di centralizzare l\u2019installazione degli aggiornamenti sui computer attraverso un server interno piuttosto che via fonte esterna. Si tratta di un sistema piuttosto sicuro e molto affidabile. Per i principianti tutti gli aggiornamento devono essere firmati da Microsoft. In secondo luogo, le comunicazioni tra l\u2019update server dell\u2019azienda e il server del vendor sono criptate via protocollo SSL.<\/p>\n<p>\u00c8 un sistema piuttosto semplice. Il server aziendale riceve una lista di aggiornamenti come un file XML dove viene infatti indicato quale, dove e come scaricare l\u2019aggiornamento. Pare per\u00f2 che questa comunicazione avviene in plain text. Scusate, ma non \u00e8 una buona idea comunicare in questo modo. Tutto <strong>deve<\/strong> essere essere criptato e quando lo si implementa in WSUS, \u00e8 fortemente raccomandato abilitare un amministratore per abilitare la crittografia. Ma \u00e8 disabilitata di default.<\/p>\n<p>In fin dei conti per\u00f2, non \u00e8 cos\u00ec terribile perch\u00e9 rimpiazzare le \u201cistruzioni\u201d non \u00e8 facile, ma se un hacker ha la possibilit\u00e0 di intercettare il traffico (per esempio, via attacco man-in-the-middle) lo far\u00e0. I ricercatori Paul Stone and Alex Chapman hanno scoperto che rimpiazzando le istruzioni l\u2019utente potrebbe finir col eseguire un codice arbitrario con alti privilegi sul sistema aggiornato. Microsoft controlla i certificati digitali, ma accetta i certificati di qualsiasi azienda. Per esempio, \u00e8 possibile introdurre clandestinamente un\u2019utility PsExec da\u00a0 SysInternals kit e, con con il suo aiuto, lanciare qualsiasi processo.<\/p>\n<p>Perch\u00e9 succedono queste cose? Il punto \u00e8 abilitare l\u2019SSL utilizzando WSUS non pu\u00f2 essere automatizzato dato che si ha bisogno di generare un certificato. Come sottolineano i ricercatori, in questo caso Microsoft non pu\u00f2 far alto che abilitare l\u2019SSL. Quindi \u00e8 un po\u2019 come se ci fosse e al tempo stesso non ci fosse la vulnerabilit\u00e0. E non c\u2019\u00e8 nulla che pu\u00f2 essere d\u2019aiuto. E la colpa non \u00e8 di nessuno, se non dell\u2019amministratore.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">One of our weaker advertising campaigns for Windows: <a href=\"http:\/\/t.co\/Fon5IvBFnP\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/Fon5IvBFnP<\/a><\/p>\n<p>\u2014 Mark Russinovich (@markrussinovich) <a href=\"https:\/\/twitter.com\/markrussinovich\/status\/631505582139117569?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Kaspersky Lab ha scoperto lo <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">spyware Flame, un\u2019altra minaccia che usava Windows Update<\/a> per infettare le sue vittime, tuttavia lo faceva in un modo doverso: un proxy falso intercettava le richieste inviate al server di Microsoft e i file di risposta inviati erano un po\u2019 diversi e, di fatto, alcuni erano stati firmati dal vendor.<\/p>\n<p><strong>Ingegneria inversa e dolore<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/oracle-cso-you-must-not-reverse-engineer-our-code\" target=\"_blank\" rel=\"noopener nofollow\">Qui la notizia di Threatpost<\/a>. Il post originale di Oracle CSO (la cache di Google cache e un\u2019altra copia \u2013 Internet non dimentica mai).<\/p>\n<p>Le due presentazioni citate sopra del Black Hat sono relazionate dato che gli autori di questi studi (gli esperti di sicurezza informatica) hanno scoperto falle di sicurezza di molte tecnologie e prodotti sviluppati da qualcun\u2019altro. Hanno pubblicato le loro scoperte e nel caso di BLEKey, hanno anche presentato il codice intero e l\u2019hardware di libero accesso. Questo, in generale, \u00e8 il modo normale di interagire con il mondo esterno, ma non a tutti piace questa situazione.<\/p>\n<p>Non mi piace dare giudizi quindi dir\u00f2 solo che si tratta di un argomento molto delicato. \u00c8 giusto analizzare i codici di altre persone? Sotto quali condizioni \u00e8 corretto farlo? In che modo dobbiamo rivelare informazioni sulle vulnerabilit\u00e0? Posso essere pagato per le vulnerabilit\u00e0 che ho scoperto? Restrizioni legislative, codici criminali e leggi non scritte dell\u2019industria, sono tutti elementi che hanno molto peso in questa questione.<\/p>\n<p>Il recente articolo di Mary Ann Davidson, <em>Chief Security Officer<\/em> di Oracle ha avuto un effetto clamoroso. Si intitolava \u201cNo, realmente non puoi\u201d (in inglese <em>No, You Really Can\u2019t<\/em>\u201c) ed \u00e8 quasi interamente dedicato ai propri clienti (non all\u2019industria in generale) che hanno inviato informazioni sulle vulnerabilit\u00e0 che avevano trovato nei prodotti.<\/p>\n<p>Vale la pena menzionare il testo del 10 agosto del 2015 pubblicato nel blog di Oracle, ma menziono solo un punto importante: se un cliente potesse imparare a capire come funzionano le vulnerabilit\u00e0 via ingegneria inversa (dato che \u00e8 l\u2019unico modo), avrebbe violato l\u2019accordo di licenza e perci\u00f2 sarebbe un errore.<\/p>\n<p><strong>\u00a0<img loading=\"lazy\" decoding=\"async\" class=\"alignnone\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/08\/05233043\/security-week-33-sobchak.png\" alt=\"\" width=\"600\" height=\"700\"><\/strong><\/p>\n<p>Ecco qui il brano dove se ne parla:<\/p>\n<p><em>Un cliente non pu\u00f2 analizzare il codice per vedere se c\u2019\u00e8 un processo che possa prevenire un attacco annunciato dal tool responsabile della scansione (il che \u00e8 quasi sempre un falso positivo). Un cliente non pu\u00f2 emettere una patch per risolvere il problema, solo il vendor pu\u00f2 farlo. Il cliente finirebbe col violare l\u2019accordo di licenza usando uno strumento che di analisi statica (che opera contro il codice sorgente). <\/em><\/p>\n<p>La reazione pubblica fu una cosa del genere:<\/p>\n<p>https:\/\/twitter.com\/nicboul\/status\/631183093580341248<\/p>\n<p>O cos\u00ec:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Adobe, Microsoft Push Patches, Oracle Drops Drama <a href=\"http:\/\/t.co\/XN4Tpb9RXw\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/XN4Tpb9RXw<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/oraclefanfic?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#oraclefanfic<\/a><\/p>\n<p>\u2014 briankrebs (@briankrebs) <a href=\"https:\/\/twitter.com\/briankrebs\/status\/631257607530020864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>O persino cos\u00ec:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Don't look for vulns. Fuck bug bounties. We won't even credit you. <a href=\"https:\/\/t.co\/VgCrjGYx1j\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/VgCrjGYx1j<\/a> An <a href=\"https:\/\/twitter.com\/Oracle?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@oracle<\/a> love letter to the security community.<\/p>\n<p>\u2014 Morgan Marquis-Boire (@headhntr) <a href=\"https:\/\/twitter.com\/headhntr\/status\/631081198534664192?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 11, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Il post non dur\u00f2 che un giorno ed \u00e8 stato rimosso per via delle \u201cincongruenze con i punti di vista (ufficiali) sull\u2019interazione con i clienti\u201d (ma Internet non dimentica). Ricordiamo che Oracle sviluppa Java e solo i pigri non sfruttano le vulnerabilit\u00e0 di Java. Tre anni fa abbiamo contato le <a href=\"https:\/\/securelist.com\/analysis\/publications\/57888\/kaspersky-lab-report-java-under-attack\/\" target=\"_blank\" rel=\"noopener\">vulnerabilit\u00e0 di Java<\/a> poer 12 mesi e ne abbiamo trovate 160!<\/p>\n<p>In un mondo ideale, i vendor dei software troverebbero e risolverebbero tutte le vulnerabilit\u00e0 dei propri software, ma purtroppo viviamo nel mondo reale. In questo mondo questo non esiste, anzi quello che spesso accade \u00e8 che chi muove i fili della trama fanno giusto il contrario.<\/p>\n<p><em>Ma vediamo l\u2019altro lato della medaglia.<\/em><\/p>\n<p>La scorsa settimana il fondatore di Black Hat, Jeff Moss, ha parlato dei <a href=\"https:\/\/threatpost.com\/software-liability-is-inevitable\/\" target=\"_blank\" rel=\"noopener nofollow\">vendor di software responsabili delle falle di sicurezza<\/a> nei propri codici. Ha detto che \u00e8\u00a0 ora di disfarsi di EULA e di tutti quei documenti dove si afferma che l\u2019azienda non ha nessuna responsabilit\u00e0 verso i suoi clienti. La dichiarazione \u00e8 interessante ma non meno pretenziosa della frase \u201cVa bandito il disassembler\u201d. Al momento c\u2019\u00e8 solo una cosa chiara: se gli utenti non (aziende e utenti privati), fornitori e ricercatori non possono comprendersi a vicenda\u00a0 questo non verr\u00e0 risolto attraverso dichiarazioni e battute su Twitter.<\/p>\n<p><strong>Che altro \u00e8 successo?<\/strong><\/p>\n<p>Un\u2019altra <a href=\"https:\/\/threatpost.com\/researchers-unveil-square-reader-mobile-pos-hacks\/\" target=\"_blank\" rel=\"noopener nofollow\">presentazione tenutasi durante il Black Hat<\/a> ha trattato l\u2019hackeraggio di Square Reader, quel dispositivo che permetter il pagamento di una merce con lo smartphone. Richiede saldatura.<\/p>\n<p>\u00c8 stato trovato un altro rootkit di un vendor nei portatili Lenovo (non tutti, ma in alcuni). <a href=\"https:\/\/threatpost.com\/lenovo-superfish-certificate-password-cracked\/111165\" target=\"_blank\" rel=\"noopener nofollow\">La notizia qui<\/a>.<\/p>\n<p><strong>Oldies<\/strong><\/p>\n<p><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\"><\/p>\n<p>La \u201cpiccola\u201d famiglia dei malware<\/p>\n<p>I \u201cvirus residenti\u201d in memoria vengono aggiunti alla fine dei file .com (eccetto per i Small-114, -118, -122 che sono scritti all\u2019inizio) quando si\u00a0 caricano i file nella memoria. La maggior parte dei virus usano comandi POPA e PUSHA con processatori \u00a080\u00d786. Small-132, -149 infetta certi file in modo incorretto. Appartengono a diversi autori. Apparentemente, l\u2019origine della \u201cpiccola famiglia\u201d potrebbe essere vista come una gara al virus residente in memoria per MS-DOS pi\u00f9 corto. Rimane solo da decidere il premio per il vincitore.<\/p>\n<p><em>Citazione da: <\/em>\u201c<em>Computer viruses in MS-DOS\u201d di Eugene Kaspersky, 1992, pp. 45.<\/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<p>\u00a0<\/p>\n<p>\u00a0<\/p>\n<p>\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Benvenuti alla edizione di Security Week di questa settimana. Nel precedetene articolo abbiamo parlato di auto che si bloccano sole, di Stagefright di Android e di come evitare che ci<\/p>\n","protected":false},"author":53,"featured_media":6498,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2641,12],"tags":[1580,212],"class_list":{"0":"post-6495","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","10":"tag-sicurezza-it"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-digest-33\/6495\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-digest-33\/5834\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-digest-33\/6121\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-digest-33\/5976\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-digest-33\/6659\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-digest-33\/8592\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-digest-33\/4797\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-digest-33\/5975\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-digest-33\/8636\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-digest-33\/8592\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-digest-33\/9591\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/security-week\/","name":"Security Week"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6495","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=6495"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6495\/revisions"}],"predecessor-version":[{"id":11430,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6495\/revisions\/11430"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/6498"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=6495"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=6495"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=6495"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}