दो Google भेद्यता कहानियां

डिस्क्लेमर: लेख में वर्णित सभी शोध गतिविधियों को भेद्यता पुरस्कार कार्यक्रम के हिस्से के रूप में किया गया था।

कहानी 1. छोटे कंटेंट टाइप के बारे में

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



हम्म। सब ठीक है। मैं शर्त लगाता हूं कि इस पृष्ठ पर सामग्री प्रकार फ़िल्टर्ड नहीं है। सर्वर के लिए एक सरल स्क्रिप्ट:

<?php header('Content-Type: text/ ; charset=UTF-8'); ?>

और हमें वही मिला जो हम चाहते थे:

कहानी 2. छोटी कॉलबैक के बारे में

फीडबर्नर में भेद्यता वितरित नहीं हुई - इसमें कुछ भी उल्लेखनीय नहीं था। इसलिए, मैंने तुरंत खोज जारी रखी। मेरा ध्यान APIs Explorer सेवा के लिए Developers.google.com पर दिया गया था। यह एक उपकरण है जो आपको विभिन्न Google प्रोग्रामिंग इंटरफेस को अंतःक्रियात्मक रूप से देखने में मदद करता है। इसके साथ, आप एपीआई और उनके संस्करणों, प्रत्येक एपीआई के लिए उपलब्ध तरीकों, साथ में प्रलेखन के साथ समर्थित पैरामीटर और बहुत कुछ देख सकते हैं। वास्तव में, मैं पोस्ट-मेसेजेज के आधार पर क्रॉस-डोमेन संचार प्रणाली में रुचि रखता था। जांच की गई Google API का लिंक निम्नानुसार है:

developers.google.com/apis-explorer/?base=https://webapis-discovery.appspot.com/_ah/api#p/

बेस पैरामीटर को कुछ नियमित अभिव्यक्तियों द्वारा फ़िल्टर किया जाता है (वास्तव में, यह खराब फ़िल्टर किया जाता है), जो 23% का उपयोग करके बाईपास करना आसान है:

developers.google.com/apis-explorer/?base=https://evil.com%23webapis-discovery.appspot.com/_ah/api#p/admin/reports_v1/

नतीजतन, एक iframe src = bad.com पैरामीटर के साथ बनाया जाता है, हम इसके एक संदेश की प्रतीक्षा कर रहे हैं। प्रत्येक संदेश में दो टोकन होने चाहिए। पहला टोकन विंडो में सम्‍मिलित है। दिए गए आइफ्रेम का नाम, दूसरा स्थान। मैंने देखा कि webapis-discovery.appspot.com/_ah/api से क्या संदेश भेजे गए हैं, और मान्य टोकन के साथ एक ही संदेश भेजने के लिए एक पृष्ठ लिखा है। पृष्ठ ने पूरी तरह से काम किया, और मैंने कार्यान्वयन के लिए कुछ HTML डेटा पास करने की कोशिश की। कोई फायदा नहीं हुआ। मैं पाठ, छवियों का स्थान बदल सकता हूं, लेकिन यह XSS के लिए पर्याप्त नहीं है। दस्तावेज़ के लिंक को बदलना भी संभव था। मैं इसे जावास्क्रिप्ट में बदलने में कामयाब रहा : सतर्क (document.domain) :



लेकिन मेरे लिए यह पर्याप्त नहीं था। मुझे यह तथ्य पसंद नहीं था कि ऑपरेशन के लिए एक उपयोगकर्ता कार्रवाई की आवश्यकता होती है। उपयोगकर्ता कभी भी वह नहीं करते हैं जो मैं चाहता हूं - इस मामले में वे लिंक पर क्लिक नहीं करते हैं :) इसलिए, मैंने कॉलबैक फ़ंक्शन (अब लगभग सभी डेवलपर्स इसे सुरक्षित मानते हैं) के साथ Developers.google.com पर पृष्ठ का उपयोग किया। मैंने इस पृष्ठ पर मूल-लाइक [0] जैसे कॉलबैक के साथ एक रीडायरेक्ट जोड़ा। पोस्टमेसेज का उपयोग करके डॉक्यूमेंटेशन लिंक बनाए जाने के बाद मेरे शोषण में क्लिक करें। ([] पात्रों को फ़िल्टर किया गया था। वास्तव में, कॉलबैक इस तरह था:

document.body.lastElementChild.previousSibling.lastElementChild.firstElementChild.firstElementChild.lastElementChild.firstElementChild.firstElementChild.firstElementChild.nextSibling.)

हम कोशिश करते हैं:



हुर्रे! यह पूरी तरह से और उपयोगकर्ता बातचीत के बिना काम करता है। तो, शोषण कुछ इस तरह से देखा:

token_1 = location.hash.split('rpctoken=')[1];
token_2 = window.name;
send_payload(data,token_1,token_2);
window.setTimeout('document.location=callback_url;',3000); // - -…

और हां, मैंने एक अच्छा स्क्रीनशॉट लिया:



मुझे ऑपरेशन का यह तरीका पसंद आया। मैंने इसे अन्य सेवाओं में उपयोग करने की कोशिश की, और मैंने उपयोगकर्ता के OAuth टोकन को चोरी करने, उपयोगकर्ता की भुगतान डेटा का उपयोग करते हुए, उसकी ओर से Google Play पर कोई भी एप्लिकेशन खरीदने में मदद की, जबकि खरीदे गए एप्लिकेशन को उपयोगकर्ता के डिवाइस पर स्वचालित रूप से इंस्टॉल किया गया था।

Google सुरक्षा टीम के लोगों ने भी इस तकनीक को पसंद किया, और उन्होंने इसे OWASP AppSec Eu पर वर्णित किया, इसे रिवर्स क्लिकिंग कहा।

पावेल टॉपरकोव, सकारात्मक अनुसंधान द्वारा पोस्ट किया गया