हैक कर लिया गया। कैसे समझना चाहते हैं


40

किसी ने, दूसरी बार, जावास्क्रिप्ट की एक साइट को चलाने में मदद की, जिसे मैंने चलाने में मदद की। यह जावास्क्रिप्ट Google एडसेंस को हाइजैक करता है, अपना खाता नंबर डालता है, और सभी विज्ञापनों को चिपका देता है।

कोड को हमेशा एक विशिष्ट निर्देशिका में (एक तीसरे पक्ष के विज्ञापन कार्यक्रम द्वारा उपयोग किया जाता है) हमेशा जोड़ा जाता है, इस एक विज्ञापन dir (20 या तो) के अंदर कई निर्देशिकाओं में कई फाइलों को प्रभावित करता है और रात भर में लगभग उसी तरह डाला जाता है पहर। Adsense अकाउंट एक चीनी वेबसाइट का है (एक कस्बे में स्थित है जहाँ से मैं अगले महीने चीन में नहीं रहूँगा एक घंटे में। हो सकता है कि मैं बस्ट हेड जाऊं ... मज़ाक करना, छाँटना), btw ... यहाँ पर जानकारी है साइट: http://serversiders.com/fhr.com.cn

तो, वे इन फ़ाइलों पर पाठ कैसे जोड़ सकते हैं? क्या यह फाइलों पर निर्धारित अनुमतियों (755 से 644 तक) से संबंधित है? वेबसर्वर उपयोगकर्ता के लिए (यह MediaTemple पर है इसलिए इसे सुरक्षित होना चाहिए, हाँ?) मेरा मतलब है, अगर आपके पास एक फाइल है जिसकी अनुमति 777 पर है, तो मैं अभी भी उस पर कोड नहीं जोड़ सकता ... वे ऐसा कैसे कर सकते हैं?

यहां आपके देखने के आनंद के लिए वास्तविक कोड का एक नमूना है (और जैसा कि आप देख सकते हैं ... इससे ज्यादा नहीं। असली चाल यह है कि उन्हें वहां कैसे मिला):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

चूंकि बहुत से लोगों ने इसका उल्लेख किया है, यहां वही है जो मैंने चेक किया है (और चेक द्वारा मैंने मतलब है कि मैंने उस समय के आसपास देखा था जब फाइलें किसी भी अजीबता के लिए संशोधित की गईं थीं और मैंने POST स्टेटमेंट्स और डायरेक्टरी ट्रैवर्सल्स के लिए फाइलें पकड़ ली थीं:

  • access_log (सामान्य से अधिक समय के आसपास कुछ भी नहीं (यानी अत्यधिक) एमएसएन बॉट ट्रैफ़िक)
  • error_log (कुछ भी नहीं है, लेकिन सामान्य फ़ाइल में अशुभ दिखने वाली फ़ाइलों के लिए त्रुटियाँ मौजूद नहीं हैं)
  • ssl_log (सामान्य कुछ भी नहीं)
  • मैसेज_लॉग (मेरे अलावा कोई एफ़टीपी यहाँ नहीं है)

* अद्यतन: ** ठीक है, इसे हल किया। चीन के हैकरों ने हमारी साइट में एक फाइल रखी थी जो उन्हें सभी तरह की प्रशासनिक चीजें करने की अनुमति देती है (डेटाबेस एक्सेस, डिलीट और फाइल्स और डायरियां बनाना, आप इसे नाम दें, उनके पास एक्सेस था)। हम भाग्यशाली थे कि उन्होंने कुछ और विनाशकारी नहीं किया। सामान्य अपाचे लॉग फ़ाइलों में कुछ भी नहीं था, लेकिन मुझे वेब सर्वर लॉग एनालाइज़र में लॉग फ़ाइलों का एक अलग सेट मिला और सबूत वहां थे। वे अपने स्वयं के व्यवस्थापक उपयोगकर्ता नाम और पासवर्ड के साथ इस फ़ाइल को एक्सेस कर रहे थे और फिर जो कुछ भी आवश्यक था उन्हें सर्वर पर संपादित कर रहे थे। उनकी फ़ाइल में उपयोगकर्ता के रूप में "अपाचे" सेट होता है जबकि हमारी साइट पर अन्य सभी फ़ाइलों का एक अलग उपयोगकर्ता नाम होता है। अब मुझे यह पता लगाने की जरूरत है कि हमारे सिस्टम पर उन्हें यह फाइल कैसे मिली। मुझे संदेह है कि इसके लिए अंततः हमारी वेब होस्ट (मीडिया मंदिर) के साथ आराम होगा,


6
मुझे नहीं पता, क्या आपने किसी को अपना पासवर्ड दिया है?

4
यदि आपको पता है कि वास्तव में ऐसा कब होता है, तो इस समय के आसपास असामान्य हर चीज के लिए अपने एक्सेस_लॉग को खोजें। विशेष रूप से सभी POST अनुरोधों पर ध्यान दें: वे कहाँ जाते हैं, उन्होंने क्या किया।
sanmai

3
Thx WhirlWind ... बहुत मददगार।
लोथर_ग्रिम्पसेनबैकर

2
वास्तव में यदि आप उन्हें जानते हैं, तो एक विरोधी स्पैमिंग साइट पर उनके पते का विवरण क्यों नहीं चिपकाएँ। नेट को "बोलने" दें और उन्हें अपने स्वयं के मेडिसिन का स्वाद दें। :-)

4
@ goshan88 - अधिक उपयोगी तो आप सोच सकते हैं। एक हमला वेक्टर एक ट्रोजन है जो डेवलपर्स के ftp क्लाइंट से पासवर्ड सूँघता है।
क्वेंटिन

जवाबों:


9

सबसे पहले chmod 744आप क्या चाहते हैं। सिस्टम पर अन्य खातों तक पहुंच को रद्द करने के लिए chmod का बिंदु है। Chmod 700, Chmod की तुलना में कहीं अधिक सुरक्षित है 744। हालांकि अपाचे को केवल आपके php एप्लिकेशन को चलाने के लिए निष्पादन बिट की आवश्यकता है।

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data को आमतौर पर Apache के खाते के रूप में उपयोग किया जाता है जो php को निष्पादित करने के लिए उपयोग किया जाता है। आप उपयोगकर्ता खाते को देखने के लिए यह कमांड भी चला सकते हैं:

`<?php
print system("whoami");
?>`

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

एक और संभावना यह है कि आप एक पुरानी लाइब्रेरी या एप्लिकेशन का उपयोग कर रहे हैं। सॉफ़्टवेयर विक्रेता की साइट पर जाएं और सुनिश्चित करें कि आप नवीनतम संस्करण चला रहे हैं।


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

1
एफ़टीपी करता एसएसएल के साथ आते हैं, तुम्हें पता है।
ग्रैविटी

1
@ अधिकांश लोग "ftps" का उपयोग नहीं करते हैं, लेकिन यह आपको हैक होने से बचाए रखेगा। sftp अधिक लोकप्रिय है।
रूक

2
Www-data को आपकी वेब निर्देशिका में फ़ाइलों का स्वामी नहीं होना चाहिए । कुछ भी जो www-data सर्वर पर खराब लिखित स्क्रिप्ट द्वारा अपडेट किया जा सकता है।
जोर्डैच

9

मेरा मीडिया मंदिर ग्रिड सर्वर खातों को कई बार इस तरह "हैक" किया गया है। उनकी सुरक्षा बहुत खराब है ... पिछले साल PLAIN TEXT PASSWORDS के साथ शुरू हुआ और आज भी जारी है (आप तकनीकी सहायता को कॉल कर सकते हैं और वे कहते हैं कि "आपका पासवर्ड क्या है?")। मुझे पता है क्योंकि मुझे मासिक ईमेल मिलते हैं कि कैसे उन्होंने मेरे सभी खाते के पासवर्ड बदल दिए हैं और वे वास्तव में हर बार हैक होने पर आपके लिए डेटाबेस पासवर्ड बदलते हैं। वह कंपनी सतह पर नरक के रूप में चमकदार दिखती है, लेकिन ग्रिड सर्वर एक गड़बड़ है। मैं तुरंत स्विच करने की सलाह देता हूं ।

कृपया इस पोस्ट को पिछले साल के मूल फ़िस्को (चेतावनी के बारे में देखें , यह आपको नाराज कर देगा)। यह वहां से खिसक गया है। मैंने पिछले साल अपने परिवार से दूर रहने और अपनी वेबसाइटों से पोर्न लिंक हटाने के लिए धन्यवाद दिया। लवली।

उनके स्टेटस पेज पर मौज-मस्ती पर नज़र रखें : यह आप सभी को नवीनतम कारनामों के बारे में बताएगा (और, हाँ, वास्तव में, वहाँ अभी "संभावित शोषण" है)।


haha। मेरी gs साइटें अभी नीचे हैं। कोई ईमेल नहीं। weblog.mediatemple.net/weblog/category/system-incidents/…
टाइपोनेयर

2

एक्सेस लॉग्स आदि में गतिविधि की कमी के आधार पर और तथ्य यह है कि लगभग एक ही समय में हो रहा है, यह प्रतीत होता है कि उन्होंने सर्वर से समझौता किया है और इसमें किसी प्रकार की शेल स्क्रिप्ट है जो एपेंडिंग को निष्पादित करने के लिए चल रही है।

क्या आपने कुछ अजीब के लिए क्रेस्टब की जाँच की है?

क्या आपने निर्देशिका और इसके संदर्भों का नाम बदलने की कोशिश की है (यह शेल स्क्रिप्ट को तोड़ सकता है)?


नाम बदलना एक अच्छा विचार है। मैं कोशिश करूँगा कि एक बार मैं यह देखूं कि साइट पर इसका क्या प्रभाव पड़ेगा। Crontab में एक छोटी सी अजीब बात थी, उस समय के लिए एक प्रविष्टि है जब फाइलें बदल दी गई थीं, लेकिन यह Plesk बैकअप प्रबंधक है ... एक संकलित अनुप्रयोग। अगर इससे समझौता होता है तो मीडिया टेंपल के हाथों में एक बड़ी समस्या है।
लोथर_ग्रिम्पसेनबैकर

1

हां, यह निश्चित रूप से फ़ाइल अनुमतियों से संबंधित हो सकता है। वे फ़ाइलें जो वेब प्रक्रिया द्वारा लिखने योग्य हैं, आपके द्वारा चलाए जा रहे वेब अनुप्रयोगों में किसी भी सुरक्षा भेद्यता के लिए खुली हैं। सब कुछ बंद कर दें ताकि वेब प्रक्रिया कुछ भी पढ़ या लिख ​​नहीं सके, इससे अधिक की जरूरत है।

अन्य घटक नीचे ट्रैक कर रहे हैं कि वे आपकी फ़ाइलों को कैसे संशोधित कर रहे हैं। वेब सर्वर के एक्सेस लॉग की जांच करना शुरू करने के लिए एक अच्छी जगह है। विभिन्न उपयोगकर्ताओं के लिए अंतिम लॉगिन समय की जाँच करें। आप एक स्क्रिप्ट भी सेट कर सकते हैं जो संशोधन के लिए फ़ाइलों की निगरानी करता है, और आपको सूचित करता है ताकि आप अपराधियों को रंगे हाथों पकड़ सकें!


1

यह भयानक रूप से Wordpress हैक्स से परिचित है जो हाल ही में नेटवर्क सॉल्यूशंस साइटों के एक हिट से टकराया है। चूंकि आप मीडिया टेंपल पर हैं, इसलिए संभव है कि आपने कुछ उपयोगकर्ताओं को अपनी मशीन साझा करते हुए दिखाई देने वाली कुछ फ़ाइलों को छोड़ दिया। यह POST या ईरी अपाचे लॉग निशान की कमी की व्याख्या करेगा। अगर ऐसा है तो कमांड लाइन पर कोड इंजेक्ट करना घातक होगा।


लॉग उस समय के आसपास ट्रैफ़िक दिखाते हैं कि इन फ़ाइलों को संशोधित किया गया था, लेकिन यह अहानिकर सामान है जैसे: 207.46.13.43 - - [05 / मई / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 और पेज = 4 HTTP / 1.1 "404 257" - "" MSNbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher

क्या आप जानते हैं कि वर्डप्रेस हैक कैसे काम करता है? मुझे अपनी समस्या को ठीक करने का तरीका बता सकते हैं।
लोथर_ग्रिम्पसेनबैकर

2
हां, यह साझा बक्सों पर खराब अनुमति थी, संभवतः नेटवर्क समाधान के हिस्से पर खराब डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण। अनुशंसित फिक्स फ़ोल्डरों पर 755 और फाइलों पर 644 के रूप में अनुमतियों को लॉक करने के लिए था।

1

कोड को हमेशा जोड़ा जाता है, हमेशा एक विशिष्ट निर्देशिका में

क्या यह फाइलों पर निर्धारित अनुमतियों (755 से 644 तक) से संबंधित है? वेबसर्वर उपयोगकर्ता के लिए

क्या आप एक साझा सर्वर पर हैं? यदि ऐसा है (या यहां तक ​​कि यदि नहीं), तो किसी ने जानवर को एक एफ़टीपी पासवर्ड के लिए मजबूर किया हो सकता है और एक स्क्रिप्ट अपलोड की है जो किसी भी फाइल को संलग्न करती है जो उसके हाथों को प्राप्त कर सकती है।

एक तीसरे पक्ष के विज्ञापन कार्यक्रम द्वारा उपयोग किया जाता है

या शायद इस कार्यक्रम में एक शोषण है।


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

1
यदि आपकी फ़ाइलें वेबसर्वर द्वारा लिखने योग्य हैं, तो संभव है कि वे स्क्रिप्ट को सर्वर पर किसी भी वेबसाइट पर अपलोड कर सकते हैं और उनकी फ़ाइलों को ओवरराइट कर सकते हैं । लेकिन मैं उस तीसरे पक्ष के ऐप को भी बारीकी से देखूंगा।

तीसरे पक्ष के कोड ... यह एक निष्पादन स्क्रिप्ट या सिर्फ एक जावास्क्रिप्ट टुकड़ा है? जावास्क्रिप्ट सर्वर पर फ़ाइलों को संशोधित नहीं कर सकता।
सलमान ए

@ सलमान ए - यह PHP स्क्रिप्ट का एक संग्रह है जो विज्ञापन का प्रबंधन करता है।
लोथर_ग्रिम्पसेनबैकर

ठीक है, फिर मुझे आशा है कि आपने उस कोड की जांच कर ली है।
सलमान ए

1

यदि आपके पास उचित पहुंच (और कर्नेल सपोर्ट) है, तो आप अपनी फ़ाइलों में परिवर्तन के लिए देखने के लिए inotify या dnotify के आधार पर एक मॉनिटरिंग डेमॉन को व्हिप करने का प्रयास कर सकते हैं , फिर फ़ाइल को खोलने के लिए "lsof" का उपयोग करके देखें कि किस प्रक्रिया के साथ फाइल खुली है पहुँच लिखें। आप निगरानी के लिए स्ट्रेस का उपयोग करने में भी सक्षम हो सकते हैं । यह एक सुराग प्रदान करना चाहिए कि निष्पादन योग्य का क्या फायदा उठाया जा रहा है।


1

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

अगला, यह आपके वेबसर्वर पर एक स्क्रिप्ट हो सकता है जो उस कोड को इंजेक्ट कर रहा है। एक साझा होस्टिंग परिदृश्य में, मुझे लगता है कि ऐसा करना संभव है cat /web/malicious.com/script.js >> /web/innocent.com/index.php। यह कुछ शर्तों के तहत काम कर सकता है, जैसे कि httpd उपयोगकर्ता और index.php फ़ाइल द्वारा निष्पादित की जाने वाली कमांड भी उस उपयोगकर्ता के स्वामित्व में / लिखने योग्य है। उस स्थिति में, आपके पास स्क्रिप्ट को इंजेक्ट करने के लिए उपयोग किए जा रहे खाते का पता लगाने के लिए आपका होस्टिंग प्रदाता होना चाहिए।


1

अधिकांश साइट फ़ाइलों को वेब सर्वर द्वारा पठनीय होना चाहिए। केवल पढ़ने के लिए साइट पर, केवल लॉग को वेब सर्वर द्वारा लिखने योग्य होना चाहिए। वेब सर्वर द्वारा उपयोग किए जाने के अलावा किसी अन्य को स्वामी सेट करें। स्क्रिप्ट को छोड़कर सभी फ़ाइलों पर सुरक्षा 640 सेट करें। स्क्रिप्ट और निर्देशिकाएं सेट करें 750. उन फ़ाइलों या निर्देशिकाओं के लिए जिन्हें वेबसीवर द्वारा लिखा जाना चाहिए, आप मालिक को वेब सर्वर में बदल सकते हैं या chmod g + 2 संबंधित फाइलों या निर्देशिकाओं को सेट कर सकते हैं।


गैर-सीजीआई लिपियों में अक्सर 600 या 640 मोड हो सकते हैं (फ़ाइल के मालिक और समूह पर निर्भर करता है और वेब सर्वर किस उपयोगकर्ता के रूप में चलता है), क्योंकि कई स्क्रिप्ट एक दुभाषिया के पास जाती हैं।
outis

0

किसी साइट को क्रैक करने के लिए एक zillion संभव तरीके हैं। वे आपकी स्क्रिप्ट में भेद्यता का उपयोग कर सकते थे, आपके पासवर्ड को चुरा सकते थे, सह-होस्टेड साइट (यदि आप एक सस्ते होस्ट पर हैं) की भेद्यता का उपयोग करते थे, सर्वर मशीन पर कुछ गैर-वेब-संबंधित सेवा की भेद्यता का उपयोग करते थे। ।

पहले चरण के रूप में, फ़ाइल मोडिफ़िकेशन दिनांक की जाँच करें, और उस समय किसी भी संदिग्ध गतिविधि के लिए पहुँच, त्रुटि और ftp लॉग की जाँच करें।


हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.