امنیت, برنامه‌نویسی

Session Fixation

احتمالا تا حالا واژه Session به گوشتون خورده. اگر برنامه نویس وب باشید که می دونید چیه ولی کاربرها باهاش درگیر نیستند و پیش هم نمیاد که لازم بشه در موردش بدونند.

بذارید یه مثال بزنم که بدونید سشن به چه کار میاد. تا حالا دیدید می رید توی یه سایت و اون خبر داره که قبلا اونجا بودید؟ جایی لاگین کردید و گزینه “مرا به خاطر بسپار” رو انتخاب کرده باشید؟ یا اصلا فکر کردید چطور می شه که شما توی صفحه login.php وارد می شید ولی دیگه هر صفحه از سایت رو باز کنید، نیازی نیست دوباره نام کاربری و پسورد وارد کنید؟ این کارها با سشن انجام می شه. ینی برنامه اون سایت از شما مشخصات رو می گیره و درصورتیکه درست بود براتون یه شماره شناسه در نظر می گیره و کافیه اون شماره شناسه رو تو صفحه های مختلف به همراه داشته باشید تا دیگه نیازی به وارد کردن مجدد پسورد نباشه. یا مثلا سایت اون شناسه رو فعال نگه داره و دو روز دیگه که وارد سایت شدید، وب اپلیکیشن اون شناسه رو از حافظه مرورگرتون بخونه و شما رو شناسایی کنه.

حالا اگه این شناسه به دست هکر بیافته چی می شه؟ می تونه با اون شناسه خودش رو به اسم شما جا بزنه. دزدی سشن روش های متفاوتی داره، از حدس زدن و کش رفتن تا تعیین آن به وسیله هکر.

در این پست در مورد Session Fixation در وب اپلیکیشن های مبتنی بر PHP خواهم گفت و یه سری راه رو هم برای جلوگیری از اون معرفی می کنم. تصمیم داشتم در این پست یک نمونه آنلاین از ضعف برنامه نویسی رو براتون بذارم که در واقع نتیجه رو ببینید ولی با توجه به تنظیمات سرور و PHP.ini این امکان وجود نداشت. برای تست می تونید از WebGoat استفاده کنید که یک پروژه است در قالب OWASP که یک نمونه از یک سایت آسیب پذیر رو در کامپیوتر شما ایجاد می کنه و می تونید روش این موارد رو امتحان کنید.

در یک حمله “تعیین سشن”، هکر کاربر یک سایت (ترجیحا ادمین) رو فریب می ده که یک لینک رو کلیک کنه:

و یا با یک کد، کاربر رو به لینک دلخواه هدایت می کنه:

ببینیم چه اتفاقی می افته در عمل:

ارسال لینک در قالب یک پیام درون سایت

ارسال لینک در قالب یک پیام درون سایت

اگر به لینک دقت کنید می بینید که با ارسال متغیر SID به صورت GET در URL، هکر اقدام به تعیین شماره شناسه ای می کنه که خودش ازش خبر داره. در صورتیکه کاربر کلیک کنه:

صفحه ورود سایت

صفحه ورود سایت

کاربر بدون اینکه شک کنه، نام کاربری و پسورد رو وارد می کنه و لاگین می کنه. حالا سایت یه سشن براش ایجاد می کنه ولی به جای اینکه شناسه سشن توسط سایت تعیین بشه، عدد ۱۲۳۴ براش به کار می ره.

کاربر با موفقیت به سایت وارد شده

کاربر با موفقیت به سایت وارد شده

از این زمان به بعد، هکر می تونه با استفاده از SID یا شناسه سشنی برابر با ۱۲۳۴ وارد سایت بشه و سطح دسترسی کاربر هدف رو داشته باشه.

به طور خلاصه، اتفاقی که در بالا افتاد رو می تونید در تصویر زیر ببینید:

security_corner_feb2004_1

یک نمونه از کد دارای ضعف امنیتی می تونه مشابه این باشه:

این کد تعداد دفعات بازدید شما از یک صفحه رو می شماره. اگر SID رو توی URL براش مشخص کنید و بعد با همون SID در یک مرورگر دیگه صفحه رو باز کنید، به جای اینکه در مرورگر دوم شمارش از صفر شروع بشه، ادامه شمارش مرورگر اول رو نشون می ده.

یکی از روش های پیشگیری از این حمله اینه که مطمئن بشیم در شروع یک سشن، حتما شناسه اون بازتولید بشه. نمونه کد زیر می تونه مثالی از این مورد باشه:

واقع در این کد چک می کنیم که اگر متغیر initiated قبلا ست نشده باشه (که به معنی ورود برای بار اوله) شناسه رو بازتولید می کنیم. البته این کد هم یک ضعف داره که با حمله ای پیچیده تر قابل دور زدن است. در این روش هکر در دو مرحله، ابتدا کاربر  رو فریب می ده و initiated ست بشه به مقدار True و سپس حمله عادی رو انجام می ده و SID رو تعیین می کنه.

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

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

روش دیگه برای جلوگیری از این حمله، خارج از بحث برنامه نویسی و با تعیین تنظیمات PHP سروره. کافیه که متغیر session.use_trans_sid رو برابر با ۰ قرار بدیم. این مورد باعث می شه که PHP نه شناسه رو توی URL قرار بده و نه از اونجا بخوندش.

منبع و منبع

Standard
امنیت

هک سخت افزاری: کابوس جدید

بعد از هک شدن سرور چه کار می کنید؟ می گردید و فایل های آلوده رو پیدا می کنید؟ تاریخچه تغییرات فایل ها رو چک می کنید و فایل هایی که پس از هک تغییر کردند رو با نسخه مطمئن جایگزین می کنید؟ بک آپ آخرین تاریخ مطمئن رو برمی گردونید؟ یا اصلا بی خیال سیستم عامل می شید و از اول نصبش می کنید و سرور رو دوباره کانفیگ می کنید؟

باید بگم که همه کارهای ممکن رو انجام دادید ولی خیالتون راحت نباشه. یک هکر (SpritesMods) که متخصص هک سخت افزاریه نشون داده که حتی با تغییر سیستم عامل هم می تونه سرور رو دوباره هک کنه.

احتمالا تا الان فکر می کردید (مثل من) که هارد درایو یه محل ذخیره سازی دیتاست که سیستم عامل کنترلش می کنه و یه کابل داره و یه سری بلاک روش وجود داره که دیتا روی اونها ذخیره و بعد خونده می شه. ولی همه هارد درایو این نیست. اگه یه هارد رو باز کنید یه کنترل کننده موتور می بیند، یه رم و یه تراشه. این تراشه نکته اصلیه که شامل یک پردازنده است و پردازنده هم یعنی امکان هک. هارد دیسک ها Firmware دارند. یک هکر پس از نفوذ به سرور و گرفتن دسترسی روت (بالاترین دسترسی. ویندوزی ها بهش ادمین می گن) می تونه این firmware رو بخونه، تغییر بده و بازنویسی کنه.

computer-hard-drive-800x800

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

فرض کنیم یک وب سرور لینوکسی داریم. هکر یک url خاص که شامل اون رشته باشه رو به سرور درخواست می ده. اون url صفحه خاصی رو باز نمی کنه و در error log سرور هم اون url ثبت می شه. کافیه که هکر پیش از این و در تغییرات firmware مشخص کرده باشه که با ذخیره شدن این رشته بر روی هارد، فایل etc/shadow به مقادیر مشخص شده از طرف هکر بازنویسی بشه. این یعنی تغییر پسورد روت و دسترسی مجدد هکر.

از اینجا به بعد دیگه برمی گرده به توانایی های هکر. ما هم می تونیم مثل هکر ها فکر کنیم و ببینیم با این توانایی چه کارهای دیگه ای می تونیم انجام بدیم.

منبع

Standard
امنیت

میزبان خود را چک کنید – ضعف امنیتی WHMCS

کمتر از ۲۰ روز پیش در این پست در مورد ضعف امنیتی WHMCS نوشتم. این نرم افزار که به عنوان سیستم پشتیبانی و مدیریت کلاینت ها در بسیاری از سرویس دهنده های میزبانی سایت استفاده می شه در نسخه جدید خود همچنان دارای نواقصی است.

PHP از نسخه ۵.۴.۰ استفاده از register_globals رو حذف کرد به این دلیل که تعریف متغیرها در سطح گلوبال باعث می شد متغیرها به وسیله کاربر تغییر کنند و این مورد ضمن اینکه یک سری کاربردهایی می تونست داشته باشه، به شدت می تونست خطرناک هم باشه.

خب حالا بیایم یه نگاهی به فایل dbfunctions.php این نرم افزار بندازیم، جایی که دستورهای ارسالی به دیتابیس رو هندل می کنه:

می بینید که نویسندگان برنامه از متغیرهای گلوبال استفاده کردند. حالا این کجا می تونه آسیب بزنه؟ برای مثال زمانی که کاربرها می خوان ticket ها رو ببینند. اونجا می شه با تذریق کدهای SQL در قالب یک متغیر GET و یا POST اطلاعات دیتابیس رو به دست آورد.

من هم اون مشکل قبلی رو در برخی هاستینگ های ایرانی چک کردم و هم این مشکل رو که متاسفانه نتایج اصلا خوب نبود. از ۱۰ تا هاستینگی که چک کردم ۸ تاشون تا ۲ روز پیش مشکل داشتند و ۲ تاشون رو هم تونستم با نام کاربری و پسورد ادمین به پنل مدیریت وارد بشم.

متاسفانه برخی سرویس دهنده ایرانی کوچکترین توجهی به مسایل امنیتی نکرده و حتی ساده ترین کار که نصب به موقع بسته های به روز رسانی است رو هم انجام نمی دن.

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

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

تاکید مجدد: لطفا از این ابزار برای آسیب رسوندن به دیگران استفاده نکنید.

لینک دسترسی به اسکریپت:

منبع و منبع

Standard