A7med Baraka
04-20-2010, 03:41 AM
نعم تمكن بعض المخترقون من إختراق موقع Apache قبل كم يوم وذلك عبر ثغرة في البرنامج الذي يستعملونه لمتابعة المشاكل والمشاريع Atlassian JIRA (http://atlassian.com/) … حيث قام المخترق حسب ما فهمت من الخبر الموجود هنا (https://blogs.apache.org/infra/entry/apache_org_04_09_2010) وهنا (http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html) من فتح تذكرة ووضع فيها رابط مختصر بواسطة إستعمال tinyurl.com يمكن المخترق من الوصول الى صلاحيات Administrator على JIRA الخاص بموقع أباتشي في إختراق من نوع cross site scripting (XSS) attack … أي الرابط قام بتوجيه المتصفح الى موقع JIRA الخاص في أباتشي ولكن تم تنفيذ هجوم XSS عليهم وحصلوا على صلاحياتهم من خلال ذلك …
من هناك بدأت قصة جديدة أهم ما في تلك القصة حسب وجهة نظري:
- التخطيط الرهيب الذي قام به المخترقون للوصول الى المحطة الأولى JIRA الخاص بفريق الأباتشي … ومن ثم الوصول الى حساب المستخدم root على خادمهم brutus.apache.org بسبب إستعمال أحدهم لكلمة سرية لحسابه في JIRA لنفس حسابه على الخادم … يعني وصلوا الى Local ومن ثم عملوا Privilege Escalation !!!
- حين وصلوا الى brutus أكتشفوا بإنه هناك مستخدمين قاموا بعمل Cache لكلماتهم السرية الخاصة بالـ Subversion … وبالتالي من هناك أستخرجوهم ومن ثم وصلوا الى خادم minotaur.apache.org … والذي هو خادم الـ shell الخاص بهم … مع العلم منع الـ Caching لكلمات السرية الخاصة بالـ Subversion ما هي إلا وضع السطر الذي بالأسفل في إعدادات Subversion:
store-passwords = no - إستعمال شركة عملاقة لبرنامج عملاق جداً جداً Atlassian JIRA لكلمات سرية بدون Salt شيء محزن صراحة … وقد أعترفوا من خلال نقاشهم مع الناس العامة على مدونتهم بذلك هنا (http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html) …
كل هذا كان نتيجة أخطاء من شركة يقوم موقع أباتشي بإستعمال برمجياتها … ومن ثم أخطاء المستخدمين عندهم بالضغط على أي رابط يتم إعطاءه لهم (ربما بدون إستعمال متصفحات تمنع الـ XSS وإختراقاته) … وأيضاً إستعمال كلمات سرية لحسابين مختلفين … طبعاً هذا بالإضافة الى شطارة وعبقرية المخترق أو المخترقين في كيفية إدارة جميع الخطوات والتخطيط للبداية والنهاية لجميع العملية …
صراحة درس ولا أروع كان ممكن من خلاله نكتشف بإنه حتى أتفه الثغرات أو أتفه الخطوات التي تقوم بها … ربما هناك من يستطيع إستغلالها والوصول الى أماكن كانت سابقاً بعيدة المتناول بالنسبة له
من هناك بدأت قصة جديدة أهم ما في تلك القصة حسب وجهة نظري:
- التخطيط الرهيب الذي قام به المخترقون للوصول الى المحطة الأولى JIRA الخاص بفريق الأباتشي … ومن ثم الوصول الى حساب المستخدم root على خادمهم brutus.apache.org بسبب إستعمال أحدهم لكلمة سرية لحسابه في JIRA لنفس حسابه على الخادم … يعني وصلوا الى Local ومن ثم عملوا Privilege Escalation !!!
- حين وصلوا الى brutus أكتشفوا بإنه هناك مستخدمين قاموا بعمل Cache لكلماتهم السرية الخاصة بالـ Subversion … وبالتالي من هناك أستخرجوهم ومن ثم وصلوا الى خادم minotaur.apache.org … والذي هو خادم الـ shell الخاص بهم … مع العلم منع الـ Caching لكلمات السرية الخاصة بالـ Subversion ما هي إلا وضع السطر الذي بالأسفل في إعدادات Subversion:
store-passwords = no - إستعمال شركة عملاقة لبرنامج عملاق جداً جداً Atlassian JIRA لكلمات سرية بدون Salt شيء محزن صراحة … وقد أعترفوا من خلال نقاشهم مع الناس العامة على مدونتهم بذلك هنا (http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html) …
كل هذا كان نتيجة أخطاء من شركة يقوم موقع أباتشي بإستعمال برمجياتها … ومن ثم أخطاء المستخدمين عندهم بالضغط على أي رابط يتم إعطاءه لهم (ربما بدون إستعمال متصفحات تمنع الـ XSS وإختراقاته) … وأيضاً إستعمال كلمات سرية لحسابين مختلفين … طبعاً هذا بالإضافة الى شطارة وعبقرية المخترق أو المخترقين في كيفية إدارة جميع الخطوات والتخطيط للبداية والنهاية لجميع العملية …
صراحة درس ولا أروع كان ممكن من خلاله نكتشف بإنه حتى أتفه الثغرات أو أتفه الخطوات التي تقوم بها … ربما هناك من يستطيع إستغلالها والوصول الى أماكن كانت سابقاً بعيدة المتناول بالنسبة له