امنیت

در پشتی در پوسته‌های وردپرس

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

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

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

در پشتی

در تصویر بالا می‌بینید که تا خط ۹ همون کاری که از فایل انتظار داریم انجام می‌شه اما بعد از اون دو تا دستور PHP دیگه وجود داره. این دستورها برای رمزگشایی کدهایی است که پیش از این با روش برگشت‌پذیر base64 رمز شده‌اند. هکرها از راه‌های زیادی برای مخفی کردن درهای پشتی استفاده می‌کنند. از به‌هم ریختگی در کد، تا استفاده از کوچک‌ترین کدهای ممکن تا از چشم مدیر سایت دور بمونه. همچنین پسورد هم می‌گذارند گاهی تا توی تست‌های نفوذ نشه پیدا کرد این فایل‌های دستکاری شده رو.

تصویر زیر، کدهای رمزگشایی شده است.

در پشتی رمزگشایی شده

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

در ابتدا یک ایمیل حاوی آدرس سایت برای هکر ایمیل می‌شه. حالا هکر که می‌دونه یک مدیر سایت از پوسته دستکاری شده استفاده می‌کنه، به آدرس سایت رفته و صفحه خطای ۴۰۴ رو باز می‌کنه. سپس می‌تونه با پسوردی که از قبل ست شده، دستورات دلخواهش رو توی سرور قربانی اجرا کنه.

این پسورد رمز شده هکره (به پیشنهاد آیدین، پسورد رو برای مدتی حذف می‌کنم که کسی آسیب نبینه):

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

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

virtual-freer

پس از گزارش من در توییتر، سایت وردپرس فارسی بلافاصله لینک دانلود پوسته‌های مشکل‌دار رو غیرفعال کرد و به کاربران اطلاع داد که از این پوسته‌ها استفاده نکنند. غیر از Modern Style پوسته P30Temp هم همین در پشتی رو داشت.

Modern Style

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

کسی که این در پشتی رو کار گذاشته از ایمیل infocallpro@gmail.com برای خبرگرفتن از درهای پشتی فعال استفاده می‌کنه. اگر جایی با این آدرس ایمیل برخورد کردید، به من اطلاع بدید تا موارد خطر احتمالی رو بررسی کنم.

استاندارد
امنیت

سایت من هک شد، چکار کنم؟

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

در این پست نحوه هک شدن و بررسی یکی از ظرف‌های عسلمون (Honey Pot) رو توضیح می‌دیم. سایت‌هایی که به عنوان ظرف عسل استفاده می‌شن روی سرویس‌های میزبانی معروف راه‌اندازی شده‌اند. هم روی VPS و هم روی هوستینگ‌های مدیریت شده و نیز مشترک. در اکثر این سایت‌ها، از سرویس‌های عادی استفاده شده و بنابراین تمهیدات خاصی در موردشون از سوی میزبان انجام نشده.

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

هدف ساده‌ای داریم؛ ما می‌خوایم که درک بهتری از ماهیت متغیرامنیت سایت داشته باشیم و تمایلات هکرها رو بررسی و تفسیر کنیم. داشتن سایت‌هایی برای هک شدن، ما رو در واکنش به نفوذهای مشابه هوشیارتر می‌کنه و درک بهتری از حس مدیر سایت در شرایط مشابه خواهیم داشت. بین خودمون بمونه، ما کمی هیجان زده هم شدیم، مثل عنکبوتی که از لرزش تارها می‌فهمه که چیزی به دام افتاده.

تصویر سایت هک شده

 

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

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

استفاده از ابزارهای امنیتی

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

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

پیام لاگین شدن ادمین به سایت

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

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

پیام های استفاده از theme Editor

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

خوشبختانه، غیرفعال کردن این گزینه خیلی راحته. کافیه یک خط کد رو به فایل wp-config.php اضافه کنید.

همچنین افزونه‌های امنیتی مثل افزونه SUCURI  و iTheme Security این اماکن رو به شما می‌دن که ادیتور رو غیرفعال کنید.

غیر فعال کردن Theme Editor

بررسی تاثیرات نفوذ

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

سوال بعدی اینه که “دیگه چی تغییر کرده؟”. ما از ابزارهای بازبینی استفاده می‌کنیم تا بفهمیم آیا فایلی تغییر کرده است یا خیر.

فایل های تغییر کرده

با بررسی لاگ تغییرات، متوجه می‌شیم که هکر دو فایل رو دستکاری کرده.

twentythirteen/page.php

twentythirteen/index.php

فایل ایندکس دوباره تغییرات داشته و نقطه خوبیه برای شروع بررسی‌ها.

با استفاده از filezilla و پروتوکول SFTP به سرورمتصل می‌شیم و می‌بینیم که واقعا این فایل‌ها امروز تغییر کرده‌اند.

FileZilla

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

صفحه تغییر چهره داده شده

البته می‌تونیم به شیوه خود هکرها با رفتن به محیط مدیریت سایت و با استفاده از theme Editor، این فایل‌ها رو باز کنیم.

Sucuri-My-Website-Was-Hacked-Theme-Editor-and-Payload

با چک کردن فایل‌های دیگه سرور متوجه می‌شیم که هکر فایل دیگری رو تغییر نداده. نمی دنیم که واکنش به موقع بوده و یا هکر همین مقدار تغییرات براش کافی بوده.

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

تغییر پسورد سایت هک شده توسط حمله کننده

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

تاریخچه ورودهای موفق به بخش مدیریت

ما همچنین می دونیم که در این دوبار، نفوذ کننده‌ها از IP های روسیه و ترکیه وارد سایت شده اند. البته اونها می‌تونن هرجایی از دنیا باشند.

هرچند این اطلاعات کمک چندانی نمی‌کنن اما گروه هکر رو می‌شناسیم:

صفحه فیسبوک گروه هکر

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

اکانت توییتر گروه هکر

بهبود وضعیت امنیت سایت

این مساله طولانی‌تر از اونیه که با یه پست وبلاگ بتونیم بگیمش. بسیاری از این حمله‌ها اتوماتیک انجام می‌شه اما این حمله خاص، دستی بوده. هرچند که نفوذ به مکانیزم کنترل (مثلا لاگین به wp-admin)، دسترسی بوده اما احتمال داره که فاز اول حمله به صورت اتوماتیک انجام شده باشه. به این شکل که یک اسکریپت احتمالا اطلاعات کاربری ضعیف رو پیدا کرده و جایی ثبت می‌کنه و هکرها بعدا و سرفرصت در فاز دوم حمله، سایت رو هک می‌کنن.

Sucuri-My-Website-Was-Hacked-Attack-Sequence

وقتی به مراحل اتفاقات نگاه می کنیم از خودمون می‌پرسیم:

برای جلوگیری از هک چکار می‌تونستیم بکنیم؟

پیشنهادهای ما برای این مورد خاص اینهاست:

مفیدترین گزینه: محدودیت دسترسی

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

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

جایگزین ۱: محدودیت تلاش برای ورود

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

جایگزین ۲: استفاده از پسورد پیچیده، طولانی و یکتا

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

جایگزین ۳: استفاده از ورود دو مرحله‌ای

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

 

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

در پایان وقتی که همه کارهای لازم برای پاک سازی سرور رو انجام دادید، باید برخی کارهای دیگه هم بکنید. برای مثال همه کاربرها رو مجبور کنید که پسوردشون رو تغییر بدن. کلیدها و salt های مندرج در wp-config.php رو تغییر بدید. اگر نمی دونید اینها چیه، می تونید از افزونه رایگان Sucuri استفاده بکنید.

Sucuri-My-Website-Was-Hacked-Post-Hack-Features

پیشنهادهای تکمیلی

خب، پیشنهادهای سایت sucuri تا ایجا بود. بذارید کمی از موردهایی که خودم دیدم و در پاک سازی سایت‌ها استفاده می‌کنم هم بگم شاید به کارتون بیاد.

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

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

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

در پایان هم پیشنهاد می‌کنم در صورت هک شدن، حتما از یک متخصص برای پاک‌سازی سایت و سرور کمک بگیرید.

 

منبع:

http://blog.sucuri.net/2014/08/my-wordpress-website-was-hacked.html

استاندارد
امنیت

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

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

 

 

استاندارد