مرکز دانلود خلاصه کتاب و جزوات دانشگاهی

فهرست مطالب

مقدمه صفحه 1

 

BIND Domain Name System: اولين نقطه آسيب پذير

صفحه 6

Remote Procedure Calls (RPC)دومين نقطه آسيب پذير :

صفحه 9

 

Windows Authenticationسومين نقطه آسيب پذير :

صفحه 11

 

Internet Explorer (IEچهارمين نقطه آسيب پذير:(

صفحه 24

 

Windows Remote Access Services پنجمين نقطه آسيب پذير :

صفحه 26

 

ششمین نقطه آسیب پذیر:نحوه حفاظت در مقابل دستيابی به ريجستری سيستم

صفحه 33

 

هفتمین نقطه آسیب پذیر:متداولترين پورت ها

صفحه 41

 

FTP هشتمین نقطه آسیب پذیر:

صفحه 47

 

Windows Peer to Peer File Sharingنهمين نقطه آسيب پذير :

صفحه 50

منابع

 

صفحه 54

مقدمه

مهمترين نقاط آسيب پذير
سيستم عامل، يکی از عناصر چهار گانه در يک سيستم کامپيوتری است که دارای نقشی بسيار مهم و حياتی در نحوه مديريت منابع سخت افزاری و نرم افزاری است . پرداختن به مقوله امنيت سيستم های عامل ، همواره از بحث های مهم در رابطه با ايمن سازی اطلاعات در يک سيستم کامپيوتری بوده که امروزه با گسترش اينترنت ، اهميت آن مضاعف شده است . بررسی و آناليز امنيت در سيستم های عامل می بايست با ظرافت و در چارچوبی کاملا" علمی و با در نظر گرفتن تمامی واقعيت های موجود ، انجام تا از يک طرف تصميم گيرندگان مسائل استراتژيک در يک سازمان قادر به انتخاب مستند و منطقی يک سيستم عامل باشند و از طرف ديگر امکان نگهداری و پشتيبانی آن با در نظر گرفتن مجموعه تهديدات موجود و آتی ، بسرعت و بسادگی ميسر گردد .
اکثر کرم ها و ساير حملات موفقيت آميز در اينترنت ، بدليل وجود نقاط آسيب پذير در تعدادی اندک از سرويس های سيستم های عامل متداول است . مهاجمان ، با فرصت طلبی خاص خود از روش های متعددی بمنظور سوء استفاده از نقاط ضعف امنيتی شناخته شده ، استفاده نموده و در اين راستا ابزارهای متنوع ، موثر و گسترده ای را بمنظور نيل به اهداف خود ، بخدمت می گيرند . مهاجمان ، در اين رهگذر متمرکز بر سازمان ها و موسساتی می گردند که هنوز مسائل موجود امنيتی ( حفره ها و نقاط آسيب پذير ) خود را برطرف نکرده و بدون هيچگونه تبعيضی آنان را بعنوان هدف ، انتخاب می نمايند . مهاجمان بسادگی و بصورت مخرب ، کرم هائی نظير : بلستر ، اسلامر و Code Red را در شبکه منتشر می نمايند. آگاهی از مهمترين نقاط آسيب پذير در سيستم های عامل ، امری ضروری است . با شناسائی و آناليز اينگونه نقاط آسيب پذير توسط کارشناسان امنيت اطلاعات ، سازمان ها و موسسات قادر به استفاده از مستندات علمی تدوين شده بمنظور برخورد منطقی با مشکلات موجود و ايجاد يک لايه حفاظتی مناسب می باشند.
در مجموعه مقالاتی که ارائه خواهد شد ، به بررسی مهمترين نقاط آسيب پذير يونيکس و لينوکس خواهيم پرداخت . در اين راستا ، پس از معرفی هر يک از نقاط آسيب پذير ، علت وجود ضعف امنيتی ، سيستم های عامل در معرض تهديد ، روش های تشخيص آسيب پذيری سيستم و نحوه مقابله و يا پيشگيری در مقابل هر يک از نقاط آسيب پذير ، بررسی می گردد .همزمان با ارائه مجموعه مقالات مرتبط با يونيکس ( پنج مقاله ) ، به بررسی مهمترين نقاط آسيب پذير در ويندوز ، طی مقالات جداگانه ای خواهيم پرداخت .
همانگونه که اشاره گرديد ، اغلب تهديدات و حملات ، متاثر از وجود نقاط آسيب پذير در سيستم های عامل بوده که زمينه تهاجم را برای مهاجمان فراهم می آورد . شناسائی و آناليز نقاط آسيب پذير در هر يک از سيستم های عامل ، ماحصل تلاش و پردازش دهها کارشناس امنيتی ورزيده در سطح جهان است و می بايست مديران سيستم و شبکه در يک سازمان بسرعت با آنان آشنا و اقدامات لازم را انجام دهند.
نقاط آسيب پذير موجود در هر سيستم عامل که در ادامه به آنان اشاره می گردد ، سندی پويا و شامل دستورالعمل های لازم بمنظور برخورد مناسب با هر يک از نقاط آسيب پذير و لينک هائی به ساير اطلاعات مفيد و تکميلی مرتبط با ضعف امنيتی است .

مهمترين نقاط آسيب پذير:
يونيکس ، يکی از سيستم های عامل رايج در جهان بوده که امروزه در سطح بسيار وسيعی استفاده می گردد . تا کنون حملات متعددی توسط مهاجمين متوجه سيستم هائی بوده است که از يونيکس ( نسخه های متفاوت ) بعنوان سيستم عامل استفاده می نمايند . با توجه به حملات متنوع و گسترده انجام شده ، می توان مهمترين نقاط آسيب پذير يونيکس را به ده گروه عمده تقسيم نمود :

• BIND Domain Name System
• Remote Procedure Calls (RPC)
• Apache Web Server
• General UNIX Authentication Accounts with No Passwords or Weak Passwords
• Clear Text Services
• Sendmail
• Simple Network Management Protocol (SNMP)
• Secure Shell (SSH)
• Misconfiguration of Enterprise Services NIS/NFS
• Open Secure Sockets Layer (SSL)

در بخش اول اين مقاله ، به بررسی BIND DomainName System وRemote Procedure Calls (موارد يک و دو) ، خواهيم پرداخت .

اولين نقطه آسيب پذير :BIND Domain Name System
نرم افزار BIND ) BerkeleyInternet Name Domain) ، در مقياس گسترده ای و بمنظور پياده سازی DNS)Domain Name Service) ، استفاده می گردد. BIND ، سيستمی حياتی است که از آن بمنظور تبديل اسامی ميزبان ( نظير : www.srco.ir ) به آدرس IP ريجستر شده ،استفاده می گردد .با توجه به استفاده وسيع از BIND و جايگاه حياتی آن در يک شبکه کامپيوتری ، مهاجمان آن را بعنوان يک هدف مناسب بمنظور انجام حملات ، خصوصا" از نوع DoS)Denila Of Service) انتخاب و حملات متنوعی را در ارتباط با آن انجام داده اند. حملات فوق،از کارافتادن سرويس DNS و عدم دستيابی به اينترنت برای سرويس های مربوطه و ميزبانان را می تواند بدنبال داشته باشد. با اينکه پياده کنندگان BIND ، تلاشی مستمر را از گذشته تا کنون بمنظور برطرف نمودن نقاط آسيب پذير انجام داده اند ، ولی هنوز تعداد زيادی از نقاط آسيب پذير قديمی ، بدرستی پيکربندی نشده و سرويس دهندگان آسيب پذير در آن باقی مانده است .
عوامل متعددی در بروز اينگونه حملات نقش دارد: عدم آگاهی لازم مديران سيستم در خصوص ارتقاء امنيتی سيستم هائی که بر روی آنان Bind deamon بصورت غير ضروری اجراء می گردد و پيکربندی نامناسب فايل ها ، نمونه هائی از عوامل فوق بوده و می تواند زمينه يک تهاجم از نوع DoS ، يک Buffer Overflow و يا بروز اشکال در DNS Cache را بدنبال داشته باشد.از جمله موارديکه اخيرا" در رابطه با ضعف امنيتی BIND کشف شده است مربوط به يک تهاجم از نوع DoS است . مقاله CERT AdvisoryCA-2002-15 جزئيات بيشتری را در اين رابطه ارائه می نمايد. از ديگر حملات اخير ، تهاجمی از نوع BufferOverflow است . مقاله CERT AdvisoryCA-2002-19 جزئيات بيشتری را در اين رابطه در اختيار قرار می دهد. درتهاجم فوق ، يک مهاجم از نسخه آسيب پذير پياده سازی توابع Resolver مربوط به DNS استفاده و با ارسال پاسخ های مخرب به DNS و اجرای کد دلخواه ، امکان سوء استفاده از نقطه آسيب پذير فوق را فراهم و حتی دربرخی موارد می تواند زمينه بروز يک تهاجم از نوع DoS را باعث گردد .
تهديدی ديگر که می تواند در اين رابطه وجود داشته باشد ، حضور يک سرويس دهنده BIND آسيب پذير در شبکه است . در چنين مواردی ، مهاجمان از وضعيت فوق استفاده و از آن بمنزله مکانی جهت استقرار داده های غير معتبر خود و بدون آگاهی مديرسيستم استفاده می نمايند. بدين ترتيب ، مهاجمان از سرويس دهنده بعنوان پلات فرمی بمنظور فعاليت های آتی مخرب خود بهره برداری خواهند کرد .

سيستم های عامل در معرض تهديد :
تقريبا" تمامی سيستم های عامل يونيکس و لينوکس بهمراه يک نسخه از BIND ارائه شده اند .در صورت پيکربندی ميزبان بعنوان سرويس دهنده ، نسخه ای از BIND بر روی آن نصب خواهد شد.

نحوه تشخيص آسيب پذيری سيستم :
در صورت دارا بودن نسخه خاصی از BIND که بهمراه سيستم عامل ارائه و بر روی سيستم نصب شده است ، می بايست عمليات بهنگام سازی آن را با استفاده از آخرين Patch های ارائه شده توسط توليد کننده ( عرضه کننده ) انجام داد. در صورت استفاده از نسخه BIND مربوط به ISC: Internet Software Consortium ، می بايست از نصب آخرين نسخه BIND ، اطمينان حاصل نمود . در صورتيکه BIND نصب شده بر روی سيستم ، نسخه ای قديمی بوده و يا بطور کامل Patch نشده باشد ، احتمال آسيب پذيری سيستم وجود خواهد داشت . در اکثر سيستم ها ، دستور : "named - v " ، اطلاعات لازم در خصوص نسخه BIND نصب شده بر روی سيستم را بصورت X.Y.Z نمايش خواهد داد . X ، نشاندهنده نسخه اصلی ، Y ،نشاندهنده جزئيات نسخه و Z نشاندهنده يک PatchLevel است . پيشنهاد می گردد ، آخرين نسخه BIND ارائه شده توسط ISC را دريافت و آن را بر روی سيستم نصب نمود. آخرين نسخه موجود Version 9.2.2 بوده و می توان آن را از سايت ISCدريافت نمود. يکی ديگر از رويکردهای کنشگرايانه مرتبط با نگهداری امنيت BIND ، عضويت در گروه های خبری نظير Symantec برای آگاهی از آخرين هشدارهای امنيتی است . در اين راستا می توان از يک برنامه پويشگر بهنگام شده که قادر به بررسی دقيق سيستم های DNS بمنظور تشخيص نقاط آسيب پذيراست ، نيز استفاده گردد .

نحوه حفاظت در مقابل نقطه آسيب پذير:
بمنظور حفاظت در مقابل نقاط آسيب پذير مرتبط با BIND موارد زير پيشنهاد می گردد :

• غير فعال نمودن BIND deamon ( به آن named نيز اطلاق می گردد ) بر روی سيستم هائی که بعنوان يک سرويس دهنده DNS در نظر گرفته نشده اند . بمنظور پيشگيری ازاعمال برخی تغييرات خاص ( نظير فعال نمودن مجدد آن ) ، می توان نرم افزار BIND را از روی اينگونه سيستم ها حذف نمود.
• بمنظور بهنگام سازی سرويس دهنده DNS ، از تمامی Patch های ارائه شده توسط توليد کنندگان استفاده و در صورت امکان آن را به آخرين نسخه موجود ارتقاء دهيد . برای دريافت اطلاعات تکميلی در رابطه با نصب مطمئن تر BIND ، از مقالات ارائه شده درسايت CERT و بخش UNIX SecurityChecklist ، استفاده نمائيد .
• بمنظور پيچيده تر نمودن حملات اتوماتيک و يا پويش سيستم مورد نظر ، Banner مربوط به " Version String " را از BIND حذف و نسخه واقعی BIND را با يک شماره نسخه غيرواقعی در فايل named.conf ، جايگزين نمائيد .
• امکان ارسال انتقالات Zone را صرفا" برای سرويس دهندگان ثانويه DNS در Domain فراهم نمائيد ( secondary DNS servers) . امکان انتقالات Zone در ارتباط با Domain های Parent و Child را غير فعال و در مقابل از امکان Delegation ( واگذاری مسئوليت ) و فورواردينگ ( Forwarding ) استفاده نمائيد .
• امکان Recursion و glue fetching را بمنظور حفاظت در مقابل عماکرد ناصحيح DNS Cache ، غير فعال نمائيد .
• بمنظور حفاظت در رابطه با استفاده از "named" و تحت تاثير قرار دادن تمامی سيستم ، BIND را محدود نمائيد . بنابراين BIND بعنوان يک کاربر non-privilage در دايرکتوری Chroot اجراء می گردد. برای نسخه شمازه نه BIND از آدرس http://www.losurs.org/docs/howto/Chroot-BIND.html استفاده نمائيد .

بمنظور حفاظت در مقابل حملات اخير و مرتبط با نقاط آسيب پذير کشف شده BIND می توان از منابع زير استفاده نمود:

• برای نقطه آسيب پذير DoS در رابطه با ISC BIND 9 از آدرس http//www.cert.org/advisories/CA-2002-15.html استفاده گردد.
• چندين نقطه آسيب پذير DoS در رابطه با ISC BIND 8 از آدرس http://www.isc.org/products/BIND/bind-security.html استفاده گردد .

برای آگاهی و استفاده از پيشنهادات لازم بمنظور نصب ايمن تر BIND بر روی سيستم های سولاريس ، می توان از آدرس :Running the BIND9 DNS Server Securely و آرشيو مقالات ارائه شده در آدرس Afentis استفاده نمود.

دومين نقطه آسيب پذير : ( Remote Procedure Calls (RPC
با استفاده از RPC برنامه های موجود بر روی يک کامپيوتر قادر به اجرای روتين هائی در کامپيوتر دوم از طريق ارسال داده و بازيابی نتايج می باشند . با توجه به جايگاه عملياتی RPC ، استفاده از آن بسيار متداول بوده و درموارد متعددی از آن بمنظور ارائه سرويس های توزيع شده شبکه نظير مديريت از راه دور ، اشتراک فايل NFS و NIS استفاده می گردد.وجود ضعف های امنيتی متعدد در RPC باعث بهره برداری مهاجمان بمنظور انجام حملات مختلفی شده است .دراکثر موارد ، سرويس های RPC با مجوزهای بيش از حد معمول ، اجراء می گردند . بدين ترتيب يک مهاجم غير مجاز قادر به استفاده از سيستم های آسيب پذير در جهت اهداف خود خواهد بود.اکثر حملات از نوع DoS در سال 1999 و اوايل سال 2000 در ارتباط با سيستم هائی بود که دارای ضعف امنيـتی و نقظه آسيب پذير RPC بودند. مثلا" حملات گشترده و موفقيت آميز در رابطه با سيستم های نظامی امريکا ، بدليل نقطه آسيب پذير RPC کشف شده در صدها دستگاه کامپيوتر مربوط به وزارت دفاع امريکا بوده است . اخيرا" نيز وجود يک ضعف امنيتی DCOMRPC در ويندوز ، باعث انتشار گسترده يک کرم در سطح اينترنت گرديد .

سيستم های عامل در معرض تهديد :
تمامی نسخه های يونيکس و لينوکس که بر روی آنان سرويس های RPC نصب شده است در معرض اين آسيب می باشند .

نحوه تشخيص آسيب پذيری سيستم :
با استفاده از يک پويشگر نقاط آسيب پذير و يا دستور " rpcinfo" ، می توان از اجراء يکی از سرويس های متداول RPC بر روی سيستم آگاه گريد :

RPC Service	RPC Program Number
rpc.ttdbserverd	100083
rpc.cmsd	100068
rpc.statd	100024
rpc.mountd	100005
sadmind	100232
cachefsd	100235
snmpXdmid	100249

سرويس های RPC ، عموما" از طريق حملات buffer Overflow ، مورد سوء استفاده قرار می گيرند .علت اين امر ، عدم انجام بررسی لازم و کافی در خصوص خطاها و يا اعتبار داده های ورودی توسط برنامه های RPC است . نقاط آسيب پذير Buffer overflow ، اين امکان را برای يک مهاجم فراهم می نمايد که داده غير قابل پيش بينی را ( اغلب بصورت کد مخرب ) به درون حافظه برنامه ، ارسال نمايد . با توجه به ضعف موجود در رابطه با بررسی خطاء و صحت داده ، داده ارسالی مکان هائی حساس و کليدی که مورد استفاده پردازنده می باشند را بازنويسی می نمايد.در يک تهاجم موفقيت آميز Overflow ، کد مخرب ارسالی ،در ادامه توسط سيستم عامل اجراء می گردد . با توجه به اينکه تعداد زيادی از سرويس های RPC ، با مجوزهای بيش از حد معمول ، اجراء می گردند ، استفاده موفقيت آميز از نقاط آسيب پذير فوق می تواند امکان دسـيابی غير مجاز و از راه دور را به سيستم فراهم می نمايد.

نحوه حفاظت در مقابل نقطه آسيب پذير:
بمنظور حفاظت سيستم در مقابل حملات مبتنی بر RPC ، موارد زير پيشنهاد می گردد :

• غير فعال نمودن و يا حذف هر يک از سرويس های RPC که ضرورتی به استفاده از آن بر روی شبکه نمی باشد .
• نصب آخرين Patch ارائه شده در رابطه با سرويس هائی که امکان حذف آنان وجود ندارد:
  - برای نرم افزار سولاريس از آدرس ( http://sunsolve.sun.com ) استفاده گردد.
  - برای IBM AIX از آدرس : http://www.ibm.com/support/us و http://techsupport.services.ibm.com/server/fixes استفاده گردد.
  - برای نرم افزار SGI از آدرس : http://support.sgi.com استفاده گردد .
  - برای کامپک ( Digital Unix ) از آدرس http://www.compaq.com/support
  - برای لينوکس از آدرس : http://www.redhat.com/apps/support/errata و http://www.debian.org./security استفاده گردد .
• عمليات جستجو بمنظور آگاهی و نصب آخرين Patch مربوطه می بايست بصورت مستمر انجام شود.
• پورت 111 ( TCP و UDP ) مربوط به RPC portmapper و پورت 135 ( TCP و UDP ) مربوط به Windows RPC را در سطح روتر و يا فايروال بلاک نمائيد .
• پورت های Loopback 32770 ، 32789 مربوط بهTCP و UDP را بلاک نمائيد .
• فعال نمودن يک پشته غيراجرائی بر روی سيستم های عاملی که از ويژگی فوق ، حمايت می نمايند. استفاده از يک پشته غيراجرائی ، لايه ای حفاظتی در مقابل تمامی حملات Buffer overflows نبوده ولی می تواند عاملی موثر در جهت مقابله با برخی از حملات استاندارد گردد.
• در ارتباط با سيستم های فايل NFS صادراتی ، مراحل زير می بايست دنبال گردد :
  - استفاده از ميزبان / IP مبتنی بر ليست های صادراتی
  - پيکربندی سيستم های فايل صادراتی بصورت فقط خواندنی
  - استفاده از "nfsbug" برای پويش نقاط آسيب پذير

سومين نقطه آسيب پذير : WindowsAuthentication
استفاده از رمزعبور، روش های تائيد کاربر و کدهای امنيتی در هر گونه تعامل ارتباطی بين کاربران وسيستم های اطلاعاتی ، امری متداول و رايج است . اکثر روش ها ی تائيد کاربران ، نظير حفاظت فايل و داده ، مستقيما" به رمزهای عبور ارائه شده توسط کاربران ، بستگی خواهد داشت . پس از تائيد کاربران ، امکان دستيابی آنان به منابع مشخص شده فراهم و هر يک از آنان با توجه به امتيازات و مجوزهای نسبت داده شده ، قادر به استفاده از منابع موجودخواهند بود. در اغلب موارد ، فعاليت کاربرانی که مجاز بودن آنان برای دستيابی به منابع ، تائيد شده است ، لاگ نشده و يا در صورتيکه فعاليت آنان ثبت گردد ، کمتر سوء ظنی به آنان می تواند وجود داشته باشد . ( آنان پس از تائيد وارد ميدانی شده اند که بدون هيچگونه رديابی ، قادر به انجام فعاليت های گسترده ای خواهند بود) . بنابراين ، رمز عبور دارای نقشی حياتی و اساسی در ايجاد اولين سطح دفاع در يک سيستم اطلاعاتی بوده و از دست رفتن رمز عبور و يا ضعف آن می تواند سيستم را در معرض تهديدات جدی قرار دهد . مهاجمان پس از دستيابی به رمز عبور کاربران تائيد شده ( استفاده از مکانيزم های متفاوت ) قادر به دستيابی منابع سيستم و حتی تغيير در تنظيمات ساير account های تعريف شده و موجود بر روی سيستم خواهند بود،عملياتی که می تواند پيامدهای بسيار منفی را بدنبال داشته باشد . پس می بايست بپذيريم که وجود يک account ضعيف و يا فاقد رمز عبور می تواند تهديدی جدی در يک سازمان باشد . در اين راستا علاوه بر اينکه می بايست از پتانسيل های ارائه شده توسط سيستم عامل با دقت استفاده نمود ، ضروری است ، تابع يک سياست امنيتی تدوين شده در رابطه با رمز عبور در سازمان متبوع خود باشيم . تعريف و نگهداری يک account بهمراه رمز عبور مربوطه در سازمان ما تابع چه سياست امنيتی است ؟ مهمترين و متداولترين نقاط آسيب پذير در ارتباط با رمز عبور شامل موارد زير است :

• Account تعريف شده دارای رمز عبور ضعيف و يا فاقد رمز عبور است .
• عدم حفاظت مناسب کاربران از رمزهای عبور ،صرفنظر از استحکام رمزهای عبور تعريف شده .
• سيستم عامل و يا ساير نرم افزارهای موجود ، امکان ايجاد account مديريتی ضعيف و فاقد رمز عبور را فراهم می نمايند .

• الگوريتم های Hashing رمز عبور( رمزنگاری مبتنی بر کليد عمومی بر پايه يک مقدار hash ، استوار بوده و بر اساس يک مقدار ورودی که دراختيار الگوريتم hashing گذاشته می گردد ، ايجاد می گردد. در حقيقت مقدار hash ، فرم خلاصه شده و رمز شده ای از مقدار اوليه خود است ) ، شناخته شده بوده و در اغلب موارد مقدار Hashe بدست آمده ، بگونه ای ذخيره می گردد که امکان مشاهده آن توسط سايرين وجود خواهد داشت. مناسبترين نوع حفاظت در اين راستا ، تبعيت از يک سياست رمز عبور قدرتمند بوده که در آن دستورالعمل ها ی لازم برای تعريف يک رمز عبورمناسب مشخص و در ادامه با استفاده از ابزارهای موجود، بررسی لازم در خصوص استحکام و بی نقص بودن رمز عبور صورت گيرد.

ويندوز، رمزهای عبور را بصورت متن شفاف ذخيره و يا ارسال نمی نمايد و در اين راستا از يک مقدار Hash متناظر با رمزعبور ، بمنظور تائيد کاربران ، استفاده می نمايد . يک مقدار Hash دارای طولی ثابت است که توسط بکارگيری يک تابع رياضی ( الگوريتم hashing ) بر روی حجم دلخواهی از داده ( message digest ناميده می شود) ايجاد می شود.در وينوز سه نوع الگوريتم تائيد وجود دارد :

• LM ( ايمنی کمتر و سازگاری بيشتر )
• NTLM
• NTLMv2 ( ايمنی بيشتر و سازگاری کمتر )

با اينکه اکثر محيط های فعلی ويندوز ، ضرورتی به حمايت از (Lan Manager (LM را ندارند، ولی ويندوز بصورت محلی رمز های عبور Hash شده مربوط به LM را ( LANMAN Hashes نيز ناميده می شود ) بصورت پيش فرض در ويندوز NT ، 2000 و XP ( در ويندوز 2003 وضعيت بدين شکل نيست ) ذخيره می نمايد. با توجه به اينکهLM از يک مدل رمزنگاری بمراتب ضعيف تر نسبت به رويکردهای فعلی مايکروسافت ( NTLM,NTLMv2 ) ، استفاده می نمايد، رمزهای عبور LM می توانند در مدت زمانی کوتاه شکسته گردند. حتی رمزهای عبوری که دارای قدرت و استحکام مناسبی می باشند ، در کمتر از يک هفته با استفاده از روش هائی خاص و با اتکاء به قدرت سخت افزارهای موجود ، شکسته خواهند شد
http://www.msdn.miscrosoft.com/library/default.asp?url=/library/en-us/security/Security/h_gly.asp

ضعف LM hashes بدلايل زير است :

• رمزهای عبور محدود به چهارده کاراکتر می باشند .
• رمزهای عبور با استفاده از فضای خالی ، به چهارده کاراکتر تبديل می شوند .
• رمزهای عبور تماما" به حروف بزرگ تبديل می گردند .
• رمزهای عبور به دو بخش هفت کاراکتری مجزا تقسيم می گردند .

با توجه به ماهيت فرآيند hashing ،يک مهاجم صرفا" می بايست عمليات تشخيص رمز عبور( cracking) را محدود به دو مجموعه نمايد که هر يک دارای هفت کاراکتر بوده که به حروف بزرگ تبديل شده اند . با تکميل عمليات فوق و اخد نتايج مثبت ، يک مهاجم قادر به تشخيص رمز عبور يک کاربر تائيد شده می گردد وبدين ترتيب ، امکان دستيابی وی به منابع سيستم فراهم خواهد شد. پيچيدگی عمليات تشخيص Hashe ، متنا سب با طول Hash افزايش می يابد ، بنابراين رشته هائی که صرفا" شامل هفت کاراکتر می باشند ، بمراتب راحت تر نسبت به رشته هائی که دارای چهارده کاراکتر می باشند ، تشخيص داده و اصطلاحا" شکسته می گردند. با توجه به اين موضوع که تمامی رشته ها شامل هفت کاراکتر بوده و تمامی آنان به حروف بزرگ نيز تبديل می گردند ، يک تهاجم به "سبک - ديکشنری" ( dictionary-style ) نيز بسادگی محقق و موفقيت آن تضمين شده خواهد بود. بنابراين، روش LMhashing ، آسيبی جدی را متوجه سياست های امنيتی رمز عبور نموده و سيستم را در معرض تهديد قرار خواهد داد .
علاوه بر تهديد و خطر ذخيره سازی LM hashes در SAM ، فرآيند تائيد Lan Manager ، اغلب و بصورت پيش فرص بر روی سرويس گيرندگان فعال و توسط سرويس دهنده پذيرفته می گردد . لازم است به اين نکته اشاره گردد که ، ماشين هائی که بر روی آنان ويندوز نصب شده است ، قادر به استفاده از الگوريتم های hash بمراتب قويتر در مقابل روش ضعيف LMhashes بمنظور ارسال داده های حساس نظير رمز عبور می باشند .حداقل پيامد منفی استفاده از روش LM hashes ، آسيب پذيری سيستم تائيد کاربران در ويندوز بوده و قطعا" در چنين مواردی نمی توان به فرآيند تائيد کاربران ، اعتماد نمود چراکه در اين وضعيت عملا" امکان استراق سمع ( شنود اطلاعاتی ) فراهم و يک مهاجم قادر به تشخيص و بدست آوردن رمزهای عبور خواهد بود.

سيستم های عامل در معرض تهديد :
تمامی نسخه های ويندوز در معرض اين تهديد قرار دارند .

نحوه تشخيص آسيب پذيری سيستم:
با اينکه دلايل و علل متفاوتی می تواند در در رابطه با ضعف رمز عبور مورد توجه قرار گيرد ، مثلا" وجود Account های فعال برای کاربرانی که سازمان خود را ترک نموده ويا سرويس هائی که اجراء نشده اند، ولی يکی از مناسبترين روش ها بمنظور آگاهی از استحکام يک رمز عبور ، بررسی و تست تمامی آنان در مقابل نرم افزارهای cracking رمزهای عبور استفاده شده توسط مهاجمان است . لازم است به اين نکته مهم اشاره گردد که از برنامه های تشخيص دهنده رمز عبور بر روی سيستم هائی که حتی مجوز دستيابی به آنان را داريد ، بدون اخذ مجوزهای لازم از مديران ارشد سيستم ، نمی بايست استفاده نمود. برای دريافت نمونه برنامه هائی در اين زمينه می توان از LC4 )l0phtcrack version 4) و John the Ripper استفاده کرد . صرفنظر از رويکرد ذخيره سازی محلی LAN Managerhash ، موارد زير می بايست موردتوجه قرار گيرد :

• در صورتيکه ويندوز NT ، 2000 و يا XP بصورت پيش فرض نصب شده اند،سيستم در معرض آسيب خواهد بود. در چنين مواردی Lan Manager hashes بصورت پيش فرض و محلی ذخيره می گردد.
• در صورتيکه ، بدلايلی نيازمند تائيد مبتنی بر LM در يک سازمان بمنظور ارتباط با سرويس دهنده وجود داشته باشد ، سيستم مجددا" در معرض آسيب قرار خواهد گرفت .چراکه اين نوع از ماشين ها اقدام به ارسال LM hashes نموده و پتانسيل شنود اطلاعاتی در شبکه را ايجاد خواهند کرد.

نحوه حفاظت در مقابل نقطه آسيب پذير :
بهترين و مناسبترين دفاع در مقابل رمزهای عبور ضعيف ، استفاده از يک سياست مستحکم مشتمل بر دستورالعمل های لازم بمنظور ايجاد رمز عبور قدرتمند و بررسی مستمر آنان بمنظور اطمينان از استحکام و صحت عملکرد می باشد . در اين رابطه موارد زير پيشنهاد می گردد :

• اطمينان ازاستحکام و انسجام رمز های عبور . با استفاده از سخت افزار مناسب و اختصاص زمان کافی ، می توان هر رمز عبوری را crack نمود. در اين راستا می توان با استفاده ازروش های ساده و در عين حال موفقيت آميز، عمليات تشخيص رمز عبور را انجام داد . اغلب برنامه های تشخيص دهنده رمزعبوراز روشی موسوم به "حملات مبتنی بر سبک ديکشنری " ، استفاده می نمايند. با توجه به اينکه روش های رمز نگاری تا حدود زيادی شناخته شده می باشند ، برنامه های فوق ، قادر به مقايسه شکل رمز شده يک رمز عبور در مقابل شکل های رمز شده کلمات ديکشنری می باشند( در زبان های متعدد و استفاده از اسامی مناسب بهمراه جايگشت های مختلف آنان ) . بنابراين ، رمز عبوری که ريشه آن در نهايت يک کلمه شناخته شده باشد ، دارای استعداد ذاتی در رابطه با اين نوع از حملات خواهد بود . تعداد زيادی از سازمان ها ، آموزش های لازم در خصوص نحوه تعريف رمزهای عبور را به کارکنان خود داده و به آنان گفته شده است که رمزهای عبور مشتمل بر ترکيبی از حروف الفبائی و کاراکترهای ويژه را برای خود تعريف نمايند.متاسفانه اکثر کاربران اين موضوع را رعايت ننموده و بمنظور تعريف يک رمز عبور با نام "password" ، صرفا" اقدام به تبديل حروف به اعداد و يا حروف ويژه می نمايند ( pa$$w0rd) . چنين جايگشت هائی نيز قادر به مقاومت در مقابل يک تهاجم مبتنی بر ديکشنری نبوده و "pa$$w0rd" به روش مشابهی که "password" تشخیص داده می شود ، crack خواهد شد .
  يک رمز عبور خوب ، نمی بايست از ريشه يک کلمه و يا نام شناخته شده ای اقتباس شده باشد .در اين راستا لازم است به کاربران آموزش لازم در خصوص انتخاب و ايجاد رمزهای عبور از موارد تصادفی نظير يک عبارت ، عنوان يک کتاب ،نام يک آواز و يا نام يک فيلم داده شود. با انتخاب يک رشته طولانی که بر اساس رويکردهای خاصی می تواند انتخاب گردد( گرفتن اولين حرف هر کلمه ، جايگزينی يک کاراکتر خاص برای يک کلمه ، حذف تمامی حروف صدادارو ساير موارد ) ، کاربران قادر به ايجاد رمزهای عبور مشتمل بر ترکيبی از حروف الفبائی و حروف ويژه بوده که در صورت مواجه شدن با حملات مبتنی بر ديکشنری ، تشخيص آنان بسختی انجام می شود. لازم است به اين نکته نيز اشاره گردد که رمزعبور می بايست براحتی بخاطر سپرده شده و بازيابی ( يادآوری)آن مشکل نباشد ( هدف از ذخيره سازی ، بازيابی است اگر چيزی را ذخيره نمائيم ولی در زمان مورد نظر قادر به بازيابی آن نباشيم ، سيستم ذخيره و بازيابی ما با اشکال مواجه شده است ! ). پس از تدوين دستورالعمل لازم بمنظور توليد رمزهای عبور مناسب و آموزش کاربران بمنظور پايبندی به اصول امنيتی تعريف شده ، می بايست از روتين ها ی جانبی متعددی بمنظور اطمينان از پيروی کاربران از دستوراالعمل های اعلام شده ، استفاده گردد. بهترين گزينه در اين راستا ، بررسی صحت رمزهای عبور پس از اعمال تغييرات توسط کاربران است .
  ويندوز 2000 ، XP و 2003 دارای ابزارهای قدرتمندی بمنظورافزايش توان سياست های امنيتی می باشند . در اکثر نسخه های ويندوز بمنظور مشاهده سياست تعريف شده در رابطه با رمز می توان از مسير زير استفاده و برنامه Local Security Policy را فعال نمود:

 

 

Local Security Policy Program

Start| Programs|Administrative Tools |Local Security Policy Select : Account Policies , Then Password Policy

• برنامه Local SecurityPolicy دارای تنظيمات زير است :
  Password must meet complexity requirements ، با فعال نمودن سياست فوق ، رمزهای عبور ملزم به رعايت استانداردهای موجود بمنظور استحکام و پيچيدگی بيشتر در زمان ايجاد و يا تغيير می باشند. در چنين حالتی ، رمزهای عبور تعريف شده می بايست با لحاظ نمودن موارد زير ايجاد گردند:
  
  ◄ رمز عبور، نمی بايست شامل تمام و يا بخشی از نام account کاربر باشد .
  ◄ رمز عبور می بايست دارای حداقل شش کاراکتر باشد .
  ◄ رمز عبور می بايست شامل کاراکترهائی از سه گروه از چهار مجموعه زير باشد :
  ● حروف بزرگ الفبای انگليسی ( A تا Z )
  ● حروف کوچک الفبای انگليسی ( a تا z )
  ● ارقام پايه دهدهی ( رقم های 0 تا 9 )
  ● کاراکترهای غير الفبائی ( مثلا" ! ، $ ، # ، % )
  
  ( Enforcepassword history (range: 0-24 . اغلب کاربران تمايل دارند که پس از انقضاء تاريخ استفاده از رمز عبور خود ، مجددا" همان رمز عبور قبلی را تعريف و از آن استفاده نمايند . با استفاده از سياست فوق ، می توان مشخص نمود که در چه زمانی و پس از چندين رمز عبور تعريف شده جديد ، کاربران مجاز به استفاده از رمزهای عبور قبلی خود برای وضعيت جديد می باشند .بدين ترتيب ،مديران شبکه اطمينان لازم در خصوص عدم استفاده مستمر و دائمی يک رمز عبور توسط کاربران را بدست آورده و اين موضوع می تواند از زوايای مختلفی بهبود وضعيت امنيتی شبکه را بدنبال داشته باشد . بمنظور نگهداری موثر تاريخچه رمز عبور، نمی بايست امکان تغيير رمزهای عبور بلافاصله پس از پيکربندی سياست minimum password age ، وجود داشته باشد .
  
  ( Maximum password age (range: 0-999 days . سياست فوق ، حداکثر عمر( اعتبار) يک رمز عبور را بر حسب روز ، مشخص می نمايد.( قبل از اينکه سيستم کاربر را ملزم به تغيير رمز عبور نمايد) . با در نظر گرفتن مقدار صفر ، رمز عبور دارای عمری جاودانه خواهد شد !
  
  (Minimum password age (range: 0-999 days . سياست فوق ، حداقل عمر( اعتبار) يک رمز عبور را بر حسب روز ، مشخص می نمايد( قبل از اينکه کاربر قادر به تغيير رمزعبور گردد) . با در نظر گرفتن مقدار صفر ، به کاربران اجازه داده خواهد شد که بلافاصله رمز عبور خود را تغيير دهند. minimum password age می بايست کمتر از maximum password age باشد . پيکربندی minimum password age می بايست بگونه ای انجام شود که دارای مقداری بيش از صفر باشد تا سياست password history نيز لحاظ شده باشد. بدون وجود يک minimum password age ، کاربران قادر به تغيير ادواری و زمانبندی نشده رمزهای عبور شده و امکان استفاده مجدد از رمزهای عبور قديمی در يک محدوده زمانی کمتر برای آنان فراهم می گردد.مقادير پيش فرض تامين کننده اهداف و خواست های امنيتی در يک سازمان نبوده و لازم است مديران سيستم در ابتدا يک رمز عبور مناسب را برای کاربر تعريف و پس از سپری شدن مدت زمان مشخصی ( مدت زمان فوق را minimum password age مشخص می نمايد ) کاربر را ملزم به تعريف ( تغيير ) رمز عبور تعريف شده توسط مديريت شبکه نمايند. زمانيکه کاربران ،عمليات Logon را انجام و در صورتيکه password history مقدار صفر را دارا باشد ، الزامی در رابطه با انتخاب يک رمز عبور جديد برای کاربران وجود نخواهد داشت . بدين دليل password history دارای مقدار پيش فرض يک است .
  
  (Minimum password length (range: 0-14 characters ، سياست فوق ، حداقل تعداد کاراکتر لازم برای تعريف يک رمز عبور را مشخص می نمايد( حداقل طول يک رمز عبور) می توان در اين رابطه حداقل طول يک رمز عبور را بين يک تا چهارده کاراکتر در نظر گرفت . با اختصاص مقدار صفر ، ضرورت وجود رمز عبور حذف می گردد. حداقل طول رمز عبور، می بايست متناسب و سازگار با سياست های امنيتی سازمان باشد. در صورتيکه در اين رابطه سياست مشخص و شفافی وجود ندارد می توان مقدار هشت را در نظر گرفت .برخی از سازمان های امنيت اطلاعات شبکه ، مقدار دوازده را در اين رابطه پيشنهاد داده اند .
  
  Store password using reversible encryption for all usersin the domain . سياست فوق ، مشخص می نمايد که می بايست رمزعبور با استفاده از رمزنگاری وارونه ، ذخيره گردد . در اين رابطه ، امکانات حمايتی لازم درخصوص برنامه هائی که از پروتکل هائی بمنظور آگاهی از رمز عبور کاربر بمنظور انجام فرآيند تائيد کاربران استفاده می نمايند، نيز ارائه شده است . ذخيره سازی رمزهای عبوری که از رمزنگاری وارونه استفاده می نمايند ، مشابه رمزهای عبورمعمولی است ( رمز عبور بصورت متن ذخيره می گردد). بنابراين فعال شدن سياست فوق می بايست با لحاظ نمودن پارامترهای متعددی نظير الزام يک برنامه بمنظور استفاده از يک رمز عبور حفاظت شده ، صورت پذيرد .
  يکی از روش هائی که می توان از آن بمنظور ايجاد اتوماتيک و نسبت دهی رمزهای عبور پيچيده به هر يک از account های کاربران استفاده نمود ، اجرای دستورالمل زير از طريق خط دستور است :

From Command Line Prompt :

Net User Username / random

• با اجرای دستورالعمل فوق ، رمزهای عبور تصادفی و پيچيده (همواره هشت کاراکتر طول ) به يک account نسبت داده شده و در ادامه رمزعبور مورد نظر بر روی صفحه نمايش داده می شود. روش فوق ، امکانی مناسب بمنظور نسبت دهی رمزهای عبوردر ارتبط با Service accounts بوده و کمتر در ارتباط با کاربران واقعی استفاده می گردد.
  بهترين روش برای مميزی کيفيت رمزهای عبور ، اجرای برنامه های cracking رمز عبور در وضعيتStand-alone است (بخشی از فرآيند بررسی رمزهای عبور) . لازم است مجددا" به اين موضوع اشاره گردد که بدون کسب مجوز لازم از مديران ارشد سيستم در سازمان ، نمی بايست از برنامه های cracking استفاده شود.پس از کسب مجوز لازم بمنظور اجرای برنامه های cracking رمز عبور ، می بايست عمليات فوق را بر روی يک ماشين حفاظت شده انجام داد.کاربرانی که رمزهای عبور آنان crack می گردد، می بايست موضوع بصورت محرمانه به اطلاع آنان رسيده و دستورالعمل های لازم در خصوص نحوه انتخاب يک رمز عبور مناسب ، در اختيار آنان قرار داده شود.اخيرا" و در پاسخ به رمزهای عبور ضعيف ، استفاده از روش هائی ديگر بمنظور تائيد کاربران، نظير بيومتريک (زيست سنجی ) ، نيز مورد توجه واقع شده است .
• حفاظت رمزهای عبور مستحکم . حتی اگر رمزهای عبور ، مستحکم و قدرتمند باشند ، در صورت عدم حفاظت آنان توسط کاربران ، سيستم های موجود در يک سازمان در معرض تهديد قرار خواهند گرفت . يک سياست امنيتی مناسب ، می بايست شامل دستورالعمل های لازم بمنظور آموزش کاربران در رابطه با حفاظت رمزهای عبور می باشد.عدم ارائه رمز عبور به افراد ديگر، عدم نوشتن رمز عبور در محلی که امکان خواندن آن برای ديگران وجود داشته باشد و حفاظت اتوماتيک فايل هائی که رمزهای عبور در آن ذخيره شده اند ، از جمله مواردی می باشند که می بايست به کاربران آموزش داده شود. اغلب کاربران در مواجهه با پيامی مشابه "Your password has expiredand must be changed," که نشاندهنده اتمام عمر مفيد يک رمز عبور است ، يک رمز عبور ضعيف را برای خود انتخاب می نمايند ، بنابراين لازم است در فرصت مناسب و قبل از برخورد با اينچنين پيام هائی ، به کاربران آموزش های لازم ارائه گردد.
• کنترل مستمر account ها . مديران سيستم و شبکه می بايست حضوری موثر و مستمر در ارتباط با مديريت account های موجود داشته باشند .
  - هر گونه account مبتنی بر سرويسی خاص و يا مديريتی که از آن استفاده نمی گردد، می بايست حذف گردد .
  - ممیزی account ها بر روی سيستم را انجام داده و لازم است در اين رابطه يک ليست اصلی ايجاد گردد .در اين رابطه می بايست رمزهای عبور در ارتباط با سيستم هائی نظير روترها ، چاپگرهای ديجيتالی متصل شده به اينترنت و ساير موارد ديگر نيز مورد بررسی قرار گيرد.
  - روتين هائی خاص بمنظور افزودن account های تائيد شده به ليست و يا حذف account هائی که ضرورتی به استفاده از آنان نمی باشد ، پياده سازی و همواره خود را پايبند به آن بدانيم .
  - اعتبار ليست را در فواصل زمانی خاصی بررسی تا از بهنگام بودن آن اطمينان حاصل گردد.
  - از روتين های خاصی بمنظورحذف account متعلق به کارکنان و يا پيمانکارانی که سازمان را ترک نموده اند ، استفاده گردد .
• نگهداری و پشتيبانی از سياست رمزعبور . بمنظور پشتيبانی و نگهداری مناسب رمز عبور، می توان علاوه بر استفاده از امکانات کنترلی ارائه شده توسط سيستم عامل و يا سرويس های شبکه ، از ابزارهای گسترده ای که در اين رابطه ارائه شده است ،نيز استفاده گردد . بدين ترتيب ،نگهداری سياست رمز عبور ، مبتنی بر آخرين تکنولوژی های موجود خواهد بود.
• غير فعال نمودن تائيد LM در شبکه . بهترين گزينه بمنظور جايگزينی با Lan Manager ، استفاده از روش NT LAN Managerversion 2) NTLMv2) است . متدهای چالش / پاسخ NTLMv2 ، با استفاده از رمزنگاری مستحکم تر و بهبود مکانيزم های تائيد ، اکثر صعف های LM را برطرف نموده است جدول زير ، کليد ريجستری موردنظری را که قابليت فوق را در ويندوز NT و 2000 کنترل می نمايد، نشان می دهد:

Rgistry key

Hive: HKEY_LOCAL_MACHINE Key: SystemCurrentControlSetControlLSA Value: LMCompatibilityLevel Value Type: REG_DWORD - Number Valid Range: 0-5 Default: 0

• پارامتر فوق ، نوع و روش تائيد را مشخص و می تواند مقداری بين صفر تا پنج را دارا باشد :
  0 - ارسال پاسخ بر اساس روش LM و NTLM ، هرگز از امکانات امنيتی NTLMv2 استفاده نمی شود .
  1 - استفاده از امکانات امنيتی NTLMv2
  2 - ارسال بر اساس روش تائيد NTLM
  3 - ارسال بر اساس روش تائيد NTLMv2
  4 - DC باعث رد تائيد LM می گرد.
  5 - DC باعث رد تائيد LM و NTLM شده و صرفا" تائيد NTLMv2 پذيرفته می گردد .

در ويندوز 2000 ، 2003 و XP نيز امکاناتی ارائه شده است که می توان با استفاده از آنان اقدام به پيکربندی تنظيمات مورد نظر در ارتباط با سطح تائيد Lan Manager نمود . در اين رابطه لازم است برنامه Local SecurityPolicy فعال و در ادامه گزينه های Local Policies و Security Options بترتيب انتخاب گردند . در ويندوز 2000 سياست LAN Manager authentication level ، و در ويندوز XP و 2003 سياست Networksecurity: LAN Manager authentication level ، بمنظور پيکربندی ومقداردهی مناسب انتخاب گردند .
در صورتيکه بر روی تمامی سيستم ها ، ويندوز NTSP4 و يا بعد از آن نصب شده باشد ، می توان مقدارپارامتر فوق را بر روی تمامی سرويس گيرندگان سه و بر روی Domain Controllers مقدار پنج درنظر گرفت (پيشگيری از ارسال LM hashes بر روی شبکه ) . سيستم هائی نظير ويندوز 95 و 98 از NTLMv2 بصورت پيش فرض بهمراه Microsoft Network Client استفاده نمی نمايند ، بنابراين لازم است بمنظور استفاده از قابليت های NTLMv2 ، برنامه Directory Services Client بر روی آنان نصب گردد. پس از نصب سرويس فوق ، مقدار ريجستری با نام LMCompatibility می تواند مقدار صفر و يا سه را دارا باشد .در صورتيکه نمی توان سرويس گيرندگان قديمی ( ويندوز 95 و يا ويندوز 98 ) را ملزم به استفاده از NTLMv2 نمود ، می توان تغيير مورد نظر را در رابطه با LM hashing نسبت به استفاده از NTLM (NT Lan Manager, version ) در Domain Controller اعمال نمود.در اين رابطه می توان مقدار LMCompatibilityLevel را چهار در نظر گرفت . درصورت استفاده از ابزاری نظير Local Security Policy،می بايست مقدار LAN Managerauthentication level را Send NTLMv2 Response onlyRefuse LM درنظر گرفت . لازم است به اين نکنه اشاره گردد که ايمن ترين گزينه در اين رابطه، اعمال محدوديت برروی سرويس گيرندگان است .