tamadon

سلام

خدا نیاره اون روزی رو که سایت مرجعی مثل http://drupal.org به اشتباه باعث شه که آدم توهم هک شدن پیدا کنه! (خودمونیش میشه: چرت و پرت بگه)

بله دیگه. ۲۳ مهر امسال (۱۵ اکتبر ۲۰۱۴ ) بود که خبر یک باگ امنیتی بزرگ در سیستم مدیریت محتوای دروپال پخش شد. این باگ در نسخه های ۷ تا ۷.۳۲ وجود داشت و به هکر اجازه می داد که از طریق روش «تزریق SQL» به سایت حمله کنه و بتونه بدون هیچ پیش نیازی، یک حساب با سطح دسترسی مدیریتی برای خودش ایجاد کنه. از اونجایی که وبلاگ من هم با دروپال نسخه ی ۷.۳۱ بود؛ فورا وبلاگم رو با اکسپلوییتی که به صورت عمومی پخش شده بود چک کردم و خوشبختانه پیام «NOT VULNERABE» رو دریافت کردم. البته بیشتر از این وقت خودم رو برای مطالعه و تحقیق پیرامون این باگ صرف نکردم، چون یک روز قبل از این آسیب پذیری،‌ یعنی ۲۲ مهر، گوگل، حمله پودل در SSL v3.0 رو معرفی کرده بود و تمام وقتم رو برای درک این حمله گذاشته بودم.

تقریبا دو هفته از این ماجرا گذشت تا از دست حمله پودل و باگ SandWorm راحت شدم و می تونستم به کارهایی که اولویت کمتری داشت (مثل همین روش در دروپال) برسم. اولین نکته ای که نظرم رو جلب کرد، این بود که در سایت دروپال گفته شده بود: «تمام نسخه های ۷ تا ۷.۳۲ آسیب پذیرند...» این جمله من رو نگران کرد. چون سایت من از همون روز اول، آسیب پذیر نبود!!! تا این که به صفحه سوالات رایج در خصوص این آسیب پذیری رسیدم و در قسمتی از اون گفته شده بود که:

متن اصلی:

My site has already been patched
We've seen many reports where people found that their site had already been patched even though nobody in charge of the site updated the site. This means that the site was compromised via a new entry or an updated entry in the menu_router table, which allowed the attacker to execute commands on the server to patch the site. At this point, the site has been compromised and should probably be taken offline while you assess what to do including forensic review; an audit of all files, code, users, permissions, roles, database content; complying with local regulations and standards including informing users and potentially law enforcement; and remediation or rebuilding the site.

ترجمه:

سایت من از قبل وصله شده است

ما گزارش های مختلفی داریم که مردم گفته اند سایت ما از قبل وصله شده و هیچ کس به جز ما هم به سایتمان دسترسی نداشته که بخواهد آن را وصله کند... این به این معناست که سایت شما در خطر است و هکر با وارد کردن یک سری ورودی در جدول menu_router سایت شما را وصله کرده است... باید به زودی آن را از دسترس خارج کنید و ...

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

از هکر/بات‌ی که وبلاگم رو هک کرده، درس های بزرگی گرفتم:
۱- حتی به CMSها هم نمیشه اعتماد کرد.
۲-آپدیت امنیتی رو حتی یک روز هم به تاخیر ننداز!

اما آیا مشکل به همین جا ختم می شد؟! مسلما نه. هکری که سایتی رو هک می کنه و صفحه رو دیفیس نمی کنه به احتمال زیاد در سایت شما یک «در پشتی» نصب می کنه تا به موقع از اون سوء استفاده کنه. این شد که:

اقدام اول: سریع از دیتابیس و فایل هام بک آپ گرفتم و وبلاگم رو از دسترس خارج کردم.

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

diff -ENwbur oldBackup/ newBackup/

تمام فایل هایی که تغییر کرده بود، رو با هسته ی دروپال و یا فایل های اصلی ماژول هایی که بعدا نصب کرده بودم چک کردم و وقتی که دیگه هیچ تغییری بین فایل ها نبود،‌ دوباره اکسپلوییت رو اجرا کردم و باز هم پیام «NOT VULNERABE» رو دریافت کردم. البته این دفعه باید گفت: متاسفانه! چون تمام فایل های من دست نخورده بود اما هنوز، وبلاگم وصله شده بود و طبق گفته ی دروپال این به این معنی بود که هنوز هکر در وبلاگ من وجود داره!

اقدام سوم: پیش خودم گفتم شاید فایل های سیستمی رو عوض کرده و کل اکانت رو پاک کردم و از نوع همه چیز رو ساختم. اما هنوز هم «NOT VULNERABE» رو دریافت می کردم

اقدام چهارم: حالا که مشکلی در فایل ها وجود نداشت، فقط دیتابیس می مونه. بنابراین دیتابیس رو با دیتابیس خامی که در زمان نصب دروپال وجود داره جایگزین کردم و خوشبختانه این دفعه پیام «!VULNERABLE» رو دریافت کردم! اما audit کردن دیتابیس یک CMS واقعا کار سختیه

اقدام پنجم: جداول اضافی که بعد از نصب دروپال ایجاد شده بود رو چک کردم و امیدوار بودم که با این کار مشکل حل شه. اول ماژول های مربوط به جدول ها رو غیر فعال کردم و بعد هم جدول ها رو drop کردم. با این که تعداد این جداول به ۱۶ تا می رسید اما مشکل از اون ها نبود!! (یعنی هکر در جدول های اصلی اینجکت کرده؟! این جوری هیچ وقت نمی تونم پیداش کنم... البته یک راهی وجود داشت....)

اقدام ششم: حالا باید جداول موجود را با جداول پیش فرض جایگزین کنم. که کار طاقت فرسایی است. (۲۷ جدول از ۷۹ جدول خالی بود. یعنی ۵۲ تا جدول باید چک شود)

اقدام هفتم: جدول ها رو با دیتابیس خام چک کردم و تعداد جداول empty را به عدد ۴۶ رساندم. یعنی ۳۳ جدول باقی می مونه... ۳۳ جدول با کلی ورودی... به نظرم درست کردن یه پازل ۶۰۰۰ تکه راحت تر از اینه که بخوام ورودی های دیتابیس رو دونه دونه چک کنم. همینجوری که داشتم به بلای عظمایی که سرم اومده فکر می کردم یادم افتاد که :« هی پسر! تو یه برنامه نویسی! کارها رو بسپار به یک اسکریپت ساده در پایتون!»

اقدام هشتم: درسته که پایتون کار مقایسه رو انجام داده بود اما کلی «ورودی» داشتم که بعدا به سایت اضافه شده بود و باید اون ها رو به صورت دستی چک می کردم... گذشت و گذشت و همین طور که به جلو پیش می رفتم نا امیدتر می شدم تا اینکه بالاخره به نتیجه رسیدم

نتیجه: باورم نمی شد! انگار که دنیا رو بهم داده باشند اما این باعث نمی شه که به دروپال فحش ندم!!! می پرسید چرا؟!! برای این که دروپال چرت گفته بود!

دریافت پیام «NOT VULNERABE» به این دلیل نبود که سایت من از قبل هک شده و هکر وبلاگم رو وصله کرده... به این دلیل بوده که هیچ وقت وبلاگ من آسیب پذیر نبوده. حتما الان می پرسید که: «مگه دروپال نگفته که تمام نسخه های بین ۷ تا ۷.۳۲ آسیب پذیره و وبلاگ تو هم از نسخه ۷.۳۱ استفاده می کنه؟ پس چطور ممکنه که تو همینجوری آسیب پذیر نباشی؟!!!!!» جواب اینه که: من شانس آورده بودم و قالبی که روی وبلاگم نصب کرده بودم باعث شده که وبلاگم آسیب پذیر نباشه. همه چیز به خاطر قالبی است که من از اون استفاده می کنم. وقتی هم که دیتابیس رو با دیتابیس خام عوض می کردم مقدار جدول system رو تغییر می داده و باعث میشده که وبلاگم با قالب پیش فرض دروپال بالا بیاد و سایتم رو «!VULNERABLE» کنه!!! همین و بس!

در هر صورت هر چه زودتر وبلاگت تون رو به نسخه ی ۷.۳۲ ارتقاء بدید و اگر نمی دونید این کار چه جوریه از لینک زیر استفاده کنید:

آموزش آپدیت هسته دروپال

من یک ریپورت هم به دروپال دادم که امیدوارم بهش رسیدگی کنند و صفحه ی سوالات رایج رو به روز کنند!

هر چند که این کار بیش از حد از من وقت گرفت اما باعث شد که یک بار تمام سیستم وبلاگم رو برای پیدا کردن بک دور چک کنم و این کار لذت خاص خودش رو داشت...

درسی که می گیریم اینه که لزوما سایت ها بزرگ همیشه مطالب شون درست نیست!

//مرسی از این که این مطلب طولانی رو خوندید ;)