امنیت

ضعف پیاده‌سازی اس‌اس‌ال : وقتی اپلیکیشن‌های اندروید اطلاعات می‌فرستند، کی فالگوش می‌ایسته؟

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

DSC_3398

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

اپلیکیشن‌های اندروید برای انام برخی از کارها با سرور اطلاعات رد و بدل می‌کنند که اگر از پروتوکل HTTP استفاده کنند، اطلاعات قابل خوندنه و اگر از پروتوکل HTTPS استفاده بشه، این فالگوش ایستادن سخت می‌شه. مشخصات امنیتی HTTPS مبتنی بر SSL نسخه جدیدش TLS است.

پلتفرم اندروید کتابخانه ها و متودهایی دارد برای ارتباط با سروربا استفاده از این پروتوکل های شبکه امن که زیرساخت کلید عمومی (PKI) را می‌سازند. در حالیکه پروتکل SSL/TLS برای افزایش امنیت طراحی شده، استفاده اشتباه از کتابخونه‌های اندروید می‌تونه اپلیکیشن‌ها رو دربرابر حمله MiTM آسیب‌پذیر کنه. در MiTM، حمله کننده می‌تونه اطلاعات رد و بدل شده اپلیکیشن و سرور رو بخونه و ممکنه:

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

تشخیص ضعف‌های امنیتی در اندروید

در ادامه زیر مجموعه‌های ضعف کشف شده SSL/TLS خواهد اومد.

  • استفاده از کنترل کننده‌های اعتماد که “زنجیره سرتیفیکیت” سرورها را چک نکرده و اماکن موفقیت حمله MiTM را ایجاد می‌کنند. بررسی گواهینامه‌ها برای اطمینان از صدور یا تایید آنها توسط Certifying Authority (CA) های شناخته شده و قابل اطمینان، بخشی جدایی ناپذیر در ارتباطات کارب و سروری است که مبتنی بر گواهینامه است.
  • استفاده از “تایید کننده hostname” اپلیکیشین به جای تایید کننده پلتفرم اندروید و عدم بررسی hostname سرور. استفاده از کنترل کننده های اعتماد (کنترل زنجیره گواهینامه) در این حالت کافی نیست چرا که حمله کننده می‌تونه یک گواهینامه داشته باشه که توسط certifying authority مطمئن صادر شده باشه و زنجیره قابل قبولی داشته باشه اما برای یک hostname دیگه گرفته باشه. برای جلوگیری از این خطر باید hostname گفته شده در گواهینامه با سروری که اپلیکیشن قراره باهاش ارتباط برقرار کنه مقایسه بشه.
  • چشم‌پوشی از خطاهای SSL توسط اپلیکیشن در زمان رندر کردن صفحه‌های سرور با WebKit. زمان ارتباط با سروری که از پروتکل SSL/TLS استفاده می‌کنه باید تمامی خطاها را چک کرد وگرنه نرم‌افزار رو در معرض حمله MiTM قرار می‌دیم که نهایتا می‌تونه منجر به حمله‌ای بشه که با تزریق کد جاوا اسکریت مخرب، کنترل اپلیکیشن به دست حمله کننده بیافته.

 

ضعف SSL در نرم‌افزارهای پر دانلود گوگل پلی

تیم امنیتی FireEye در این بررسی، ۱۰۰۰ نرم‌افزار رایگان گوگل پلی که بیشترین دانلود رو داشتند، چک کرده. در مجموع ۶۷۴ اپلیکیشن (۶۸%) حداقل یکی از ۳ ضعف امنیتی گفته شده را داشتند. در تصویر زیر می توانید نتایج مرتبط با هر ضعف امنتی را ببینید:

androidssl1

  • از مجموع ۶۱۴ اپلیکیشن که از SSL/TLS برای ارتباط با سرور استفاده می‌کردند، ۴۴۸ اپلیکیشن  (۷۳%) گواهینامه را چک نمی‌کردند.
  • ۵۰ اپلیکیشن (۸%) از تایید کننده hostname خودشون استفاده می کردند که صحت hostname رو چک نمی‌کرد.
  • از ۲۸۵ اپلیکیشنی که از Webkit استفاده می‌کردند، ۲۱۹ اپلیکیشن (۷۷%) از خطاهای SSL چشم‌پوشی می‌کردند.

این تیم همچنین به صورت خام ۱۰هزار نرم‌افزار گوگل پلی رو چک کردند. این مجموعه به صورت رندوم از نرم‌افزارهای رایگان انتخاب شدند. حدود ۴۰% اپلیکیشن‌ها از کنرل کننده خودشون استفاده می‌کردند که گواهینامه سرور را چک نمی@کرد و اطلاعات کاربر را در معرض دزدی قرار می‌دادند. ۷۵۰ اپلیکیشن (۷%) نیز hostname را چک نمی‌‌کردند که بنابراین قادر نبودند تغییر مقصد درخواست‌ها به سرور تحت کنترل حمله کننده را متوجه بشوند. ۱۳۰۰ نرم‌افزار نیز زمان استفاده از Webkit خطاهای SSL را چک نمی‌کردند.

نمونه اول: کتابخانه Flurry

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

شماره یک کتابخانه‌های تبلیغاتی گوگل پلی در اختیار Flurry است و از مجموع ۷۰ هزار نرم‌افزار بالای ۵۰ هزار دانلود، ۹,۷۰۲ تاشون از این کتابخانه استفاده می کنن. این اپلیکیشن‌ها در مجموع ۸.۷ میلیارد بار دانلود شدن. تا پیش از نسخه ۳.۴، این کتابخانه از HTTPS برای آپلود اطلاعات مکانی و IMEI کاربر استفاده می‌کرد در حالیکه کنرل کننده اعتمادش مشکل داشت.

در آژمایشی که انجام شد، اطلاعات منتقل شده به سرور https://data.flurry.com خونده شد و اطلاعات مکانی دستگاه شبیه سازی شده با آنچه که از اطلاعات منتقل شده این کتابخانه به دست اومد، منطبق بود. در تصویر زیر بخشی از اطلاعات خونده شده رو مشاهده می‌کنید.

androidssl2

 

نمونه دوم: اپلیکیشن عکس‌برداری

Camera360 Ultimate نرم‌افزاری است که بیش از ۲۵۰ میلیون بار دانلود شده و اپلیکیشن عکاسی شماره ۱ در بسیاری از کشورهاست. این اپلیکیشن به همراه اپلیکیشن‌های جانبی و سرویس ابری، به کاربران امکان ادیت، نگهداری و انتشار عکس‌هاشون رو می‌ده.

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

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

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

این ضعف‌ها در نسخه منتشر شده در ماه گذشته، برطرف شد.

 

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

پ‌ن ۲: بعضی اصطلاحات رو سعی کردم فارسی بنویسم که مطمئن نیستم بهترین جایگزین باشن و یااصلا کار درستی باشه و ممکنه مفهوم رو درست منقل نکرده باشن. ممنون می‌شم نظرتون رو بهم بگید.

منبع

Standard
امنیت

ضعف امنیتی مهم در وردپرس

حدود یک هفته پیش نسخه جدید وردپرس برای جلوگیری از DDoS ارائه شد. مشکل در xmlrpc.php بود که API endpoint وردپرس محسوب می‌شه. برای اینکه بدونید xmlrpc.php به چه دردی می خوره می‌تونید این لینک رو ببینید.

xmlrpc - 01

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

یکی از متغییرهایی که می‌شه باهاش اطلاعاتی از API وردپرس دریافت کرد، wp.getUsersBlogs است که وبلاگ‌های یک کاربر رو بر‌گردونه. این متغیر از نسخه ۳.۵ به بعد وردپرس در دسترسه. برای کار با این گزینه باید پارامترهای مورد نیازبه روش post به آدرس mydomain.com/xmlrpc.php ارسال بشن.

خب بذارید روی یک سایت واقعی این درخواست رو بفرستیم.

xmlrpc - 02

دیدیم که در پارامترها، نام کاربری و پسورد به اسکریپت php ارسال شد و با توجه به اشتباه بودن اونها، خروجی خطا نشون داده شد. با faulcode برابر ۴۰۳ و پیام “نام کاربری یا رمز اشتباه است”.

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

xmlrpc - 03

 

چندتا مورد رو با دیدن این دو تصویر و مقایسه شون می‌شه فهمید.

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

دوم اینکه می بینیم حتی با وجود کد خطا، صفحه html اصلی (بدون خطا یا به عبارتی با کد ۲۰۰) باز شده. بنابراین تشخیص این روش برای فایروال‌ها مشکله. یکی از شیوه‌های تشخیص تلاش برای هک، تعداد دفعاتیه که صفحه‌هایی با کد خطا مثل ۴۰۴ باز شده‌اند.

سوم اینکه یکی از روش‌های جلوگیری از حدس و خطا (Brute Force)، تغییر صفحه ورود سایته. مثلا من از این روش استفاده می‌کنم و صفحه لاگین با آدرس wp-login که آدرس پیشفرض وردپرسه، باز نمی‌شه. اما در این روش دیگه نیازی به داشتن آدرس صفحه نیست.

آمار سایت امنیتی سکوری نشون می ده که در ماه گذشته استفاده از این روش با شیب زیادی، رشد داشته.

wordpress-brute-force

 

پیشگیری

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

xmlrpc - 04

برای حل موقتی این مشکلی تا زمانی که وردپرس براش فکری نکره باید یک دستور رو به فایل توابع وردپرس اضافه بکنید. در بخش Appearance و در زیر مجموعه Theme Editor رفته و از لیست فایل قالب، فایل functions.php رو انتخاب می‌کنیم و این کد رو به متن اضافه می کنیم:

 

پ ن: ممنون از جادی که اجازه داد از اسکرین شات سایتش استفاده کنم (تصویر اول)

منابع:

WordPress XML-RPC Brute Force Attack Vulnerability

New Brute Force Attacks Exploiting XMLRPC in WordPress

More WordPress XMLRPC Brute Force Attacks

 

 

Standard
امنیت

باز نشدن سایت‌ها، یک هک واقعی

هفته گذشته یکی از دوستان توی صحبت هایی که داشتیم گفت وقتی از *****شکن استفاده نمی کنه، هیچ سایتی باز نمی شه به جز گوگل، اون هم بدون HTTPS. اولین حدسی که زدم این بود که سرویس DNS ای که استفاده می کنه دچار مشکل شده. یعنی هک شده؟
قدم به قدم با هم جلو رفتیم. اول پرسیدم که آیا از نرم افزارها یا سرویس های DNS امن و آزاد استفده می کنه؟ چون بعضی از این سرویس ها در اینترنت ایران دچار محدودیت می شن. استفاده نمی کرد. پیش از این در پست دیگه‌ای در مورد DNS نوشته بودم.
ازش خواستم که Trace Route به آدرس گوگل بدون HTTPS و گوگل رمزگذاری شده رو برام بفرسته. تریس‌روت به گوگل بدون HTTPS که بین راه به کلی مشکل برمی‌خورد و بعد از یکی دوبار timeout به مقصد می رسید. سایت دیگه که در مرحله اول نمی تونست IP رو پیدا کنه. باز هم شک اولیه به مشکل داشتن DNS تقویت شد.

tracert 1

می بینید که خطای unable to resolve target system name می‌ده.
ازش خواستم که با IPConfig و یا چک کردن تنظیمات شبکه، ببینه که چه سرویس DNS ست شده. دو IP وجود داشت:
۷۴.۸۲.۲۰۷.۲۶
۸.۸.۸.۸

آی‌پی دوم که مربوط به سرویس دی‌ان‌اس گوگله اما آی‌پی اول مشکوکه. با کمی جستجو متوجه شدیم که این IP نه تنها مربوط به سرویس های معتبر DNS نیست که در کنترل یک هکره.
نمونه های تغییر دی‌ان‌اس به این IP پیش از این در کشور تایلند دیده شده بود و بر اساس گزارش های موجود یا ناشی از بدافزاری بوده که اخیرا با شبیه سازی به‌روز رسانی Flash Player نصب می شده و یا در اثر استفاده از ضعف امنیتی مودم/روتر توسط هکر و نفوذ به سیستم و تغییر سرویس DNS. نکته اینجاست که قربانی‎های این روش در کشور تایلند پس از باز کردن سایت گوگل، به سایت دیگری منتقل می شدند و بهشون اعلام می‌شد که باید از نسخه Flash Player Pro استفاده کنند.

update-flash-player-1

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

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

۱. اتصال اینترنت رو قطع می کنیم.
۲. IP ست شده در سرویس DNS رو به حالت عادی برمی‌گردونیم. می تونیم فعلا از سرویس‌های گوگل استفاده کنیم.
۳. مشخصات نگهداشته شده توی ویندوز برای سرویس DNS رو با این دستور پاک سازی می کنیم: ipconfig /flushdns
۴. با آنتی‌ویروس و ضد بدافزار، کل سیستم رو اسکن می‌کنیم.
۵. با اتصال به اینترنت، کلیه پسوردها (حداقل پسوردهای استفاده شده در زمان هک) رو تغییر می دیم.
۶. از گزینه های کمکی سایت ها برای کنترل لاگین از مکان‌های غیر عادی استفاده می کنیم. سرویس‌هایی مثل جیمیل و فیسبوک، این گزینه رو در اختیار کاربر می ذارن.
۷. دسترسی به صفحه لاگین مودم/روتر از طریق وایفای و یا اینترنت رو محدود می کنیم. (در این مورد پست دیگه ای خواهم گذاشت)
۸. آخرین نسخه firmware مودم/روتر رو از سایت رسمی اون دانلود کرده و به‌روز رسانی انجام می‌دیم.

همچنین برای جلوگیری از اتفاقات مشابه و یا سواستفاده های احتمالی از سرویس DNS، پیشنهاد می شه یا به صورت دستی از IP سرویس‌های معتبری مانند گوگل استفاده بشه و یا از سرویس‌های امنی مثل opennicproject و DNSCrypt که خود را ملزم به رعایت حریم خصوصی کاربران می دونند و تاریخچه‌ای از درخواست‌های کاربران (که نشون دهنده سایت‌هاییه که بازدید کردن) توی سرورهاشون نگه‌ نمی‌دارن.

برخی از *****شکن‌ها برای بالا بردند امنیت کاربر، درخواست‌های DNS رو هم از طریق ترافیک رمزشده خودشون منتقل می‌کنند اما نکته اینجاست که آیا این *****شکن‌ها خودشون قابل اعتمادن؟

 

پ.ن: اون علی که توی تصویر اول می‌بینید، همون علی پست قبل که دچار هک فرضی شد، نیست.

Standard