این پست در مورد خطرات حمله man-in-the-middle به مرورگرهاست، مخصوصا زمانی که داریم از شبکه های عمومی استفاده می کنیم. پیش فرض های این پست:

• بیرون از خانه ایم
• نوتبوک یا گوشی هوشمندمون همراهمونه
• اینترنت نداریم
• یه وایفای عمومی وجود داره که می تونیم استفاده کنیم
• می خوایم اخبار رو چک کنیم
• احتمالا ایمیلمون رو هم چک می کنیم (مسلما با اتصال  SSL)
• مرورگر و افزونه هاش به روزه و کسی نمی تونه با استفاده از ضعف های امنیتی جدید ما رو هک کنه
• جاوا اسکریپت مرورگرمون فعاله (معمولا اینجوریه)

خب بیایم ببینیم چه اتفاقایی می تونه برامون بیافته.

Sniffing

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

گرفتن شل جاوا اسکریپت

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

می بینید که کدی با اسم socket.io به مرورگر ما تزریق شده. نمونه ای از اون کد خرابکار می تونه تصویر زیر باشه.

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

خوندن کوکی ها

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

• کوکی می تونه فقط برای یک دامنه خاص معتبر باشه. یعنی کوکی های گوگل در سایت یاهو بدون استفاده است.
• آدرس سایت باید درست باشه. مثلا یک کوکی می تونه در  بخشی از سایت که آدرس /protected_stuff/ داره ممنوع باشه.
• سرور می تونه کوکی رو نشان گذاری کنه یعنی در زمان ذخیره کردن بگه این کوکی Secure است و بنابراین مرورگر این اطلاعات رو فقط از طریق اتصال امن (مثلا TLS)  منتقل می کنه و هکر به اونها دسترسی نداره. هرچند اینکه یک سایت از کانکشن امن استفاده می کنه معنیش این نیست که کوکی ها رو Secure نشان گذاری کرده.

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

اینجوری می شه کوکی غیرامن هر سایتی رو دزدید. نمونه ای از سایت هایی که با این روش می شه کوکیشون و اطلاعات مرتبط رو به دست آورد:

• گوگل: ایمیل، اسم و تصویر
• ویکی پدیا: اگر از اتصال امن استفاده بشه هیچ اطلاعاتی درز نمی کنه، در خیر اینصورت دسترسی کامل به اکانت
• استک اورفلو: دسترسی کامل به اکانت
• ولفرام آلفا: آی‌پی استفاده شده جهت لاگین، دسترسی کامل به اکانت از جمله تاریخچه جستجوها

دزدی پسورد

غیر از اینکه هکر می تونه اطلاعات منتقل شده سایت هایی که بازدید می کنید رو بخونه، می تونه از شیوه های پیچیده تری برای به دست آوردن پسوردهای ذخیره شده در مرورگر هم استفاده بکنه. یک سناریوی حمله می تونه این باشه که از همون شل جاوا اسکریپت استفاده کنه و با لود کردن یک فریم در صفحه و باز کردن صفحه لاگین سایتی که از HTTPS استفاده نمی کنه، مرورگر رو گول بزنه به پر کردن نام کاربری و پسورد و سپس با یک کد جاوا اسکریپت دیگه، اطلاعات تکمیل شده رو بدزده. برخی سایت ها با ست کردن X-Frame-Options در هدر از لود شدن صفحه شون در فریم جلوگیری می کنند که البته هکر می تونه اون هدر رو هم تغییر بده و دسترسی خودش رو باز کنه.

سرویس های ایمیل مثل web.de و GMX از فرم لاگین HTTP استفاده می کنند که اطلاعات رو به یک آدرس HTTPS ارسال می کنه. این راه در مقابل sniff امنه اما در برابر این روش حمله، آسیب پذیره. سایت wordpress.com هم این مشکل رو داره.
نمونه دیگه می تونه پسورد روتر باشه. هکر با این حمله می تونه پسورد ادمین روتر ما رو به دست بیاره.

مسموم کردن کش (Cache Poisoning)

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

مسموم کردن دانلود (Download poisoning)

فرض کنیم کاربر ویندوزیم و چندوقت یه بار با استفاده از مرورگر نرم افزاری رو دانلود و نصب می کنیم، برای مثال از sourceforge. اگر نگاهی به سورس صفحه دانلود این سایت بندازیم می بینیم که همیشه از این کد استفاده می کنه:

اگر زمان استفاده از wifi مخرب، هکر این کد رو مسموم کنه، تمامی دانلود های بعدی ما از این سایت به سرور هکر منتقل شده و فایل هایی خارج از سرورهای قانوی sourceforge دانلود می کنیم. معمولا این تغییر سرور قابل شناسایی نیست. سایت ها نیز از پروتوکول HTTP برای صفحه دانلود استفاده می کنند چرا که بیشتر از اینکه اطلاعات دانلود شده سری باشند، یکپارچه بودن فایل دانلود شده مهمه.

مسموم کردن دستور (Commandline snippet poisoning)

احتمالا با دیدن بخش بالا به خودمون گفتیم: “هه! من که کاربر لینوکسم و نرم افزار دانلود نمی کنم. از مخازن استفاده می کنم”. زیاد خوشحال نباشیم. بذارید یه سناریوی حمله دیگه رو ببینیم. احتمالا بارها پیش اومده که مشکلی توی سیستممون داشتیم و مشکل رو گوگل کردیم و یا توی سایت هایی مثل “انجمن اوبونتو” دنبال راه حل بودیم. به یک روش برخوردیم که با اجرای یک تیکه کد می تونیم مشکل رو حل کنیم. بعد هم با کپی کردن کدی که به نظر سالم بوده، اون رو در ترمینال اجرا کردیم. کافیه هکر یک کد جاوا تزریق بکنه به صفحه هایی که احتمالا بازدید خواهیم کرد و تیکه های کد (snippet) رو مسموم بکنه. این لینک شامل نمونه ای عملی از تکه کدیه که ظاهرش یه چیزه و نتیجه کپی کردن، چیز دیگه است.

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

راه حل

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

منبع

دیروز دیدم که گوگل یه ایمیل دریافتی رو به عنوان اسپم شناخته. واسم جالب شد چک کنم ببینم چیه و چکار می خواد بکنه. ایمیل ظاهرا از طرف اپلیکیشن 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 در ۲۷ درصد از پسوردهای رمز شده تکرار شده، می تونیم بگیم که ۲۷ درصد پسوردهای کاربران ادوب دقیقا ۸ کاراکتر داره.

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

منبع