मेरी पहली हैक: एक साइट जो आपको किसी भी उपयोगकर्ता पासवर्ड को सेट करने की अनुमति देती है

हाल ही में, मुझे एक दिलचस्प भेद्यता मिली जो किसी भी उपयोगकर्ता को किसी भी पासवर्ड को सेट करने के लिए एक विशिष्ट साइट सेट करने की अनुमति देती है। कूल, हह?

यह हास्यास्पद था, और मुझे लगा कि मैं एक दिलचस्प लेख लिख सकता हूं।

आप उस पर टूट पड़े।



नोट: अनुवादित लेख के लेखक एक सूचना सुरक्षा विशेषज्ञ नहीं हैं, और यह SQL इंजेक्शन की दुनिया में उनका पहला भ्रमण है। वह " अपने भोलेपन के लिए कृपालु" होने के लिए कहता है।

चेतावनी: अनुवादित लेख के लेखक इस भेद्यता के साथ साइट का खुलासा नहीं करेंगे। इसलिए नहीं कि उसने मालिक को इसके बारे में सूचित किया और वह चुप्पी से बंधा हुआ है, बल्कि इसलिए कि वह खुद के लिए भेद्यता को संरक्षित करना चाहता है। यदि आप इस साइट का पता लगाते हैं, तो कृपया अपना मुंह बंद रखें (tsyts)।

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

/api/users?email=no 

और मैंने सोचा: मुझे आश्चर्य है कि क्या उन्होंने कुछ मूर्खता की अनुमति दी है? शायद मुझे एसक्यूएल इंजेक्शन आज़माना चाहिए?

मैंने एसक्यूएल इंजेक्शन कैसे करें - अपनी स्मृति को ताज़ा करने के लिए "xkcd छोटे बॉबी टेबल" के लिए नेट की खोज की - मुझे यह पसंद नहीं है - और काम करने के लिए मिला।

Chrome नेटवर्क टैब में, मैंने अनुरोध कॉपी किया (कॉपी> कॉपी के रूप में लाया गया) और परिणाम को एक टुकड़े में चिपकाया ताकि अनुरोध खेला जा सके:

 fetch('https://blah.com/api/users', { credentials: 'include', headers: { authorization: 'Bearer blah', 'content-type': 'application/x-www-form-urlencoded', 'sec-fetch-mode': 'cors', 'x-csrf-token': 'blah', }, referrer: 'https://blah.com/blah', referrerPolicy: 'no-referrer-when-downgrade', body: 'email=no', // < -- The bit we're interested in method: 'POST', mode: 'cors', }); 

बाकी लेख body रेखा के साथ उपद्रव के लिए समर्पित है - यह सर्वर को निर्देश भेजने के लिए एक परिवहन है।

पहले, मैंने अंतिम नाम कॉलम में मान सेट करके अपना अंतिम नाम बदलने की कोशिश की, बस इसके नाम पर ध्यान केंद्रित किया:

 { // ... body: `email=no', lastName='testing` } 

कुछ भी दिलचस्प नहीं हुआ। फिर मैंने last_name साथ भी यही किया, फिर मैंने surname साथ अपनी किस्मत surname - और उफ़! - पृष्ठ ने मेरे अंतिम नाम को "परीक्षण" से बदल दिया।

यह बहुत रोमांचक था। मैंने हमेशा SQL इंजेक्शन को किताबी कीड़ा माना है। तथ्य यह है कि यह वास्तव में कोड को खोलने के लिए दुनिया को खोलता नहीं है जो उपयोगकर्ता इनपुट को सीधे SQL अभिव्यक्तियों में सम्मिलित करता है।


सभी असंबद्ध के लिए, मैं समझाता हूं कि मेरे द्वारा खोजे गए परिणाम का क्या अर्थ है।
मेरा मानना ​​है कि सर्वर पर ऐसा ही कुछ होता है:

 const userId = someSessionStore.userId; const email = request.body.email; const sql = `UPDATE users SET email = '${email}' WHERE id = '${userId}'`; 

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

यदि मेरी उपयोगकर्ता आईडी 1234 है, और मैं ईमेल = नहीं भेजता हूं, तो SQL इस तरह से निकलता है:

 UPDATE users SET email = 'no' WHERE id = '1234' 

और यदि आप स्ट्रिंग no', surname = 'testing प्रतिस्थापित करते हैं, तो SQL मान्य होगा, लेकिन मुश्किल:

 UPDATE users SET email = 'no', surname = 'testing' WHERE id = '1234' 

जैसा कि आपको याद है, मैं डेवलपर टूल में कोड स्निपेट से अनुरोध भेजता हूं, जबकि मैं प्रोफाइल पेज पर हूं। तो अब से, आप इस पृष्ठ (HTML <इनपुट> तत्व) पर उपनाम फ़ील्ड के बारे में सोच सकते हैं, जिसमें आप डेटाबेस में surname कॉलम में मेरे उपयोगकर्ता खाते के लिए मूल्य निर्धारित करके जानकारी लिख सकते हैं।

तब मुझे आश्चर्य हुआ कि क्या मैं किसी अन्य कॉलम के डेटा को surname कॉलम में कॉपी कर सकता हूं?

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

डेटा को एक कॉलम से दूसरे में कॉपी करना थोड़ा और मुश्किल हो गया, क्योंकि मैं इस तरह का अनुरोध भेजना चाहता था (यह माना जाता था कि password कॉलम होना चाहिए):

 UPDATE users SET email = 'no', surname = password WHERE id = '1234' 

ध्यान दें कि password के आसपास कोड में कोई उद्धरण नहीं है। जैसा कि आप याद करते हैं, एक सुपर-आधुनिक क्वेरी डिज़ाइनर को इस तरह दिखना चाहिए ...

 const sql = `UPDATE users SET email = '${email}' WHERE id = '${userId}'`; 

... वह यह है कि, जब आप no', surname = password पास no', surname = password देने की कोशिश करते no', surname = password परिणामी स्ट्रिंग एक मान्य SQL क्वेरी नहीं होगी। इसके बजाय, मुझे अनुरोध के दूसरे भाग बनने के लिए पूरे इंजेक्शन वाले स्ट्रिंग की आवश्यकता थी, और इसके बाद आने वाली हर चीज को नजरअंदाज करना चाहिए। विशेष रूप से, मुझे WHERE और पास करने की आवश्यकता थी; SQL कथन के अंत में, साथ ही साथ # टिप्पणी करें ताकि इसके दाईं ओर की जानकारी को अनदेखा कर दिया जाए। हां, मैं बहुत समझाता हूं।

संक्षेप में, मैंने एक नई लाइन भेजी:

 { // ... body: `email=no', surname = password WHERE username = 'me@email.com'; #` } 

और निम्नलिखित लाइन डेटाबेस को भेजी जाएगी:

 UPDATE users SET email = 'no', surname = password WHERE username = 'me@email.com'; # WHERE id = '1234' 

कृपया ध्यान दें कि डेटाबेस WHERE id = '1234' को नजरअंदाज कर देगा, क्योंकि यह भाग टिप्पणी के बाद आता है # (एसक्यूएल प्रश्नों में टिप्पणी पर प्रतिबंध लगाने से मैला कोड से बचाने के लिए एक अच्छा तरीका लगता है)।

मुझे उम्मीद थी कि मेरा पासवर्ड P @ ssword1 अंतिम नाम फ़ील्ड में टेक्स्ट फॉर्म में दिखाई देगा, लेकिन इसके बजाय मुझे 00fcdde26dd77af7858a52e3913e6f3330a32b31 मिला।

इसने मुझे निराश किया, हालांकि इसने मुझे आश्चर्यचकित नहीं किया, और मैंने अपने पासवर्ड के हैश को किसी अन्य उपयोगकर्ता के पासवर्ड कॉलम में कॉपी करने का प्रयास जारी रखा।

मुझे शुरुआती लोगों के लिए समझाएं: जब आप कहीं खाता बनाते हैं और एक नया पासवर्ड P @ ssword1 भेजते हैं, तो यह 00fcdde26dd77af7858a52e3913e6f3330a32b31 जैसे हैश में बदल जाता है और डेटाबेस में संग्रहीत होता है। इस हैश को देखते हुए, कोई भी आपके पासवर्ड को निर्धारित करने में सक्षम नहीं होगा (या तो वे कहते हैं)।

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

इसका मतलब यह है कि अगर मैं किसी को पासवर्ड P @ ssword1 देना चाहता हूं, तो मुझे इस उपयोगकर्ता का मान पासवर्ड कॉलम में 00fcdde26dd77af7858a52e3913e6f3330a32b31 पर सेट करना होगा।

हल्के वजन।

मैंने एक और ब्राउज़र खोला, अलग-अलग मेल के साथ एक नया उपयोगकर्ता बनाया और सबसे पहले यह जांचा कि क्या मैं उसे डेटा सेट कर सकता हूं। इसके लिए body संपत्ति अपडेट करें:

 { // ... body: `email=no', surname = 'WOOT!!' WHERE username = 'user-two@email.com'; #` } 

मैंने कोड निष्पादित किया, इस उपयोगकर्ता के पृष्ठ को अपडेट किया और, ofiget, इसने काम किया! अब उनका उपनाम "WOOT !!" था। (मेरी दादी का पहला नाम)

फिर मैंने इस उपयोगकर्ता के लिए एक पासवर्ड सेट करने की कोशिश की:

  // ... body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b31' WHERE username = 'user-two@email.com'; #` } 

और तुम जानते हो क्या?!?!?

यह काम नहीं किया अब मेरे पास दूसरे खाते तक पहुंच नहीं थी।
यह पता चला कि मैंने दो गलतियाँ कीं, जिनकी गणना में कई घंटे लग गए। इस लेख को पढ़ने वाले सूचना सुरक्षा विशेषज्ञ पहले से ही समझ चुके हैं कि वे किस बारे में बात कर रहे हैं और संभवत: उस मूर्ख पर हँस रहे हैं जो हैकिंग के पहले पृष्ठ पर सूचीबद्ध अपने "कारनामे" को सबसे कम उम्र में लिखता है।

Nuuuuu, अंत में मैंने "पासवर्ड हैश" के लिए नेटवर्क खोजा और देखा कि कई हैश मेरे 00fcdde26dd77af7858a52e3913e6f3330a32b31 से अधिक लंबे हैं। लगता है वह कहीं फसल कर रहा है।
मैंने उपनाम क्षेत्र में पाठ का एक टुकड़ा दर्ज करने की कोशिश की, और 40 अक्षरों की सीमा पाई (यह अच्छा है कि वे डेटाबेस बाधा से मेल करने के लिए <इनपुट> के लिए अधिकतम गति निर्धारित करते हैं)।

अब मुझे केवल हैश के पहले 40 पात्रों में दिलचस्पी थी, जो बहुत लंबे समय तक हो सकते थे। मैंने "sql सबस्ट्रिंग" की खोज की, और जल्द ही सर्वर को निम्नलिखित अनुरोध भेजा:

 { // ... body: `email=no', surname = SUBSTRING(password, 30, 1000) WHERE username = 'me@email.com'; #` } 

30 के साथ शुरू यह सुनिश्चित करने के लिए कि पहले 10 अक्षर अंतिम 10 वर्णों के साथ ओवरलैप होते हैं 00fcdde26dd77af7858a52e3913e6f3330a32b31। या अंतिम 9. या 11।


वास्तविकताओं पर वापस: वर्णों को ओवरलैप किया गया और लाइनों के संयोजन से मुझे 64 वर्णों का हैश मिला। फिर से मैंने इसे दूसरे उपयोगकर्ता पर कॉपी करने की कोशिश की:

  { // ... body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b3121a61bce915cc6145fc44453' WHERE username = 'user-two@email.com'; #` } 

और तुम जानते हो क्या?!?!
ठीक है, आपने इसका अनुमान लगाया, क्योंकि मैंने दो गलतियों का उल्लेख किया है।

मैं अभी भी दूसरे खाते में प्रवेश नहीं कर सका, लेकिन पहले से ही इसके करीब था (मेरे लिए उस समय इसके बारे में जानना अच्छा होगा)।

मैंने "सर्वोत्तम प्रैक्टिस डेटाबेस पासवर्ड" की खोज की और "नमक" जैसी चीज़ को याद किया।

नमक का उपयोग करने का अर्थ है कि यदि आप एक उपयोगकर्ता के लिए P @ ssword1 के लिए एक हैश बनाते हैं, तो दूसरे उपयोगकर्ता के लिए एक ही पासवर्ड एक अलग हैश (दूसरा नमक का उपयोग किया जाता है) देगा। बेशक, एक पासवर्ड हैश दो उपयोगकर्ताओं के लिए काम नहीं करेगा, लवण अलग हैं।

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

मैंने उस कॉलम से मान कॉपी करने की उम्मीद में क्वेरी बदल दी जिसे नमक कहा जा सकता है,
उपनाम कॉलम के लिए:

  { // ... body: `email=no', surname = salt WHERE username = 'myemail@email.com'; #` } 

पात्रों का एक यादृच्छिक सेट उपनाम क्षेत्र में दिखाई दिया, एक अच्छा संकेत। 64 चरित्र वाले नमक के लिए जो निकला, उसे पाने के लिए मैंने फिर से SUBSTRING का उपयोग किया।

सब कुछ तैयार था। मेरे पास एक पासवर्ड हैश है और इसे बनाने के लिए जिस नमक का उपयोग किया गया था, आपको बस उन्हें किसी अन्य उपयोगकर्ता को कॉपी करने की आवश्यकता है। और मैंने उस शाम अपना आखिरी नेटवर्क अनुरोध भेजा:

 fetch('https://blah.com/api/users', { credentials: 'include', headers: { authorization: 'Bearer blah', 'content-type': 'application/x-www-form-urlencoded', 'sec-fetch-mode': 'cors', 'x-csrf-token': 'blah', }, referrer: 'https://blah.com/blah', referrerPolicy: 'no-referrer-when-downgrade', body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b3121a61bce915cc6145fc44453', salt = '8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52' WHERE username = 'user-two@gmail.com'; #`, method: 'POST', mode: 'cors', }); 

यह काम किया! अब मैं पहले खाते के पासवर्ड से दूसरे खाते में लॉग इन कर सकता था।
क्या वह पागल नहीं है?

* * *

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

सिद्धांत रूप में, निश्चित रूप से। मैं ऐसा कभी नहीं करूंगा।

* * *

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

लेकिन मैं खुद से यह पूछने में मदद नहीं कर सकता कि क्या यह सिर्फ एक शुरुआत थी। यह वस्तुतः पहली साइट है जिस पर मैंने एसक्यूएल इंजेक्शन की कोशिश की, और सब कुछ मेरे लिए तैयार किया गया था, जैसे कि मैंने बच्चों के लिए हैकिंग परीक्षा पास की थी।

जिस साइट का मैंने वर्णन किया है वह छोटी है, इसमें कुछ उपयोगकर्ता (34,718) हैं। यह एक पेड सर्विस है, इसलिए अनुभवी हैकर्स के लिए यह कोई दिलचस्पी नहीं है। और फिर भी इसने मुझे मारा कि यह संभव था।

संक्षेप में, अब मैं इस पूरे विषय पर सूचना सुरक्षा से जुड़ा हुआ हूं। मेरे लिए, दो पसंदीदा गतिविधियों को इसमें जोड़ा गया था: एक कोड और गुंडे लिखना। इसलिए "सूचना सुरक्षा वेतन ऑस्ट्रेलिया" को देखते हुए, मुझे लगता है कि मैंने खुद को एक नई नौकरी दी।
पढ़ने के लिए धन्यवाद!

पुनश्च: लेख का अनुवाद लेखक की शैली को यथासंभव संरक्षित करने की कोशिश करता है :)