حمله برروی LSDB ها در پروتکل مسیریابی OSPF همراه سناریو عملی

سلام دوستان.

دلیل اصلی نوشتن این مطلب برمیگرده به پستی که در یکی از سایت های ایرانی خوندم، سایت وتیمی که خود را جزو بهترین و برترین شرکت های امنیت شبکه و رایانه ای کشور می داند. درواقع مطلبی که خوندم  دوست عزیز امنیتی مون اسم تاپیک رو ”  آسیب پذیری موجود بر روی پروتکل OSPF ”  گذاشته بود و اگر بطور صریح حرف بزنیم ترجمه و شرح CVE-2012-0249 بودش!

این باگ مربوط به برنامه Quagga که بیس آن Zebra است. باگ در Daemon OSPF که وظیفه اجرای پروتکل OSPF را برعهده دارد رخ می دهد. در بسته های دریافتی LS Update طول چک نمی شود. طول در LSA Hader قرار میگیرد (فیلد length)  و این باگ باعث ایجاد حملات DOS می شود. حال نمیدونم وظیفه پروتکل آیا واقعا چک کردن طول داده هاست؟ یا این یک خطای برنامه نویسی است؟ که این بشر نوشته کشف آسیب پذیری در پروتکل OSPF ونکته ظریف اینجاست که اگر باگ مرتبط با پروتکل باشد بدون شک بایستی در تمامی دیوایس هایی که این پروتکل را پیاده سازی نموده اند وجود داشته باشد. پروتکل های که نوشته می شوند براساس تفکر و منطق هستند پس باگ هم بایستی logical باشد نه مرتبط با Secure Coding.

امیدوارم که شاهد اینگونه توهمات نباشیم و ازروی هیجان حرف زدن و عمل نمودن را کنار بگذاریم. حیله و حقه بازی واقعا کارزشت و ناپسندی هستش مخصوصا عوام فریبی، کسانی که در این فیلد کاری نیستند.

 

ابتدا مروری بر قواعد OSPF خواهیم داشت تا حمله بهتر درک شود:

  • قواعد براساس وضعیت پیوندهایا همان Link-State است، بنابراین همه روترهایی که در یک ناحیه OSPF قر ار دارند بایستی توپولوژی آن Area رو یادبگیرند.
  • بطورکلی OSPF سه مرحله دارد:
  1. اطلاعات روترهای مجاور، neighbor ها که شرایط برقراری ارتباط و تبادل داده ها را دارد، در جدولی به نام neighbor table ذخیره می شود.
  2. نگهداری و تبادل اطلاعات توپولوزیکی شبکه، بین روترهای همسایه است. این اطلاعات در جدولی به نام LSDB ذخیره می گردد.
  3. انتخاب بهترین مسیر ازروی جدول LSDB که این کارتوسط الگوریتم Dijkstra انجام می شود.

برای ساخت Topology Database از ارسال و دریافت بسته هایی به نام LSA استفاده می شود لذا بنابرموقعیت توپولوژیکی 11نوع LSA داریم که Header تمامی آنها یکسان است. ساختار این هدر را در پایین می توانید مشاهده کنید :

 

وقتی تغییری در وضعیت یک لینک ایجاد می شود مانند قطع،تغییر هزینه و یا ایجاد یک لینک جدید روتری که تغییر را Sense نموده است LSA ی که شامل تغییرات موجود است را از طریق پیام Multicast برای همسایگان خود ارسال می کند. روترهایی که LSA را دریافت میکنند ابتدا براساس آن LSDB خود را update می کند و در ادامه آن را بصورت Multicast برای همسایگان خودش هم ارسال می کند و در مدت کوتاهی Routing Domain از تغییر آگاه می شود. وقتی دیتابیس هر روتر تکمیل شد داده های موجود تشکیل یک گراف می دهند و با اجرای الگوریتم Dijkstra برروی گراف بهترین مسیر بدست خواهد آمد.

 

در Section 12.4 از RFC 2328 نیز 10 رویداد که باعث ایجاد LSA میگردد شرح داده شده است، ضمنا اگر دلیلی برای ایجاد LSA نباشدآخرین LSA بعد از 30min نیز re-Advertise خواهد شد.

 

باتوجه به حمله ای که می خواهیم آن را پیاده سازی کنیم در Header سه فیلد مورد توجه است:

  • LS Type: نوع LSA را مشخص می کند (مانند Router,Network,Summary, …) در ادمه برروی Router LSA بحث خواهیم نمود.
  • Link State ID: متناسب با مقدار فیلد LS Type این فیلد نیز نقش و مقدار متفاوتی خواهد داشت، اما در Router LSA این فیلد برابر ROuter ID روتر ایجاد کننده پیام است درواقع همان روتری که تغییر را sense کرده است.
  • Advertising Router: این فیلد در ROuter  LSA  برابر مقدار همان Link-State ID است.

 

در Section 12.1 براساس این سه فیلد می توان تشخیص داد که LSA دریافتی Unique است یا نه؟ درصورت Unique بودن به LSDB اضافه خواهد شد درغیراینصورت اگر نمونه ای قبلا در LSDB موجود باشد درصورت جدید بودن جایگزین نسخه قبلی از LSA خود خواهد شد.

 

مکانیزم امنیتی Fight-Back چیست وچگونه تریگر می شود؟ هرگاه روتری LSA جعلی از خودش را درون شبکه مشاهده کند، این حق را دارد تا Valid LSA را برای همه روترها ارسال کند. براساس Section 13.4 اگر LSA دریافتی فیلد Advertising Router آن برابر با ROuter ID خودش باشد و همچنین جدیدتر از LSA که خودش ایجاد کرده باشد، این مکانیزم تریگر خواهد شد. درواقع بصورت شبه کد میتوان چنین چیزی را داشت:

 

نکته قابل تامل دراین قسمت خواهد بود که فقط Advertising Router چک  می شود. در حمله که انجام می دهیم نیاز داریم برروی دوفیلد بیشتر تمرکز نماییم:

  1. Link State ID
  2. Advertising ID

 

براساس قواعد OSPF هر روتر LSA خود را ایجاد می کند و انتظار نمی رود که روتری LSA دیگر روترها را ایجاد نماید پس دو فیلد بالا که توضیح داده شد بایستی مقدار یکسان داشته باشد. در OSPF برای چک  نمودن یکسان بودن این دو فیلد عمل خاصی انجام نمی شود و این باعث می شود تا بتوان LSA ی را ارسال کرد که دو فیلد مقداری متفاوت داشته باشد.  شرح حمله بدین صورت است که فرض می کنیم مهاجم می خواهد Router LSA را از سمت برخی قربانی ها (Rv) ارسال کند:

  • LS ID: برابر است با ID روتر Rv
  •  Advertising router: هر مقدار به جز مقدار ID روتر Rv

 

براساس قواعد OSPF می تونیم اطمینان خاطر داشته باشیم که Fight Back فعال نخواهد حتی در دیگر روترها درون AS  و LSA جعلی را درون LSDB خودشان قرار می دهند اما بااین حال مشکلی پیش رو خواهیم داشت. همانطور که قبل گفته شد در بخش 12.1 از RFC براساس سه فیلد LSA جعلی جایگزین LSA معتبر در LSDB نخواهد شد بخاطر اینکه متفاوت هستند (Advertising Router یکسان نیست)  همچنین نمیتوان اطمینان داشت تا LSA جعلی از LS DB پاک نشود. در RFC ی که به شرح OSPF پرداخته است ابهامی وجود دارد که می توان از آن استفاده نمود و حمله را با موفقیت انجام  داد. براساس بخش 16.1 گفته می شود که محاسبه مسیرها برروی LSDB براساس Vertex ID خواهد بود:

This is a lookup … based on the Vertex ID 

در شرح OSPF نیز Vertex ID همان فیلد Link State ID می باشد. یعنی وقتی روترها می خواهند جدول مسیریابی را تشکیل دهند براساس این فیلد عمل خواهند نمود.

حال ابهامی بوجود می آید، باتوجه به ابهامی که در RFC وجود دارد ما دو LSA با مقدار Link-State ID یکسان داریم.  برای انجام محاسبات   کدام LSA  از LSDB مورد استفاده قرار میگیردد؟ LSA جعلی و یا LSA معتبرواصلی؟ به یاد داریم که هردو LSA جعلی و اصلی در تمامی LSDB درون AS وجود دارد. هردو LSA فیلد Links State ID دارای مقدار یکسان هستند.براساس متن OSPF قادر به پاسخگویی این سوال نخواهیم بود بنابراین جواب بستگی به پیاده سازی دارد.
اکثر شبکه هایی که OSPF را پیاده سازی کرده اند برپایه IOS های سیسکو است. براساس تحقیقات انجام شده Infonetics تقریبا 75 درصد شبکه های Enterprise در جهان از سیسکو استفاده می کنند. برای پیاده سازی حمله از GNS3 و SCAPY استفاده می کنیم که برروی روتر c7200 و آخرین نسخه Stable از IOS ارائه شده توسط سیسکو که ورژن 150-1M است.
LSA جعلی را با شماره Sequence بالاتر از LSA اصلی ارسال می کنیم. LSA جعلی نه تنها در LSDB قرار می گیرد بلکه در تمامی LSDB های درون AS جایگزین خواهد شد.

خوب حال در عمل چگونه خواهد بود. اسکرین شات از GNS3 را میبینیم که سعی نموده ایم بصورت خیلی ساده حمله انجام شود چون تنها نیاز به POC حمله داریم.

GNS3-Screenshot

کانفیگ روترها نیز کارخاصی ندارند تنها نیاز به تعریف IP برای اینترفیس ها و همچنین اضافه نمودن آنها به دامنه مسیریابی OSPF می باشد. Attacker هم نیز همان Backtrack است. نکته قابل ذکر اینجاست که برروی روتر R1 یک اینترفیس Loopback با Ip=192.168.200.20 و Subnetmask=255.255.255.255 را کانفیگ میکنیم. هدف در این سناریو جعل پیام R1 و ارسال آن به R2 توسط نفوذگر می باشد که در این جعل پیام اینترفیس Loopback تعریف شده را به دامنه مسیریابی وارد می کنیم و سرویس Non-repudiation نیز نقض می شود، همچنین میتوانید با استفاده از wireshark پکت های ارسالی را مشاهده کنید. بعد از ارسال پکت برروی روترها می توانید با دستور show ip ospd database تغییراتی که پکت ایجاد نموده است را مشاهده کنید.

سورس حمله به زبان پایتون و Scapy :

 

خوب بطورکلی باگ های پروتکل OSPF آخرین که بصورت پابلیک ارائه شد در کنفرانس BlackHat 2011-2013 بود. میتونیم بگیم که مقاله 2013 بهینه تر و تکمیلترشده مقاله ای هستش که در 2011 توسط دکتر Gabi Nakibly ارائه شد.

در مقاله 2011 از مکانیزم امنیتی Fight-Back برعلیه خودش استفاده میکنیم درواقع خودمون باعث تریگر شدن این مکانیزم میشیم و براساس RFC و مستندات موجود میتونیم LSA که این مکانیزم ایجاد میکند رو حدس بزنیم و قبل از ارسال و Flood شدن در Routing Domain خودمون ایجاد و Flood کنیم.

 

شاید در پست های آتی به مباحث همچون IDS/IPS بپردازیم.

یاحق،

موفق باشید.

 

دانلود مطلب بصورت PDF

AHA

قطره ای از دریای بیکران IT

More Posts

11 thoughts on “حمله برروی LSDB ها در پروتکل مسیریابی OSPF همراه سناریو عملی”

    1. سلام.

      روترها کانفیگ خاصی ندارند خودتون هم می تونید کانفیگ کنید. یک شبکه OSPF ساده و ابتدایی هستش.

      اگر فایل رو هنوز داشته باشم پیدا کردم همینجا لینک دانلود رو میزارم.

  1. سلام. ممنون از متلب مفیدتون.
    من یه سوال داشتم و کارم خیلی گیر جواب این سواله: شما به OSPF-TE هم تسلط دارید؟ میخوام بدونم آیا نقطه ضعفی داره که بشه روش حمله ای طراحی کرد؟ خیلی تحقیق کردم ولی تقریبا تمام نقاط ضعفی که داشتته رو تصحیح کردن. ممنون میشم اگه پاسخگوی سوالم باشید.

    1. نویسنده این یادداشت AHA حال حاضر در خدمت مقدس سربازی هستند بایستی صبر کنید تا پس از بازگشت پاسختون رو بدن.

      1. سلام.
        من کلا دنبال یه نقطه ضعف امنیتی بودم که برای پایان نامه تعریف بشه. ولی خب در حین تحقیقاتم به نتیجه دیگه ای رسیدم و دارم روش کار میکنم. ممنون از اینکه پاسخگو هستید.
        موفق باشید.

        1. سلام .

          خواهش. در صورتیکه حاصل تحقیقاتتون رو به اشتراک گذاشتید لینک رو در اینجا قرار بدین تا بحث جامع تر شود.

          باتشکر

      2. سلام.
        هر گونه نقطه ضعفی که این پروتکل داره رو بی زحمت بیان کنید.آسیب پذیری هایی که هست و رفع نشده.
        با تشکر از شما

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *