حمله فردی در مرورگر

احتمالا در مورد حمله “فردی در میانه” یا MiTM شنیدید (۱). در این حمله، فردی خودش رو در مسیر رد و بدل اطلاعات قربانی قرار می‌ده و می‌تونه به اطلاعات مهم دست پیدا کنه. این حمله روش‌های مختلفی برای پیشگیری داره که اولین و راحت ترینش استفاده از رمزگذاریه. یعنی هرجا که می‌شه، باید نسخه https سایت‌ها رو باز کرد که برای اینکار هم افزونه HTTPS everywhere گزینه خیلی خوبیه.

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

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

فردی در مرورگر

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

روش این حمله رو اولین بار آگوستو پائس د باروس در یک ارائه درباره روند تغییرات درهای‌پشتی در سال ۲۰۰۵ نشون داد و فیلیپ گورینگ، سال ۲۰۰۷ از اصطلاح “مردی در مرورگر” که من اینجا به فردی در مرورگر تغییرش دادم، استفاده کرد.

بدافزارهای MiTB از امکاناتی مثل Helper Objects مرورگر (در اینترنت اکسپلورر)، افزونه‌ها، پلاگین‌ها، کدهای جاوا اسکریپت (مثل user scripts) و امثال اونها سواستفاده می‌کنند. در ادامه می‌تونید لیستی از بدافزارهایی که از حمله فردی در مرورگر استفاده می‌کنند و مرورگرها و سیستم‌عامل‌های هدفشون رو ببینید.

چگونه آلوده می‌شویم

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

بدافزار Carberp با هدف قراردادن بانک‌های معروف آمریکا و کانادا مثل WellsFargo، Citi، JP Morgan و غیره، در بازار سیاه قیمتی حدود ۴۰ هزار دلار داشت که از سال ۲۰۱۳ کدش با قیمت ۵ هزار دلار در دسترس قرار گرفت. این بدافزار با استفاده از ضعف‌های امنیتی سیستم‌عامل ویندوز، کامپیوتر قربانی رو آلوده می‌کنه و می‌تونه مدت‌ها بدون تشخیص داده شدن به وسیله آنتی ویروس به عملکرد خودش ادامه بده.

آمارها نشون می‌ده که بخش زیادی از کاربرها (حدود ۷۳ درصد) قابلیت تشخیص بین پیام‌های خطای POP UP واقعی و تقلبی رو ندارند و نمی‌تونن متوجه آلوده بودن احتمالی یک فایل بشن.

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

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

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

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

پیشگیری و تشخیص

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

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

استفاده از افزونه‌هایی مثل HTTPS Everywhere باعث می‌شه که هرجایی که امکانش باشه از رمزگذاری استفاده کنید، هرچند باید به خاطر داشته باشیم که این مساله بعد از آلوده شدن به بدافزار کمک چندانی به ما نمی‌کنه.

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

در صورتیکه ترجیحتون استفاده از ویندوزه، برای کارهای مهم از نرم‌افزارهای پورتابل استفاده کنید. پیدا کردن محل قرارگیری مرورگر پورتابل و آلوده کردنش، کار بدافزار رو سخت‌تر می‌کنه. در صورت استفاده از فایرفاکس پورتابل، می‌تونید با رفتن به بخش تنظیمات شبکه، گزینه not use a proxy رو انتخاب کنید و پراکسی بدافزارهای احتمالی روی ویندوز رو دور بزنید.

اگر متوجه مساله مشکوکی در حساب‌های کاربری و بانکیتون شدید، با استفاده از تلفن با پشتیبانی اون شرکت تماس گرفته و مشکل رو مطرح کنید و یا یک کامپیوتر دیگه وارد حسابتون بشید و آحرین تغییرات رو چک کنید. در صورت آلوده شدن به بدافزار، کار زیادی ازتون بر نمیاد و در اولین فرصت باید با کارشناسان امنیتی تماس بگیرید برای پاک سازی سیستم و همچنین به بانکتون (و ادمین سایت و غیره) اطلاع بدید تا جلوی آسیب بیشتر گرفته بشه.

با توجه به محدودیت کاربر در تشخیص آلودگی، نقش سریس دهنده پر رنگتر می‌شه. برای مثال بانک‌ها باید با روش‌های تحلیل عملکرد کاربر و یا تحلیل انتقال پول‌ها، پترن‌های مشکوک رو تشخیص بدهند. آمارها نشون می‌ده که در سال ۲۰۰۹، میزان موفقیت آنتی‌ویروس‌ها در برابر بدافزار زئوس فقط ۲۳ درصد بوده و سال‌های بعد نیز موفقیت چشمگیری مشاهده نشده.

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

جدول زیر شون دهنده کارهاییه که می‌تونیم انجام بدیم و میزان اثری که برای پیشگیری از حمله فردی در مرورگر می‌تونن داشته باشن.

پانوشت:

۱- معمولا با “مردی در میانه” می‌شناسنش اما من “فرد” رو ترجیح می‌دم

امنیت

گاف بزرگ اپل چگونه اتفاق افتاد و چه باید کرد؟

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

اپل در آپدیتی که برای iOS ارائه کرده به صورت خلاصه هم مشکل رو گفته و هم خطر احتمالی رو.

اپل به وضوح در مورد a privileged network position و the authenticity of the connection توضیح نداده اما می شه فهمید که خطر چیه: MiTM

حمله MiTM (فردی در میانه) علیه سایت های رمزگذاری نشده، ساده است. مثلا اگر ما یه اکسس پوینت داشته باشیم، می تونیم استفاده کننده ها رو فریب بدیم و وقتی خواستن سایت http://example.com رو ببینن، اونها رو به یک سایت تقلبی منتقل کنیم. می تونیم اطلاعات سایت اصلی رو بگیریم و تغییراتی توش بیدم و حتی توش بدافزار تزریق کنیم و برای کاربر بفرستیم و اون هم متوجه نشه.

اما اگر کاربر بخواد یه سایت رمزگذاری شده رو ببینه، مثلا https://example.com، اونوقت انجام حمله MiTM به سادگی قبل نیست چرا که سایت تقلبی نمی تونه سرتیفیکیتی رو ارائه کنه که باید از طرف سایت اصلی ارائه بشه. چرا نمی تونه اون سرتیفیکیت رو بده؟ چون کلید خصوصی معتبر اون سایت رو نداره. و اگر کسی سعی کنه با سرتیفیکیت تقلبی و یا مشکل دار، کاربر رو فریب بده اونوقت مرورگر بهش یه پیام اخطار می ده.

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

خب بریم سر اصل قضیه. مشکل برنامه نویسی که منجر به این اشتباه بزرگ شد چی بوده؟

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

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/SecureTransport.h

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslHandshake.c

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/SecureTransport.h

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslHandshake.c

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

و در صورتیکه بخواید مسیر فراخوانی توابع رو تا رسیدن به جایی که اشتباه رخ می ده دنبال کنید، می تونید این توابع رو چک کنید:

SSLProcessHandshakeRecord()   
  -> SSLProcessHandshakeMessage()

1 2	SSLProcessHandshakeRecord() -> SSLProcessHandshakeMessage()

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

    -> SSLProcessClientHello()
    -> SSLProcessServerHello()
    -> SSLProcessCertificate()
    -> SSLProcessServerKeyExchange()

-> SSLProcessClientHello()

-> SSLProcessServerHello()

-> SSLProcessCertificate()

-> SSLProcessServerKeyExchange()

تابع SSLProcessServerKeyExchange برای اتصال های TLS مشخصی فراخوانی می شه، مخصوصا وقتی forward secrecy استفاده می شه. forward secrecy روشیه که در اون به جای استفاده از جفت کلید همیشگی سایت، از جفت کلیدهای موقت استفاده می شه که بعد از بسته شدن صفحه، از بین می رن. نتیجه استفاده از forward secrecy اینه که بعد از بسته شدن صفحه (در اصل بعد از بسته شدن session) اماکن رمزگشایی از ترافیک ارسال وجود نخواهد داشت، حتی برای خود سایت و کاربر.

کد به این شکله:

SSLProcessServerKeyExchange() 
  -> SSLDecodeSignedServerKeyExchange()
     -> SSLDecodeXXKeyParams()
     IF TLS 1.2 -> SSLVerifySignedServerKeyExchangeTls12()
     OTHERWISE  -> SSLVerifySignedServerKeyExchange()

SSLProcessServerKeyExchange()

-> SSLDecodeSignedServerKeyExchange()

-> SSLDecodeXXKeyParams()

IF TLS 1.2 -> SSLVerifySignedServerKeyExchangeTls12()

OTHERWISE -> SSLVerifySignedServerKeyExchange()

و نهایتا تابع SSLVerifySignedServerKeyExchange در فایل sslKeyExchange.c که لینکش رو بالاتر گذاشتم، به شکل زیره:

. . .
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
    goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;  /* MISTAKE! THIS LINE SHOULD NOT BE HERE */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

err = sslRawVerify(...);
. . .

. . .

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;

hashOut.length = SSL_SHA1_DIGEST_LEN;

if ((err = SSLFreeBuffer(&hashCtx)) != 0)

goto fail;

if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)

goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)

goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)

goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

goto fail;

goto fail; /* MISTAKE! THIS LINE SHOULD NOT BE HERE */

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)

goto fail;

err = sslRawVerify(...);

. . .

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

[1] if (certificate check is not valid)
[2]   goto fail;
[3]   goto fail;
[4] if (next certificate check is not valid)
[5]   goto fail;

[1] if (certificate check is not valid)

[2] goto fail;

[3] goto fail;

[4] if (next certificate check is not valid)

[5] goto fail;

برنامه نویس از {} استفاده نکرده که اگر با دستورات شرطی آشنا باشید می دونید که معنی کدها بالا اینه:

[1] if (certificate check is not valid) {
[2]   goto fail;
[3] }
[3]   goto fail;
[4] if (next certificate check is not valid) {
[5]   goto fail;
[6] }

[1] if (certificate check is not valid) {

[2] goto fail;

[3] }

[3] goto fail;

[4] if (next certificate check is not valid) {

[5] goto fail;

[6] }

در واقع هیچ وقت به دستور شرطی آخر و بعدش دستور sslRawVerify نمی رسیم و قبل از اون دستور goto fail اجرا می شه. دستور sslRawVerify خیلی مهمه و درواقع با اجرای اون و اگر خطایی وجود نداشته باشه، متغیر err برابر صفر می شه و تابع SSLVerifySignedServerKeyExchange اعلام می کنه که همه چیز درسته.

در دستورهای شرطی، اگر خطایی وجود داشته باشه، متغیر err برابر مقدار خطا می شه و بعد دستور goto fail اجرا می شه. اما در اون خطی که goto fail به اشتباه تکرار شده، بدون اینکه مقدار متغییر err برابر با کد خطا بشه، دستور goto fail انجام می شه و بقیه بررسی هم انجام نمی شه. یعنی اگر خطایی وجود داشته باشه که در بررسی های بعدی قرار بوده پیدا بشه، هیچ وقت پیدا نمی شه.

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

هکر چطوری می تونه از این ضعف امنیتی استفاده کنه؟

کاربر رو فریب بده که از یک سایت HTTPS تقلبی بازدید کنه.
مرورگر یا نرم افزار رو مجبور کنه که از forward secrecy استفاده کنه چرا که سروره که مشخص می کنه چه الگوریتم رمزنگاری استفاده بشه.
مرورگر یا نرم افزار رو مجبور کنه که از TLS نسخه ۱.۱ استفاده کنه چرا ه سروره که مشخص می کنه چه نسخه ای از TLS رو می پذیره.
سرتفیکیت TLS رو ارائه بده که به نظر واقعی میاد اما با کلید خصوصی اشتباه تولید شده باشه.

این کارها امکان پذیره و در این پست می تونید نمونه اجرا شده اش رو ببینید.

چکار می شه کرد؟

اپل برای iOS نسخه به روز رسانی داده، پس آپدیتش کنید.

متاسفانه برای OS X تا کنون نسخه به روز رسانی نیومده و اپل فقط گفته “به زودی” مشکل رو برطرف می کنه. پس تا اون موقع به هیچ عنوان از شبکه های غیر مطمئن (مثل وایفای عمومی) استفاده نکنید.

اگر می تونید از VPN های امن استفاده کنید.

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

به روز رسانی: نسخه جدید OS X ارائه شده. می تونید آپدیت کنید

منبع / منبع / منبع

Scriptics

Tag Archives: MiTM

حمله فردی در مرورگر

گاف بزرگ اپل چگونه اتفاق افتاد و چه باید کرد؟