Google स्प्रेडशीट का उपयोग करके किसी भी साइट का डीडीओएस

Google अपने फ़ीडफ़ेचर स्पाइडर का उपयोग फ़ार्मूला = छवि ("लिंक") के माध्यम से डाली गई Google स्प्रेडशीट पर किसी भी सामग्री को कैश करने के लिए करता है।

उदाहरण के लिए, यदि आप तालिका के किसी एक कक्ष में सूत्र सम्मिलित करते हैं

=image("http://example.com/image.jpg") 

Google इस छवि को डाउनलोड करने के लिए FeedFetcher मकड़ी को भेजेगा और इसे तालिका में आगे के प्रदर्शन के लिए कैश करेगा।

हालाँकि, यदि आप छवि URL में एक यादृच्छिक पैरामीटर जोड़ते हैं, तो FeedFetcher इसे हर बार फिर से डाउनलोड करेगा। उदाहरण के लिए, पीड़ित की साइट में 10 एमबी की पीडीएफ फाइल है। ऐसी सूची को तालिका में सम्मिलित करने से Google स्पाइडर को एक ही फ़ाइल को 1000 बार डाउनलोड करना पड़ेगा!

 =image("http://targetname/file.pdf?r=1") =image("http://targetname/file.pdf?r=2") =image("http://targetname/file.pdf?r=3") =image("http://targetname/file.pdf?r=4") ... =image("http://targetname/file.pdf?r=1000") 

यह सब कुछ साइट स्वामियों के लिए यातायात सीमा की थकावट का कारण बन सकता है। कोई भी जो केवल एक टैब के साथ एक ब्राउज़र का उपयोग कर रहा है, वह किसी भी वेब सर्वर पर एक बड़े पैमाने पर HTTP GET FLOOD हमला कर सकता है।

एक हमलावर के पास तेज चैनल होना भी नहीं है। चूंकि सूत्र एक पीडीएफ फाइल के लिए लिंक का उपयोग करता है (जो कि एक चित्र में नहीं है जो तालिका में प्रदर्शित किया जा सकता है), हमलावर को Google सर्वर से प्रतिक्रिया में केवल एन / ए प्राप्त होता है। यह आपको हमले को कई बार बढ़ाने की अनुमति देता है [DNS और NTP के प्रवर्धन का एनालॉग - लगभग। अनुवादक] , जो एक गंभीर खतरा बना हुआ है।



कई टैब के साथ एक लैपटॉप का उपयोग करना, बस 10 एमबी की फ़ाइलों की लिंक की पेस्टिंग-पेस्टिंग सूची, Google स्पाइडर इस फ़ाइल को 700 एमबीपीएस से अधिक की गति से डाउनलोड कर सकता है। मेरे मामले में, यह 30-45 मिनट तक चला, जब तक कि मैंने सर्वर को खटखटाया नहीं। अगर मैंने सब कुछ सही ढंग से गणना की, तो 45 मिनट में लगभग 240GB ट्रैफिक आया।

जब मैंने आउटगोइंग ट्रैफ़िक की मात्रा देखी तो मैं हैरान था। थोड़ा और, और मुझे लगता है कि आउटगोइंग ट्रैफ़िक 1 Gb / s तक पहुंच जाएगा, और आने वाले 50-100 Mbit / s। मैं केवल कल्पना कर सकता हूं कि अगर कई हमलावर इस पद्धति का उपयोग करते हैं तो क्या होगा। Google स्पाइडर एक से अधिक आईपी पते का उपयोग करता है, और यद्यपि उपयोगकर्ता-एजेंट हमेशा समान होते हैं, अगर हमले को पीड़ित आश्चर्यचकित करता है, तो वेब सर्वर कॉन्फ़िगरेशन को संपादित करना बहुत देर हो सकती है। इसके उपयोग में आसानी के कारण, हमला आसानी से घंटों तक रह सकता है।

जब इस बग का पता चला, तो मैंने इसका उपयोग करके Google की घटनाएं शुरू कीं, और दो पाया:
• एक लेख जहां एक ब्लॉगर वर्णन करता है कि कैसे उसने गलती से खुद पर हमला किया और यातायात के लिए एक बड़ा बिल प्राप्त किया। [ Habré पर अनुवाद - लगभग। अनुवादक] ।
• एक अन्य लेख में Google स्प्रेडशीट का उपयोग करते हुए एक समान हमले का वर्णन किया गया है, लेकिन सबसे पहले, लेखक साइट पर सभी फ़ाइलों के लिंक पार्स करने और कई खातों का उपयोग करके इस सूची पर हमले शुरू करने की पेशकश करता है।

मुझे यह कुछ अजीब लगता है कि किसी ने अनुरोध करने के लिए एक यादृच्छिक पैरामीटर जोड़ने की कोशिश नहीं की। यहां तक ​​कि अगर साइट में केवल एक फ़ाइल है, तो एक यादृच्छिक पैरामीटर जोड़ने से आप इस साइट पर हजारों अनुरोध कर सकते हैं। वास्तव में, यह थोड़ा डरावना है। बस एक खुले ब्राउज़र टैब में कई लिंक चिपकाने से ऐसा नहीं होना चाहिए।

कल मैंने इस बग का विवरण Google को भेजा और जवाब मिला कि यह भेद्यता नहीं है और बग बाउंटी कार्यक्रम से नहीं जाता है। शायद वे इसके बारे में पहले से जानते थे, और वास्तव में इसे बग नहीं मानते हैं?

हालांकि, मुझे उम्मीद है कि वे इस समस्या को ठीक कर देंगे। यह केवल थोड़ा सा कष्टप्रद है कि कोई भी Google स्पाइडर को इतनी सारी समस्याएं दे सकता है। URL में अतिरिक्त मापदंडों को छोड़ कर फ़ाइलों को डाउनलोड करने के लिए एक साधारण फिक्स है [मेरी राय में, यह एक बहुत ही बुरा फिक्स है। यह बैंडविड्थ को सीमित करने या प्रति यूनिट समय और ट्रैफ़िक की संख्या को सीमित करने और एक ही समय में एक निश्चित आकार से बड़ी फ़ाइलों को डाउनलोड न करने के लायक हो सकता है - लगभग। अनुवादक] ।