در این بخش از دوره آموزشی SEC504 شما با ادامه مبحث Sniffing در شبکه و حملات مبتنی بر DNS و SSH آشنا خواهید شد.
DNS Attack
تصویر زیر نشان می‌دهد که بوسیله Dsniff چگونه می‌توان ترافیک را با استفاده از حمله DNS هدایت نمود. Dsniff یکی از ابزارهای کاربردی Sniffing در شبکه می باشد.
مرحله اول: نفوذگر برنامه DNSSpoof را اجرا می‌کند که برای هر DNS Query که برای دامنه هدف می‌باشد، Listen شده است.
مرحله دوم: قربانی یک برنامه مانند مرورگر وب را اجرا نموده و سعی در ترجمه نام یک دامنه (name resolve) را دارد.
مرحله سوم: DNSSpoof درخواست‌ها را مشاهده می‌کند. برای sniff نمودن این درخواست‌ها در محیط سوییچ، نفوذگر ممکن است از روش MAC Folooding یا ARP Poisoning استفاده کرده باشد که در بخش‌های پیشین به آن اشاره شده است. پس برای مشاهده در خواست‌های DNS ابتدا باید یکی از این موارد انجام شود و سپس درخواست‌های DNS به سمت نفوذگر هدایت شود.
مرحله چهارم: ابزار DNSSpoof یک بسته حاوی DNS Response را ارسال می‌کند که جعل شده و به نظر می‌رسد که از DNS Server قربانی ارسال شده است. در این بسته یک آدرس دامنه به یک IP که مورد نظر نفوذگر می‌باشد، اشاره نموده است(Spoofed).
مرحله پنجم: در این مرحله قربانی جایی را مشاهده می‌کند و به آدرسی هدایت می‌شود که نفوذگر می‌خواهد. در این حالت قربانی تصور می‌کند که چیزی که مشاهده می‌کند همان مقصد واقعی می‌باشد!
توجه داشته باشید که یک پاسخ در ادامه توسط DNS سرور واقعی ارسال خواهد شد ولی قربانی قبلاً پاسخ جعلی را در Cache خود ذخیره نموده است. در این حالت پاسخ واقعی نادیده گرفته می‌شود، زیرا خیلی دیر ارسال شده است.
یک چالشی که در این بخش وجود دارد، تقابل DNS سرور واقعی و DNS سرور جعلی است و برای موفقیت در این حمله، پاسخی که نفوذگر ارسال می‌کند باید سریعتر از پاسخ DNS سرور اصلی باشد. البته درصد موفقیت نفوذگر بیشتر می‌باشد، زیرا درخواست نام یا DNS Request قبل از ارسال به DNS سرور واقعی به نفوذگر می‌رسد. بنابراین نفوذگر می‌تواند پاسخ جعلی را سریعتر از سرور واقعی ارسال کند(Sniffing).
تاثیرات DNSSpoof
با کنترل DNS، نفوذگر می‌تواند قربانی را به وب سایت مورد نظر خود هدایت کند، اما مهم تر از این مورد، امکان هدایت ترافیک کاربر از طریق یک پراکسی می‌باشد. این قابلیت قدرتمند صحنه را برای انجام Active Sniffing برای SSL و SSH نیز فراهم می‌کند.
توجه داشته باشید که نفوذگر مجبور نیست که در همان شبکه‌ای باشد که قربانی در آن حضور دارد. نفوذگر فقط باید بین یک قربانی و سرور DNS باشد تا بتواند درخواست‌های DNS را Sniff کند. با استفاده از DNSSPoof می‌توانیم ترافیک را به هرجایی که می‌خواهیم هدایت نماییم.
SSL and SSH Sniff
تصویر زیر نحوه انجام حمله در سطح SSL یا SSH را نمایش می‌دهد که یکی از حملات دیگر مرتبط با Sniffing در شبکه می باشد.
مرحله اول: نفوذگر ابزار DNSSpoof و Webmitm یا SSHmitm را اجرا می‌کند.
مرحله دوم: در این مرحله قربانی سعی در Resolve نمودن یک نام می‌نماید که این کار می‌تواند با اجرای مرورگر و تایپ نمودن آدرس یک وب سایت در آن، انجام شود. سپس DNSSpoof، درخواست را شناسایی نموده و پاسخ جعلی خود را ارسال می‌نماید.
مرحله سوم: مروگر قربانی یک ارتباط SSL را برقرار می‌کند (با فرآیند webmitm با ماشین قربانی این ارتباط برقرار می‌شود)
مرحله چهارم: ابزار webmitm اتصال SSL خود را با مقصد که سرور وب واقعی می‌باشد، برقرار می‌کند.
مرحله پنجم: در این مرحله با توجه به اینکه نفوذگر بین قربانی و مقصد قرار گرفته است، پیامی را مشاهده می‌نماید که بیانگر عدم اعتبار گواهینامه سایت مقصد است. در این صفحه اشاره شده است که با توجه به نامعتبر بودن گواهینامه، از ادامه کار خودداری نمایید اما اکثر کاربران به سادگی ارتباط را ادامه می‌دهند. همانطور که کاربر به وب سایت دسترسی پیدا می‌کند، تمام ترافیک وی بر روی سیستم نفوذگر قابل مشاهده است.
فرایند بالا برای ارتباط SSH نیز صادق است.
اساسا ابزارهای Webmitm و SSHmitm، ابزارهای مبتنی بر پراکسی هستند که برای سوء استفاده از یک مدل اعتماد مبتنی بر کاربر، استفاده می‌کنند.
ابزار دیگری از مجموعه Dsniff که برای حملات مشابه در برابر SSH (تنها نسخه یک از SSH) کاربرد دارد، SSHmitm می‌باشد. این ابزار کلید عمومی خود را برای سرور SSH جایگزین می‌کند و دو ارتباط SSH را تنظیم می‌نماید که یکی از کلاینت به نفوذگر و دیگری از نفوذگر به سرور می‌باشد.
آشنایی با تکنیک ها و ابزارهای Sniffing در شبکه
در این مرحله کلاینت یک پیام هشدار دریافت می‌کند مبنی بر اینکه کلید تغییر کرده است، اما پیام‌ها بیشتر وابسته به نوع SSH کلاینتی است که مورد استفاده قرار می‌گیرد. به عنوان مثال برای Open SSH به صورت پیش‌فرض پیام زیر نمایش داده می‌شود:
باز هم بیشتر افراد این پیام را نادیده می‌گیرند. همچنین این پیام در هر زمانی که کلید جدید از سرویس SSH ایجاد می‌شود نیز نمایش داده می‌شود. چقدر شما این کار را انجام می‌دهید؟
بعضی از سازمان‌ها هر ساله کلیدهای جدیدی را ایجاد می‌کنند که این کار، ایده خوبی است تا اطمینان حاصل کنید که کلیدهای شما جدید هستند و در معرض حمله قرار نگرفته اند. با این وجود با مدیران سیستم در ارتباط باشید و اگر آن‌ها از این مورد اطلاع داشته و به شما اطمینان دهند که این موضوع مربوط به ایجاد کلید جدید می‌باشد، جای نگرانی در خصوص حملات Sniffing وجود ندارد. ولی اگر خارج از مورد مذکور، این پیام را مشاهده نمودید باید آن را به تیم Incident Handling اطلاع دهید.
از سوی دیگر، شما می‌توانید توزیع کلید جدید را به صورت دستی یا خودکار انجام دهید، به گونه ای که پیام هشدار برای آن‌ها نمایش داده نشود.
جلوگیری از نمایش پیام‌های هشدار SSL
همانطور که در بخش پیشین اشاره گردید، معمولا کاربران پیام‌های هشدار مربوط به جعلی بودن SSL یا کلید جدید در SSH را نادیده گرفته و پس از تایید آن به کار خود ادامه می‌دهند. اما برخی از کاربران هم هستند که ممکن است از ادامه کار صرف نظر نمایند. برای فریب این کاربران هم می‌توان پیام‌های هشدار را حذف نمود که روش‌های مختلفی برای این کار وجود دارد.
یکی از این روش‌ها این است که نفوذگر سیستم مربوط به اعطای گواهی (Certificate Authority) و یا سیستم ثبت کننده آن (Registration Authority) را مورد نفوذ قرار داده و به تسخیر خود در آورد.
برای این مورد، نمونه‌های تاریخی هم وجود دارد. در سال 2011 دو حمله عمده از این نوع رخ داده است. اولین حمله مربوط به در اختیار گرفتن یک RA مرتبط به CA شرکت Comodo بود که در آن 9 گواهی SSL جعلی ساخته شد.
چند ماه بعد اعلام شد که Diginotar CA هم مورد نقوذ قرار گرفته شده و صدها گواهی SSL غیرقانونی و جعلی ساخته شده است.
از سوی دیگر نفوذگر می‌تواند کلیدهای سرور را از طریق حافظه و با استفاده از مشکل امنیتی Heart Bleed استخراج نماید. ابزاری که برای این کار مورد استفاده قرار می‌گیرد، ابزار Power Bleed می‌باشد که توسط Joff Thyer ایجاد شده است و از طریق آدرس زیر در دسترس می‌باشد:
https://github.com/yoda66/PowerBleed
رویکرد دیگر، بهره برداری از ضعف‌های موجود در الگوریتم‌های رمزنگاری مورد استفاده برای ایجاد گواهینامه‌ها می‌باشد. در دسامبر 2009 Alexander Sotirov و چندین محقق دیگر توانستند تا گواهینامه‌های جعلی را با استفاده از همین روش جهت اثبات (Proof of Concept) ایجاد نمایند.
روش‌های دیگر برای جلوگیری از پیام هشدار در SSL
اگر نفوذگر از طریق بدافزار بتواند سیستمی را در اختیار خود قرار دهد، می‌تواند یک گواهی نامه یا Certificate را داخل مرورگر قربانی ذخیره نماید.
همچنین نفوذگر می‌تواند از طریق ایمیل یا یک Pop up ، بوسیله مهندسی اجتماعی، کاربران را مجبور به جاسازی گواهی نامه‌های جعلی در مرورگر خود نماید.
یکی از روش‌های دیگر، اجرای حمله MITM است به منظور تبدیل کلیه ترافیک‌های HTTPS به HTTP که این کار با ابزار sslstrip انجام می‌شود.
یکی از روش‌های دیگر حمله به وب سایت‌هایی است که تنها در فرآیند احراز هویت، از SSL استفاده می‌کنند و پس از آن اطلاعات به صورت Clear Text و در بستر HTTP منتقل می‌شود. ابزار Firesheep این حمله را انجام می‌دهد که البته نسخه تحت موبایل آن ابزار droidsheep می‌باشد.
