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

ایمیل اسپم

همونطور که در تصویر می بینید ارسال کننده service@informaticsfairview.com گفته شده و از طریق سرور server2.synermaxx.net. در قدم اول گوگل همچین ایمیل هایی رو با نگاه منفی بررسی می کنه چرا که ایمیل از سرور a ارسال شده ولی توی Header داره ادعا می کنه که از آدرسی در سرور b اومده.

اسپمر می تونست اون اعلام “via blah blah” رو که در تصویر می بینید با روش هایی حل بکنه ولی گویا طرف خیلی کاربلد نبوده.

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

قیافه لینکی که کاربر بهش منتقل می شه به نظر عادی میاد. از کلمات voice و message استفاده شده و یه سری متغیر ارسالی. ولی چرا این لینک در سایت ferlosa.com قرارداره و نه سایتی مرتبط با واتزاپ؟

قبل از اینکه کد رو باز کنیم، می تونیم با استفاده از سرویس safe Browsing این سایت رو چک کنیم و ببینیم بدافزار یا تروجان روی خودش داره یا نه.

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

حدس بعدی که می زنم اینه که سایت هک شده و یه اسکریپت PHP روش قرار گرفته برای منتقل کردن قربانی ها به سایت مخرب. با یه نگاه گذرا متوجه شدم که سایت ضعف امنیتی داره و با تزریق SQL می شه به دیتابیس دست پیدا کرد. با ادمین سایت تماس گرفتم تا نسخه ای از voice.php و یا لاگ سرور رو برای من بفرسته  که بتونم مسیر رو دنبال کنم. با توجه به اینکه پاسخی دریافت نکردم مجبور شدم خودم سایت رو هک کنم تا بتونم با ورود به محیط مدیریت سایت به اطلاعاتی که می خوام برسم.

این اطلاعات جدول کاربرهاست که از طریق SQL Injection به دست آوردم (البته به جای پسورد ادمین ستاره استفاده کردم که لو نره) :

و این هم صفحه ورود به پنل مدیریت

ولی اینجور که از شواهد برمیاد پنل مدیریت از کار افتاده و حدس می زنم کار هکر باشه. راهش اینه که ادمین از طریق کنترل پنل میزبان بره و مشکلات رو برطرف کنه.

درپایان:

این پست یه کار دم دستی بود و تمام جوانب رو پوشش نداد. در صورتیکه به سرور هک شده دسترسی داشته باشم می تونم اطلاعات بیشتری رو راجع به هکر که به دست بیارم.

ضعف برنامه نویسی در ارتباط با دیتابس حتما به این معنی نیست که هکر بتونه در خروجی صفحه نتیجه تزریق رو ببینه و در نتیجه با نشون ندادن خروجی ها از هک جلوگیری کرد. این اشتباهیه که در برخی برنامه ها دیدم. مثلا برنامه نویس گفته هر وقت مشکلی در تماس با دیتابیس بود صفحه رو نشون نده یا برو صفحه اول سایت رو نشون بده.
تزریق SQL می تونه با یه “گزاره منطقی” باشه و یا یک دستور که در لود شدن صفحه تاخیر ایجاد کنه. بهترین روش جلوگیری از SQL Injection بررسی ورودی ها و نیز استفاده از کلاس های PHP (و یا سایر زبان های برنامه نویسی) است که کار ارتباط با پایگاه داده رو به صورت تخصصی انجام می دن.

زمانی که ادوب اعلام کرد پسوردهای رمز شده لو رفته اند سوال پیش اومد که این پسوردها رمز شده بودند یا هش؟

اصطلاح رمز شده یا Encrypted زمانی استفاده می شه که امکان Decrypt هم باشه، ینی ادوب بتونه پسورد شما رو به صورت واضح بخونه در حالیکه روش امنی که باید برای نگهداری پسوردها استفاده بشه هش Hash کردنه که یک طرفه است و از نتیجه هش نمی شه به پسورد اصلی رسید. برای بالا بردن امنیت پسوردهای ذخیره شذه از salt هم استفاده می شه که یک رشته از کراکترهای تصادفیه که پیش از هش شدن به پسورد اضافه می شه. استفاده از salt باعث می شه که اگر دو کاربر از پسورد مشابهی استفاده کرده باشند، نتیجه هش شده برای اونها متفاوت می شه و درنتیجه در صورت دسترسی هکر به دیتابیس، پیداکردن پسورد مشکلتر می شه.

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

و در تصویر زیر می بینید که اطلاعات هر ستون مربوط به چه فیلدی است.

این فیلدها برای بررسی ما غیر ضروری بود و حذف شدند: user ID, email addresses, username

فقط ستون های پسورد و یادآوری باقی موندن. همچنین پسوردها نیز با روش base64 رمزگشایی شدن و به نسخه هگزادسیمال تبدیل شدند. با این تبدیل طول پسوردها واضح تر شد:

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

سوال بعدی اینه که حالا که پسوردها هش نشدن پس از چه روش رمزگذاری (Encryption) استفاده شده؟ روش هایی مثل RC4 یا Salsa-20 رو کنار بذاریم چون نتیجه رمزگذاری در این دو روش با طول پسوردها برابر می شه. در حالیکه در تصویر بالا می بینیم که پراکندگی طول پسوردهای رمز شده مخالف اینه.

Stream cipher که به طور معمول در پروتوکول های شبکه استفاده می شه به ما اجازه می ده که هر بار یک بایت از اطلاعات رو رمز کنیم بدون اینکه مجبور باشیم ورودی را به تعداد مشخصی بایت بلوک بندی کنیم.

با توجه به اینکه رمزها ضریبی از ۸ است مشخصا دنبال روش رمز گذاری می ریم که بلوک های ۸ بایتی (۶۴ بیت) رو رمز گذاری می کنه. در نتیجه به نظر میاد که با یک روش رمزگذاری DES (Data Encryption Standard) و یا نسخه مدرن ترش  ۳DES طرفیم. (این احتمالات رو کنار گذاشتیم: سایر روش های ۶۴ بیتی که یه زمانی استفاده می شدند و یا شیوه جدیدی ساخته خود ادوب)

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

سوال بعدی اینه که از چه مدی برای رمزگذاری (encryption mode) استفاده شده.

ابتدایی ترین مدی که برای رمزگذاری استفاده می شه “مد رمز گذاری بلوکی خام”ه که با اسم Electronic Code Book (ECB) شناخته می شه. در این حالت الگوهای متن اولیه در متن رمزگذاری شده قابل شناساییه. در مدهای دیگه این ضعف وجود نداره و الگوها رو غیر قابل شناسایی می کنند.

یکی از دلایلی که از ECB استفاده نمی شه اینه که نتیجه رمز گذاری یک پسورد ثابت با یک کلید ثابت و با این مد، نتیجه یکسانی رو به همراه داره. بذارید یه نمونه تصویری از این مشکل رو ببینیم.

فرض کنیم تصویر کلمه sophos رو با ترکیب رنگ RGB داشته باشیم (که هر پیکسل ۳ بایت داره) و اون رو به بلوک های ۸ بایتی تقسیم کنیم و با روش DES و مد ECB اون رو رمزگذاری کنیم. حال با فایل به دست اومده به عنوان یک تصویر RGB برخورد کنیم و اون رو نگاه کنیم، نتیجه زیر حاصل می شه

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

اگر ادوب از این روش استفاده می کرد می بایست در کوتاه ترین پسورد شاهد ۱۶ بایت می بودیم. ۸ بایت برای nonce و ۸ بایت برای پسورد رمزگذاری شده. با توجه به اینکه ما رمزهای ۸ بایتی رو در جدول می بینیم پس از این شیوه استفاده نشده.

حتی اگر فرض کنیم از عدد دیگه ای مثل userid به عنوان nonce استفاده شده باشه، نباید شاهد رمزهای تکراری در دیتابیس باشیم چرا که احتمال تکرار یک رمز با بلوک های ۶۴ بیتی ۱ در ۲ به توان ۶۴ است (حدود ۲۰ میلیون میلیون میلیون). ما با ۱ میلیون داده طرفیم و این ینی هیچ رمز تکراری در این یک میلیون نباید باشه.

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

بازیابی پسورد

بذارید یه سوال دیگه بپرسیم. پسوردی که رمزگذاری شده اش ۱۱۰edf2294fb8bf4 است و در مجموعه انتخابی ۱.۶ درصد پسوردها رو شامل می شه، چیه؟

بهتره نگاهی به اتفاقات مشابه و آمار هک های دیگه بندازیم و از اون برای تحلیل این داده ها استفاده بکنیم. ۳ سال پیش که Gawker Media هک شد، لیست بیشترین پسوردهای استفاده شده مطابق تصویر زیر بود.

به غیر از کلمه lifehack که یکی از برندهای اون سایت بود، بقیه پسوردهای استفاده شده از کلماتی انتخاب شده که راحت به یاد می مونه و تایپ می شه. با دیدی که از این لیست داریم و نگاهی به ستون یادآوری پسورد می تونیم ۵ پسورد پرکاربرد در داده های لو رفته ادوب رو به دست بیاریم:

دقت کنید که پسوردهای ۸ کاراکتری ۱۲۳۴۵۶۷۸ و password در دو بلوک ذخیره شده اند که نشون میده متن رمز شده حداقل ۹ کاراکتر داشته. به احتمال بسیار زیاد روند این شکلیه که پسورد به اضافه یک بایت صفر(ASCII NUL)  می شه که نشون دهنده انتهای رشته در زبان C است و با اضافه شدن ۷ بایت NUL، متن تبدیل به ضریبی از بلوک های ۸ بایتی می شه. بنابراین می تونیم به این نتیجه برسیم که e2a311ba09ab4707 در بلوک دوم، نشون دهنده ۸ بایت صفرِ رمز شده است.

اگر پیش فرض های ما و نتایجی که بهش رسیدیم درست باشه و با توجه به اینکه بلوک e2a311ba09ab4707 در ۲۷ درصد از پسوردهای رمز شده تکرار شده، می تونیم بگیم که ۲۷ درصد پسوردهای کاربران ادوب دقیقا ۸ کاراکتر داره.

می بینید که با کمی تلاش تونستیم ۵ پسورد پرکاربرد ادوب رو به دست بیاریم که پسورد حدود ۲.۷۵ درصد کاربرها بوده و همچنین تونستیم بفهمیم که ۱/۳ پسوردهای کاربران دقیقا ۸ کاراکتر داره. می تونیم تصور کنیم که چه مقدار دیگه اطلاعات می شه از این “بزرگترین جدول کلمات متقاطع تاریخ” به دست آورد.

منبع