در این بخش از دوره آموزشی SEC542 شما با آسیب پذیری Shellshock و جزئیات آن آشنا شده و همچنین به مبحث Spidering هم پرداخته می شود.
Shellshock
در سپتامبر سال 2014 مجموعه ای از نقص های قابل توجهی که بر روی Bash تاثیر می گذاشت، اعلام شد که این آسیب پذیری با نام ShellShock معروف شد. با توجه به اینکه بیشتر توزیع های لینوکس مانند Mac OS X نیز از این شل استفاده می کردند، این آسیب پذیری موجب نگرانی آن ها نیز می شد.
آسیب پذیری ShellShock با کد CVE-2014-6271 به ثبت رسیده است و تمرکز آن بر روی Bash می باشد. Bash به عنوان یک مفسر دستور زبان عمل می کند. به عبارت دیگر، به کاربر اجازه می دهد هنگامی که سیستم عامل اجرا شد دستورات را در یک پنجره مبتنی بر متن وارد کند.
Bash همچنین برای اجرای دستورات ارسال شده به آن توسط برنامه های کاربردی استفاده می شود. و همین ویژگی است که آسیب پذیر است. نوعی از این دستورات که می تواند به Bash فرستاده شود اجازه می دهد که متغیرهای محیطی تنظیم شوند. متغیرهای محیطی پویا، مقادیر نامگذاری شده ای هستند که از طریق پروسس های اجرا شده روی کامپیوتر تأثیر می پذیرند.
در واقع این آسیب پذیری بیانگر این است که مهاجم می تواند کدهای مخرب خود را به متغیرهای محیطی پیوست کند و به محض اینکه متغیر دریافت شد کد مهاجم اجرا شود.
لازم به ذکر است که شش CVE جداگانه مربوط به این آسیب پذیری وجود دارد که ما بر دو نمونه از آن ها که شامل CVE-2014-6271 و CVE-2014-6278 می باشد، تمرکز می کنیم.
Shellshock and the Web
شما ممکن است تعجب کنید که چرا ما در مطالب مربوط به تست نفوذ وب، در مورد Bash صحبت می کنیم؟
شاید برای اکثر افراد ارتباط بین آسیب پذیری Bash و برنامه تحت وب کاملا واضح نباشد. برای توضیح این موضوع باید توجه داشته باشید که اولین و اساسی ترین راه اتصال ShellShock و وب، از طریق اسکریپت های CGI نوشته شده با استفاده از /bin/bash بر روی سیتسم است.
اگرچه استفاده از Bash در اسکریپت های SGI برای برنامه های کاربردی وب مدرن بسیار غیر معمول می باشد اما متاسفانه این بدین معنا نیست که ما در برابر این حمله مصون هسیتم. در بسیاری از توزیع های مدرن لینوکس /bin/sh یک Symlink برای /bin/bash می باشد. این موضوع همچنین می تواند CGI های نوشته شده در /bin/sh را آسیب پذیر نماید.
Michal Zalewski به این موضوع هم اشاره کرده بود که توابع popen() و system() هم می توانند آسیب پذیر باشند، پس می توان نتیجه گیری نمود که برنامه های وب نوشته شده با زبان های برنامه نویسی PHP، پایتون، جاوا و C نیز احتمالا آسیب پذیر هستند.
ShellShock Payload
تصویر بالا نشانگر نحوه اکسپلویت نمودن آسیب پذیری ShellShock می باشد. سوالی که در این بخش به وجود می آید این است که کجا ممکن است این رشته ها را تزریق نمود؟
در پاسخ باید گفت که در بخش User-Agent، کوکی، ورودی های Referer و در هر جایی که ممکن است یک متغیر محیطی CGI به پایان برسد، امکان تزریق کد وجود خواهد داشت.
توجه داشته باشید که سمیکالن به عنوان یک جداساز فرمان ها در سیستم های لینوکسی می باشد که اجازه می دهد دستورات متعدد را در یک خط وارد کنیم.
Injection Explained
بیایید یک رشته تزریق ShellShock را تجزیه کنیم تا دقیقا پی ببریم که این دستور چه کار می کند.
فرض ما بر این است که آسیب پذیری ShellSock با یک وب سرور آسیب پذیر در ارتباط است. در این سناریو سرور نه تنها یک نسخه آسیب پذیر از Bash را اجرا نموده است بلکه همچنین متغیرهای محیطی CGI را به Bash منتقل می کند. به احتمال زیاد متغیرهای محیطی CGI برای هدف ما، HTTP_USER_AGENT، HTTP_COOKIE و HTTP_REFERER می باشد.
در این مثال از User-Agent برای حمله استفاده می شود و به جای یک User-Agent مانند Mozilla/5.0 …. که به طور معمول انتظار می رود، ما بوسیله یک ابزار Intercept Proxy مانند ابزار Burp Suite می توانیم رشته زیر را ارسال نماییم:
() { 42;} ;echo ; /user/bin/id
بنابراین چیزی که به Bash به عنوان متغیر محیطی منتقل می شود عبارت زیر خواهد بود:
HTTP_USER_AGENT=’ () { 42;} ;echo; /usr/bin/id’
این تزریق ShellShock ما می باشد. در ادامه به توضیح بخش های مختلف این دستور می پردازیم تا اتفاقی که رخ می دهد را شرح دهیم.
بخش Prefix عبارت () { 42;}
Syntax بخش Prefix به Bash می گوید که HTTP_USER_AGENT فقط یک متغیر محیط استاندارد نبوده بلکه یک تابع Bash می باشد که در یک متغیر محیطی ذخیره شده است.
پرانتزها، نشان می دهد که این یک تابع است.
داخل { } مواردی است که تابع واقعا می خواهد آن را انجام دهد.
عدد 42 اختیاری است. ما می توانیم در این جا برخی از دستورات شل را قرار دهیم. اما در واقع چیزی در اینجا اجرا نخواهد شد. ما فقط به برخی از داده ها نیاز داریم که در فرآیند اجرا، خطایی رخ ندهد.
توجه داشته باشید که بیشتر پیلودهای ShellShock از یک کولن یا : استفاده می کند که به معنی do nothing برای Bash می باشد.
بخش Padding که شامل ;echo می باشد
اغلب مثال هایی که برای ShellShock آورده می شود، فاقد هرگونه Padding می باشد. اما از آن جا که ما تزریق را در هدر HTTP انجام می دهیم و به ماژول های سمت سرور برای مدیریت این داده ها نیاز است، اضافه نمودن یک ;echo به پیلود اصلی می توانند باعث جلوگیری از ایجاد پیام خطای سرور شود.
بخش Command که شامل ;/usr/bin/id می باشد
در این بخش دستوری که مد نظر ما بوده و قصد داریم تا این دستور در سیستم هدف اجرا شود را وارد می کنیم. در این مثال دستور مورد نظر ما id می باشد و اگر به صورت Blind از آسیب پذیری ShellShock استفاده کنیم از دستوراتی مانند Ping و یا Nslookup استفاده می نماییم.
Spidering Web Applications
فرآیند Spidering یا Crawling وب سایت در واقع دنبال نمودن لینک های وب سایت و دانلود صفحات است. نتیجه فرآیند مذکور این است که نفوذگر یک کپی از لینک های عمومی سایت را دارد. با انجام این کار، نفوذگر می تواند سایت هدف را در فرصت مناسب بررسی کند و به جست و جوی منابع و شناسایی نقاط ضعف آن بدون ایجاد لاگ در سرور بپردازد. ابزارهای ایجاد دیکشنری، می توانند وب سایت دانلود شده را تحلیل نموده و یک لیست از کلمات کلیدی را ایجاد نمایند که از این دیکشنری می توان در مراحل شکستن کلمات عبور استفاده نمود.
همچنین نفوذگران می توانند آدرس های ایمیل، اسامی، شماره های تماس و سایر داده ها را از سایت استخراج نمایند تا از آن ها در حملات مهندسی اجتماعی استفاده نماید. در نهایت هم نفوذگر می تواند از سایت دانلوده شده برای جست و جوی اطلاعاتی مانند کلمات عبور و اطلاعات حساس دیگری که با توجه به اشتباه مدیر سایت در آن قرار داده شده است نیز استفاده نماید. توجه داشته باشید که در طول زمان تست ما فرآیند Spidering را چندین بار انجام خواهیم داد. این عملیات توسط ابزارهای اسکن آسیب پذیری مانند Acunetix و یا ابزار Burp Suite هم انجام می شود.
Spidering Methods
قسمت عمده ای از هر آزمون نفوذپذیری وب انجام فرآیند Spidering است. شما می توانید هم به صورت دستی و هم به صورت خودکار با استفاده از ابزار این کار را انجام دهید. در صورتی که به صورت دستی این تست را انجام دهید باید پس از شناسایی هر بخش آن را بر روی سیستم خود ذخیره کنید.
توجه داشته باشید که امکان دارد وب سایت دارای صفحات و فرم های پیچیده ای باشد که با ابزار امکان شناسایی و دسترسی به آن وجود نداشته باشد ولی به صورت دستی قابل شناسایی هستند.
Robot Control
ابزارهای Spidering خودکار با نام Robots شناخته می شوند. این ها اغلب توسط موتورهای جست و جو مانند گوگل مورد استفاده قرار می گیرند تا یک پایگاه داده از صفحات موجود را ایجاد نمایند. همچنین مدیران وب سایت از قابلیت به منظور کنترل صحت لینک ها، جمع آوری آدرس های ایمیل و اهداف دیگر استفاده می کنند.
Robots Exclusion Protocol یک استاندارد غیررسمی است که به طور معمول به مدیران وب سایت اجازه می دهد تا بخش های مختلف سایت را برای عدم Crawl شدن مشخص نماید.
آن ها یک فایل با نام robots.txt را ایجاد نموده و آن را داخل پوشه اصلی یا اصطلاحا root سایت قرار می دهند. در این فایل لیست صفحات که نباید توسط موتورهای جست و جو Crawl شود، مشخص می گردد. بسیاری از روبات ها مانند Google Crawler این فایل را بررسی نموده و بر اساس آن عمل می نمایند.
به هرحال روبات ها این مسیرهای موجود در فایل robots.txt را نادیده می گیرند ولی نفوذگران می توانند از آن استفاده کنند، چرا که لیست از صفحات و دایرکتوری های سایت درون آن وجود دارد که می تواند در فرآیند نفوذ تاثیر گذار باشد.
علاوه بر این، مدیران وب سایت می توانند از تگ های متا در HTML استفاده نماید تا نشان دهند که ربات ها نباید یک صفحه خاص را مشاهده نمایند ولی این روش چندان مورد استفاده قرار نمی گیرد.
به عنوان مثال تگ های زیر برای عدم ذخیره سازی یا اصطلاحا Cache نمودن صفحات می شود:
همچنین برای کنترل ربات های موتور جست و جو و این که آن ها کجا باید بروند از تگ های زیر می توان استفاده نمود:
یکی از ابزارهای مناسب برای خودکار سازی فرآیند Spidering استفاده از ابزار ZAP می باشد. ZAP یا Zed Attack Proxy یک ابزار همه منظوره برای تست نفوذ وب می باشد که یکی از کارهای آن Spidering می باشد.
آنالیز نتایج Spidering
پس از انجام Spidering یک وب سایت، ما باید اطلاعات به دست آمده را به منظور شناسایی بخش های مهم، تجزیه و تحلیل نماییم. ما در این نتایج به دنبال کامنت های حساس موجود، توابع غیرفعال شده، لینک های مهم که ممکن است به سرورهای اپلیکیشن داده شده باشد و منجر به شناسایی آن ها شود، هستیم.
