UDP + ser­veur mem­ca­ched ex­po­sé = at­taque DDos mas­sive !

L'Informaticien - - SOMMAIRE - GUILLAUME PéRISSAT

De­puis fin fé­vrier, les at­taques uti­li­sant mem­ca­ched comme vec­teur d’am­pli­fi­ca­tion se sont mul­ti­pliées. Le ser­vice de mé­moire cache dis­tri­bué, très uti­li­sé, peut en ef­fet mul­ti­plier jus­qu’à 51 200 fois la taille du pa­quet en­voyé au ser­veur cible. Avec près de 90 000 ser­veurs mem­ca­ched connec­tés à In­ter­net, non pro­té­gés et port UDP ou­vert, on com­prend que ce vec­teur soit de­ve­nu, en quelques jours, très pri­sé des at­ta­quants.

Le 28 fé­vrier der­nier, Gi­thub su­bit une at­taque DDoS. Rien de nou­veau sous le so­leil, le cé­lèbre site est fré­quem­ment la cible de cam­pagnes mal­veillantes. Mais cette fois- ci, l’in­fra­struc­ture d’Aka­mai, sur la­quelle est ve­nue se ré­fu­gier Gi­thub, doit en­cais­ser une at­taque at­tei­gnant un pic à 1,3 Tbps, su­pé­rieure à ce­lui en­re­gis­tré lors de l’at­taque de DynDNS en oc­tobre 2016, alors consi­dé­rée comme la plus im­por­tante en­re­gis­trée à ce jour. Autre fait no­table à pro­pos de cette at­taque, celle- ci ne s’ap­puie pas sur un bot­net d’ob­jets connec­tés ou de type Mi­rai. Il s’agit là d’une at­taque par am­pli­fi­ca­tion ex­ploi­tant une faille du ser­vice mem­ca­ched, jo­li­ment af­fu­blée par Cloud­flare de l’ap­pel­la­tion « mem­cra­shed » . Le 1er mars, c’est au tour du pa­tron d’OVH, Octave Kla­ba, de rap­por­ter sur Twit­ter avoir ab­sor­bé une at­taque si­mi­laire avec, là en­core, un pic à 1,3 Tbps. Mem­ca­ched est un sys­tème de mé­moire cache dis­tri­buée, qua­li­fiée par OVH de « ser­vice de base de don­nées à clé- va­leur en mé­moire à sto­ckage non per­sis­tant » , met­tant en cache des don­nées – conte­nu sta­tique et ré­sul­tats de re­quête – afin de ré­duire le nombre de fois qu’une source de don­nées ex­ternes doit être lue. De fait, mem­ca­ched est fré­quem­ment uti­li­sé pour amé­lio­rer les per­for­mances des sites web, d’au­tant qu’il est open­source. On le re­trouve ain­si chez YouTube, Red­dit, Fa­ce­book ou en­core Twit­ter. Par dé­faut, il est connec­té sur le port TCP 11211 mais aus­si UDP 11211. « Pour les très grandes ins­tal­la­tions où le nombre de clients est suf­fi­sam­ment éle­vé pour que le nombre de connexions TCP pro­voque des dif­fi­cul­tés d’échelle, il existe éga­le­ment une in­ter­face ba­sée sur UDP » , écrivent les dé­ve­lop­peurs de mem­ca­ched. Et c’est l’avan­tage – mais aus­si l’in­con­vé­nient – d’User Da­ta­gram Pro­to­col, « c’est l’un des meilleurs pro­to­coles à uti­li­ser pour l’am­pli­fi­ca­tion ! » , si­gnale Cloud­flare. « Il n’y a ab­so­lu­ment au­cune vé­ri­fi­ca­tion, et les don­nées se­ront li­vrées au client, à une vi­tesse ful­gu­rante ! De plus, la re­quête peut être mi­nus­cule et la ré­ponse énorme. »

Am­pli­fi­ca­tion : x 51 200

Ad­di­tion­nons main­te­nant ce fac­teur à un grand nombre de ser­veurs mem­ca­ched non pro­té­gés par une au­then­ti­fi­ca­tion et

connec­tés à In­ter­net, au nombre de 88 000, se­lon Sho­dan, prin­ci­pa­le­ment aux États- Unis, en Chine et en France. On ob­tient alors la pos­si­bi­li­té de réa­li­ser des at­taques par dé­ni de ser­vice dis­tri­bué de grande am­pleur en em­ployant des tech­niques d’usur­pa­tion d’adresses IP clas­siques. Plus concrè­te­ment, un at­ta­quant uti­lise un ser­veur usur­pant l’IP de sa vic­time et en­voie sur le port UDP 11211 d’un nombre x de ser­veurs mem­ca­ched non pro­té­gés une re­quête fal­si­fiée. Les ser­veurs mem­ca­ched en­voient alors leur ré­ponse à la re­quête vers la cible, la noyant sous les don­nées. L’am­pli­fi­ca­tion uti­li­sant « mem­cra­shed » fait son pe­tit ef­fet : Cloud­flare ex­plique que pour un pa­quet de re­quête de 15 oc­tets, la ré­ponse du ser­veur est com­prise entre 134 et 750 Ko. Soit un vec­teur d’am­pli­fi­ca­tion pou­vant at­tendre 51 200. « Le meilleur fac­teur d’am­pli­fi­ca­tion qu’on ait ja­mais vu » , sou­ligne Xa­vier Daspre, En­ter­prise Se­cu­ri­ty Ar­chi­tect chez Aka­mai. Jus­qu’alors peu connu dans le pe­tit monde des DDoS, l’uti­li­sa­tion de mem­ca­ched comme pro­to­cole d’am­pli­fi­ca­tion a connu un boom de po­pu­la­ri­té fin fé­vrier, à en croire l’ob­ser­va­toire DDoSMon mis en place par la so­cié­té de sé­cu­ri­té in­for­ma­tique chi­noise Qi­hoo 360 ( https:// ddosmon. net/ mem­ca­ched_ am­pli­fi­ca­tion_ at­tack). Si son uti­li­sa­tion semble se tas­ser au mo­ment où nous écri­vons ses lignes ( grâce au « kills­witch » ? lire l’en­ca­dré). Mais mieux vaut ne pas crier vic­toire trop tôt, les cher­cheurs ne dé­nombrent qu’en­vi­ron 6 000 adresses IP uniques liées à des ser­veurs mem­ca­ched vul­né­rables uti­li­sés pour des at­taques, quand Sho­dan, rap­pe­lons- le, en re­cense 88 000. Sur son blog, OVH in­dique que « si un pe­tit nombre de services Mem­ca­ched ou­verts a ra­pi­de­ment été cor­ri­gé, ils sont en­core très nom­breux à de­meu­rer uti­li­sables pour com­mettre des at­taques […] Il sem­ble­rait que la me­nace de Mem­ca­ched soit par­tie pour du­rer dans le temps. Même si les pro­tec­tions mises en place par les hé­ber­geurs ont dras­ti­que­ment ré­duit la taille des at­taques, la ma­jo­ri­té est à pré­sent in­fé­rieure à 100 Gbps, la cor­rec­tion de la confi­gu­ra­tion par les uti­li­sa­teurs reste la clef » .

La sé­cu­ri­té, l’af­faire de tous

No­tons que, avant sa ver­sion 1.5.6, der­nière en date, mem­ca­ched au­to­ri­sait par dé­faut les connec­tions TCP et UDP. Les dé­ve­lop­peurs de mem­ca­ched ex­pliquent eux- mêmes dans leur do­cu­men­ta­tion tech­nique que le ser­vice ne fait « pas beau­coup, voire au­cun, ef­fort pour as­su­rer sa dé­fense contre les connexions in­ter­net aléa­toires. Vous ne de­vez donc pas ex­po­ser di­rec­te­ment mem­ca­ched à In­ter­net, ni à d’autres uti­li­sa­teurs non au­to­ri­sés » . Mais pour peu que le ser­veur soit ac­ces­sible, et non abri­té der­rière un fi­re­wall, n’im­porte qui peut y en­voyer des don­nées. Il est donc né­ces­saire de le sé­cu­ri­ser. Si une connexion UDP n’est pas in­dis­pen­sable ( 99 % des uti­li­sa­teurs n’en ont pas be­soin, se­lon OVH), il ne reste plus qu’à désac­ti­ver l’écoute du pro­to­cole grâce à la com­mande – U 0. Il est éga­le­ment conseillé de cou­per le ser­veur d’In­ter­net en li­mi­tant l’adresse d’écoute à 127.0.0.1, ou en for­çant l’écoute sur une IP pri­vée si d’autres ma­chines doivent pou­voir s’y connec­ter. En outre, « la pa­rade la plus simple, c’est de po­si­tion­ner un fi­re­wall clas­sique de­vant son ser­veur » , ajoute Xa­vier Daspre. Les hé­ber­geurs ont éga­le­ment mis en place des me­sures de leur cô­té, le géant rou­bai­sien an­non­çant par exemple que, plu­tôt que de blo­quer le port UDP 11211 – ce qui risque d’avoir quelques fâ­cheuses consé­quences pour les services l’uti­li­sant –, il a pla­cé « sous mi­ti­ga­tion per­ma­nente » les adresses IP re­ce­vant un très grand nombre de re­quêtes Mem­ca­ched par se­conde et donc iden­ti­fiées comme contri­buant à des at­taques DDoS. Di­gi­tal Ocean, AWS et Li­node ont éga­le­ment pro­cé­dé à des me­sures si­mi­laires. Ce qui ne doit pas pour au­tant em­pê­cher les uti­li­sa­teurs et ad­mi­nis­tra­teurs sys­tème de sé­cu­ri­ser leurs ser­veurs : « La vul­né­ra­bi­li­té, même si tout le monde a été mis en garde, reste ou­verte » , aver­tit l’En­ter­prise Se­cu­ri­ty Ar­chi­tect d’Aka­mai. ❍

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.