اخیراً چندین شرکت امنیتی، موجی از حمله‌های گسترده‌ی UDP Amplification را شناسایی نمودند که در واقع این حمله‌ها از آسیب‌پذیری‌های سرورهای Memcached استفاده می‌کردند. این آسیب‌پذیری‌ها سرعت برنامه‌های وبِ Dynamic را با Cache نمودن Objectها و داده‌ها در RAM بالا می‌بردند.
با توجه به این که این حمله‌ها مشابه DNS Reflection بودند، تحلیل‌گران امنیتی مسیر حمله‌ی (Attack Vector) جدید را «Memcached Reflection» نام‌گذاری نمودند. بنا به گفته‌ی اُلیور آدام، یکی از اعضای تیم Link11، «مهاجمین از تجهیزات سیستم Caching رایگانی که دارای امنیت پایینی می‌باشد سوءاستفاده نمودند و این سیستم از طریق پورت 11211 UDP که برای خواندن و نوشتن داده و همچنین تحلیل‌های Query می‌باشد، به صورت ناامن قابل دسترس است.»
مارِک مجکاسکی از شرکت Cloudflare که حمله‌های جدید را «Memcrashed» خوانده و اشاره نمود که متاسفانه Memcashed بستر مناسبی برای این نوع حمله‌ها می‌باشد. به بیان مجکاسکی، متاسفانه از آنجا که هیچ‌گونه بازرسی انجام نمی‌شود و داده با سرعتی باورنکردنی به مشتری تحویل داده می‌شود این پروتکل برای Amplification ایده‌آل محسوب می‌گردد.
محققان تیم Nexusguard در بررسی این تهدید اظهار نمودند که این حمله دارای فاکتور Amplification ۵۱۰۰۰ بوده و بسیار شدیدتر از تمام حملاتی است که تا به حال دیده شده است. با توجه به اینکه حمله‌ی سال ۲۰۱۶ که بر روی یک ارائه‌دهنده‌ی DNS به نام DynDNS انجام شد و پلتفرم‌ها و سرویس‌های اینترنتی بزرگ در اروپا و آمریکای شمالی را آفلاین نمود، دارای فاکتور Amplification ۵۵ بود، درنتیجه می‌توان به عمق شدت این حمله پی برد.
شرکت GitHub اذعان داشت که بزرگترین حمله‌ی DDoS که تاکنون ثبت شده است، اخیراً با استفاده از این شیوه سایت GitHub.com را مورد هدف قرار گرفته است. به گفته‌ی سم کوتلر، مدیر مهندسی Reliability سایت GitHub، حمله از بیش از هزار سیستم مستقل (ASN) بر روی ده‌ها هزار Endpoint منحصربه‌فرد آغاز شد. این حمله، از نوع Amplification بود که با استفاده از رویکرد مبتنی بر Memcached که بالاترین سرعتش Tbps 1.35 بود و از طریق 126.9 میلیون Packet در هر ثانیه، انجام گردید.
اقدامات پیشگیرانه
مجکاسکی در ادامه افزود از آنجا که این تهدید هنوز جدی و مهم محسوب می‌شود، تاکنون ۵۷۲۹ آدرس Source IP منحصربه‌فرد سرورهای Memcached شناسایی شده و می‌توان به سادگی از طریق Shodan بیش از ۸۸۰۰۰ سرور باز Memcached را پیدا کرد. بنا به توصیه‌ی ایشان، درصورتی که از Memcached استفاده می‌کنید و UDP Support بلااستفاده است، حتما آن را غیرفعال نمایید. برای این منظور در حین بالا آمدن Memcached با استفاده از دستور–listen 127.0.0.1 آن را محدود به Localhost کنید و یا با استفاده از دستور –U 0 به طور کلی پروتکل UDP را غیرفعال نمایید.
مجکاسکی موکداً از تمام Developerها خواست که از UDP استفاده نکنند و در صورتی که ناگزیر به استفاده هستند، به هیچ عنوان آن را به صورت Default فعال ننمایند. وی اضافه کرد که اگر از شدت میزان خطر حمله‌ی Amplification بی‌اطلاع هستید، هرگز دستور SOCK_DGRAM را در ویراستار (Editor) خود تایپ نکنید.
رونالد دابینز، کارشناس ارشد شرکت Arbor Networks در یک پست وبلاگی نوشت که آمادگی شناسایی، دسته‌بندی، ردیابی و کاهش این حملات و همچنین اطمینان از اینکه نمی‌توان از هیچ‌یک از تاسیسات Memcached در شبکه‌های آن‌ها و یا در شبکه‌های End Customer آن‌ها به عنوان Reflector یا Amplifier سوءاستفاده نمود، برای اپراتورهای شبکه بسیار حائز اهمیت است.
مت کاتورن، معاون بخش امنیت شرکت ExtraHop اظهار داشت که اولین قدم در ایمن‌سازی هر چیز، شناخت آن است. توانایی نظارت به طرح‌های ترافیک، تراکنش‌ها و پیکربندی‌های سرویس از دیدگاه شبکه، قدمی حیاتی در درک و اعتبارسنجی رفتار سیستم‌ها و سرویس‌هایی است که آن‌ها ارائه می‌نمایند.»
سامی میگوئس، یکی از محقیقن تهدیدات امنیتی شرکت Synopsys بیان داشت که تمامی اپراتورهای دارای سرورهای Memcached، باید برای کاهش خطر، سه اقدام کلیدی زیر را در مجموعه‌های خود اعمال کنند:
- اطمینان از عدم برقراری ارتباط بین سرور Memcached و فضای اینترنت.
- فایروال مرزی تمامی شبکه‌ها، بلافاصله تمام دسترسی‌ها از اینترنت به پورت 11211 UDP را مسدود نماید.
- در تمام سرورهای Memcached، UDP غیرفعال شود.
وی افزود در زیرساخت‌های با ابعاد گسترده‌تر، IPSها باید Packetهای Spoof شده را از شبکه‌های فعلی‌شان مسدود نموده و Developerهای پروتکل نیز درک بهتری از بازرسی‌های سرعت و حمله‌های Amplification به دست آورند.
