{"id":4813,"date":"2015-08-24T14:41:54","date_gmt":"2015-08-24T14:41:54","guid":{"rendered":"https:\/\/kasperskydaily.com\/france\/?p=4813"},"modified":"2019-11-22T09:16:40","modified_gmt":"2019-11-22T09:16:40","slug":"security-week-34","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/security-week-34\/4813\/","title":{"rendered":"La s\u00e9curit\u00e9 pendant la semaine 34 : les patchs ne suffisent pas"},"content":{"rendered":"<p>Quelle semaine \u00e9pouvantable pour le monde de la s\u00e9curit\u00e9 informatique, mes amis ! Apr\u00e8s une semaine amusante pendant laquelle nous avons d\u00e9couvert des bugs, des exploits zero-day et d\u2019autres raret\u00e9s convoit\u00e9es par les chercheurs, voici le contrecoup douloureux d\u2019avoir vu toutes ces intrusions dans des softwares vuln\u00e9rables. C\u2019est important, mais parfois tr\u00e8s ennuyeux. A chaque fois, je me nourris gr\u00e2ce \u00e0 une nouvelle fourn\u00e9e d\u2019articles sur la s\u00e9curit\u00e9 informatique parus sur notre blog d\u2019actualit\u00e9 Threatpost. Les trois articles qui font les gros titres sur les patchs sont plut\u00f4t difficiles \u00e0 dig\u00e9rer.<\/p>\n<p>Bon, quoi qu\u2019il en soit, c\u2019est important. On ne peut pas simplement trouver une vuln\u00e9rabilit\u00e9, comme ils disent. Le plus difficile, c\u2019est de la corriger sans tout d\u00e9truire. On peut trouver de nombreuses raisons de ne pas corriger un bug imm\u00e9diatement, ni ce semestre, ni m\u00eame jamais. Pourtant, il faut r\u00e9soudre le probl\u00e8me.<br>\nAujourd\u2019hui, nous pr\u00e9senterons trois cas de bugs qui n\u2019ont malheureusement pas \u00e9t\u00e9 corrig\u00e9s. Pour rappel, chaque semaine, l\u2019\u00e9quipe de Threatpost choisit trois nouvelles importantes que je vais commenter en longueur. Vous trouverez ici les articles pr\u00e9c\u00e9dents.<\/p>\n<h3>Autre bug sur Android, maintenant dans Google Admin<\/h3>\n<p>L\u2019article du Threatpost. Les recherches de MWR.<\/p>\n<p><em>Qu\u2019est-ce qui a \u00e9t\u00e9 d\u00e9couvert ?<\/em><\/p>\n<p>Avez-vous d\u00e9j\u00e0 remarqu\u00e9 ces merveilleux articles sur des bugs qui paraissent en masse derni\u00e8rement ? Eh bien, une voiture a \u00e9t\u00e9 pirat\u00e9e ? Voici une demi-douzaine de vuln\u00e9rabilit\u00e9s trouv\u00e9es dans des voitures ! D\u2019abord, la faille Stagefright, ensuite quelques petits bugs, et maintenant, Google Admin et une fuite du sandbox.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095502\/security-week-34-kid.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-4815\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095502\/security-week-34-kid-1024x682.jpg\" alt=\"security-week-34-kid\" width=\"1024\" height=\"682\"><\/a><\/p>\n<p>Google Admin, l\u2019une des applications du syst\u00e8me Android, peut accepter des URL d\u2019autres applications. Apparemment, n\u2019importe quelle URL fonctionne, m\u00eame celles qui commencent par \u00ab\u00a0file:\/\/\u00a0\u00bb. Par cons\u00e9quent, une simple action sur le r\u00e9seau, comme le chargement de sites Web, commence dans une sorte de gestionnaire de fichiers. Toutes les applications sur Android ne sont-elles pas isol\u00e9es les unes des autres ? Zut, ce n\u2019est pas le cas ! Google Admin jouit de privil\u00e8ges, et en le trompant avec une URL ind\u00e9sirable, une application peut s\u2019\u00e9chapper du sandbox et acc\u00e9der \u00e0 des donn\u00e9es priv\u00e9es.<\/p>\n<p><em>Comment cela a \u00e9t\u00e9 corrig\u00e9 ?<\/em><\/p>\n<p>Tout d\u2019abord, permettez-moi de vous expliquer comment cette vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9voil\u00e9e par des chercheurs ind\u00e9pendants. Elle n\u2019a \u00e9t\u00e9 d\u00e9couverte qu\u2019au mois de mars, avec l\u2019envoi d\u2019un rapport \u00e0 Google. Cinq mois plus tard, les chercheurs ont de nouveau regard\u00e9 ce qui se passait et se sont aper\u00e7us que le bug n\u2019avait toujours pas \u00e9t\u00e9 corrig\u00e9. Le 13 ao\u00fbt, l\u2019information sur le bug a \u00e9t\u00e9 d\u00e9voil\u00e9e publiquement, incitant Google a publi\u00e9 enfin un patch.<\/p>\n<p>Au fait, Google poss\u00e8de une \u00e9quipe interne de chercheurs qui consacre son temps et ses efforts \u00e0 traquer les bugs de partout, et pas seulement sur leurs propres softwares. Le Project Zero de Google accorde en g\u00e9n\u00e9ral 90 jours \u00e0 l\u2019\u00e9quipe avant de rendre public un bug. On peut alors se demander si Google est capable de publier lui-m\u00eame un patch pendant cette p\u00e9riode.<br>\nOr, avec Google Admin, quelque chose n\u2019a pas du tout fonctionn\u00e9. D\u2019abord, il y avait en effet quelque chose qui ne fonctionnait pas. Ensuite, nous savons tous que les patchs ne permettent pas toujours de r\u00e9soudre le probl\u00e8me sur tous les appareils Android vuln\u00e9rables. Des mises \u00e0 jour de s\u00e9curit\u00e9 tous les mois ? Et qu\u2019en est-il d\u2019un patch sur lequel on travaille pendant une demi-ann\u00e9e ? Oui, oui, tout va bien.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/09\/06095442\/security-week-34-kitten.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-4816\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/09\/06095442\/security-week-34-kitten-1024x1024.jpg\" alt=\"security-week-34-kitten\" width=\"1024\" height=\"1024\"><\/a><\/p>\n<h3>Vuln\u00e9rabilit\u00e9 ouverte dans les syst\u00e8mes SCADA de Schneider Electric<\/h3>\n<p>L\u2019article du Threatpost. L\u2019alerte de ICS-CERT.<\/p>\n<p>Bienvenue dans le monde merveilleux d\u2019une infrastructure essentielle ! Veuillez vous assoir, mettez-vous \u00e0 l\u2019aise, n\u2019appuyez pas sur ce bouton rouge effrayant et ne touchez pas \u00e0 ces c\u00e2bles qui sortent bizarrement de cette chose. Oui, il faut qu\u2019ils sortent. C\u2019est normal. Ca fait des ann\u00e9es qu\u2019ils sont comme \u00e7a. Si vous les touchez, nous sommes tous perdus !<br>\nLes syst\u00e8mes SCADA font partie d\u2019infrastructures essentielles. Ces derni\u00e8res sont notamment responsables de la gestion d\u2019\u00e9l\u00e9ments importants, comme les chaudi\u00e8res de vos immeubles ou m\u00eame des centrales nucl\u00e9aires. De tels syst\u00e8mes ne sont pas suppos\u00e9s \u00eatre \u00e9teints ou r\u00e9initialis\u00e9s. Alors, ne jouez pas avec les param\u00e8tres et ne touchez \u00e0 rien !<br>\n<\/p><blockquote class=\"twitter-pullquote\"><p>La #s\u00e9curit\u00e9 pendant la semaine 34 : nouvelles #vuln\u00e9rabilit\u00e9s non corrig\u00e9es sur #Android, Mac #OSX, #SCADA de Schneider Electric et autres<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2FJ9ij&amp;text=+La+%23s%C3%A9curit%C3%A9+pendant+la+semaine+34+%3A+nouvelles+%23vuln%C3%A9rabilit%C3%A9s+non+corrig%C3%A9es+sur+%23Android%2C+Mac+%23OSX%2C+%23SCADA+de+Schneider+Electric+et+autres+\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote><br>\nSi vous avez des questions, n\u2019essayez rien vous-m\u00eame, s\u2019il vous pla\u00eet. Lisez plut\u00f4t notre article \u00e0 ce sujet. Pendant ce temps, reconnaissons quand m\u00eame que, malgr\u00e9 l\u2019importance cruciale de ces syst\u00e8mes, ils sont souvent d\u00e9ploy\u00e9s sur des PC normaux, avec de vieilles versions de Windows. Contrairement aux entreprises classiques, qui mettent \u00e0 jour ou remplacent leurs hardwares et softwares environ une fois tous les cinq ans, certaines installations ou turbines industrielles, qui permettent de conserver \u00e0 l\u2019abri des substances chimiques mortelles, peuvent fonctionner 24h\/24 et 7j\/7 sur un m\u00eame hardware depuis plusieurs d\u00e9cennies.\n<p><em>Qu\u2019est-ce qui a \u00e9t\u00e9 d\u00e9couvert ?<\/em><\/p>\n<p>Eh bien, un grand nombre de bugs a \u00e9t\u00e9 d\u00e9couvert de l\u2019un de ces syst\u00e8mes : Modicon M340 PLC Station P34 CPU de Schneider Electric. En r\u00e9sum\u00e9, cet ensemble de vuln\u00e9rabilit\u00e9s permettrait \u00e0 un intrus de s\u2019emparer de presque tout ce que le syst\u00e8me contr\u00f4le. Une faille majeure a \u00e9t\u00e9 d\u00e9couverte ici (au fait, nous en trouvons souvent dans des routers et autres objets connect\u00e9s) dans les justificatifs d\u2019identit\u00e9 cod\u00e9s mat\u00e9riellement.<\/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>Ce qui a \u00e9t\u00e9 cod\u00e9 mat\u00e9riellement dans les syst\u00e8mes SCADA reste secret (pour des raisons \u00e9videntes de s\u00e9curit\u00e9). Toutefois, nous \u00e9mettons l\u2019hypoth\u00e8se selon laquelle il s\u2019agissait d\u2019identifiants de connexion par d\u00e9faut, qu\u2019un fournisseur avait transmis en vue de simplifier le service, ou d\u2019un test de mot de passe en dehors du code qu\u2019un fournisseur aurait oubli\u00e9 d\u2019effectuer. Ou tout ce que vous voulez.<\/p>\n<p><em>Comment cela a \u00e9t\u00e9 corrig\u00e9 ?<\/em><\/p>\n<p>Le bug n\u2019a pas \u00e9t\u00e9 corrig\u00e9. Deux bonnes semaines se sont \u00e9coul\u00e9es depuis que le chercheur Aditya Sood a pr\u00e9sent\u00e9 cette vuln\u00e9rabilit\u00e9 \u00e0 la conf\u00e9rence DEF CON, et aucun patch n\u2019est encore sorti. C\u2019est plut\u00f4t compr\u00e9hensible. Un fournisseur est confront\u00e9 \u00e0 une t\u00e2che tr\u00e8s difficile. En effet, un travail \u00e9prouvant, tel celui de corriger les softwares vuln\u00e9rables, le devient encore plus car, au moment d\u2019une baisse de productivit\u00e9, un client pourrait causer des pertes consid\u00e9rables. Parfois, une baisse de productivit\u00e9 est tout simplement impossible.<br>\nAlors, combien de temps faudra-t-il pour qu\u2019un patch soit publi\u00e9 ? Pendant combien de temps les op\u00e9rations devront-elles \u00eatre suspendues ? Est-ce que tout rentrera dans l\u2019ordre, ensuite ? Toutes les caract\u00e9ristiques des appareils auront-elles \u00e9t\u00e9 prises en compte ? Dans l\u2019ensemble, la situation est tr\u00e8s emb\u00eatante, mais elle sert aussi de pi\u00e8tre excuse pour ne pas corriger le bug. A de nombreuses reprises, il a \u00e9t\u00e9 prouv\u00e9 que ne pas connecter \u00e0 Internet des infrastructures essentielles, ou de les prot\u00e9ger simplement au moyen d\u2019un pare-feu, ne constituaient pas de bonnes solutions.<\/p>\n<div id=\"attachment_4817\" style=\"width: 650px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095459\/security-week-34-keynote.jpg\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-4817\" class=\"wp-image-4817 size-full\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095459\/security-week-34-keynote.jpg\" alt=\"security-week-34-keynote\" width=\"640\" height=\"480\"><\/a><p id=\"caption-attachment-4817\" class=\"wp-caption-text\">D\u00e9veloppeurs pendant la pr\u00e9sentation<\/p><\/div>\n<p>\u00a0<\/p>\n<h3>Un bug non corrig\u00e9 sur Mac OS X<\/h3>\n<p>L\u2019article du Threatpost.<br>\nUne fois de plus, nous abordons le th\u00e8me de la responsabilit\u00e9 en cas de r\u00e9v\u00e9lation. Pour ce qui est du bug de Google, les chercheurs ont eu cinq mois devant eux avant que l\u2019information ne devienne publique, alors m\u00eame que Google s\u2019impose lui-m\u00eame un d\u00e9lai de 90 jours. Combien de temps devrions-nous attendre ? Combien de temps devrions-nous laisser aux d\u00e9veloppeurs pour qu\u2019ils comblent une telle faille ?<br>\nSi nous leur accordions une p\u00e9riode suffisamment longue, les d\u00e9veloppeurs ne se ramolliraient-ils pas, en remettant toujours \u00e0 plus tard le patch, car ils auraient tout le temps n\u00e9cessaire ? Quoi qu\u2019il en soit, il n\u2019y a pas de d\u00e9lai de rigueur \u00e0 respecter, m\u00eame si tout le monde s\u2019accordera sur le fait que r\u00e9v\u00e9ler un bug au grand public, avant d\u2019en avoir inform\u00e9 les d\u00e9veloppeurs, est une tr\u00e8s mauvaise chose.<\/p>\n<p><em>Qu\u2019est-ce qui a \u00e9t\u00e9 d\u00e9couvert ?<\/em><\/p>\n<p>Voici un bon exemple de cas o\u00f9 les d\u00e9veloppeurs ont \u00e9t\u00e9 avertis, ou non, ou peut-\u00eatre, ou l\u2019ont \u00e9t\u00e9 avec un d\u00e9lai trop court. Dans tous les cas, ils n\u2019ont pas eu suffisamment de temps pour r\u00e9agir. Luca Todesco, un jeune chercheur de 18 ans, a r\u00e9v\u00e9l\u00e9 en d\u00e9tail une vuln\u00e9rabilit\u00e9 grave qu\u2019il a trouv\u00e9e sur Mac OS X Yosemite et Mavericks (10.9.5 \u2013 10.10.5), laquelle permet \u00e0 un attaquant d\u2019obtenir des privil\u00e8ges root sur la machine expos\u00e9e.<\/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>Le bug ne peut pas \u00eatre exploit\u00e9 \u00e0 distance : le pirate devrait pousser l\u2019utilisateur \u00e0 t\u00e9l\u00e9charger et \u00e0 ex\u00e9cuter un exploit (ce qu\u2019il arriverait certainement \u00e0 faire). Il y a aussi une preuve de concept disponible, il suffit de la r\u00e9cup\u00e9rer et de l\u2019utiliser.<\/p>\n<p><em>Comment cela a \u00e9t\u00e9 corrig\u00e9 ?<\/em><\/p>\n<p>Eh bien, cela n\u2019a pas encore \u00e9t\u00e9 corrig\u00e9. Selon le chercheur, il n\u2019a re\u00e7u aucun retour de la part d\u2019Apple, malgr\u00e9 ses nombreuses tentatives pour en obtenir. Le fait d\u2019avoir r\u00e9v\u00e9l\u00e9 publiquement une telle vuln\u00e9rabilit\u00e9 ne l\u2019inqui\u00e8te pas : d\u2019apr\u00e8s lui, il a simplement explor\u00e9 un nouveau jailbreak, c\u2019est tout. Rien de bien grave !<\/p>\n<p>https:\/\/twitter.com\/qwertyoruiop\/status\/632966294804017153<\/p>\n<p>C\u2019est une mauvaise comparaison car un jailbreak est un processus que les utilisateurs, qui savent pr\u00e9cis\u00e9ment ce qu\u2019ils font, d\u00e9cident volontairement d\u2019effectuer. On ne peut pas obliger un utilisateur d\u2019iPhone \u00e0 effectuer un jailbreak sur son appareil, \u00e0 moins que l\u2019utilisateur ne le veuille. Pour le bug d\u00e9couvert par Luca Todesco, ce n\u2019est pas toujours le cas. Rien d\u2019\u00e9tonnant \u00e0 ce qu\u2019il ait \u00e9t\u00e9 vivement critiqu\u00e9 par ses pairs :<\/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>Il n\u2019est pas tr\u00e8s clair si le nouveau bug d\u00e9couvert affecte le nouveau Mac OS X El Capitan. J\u2019attends impatiemment la publication du patch.<\/p>\n<h3>Quelles sont les autres nouvelles ?<\/h3>\n<p>Microsoft a corrig\u00e9 un bug sur Internet Explorer (au moins, quelqu\u2019un a corrig\u00e9 quelque chose) en publiant un patch d\u2019urgence, le deuxi\u00e8me ce mois-ci.<br>\nLes donn\u00e9es priv\u00e9es du site Web Ashley Madison pour les personnes mari\u00e9es, qui avaient \u00e9t\u00e9 vol\u00e9es par des hackers, ont maintenant \u00e9t\u00e9 publi\u00e9es en ligne, tel que l\u2019avait annonc\u00e9 le groupe qui a revendiqu\u00e9 ce piratage.<\/p>\n<p>https:\/\/twitter.com\/kaspersky\/status\/634349398198218752<\/p>\n<p>Kaspersky Lab a d\u00e9couvert Blue Termite, une campagne de cyberintelligence qui se r\u00e9clame d\u00e9j\u00e0 d\u2019un grand nombre de victimes au Japon. Il n\u2019est pas pass\u00e9 inaper\u00e7u que les cyberespions, actifs depuis plus de deux ans, ont soudainement intensifi\u00e9 leurs activit\u00e9s cet \u00e9t\u00e9, d\u00e8s qu\u2019ils ont pu mettre la main sur un exploit de Flash, lequel avait \u00e9t\u00e9 divulgu\u00e9 dans les donn\u00e9es vol\u00e9es par le groupe The Hacking Team.<\/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<h3>Plus ancien<\/h3>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095457\/infosec-digest-32-book.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-4818\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/93\/2015\/08\/06095457\/infosec-digest-32-book-800x1024.jpg\" alt=\"infosec-digest-32-book\" width=\"800\" height=\"1024\"><\/a><\/p>\n<p>\u00ab\u00a0Justice\u00a0\u00bb<\/p>\n<p>Plut\u00f4t dangereux, qui affecte les fichiers .COM avec les fonctions DOS 43h, 4Bh, 3Dh, 56h. Le malware est r\u00e9dig\u00e9 \u00e0 la fin des fichiers et alt\u00e8re 5 bytes au d\u00e9but (NOP; NOP; JMP Loc_Virus). Le processus pour compromettre COMMAND.COM utilise la m\u00eame m\u00e9thode que le virus Lehigh. Il d\u00e9robe r\u00e9guli\u00e8rement des donn\u00e9es enregistr\u00e9es sur le lecteur et les copie \u00e0 un autre endroit. Il contient le texte : \u00a0\u00bb AND JUSTICE FOR ALL \u00ab\u00a0. D\u00e9tournements int 13h et int 21h.<\/p>\n<p><em>Citation tir\u00e9e de l\u2019ouvrage \u00ab\u00a0Computer viruses in MS-DOS\u00a0\u00bb, par Eug\u00e8ne Kaspersky, 1992. Page 72<\/em><br>\n<em>Clause de non-responsabilit\u00e9 : cet article ne refl\u00e8te que l\u2019opinion personnelle de l\u2019auteur. Elle peut correspondre \u00e0 la position de Kaspersky Lab, mais pas n\u00e9cessairement.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>On peut trouver de nombreuses raisons de ne pas corriger un bug imm\u00e9diatement, ni ce semestre, ni m\u00eame jamais. Pourtant, il faut r\u00e9soudre le probl\u00e8me.<\/p>\n","protected":false},"author":53,"featured_media":4814,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6],"tags":[59,29,1209,1210,1184,16,24,789,1208,1207,61,322],"class_list":{"0":"post-4813","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-news","8":"tag-android","9":"tag-apple","10":"tag-bugs","11":"tag-def-com","12":"tag-defcon23","13":"tag-google","14":"tag-os-x","15":"tag-patchs","16":"tag-scada","17":"tag-schneider-electric","18":"tag-securite","19":"tag-vulnerabilites"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-34\/4813\/"},{"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":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-34\/6526\/"},{"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":"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.fr\/blog\/tag\/android\/","name":"android"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/4813","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=4813"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/4813\/revisions"}],"predecessor-version":[{"id":13103,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/4813\/revisions\/13103"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/4814"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=4813"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=4813"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=4813"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}