tamadon

همه چیز در مورد CVE-2014-6271 یا ShellShock یا باگ بش

When Unix is shocked (Everything about CVE-2014-6271 or ShellShock or Bash Bug)

سلام

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

امسال، سالیه که کاربران یونیکس و به خصوص لینوکس شک زده شدند. در اوایل سال برنامه ای که قرار بود تامین کننده ی امنیت باشه، خونریزی کرد و الان هم (۲۴ سپتامبر ۲۰۱۴ یعنی ۲ مهر ۱۳۹۳) نسخه ای از Bash که عمر ۲۲ ساله داره دچار یک ضعف امنیتی وحشتناک شده. واو!

باگ Bash که بود و چه کرد؟!

بش یک مفسر است که دستورات کاربر را در محیط های یونیکسی مدیریت می کند. با استفاده از این باگ، هکر می تواند از راه دور، دستوراتی که می خواهد را در سیستم قربانی اجرا کند. اما هکر نیاز به دو دسترسی دارد. دسترسی به شل و دسترسی به متغیرهای محیطی یا Environment Variableها. این دسترسی در موارد زیر ایجاد می شود:

•     آپاچی سروری که از mod_cgi یا mod_cgid استفاده کند و در آن از اسکریپت های CGI استفاده شده باشد.

•     با استفاده از قابلیت ForceCommand در SSH. در بعضی از سایت ها نوشته شده که این قابلیت در OpenSSH موجود است. اما به نظر من اشتباه است. چون اگر قضیه مربوط بهOpenSSH میشد یعنی این که از قبل به کاربر دسترسی شل داده شده و دیگر نیازی به بایپس و دور زدن آن نیست. این قضیه بیشتر مربوط به تنظیمات sshd-که روی کاربران راه دور محدودیت هایی را در اجرای کد فراهم می سازد- می شود. (امیدوارم حق با من باشه  )

•     در DHCP client. اگر با DHCP آشنا باشید می دانید که طبق این پروتکل، یک سری تعامل بین سرور و کلاینت انجام میشود. حالا اگر سرور، بدخواه و مخرب باشد از طریق شل اسکریپتی که برای تنظیمات استفاده میشود، می تواند روی کلاینت ها با دسترسی root فرمان اجرا کند!

•     هر برنامه ی دیگری که با شل سر و کار داشته باشد. البته شرط آن این است که متغیرهایش را export کرده باشد. (وقتی export می کنیم یعنی آن را تبدیل به Environment Variable می کنیم.)

آیا سیستم من آسیب پذیر است؟

برای چک کردن این موضوع کافی است که دستور زیر را در شل یا ترمینال خود وارد کنید و در صورتی که پیام Bash is vulnerable چاپ شد یعنی اینکه شما نسبت به این رخنه آسیب پذیرید:

env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

و اگر عبارت زیر چاپ شد یعنی اینکه سیستم شما وصله شده است:

bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test

نکته: کمتر از ۲۴ بعد از انتشار این آسیب پذیری آپدیتی ارائه شد که به صورت ناقص بود و اگر چه که در برابر حملات عمومی مقاوم بود ولی راه دور زدن داشت. بنابراین اگر شما فقط در ساعات اولی سیستم خود را به روز کرده اید می بایست دوباره آن را آپدیت کنید. (یعنی تنها آپدیت های بعد از ۲۵ سپتامبر معتبرند)

چگونه سیستم خود را به روز کنم؟

خوشبختانه به روز رسانی و وصله کردن این باگ در سیستم ها مختلف بسیار آسان است و تنها کافی است که bash خود را به روز کنید:

• اوبونتو و سایر توزیع های لینوکس بر پایه ی debian

در ترمینال خود دستور زیر را وارد نمایید:

    sudo apt-get update && sudo apt-get install --only-upgrade bash

برای اطمینان، بعد از آپدیت دستوری که در قبل گفته شد را چک کنید.

• استفاده از yum در CentOS / Red Hat / Fedora

    sudo yum update bash

برای اطمینان، بعد از آپدیت دستوری که در قبل گفته شد را چک کنید.

• در OS X

    ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
    brew update
    brew install bash
    sudo sh -c 'echo "/usr/local/bin/bash" >> /etc/shells'
    chsh -s /usr/local/bin/bash

    برای اطمینان، بعد از آپدیت دستوری که در قبل گفته شد را چک کنید.

آیا خطر این آسیب پذیری از خونریزی قلبی بیشتر است؟

نظر شخصی من این است که بله! اولا که تعداد سیستم های آلوده به این رخنه بسیار بیشتر ازHearBleed است و دوم اینکه حتی اگر ادمین یک شبکه سرور را آپدیت کند باز هم تعداد زیادی سیستم ها بدون وصله باقی خواهند ماند که حتی با گذشت زمان هم وصله نخواهند شد. اما دسترسی اولیه ای که HearBleed در اختیار هکر قرار می دهد بیشتر از ShellShock بوده و ممکن است این باگ زمانی کارآمد باشد که نفوذگر از طریق دیگری وارد شبکه شده باشد.

این اتفاق به خاطر چیست؟ (کمی تخصصی)

موضوع مورد بحث در این مقاله صرفا مورد اول یا همون وب سروره. گفته شد که در وب سرور آپاچی، برای اکسپلوییت این آسیب پذیری باید از طریق CGI عمل کرد. اگر با cgi آشنایی داشته باشید می دونید که این اسکریپت ها با وب سرور در تعامل اند و دستورات بش رو اجرا می کنند. از طرفی می تونند خروجی رو به کاربر نهایی نشون بدند. بنابراین اولین شرط برقراره. یعنی اسکریپت های cgi به شل دسترسی دارند. دومین شرط هم وجود متغیرهای محیطی یا Environment Variable بود که خوشبختانه یا متاسفانه متغیرهایی مثل User-Agent یا Referrer به عنوان متغیرهای محیطی cgi شناخته می شوند. لیست کاملی از متغیرهای محیطی cgi در این لینک موجوده که ممکنه حمله از طریق هر کدام از این ها صورت بگیره. من یک عبارتی رو توییت کردم  که اگر اون رو درک کنید، دقیقا متوجه میشید که این اتفاق به خاطر چیه؟ و اون هم این بود که:

Bashمتغیرهای محیطی ای که با } () شروع میشه رو به عنوان تابع در نظر میگیره!

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