امنیت

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

حدود یک هفته پیش نسخه جدید وردپرس برای جلوگیری از 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
امنیت

خطر عکس پروفایل واتزاپ – یک هک فرضی

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

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

بیاید شروع کنیم.

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

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

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

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

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

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

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

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

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

Standard