NotPe­tya / Ex­pe­tr : re­tour sur une at­taque in­for­ma­tique qui change le monde

RE­TOUR SUR UNE AT­TAQUE IN­FOR­MA­TIQUE QUI CHANGE LE MONDE

L'Informaticien - - SOMMAIRE - ÉMILIEN ERCOLANI

Parce qu’elle a pris racines il y a une quin­zaine d’an­nées et à cause de son mode opé­ra­toire, de sa préparation et du but fi­nal de ses au­teurs hors du com­mun, l’at­taque NotPe­tya/ Ex­Pe­tr est en soi une of­fen­sive que nous n’avions en­core ja­mais vue. Le temps est ve­nu de l’ana­lyse, tout comme ce­lui de la ma­nière de se pré­pa­rer à ce que nous ré­serve l’ave­nir en ma­tière de dé­fense et de cybersécurité.

Sa­viez-vous qu’en­vi­ron 90 % des échanges de mar­chan­dises dans le monde sont réa­li­sés par ba­teau ? Alors, le mar­di 27 juin, quand le monde a ap­pris que les sys­tèmes in­for­ma­tiques de la plus grande en­tre­prise da­noise, Maersk Line, le grand ar­ma­teur qui em­ploie plus de 100 000 per­sonnes, avaient été tou­chés par un mal­ware in­con­nu, le monde ma­ri­time a lé­gè­re­ment tan­gué. L’en­tre­prise re­pré­sente à elle seule 18 % du trans­port de contai­ners. Dans le mi­lieu, les sys­tèmes de com­mu­ni­ca­tion sont cri­tiques afin d’or­ga­ni­ser les opé­ra­tions quo­ti­diennes des na­vires et un simple in­ci­dent peut avoir de grandes consé­quences. Lorsque les sys­tèmes de com­mu­ni­ca­tion des ports aux États- Unis, en Es­pagne, en Inde ou aux Pays- Bas ne ré­pondent plus, c’est la pa­nique à bord. Au South Flo­ri­da Con­tai­ner Ter­mi­nal, près de Mia­mi, plu­sieurs car­gos sont coin­cés et les contai­ners ne peuvent être dé­bar­qués. En Inde, le port Ja­wa­har­lal Neh­ru, si­tué près de Mum­bai et Bom­bay, les opé­ra­tions sont là aus­si per­tur­bées. « Nous sommes dans l’at­tente, sans sa­voir quand tout va re­ve­nir à la nor­male » , ex­pli­que­ra ain­si Anil Dig­gi­kar, le di­rec­teur du port. Il se contente de se faire l’écho de Maersk Line, dont le per­son­nel in­for­ma­tique est en pleine ef­fer­ves­cence. L’im­pact de l’at­taque qui vient de se pro­duire a des ré­per­cus­sions sur l’en­semble de l’in­dus­trie ma­ri­time, ain­si que dans les 76 ports dont l’en­tre­prise da­noise a la gé­rance via sa di­vi­sion APM Ter­mi­nal.

Mars 2016 : Pe­tya

Les équipes in­for­ma­tiques de Maersk Line ne le savent pas en­core, mais elles viennent d’être vic­times d’un mal­ware qui va faire beau­coup de bruit. Elles ignorent aus­si qu’il leur fau­dra plu­sieurs se­maines pour tout re­mettre en ordre. Le 20 juillet, soit presque un mois plus tard, l’ar­ma­teur ex­plique que si les sys­tèmes de com­mu­ni­ca­tion ont bel et bien été tou­chés, il n’a en re­vanche consta­té « au­cune faille ni perte de don­nées d’une tierce par­tie » , no­tam­ment

parce que le mal­ware « n’a pas pu

se ré­pandre entre dif­fé­rents ré­seaux » . Mais pour­quoi une telle en­tre­prise a-t- elle été vic­time de cette cy­be­rat­taque ? La dé­fense est ban­cale : ni les patchs de Mi­cro­soft, ni les lo­gi­ciels an­ti­vi­rus n’au­raient pu ga­ran­tir une pro­tec­tion to­tale, et mal­gré ses dé­fenses in­for­ma­tiques, le ver a été in­tro­duit dans la pomme. C’est une étrange ré­ac­tion, qui cache peut- être des né­gli­gences dont a fait preuve Maersk Line. Tou­jours est- il que le 27 juin, les équipes in­for­ma­tiques pensent, comme beau­coup d’autres à ce mo­ment, avoir été tou­chées par le ran­som­ware Pe­tya. Ap­pa­ru en

mars 2016, il est à lui seul presque un nou­veau genre et fait dé­jà trem­bler à l’époque, alors que le monde de l’in­for­ma­tique se re­met­tait à peine de Lo­cky. Il fait ses pre­mières ap­pa­ri­tions en Al­le­magne no­tam­ment, en se pro­pa­geant par phi­shing, pro­po­sant des liens dans les e-mails sen­sés re­di­ri­ger vers un té­lé­char­ge­ment sur Drop­box. L’ori­gi­na­li­té de Pe­tya, à l’époque, était que le ran­som­ware ne se conten­tait pas de chif­frer les fi­chiers du disque comme le fai­saient « tra­di­tion­nel­le­ment » les autres. Il chif­frait éga­le­ment et sur­tout la MFT ( Mas­ter File Table), pour Table de fi­chiers prin­ci­pale, avec un sys­tème étran­ge­ment ba­sique puis­qu’il s’agit du cryp­tage XOR. Une fois in­tro­duit dans la ma­chine, Pe­tya conti­nuait en rem­pla­çant la MBR (Mas­ter Boot Re­cord), la zone d’amorce, qui est par exemple pour les PC à ar­chi­tec­ture In­tel le pre­mier sec­teur adres­sable d’un disque dur. S’en­sui­vait un re­dé­mar­rage for­cé de Windows. Vous connais­sez la suite puis­qu’elle res­semble à un écran rouge, une tête de mort et une de­mande de ran­çon ! En l’oc­cur­rence en­vi­ron 400 dol­lars à payer en bit­coins.

12 mai 2017 : Wa­naC­rypt

Les équipes in­for­ma­tiques de Maersk Line com­pren­dront ra­pi­de­ment que ce n’est pas Pe­tya qui les a frap­pées, mais une « va­riante » bien plus évo­luée que l’on a ra­pi­de­ment nom­mée NotPe­tya. Ef­fec­ti­ve­ment, après avoir cru au dé­but que c’était Pe­tya, les cher­cheurs et la com­mu­nau­té mon­diale se sont ra­pi­de­ment unis au­tour du nom NotPe­tya pour dé­fi­nir le mal­ware ; sans pour au­tant sa­voir quel était son but ou son fonc­tion­ne­ment exact. Mais pour com­prendre jus­te­ment comment fonc­tionne le mal­ware, il faut re­gar­der ce qu’il s’est pas­sé ces der­nières an­nées. Et le pre­mier élé­ment de ré­ponse est ré­cent puis­qu’il s’agit d’un autre mal­ware qui a beau­coup fait cou­ler d’encre : Wa­naC­rypt. Plus de 300 000 uti­li­sa­teurs avaient été sa vic­time, prin­ci­pa­le­ment dans les en­tre­prises. L’at­taque avait été très re­mar­quée car elle fut la pre­mière cy­be­rat­taque par ran­som­wares. En juin, dans L’In­for­ma­ti­cien n°158, nous ex­pli­quions dé­jà que ce n’était que la pre­mière d’une longue sé­rie. Wa­naC­rypt tou­chait les OS Windows via une faille bap­ti­sée Eter­nal Blue qui était pour­tant pat­chée par Mi­cro­soft de­puis mars der­nier (bul­le­tin de sé­cu­ri­té MS17- 010) ; toutes les ver­sions (Vis­ta, 7, 8, 8.1, y com­pris Windows XP) en plus de Windows Ser­ver 2008/2008 R2/2012/2012 R2/2016 étaient concer­nées. En France, plu­sieurs en­tre­prises ont été af­fec­tées, no­tam­ment Re­nault dont la qua­si-to­ta­li­té des usines a été tou­chée. L’ex­ploit Eter­nal Blue a toute son im­por­tance car il est is­su de do­cu­ments vo­lés à la NSA par le dé­sor­mais cé­lèbre groupe The Sha­dow Bro­kers. « Nous avons vu des failles gar­dées par la CIA ap­pa­raître sur Wi­kiLeaks, et main­te­nant cette faille vo­lée à la NSA a af­fec­té des clients au­tour du monde » , ex­pli­quait alors Brad Smith, pré­sident de Mi­cro­soft. Si de nom­breuses en­tre­prises ont été vic­times de Wa­naC­rypt, c’est parce qu’un grand nombre d’entre

elles n’a pas ap­pli­qué le patch MS17010. La cy­be­rat­taque au­ra eu le mé­rite d’en faire ré­agir quel­que­sunes, bien que la com­mu­nau­té mon­diale de la cybersécurité s’ac­ti­vant, les dé­gâts furent alors très li­mi­tés par rap­port au po­ten­tiel ini­tial. En ef­fet, après ra­pide ana­lyse, le cher­cheur dont le pseu­do­nyme est Mal­wa­reTech re­marque que le programme en­voie une re­quête HTTP à un nom de do­maine long et com­plexe, mais non en­re­gis­tré, qu’il achète im­mé­dia­te­ment. C’est à ce mo­ment-là que la pro­pa­ga­tion du ran­som­ware s’ar­rête, alors que les ser­veurs du nom de do­maine étaient dan­ge­reu­se­ment sur­char­gés de re­quêtes. C’est ce qu’on a ap­pe­lé le kill switch ; une fonc­tion a prio­ri im­plé­men­tée pour ten­ter de gar­der le contrôle de la cy­be­rat­taque. Les ha­ckers ayant com­pris que leur as­tuce avait été dé­jouée, ils ont alors uti­li­sé un se­cond nom de do­maine. Re­be­lote : il est aus­si­tôt ache­té par les cher­cheurs. Les at­ta­quants ont alors éla­bo­ré une troi­sième ver­sion en en­le­vant le kill switch. Coup de chance, cette nou­velle mou­ture de Wa­naC­rypt s’avère dé­fec­tueuse.

27 juin 2017 : NotPe­tya/Ex­Pe­tr

Nous avons vu que Wa­naC­rypt s’ap­puyait sur l’ex­ploit Eter­nal Blue de Windows. NotPe­tya a fait de même,

en plus de pas­ser par un autre ex­ploit : Eter­nal Ro­mance. Tous deux sont is­sus du vol de do­cu­ments à la NSA par le groupe The Sha­dow Bro­kers, dont nous avons ap­pris l’exis­tence en 2016. Alors que Wa­nac­rypt s’est dé­ployé avec un ef­fet boule de neige, la pro­pa­ga­tion de NotPe­tya/Ex­Pe­tr fut plus lente. En fait, elle est sur­ve­nue via le ha­cking d’un lo­gi­ciel ukrai­nien de comp­ta­bi­li­té bap­ti­sé « MeDoc ». Les pi­rates au­raient uti­li­sé la fonc­tion­na­li­té de mise à jour au­to­ma­tique pour dif­fu­ser le mal­ware/ran­som­ware sur tous les postes uti­li­sant le­dit lo­gi­ciel. C’est donc le mode de pro­pa­ga­tion de NotPe­tya qui dif­fère : il dis­po­sait de trois vec­teurs de pro­pa­ga­tion, dont le pre­mier via le pro­to­cole SMB de Windows mais sur un ré­seau lo­cal. Le mal­ware vé­ri­fiait la pré­sence du fi­chier C:\Windows\perfc avant de con­ti­nuer son exé­cu­tion. Des droits éle­vés per­mettent au mal­ware de vo­ler les mots de passe lo­caux, soit en uti­li­sant un ou­til de type Mi­mi­katz en ver­sion 32 et 64 bits, soit en fai­sant ap­pel à l’API CredE­nu­me­ra­teW. Il dis­po­sait de plu­sieurs ca­pa­ci­tés pour se pro­pa­ger sur le ré­seau : • en uti­li­sant les iden­ti­fiants ré­cu­pé­rés sur la ma­chine ; • en ex­ploi­tant des vul­né­ra­bi­li­tés du pro­to­cole SMB (iden­ti­fiées dans le bul­le­tin MS17- 010). Après pro­pa­ga­tion, le mal­ware force un re­dé­mar­rage de la ma­chine via une tâche pla­ni­fiée. Un mes­sage est alors af­fi­ché in­di­quant qu’une vé­ri­fi­ca­tion de l’in­té­gri­té des disques est en cours. Le ran­çon­gi­ciel se­rait en fait en train de chif­frer la Mas­ter File Table ( MFT). Ce­la rend in­ac­ces­sibles les fi­chiers pré­sents sur la ma­chine. En­fin, le mal­ware s’ins­talle à la place du sec­teur de dé­mar­rage de Windows afin d’af­fi­cher le mes­sage de ran­çon. Le deuxième vec­teur est un ex­ploit mo­dif ié Eter­nalB­lue vi­sant le ser­vice Windows SMBv1, aus­si uti­li­sé par Wan­naC­ry et les vul­né­ra­bi­li­tés Mi­cro­soft CVE- 20170146 ( Windows SMB Re­mote Code Exe­cu­tion Vul­ne­ra­bi­li­ty), Mi­cro­soft CVE- 2017- 0147 ( Windows SMB In­for­ma­tion Dis­clo­sure Vul­ne­ra­bi­li­ty), Mi­cro­soft CVE-2017- 0143 ( Windows SMB Re­mote Code Exe­cut ion Vul­ne­ra­bi­li­ty), Mi­cro­soft CVE2017- 0145 ( Windows SMB Re­mote Code Exe­cu­tion Vul­ne­ra­bi­li­ty), Mi­cro­soft CVE-2017- 0148 ( Windows SMB Re­mote Code Exe­cut ion Vul­ne­ra­bi­li­ty), Mi­cro­soft CVE-20170144 ( Windows SMB Re­mote Code Exe­cu­tion Vul­ne­ra­bi­li­ty). En­fin, le troi­sième vec­teur est un ex­ploit Eter­nel Ro­mance 1.3.0, un code d’exé­cu­tion ci­blant les OS Windows XP, 2003, Vis­ta, 7, 8, Windows 2008 et 2008 R2 sur le port 445 ( bul­le­tin de sé­cu­ri­té et patch Mi­cro­soft MS17- 010). D’où la

pro­pa­ga­tion très ra­pide à tra­vers les ré­seaux sur des or­ga­ni­sa­tions comme Au­chan, SNCF, Saint- Go­bain ou le géant pu­bli­ci­taire WPP, en ce qui concerne uni­que­ment la France.

NotPe­tya : plu­tôt un wi­per ?

Après l’avè­ne­ment de NotPe­tya, la com­mu­nau­té mon­diale de la cybersécurité s’est ra­pi­de­ment mise en marche. Deux jours plus tard, le 29 juin, l’édi­teur Kas­pers­ky ex­plique que le mal­ware n’est peut- être pas ce que l’on croit. Ce ne se­rait pas un ran­som­ware, mais un « wi­per ». En d’autres termes, le mal­ware au­rait cher­ché à se faire pas­ser pour ce

qu’il n’était pas avec un but pré­cis : dé­truire de la don­née, et ac­ces­soi­re­ment brouiller les pistes. C’est le cher­cheur Matthieu Suiche qui a poin­té une dif­fé­rence ma­jeure entre le ran­som­ware Pe­tya de 2016 et le NotPe­tya de 2017. Si le pre­mier mo­di­fiait le disque de ma­nière à pou­voir chif­frer et dé­chif­frer les don­nées, le se­cond va écra­ser un cer­tain nombre de blocs sec­to­riels du disque. Tou­te­fois ces blocs sont gé­né­ra­le­ment in­uti­li­sés sur la plu­part des ma­chines. Une autre ex­per­tise va dans le sens de la théo­rie « wi­per ». Au dé­but de l’at­taque, l’adresse mail uti­li­sée par les at­ta­quants avait été blo­quée dans les pre­mières heures de la pro­pa­ga­tion du ran­som­ware, sans que ce­la semble gran­de­ment le per­tur­ber. Nor­mal, ré­pon­dait Kas­pers­ky, quand bien même ils au­raient ob­te­nu moult ran­çons, les au­teurs de NotPe­tya au­raient été bien in­ca­pables de four­nir une clé de dé­chif­fre­ment. L’iden­ti­fiant d’ins­tal­la­tion, in­dis­pen­sable à l’ob­ten­tion de la clé, n’est en fait, se­lon l’édi­teur russe, qu’un amas de ca­rac­tères gé­né­ré aléa­toi­re­ment, d’où il est im­pos­sible de re­ti­rer la moindre in­for­ma­tion per­met­tant de dé­chif­frer le disque. « Ce que ce­la si­gni­fie ? D’une part, même si la vic­time paie, elle ne ré­cu­pé­re­ra pas ses don­nées. Deuxiè­me­ment, ce­la ren­force la théo­rie se­lon la­quelle le prin­ci­pal ob­jec­tif d’Ex­Pe­tr n’était pas fi­nan­cier, mais bien des­truc­teur. »

Pro­tec­tion : ce qu’en disent les ex­perts

Ce que l’on a vu ces der­niers mois avec Wa­naC­rypt, NotPe­tya ou même Adyl­kuzz nous ap­prend beau­coup de choses et no­tam­ment que nous ne sommes pas à l’abri de me­naces in­con­nues qui peuvent frap­per les ma­chines. Comment alors se pro­té­ger de la ma­nière la plus ef­fi­cace pos­sible ? Tous les édi­teurs vous di­ront qu’ils ont les meilleures so­lu­tions. Mais l’im­por­tant est plu­tôt d’an­ti­ci­per. Lors d’un we­bi­naire or­ga­ni­sé par notre ma­ga­zine dé­but juillet (*), le cher­cheur Re­naud Lif­chitz, chez Di­gi­tal Se­cu­ri­ty, es­ti­mait par exemple que

des at­taques via les sys­tèmes de mises à jour vont se mul­ti­plier, sur WSUS ( Windows Ser­ver Up­date Services) par exemple, en sub­sti­tuant une mise à jour par une autre « no­tam­ment dans des in­tra­nets avec des at­taques type

Man in the Middle » . « Il faut pen­ser en termes de cy­ber- ré­si­lience plu­tôt qu’en termes de cybersécurité » , ex­pli­quait pour sa par t Laurent Hes­lault, chez Sy­man­tec. Et donc en par­tant du prin­cipe que de nou­velles at­taques

vont ar­ri­ver. « La no­tion de cor­rec­tifs est es­sen­tielle, mais ce n’est qu’un des élé­ments de la chaîne » ,

ajoute- t- il. « Nous sommes en gé­né­ral tou­jours en re­tard par rap­port aux cy­ber- at­ta­quants » , ex­pli­quait pour sa part Ni­co­las Ster­ck­mans, chez Mal­wa­reBytes. Pour Re­naud Lif­chitz, l’un des pre­miers élé­ments de ré­ponse ré­side dans l’ad­mi­nis­tra­tion des sys­tèmes, par exemple évi­ter les su­per- ad­mi­nis­tra­teurs et les rem­pla­cer par des ad­mi­nis­tra­teurs en fonc­tion des zones du ré­seau. Le cloi­son­ne­ment des ré­seaux est aus­si un su­jet pri­mor­dial, no­tam­ment pour des sys­tèmes an­ciens que l’on sait plus faibles. La vir­tua­li­sa­tion peut aus­si être une ré­ponse pour cette vi­sion de la ré­si­lience. Pa­ral­lè­le­ment, les tech­niques des édi­teurs évo­luent et l’intelligence artificielle prend une place consi­dé­rable dans le monde de la cybersécurité. « Chez Mal­wa­reBytes, nous tra­vaillons

avec l’IA sur l’ana­lyse de la chaîne d’at­taque afin de l’in­ter­rompre, au lieu de tra­vailler sur la me­nace en el­le­même » , ex­plique Ni­co­las Ster­ck­mans. En ma­tière de tech­niques d’ave­nir, le chif­fre­ment « full ho­mo­morphe » est « un pro­ces­sus en­core lourd à mettre en place, des so­lu­tions in­ter­mé­diaires existent mais manquent de sca­la­bi

li­té » , ana­lyse Re­naud Lif­chitz. Quoi qu’il en soit, tous s’ac­cordent pour dire que les scénarios de risque existent et conti­nue­ront à exis­ter. Mais peut- être que la phi­lo­so­phie sé­cu­ri­taire des en­tre­prises, ai­dée par un ap­pui des di­rec­tions gé­né­rales en pleine prise de conscience, doit, elle aus­si, sor­tir de sa zone de confort.

EN MARS 2016, LE RAN­SOM­WARE PE­TYA TOUCHE DES MIL­LIERS DE MA­CHINES DANS LE MONDE.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.