آموزش های تخصصی شبکه و امنیت و ضد امنیت

شروع هك ( شناسایی هدف - قسمت دوم-dns ) 
بحث تا جايي ادامه پيدا كرد كه ما با استفاده از whois ، اطلاعاتي در مورد سايت بدست آورديم . در ايران ، چون صاحبين سايتها ، امكان ثبت مستقيم دامنه ي مورد نظر خودشون رو ندارند ، اين كار رو به عهده ي يك سري از شركتها ميسپرند ، و معمولاً اطلاعات داخل بانك اطلاعاتي دامنه ها ، اطلاعات شركت ثبت كننده هست ، نه اطلاعات صاحب سايت . ( بعضي از اين فيلدها قابل تغيير هستند ، اما خيلي ها اون رو تغيير نميدند ) . اما گفتيم كه در بين اطلاعاتي كه از whois بدست مياد ، آدرس DNS ها خيلي مهم هستند . بنابرين قبل از اينكه مراحل بعدي جمع آوري اطلاعات رو ادامه بديم ، در اين مقاله بر روي DNS ها مكث مي كنيم .

چرا DNS مهم هست ؟ DNS يكي از كامپونت هاي اصلي اينترنت هست . پس هر جا كه اينترنت هست ، DNS هم هست . مايكروسافت DNS رو يكي از كامپونت هاي اصلي AD قرار داده و اين نشون دهنده ي اهميت اين سرويس هست . از نظر ما ، اين سرويس به خاطر اين گستره ي كاربري ، ميتونه جالب باشه . اگر يه سازماني بخواد اجازه دسترسي به اينترنت رو بده ( كه همه اين كار رو ميكنند ) ،بايد اجازه خروج و ورود query هاي DNS رو به شبكه داخلي سازمان بده . و اين ميتونه خيلي معني داشته باشه . پس بهتره كمي DNS ها رو بهتر بشناسيم . 

همونطور كه ميدونيد ، وظيفه ي اصلي DNS ها ، ترجمه ي آدرس دامنه ها به آدرس IP هست . سازمان جهاني IANA ( بخوونيد يانا ) ، روي اسمها و آدرسها نظارت داره و اونها رو مديريت ميكنه . DNS ها از يك ساختار سلسله مراتبي استفاده ميكنند . بنابرين بالاترين سطح DNS ها رو Root Level DNS ميگند . شبكه اينترنت وابسته به 13 سرور Root Level هست ، كه اسم ، آدرس و موقعيت اونها رو ميتونيد در آدرس http://www.root-servers.org ببينيد . اين 13 سرور ، به شدت محافظت ميشند . يعني از نظر فيزيكي ، در حد پايگاه هاي نظامي و از نظر امنيت خود سرورها ، در بالاترين حد قرار دارند . به طوري كه سيستم عامل مورد استفاده در اين سرور ها ، يك نوع خاص از يونيكس هست كه مشابه اون در جاي ديگه وجود نداره . اين مسئله نشون دهنده ي اهميت DNS ها هست . ولي با اين وجود ، و به همين دليل مهم بودن ، تكنيكهاي مختلفي براي سو استفاده از DNS ها وجود داره . قبل از اينكه اين تكنيكها رو شرح بدم ، بايد با روش كار DNS آشنا باشيد . بهترين راه فهميدن نحوه ي كار DNS اين هست كه با يك مثال واقعي اون رو بررسي كنيم . وقتي ما به اينترنت وصل ميشيم ، در حقيقت يك كامپيوتر از يك شبكه داخلي ميشيم كه ISP ارتباط ما رو مديريت ميكنه . در اين حالت ، ما از DNS داخلي ISP استفاده ميكنيم . DNS مثل يك دفترچه راهنماي تلفن ميمونه كه بايد بتونه شماره تلفن هر شخص رو بر اساس نام اون شخص پيدا كنه . واضح هست كه مدير يك ISP محلي در تهران ، نميتونه همه ي شماره تلفن ها يا آدرس IP ها رو براي همه ي نامهاي موجود در اينترنت ، براي DNS خودش تعريف كنه . بنابرين DNS يك ISP محلي ، چيزي نيست جز يك واسطه .اين DNS ها ، فقط تعداد كمي ركورد مربوط به ماشينهاي داخل شبكه خودشون و قابليت cache كردن ركوردها و بعضي اطلاعات رو براي بالا بردن سرعت دارند . اين نوع DNS ها رو Non- authoritative ميگند . وقتي ما در برازر خودمون يك آدرس رو تايپ ميكنيم ، مثل www.imenafza.net ، برازر درخواست تبديل اين اسم رو به شماره IP ، ميفرسته براي DNS مربوط به ISP ما . حالا اگر قبلاً DNS ما ، چنين درخواستي رو داشته ، و اون رو cache كرده باشه ، شماره ip رو براي ما برميگردونه ، و در غير اين صورت ، درخواست رو براي DNS بالاتر از خودش ميفرسته . اين ارسال درخواست ها به صورت سلسله مراتبي ادامه پيدا ميكنه ، و اگر در هر مرحله درخواست نا موفق بود ، نهايتاً به DNS هاي سطح بالاتر ميرسه كه به اونها authoritative ميگند . اگر اين DNS ها هم نتونند ، ركوردي براي درخواست مورد نظر پيدا كنند ، اون رو براي root ها ميفرستند و اگر باز هم ركوردي پيدا نشد ، نتيجه ميگيريم كه دامنه ي مورد درخواست ما ثبت نشده و وجود نداره . اين يك شماي خيلي ساده شده از روش كار DNS ها بود. 

اما مشكلات اين ساختار سلسله مراتبي چي هست ؟ واضح هست كه همه ي مشكلات در همين ارسال و دريافت اطلاعات بين DNS ها نهفته هست . 

يكي از مشكلات قديمي كه فكر ميكنم در حال حاضر فقط بايد در حد اطلاعات عمومي باهاش آشنا باشيم ، Zone Transfer هست . داستان اين Zone Transfer هم اين هست كه همه جا ، به خاطر اهميت سرويس DNS ، از حداقل دو تا DNS استفاده ميشه كه اولي master يا primary هست و وظيفه ترجمه آدرس ها رو داره ، و دومي slave يا secondary هست و وظيفه كمكي رو داره . حالا طبق اصول مديريتي شبكه ، اطلاعاتي كه در DNS اولي هست ، بايد طبق يك برنامه زمان بندي شده ، يا درخواست مستقيم DNS دومي ، به DNS دوم هم منتقل بشه كه اين DNS هم اطلاعاتش به روز باشه . حالا اگر تنظيمات در سرور DNS اول طوري باشه ، كه اين اطلاعات درخواستي رو براي هر سيستمي كه درخواست كرد ، بفرسته ، مشكل Zone Transfer داره ، و اگر يك همچين سروري پيدا بشه ، هكر ميتونه تمام اطلاعات ركورد شده روي اون DNS رو كه شامل آدرس هاي خصوصي اون شبكه هم ميشه رو بدست بياره و به اين شكل اطلاعات كاملي از شبكه ي هدف به چنگ بياره . براي جلوگيري از اين حالت بايد سرور اصلي رو به گونه اي تنظيم كرد كه فقط اطلاعات رو براي آدرس سرور دوم بفرسته و به درخواست هاي ديگه پاسخ نده . جهت اطلاع هم بايد بگم كه دو نوع Zone Transfer‌ داريم . يكي Full يا AXFR كه تمامي اطلاعات ارسال ميشه و ديگري هم Incremental يا IXFR كه آخرين تغييرات بعد از آخرين ارسال ، ارسال ميشه .

يكي ديگه از مشكلات ساختاري DNS ها ، كه نسبت به قبلي متداول تر هست ، DNS Spoofing هست . در اين حالت ، درخواست كننده به جاي اينكه به آدرس صحيح ارجاع داده بشه ، به يك آدرس غلط فرستاده ميشه . اين نوع حملات به چند روش قابل اجرا هست . همونطور كه در بالا اشاره كرديم ، در مسير سلسله مراتبي ، تعدادي DNS ممكنه وجود داشته باشه كه كارشون cache كردن هست . اگر يك هكر بتونه اطلاعات غلطي رو به جاي اطلاعات صحيح وارد cache اين سرورها بكنه ، ميتونه درخواستهاي بعدي براي يك سايت خاص رو كه از اون DNS ميگذرند رو به يك آدرس ديگه منحرف كنه . اين حملات به DNS Cache Poisoning معروف هستند.
حالت ديگه ميتونه اين باشه كه هكر يك جايي بين درخواست كننده و سرور DNS قرار بگيره و به ترافيك گوش بده ، و هر وقت متوجه درخواستي شد ، قبل از اينكه DNS به اون درخواست جواب بده ، جواب غلط رو براي درخواست كننده بفرسته و اون رو به آدرس ديگه اي ارجاع بده . به اين حالت Spoofing DNS Response ميگند .
حالت سوم ميتونه اين باشه كه هكر كنترل يك DNS رو در دست بگيره و ... . به اين حالت DNS Server Compromise ميگند . 

خب ، به نظر ميرسه كه مباحث مربوط به DNS تموم شده باشه . اما اينطور نيست. جالب ترين بخش داستان DNS ها ، استفاده از اونها در حملات SQL Injection هست . حتماً مي پرسيد كه DNS چه ربطي به SQL Injection داره ؟ 
موضوع اينجاست كه MS SQL و Oracle يك سري توابع و پروسيجر دارند كه ميتونند مستقيم يا غير مستقيم با DNS ها كار كنند و اطلاعات بگيرند . بعضي از اين دستورات و توابع با كاربر public هم قابل اجرا هستند و به بعضي از اونها هيچ اشاره اي در راهنما هاي hardening در ايمن سازي بانكهاي اطلاعاتي نشده . چون اين روش خيلي پيچيدگي داره ، من اون رو در بخش " حملات تحت وب " و SQL Injection بررسي ميكنم ، اما علاقمندان ميتونند به ارائه ي آقاي "پاتريك كارل سن" در كنفرانس Defcon 15 ، تحت عنوان SQL Injection & OOB Channels مراجعه كنند .

در درس بعدی , مراحل بعدی جمع آوری اطلاعات رو ادامه میدیم .